Snowbank bonding terms, vesting and redemption

Snowbank bonding exchanged an accepted asset for a vesting claim on SB, the Snowbank token on Avalanche. Depositing committed the asset before the full payout became claimable. The depository specified the input token, quoted payout and vesting term; the caller set the maximum acceptable price. Redemption released the vested portion or directed it into configured staking. Current availability of the original application remains unconfirmed, so an old quote does not establish that a bond can be purchased today.

Updated - 18 October 2026

The short version: A Snowbank bond’s stored vesting record governed claimable SB, while staking warmup could delay release after a staking redemption.

The commitment began with the deposit

Reading terms and calculating a payout left assets untouched; a successful deposit transferred the selected input and created a bond claim. A token approval authorized spending by the chosen depository, without creating the vesting record. The input contract address mattered because each depository fixed its accepted token at deployment. The deposit amount used that token’s decimal scale, while the payout used SB units.

A quote had to match the depository that would receive the deposit. A different input token, recipient or vesting term changed the proposed transaction. Inspect these fields before a first deposit or any required token approval. If the quoted terms do not match the intended purchase, stop before committing assets.

Reserve assets and price-feed inputs followed different funding paths

SnowbankBondDepository and SnowbankPriceFeedBondDepository used different treasury funding calls, with distinct permissions and asset handling for each deposit path.

Reserve and liquidity inputs

The reserve and liquidity implementation obtained the input’s accounting value from the treasury, then calculated the bond payout. Reserve-token valuation adjusted token decimal places; liquidity-token valuation used the configured bond calculator. The depository transferred the accepted asset from the caller, approved the treasury and invoked its deposit function. That path required both an accepted input and the appropriate treasury depositor permission for the depository itself. A wallet holding a reserve asset therefore still needed the depository configured for that exact token.

Price-feed funding

The price-feed implementation sent the input directly to the treasury and requested payout tokens through mintRewards . That call required treasury reward-manager authorization and sufficient excess reserves. Its payment branch examined the depository’s native balance. At or above the requested amount, it attempted to wrap that amount through the configured input contract. Below that amount, it transferred the input token from the caller. Native payment required a compatible wrapped-native input; an ERC-20 allowance did not determine which branch executed.

Quoted payouts faced price and capacity limits

A deposit could proceed only when its payout met the size bounds, its price stayed within the caller’s ceiling and debt passed the capacity check. In the reserve and liquidity depository, the control variable, debt ratio and any active floor determined internal bond pricing. The quote therefore changed with the depository’s state. The maximum-price argument limited the internal price accepted during execution.

The lower payout check required at least 10,000,000 raw units. With SB’s nine decimal places, this equaled 0.01 SB. It constrained the SB payout, not a universal minimum amount of the deposited asset. The upper payout depended on token supply and the configured payout parameter.

Debt capacity was checked after debt decay and before the new deposit increased debt. Treasury authorization was a separate requirement.

How long did a Snowbank bond take to vest?

Each bond stored its own remaining vesting time in seconds, which determined when its unpaid payout became claimable. That record paired the remaining payout with a last-interaction timestamp.

Configured duration and stored duration

A new deposit copied the selected depository’s vesting term into the recipient’s bond record. Both published depositories required at least 129,600 seconds, or 36 hours, for vesting-term updates through setBondTerms .

Initialization accepted its separately supplied term without that same lower-bound check. The setter’s threshold consequently did not establish an original duration for every bond. The stored record and the term applicable to a proposed deposit answered different timing questions.

Partial redemption

During an unfinished term, redemption calculated the vested fraction from elapsed seconds divided by the stored remaining duration. It redeemed that fraction of the unpaid balance, shortened the remaining term and updated the last-interaction timestamp. Once the record reached full vesting, redemption processed the entire unpaid amount and deleted the record. Earlier claims therefore left the unvested balance on its remaining schedule. The claimable amount and total unpaid amount described different balances; a full displayed payout did not mean every token was immediately available.

The standard depository’s DAO fee used the payout as its base

The reserve and liquidity implementation recorded the depositor’s calculated payout in full and accounted for the DAO allocation separately. Its DAO fee equaled the bond payout multiplied by the configured fee parameter and divided by 10,000. A nonzero allocation went to the configured DAO address. The treasury deposit calculation treated the valued input minus the payout and that allocation as profit.

The price-feed implementation exposed no equivalent fee field in its terms. Its payout funding instead used the treasury’s reward-minting path.

Funding and redemption modes required different prerequisites

Reserve, liquidity and price-feed funding required different assets or permissions, while wallet and staking redemptions used an already vested claim. Staking modes followed the depository’s configuration.

Bond vesting and staking warmup governed separate releases. Selecting staking during redemption could create a pending staking balance; the helper called stake and claim together. Immediate sSB release still required an eligible warmup record.

A completed deposit left a dated bond record

A successful deposit recorded the payout, vesting term, timestamp and price, then emitted BondCreated with the deposit amount and expiry. That event described creation of a claim. An allowance change alone described spending permission, while a transaction identifier alone did not establish a successful execution.

The deposit amount described the asset paid into the bond; the payout described the SB owed under its vesting record. Redemption later reduced that obligation and emitted BondRedeemed . The published redemption path distributed SB or staked the vested amount, rather than returning the deposited asset.

Open full-size image

Within the same depository, a further deposit reset the recipient’s combined unpaid payout to the then-applicable vesting term.

Snowbank bonding - your questions answered