Karak
Karak Vault State Determines The Next Redemption Step And The Evidence That Confirms Completion
Karak exposes enough vault and withdrawal state to separate an open position from a queued redemption and a completed exit. Start with the exact network, standard vault, staker and withdrawal nonce. When the current state permits a transaction, submit the appropriate start or finish call and confirm completion through the matching event and final share and asset balances.
A wallet confirmation shows that the wallet accepted a signature request, not that the transaction succeeded on-chain. The receipt, queued record and balance changes must agree before the task is closed, while a reverted call leaves the prior on-chain state intact.
The short version: Match the network, vault, wallet and nonce before starting or finishing a redemption, then use the receipt, event, pending state and balance changes to confirm completion.
Standard Progress and Bounded Recovery
The normal path follows the current state in the standard token vault, while recovery begins by correcting the read context rather than sending another transaction.
Normal Progress
Read the share balance, the next withdrawal nonce and any queued record for the relevant earlier nonce. If no redemption has started, confirm the intended share amount and beneficiary, then confirm that the vault has enough share-token allowance before calling startRedeem. A confirmed start moves the selected shares into the vault and creates a pending record. After the required delay, finishRedeem completes that same request.
Absent or Mismatched Records
If an expected request appears absent, stop before creating another one. Compare the network, vault address, staker address and nonce with the successful start receipt. A legacy supervised withdrawal and a standard vault redemption use different state stores, so one route cannot report the other route’s progress. When the original transaction never confirmed, no queued state exists to finish.
State Fields That Control the Next Action
The standard vault stores the staker, start timestamp, share amount and beneficiary for each queued withdrawal.
| Queued Parameter | Recorded Value | Main Failure Signal |
|---|---|---|
| Staker | Address that queued the redemption | A different staker address has a separate nonce history |
| Start | Timestamp recorded when the request began | A zero value means no live record exists at that key |
| Shares | Vault shares held for redemption | Completion fails if the stored shares are not redeemable |
| Beneficiary | Address designated to receive the asset | Completion pays the stored address rather than the caller |
getNextWithdrawNonce is a cursor for the next request, not a count of pending withdrawals. Earlier nonces can represent open or completed requests. Use the start receipt or event to identify the relevant nonce, then compare isWithdrawalPending with getQueuedWithdrawal. The first reports existence, while the second supplies the fields needed to validate the request.
The Commitment Boundary
The meaningful commitment occurs when startRedeem succeeds because the contract then stores the request and takes custody of its queued shares.
Inputs Before Submission
Before submitting that transaction, the share amount and beneficiary remain planning inputs. Correct either value without altering vault state. Also verify the selected vault manages the intended underlying asset, because a valid call against the wrong vault creates a valid request in the wrong context.
Fields After Confirmation
After confirmation, the standard request does not expose a user function for editing its shares or beneficiary. The bounded action is to monitor the saved request and finish it when eligible. Sending another start transaction does not rewrite the first record; it creates another nonce and another withdrawal key. A mistaken beneficiary can therefore leave a pending request without a routine field-level correction.
When Is a Withdrawal Ready to Finish?
A withdrawal is ready when its queued record exists, the required delay has elapsed, the finish function is available and the stored shares remain redeemable. The standard vault rejects completion until its minimum withdrawal delay has elapsed.
Calculate maturity from the stored start time and the delay that applies to the deployed implementation. A cached interface countdown can lag contract state. The pending flag confirms that a request exists, but it does not prove maturity. An early finish call reverts and preserves the request, although the caller can still spend transaction fees.
One Valid State Change
The valid change depends on the current state: create a request only from an unqueued share balance, or finish the existing request after it becomes eligible.
Queueing the Shares
startRedeem accepts a nonzero share amount and a nonzero beneficiary for the standard vault. A successful call records the request, advances the staker’s nonce and emits a start event containing the withdrawal key. It also transfers the selected shares from the staker into the vault, separating queued shares from the wallet’s remaining position.
Completing the Redemption
finishRedeem takes the saved withdrawal key. Once validation succeeds, the vault determines the redeemable asset amount, removes the queued record, burns the held shares and sends the underlying asset to the stored beneficiary. A finish event identifies the completed request. Starting a second redemption is not a repair for a request that merely needs more time.
Transaction Receipts and Event Pairing
The receipt status decides whether a submitted action changed state. A successful start receipt should contain the expected vault and start event, while a reverted receipt creates no usable withdrawal record. Keep both the transaction hash and withdrawal key because they identify different objects: one identifies the transaction and the other identifies the queued redemption.
Completion evidence should agree across the receipt, event, contract state and balances. The finish receipt must succeed, the finish event must carry the expected request identity and a fresh contract read must show that the request is no longer pending. Finally, reconcile the beneficiary’s underlying asset balance and the staker’s remaining share balance. A visual success message alone does not establish those changes.
Incomplete Progress and Wrong-Context Reads
Incomplete progress has several observable forms. A signed wallet prompt may never reach the network. A broadcast transaction can remain pending, and a mined transaction can revert. None of those states creates the same result as a successful start. Conversely, a confirmed start remains pending until a separate successful finish removes its record.
An empty read can also be accurate for the inputs supplied while still describing the wrong position. Changing the network, vault, staker or nonce changes the lookup. An indexer may remain behind the chain after a successful transaction, so compare its display with the receipt and a direct contract read. Do not submit a replacement state change merely to refresh an interface.
Share Conversion During the Queue
Queued shares define the size of the claim, but they do not lock an immutable quantity of the underlying asset. The start event includes an asset estimate calculated when the request begins. The vault converts queued shares to underlying assets again when the redemption finishes.
Changes to the vault’s assets or share conversion can therefore affect the amount returned at completion. Slashing can reduce vault assets, and the contract checks whether the queued shares remain redeemable before finishing. Reconcile the actual amount from the successful finish event and beneficiary balance rather than treating the earlier estimate as a fixed payout.
Closure Across Multiple Requests
Closure applies to one request in one vault. A staker can have earlier nonces, later nonces or positions in other vaults that remain open after one redemption finishes. The next nonce also stays advanced because completing a request does not rewind request history.
For the completed item, the withdrawal key should match the finish event, the pending check should return false and the queued record should no longer contain live request data. The beneficiary should hold the transferred underlying asset, while the queued shares should no longer exist as outstanding vault shares. These checks prove contract-level closure only; they do not prove that an interface or external accounting service has finished indexing it.
Practical questions about Karak
Can Another Address Finish a Queued Karak Redemption?
Yes. In the standard ERC-20 vault, any address may call finishRedeem once the delay has elapsed, the function is active and the queued shares remain redeemable. The contract sends the underlying assets to the beneficiary stored when startRedeem succeeded. The caller does not gain control of the payout by completing the request. This permissionless finish behavior is route-specific, so a legacy supervised withdrawal with a designated withdrawer follows different authorization checks.
Is the Beneficiary Required to Match the Staker?
No. The standard vault accepts the beneficiary separately from the staker, so the payout address can differ from the address that queued the shares. The beneficiary becomes part of the stored request, and finishRedeem uses that saved address. Because the standard request has no documented beneficiary-update function, compare the complete address before confirming the start transaction rather than relying on a shortened wallet label.
What Happens If I Query the Wrong Withdrawal Nonce?
A wrong nonce usually returns an empty queued record and a false pending result, even when another nonce remains active. Check the staker’s next nonce to understand the available range, then use the successful start receipt or indexed event to locate the request that was actually created. Keep the vault address in the lookup because each vault maintains its own withdrawal state.
Does Finishing a Queued Redemption Need a New Token Approval?
No new underlying-token approval is part of finishRedeem for the standard vault. The start step has already moved the queued vault shares into the vault, and the finish step processes those stored shares. The transaction caller still needs the network’s gas asset. An allowance failure belongs to an earlier asset or share movement, not to the ordinary completion of an existing queued request.
Is getNextWithdrawNonce a Count of Unfinished Withdrawals?
No. getNextWithdrawNonce returns the nonce that the next request will use, not the number of requests still pending. The value advances when new redemptions start and does not decrease when they finish. Some earlier nonces may be closed while others remain open. Determine each request’s status with its own nonce, staker address and vault rather than subtracting completed items from the cursor.
Could the Same Withdrawal Key Appear in More Than One Vault?
Yes. The standard withdrawal key is derived from the staker address and that vault’s withdrawal nonce, while each vault stores requests in its own contract state. A staker using the same nonce in two vaults can therefore produce the same key value. Record the network and vault address beside every key because the key alone does not identify the contract that owns the request.
Why Can the App Still Show Pending After the Finish Transaction Succeeds?
The interface may be reading an indexer that has not processed the finishing block yet. First confirm that the receipt succeeded on the expected network and vault. Then match the finish event to the withdrawal key and query the pending state directly. If the contract reports closure and the beneficiary balance changed, a lingering pending label is a display or indexing issue rather than another withdrawal step.