Snowbank treasury code constrained asset management and reward minting through excess reserves

What did excess reserves measure?

Excess reserves equaled recorded reserves minus total SB supply net of treasury debt. In simplified notation, the relationship was totalReserves - (totalSupply - totalDebt) . Here, totalSupply meant SB supply, and subtracting debt reduced the supply deduction without adding tokens to the treasury.

Reserve tokens and liquidity positions

Reserve-token valuation scaled an asset’s raw amount into SB units using the tokens’ respective decimal counts. Liquidity tokens, which represented pool positions, instead followed the assigned bond calculator’s valuation function. That output entered the treasury accounting. An asset’s quoted exchange price therefore could not replace its configured treasury valuation.

Stored totals and reserve audits

totalReserves was a stored figure that treasury operations updated, so a direct token transfer did not itself update that bookkeeping. A manager-only auditReserves call recalculated the total from balances in the reserve and liquidity lists. Each entry followed the applicable valuation rules, and the audit loops did not deduplicate assets appearing in both lists.

Asset management and reward minting used different permissions

Asset management spent treasury holdings, while reward minting created additional SB. Each action required a separate caller role and used the same excess-reserve margin.

Transferring treasury assets

The manage function required a liquidity manager for a token flagged as liquidity and a reserve manager otherwise. It compared the requested asset’s treasury value with excess reserves, then reduced totalReserves by that value. The asset went to the caller. For a recognized asset, this consumed accounting headroom without burning SB or reducing treasury debt.

Issuing SB rewards

A reward manager used mintRewards to mint SB to the specified recipient, subject to the excess-reserve limit on the requested amount. Minting increased token supply without reducing the recorded reserve total, so it consumed the margin through the supply term. The function accepted a recipient argument; its interface did not restrict every reward to a staking address.

Open full-size image

How did deposits and withdrawals affect excess reserves?

Approved deposits added their retained accounting surplus to excess reserves, while reserve withdrawals offset falling reserves with an equal SB burn.

Approved deposits

An accepted reserve or liquidity deposit added its full treasury value to totalReserves . The treasury minted that value minus the supplied _profit to the approved caller. All else equal, a positive retained amount increased excess reserves; retaining zero left the margin unchanged. The parameter expressed an accounting amount, not a percentage of the deposited balance. A _profit above the calculated value caused subtraction to revert.

Burning SB for reserves

Reserve withdrawals required a reserve spender and an accepted reserve token, alongside the spender’s SB balance and burn allowance. The treasury burned SB equal to the asset’s accounting value and subtracted that value from recorded reserves. With debt unchanged, those reductions offset each other while the excess-reserve calculation remained valid. This distinguished withdraw from manage , although both transferred assets to their callers.

Treasury debt changed both sides of the calculation

Borrowing reserves reduced recorded reserves and increased treasury debt by the same internal value. An approved debtor’s available capacity equaled its configured staked-token balance minus its existing treasury debt. The borrowing function checked that balance without taking custody of the staked tokens. Increasing debt reduced the supply deduction, offsetting the reserve decrease where the excess-reserve arithmetic remained valid.

Repayment with accepted reserves increased recorded reserves and reduced debt by the asset’s accounting value. Repayment with SB instead burned SB and reduced treasury debt by the same amount. Those reductions left supply net of debt unchanged. Both repayment functions required an approved debtor; subtraction checks also prevented repayment above the recorded debt balances.

Permission queues controlled access

The treasury manager controlled permissions for deposits, reserve spending, borrowing and rewards. For the listed reserve, liquidity, debtor and reward roles, enabling an inactive address required a matured queue entry and a manager’s toggle call. Reserve-manager and liquidity-manager queues used twice the configured base delay. Other listed role queues used the base delay, expressed in seconds. The constructor supplied that delay, so the code established no universal waiting period.

Disabling an already active listed role did not require a fresh delay. Existing permissions still mattered independently of the reserve margin.

SB backing figures and redemption access had different meanings

The accounting margin described how much valued asset management or reward issuance the specified functions could permit. It established neither a market price floor nor withdrawal access for every SB holder. Direct reserve withdrawals required reserve-spender permission and an SB burn. These were rules of the published Avalanche implementation; current balances and access to the original application remain unconfirmed. Reading quantities also required the correct precision: the reserve-token conversion used SB’s nine decimal places.