Exit & Withdrawal
User can request to exit their staked position anytime.
Last updated
Was this helpful?
User can request to exit their staked position anytime.
Last updated
Was this helpful?
It’s important to note that all staked positions are 100% collateralized, with ETH primarily held in active validators. Any remaining ETH may be in the operator pool, awaiting deposit into new validators.
Exiting a validator to access the underlying 32 ETH is not instantaneous; it requires the validator to go through the protocol's exit process and enter an exit queue. Consequently, a user exiting their staked position involves a two-step process:
Requesting exit: Users first signal their intent to exit by interacting with the integration contract, which locks their receipt tokens and places them in the exit queue of the operator pool contract. Each pool has its own exit queue, and an integration contract can be linked to multiple operator pools.
Receiving an exit ticket: A ticket, representing the user's position in the exit queue, is minted as an NFT. This ticket reflects the user's place in the queue until their ETH are available to withdraw.
Under normal conditions, with the pool generating rewards and receiving new deposits, it generally takes about 1-4 days for exited ETH to become available for withdrawal. However, in cases where exit demand significantly exceeds the available ETH, the process may be delayed. This delay is influenced by the Ethereum validator exit and withdrawal queue, which typically takes several days but can extend significantly longer in extreme cases.
When the pooling contract receives ETH to fulfill exit requests, it creates a 'cask' that corresponds to the received ETH and the current exit queue demand.
The exit queue functions as a system where users receive a ticket to retrieve their ETH. This ETH is periodically allocated to the queue in the form of casks. The queue operates on a first-come, first-served basis, without discrimination or favoritism towards any user or scenario.
When casks arrive, users must still claim their ETH. This is due to Solidity's limitations on the number of actions that can be performed in a single transaction. Consequently, a cask may fulfill one or multiple tickets at once. The smart contract cannot iterate through all tickets in a single transaction due to the potentially high and variable number of tickets.
Tickets can have several statuses:
unfulfillable: the ticket is waiting for a cask to arrive and fulfill its exit request.
partially fulfillable: the ticket has one or several casks partially fulfilling its exit request, this means that the ticket can be claimed, but this action will result in getting an updated ticket with the remaining amount yet to be claimed.
fulfillable: the ticket has one or several casks completely fulfilling its exit request. Claiming this ticket will retrieve the funds and burn the ticket.
In the example above, we can see that:
Tickets #0 and #1 are currently fulfillable by cask #0.
Ticket #2 is currently partially fulfillable by cask #1
Ticket #3 is unfulfillable.
Keep in mind that both of these queues can grow independently, and the goal of the pooling contract is to provide casks to make the cask queue grow and reach the same height as the ticket queue, making all ticket fulfillable
