Documentation
Treasury mechanics
Staking pays from inventory the protocol already holds. Bonds escrow their full payout before a sale window opens. The treasury keeps four balances apart so that neither mechanism can spend what the other has committed.
The constraint everything follows from
Supply is fixed at 1,000,000,000 units and no mint path survives deployment. That single fact shapes the whole treasury design: every payout must come from inventory that already exists, so the question is never how much can be emitted but what has been set aside, and what is already committed against it. That answer has to be exact, which is why the treasury separates balances instead of tracking one pooled number.
Balance separation
AlmeruTreasury holds four accounted balances. They are not four contracts;
they are four ledgers within one contract, and every inbound or outbound movement is
attributed to exactly one of them.
| Balance | Holds | Spendable by |
|---|---|---|
| Free | Uncommitted assets available for discretionary use | Buybacks, within oracle constraints |
| Backing | Reserves accounted as backing for outstanding supply | Nothing — it is a measured position, not a budget |
| Bond | Payouts escrowed against open and scheduled bond windows | Bond settlement only |
| Operating | Assets earmarked for protocol operation | Operating expenditure only |
The separation is what makes the guarantees below checkable. "The protocol can cover its bonds" is not an assertion about a total; it is the statement that the bond balance is at least the sum of outstanding bond obligations, and that no other module has a path to spend from it.
Staking
Staking is a deposit-and-receipt system. A holder deposits the token and receives a receipt representing that position; rewards accrue to the receipt. Three token forms exist:
| Form | Behaviour | Balance changes when |
|---|---|---|
TOKEN | The base asset. Fixed supply, non-mintable, tradeable in the canonical pool | You transfer it |
sTOKEN | Rebasing staking receipt. Balance grows as rewards accrue | Every rebase |
gTOKEN | Non-rebasing wrapper. Balance is constant; each unit claims a growing share | Never — the redemption rate moves instead |
sTOKEN and gTOKEN represent the same underlying position and
convert between each other at the current index. The choice is about accounting ergonomics:
a rebasing balance is easier to read at a glance, a constant balance is easier to integrate
against.
Rewards come from inventory, never from later buyers. The staking module pays out of a reward balance funded at launch and topped up by the fee route. It has no mint authority and no claim on incoming purchases. When the reward inventory is exhausted, emission stops. It does not dilute, and it does not borrow forward against future deposits.
Fee income reaching the holder-reward leg of the route — 40% of the protocol share in the common configuration described in What launches — replenishes that inventory. Emissions are therefore a function of realised trading activity, not of a schedule the protocol promises to meet.
Bonds
A bond sells token at a discount for an asset the treasury wants to hold. Two rules constrain every window:
Full pre-escrow
Before a bond window opens, the entire payout for that window is moved into the bond balance and is committed. The protocol cannot open a window it does not already hold the tokens to settle. That removes the failure mode where a bond program sells more than it can deliver and covers the gap with new issuance — an option that does not exist here anyway.
Per-epoch capacity
Each epoch carries a capacity cap: the maximum that may be sold in that epoch, regardless of demand. When capacity is exhausted the window closes until the next epoch, and unused capacity does not roll forward. Caps are read against the oracle's harmonic-liquidity floor, so a period of thin depth reduces what a bond may absorb rather than letting it price aggressively into a shallow book.
epoch opens ├─ escrow full payout → treasury.bond ├─ capacity = min(configured cap, liquidity-constrained cap) ├─ price = f(time-weighted average price, discount) └─ sold ≥ capacity → close until next epoch unused capacity: discarded, never carried forward
Buybacks
Buybacks spend from the free balance into the canonical pool. They are gated on both oracle signals: purchases price against the time-weighted average rather than the spot quote, and they will not execute if measured depth is below the harmonic-liquidity floor. The intent is that the treasury buys because it holds surplus, not because a momentary print made it look cheap. The oracle mechanics are in Market integration.
Buybacks cannot touch the bond, backing or operating balances. If the free balance is empty, no buyback occurs — the module has no borrowing path.
Reserves and backing
The reserve leg of the fee route — 60% of the protocol share in the common configuration — accumulates into the treasury and is accounted as backing. Backing is a measurement, not a promise: it states what the treasury holds against outstanding supply at a point in time. It carries no redemption right and no floor commitment, and it grows only when trading occurs.
Locked liquidity sits outside all four ledgers, in AlmeruLocker. It
compounds in place and is never withdrawable into the treasury, so it is never counted as
spendable by any module above.
Configuration and change
The reward route is set at deploy and frozen. Parameters that remain adjustable — bond
discount, epoch capacity, buyback budget — move through AlmeruTimelock, so no
change takes effect in the block it is proposed. The authority model behind that is in
Protocol architecture and
Wallets and authority; the caps that bound the agent itself are
in Security model.