Reserves, vaults, POL, and buybacks

STANDARD is backed by ETH held in two vaults, the reserve assets the expansion vault has bought with some of that ETH, and 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"). Since 2026-10-02 the address registry points the expansion vault at a multisig Safe (2 of 4 signers) instead of a contract, and on 2026-10-13 and 14 that Safe moved most of its ETH into USDG, the Reserve's stock tokens and Uniswap v4 liquidity (see Reserve assets and the all-assets ratio). OneSource follows whatever address the registry currently lists. GET /v1/backing/current reports each vault's custody (type, owner_count, threshold) and the vault's USDG as expansion_vault_usdg, which stays in USDG's own units and also carries an eth_value. GET /v1/vaults/current reports expansion_eth_raw as basis: measured. Its 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' ETH balances, plus pol_eth_raw/pol_std_raw when observed, feed GET /v1/backing/current and /history. incentives_vault_std_raw (below) does not: it's STANDARD held for a different purpose, not ETH-equivalent backing, so it's reported alongside the backing ratios rather than folded into them.

Reserve assets and the all-assets ratio

Until 2026-10-13 the expansion vault held almost only ETH, so an ETH-only backing ratio told the whole story. Over the next two days it moved most of that ETH into USDG, the Reserve's stock tokens (SPCX, BABA and SKHY) and Uniswap v4 liquidity positions. The vault still held the value, but the two older ratios only count ETH, so they fell by roughly 18 times. GET /v1/backing/current now adds a third ratio, eth_backing_per_standard.including_reserve_assets, which counts those holdings as well.

including_reserve_assets is the vault's ETH, plus the ETH value of its Uniswap v4 positions (principal and uncollected fees), plus the ETH value of its priced reserve assets (USDG and the stock tokens), divided by circulating STANDARD. POL stays out for the reason given below. The ratio carries the label "all reserve assets at current pool prices", and that label is literal:

• Stock tokens and liquidity positions are valued at the current price in the Reserve's own stock/USDG Uniswap pools.
• USDG is counted at $1 and converted to ETH with the Chainlink ETH/USD price.

These are current pool prices. They move, and selling a large amount would fetch less. The ratio is null until a snapshot has both a position inventory and prices, and including_reserve_assets_note repeats the basis next to the number.

Three response fields show where the figure comes from:

• vault_positions: one entry per Uniswap v4 position the expansion vault owns, with the pool, the tick range, in_range, the amounts on each side, uncollected fees, and an eth_value with a valuation0 and valuation1 naming how each side was priced.
• reserve_value: the same total split into vault_positions_eth, usdg_eth and stock_tokens_eth, with total_eth, the eth_usd_price used, and unavailable and unpriced lists for anything that couldn't be valued.
• eth_value and valuation on each entry in reserve_assets and on expansion_vault_usdg. An asset that couldn't be priced has a null eth_value and valuation: unpriced.

GET /v1/backing/history carries the new ratio as eth_backing_per_standard_including_reserve_assets. It starts at the first snapshot that measured positions and prices. Earlier points are null and aren't backfilled.

excluding_pol and including_pol keep their original meaning: vault ETH without and with POL. That keeps their history comparable, but they now fall whenever the vault moves ETH into another asset, so a drop in either no longer means backing shrank. Use including_reserve_assets to ask what the vault's whole reserve is worth per STANDARD, and the ETH-only pair to ask how much plain ETH is left.

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 keeps POL out of the reserve-asset figure and reports two ETH-only figures beside it: excluding POL (only the two vaults' direct ETH) and including POL (adding the reserve's pool share). None of the three is "the" backing number; they answer different questions. One is what the protocol could redeploy today. Another is what the reserve's full on-chain footprint adds up to. including_reserve_assets values everything the expansion vault holds, apart from POL.

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.

Protocol v1.1: bid-side-only buybacks and the incentives vault

Protocol v1.1 (live 2026-09-21) changed where the POL share of protocol fees goes. Per the whitepaper, that share used to top up POL Manager's own paired ETH/STANDARD position in the pool; it no longer does. Instead a separate polBuyback contract uses it to buy STANDARD off the market (bid-side only, no new pairing) and forwards those tokens to a new incentivesVault contract, held there for future distribution rather than burned. The whitepaper is explicit that this doesn't touch what POL Manager already holds: "the genesis liquidity positions remain in place and no longer receive new liquidity from the POL share... their original manager continues collecting LP fees." So pol_eth_raw/pol_std_raw/pol_total_controlled_*_raw keep meaning what they meant before v1.1; only the growth path changed.

GET /v1/vaults/current and /history report the incentives vault's balance as incentives_vault_std_raw, with an incentives_vault_note explaining why it's kept separate from the backing figures above. Each polBuyback purchase is decoded and served as a pol_buyback row in GET /v1/flows/protocol (ETH spent and STANDARD received), and each LP fee collection by the POL Manager as a pol_fees_collected row (see Where protocol money moves).

The incentives vault is also where the S-Bills premium budget's 1.5M STANDARD seed came from, moved via the owner Safe as a plain transfer rather than a tracked polBuyback distribution. See S-Bills: fixed-term staking for what that seed funds and how OneSource tells it apart from an ordinary deposit.

Where protocol money moves

GET /v1/flows/protocol (1s_std_protocol_flows, $0.02) lists the protocol's own money movements, newest first, one row per movement with a kind:

• holdings_migrated: a vault or the POL Manager moved its whole balance to a successor address.
• taxes_forwarded: the tax hook paid settled taxes to the FeeSplitter (ETH).
• fees_recycled: resolution and revocation fees the Central Bank returned to issuance for one epoch (STANDARD).
• team_claimed: a team claim paid out of the FeeSplitter (ETH).
• pol_buyback and pol_fees_collected: the buybacks and LP fee collections described above.
• pol_paired: a POL Manager pairPol call, which puts ETH into the STANDARD/ETH pool as protocol-owned liquidity by swapping part of it for STANDARD and adding both as a full-range position. eth_amount is the ETH committed in that call.
• incentive_sent: the incentives vault sent a token. The 1.5M STANDARD S-Bills seed is one of these rows.
• vault_outflow: value that left the reserve vault Safe, in ETH or an ERC-20 token such as USDG, with a method field naming how it moved (a swap call, a plain ETH send, or a token transfer).

Rows also carry a to_label that names to_address when it is a known counterparty, and is null otherwise. The labels are uniswap_v4_position_manager, uniswap_v4_pool_manager, uniswap_swap_router_02, expansion_vault_safe, protocol_owner_safe, incentives_vault, fee_splitter and stock_token_counterparty. The last is the address the vault paid 2,550,200 USDG to and received 3,461.60 SPCX, 8,698.18 BABA and 6,233.77 SKHY from in return. The API doesn't attribute it beyond that.

Sends between Safes that hold the reserve at that block are internal moves and get no row. A Safe can batch several sends into one transaction (multiSend); each send that leaves custody gets its own row, told apart by sub_index. Amounts are integer strings in the token's smallest unit, each with a *_dec field already divided by the token's decimals. Filter with kind and page with cursor.

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 bid-side POL buyback) 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 fifteen 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, counting every reserve asset?	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
Where has protocol money moved, including value that left the reserve vault?	GET /v1/flows/protocol	1s_std_protocol_flows
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.