Zircuit withdrawals - Keeper Queues and Asset Exits

Share location and payout destination

Share location and payout destination determine whether a Finance redemption needs cross-chain transport before, after or on both sides of the vault operation.

Shares on Base

Base hosts the Finance accounting vaults, which use the ERC-4626 tokenized vault standard. A request that starts and ends there needs no cross-chain messaging. The local route still uses the withdrawal queue. Keeping the operation on the accounting chain removes a transport dependency without removing keeper processing.

Shares on Ethereum

Ethereum supplies another supported access chain for the USDC and USDT vaults. Shares held there must reach the Base-side composer for redemption. A payout directed to Ethereum also needs an outbound asset message. Source and destination describe separate routing choices, while Base remains the accounting chain.

The keeper-managed redemption queue

The Finance composer holds requested shares in a queue until an authorized keeper redeems them and arranges delivery of the underlying assets.

Request creation

The request transfers shares into the composer and emits a WithdrawalRequest event with a queue index. That index identifies a pending request. The event records entry into the queue, before the vault exchanges those shares for assets.

Keeper processing

An account with the WITHDRAWAL_MANAGER role calls processWithdrawals to fulfill selected entries. This transaction calls the vault's redemption function and sends the resulting assets toward their destination. Batch processing can fulfill several entries together.

Cancellation before processing

A pending request can be cancelled through cancelWithdrawal, returning its shares and prepaid fees. Cancellation becomes unavailable once the keeper processes that entry.

Open full-size image

How long can a Finance withdrawal take?

Finance lists a withdrawal window of 14-21 days for its stablecoin vaults. Cross-chain message delivery accounts for only part of an exit that also requires queued redemption.

The vault's allocations have different withdrawal liquidity. Monarq's institutional allocation differs from money market holdings and lending exposure through Aave and Morpho. Liquid reserves support redemptions, while other allocations have their own settlement terms. An individual strategy's liquidity label does not replace the pooled vault's withdrawal window. Successful processing of a particular queue entry executes its redemption. For a cross-chain payout, destination delivery remains a further requirement. A confirmed request transaction therefore supplies a starting record, without establishing when the asset will become spendable.

Asset output and the costs of delivery

The shares selected for redemption determine the quoted underlying asset output, while the route determines cross-chain messaging requirements. A share balance and a stablecoin balance measure different things.

Finance uses a redemption preview to estimate the assets returned for the selected shares. ERC-4626 distinguishes that operation-specific preview from a general share-to-asset conversion estimate. A preview reflects current conditions; it does not promise the same output after conditions change. The integration SDK requires a slippage tolerance of at least 0.1% and rejects lower values before submission. The tolerance sets a minimum acceptable asset output; execution reverts if the output falls below it.

Transaction gas and messaging fees are separate costs. A local route avoids cross-chain messaging, while a remote destination adds transport fees. The fee buffer increases the quoted messaging amount to allow for changes before execution. That extra funding concerns message delivery, not the value of the shares themselves.

Request status and payment confirmation

The tracking interface distinguishes source submission, delivery to the hub, hub execution and destination receipt. Its completed status describes the full operation. A source transaction hash can identify an operation that still has unfinished components.

Bridge withdrawals from the L2

A canonical withdrawal moves assets from Zircuit L2 to Ethereum through bridge contracts, separately from Finance redemption. Initiation occurs on the L2. Release depends on a corresponding state output and the applicable finalization period. Zircuit's manual withdrawal method can combine proof and release in one Ethereum transaction after that period elapses. The L2OutputOracle exposes the configured finalization period in seconds. This parameter governs eligibility for release; the initial transaction receipt alone does not establish that eligibility. The Ethereum transaction also requires gas, independently of the earlier L2 transaction.

For compatible Ethereum-native ERC20 tokens, the bridge burns the L2 representation and releases the corresponding escrowed tokens on Ethereum. Matching token contracts and compatible behavior matter. Rebasing or transfer-fee logic can violate the bridge's accounting assumptions. The canonical system also has an ERC721 bridge for NFTs, with its own asset-specific requirements. Other bridge providers have distinct token coverage: Zircuit lists Hyperlane for ezETH, pzETH and rstETH and Relay for ETH and WETH. Availability depends on the selected token and route.

Liquidity Hub assets and Tapir claims

Liquidity Hub deposits and Tapir positions represent different holdings, so an exit can return a token that still needs a separate redemption. The returned asset determines which remaining conditions apply.

Staking assets and partner redemption

The original Ethereum staking arrangement imposes no Zircuit lockup or withdrawal period. Withdrawal retains accrued Zircuit rewards under that arrangement's terms. A liquid staking token or liquid restaking token represents another protocol's underlying position. Converting that token into its underlying asset follows the partner's redemption rules, including any applicable waiting period.

Tapir settlement and Finance redemption

Tapir's Zircuit Finance USDC market on Base adds claim tokens over a vault position. Trading before maturity depends on available liquidity and an open market. Holders of equal Depeg Protected (DP) and Yield Boosted (YB) token amounts can also recombine them into vault shares while the pool is active, subject to its fees and pause state. Under the pool's published September 8, 2026 configuration, maturity is December 14, 2026, with a 72-hour cooldown and a minimum 24-hour wait after final-price submission. Claim redemption returns vault shares after oracle price submission, both timing checks and pool resolution, while the pool is unpaused. Converting those shares to USDC then follows the Finance withdrawal process. Access to the market remains subject to eligibility and approval.

Reduced L2 support and emergency exit conditions

The February 25, 2026 transition announcement set best-effort availability for the L2 and best-effort maintenance for the native bridge. It removed official support for the bridge interface and announced the end of active sequencer-level security (SLS) analysis on the L2. These operating changes affect chain-dependent exits; Finance's Base-hosted accounting and redemption queue have separate dependencies.

The mainnet escape hatch addresses a prolonged absence of new L2 state outputs, subject to its activation conditions and proofs of eligible holdings. Escape eligibility concerns the age of the latest state output, not the age of a withdrawal request. A slow Finance redemption does not activate that mechanism. The escape tooling reconstructs holdings from the last relevant published state, so asset eligibility and proof construction constrain recovery.

The Legacy Testnet, deprecated in June 2025, used a shortened 5-day escape delay. Its Sepolia-specific configuration does not establish mainnet timing or asset coverage. Normal bridge exits rely on published state outputs; an emergency exit becomes applicable only when its inactivity and proof conditions hold.