Protocol overview and issuance

The Standard Reserve ("STANDARD") is an on-chain reserve protocol on Robinhood Chain (chain id 4663): a Central Bank contract, a supply of $STANDARD tokens, an ETH/STANDARD Uniswap v4 pool, and a set of charters and branches that mint new supply over time. The Standard token contract itself and the TaxHook have Sourcify-verified source (exact match, 2026-09-16); the Central Bank and the other 9 contracts don't, so this page states each mechanic's basis the way the API does: measured (read straight off a contract call or log), constant (a fixed parameter read once from chain), or inferred_from_bytecode (the rule was pinned by running the real deployed bytecode against controlled inputs on a fork, because no verified source exists to read it from). See Contracts and addresses for the full verification breakdown and How to read a TSR response for the full field vocabulary.

Supply: the hard cap, and what actually shrinks it

Standard's verified source fixes a hard cap of 1,000,000,000 (one billion) STANDARD. maxSupply(), the number GET /v1/supply/current reports as the ceiling issuance can ever reach, starts there and only ever decreases, never back up. Two different things can lower it, and only one of them is a "burn" in the sense of tokens leaving circulation for good:

• Permanent burns (the public burn/burnFrom functions, used for buybacks, POL fee disposal, and voluntary burns, plus the STANDARD leg the tax hook burns on a non-POL LP withdrawal) reduce maxSupply and can never be re-minted. GET /v1/supply/current's burned_forever_cum_raw field tracks this cumulative total. This is what "burned" means in the sense that matters for supply: gone.
• Ledger retirements (the Central Bank's retire, used for license payments and the non-recycled half of resolution and revocation fees) also reduce maxSupply by the same amount, but no token ever moves: it's unminted ledger value written off, not a Transfer to the burn address. ledger_retired_cum_raw tracks this total separately.

Neither of those is the same as depositing STANDARD into the Central Bank (convertFrom, the deposit path underlying a charter's pending-credit balance). A deposit does send STANDARD to the burn address, and so it's counted in burned_cum_raw (the raw sum of every Transfer to 0x0), but it does not reduce maxSupply and is not part of burned_forever_cum_raw: the value becomes ledger credit that a later withdraw re-mints back into circulation. deposited_cum_raw tracks this cumulative total separately so it isn't mistaken for a permanent burn. Concretely: burned_cum_raw ≈ burned_forever_cum_raw + deposited_cum_raw, but only the first term is gone for good.

The practical read: if you want "how much STANDARD has left circulation forever," use burned_forever_cum_raw plus ledger_retired_cum_raw, not burned_cum_raw. circulating_raw (minted minus everything burned, deposited or not) is unaffected by which bucket a burn falls into, since a deposit is a real supply move even though it's reversible; it's specifically the label "burned" that overstates permanence if applied to the raw Transfer-to-0x0 total.

Issuance: charters, branches, and the base rate

A charter is a soulbound (non-transferable) ERC-721 token, your membership in the reserve. A charter earns nothing by itself; it becomes productive once it opens one or more branches, which it does by burning STANDARD for a license (see Charters, branches, and licenses). Every open branch accrues new STANDARD issuance continuously, at a per-branch rate derived from a chain-read base_rate divided across the total number of branches and scaled by the current multiplier. GET /v1/constants (1s_std_addresses's sibling constants call) and GET /v1/supply/current report the live inputs; there are no whitepaper numbers baked into this page, since whitepaper constants are redacted by design and the deployed contract is the only source of truth.

Epochs: the accounting window for policy

An epoch is the Central Bank's fixed-length settlement window. At the end of each epoch, the bank reads the net ETH flow into or out of the ETH/STANDARD pool over that period. That's pool-side ETH: what the pool's own reserve actually gained or lost, not what any individual trader paid or received (buy-side taxes are excluded from inflow; sell-side taxes are included in outflow, basis: inferred_from_bytecode, confirmed by fork replay of six real transactions). That flow becomes the epoch's own signal. The step rule below actually reads signal_n = F_n + F_{n-1} (this epoch's flow plus the prior epoch's), not a single epoch's flow in isolation.

The multiplier: bounds and the step rule

The multiplier scales issuance up or down between epochs. It only moves at a settlement boundary, and only in the direction the two-epoch signal points (basis: inferred_from_bytecode, pinned by running the deployed Central Bank bytecode through 15 scripted scenarios on a mainnet fork, see docs/tsr/BYTECODE_SEMANTICS_2026-09-15.md in sre-services for the transcripts):

• Positive signal (> 0): the consecutive-positive streak increments, and the multiplier raises starting from the second consecutive positive settlement, not the first.
• Zero signal: a hold. The streak resets to zero, but the multiplier does not move. Zero is neither a raise nor a cut.
• Negative signal (< 0): the streak resets to zero, and the multiplier cuts, except the very first settlement the bank ever performs never cuts, regardless of how negative the signal is. Every settlement after the first cuts normally.

The streak keeps counting even after the multiplier hits its ceiling (it doesn't reset on a raise), and cuts can repeat every epoch the signal stays negative, all the way to the floor. Constants (M_STEP_UP, M_STEP_DOWN, M_MIN, M_MAX, M_START) are chain-read and reported by GET /v1/constants; this page doesn't restate their values since they're exactly the kind of number that would drift out of sync with a live read.

What's unresolved: no epoch had settled on mainnet as of the fork analysis behind this page, so the step rule (including the first-settlement no-cut exemption and the exact reason for it) is pinned by executing the real bytecode with chosen inputs, not by observing a real EpochSettled event. It should be re-checked against the first live settlement. GET /v1/policy/current and GET /v1/policy/outlook both label every pre-settlement field with its own _source and _basis so a caller can tell a live constants-derived estimate from a settled, event-sourced one.

Where to look

Question	Route	MCP tool
What's the current epoch's signal, regime, and multiplier?	GET /v1/policy/current	1s_std_policy_current
What would the multiplier be if this epoch's sign holds?	GET /v1/policy/outlook	1s_std_policy_outlook
How much of the issuance budget is left, and when does it run out at this rate?	GET /v1/issuance/runway	1s_std_issuance_runway
What are the chain-read constants behind all of this?	GET /v1/constants	n/a
What's the current supply, and how much of the cap is permanently gone vs. just deposited?	GET /v1/supply/current, /history	1s_std_supply

See Deciding with the data for the fuller decision-oriented walkthrough of "what will policy do next."