Charters, branches, and licenses

Charter: the membership token

A charter is a soulbound (non-transferable, it can't be sold or moved once minted) ERC-721 token. It's the position that lets its holder open branches. The charter supply comes from two sources: the genesis mint, and the charter auction (below), which sells new charters directly on an ongoing basis. A charter earns nothing on its own; it's only productive once it has one or more open branches.

Branch: the thing that earns

A branch is a license opened under a charter that accrues STANDARD issuance continuously for as long as it stays open. A single charter can open more than one branch. Days of issuance restates a license's price in terms of how many days of that branch's own issuance it would take to earn the price back, deliberately not framed as a yield, APY, or payback period, since this API never states a return figure.

License: what you burn to open a branch

A license is purchased through the license auction and paid for in STANDARD, which is burned on purchase (100% of it: licenses are one of the token's three burn paths, alongside buybacks and the resolution fee).

Protocol v1.1 (live 2026-09-21) replaced the license auction contract outright and changed its cadence: per the team's own announcement, each "day" window is now 12 hours rather than 24, so two auction windows run per calendar day, each offering its own batch of licenses; a charter can still buy at most 3 branches in any rolling 24-hour period regardless of how many windows that spans. GET /v1/addresses reflects the new contract address; the retired one is kept in the registry so its historical auction days stay attributable. The cadence, per-charter cap, and half-life below come from the team's announcement, not yet an independently confirmed read of the new contract's own bytecode (it isn't Sourcify-verified either). The day-window mechanics themselves (day roll, opening-price rule, floor-price recompute) are assumed unchanged from the retired contract, since the announcement describes it as a parameter migration rather than a behavioral rewrite, but that assumption hasn't been fork-replayed against the new deployment yet.

• Supply per window: the number of licenses on offer per auction window is a chain-read constant (licenses_per_day or equivalent), not fixed at 1 or unlimited; GET /v1/branches/summary and GET /v1/auctions/current report it live.
• Intra-window decay: within a window, the price decays on an exponential half-life, the same excess-over-floor shape confirmed for the trading tax hook (see Trading tax hook): price(t) = floor + (start − floor) · 0.5^(t / half_life), truncated, not rounded, and not a whole-price decay. This shape was measured directly against three real day-0 purchases and matched a fork replay to the wei on the retired contract (basis: inferred_from_bytecode); under v1.1 the half-life itself is a faster 2 hours per the team's announcement, read live off the new contract rather than hardcoded, but not yet independently re-confirmed by a fork replay the way the original value was.
• Day roll: when a new day's first sale-triggering call lands, the contract "rolls." The old day's unsold offer disappears (it doesn't carry over), and a new day's ladder starts. The new day's opening price is max(start_multiplier × yesterday's last sale price, today's floor price) if a sale happened the prior day, or start_multiplier × today's floor price if it didn't. The floor price itself is recomputed from the live base_rate, multiplier, and total-branches count at the moment of the roll, which is why the floor can move day to day even without a governance change. Both rules are basis: inferred_from_bytecode, pinned by nine wei-exact fork replays, and pending confirmation against real mainnet day-roll behavior beyond what's already been observed live.
• When the next day opens: GET /v1/auctions/current (1s_std_auctions_current), GET /v1/branches/auction/live, and GET /v1/branches/doi (1s_std_branches_doi) each carry a day_clock object: current_day, day_started_at, next_day_starts_at, seconds_to_next_day, and auction_day_seconds, all basis: "derived". These come from auctionAnchor() + n × auction_day_seconds, not from the day-roll event, since that event only fires on the first sale of a new day and so can't tell you a boundary before it happens. auction_day_seconds is read live from the contract, not assumed to be 24 hours: under v1.1 it's 12 hours, so current_day now increments twice per calendar day. A charter auction's anchor is only set once that auction's start() call runs, not at deploy, so a charter auction that hasn't started yet reports every day_clock field as null with a sibling day_clock_reason explaining why.

Charter auction: the other way in

Buying a license under an existing charter is one path to a branch. The charter auction is the other: it sells new charters directly, on its own Dutch-auction schedule, and its own price (converted to ETH) doesn't always match what a license would cost converted to ETH on the same day. GET /v1/branches/license-cost computes both prices in ETH terms (including buy tax and pool price impact) and names the cheaper of the two (cheapest_path) so you don't have to eyeball it. GET /v1/auctions/days?kind=license and ?kind=charter give recent per-day history (open/floor/close price and sell-out timing) for judging whether today's number looks typical for either auction; license days also carry purchase aggregates (transaction count, distinct charters, average price, total paid, and a purchase-size distribution), which are null for charter days.

Charter stimulus: a one-time claim

The 2026-10-11 monetary policy update put 1,089,501.51 STANDARD into two claim contracts, BranchClaim and BranchTopUp. The incentives vault funded them. Each charter has a share, and the owner can claim it until 2026-11-10 07:03:45 UTC. After that deadline anyone can sweep what's left back to the incentives vault.

• Only the charter's owner can claim its share.
• A full exit forfeits an unclaimed stimulus. Exiting every branch burns the charter, and a claim needs a charter that still exists. A simulated full exit followed by a claim reverted on both contracts. A partial exit leaves the charter in place and the claim pays in full. To keep the stimulus, claim it before the last branch is closed.
• Unclaimed stimulus counts as circulating. The STANDARD waiting in the two contracts is part of circulating_raw on GET /v1/supply/current until it is claimed or swept.

Where the numbers appear:

• GET /v1/charters/{id} carries a stimulus object with status (claimable, claimed, closed_unclaimed, forfeited, no_allocation, not_eligible, unknown or unavailable), claimed_raw, claimable_raw, deadline, and at_risk_on_full_exit_raw, the amount a full exit would forfeit. On a burned charter, claimable_raw is 0 and forfeited_raw is the unclaimed amount it lost. A figure that couldn't be read is null, with the reason in error. Claimed amounts come from indexed claim history. Claimable amounts are read from the contracts at one block.
• GET /v1/wallets/{address} repeats that object on each charter and adds a roll-up: claimable_raw, the charters it covers, and claimed_by_wallet_raw, the amount the wallet has already claimed. Live reads cover at most 50 charters per request. Past that, truncated is true and the roll-up's claimable_raw is null.
• GET /v1/supply/current carries funded, claimed, swept and unclaimed totals, the deadline, and a per-contract breakdown. It is live state, so it is null on at_block reads.
• GET /v1/decisions/exit carries it as parts.stimulus, with the status, claimable amount, deadline and at-risk amount repeated in summary.stimulus_*.

Burned Charter Claim: a refund keyed by wallet

Separately from the stimulus, a RefundClaim contract refunds the revocation fee, in STANDARD, to wallets that held a charter when it was revoked for dormancy. The Standard Reserve site calls it the Burned Charter Claim. It has been live since 2026-10-15, and the claim closes at 2026-11-14 11:36:37 UTC. After that, claim() reverts and anyone can sweep() what's left to the contract's refund address.

• The refund is keyed by wallet, not by charter. A wallet has one amount, and it covers every charter that wallet lost, listed in burned_charter_ids.
• Only the loaded wallet can claim, by calling claim() from that wallet. The contract doesn't check who owns a charter today, because a revoked charter no longer exists.
• A charter that burned by exiting every branch is not eligible. This refund is only for revocation.

GET /v1/charters/{id} carries a burned_charter_claim object, on revoked charters only. GET /v1/wallets/{address} carries one for a wallet with an allocation. Both leave it out when there is nothing to show. Its status is claimable, claimed, closed_unclaimed, not_open or unknown. The allocation, claimable_raw and the deadline are read from the contract at one block. Who claimed, and in which transaction, comes from indexed claim history. A figure that couldn't be read is null, with the reason in error, never zero. The contract is listed in Contracts and addresses.

Launchpad charter drops

When a token launched on the Standard Reserve launchpad graduates, part of its supply is set aside for charters. That share is a charter drop. The drop works like this:

• The branch count is frozen when the drop records it. Each charter's branches at that moment set how many count toward the drop. Branches opened afterward never count toward it. The drop records counts in batches of charter ids, and a batch can land after the drop is registered. The API reads each charter's count at the batch that covers it. A charter no recorded batch covers yet has status: snapshot_incomplete and no count, and claims on it revert until its batch lands.
• Each drop has a payout mode, and it decides when a share becomes claimable. Nothing is paid until the owner claims.
  • per_branch: the owner can claim a per-branch share for each branch closed below the frozen count, as each one closes. Branches that are still open are locked.
  • at_exit: nothing is claimable while the charter has any branch. Once it has none, the whole share (frozen minus claimed) is. Until then every counted branch stays locked.
  • unknown: a mode this API doesn't recognize. It is never shown as claimable.
• Each drop is its own claim. One claim per drop, and claimMany batches several into one transaction.
• Re-opening branches before you claim cancels the closures that haven't been claimed. A branch you close and then replace no longer counts as closed.
• Unclaimed drops expire after 365 days. The leftover goes to the launchpad's fee multisig, not back to the Standard Reserve. expires_at, expired and recovered on each drop show where it stands.

Closing the last branch burns the charter, and a burned charter can only claim if noteOwner(id) was called while it still existed. Anyone can call it, and it reverts once the charter is burned. If nobody called it, the claim reverts with OwnerUnknown and the drop share is lost for good. Call noteOwner before closing the last branch. An at_exit share is paid only after the charter has no branches left, so every at_exit payout depends on that note. The note is kept per CharterDrop contract, and there are now two (see below), so a charter needs a note on each one that holds a share for it. The API flags this in owner_note, whose contracts_to_note lists each CharterDrop contract still missing a note for the current owner, and warns about it on the exit decision.

Two launchpads

Launchpad v2 runs beside the original, with its own factory and its own CharterDrop contract. Both are listed in Contracts and addresses. Each drop in charter_drops.drops says which launchpad it came from in launchpad_version (1 or 2, null while the launch isn't indexed yet) and names its CharterDrop in drop_contract. v1 drops are always per_branch. v2 launches can pick either mode, can pair with WETH as well as a stock token, and can set a venue policy (URC-5) so the token trades only in its own pool, plus a hook module. See Launchpad venue policy (URC-5) for what the policy means and the routes that report it.

Where the numbers appear:

• GET /v1/charters/{id} carries a charter_drops block. For each drop it lists the frozen, claimable, locked and claimed branches and the amounts they're worth, in launch tokens, in the pair stock and, when the Reserve has a price for that stock, in ETH. Totals for the whole charter and the owner_note check sit beside the list. If the drop data is unavailable, only this block degrades and error says why.
• GET /v1/wallets/{address} carries the same roll-up across the wallet's charters, with charters_needing_note counting the ones that should call noteOwner before closing their last branch.
• GET /v1/decisions/exit carries parts.charter_drops: what closing the branches you ask about would release, what is already claimable without closing anything, and how many claim transactions that takes. An at_exit drop releases its share only if the close takes the charter to zero branches. For a partial close, at_exit_drops_held counts the drops that stay unpaid, and the warning at_exit_drops_pay_only_when_the_last_branch_closes says so. If those branches are all the charter has left, it warns about noteOwner.
• GET /v1/decisions/branch and GET /v1/decisions/charter carry parts.charter_drops_history: what one branch would have earned from each past drop at today's prices, and the most recent drops. Each recent drop carries its mode, and at_exit_drops counts the ones that pay a branch's share only when the charter's last branch closes. This is history, not a forecast. A branch opened now is in none of those drops, and how many drops launch, what their tokens are worth and how many branches share each one can all change.
• GET /v1/decisions/plan with charter_id adds a charter_drops block beside the strategies, not inside them, because drops pay in launch tokens that are claimed separately. No strategy's ETH result includes it.

Drop values are basis: derived. Stock values use the spot price of a shallow pool, so read them as context, not as a quote you could sell at. ETH values are null, with a reason, until the Reserve has a price for the drop's stock. The exception is a drop paired with WETH, which is valued at exactly 1 ETH per WETH and reports stock_eth_basis: constant.

Where to look

Question	Route	MCP tool
What does a license cost today, in ETH?	GET /v1/branches/license-cost	1s_std_license_cost
How many more licenses can this specific charter still buy today?	GET /v1/charters/{id}/license-headroom	1s_std_license_headroom
What's a branch worth in days-of-issuance terms?	GET /v1/branches/doi	1s_std_branches_doi
Recent auction days, prices, and sell-out speed	GET /v1/auctions/days	1s_std_auction_days
Standing license bids: who bid, at what max, and whether each can fill	GET /v1/auctions/license/bids	1s_std_license_bids
Inputs for a standing bid at a max price, in one call	GET /v1/decisions/bid	1s_std_decision_bid
One call bundling the branch-buy decision, plus past charter-drop history	GET /v1/decisions/branch	1s_std_decision_branch
What stimulus can this charter still claim, and what would a full exit forfeit?	GET /v1/charters/{id}	1s_std_charter
Which launchpad drops can this charter or wallet claim?	GET /v1/charters/{id}, GET /v1/wallets/{address}	1s_std_charter, 1s_std_wallet

See Deciding with the data for the full branch-cost decision walkthrough, and What goes into a standing license bid? for how standing bids work.