Contracts and addresses

The Standard Reserve deployed 12 contracts on Robinhood Chain (chain id 4663), plus it shares the chain's existing Uniswap v4 PoolManager singleton rather than deploying its own. 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 12 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
licenseAuction	Runs the daily branch-license Dutch auction
charterAuction	Runs the charter Dutch auction
genesisMinter	Handled the founding-charter genesis mint
poolManager (shared)	Uniswap v4's own singleton contract; the ETH/STANDARD pool is one PoolId inside it, not a separate deployed contract

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.

Verification status: read this honestly

2 of the 12 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 10, including registry, remain unverified on Sourcify and Blockscout. That means:

• The addresses and deploy blocks are trustworthy for all 12, 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 9 contracts (centralBank, charterNFT, polManager, feeSplitter, contractionVault, expansionVault, licenseAuction, charterAuction, genesisMinter), 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.
• 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