Four prices, one stock
Every tokenized equity on Robinhood Chain has four prices that disagree by construction. Two are multiplier-adjusted and two are not. Mixing them is the most reliable way to produce a wrong number on this chain — and the spread between them is the signal nobody publishes.
RobinhoodRPC Research
Engineering & market structure
Ask what AAPL is worth on Robinhood Chain and there are four defensible answers. They are all correct, they measure different things, and two of them are scaled differently from the other two.
The four sources
Robinhood's REST endpoint returns the price of the underlying share. Chainlink's onchain feed returns the price of one token, which is the underlying share price times the multiplier. Applying uiMultiplier() to a Chainlink price squares it; forgetting to apply it to a Robinhood price divides the answer by it.
The number nobody publishes
The interesting quantity is not any single price but the gap between what the token trades at onchain and what the underlying is worth. That is the premium or discount, and it is the defining signal on a tokenized-equity chain: it indicates arbitrage opportunity, liquidity stress, and whether the tokenization is holding its peg.
premium_bps = (dex_mid − underlying_mid × multiplier) ÷ (underlying_mid × multiplier) × 10000No provider on Robinhood Chain publishes it. Every input is public — the chain, Robinhood's free REST API, Chainlink's feeds — so this is not a data-access problem. It is a composition problem, and composition is the part generic infrastructure has no reason to do.
The hard part is timing, not arithmetic
The formula is trivial. What is not trivial is that the four inputs arrive on different clocks: a 15-second REST cache, an oracle heartbeat that may not have fired, sub-second pull-based streams, and per-block DEX observation.
Treating them as simultaneous introduces an error that looks exactly like a real premium. Each input therefore has to carry its own observation time and staleness, and a reconciliation built on a stale oracle must be flagged rather than published as though it were fresh.
Sessions change the answer
Chainlink's tokenized equity feeds run 24/5. The chain runs 24/7. Prints therefore land while the underlying market is closed, and that is precisely when divergence is widest — the token keeps trading against an underlying reference that stopped updating hours ago.
A premium computed without a session tag is not interpretable. A wide overnight spread is usually a stale reference, not a mispriced token, and a system that cannot tell those apart will generate false signals every night.
Flags, not silent numbers
- STALE_ORACLE — the Chainlink round is older than the tolerance; staleness reported in milliseconds.
- SESSION_CLOSED — the underlying market was shut when this was computed.
- TRADING_HALTED — the instrument is halted.
- CONTRACT_PAUSED — a corporate action pause window is active.
- MULTIPLIER_PENDING — a multiplier change is scheduled and not yet applied.
- WIDE_SPREAD / THIN_LIQUIDITY — the onchain side is unreliable.
The rule underneath all of these is the same: degrade loudly. A stale value flagged as stale is useful. A stale value served confidently is worse than no value at all, because the consumer cannot detect it.