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.

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	GET /v1/decisions/branch	1s_std_decision_branch

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.