Deciding with the data

The rest of this section is organized by route. This page is organized by question: pick the decision you're facing, and it names the routes and MCP tools that answer it. See How to read a TSR response first for what basis, serving_state, and assumptions[] mean below.

Should I exit now?

Exiting retires a charter's open branches for a pro-rata share of the reserve, minus a resolution fee that scales with system-wide exit pressure (how much has already left recently relative to what's held). The fee moves with everyone else's behavior, not just yours, so "now vs. later" is a real question.

Route	MCP tool	What it answers
GET /v1/charters/{id}/exit-quote	1s_std_exit_quote	Your actual quote: gross, fee, net, and realizable_eth (net STANDARD sold into the pool, estimated)
GET /v1/exit/fee-curve	1s_std_exit_fee_curve	How the fee rate would move at larger or smaller withdrawal sizes than yours
GET /v1/exit/fee-forecast	1s_std_exit_fee_forecast	A current-pace projection of the fee rate assuming no one else exits between now and then
GET /v1/tax/schedule	1s_std_tax_schedule	The sell-tax bps applied to realizable_eth, falling during the launch decay window, so timing can matter here independently of the exit fee. The decay is basis: inferred_from_bytecode: the excess over the floor rate halves every 4 minutes and truncates, it isn't a whole-rate decay, and this is pending confirmation at the first real epoch settlement (~2026-09-18 01:00Z)
GET /v1/decisions/exit	1s_std_decision_exit	All of the above in one call, plus pool state and pending governance changes to fees or resolution, bundled for this one decision

realizable_eth and the fee-curve ladder are estimates with assumptions[]: a single-range constant-liquidity approximation of the pool swap. Re-quote right before you transact rather than caching either.

What does a branch cost right now?

There are two ways to add a branch: buy today's Dutch-auction license, or buy into the charter auction directly. They aren't always the same price once you convert both to ETH.

Route	MCP tool	What it answers
GET /v1/branches/license-cost	1s_std_license_cost	Today's license price converted to an estimated ETH cost (buy tax + pool price impact included), compared against the charter auction's own ETH price, with cheapest_path naming the cheaper route
GET /v1/charters/{id}/license-headroom	1s_std_license_headroom	How many more licenses this charter can still buy today, with a live quote for each remaining slot
GET /v1/auctions/days?kind=license or kind=charter	1s_std_auction_days	Recent days' open/floor/close prices and how fast each sold out, for judging whether today's price is typical
GET /v1/decisions/branch	1s_std_decision_branch	The above plus days-of-issuance and any pending governance change to the licenses-per-day rate, bundled

"Days of issuance" (GET /v1/branches/doi, 1s_std_branches_doi) is how this API expresses what a license's STANDARD price buys you in issuance terms; it's not a payback calculation, and there's no ROI or APY framing anywhere in this API. Say "days of issuance" or "issuance in ETH terms," not "yield."

The next day's opening license price (GET /v1/auctions/current, /v1/auctions/days) is also basis: inferred_from_bytecode: it's max(start_multiplier × yesterday's last sale, today's floor price) when a sale happened the prior day, or start_multiplier × today's floor price when it didn't, pending confirmation at the first real epoch settlement (~2026-09-18 01:00Z).

What will policy do next?

The Central Bank's issuance rate moves with a multiplier that steps up or down based on the sign of net ETH flow across consecutive epochs (a fixed multi-day settlement window). Both the step rule and what counts as "the prior epoch's flow" for this purpose were established by running the real contract bytecode against controlled inputs, since no verified source exists for it (basis: inferred_from_bytecode; see How to read a TSR response). Two details worth knowing before you read a projection: a zero net-flow signal holds the multiplier rather than cutting or raising it, and no cut can fire at the very first epoch settlement no matter what the signal says. Both are pending confirmation against the contracts' live behavior at the first real settlement (~2026-09-18 01:00Z).

Route	MCP tool	What it answers
GET /v1/policy/outlook	1s_std_policy_outlook	A current-sign-holds projection: what the multiplier and issuance rate would be if the current epoch's net-flow sign doesn't change before close
GET /v1/issuance/runway	1s_std_issuance_runway	Cumulative issuance against the total budget, current stream rate, and a same-rate projection of when the budget runs out
GET /v1/governance/changes	1s_std_governance_changes	Param-change history, anything queued but not yet applied, one-way switch states, and guardian pause state
GET /v1/policy/current	1s_std_policy_current	The latest settled (or, before first settlement, live-estimated) epoch: signal, regime, multiplier, issuance

multiplier_if_sign_holds_raw and issuance_if_sign_holds_raw are projections, not predictions: nothing stops the sign from flipping before the epoch closes, and the response says so in assumptions[].

Is the token backed, and is the buyback mechanism working?

STANDARD is backed by ETH held in two vaults (expansion and contraction) plus any configured reserve assets, with an automated buyback that burns tokens when conditions allow it.

Route	MCP tool	What it answers
GET /v1/backing/current	1s_std_backing	Vault ETH, reserve holdings, and ETH backing per circulating STANDARD, both including and excluding protocol-owned liquidity
GET /v1/backing/history	(same tool, ranged)	The same ratio over time, so a single snapshot isn't read as the whole trend
GET /v1/buybacks/readiness	1s_std_buyback_readiness	Whether a buyback tick could fire right now: capacity, cooldown, TWAP deviation, and recent executed ticks
GET /v1/decisions/charter	1s_std_decision_charter	Backing and holder concentration bundled with the charter-buy decision, since both speak to how established the reserve is

Protocol-owned liquidity (POL, the paired liquidity the STANDARD/ETH pool itself needs to function) is reported separately from free reserve backing. It isn't a claim you can redeem against circulating supply, so backing/current reports both an excluding-POL and an including-POL figure rather than picking one.

Who else is here?

Ownership concentration and dormancy both matter for judging how decentralized (and how "use it or lose it") the reserve actually is.

Route	MCP tool	What it answers
GET /v1/holders/concentration	1s_std_holders_concentration	Branch-per-charter distribution, top owners, an HHI concentration score, and a genesis-vs-auction cohort split
GET /v1/wallets/{address}	1s_std_wallet	One wallet's full position: charters, pending owed, dormancy deadline, and license headroom per charter
GET /v1/dormancy/bounties	1s_std_dormancy_bounties	Wallets already past their reportable-dormancy window, ranked by estimated bounty

reportable_at_block on the dormancy routes is itself an estimate (built from a measured or, failing that, a hardcoded block-time assumption), not a live chain read. See the route's own description in the OpenAPI spec before building an automated reportDormant() caller against it.

Composite routes: one call per decision

GET /v1/decisions/branch, /v1/decisions/exit, and /v1/decisions/charter (MCP: 1s_std_decision_branch, 1s_std_decision_exit, 1s_std_decision_charter) each bundle the routes above into the single call the matching decision actually needs, with a summary carrying the handful of numbers you'd look at first and parts.<name>.status reporting each underlying route's own success or failure independently. Reach for a composite first; drop down to the individual routes above only when you need a field the composite's summary doesn't surface, or a parameter (like a custom branches count) the composite doesn't forward.