Karak withdrawals in the 2024 vault design required a queued request before a separate completion call

The position and its queue record determined the available action

Completion required an existing queue entry; without one, the token and native implementations first needed a valid withdrawal request. The token Vault took a share amount from its holder. NativeVault required the caller to own a native node with eligible ETH. A position's total balance didn't establish how much either method could pay immediately. Identifying the vault type therefore came before choosing the exit function. The request also belonged to a particular contract and account, so a pending entry elsewhere couldn't establish readiness for that position.

V1 staking, V2 staking and K2 bridge access appear as legacy entries. Their labels don't establish account eligibility or make the 2024 queue rules universal.

The nine-day minimum separated initiation from completion

The 2024 vault design set MIN_WITHDRAWAL_DELAY to nine days. The timing check compared the request's stored start timestamp plus that delay with the current block timestamp. Reaching that boundary satisfied the wait, while other completion checks still applied.

The design combined a seven-day slashing window with a two-day veto window. A Distributed Secure Service (DSS) could request penalties against collateral that backed an operator's obligations. The withdrawal delay allowed time to process relevant penalties before assets left the vault. A pending request therefore didn't freeze the value behind its shares or native position. Slashing could reduce the eventual payment even after initiation succeeded. The service's ability to impose a penalty followed its own allocation and slashing rules; the queue wasn't a guarantee of principal preservation.

The contract recorded the start time when initiation succeeded. Time spent preparing a request didn't count toward the delay. An operator's service unallocation was a separate action.

Token vault exits locked shares before paying the beneficiary

In the 2024 token Vault, version 2.0.0, startRedeem accepted shares and a beneficiary address. Shares represented a claim on the underlying ERC-20 asset, so their quantity wasn't necessarily the asset quantity eventually paid. Initiation moved the requested shares from the staker into the vault and stored their amount in the queue record. It didn't burn those shares or send the underlying asset to the beneficiary. The record retained the staker, start timestamp, share amount and beneficiary.

Native ETH requests depended on credited funds and a fresh snapshot

NativeVault handled ETH through a NativeNode mapped to the account whose position it tracked. A completed snapshot updated that position's accounting from node funds and validator balance proofs. The vault's startWithdrawal method took an ETH amount in wei and a recipient address. Initiation required an existing node, enough eligible funds and a last completed snapshot that hadn't expired. The token vault's share-based request didn't replace those requirements.

ETH already credited at the node

In the 2024 NativeVault, withdrawableWei returned the smaller of an owner's share-equivalent ETH and credited withdrawable node ETH. Total restaked ETH included validator balances as well as node funds. That total could exceed the ETH eligible for this withdrawal method. Existing queued amounts also reduced the capacity for another request. A new request needed enough eligible ETH to cover its amount alongside funds already queued. Increasing the requested amount couldn't make an uncredited balance available, and a share balance alone didn't establish the node's withdrawable funding.

The last completed snapshot controlled initiation

The seven-day freshness boundary

The 2024 design set SNAPSHOT_EXPIRY to seven days. Initiation failed with SnapshotExpired once the current timestamp reached the start timestamp of the last completed snapshot plus that period. This freshness requirement applied when starting a native withdrawal. It governed a different clock from the withdrawal request's nine-day waiting period. If no snapshot was already in progress, the node owner could call startSnapshot, or anyone could call validateExpiredSnapshot after expiry.

Balances awaiting validator proofs

While a snapshot still needed validator proofs, starting it didn't refresh the last completed timestamp or credit its new node balance. Completion of the snapshot incorporated those changes into accounting. An unfinished snapshot didn't itself forbid withdrawal initiation if the earlier completed snapshot remained fresh and enough credited ETH was available.

Completion determined the payment and closed the request

The token vault's finishRedeem converted queued shares into underlying assets using the vault's accounting at completion. Slashing could reduce the assets backing those shares during the wait. The earlier StartedRedeem event's asset figure therefore wasn't a fixed payout. The stored beneficiary received the assets when completion succeeded. The function also checked the queued shares against the vault's redemption limit. Passing the time check alone couldn't override that limit or a pause affecting completion. The share amount remained the request's input; the completion event recorded the actual underlying asset amount.

Native finishWithdrawal compared the recorded ETH request with the owner's current withdrawableWei . When the request exceeded that value, the function capped the payment at the available amount. It reduced the owner's accounting and instructed the NativeNode to send ETH to the stored recipient. The queued ETH amount could therefore exceed the final payment without changing the recipient.

Open full-size image

Successful completion emitted FinishedRedeem or FinishedWithdraw and removed the request's queue entry. The successful transaction receipt and corresponding payment established completion. A submission hash alone didn't establish a transfer. A revert during completion rolled back that call's payment and queue updates.

K2 claims have a separate eligibility screen

The K2 withdrawal entry point is a claim-eligibility screen for available K2 assets. Its process differs from the token Vault and NativeVault queues. The nine-day parameter describes the 2024 vault implementations; it doesn't establish a K2 claim schedule. Connecting a wallet alone doesn't prove that a payment has occurred. K2 Claims asks to connect the wallet associated with the original withdrawals.