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.

GET /v1/decisions/exit also carries parts.sbills_alternative: what the exit's net STANDARD (exit_quote.net_raw, after the exit fee) would earn staked for one S-Bills term at today's quote. It reports the rate paid, the premium, the term, and the exit fee that bill would pay if it left early; summary.sbills_alternative_* repeats the headline numbers. It is basis: derived and assumes the STANDARD is staked immediately at today's quote as the only deposit. The part is skipped, with a reason, when the exit has no positive net amount. The two options sit side by side as inputs, and the route doesn't say which is better.

The fee-forecast route also names when the fee changes, not just where it's headed: expiry_schedule lists each window day still counted in the fee, when it drops out, and the resulting rate, and next_fee_change_at picks out the first one that actually moves the number. It's null (with incomplete_days naming the gap) if a day in the window can't currently be computed.

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. For kind=license, each day also carries purchase aggregates: transaction count, distinct charters, count-weighted average price, total paid, and a purchase-size distribution (null for kind=charter)
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

Buy today's license or wait for tomorrow's? GET /v1/decisions/branch (1s_std_decision_branch) carries summary.next_day_starts_at and summary.seconds_to_next_day, lifted from the same day_clock object described in Charters, branches, and licenses. Both are null if the license auction hasn't started yet or the boundary can't be computed. There's no built-in "wait and save" recommendation: the next day's opening price resets off that day's own floor and last sale rather than continuing the current decay, so knowing the countdown tells you when the price resets, not which side of it is cheaper. Pair it with GET /v1/auctions/days?kind=license to see whether recent day-opens have landed above or below where today's price already sits.

"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."

Planning a multi-day expansion, rather than a single license buy? GET /v1/decisions/plan (1s_std_decision_plan, $0.05 like the other composite routes) seeds a keep/selective/aggressive strategy simulation from this API's own live routes (license price, pool price, issuance rate, branch count) and runs it forward over a horizon you choose. It's explicitly a simulation for comparing strategies, not a forecast: the response never names a winning strategy, and every seeded assumption is reported with a source (seeded_live, user_supplied, or default) so you can tell what it held constant. Each strategy also carries stake_instead_of_sale: the STANDARD it would release at the end of the horizon, priced as one S-Bill deposited then instead of sold. quote_now is the contract's own quote for that amount today (measured). at_horizon_end projects the rate paid and premium at the moment of the stake from the contract's drift rule and price-impact curve (derived, computed locally, and within about 1e-12 relative of simulated on-chain quotes when no parameters or deposits change). It assumes the stake is the only deposit and the rate parameters don't change. The block is {available: false, reason} when a strategy releases nothing or a read failed. It sits beside the three strategies rather than ranking against them, so the plan still never names a winner.

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 the charter auction's price be later today? GET /v1/auctions/current carries charter.expected_prices (and GET /v1/decisions/charter repeats it as summary.charter_expected_prices): the charter price at +15m, +30m, +1h, +4h, and end_of_day, the last second before the next day opens. It is basis: derived, decaying from the measured currentPrice() with the charter's own dayHalfLife and dayFloorPrice, and it matches simulated on-chain prices within about 11 wei. It assumes no charter is bought first and that the half-life, floor, and bank regime stay as they are. A row that would land in the next auction day is null with a reason, since the next day's opening price isn't projected. In contraction regime every row is null: the curve was verified only outside contraction, where currentPrice() doubles.

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 (including the address registry's execution_permissionless), 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. Collected trading taxes sitting in the hook or the FeeSplitter, awaiting the permissionless forwardTaxes() push (hook_eth_balance_raw/fee_splitter_eth_balance_raw on /v1/buybacks/readiness), aren't counted in either backing figure either: they're revenue in transit, not reserve holdings. See Reserves, vaults, POL, and buybacks.

What goes into staking or holding?

GET /v1/decisions/stake?amount=&wallet= (1s_std_decision_stake, $0.05) bundles the live S-Bills quote for amount STANDARD (whole tokens, not wei) with the current S-Bills state. Pass wallet and it adds that wallet's open principal and its headroom under the per-wallet cap; the same optional wallet is also accepted by GET /v1/sbills/quote, which then reports exceeds_wallet_cap, wallet_open_principal_raw, and wallet_cap_headroom_raw in checks.

The response also carries a top-level waiting block: a basis: derived projection of the per-term rate 1h, 6h, and 24h from now, plus the time the rate reaches its ceiling. It holds only under the assumption stated in waiting.assumption, that nobody else deposits and the admin doesn't change rate parameters. The inputs it starts from (current rate, drift per second, ceiling, last update) are measured from the contract and listed under waiting.inputs. Each point's rate is the drifted rate. quote_rate_paid is this amount's quote at that rate, computed with the contract's price-impact curve (the rate decays toward the floor as the amount grows). Against simulated on-chain quotes it lands within about 5e-11 relative at 1 STANDARD, 7e-13 at 50, and 6e-16 from 123,456 up. It reports what the rate does under that assumption and nothing about timing a deposit.

GET /v1/decisions/hold (1s_std_decision_hold, $0.05, no parameters) bundles the policy outlook, issuance runway, the latest pending governance changes, the tax schedule, buyback readiness, and the dormancy count. The dormancy part carries the number of reportable wallets (capped at 500, with count_is_lower_bound), not the wallet list. Both are null, with constants_missing: true, until the dormancy window has been read from chain. To get the wallets, page GET /v1/dormancy?reportable=true.

Both routes report each underlying read under parts.<name>.status and return inputs only.

Route	MCP tool	What it answers
GET /v1/decisions/stake	1s_std_decision_stake	The S-Bills quote, live S-Bills state, optional wallet cap headroom, and the derived rate projection, bundled
GET /v1/decisions/sbill	1s_std_decision_sbill	One bill's record and live state, with the exit-fee schedule (active) or the redeem and roll figures (matured)
GET /v1/decisions/hold	1s_std_decision_hold	Policy outlook, issuance runway, pending governance, tax schedule, buyback readiness, and dormancy count, bundled

What should I do with one S-Bill I already hold? GET /v1/decisions/sbill?bill_id= (1s_std_decision_sbill, $0.05) returns the bill's record and the live S-Bills state, plus a block that depends on the bill's state. Each block is always an object, with applicable: false and a reason when it doesn't apply.

• Active bill: exit_schedule.exit_now is measured from the contract's own quoteExit: the fee, the payout, and the premium vested so far. An early exit pays principal minus the fee whenever it happens; the premium and any bonus never go to a leaver (premium_given_up). fee_by_day is derived: the fee the bill would pay if it exited on each coming day until older exits leave the 7-day window or the bill matures. It assumes no other exits, deposits, maturities, or settlements. lowest_projected_fee names the earliest cheapest day and the saving against today, and projection_check compares today's projected fee with quoteExit on every response.
• Matured bill: maturity.redeem_quote is measured from quoteRedeem. maturity.roll is derived: the new principal (the redeem payout), plus the rate and premium from a fresh quote at roll time. Only the bill's owner can roll. There is no auto-roll, so a matured bill earns nothing until its owner redeems or rolls it.
• Exited or redeemed bill: the record only.

An unknown bill_id returns 404 and a malformed one returns 400.

What goes into a standing license bid?

A standing bid is an order on a charter to buy licenses at or below a maximum unit price. One bid per charter; only the charter NFT's owner can place or cancel it, for 1 to 3 licenses. Nothing is escrowed when it is placed. A fill is paid from the charter's pending STANDARD on the Central Bank, at the license price current at fill time (not the bid's max), and it is all-or-nothing: a bid for 3 either buys 3 or buys none. A fill shares the daily license supply with direct buys. Two caps apply per charter: 3 licenses per 86400-second window and 10 branches in total. fill() is a separate transaction that any address may send, so the price reaching a bid's max does not by itself fill the bid.

GET /v1/auctions/license/bids (1s_std_license_bids, $0.02) returns the open-bid book, read from the contract at one pinned block. Each bid carries the contract's own fillable answer, the checks behind it, and a blocking list naming every failing check: price above max, daily supply used up, charter window cap, charter branch cap, insufficient pending, owner changed, charter burned. A stale bid (its bidder no longer owns the charter) is flagged stale and prunable. effective_crossing_price_raw is basis: derived: the lower of the bid's max and its charter's pending STANDARD divided by its count. Pending keeps accruing, so a bid held back by pending can become fillable sooner than that figure implies. Bidder addresses are included, since they are public chain state. Filters are charter_id, bidder, and fillable_only; sort is max_desc (default) or charter_id.

GET /v1/decisions/bid?max_unit_price=&count=&charter_id= (1s_std_decision_bid, $0.05) bundles the book header, the auction state, and the derived blocks below. max_unit_price is in whole STANDARD tokens; count and charter_id are optional.

• crossing (derived): when the license price reaches the max, today or on the next auction day, down to the second. It assumes the curve doesn't change first. crossing.next_day is the same question for the next day's curve, since a bid at or below the price still waits for the daily reset when today's supply is gone.
• queue (derived): the other open bids that would fill before the price reaches the max, and the supply left after them. Supply left is clamped at 0, and licenses_ahead_beyond_supply reports the overflow. at_effective_crossing gives the queue at the price a short-pending charter can actually pay.
• this_charter (measured, with charter_id): pending STANDARD, the window and branch caps, and any existing bid the new one would replace. That bid is left out of the queue. The window cap is checked twice: now, and when the price reaches the max. window_cap_covers_count_at_crossing and window_cap_covers_count_at_next_day_crossing are basis: derived and count the charter's full allowance from cap_window_resets_at onward. Window resets fall on auction-day rolls, so a charter that has used its allowance today can usually still fill on the next day's curve. effective_crossing_day (today or next_day) gives the day whose curve reaches the charter's effective price, and queue.at_effective_crossing is counted on that day.
• fill_execution: states that a crossing is not a fill, plus measured fills_to_date, distinct_fillers, and last_fill_at from the events index. If nobody is sending fills, last_fill_at goes stale.

Each part reports its own status, and the route states no verdict.

Route	MCP tool	What it answers
GET /v1/auctions/license/bids	1s_std_license_bids	Every standing bid, with fillable and blocking reasons, stale flags, and effective crossing price
GET /v1/decisions/bid	1s_std_decision_bid	When the price reaches a max, who is ahead in the book, what a charter can pay, and how fills happen, bundled

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/flow/charters	1s_std_flow_charters	Pool buys and sells by wallets that held at least one Charter when each swap occurred; each swap is counted once and ambiguous multi-swap transactions are excluded
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.

GET /v1/decisions/plan (1s_std_decision_plan) is a fourth composite with a different shape: instead of bundling several current-state routes into one snapshot, it seeds a forward simulation from them. See "What does a branch cost right now?" above for what it answers.

GET /v1/decisions/stake and GET /v1/decisions/hold (1s_std_decision_stake, 1s_std_decision_hold) are the fifth and sixth. Stake bundles current-state reads and adds one derived projection; hold is a plain bundle. See "What goes into staking or holding?" above. GET /v1/decisions/sbill (1s_std_decision_sbill) is the seventh: it takes one bill and returns exit or roll figures depending on the bill's state. See "What should I do with one S-Bill I already hold?" above. GET /v1/decisions/bid (1s_std_decision_bid) is the eighth: it models a standing license bid at a max price. See "What goes into a standing license bid?" above.