Reserves, vaults, POL, and buybacks

STANDARD is backed by ETH held in two vaults, plus any reserve assets the expansion vault has acquired, plus the reserve's own share of the ETH/STANDARD pool's liquidity.

The two vaults

• Expansion vault: accumulates ETH during expansion (net-inflow) epochs, intended to deploy it into hard reserve assets (the whitepaper describes "tokenized gold, comparable"; the specific asset and the deployment split are not yet observed live). GET /v1/vaults/current reports expansion_eth_raw as basis: measured; reserve-asset fields (reserve_assets.gold_raw, etc.) stay null until that path is actually exercised on-chain, not coerced to zero. See Null means "couldn't read it," not zero.
• Contraction vault: funds automated buybacks that burn STANDARD from the market during contraction (net-outflow) epochs. contraction_eth_raw is likewise basis: measured.

Both vaults' balances, plus pol_eth_raw/pol_std_raw when observed, feed GET /v1/backing/current and /history.

Hook-held taxes are not vault backing

Collected trading taxes (see Trading tax hook) sit in the TaxHook contract's own ETH balance until the permissionless forwardTaxes() pushes them to the FeeSplitter, and from there they route onward by the protocol's normal fee logic, not into either vault directly. GET /v1/buybacks/readiness reports that pending balance as hook_eth_balance_raw, plus fee_splitter_eth_balance_raw for ETH that reached the FeeSplitter but hasn't been routed further. Neither figure is counted in backing/current's vault totals, with or without POL: it's protocol revenue in transit, not reserve backing a STANDARD holder could redeem against. Don't add either balance into a backing-per-token calculation built from /v1/backing/current alone.

Protocol-owned liquidity (POL)

POL is liquidity the protocol itself owns inside the ETH/STANDARD Uniswap v4 pool, as opposed to liquidity supplied by outside market makers, managed by a dedicated POL Manager contract. It's seeded at genesis and can grow from a share of ongoing fees. Because POL sits inside the pool rather than in a vault the protocol could otherwise redeploy, GET /v1/backing/current reports two figures rather than one: excluding POL (only the two vaults' direct holdings) and including POL (adding the reserve's pool share). Neither is "the" backing number; they answer different questions. One is what the protocol could redeploy today; the other is what the reserve's full on-chain footprint adds up to.

The POL Manager also carries a TWAP deviation gate: a bound (in ticks) on how far the pool's price can have moved from its time-weighted average before certain POL Manager operations (deploying ETH into the pool, for instance) are allowed to proceed. This exists to stop POL operations from executing against a price that's been manipulated or is moving unusually fast in a single block. The exact selectors and events behind this (setTwapDeviationTicks, TwapDeviationSet, a public/private deviation-ticks split) are confirmed by keccak-matching the observed event signatures against the deployed bytecode (basis: inferred_from_bytecode, hash-confirmed, a confirmed signature, not a confirmed account of every field's semantics). The time-weighted reference itself lives on the verified TaxHook contract, not the POL Manager: the hook tracks a running tick-cumulative and rotates a pair of window checkpoints on every swap, giving a time-weighted average tick over roughly one to two 30-minute windows, which is what a buyback or POL crank's TWAP-deviation check actually compares the current tick against.

The pool's LP fee

Separately from the tax hook's own buy/sell tax, the ETH/STANDARD pool charges the ordinary Uniswap LP fee that liquidity providers earn on every swap. GET /v1/pool reports its rate as lp_fee_bps, read live from Uniswap and cached in tsr.constants as pool_lp_fee_ppm; it's a static 100 bps (1%), not a value that moves with the launch-tax decay. This rate is folded into the price-impact estimates used elsewhere in this API, for example the estimated ETH cost of a license on GET /v1/branches/license-cost and the strategy simulation on GET /v1/decisions/plan, both of which take a fee at this rate off the post-tax amount as one of the haircuts between a nominal price and what actually settles, as a modeling simplification rather than a confirmed statement of which side of the swap bears it on-chain. Which side actually pays the LP fee is a separate, still-unresolved question; see Governance switches and risks for why knowing the rate doesn't settle that.

Buybacks

A buyback tick burns STANDARD purchased with contraction-vault ETH. GET /v1/buybacks/readiness reports whether a tick could fire right now, covering capacity, any cooldown since the last tick, the TWAP-deviation check above, and a log of recent executed ticks. Before the first epoch has settled, this route (like /v1/policy/current) falls back to a live, clearly-labeled regime_provisional/regime_note estimate rather than presenting an unsettled regime as final.

Whether a buyback tick (or a POL-pairing swap) can be triggered by anyone, or only by a designated crank operator, is a separate question that permissionless answers directly: it reads the AddressRegistry's executionPermissionless one-way switch, with permissionless_source naming the exact call (registry.executionPermissionless), since the registry itself exposes no such flag from the outside without reading it directly. See Governance switches and risks for what the switch governs and its current state, and for the executor/guardian addresses GET /v1/buybacks/readiness also reports.

What's not yet confirmed: the whitepaper's own regime-based ETH-split (it describes a 70/15/15 split across uses by regime) is unverified against the deployed Central Bank contract. Two of the twelve Standard Reserve contracts (Standard and TaxHook) have Sourcify-verified source (exact match, 2026-09-16); the Central Bank is not among them, so its internal fee-routing logic isn't something this API can read out of Solidity and confirm. Treat any specific split percentage you see elsewhere as whitepaper framing, not a confirmed mainnet behavior, until a verified source or a bytecode-fork analysis pins it the way the tax decay curve and multiplier step rule were pinned.

USD pricing on pool state and candles

GET /v1/pool and GET /v1/pool/candles (with quote=usd) both add USD-denominated fields (price_usd_per_std, and open_usd/high_usd/low_usd/close_usd on candles) alongside the native ETH-denominated ones. The conversion comes from Chainlink's ETH/USD price aggregator on Ethereum mainnet, read separately from the Robinhood Chain pool state and stamped with its own usd_as_of_block (the Ethereum mainnet block the oracle read came from, distinct from the response's own Robinhood Chain as_of_block). If the feed's answer is non-positive or more than an hour stale, every *_usd field comes back null with a usd_unavailable_reason, and the ETH-denominated fields are unaffected either way.

Where to look

Question	Route	MCP tool
Is the token backed, and by how much per STANDARD?	GET /v1/backing/current, /history	1s_std_backing
Could a buyback fire right now?	GET /v1/buybacks/readiness	1s_std_buyback_readiness
What's in each vault right now, and historically?	GET /v1/vaults/current, /history	1s_std_vaults
What's the pool's current price, tick, and liquidity?	GET /v1/pool	1s_std_pool

See Deciding with the data for the fuller backing/buyback decision walkthrough.