Contracts and addresses

The Standard Reserve deployed 12 contracts on Robinhood Chain (chain id 4663) at launch, plus it shares the chain's existing Uniswap v4 PoolManager singleton rather than deploying its own. Protocol v1.1 (live 2026-09-21) added two more (incentivesVault, polBuyback) and replaced licenseAuction outright with a new deployment, kept in the registry as licenseAuctionLegacy so its auction history stays attributable to the contract that actually ran it. A later addition, sbills (S-Bills fixed-term staking, deployed 2026-10-01; see S-Bills: fixed-term staking), is not in the AddressRegistry at all, the only one of the 16 that isn't. GET /v1/addresses is the live source of truth, it's free, requires no API key or payment, and exists specifically so you can check an address before sending it funds or trusting data attributed to it. Don't hardcode addresses from this page or any other document into anything that moves money; read them from that endpoint at call time.

The 16 roles, plus the shared pool singleton

Role	What it does
registry	Address book the other contracts resolve each other's roles through
centralBank	Issuance authority: reads pool net flow, sets the multiplier, routes fees
standard	The $STANDARD ERC-20 token itself
charterNFT	The soulbound charter ERC-721
taxHook	Uniswap v4 hook applying the launch-tax decay on swaps (see Trading tax hook)
polManager	Manages protocol-owned liquidity in the ETH/STANDARD pool, including the TWAP-deviation gate
feeSplitter	Routes protocol fee flow across destinations
contractionVault	Holds ETH for automated buybacks during contraction
expansionVault	Holds ETH for reserve-asset accumulation during expansion. Since 2026-10-02 the registry points it at a multisig Safe (2 of 4 signers); see Reserves, vaults, POL, and buybacks
licenseAuction	Runs the branch-license Dutch auction. Protocol v1.1 replacement, active from block 69222157; see Charters, branches, and licenses for the cadence change
licenseAuctionLegacy	The retired license auction this replaced. Kept in the registry, not scanned for new activity, so auction days sold before the switch stay attributable to the contract that actually ran them
charterAuction	Runs the charter Dutch auction
genesisMinter	Handled the founding-charter genesis mint
incentivesVault	Protocol v1.1: holds STANDARD bought back by polBuyback, for future distribution (see Reserves, vaults, POL, and buybacks)
polBuyback	Protocol v1.1: executes the bid-side buybacks that fund incentivesVault. Its buyback events are decoded and served as pol_buyback rows in GET /v1/flows/protocol
poolManager (shared)	Uniswap v4's own singleton contract; the ETH/STANDARD pool is one PoolId inside it, not a separate deployed contract
sbills	Fixed-term STANDARD staking (S-Bills). Not in the AddressRegistry; OneSource hard-codes the address and checks it against the registry and token addresses embedded in the contract's own bytecode (see S-Bills: fixed-term staking)

Every address was sourced from the team's own published site bundle, their live app's configuration, not an explorer name match, since name matching on an explorer is exactly the copycat vector this registry exists to defend against. Each was then cross-checked as present on-chain, with non-zero bytecode, at its stated deployment block. taxHook deployed as its own separate contract, later than centralBank/standard/charterNFT (which share one deploy block). This differs from the rehearsal cluster's arrangement, where the Central Bank contract itself doubled as the pool's hook; don't assume this deployment's pattern carries over to any other TSR-shaped deployment. The three Protocol v1.1 additions (licenseAuction's new deployment, incentivesVault, polBuyback) were sourced and cross-checked the same way; licenseAuctionLegacy keeps its original launch-era source, unchanged by the migration. sbills was sourced from the team's stake page bundle and verified on-chain the same way, but it isn't a registry role at all: there's no registry entry to cross-check it against, only the bytecode-embedded addresses described below.

Verification status: read this honestly

2 of the 16 contracts have verified source: standard (the $STANDARD token) and taxHook. Both verified on Sourcify (exact_match, 2026-09-16), compiled with solc 0.8.26. The other 14, including registry and sbills, remain unverified on Sourcify and Blockscout. That means:

• The addresses and deploy blocks are trustworthy for all 16, cross-checked against live bytecode presence at each block, not just copied from an announcement.
• For standard and taxHook, the mechanics described elsewhere in this section (the tax decay formula, exact-output tax grossing, the epoch net-flow window, the supply/burn/retirement model) are read directly from verified Solidity, the strongest claim this documentation makes.
• registry (the AddressRegistry) is a special case: it hasn't verified on Sourcify itself, but its full source ships inside both verified bundles above (all three contracts were compiled together), so its ABI and behavior are known from source even though the registry's own bytecode carries no Sourcify record of its own. Treat it as source-known, not source-verified: a caller checking Sourcify directly for the registry's address will still see no match.
• For the other 12 registry-listed contracts (centralBank, charterNFT, polManager, feeSplitter, contractionVault, expansionVault, licenseAuction, licenseAuctionLegacy, charterAuction, genesisMinter, incentivesVault, polBuyback), the mechanics (the multiplier step rule, the day-roll pricing rule, and similar) are still not read from a verified Solidity file. They're established either by measured on-chain calls and event logs at real blocks, or by inferred_from_bytecode, running the actual deployed bytecode against controlled inputs on a forked copy of the chain, which is strong evidence (it's the real code executing) but only pins the cases actually exercised, not a full audited account of every code path. incentivesVault and polBuyback are newer still: their behavior is currently established only by the team's own announcement, not yet by a fork replay against either contract's deployed bytecode.
• sbills has no verified source and, unlike every other row here, no Sourcify-adjacent ABI to fall back on: its full interface was recovered from bytecode (no verified source exists anywhere for it), cross-checked against the 4-byte selectors and event topics the bytecode actually contains, and against a handful of parameter names recovered from the team's own published site bundle. Treat its function and event names as recovered, not source-confirmed, even where this documentation states them plainly.
• Several event names attached to the POL Manager contract are inferred rather than hash-confirmed: a candidate name matches the contract's behavior and call pattern, but no keccak-256 hash of a candidate signature matched the observed topic. Treat those field names as working labels, not confirmed identifiers.
• Every API field built from an unverified contract's mechanics is labeled basis: inferred_from_bytecode (or the matching _basis sibling) so it's never confused with a source-verified read. See How to read a TSR response.

GET /v1/addresses reports a registry_status of placeholder, partial, or verified precisely so a caller doesn't have to track this by reading documentation. Anything not listed, or listed below verified, should be treated as unconfirmed regardless of what any other source (including this page) claims.

Explorer

Robinhood Chain's block explorer is at robinhoodchain.blockscout.com; it is unreachable from outside networks. Sourcify (sourcify.dev) is the verification source this page relies on instead. Re-check both directly rather than assuming this page's verification status stays current, since a verification landing after this page was written wouldn't be reflected here.

Where to look

Question	Route	MCP tool
Is this address actually a Standard Reserve contract?	GET /v1/addresses	1s_std_addresses
What genesis-mint metrics does the reserve report?	GET /v1/genesis/live, /v1/genesis/mints	1s_std_genesis_live