Snowbank
Snowbank supported direct staking and a helper that claimed eligible sSB
Snowbank supported direct SB staking on Avalanche and a helper that called stake and claim within one transaction. Immediate sSB release required an eligible warmup record, even when both calls shared that transaction. These were features of the published implementation; current availability of the original application remains unconfirmed.
Updated -
SB approval followed the entry contract
A direct deposit required the staking contract to transfer SB from its caller. Through the helper, the helper first transferred SB from its own caller. The caller therefore had to grant SB allowance to the contract that first transferred the tokens. Approval for one address did not automatically authorize the other address, even though both routes reached the same staking implementation.
The recipient argument identified the account whose staking record received the deposit. It did not change which account supplied the SB. A caller funding another recipient still supplied the tokens and the relevant allowance.
The helper combined calls in a fixed order
The helper placed the staking call before the claim call inside its own stake function. It passed the same recipient to both calls. That ordering allowed the claim to examine the record that staking had just updated, including any deposit that the recipient already had pending.
Token movement
Transfer from the caller
SB entered the helper through transferFrom for the requested amount. The helper therefore needed access to the caller’s SB balance through an allowance. Naming a recipient did not give the helper permission to debit that recipient.
Approval for the staking contract
The helper then approved its configured staking contract for that amount. During the nested staking call, the staking contract treated the helper as its caller. This authorization covered the movement from the helper into staking.
Claim dispatch
After staking returned, the helper called claim for the recipient. The helper itself neither calculated the warmup expiry nor transferred sSB to the recipient. Those responsibilities remained with the staking contract and its configured warmup contract.
When did the helper release sSB immediately?
Zero configured warmup epochs allowed immediate release when the resulting expiry was nonzero and the required transfers succeeded. With a positive warmup, staking assigned a future expiry. The helper’s immediate claim left the record pending whenever the stored staking epoch remained below its expiry.
Claim eligibility used the stored epoch number, which claim did not advance. Each call to rebase advanced it by one only if the stored epoch end time had been reached. An estimate based only on elapsed hours did not replace that condition.
Shared settings and recipient fields
Both entry methods used the staking contract’s warmup period and recipient accounting. These fields described the published rules, without establishing a current configured duration. Gons were the internal units that connected the deposited amount with the rebasing token balance.
| Field | Published value or rule | Role in staking | Required condition |
|---|---|---|---|
| warmupPeriod | Configurable count of epochs | Added to the staking epoch when depositing | Manager authority to change the setting |
| Recipient expiry | epoch.number + warmupPeriod | Replaced the previous expiry on a new deposit | An accepted stake for that recipient |
| Recorded deposit | Previous deposit + requested SB amount | Accumulated the deposited SB | Successful SB transfer into staking |
| Recorded gons | Previous gons + gonsForBalance(amount) | Accumulated rebasing accounting units | The configured token’s balance conversion |
| Recipient deposit lock | False for an accepted stake | Blocked the staking call when true | An unlocked recipient record |
| Helper staking address | Immutable address fixed at construction | Received both stake and claim calls | Nonzero constructor address |
New deposits changed an existing recipient record
Adding SB combined the new deposit with the recipient’s existing warmup deposit and gons. The contract also replaced the shared expiry with the current staking epoch plus the configured warmup period. It did not create a separate expiry for each contribution. That behavior applied to deposits arriving directly and through the helper.
An older contribution therefore shared the newly assigned expiry after another accepted stake. The helper’s following claim examined that updated record, rather than the record that existed before the deposit. The direction of an expiry change depended on the current epoch and configuration; the code did not preserve an older contribution’s separate release date.
Gons connected deposits with rebasing balances
Deposited SB and recorded gons measured different things. The deposit field accumulated the amount supplied. Gons represented the claim’s rebasing balance through the configured token’s conversion functions.
Internal accounting units
Staking converted each new amount with gonsForBalance and added those units to the recipient’s record. In the published sSB token, the conversion multiplied the token amount by the current gons-per-fragment value. Keeping the internal units allowed the corresponding displayed balance to reflect a later rebase without rewriting every holder’s gon balance.
The displayed token balance
The reverse conversion, balanceForGons, divided gons by the current gons-per-fragment value. A positive rebase changed that relationship as the token supply increased. The same internal units could then represent more sSB. Choosing the helper did not introduce a different conversion or a separate staking asset.
Claiming and forfeiting released different assets
A matured claim released the sSB represented by its gons. Forfeiting instead returned the caller’s recorded SB deposit and recovered the associated sSB for the staking contract. The caller did not receive that recovered sSB.
The helper’s destinations stayed fixed
The helper’s constructor fixed its staking destination and token address as immutable values. Both addresses had to be nonzero. Each deposit used those stored destinations; the caller supplied an amount and recipient, without selecting another staking contract inside that call.
The warmup contract had a narrower role. Its retrieve function accepted calls only from its configured staking contract and transferred the requested token amount to the specified recipient. The helper reached that release mechanism through claim. It had no separate authority to call retrieve directly as the staking contract.
Bond redemption selected a configured staking route
Bond redemption could send the vested payout to its recipient or pass that payout into staking. The redeem function’s staking choice controlled this distinction. The depository’s configuration then determined whether staking used the helper or called the staking contract directly.
The useHelper setting selected the integration. The redemption caller’s choice to stake did not itself select a different helper address or override that configuration.
With helper mode enabled, the depository approved the helper for the payout and called its stake function. In direct mode, it approved the staking contract and called stake there. Both paths preserved the bond payout’s recipient.
Vesting determined the payout available for redemption; the chosen staking implementation governed the resulting warmup record.
The entry method did not set the rebase return
Both methods reached the same staking function, which invoked rebase before recording the new deposit. The helper supplied an additional claim call after that function returned. It did not supply an independent reward calculation or set a different rebase rate for its recipient.
The published sSB implementation restricted its rebase function to the configured staking contract. A zero profit input left total supply unchanged. A positive profit input used the token’s rebasing calculation, subject to its supply limit. Calling through the helper therefore did not establish a fixed return or prove that the balance would grow during a particular interval.
The staking return value described the deposit
The direct stake function returned true after updating the recipient record and sending the corresponding staking tokens into warmup. That return value belonged to the deposit operation. The published helper’s stake function had no return value specifying how much sSB reached the recipient.
The recipient’s warmup record and sSB token balance described different states. Successful execution could leave a pending record when release conditions remained unmet. Direct staking required a separate call to claim for an eligible record before the recipient received sSB. A pending helper deposit needed a later claim too.
What to know about Snowbank
Can another account call claim for my staking recipient?
Anyone could call claim for an eligible recipient, but the function released sSB to that recipient. The caller could not redirect the payout.
Was the helper required to unstake sSB?
Unstaking used the staking contract directly. Its unstake function required sSB allowance, accepted sSB from its caller and returned the same amount of SB. The trigger argument controlled an initial rebase call.
Did the helper’s Time variable establish that it used the TIME token?
Time was a Solidity address variable, so its name did not establish that the asset was TIME. The helper’s constructor supplied the actual token address. The application’s Avalanche configuration identified Snowbank’s base token as SB.
Could a deposit lock block staking into my own recipient record?
A locked recipient record blocked new stakes into that record, including deposits funded by its owner. The condition applied inside the staking contract, so the helper could not bypass it. The toggleDepositLock function changed the caller’s own lock setting; it did not provide a way to unlock another recipient.
How were SB amounts represented in the helper’s arguments?
The published SB token used nine decimal places, and the helper accepted amounts in the token’s smallest units. One SB therefore corresponded to 1,000,000,000 base units. The helper forwarded the same raw amount into staking. Displayed token amounts and raw contract arguments required that decimal conversion.
Did helper staking require an unlimited SB allowance?
The published helper required enough allowance to transfer the requested SB amount, without requiring an unlimited allowance. It then approved its configured staking contract for that requested amount. This internal approval belonged to the helper, while the caller’s authorization covered the helper’s initial transfer from the caller.