Lighter Core and Robinhood Chain: two perp instances, one data trap

Start with the two instances

Lighter Core describes an exchange whose state and execution proofs are anchored to Ethereum. Robinhood Chain documents a separate Lighter instance with its own contracts, sequencer, blockspace and liquidity. The distinction is operational: an order or position in one environment cannot be assigned to the other's book simply because both use the Lighter name.

The Robinhood Chain documentation gives its own contract and API base. That is the starting key for a dataset. A parent label such as 'Lighter' can describe the broader ecosystem, but an analyst must decide whether a reported number refers to Core, the Robinhood Chain instance, or a clearly defined sum of non-overlapping components. A provider's page title alone is not enough to make that decision.

Sources: Lighter Core technical architecture ↗ · Robinhood Chain Lighter Domains ↗

Robinhood Wallet is an interface to a Lighter market

Robinhood's Wallet guide says a user deposits USDG into a Lighter trading contract on Robinhood Chain, then signs an order to open a perp position on Lighter. The Wallet presents balances, orders and risk information to the trader. The documented destination is the Robinhood Chain Lighter instance, not a new Wallet order book to add to the venue total.

A trader can use leverage to gain exposure to a stock or crypto price without owning the underlying asset. That makes these contracts relevant to a perp research universe, including when the reference asset is a traditional-market instrument. It does not turn a Robinhood stock token or a spot transaction into a perpetual trade. Market lists and eligibility may differ by interface and over time.

Sources: Robinhood Wallet perpetual futures guide ↗ · Robinhood Chain Lighter Domains ↗

How to count activity without counting a trade twice

For each daily observation, retain an instance identifier, venue API host, UTC start and end, contract type, unit, raw response and retrieval time. In Core's documented market-metadata endpoint, the filter can select perp rather than spot books. Robinhood Chain publishes a separate API base; its market definitions need their own captured response. An endpoint reference proves that a route exists. It does not provide a historical 30-day volume or open-interest series by itself.

A clean expansion starts with two venue children and one ecosystem parent. An interface such as Robinhood Wallet attaches to the Robinhood Chain child. Do not add the interface's activity to that child's activity; the same executed order may appear in both views. Add the two child instances to an ecosystem total only when their periods, units, market filters and source coverage are comparable and the parent total has not already included them. Otherwise show the separate rows and mark the combined value unknown.

Sources: Lighter Core orderBookDetails API reference ↗ · Robinhood Chain Lighter Domains ↗ · Robinhood Wallet perpetual futures guide ↗

Volume does not establish the fees or revenue a token receives

Lighter's published Core schedule describes a Standard account with zero maker and taker trading fees and paid Premium tiers. It does not tell us how many fills occurred in each tier, what other charges applied to an account, or which schedule governs the separate Robinhood Chain instance. Applying one advertised rate to all reported volume would manufacture a fee estimate rather than reconstruct realized charges.

The same care applies to external provider totals. Before comparing reported fees with volume, inspect what each numerator includes, whether both belong to the same instance and whether their windows end at the same UTC boundary. Transfer, withdrawal or liquidation charges can make a provider's broad fees field different from trading fees. Protocol revenue is a further accounting step; token-holder benefit is another step still. A zero in one provider field means that provider reported zero for its defined field, not proof that the entire business earned nothing.

Sources: Lighter trading fee schedule ↗ · Robinhood Chain Lighter Domains ↗

What LIT documentation establishes—and what remains to verify

Lighter's utility documentation describes LIT staking for Liquidity Pool access, staking-related rewards, trading-fee discounts and a plan to use trading-fee revenue for LIT purchases. These are documented mechanisms and terms. They are not, on their own, a ledger of purchases, burns or distributions. The page's displayed treasury address is an all-zero placeholder, so that address cannot be used to trace execution.

A future token-flow analysis needs dated terms for each instance, identified contracts and transaction records, current supply conventions and an unlock schedule. It must distinguish tokens bought for a treasury from tokens permanently burned, and avoid crediting one purchase as two separate holder benefits. Until that reconciliation exists, PerpsAtlas will not infer an annualized LIT benefit or a valuation from volume and a stated buyback policy.

Sources: LIT utility documentation ↗ · Lighter trading fee schedule ↗

The evidence needed for a live Lighter profile

The next step is not to promote a moving provider snapshot into a ranking. We need captured raw responses from each instance; stable mapping of every perp market to its order book; daily UTC volume and open-interest observations with null reasons; and a comparison against separately scoped provider records. A gap in historical coverage should remain visible as a gap, not be filled with the other instance's numbers.

Only after those checks can we show comparable 30- and 90-day changes, fees, revenue and a money-flow waterfall. If Core and Robinhood Chain share a program or treasury, the accounting must identify the actual source and destination of that flow. The article's scope classification is ready; a verified time series and token execution record are not yet established.

Sources: Robinhood Chain Lighter Domains ↗ · Lighter Core orderBookDetails API reference ↗ · LIT utility documentation ↗

What we monitor next

• Capture and reconcile daily perp-only market, volume and open-interest responses for each instance.
• Check the effective fee and token-program terms for each instance before attributing revenue or token benefit.
• Trace any stated buyback through identified contracts and transactions; establish current supply and unlock data.

Frequently asked questions

Is Robinhood Wallet a third Lighter exchange?

No. Robinhood documents Wallet trades as orders on the Lighter instance deployed on Robinhood Chain.

Can I add Core and Robinhood Chain volume?

Only after confirming non-overlapping instance scopes and matching periods, units and contract filters. Never add a Wallet interface total to the instance executing its trades.

Does documented LIT utility prove holders received revenue?

No. Terms describe possible mechanisms; realized purchases, distributions, burns and supply effects require separate dated transaction evidence.

Compare the evidence

Related research

• How much does a perp DEX trade really cost? Fees, fills and funding →

Source register

1. Lighter Core technical architecture · checked 2026-09-29
2. Robinhood Chain Lighter Domains · checked 2026-09-29
3. Robinhood Wallet perpetual futures guide · checked 2026-09-29
4. Lighter Core orderBookDetails API reference · checked 2026-09-29
5. Lighter trading fee schedule · checked 2026-09-29
6. LIT utility documentation · checked 2026-09-29