Capital moves.Policy responds.

Reserve Protocol is conceived as a set of contracts and accounting rules around a protocol token and a designated token/ETH liquidity venue. Trading supplies an observable capital-flow signal. A policy controller may use that signal to adjust future issuance and direct protocol revenue. Charter holders may operate branches, and active branches may earn a share of issuance as an internal accrual rather than an immediate wallet transfer.

The proposed loop begins with external actors trading through the designated pool. Pool accounting reports ETH entering and leaving over fixed epochs. At an update boundary, the controller classifies the recent signal, updates bounded policy state, and computes an issuance amount for the next accounting period. That amount is divided among active branches. Fees generated by defined protocol actions may be routed to reserve operations, liquidity support, or other approved destinations.

1. MeasureRecord eligible ETH-side inflow and outflow for a defined pool and epoch without treating price appreciation as new capital.
2. UpdateConvert the signed flow signal into a bounded policy state using an approved cadence and response curve.
3. AccountCredit branch-weighted issuance to an internal ledger, preserving a distinction between accrued and circulating tokens.
4. RouteAllocate collected assets under explicit reserve, liquidity, and operating rules instead of implying automatic backing.
5. Retire and settleWhen a participant realizes accrued value, retire the corresponding branch weight and apply payout, charge, burn, and charter-lifecycle rules at the same settlement boundary.

The model is easier to follow when custody, observation, policy and ownership remain separate. Traders exchange assets through a designated venue. That venue produces finalized measurements and fees. The controller reads measurements and issues bounded instructions. Charter holders act through branches, while reserve operators can use protocol assets only within an approved mandate. No single arrow below implies a general claim on every asset in the system.

A trader interacts with the liquidity venue, not directly with the issuance ledger. A charter owner controls charter and branch lifecycle actions, but cannot rewrite policy. The controller calculates issuance or routing without acquiring unrestricted custody over user wallets. Even if one future contract performs several functions, its events and permissions still need to preserve these boundaries.

Inputs and outputs must be typed by asset and unit. ETH entering a pool, protocol tokens burned for a license, internal token-denominated accrual, and wallet tokens minted at settlement are different events. A production specification would define which contract emits authoritative events, how an indexer recovers after failure, and which state is canonical if a user interface and a chain read disagree.

• Administrative capabilities, upgrade paths, pause rights, and signer thresholds require publication before deployment.
• Custody arrangements and eligible reserve assets require a mandate independent of marketing language.
• A front-end read failure must return unavailable; it must not synthesize a zero balance or an eligibility result.

In practiceThe map is a chain of responsibility: market activity becomes a measurement; a measurement can inform policy; policy can change future accounting. It does not make every participant a creditor of the reserve.

A future Reserve token specification may define a hard cap, a genesis mint, a policy-controlled issuance budget, and enumerated burn paths. None of those quantities is approved for Reserve. The important design constraint is conservation across accounting domains: an internal accrual is a claim recorded by the protocol, not a wallet token, and therefore must not be counted as circulating supply before settlement.

Issuance accounting should create a ledger entry attributable to an epoch and branch set. A payout settlement should retire the corresponding branch position, consume its attributable ledger entry exactly once, apply any approved resolution charge, and mint only the net amount. License payments, policy buybacks, resolution charges, or other burns count only after irreversible settlement. Failed, reverted, pending, or indexed-but-unfinalized operations must not change reported final supply.

• Supply, accrued balances and burned amounts require independent event reconciliation.
• Rounding rules must state who receives or absorbs residual units.
• The authorization rule must state whether a burn permanently reduces maximum supply, restores mint headroom, or changes circulating supply without changing either limit.
• No displayed zero may stand in for an unavailable onchain total-supply read.
• The current UI’s zero tokens issued is a declared initial state, not a chain query.

In practiceAccrual changes an internal ledger. Settlement can change a wallet balance. A finalized burn changes circulating supply. Keeping those moments separate is the basis of auditable token accounting.

For each epoch, pool accounting would aggregate eligible ETH that enters because traders acquire the protocol token and eligible ETH that leaves because traders sell it. Gross values remain available for audit, while their difference becomes the signed net-flow observation. Transfers outside the designated venue, internal liquidity movements, and protocol operations must be classified explicitly so the same asset movement cannot appear as organic demand twice.

Anyone able to trade can affect the raw signal, so measurement is not equivalent to truth about long-term adoption. Self-trading, flash liquidity, multi-pool routing, MEV, bridge activity and reserve operations can distort attribution. A production design needs minimum-liquidity conditions, inclusion and exclusion rules, anomaly monitoring, finality windows, and a defined response when the hook or indexer is unavailable.

The reference uses different observation windows for different decisions: prior finalized epochs inform issuance, while the current epoch can determine fee routing. Reserve has approved neither convention. A production specification must name the window, finality boundary and fallback for each decision separately so a missing or stale signal cannot be reused under a different meaning.

At a policy boundary, the controller would read finalized flow observations and current policy state. A positive signal may move the multiplier toward expansion; a neutral or negative signal may move it toward contraction. The public reference describes reductions as faster than increases, but its coefficients and several controller values are not publicly readable. Reserve therefore adopts no numeric response curve in this paper.

1. SnapshotLock the eligible flow window, branch set and prior controller state at a deterministic boundary.
2. ValidateReject stale, incomplete or out-of-range observations according to a separately approved fault policy.
3. TransitionApply the signed-signal response, rate limit and absolute bounds to obtain the next multiplier.
4. AccrueCompute issuance for that period and assign ledger units to the eligible branch snapshot.
5. PublishEmit inputs, prior state, new state and rounding results so independent observers can reproduce the update.

Costs and consequences are asymmetric. Raising issuance dilutes existing circulating ownership once accrual is withdrawn. Cutting issuance lowers prospective branch income and may change demand for branch licenses. Tight bounds can make the controller slow; loose bounds can amplify noisy flow. Governance intervention may be necessary during faults, but discretionary overrides introduce capture and predictability risks that must be disclosed.

In practicePolicy changes the rate of future accrual. It cannot erase a finalized wallet balance, turn a missing measurement into zero flow, or make additional issuance costless to existing holders.

The envisaged charter is a unique ownership record. Its owner may create branches within approved limits, settle available accrual by retiring the corresponding branch position, and perform any required liveness action. At genesis it may be non-transferable so allocation cannot immediately become a secondary-market claim. Supply, eligibility, price, wallet limits and allocation procedure are not configured for Reserve.

Ownership changes must be atomic with the branch set and accrual position. Separating them would allow a seller to retain value that a buyer believed was attached, or allow two accounts to claim the same branch authority. Metadata should distinguish descriptive fields from rights enforced by contracts. The interface must not imply that being selected, entering an address, or seeing an empty grid cell grants a reservation.

• Creation consumes the approved payment, eligibility proof or auction settlement and creates one owner record.
• Branch changes update the charter’s active weight and may incur a license cost or burn.
• Settlement retires the corresponding branch weight, reduces its attributable internal accrual, and may mint a net wallet amount after an approved charge.
• Retiring the final branch should terminate future accrual and may burn or permanently retire the charter.

A charter would begin with a defined initial branch state. Additional branches could require a license acquired through a policy-controlled release. When exercised, the license is consumed and the charter’s active branch count rises by one, subject to per-charter and per-period limits. The reference design pays for licenses in the protocol token and burns the payment; Reserve has not selected a payment asset or burn rule.

1. ReleaseThe policy system makes a bounded number of licenses available under an announced schedule.
2. AcquireAn eligible charter owner accepts the current auction terms and supplies the required settlement asset.
3. SettleThe system finalizes payment, consumes the license and applies any approved burn or revenue routing.
4. ActivateThe branch becomes part of a future eligible snapshot only after the specified activation boundary.

Branch expansion has two economic consequences: it may create demand for the settlement asset, and it dilutes the relative share of every existing branch in later issuance. Without caps or a carefully calibrated release, concentrated capital could dominate branch weight. Without enough release, existing owners may form a closed rent-seeking group. License supply, charter limits, anti-sybil assumptions and activation timing therefore belong to the core policy specification.

Under the candidate format, an auction opens at a published price and declines toward a floor over a fixed period. A participant accepts the current price; if inventory and payment remain valid when the transaction executes, settlement is immediate and first-come. License auctions and charter auctions may use different payment assets and route proceeds differently, so they require separate configurations even if they share a price function.

Descending auctions reduce the need to submit and later reclaim bids, but they create latency, ordering and MEV risk. Users may pay different prices seconds apart; bots may win scarce inventory; failed transactions can still consume gas. A client should display a user-defined maximum payment and a freshness bound, while the contract—not the interface—enforces final price, remaining inventory and settlement.

In practiceA descending sale exchanges price certainty for allocation certainty: buying earlier reduces the chance of missing inventory, while waiting may lower the price but increases execution and availability risk.

At each finalized epoch, the policy system would credit a charter’s internal balance according to its eligible branch share. The balance remains protocol accounting until the owner settles it by retiring the corresponding branch position. This prevents every epoch from minting directly to many wallets and applies the payout and lifecycle changes at one boundary. It also creates a liability that must be reserved against any maximum supply authorization.

Retiring one branch should remove one unit of future branch weight and release only the amount attributable under the approved rule. If accrual is pooled at charter level, the specification must define whether retirement settles a pro-rata share, a last-in allocation, or another deterministic partition. Retiring the last branch is a terminal event: it should settle or otherwise dispose of remaining accrual, extinguish future participation, and retire the charter according to the chosen lifecycle. If a charge would normally be redistributed but no eligible position remains, an explicit burn, reserve, hold, or other approved fallback must replace division by an empty recipient set.

1. QuoteRead finalized accrual, branch state, available cap headroom and the current approved charge parameters.
2. AuthorizeVerify charter control, the branch position selected for retirement, replay protection and any applicable cooldown.
3. SettleAt one atomic state boundary, reduce attributable accrual, retire the selected branch, apply the charge exactly once, mint the net wallet amount and finalize any burn or redistribution.
4. ReconcileExclude retired weight from future snapshots and reconcile accrual, wallet mint, charge and any destination without rewriting finalized epochs.

A charge may discourage simultaneous exits or redistribute value, but it cannot guarantee solvency, price support or loss protection. Large variable charges may also trap holders economically or encourage pre-emptive exits. The design needs transparent quoting, a maximum user-approved charge, rounding rules, and tests for zero branches, partial withdrawals, concurrent retirement and exhausted supply authorization.

In practiceSettlement realizes part of the position by surrendering future branch weight. The wallet receives only the amount authorized after charges; the retired productive unit does not remain behind to earn again.

The reference design allows anyone to report a charter after a defined inactivity interval. A valid owner check-in resets the timer; a finalized report can revoke the inactive position, compensate the reporter, apply a charge, and distribute or settle the remainder. Reserve treats this as an optional mechanism because false or premature revocation would destroy valuable ownership rights.

Inputs include an authoritative clock or epoch index, the last accepted liveness marker, charter control evidence and branch/accrual state. Outputs can include a changed owner or terminal charter state, stopped future accrual, a reporter bounty, burned tokens, or redistributed ledger units. Every output changes incentives: a large bounty promotes monitoring but can attract harassment; a short timeout reduces dead weight but penalizes lost access or chain outages.

• The inactivity threshold, check-in action and acceptable liveness source are to be confirmed.
• The report bond, bounty, cap, charge and remainder destination are to be confirmed.
• Bounty, charged amount and owner remainder must reconcile to the finalized available balance. The reference does not make clear whether its bounty sits inside or before the displayed charge split, and Reserve must define both ordering and a fallback when no redistribution recipient remains.
• Challenge duration, dispute resolution and recovery from compromised keys require a threat model.
• A missing timestamp, indexer failure or network partition must produce an unavailable/fault state, never an automatic revocation.

Protocol revenue can arise from pool fees, charter auctions, license settlement, resolution charges, or other approved operations. Each source must identify its asset, gross amount, collection contract and finality. A routing policy then assigns finalized balances to named destinations. The current Reserve interface intentionally says “Routing to be announced”; it does not import the public reference percentages.

A contraction operation would exchange a bounded amount of reserve assets for protocol tokens and then burn verified proceeds. The policy must limit spend per execution and over time, define acceptable venues and slippage, prevent self-dealing, and disclose whether execution is automated or delegated. A reserve balance can fall, an asset can depeg, and a buyback can fail to support market price. Nothing in this design creates an unconditional redemption right.

Reporting should reconcile opening balances, inflows by source, authorized transfers, market execution, burns, fees, and closing balances by asset. If custody or price data cannot be verified, the interface should mark the operation unavailable or stale rather than report a synthetic zero. Governance must define who can alter destinations and limits and whether changes are delayed.

In practiceRouting decides where finalized assets may go. It does not guarantee that those assets are sufficient, liquid, correctly valued, or redeemable by a token holder.

The initial charter may be non-transferable. A later governance decision could enable transfers after the system has operating history and a complete transfer specification. If activated, a sale or gift should move control of the charter, its active branches, its unresolved lifecycle state, and the chosen treatment of accrued balances in one transaction. Moving only the NFT label while leaving economic state behind would be misleading.

1. Approve migrationPublish the transfer specification, risks, activation authority, delay and whether the change can ever be reversed.
2. Snapshot positionResolve pending branch, auction, withdrawal, revocation and accrual operations before ownership changes.
3. Authorize transferVerify current owner approval plus any compliance, recipient or marketplace restrictions actually adopted.
4. Move atomicallyUpdate owner and every attached control right without duplicating accrual or leaving orphan branches.
5. ResumeMake the new owner effective from a deterministic future accounting boundary and emit a complete audit event.

A charter transfer can create price discovery for the full operating position without requiring the seller to liquidate accrued tokens first. That may reduce token-sale pressure, but it can also concentrate control, create leverage around expected accrual, and expose buyers to hidden liabilities. Market price is not a protocol-guaranteed floor, and the protocol should not describe a private marketplace quote as realizable value.

• The treatment of already accrued but unsettled units must be explicit.
• Open auctions, cooldowns, reports and revocation challenges must block or travel with the position deterministically.
• Approval, royalty, marketplace, recipient and jurisdiction rules are not specified.
• A one-way activation removes a user expectation of permanent non-transferability and therefore requires advance notice.

The expansion hypothesis is that sustained net capital entry can support a higher issuance multiplier, making active branches more valuable and potentially increasing demand for branch licenses. If license settlement burns protocol tokens, expansion demand may remove some circulating supply. However, prospective issuance also dilutes circulating ownership, and speculative trading can create a signal without durable use.

The contraction hypothesis combines lower future issuance with bounded reserve-funded purchases and possible exit-charge redistribution. Lower issuance reduces prospective dilution; purchases may remove tokens if execution and burns succeed; redistribution may reward positions that remain. These effects can be overwhelmed by thin liquidity, synchronized exits, depleted reserves, adverse asset prices, or loss of confidence.

Before activation, the controller should be simulated across normal growth, oscillating flow, wash trading, illiquidity, reserve-asset drawdown, chain congestion and mass retirement. Metrics should distinguish realized flow, policy output, ledger accrual, wallet issuance, burns, reserve value and execution cost. Circuit breakers must have explicit triggers and consequences; an operator’s discretion should not be disguised as autonomous policy.

The following register groups the minimum decisions required to turn the design into an implementable specification. “To be confirmed” means no Reserve value has been approved. It is different from a numeric zero and different from an unavailable read. Any future update should include rationale, units, bounds, change authority and an effective date.

The public reference contains readable example settings as well as redacted formulas and parameters. Those observations are recorded separately in docs/whitepaper-source-map.md for traceability. They are not silently promoted into this register, and redacted values are not reconstructed by assumption.

The proposed token is not described here as a bank deposit, insured account, guaranteed stable asset or claim redeemable on demand. Reserve operations may be unable or unwilling to support market price. A charter is not a guaranteed income stream. Accrual depends on future implementation, valid policy operation, active branch rules and sufficient supply authorization; its market value may be zero.

Formal verification of isolated invariants would not prove economic safety. An audit would reduce some implementation uncertainty but would not eliminate governance compromise, oracle and market manipulation, custody loss or adverse incentives. Conversely, a polished interface and deterministic zero-state display provide no evidence that the underlying system exists.

• Do not send assets or sign transactions based on this paper or the current application.
• Do not interpret “reserve” as guaranteed collateral, insurance, redemption or protection from loss.
• Treat all parameters as pending until they are published with units, authority and verified contract references.
• Require independent technical, economic and legal review before any production authorization.