Skip to main content

Depositing & Withdrawing

Providing and withdrawing liquidity happens through vault orders. You create an order that escrows your assets or shares in the trading contract, and a permissionless keeper fills it later, in full, in a single transaction. The fill happens at the share value holding at the moment the keeper executes, and the keeper's verified oracle price feeds directly into that value: the vault prices shares against its assets adjusted for the pending profit and loss of open positions at that price, marked conservatively against you (see Share Value below).

Depositing​

To provide liquidity you create a deposit vault order for an amount of the underlying token (e.g., USDC). At creation, that amount plus a small flat execution fee is escrowed inside the trading contract. The execution fee is a per-market parameter, paid in the settlement token: it goes to the keeper who fills the order and is refunded in full if you cancel. When a keeper fills the order, the vault mints shares to you: it takes the vault fill fee off the top, then converts what is left into shares at the fill-time share value, with the pending PnL of open positions marked against you.

For example, say you deposit 10,000 USDC and the vault fee on this fill is 0.1%. The fee comes to 10 USDC, leaving 9,990 USDC to convert. At a fill-time share value of 1.00 USDC per share, you receive 9,990 shares. If share value were instead 1.08 USDC per share, you would receive 9,990 / 1.08 = 9,250 shares.

A deposit must be at least the market's minimum size (min_deposit, a per-market parameter), checked when you create the order. The vault also enforces a maximum balance cap, so a fill that would push the vault above max_vault_balance is rejected until capacity frees up.

Redeeming​

To exit, you create a redeem vault order for a number of shares. There is no minimum beyond a positive number of shares. The shares are escrowed at creation, along with the same flat execution fee in the settlement token. When a keeper fills the order, the vault burns the shares and pays you the underlying assets net of the vault fill fee, valued at the fill-time share value with pending PnL marked against you.

You can cancel a resting vault order at any time before it fills, and cancelling refunds the escrowed assets (for a deposit) or shares (for a redeem) in full, along with the escrowed execution fee. The one exception is an emergency freeze, which halts cancels along with everything else.

Redeem Cooldown​

Deposits have no cooldown. A deposit order becomes fillable as soon as a keeper holds a verified price published after the order was created.

A redeem order must wait out redeem_lock seconds before a keeper can fill it. The cooldown runs from the order's creation time, and the lock length is a per-market parameter read at fill time, so a parameter change to redeem_lock also moves the deadline of orders already in the queue, in either direction.

Per-Order Minimum Received​

Every vault order carries an optional min_out bound that you set: the fewest shares you will accept for a deposit, or the fewest assets for a redeem, both measured net of the vault fill fee. A fill that would return less is rejected, so the order rests until the share value comes back within your tolerance or you cancel. Set it to zero to leave the order unbounded. This is your own slippage protection against the share value moving between submission and fill, distinct from the protocol's own gates described in Risks & Rewards.

Retired-Market Direct Redeem​

Once a market reaches the Retired status (its final, defunct state after wind-down), a redeem pays out immediately at creation, with no keeper, no cooldown, and no execution fee. Deposits are rejected in a Retired market. This gives liquidity providers a direct exit once the market has been fully wound down. For the full status lifecycle, see the trading documentation.

Share Value​

Share value starts from the vault's total assets divided by the total supply of shares. It moves when value settles into or out of the vault: fees, interest, and realized trader PnL. Continuing the earlier example, a vault holding 1,040,000 USDC against 1,000,000 shares is worth 1.04 USDC per share, and a 40,000 USDC trader loss settling into the vault lifts it to 1.08 USDC per share.

When a vault order fills, the conversion does not use that raw balance. It prices shares against the vault's effective backing: the asset balance minus the net unrealized PnL of the market's open positions, measured at the keeper's verified price. Unrealized trader profit is money the vault will owe when those positions close, so it is subtracted from the backing before your shares are priced. Unrealized trader losses are money the vault stands to collect, so they raise the effective backing above the raw balance. Say the vault above holds 1,040,000 USDC while open positions are collectively 40,000 USDC in profit. A fill prices shares at (1,040,000 - 40,000) / 1,000,000 = 1.00 USDC per share, not 1.04. If those positions were instead 60,000 USDC underwater, a fill would price shares at 1.10 USDC. Depositing or redeeming therefore always transacts at what the vault is really worth at that moment, with the open book counted.

The unrealized PnL is measured in the direction adverse to the order's owner. A deposit marks it at the price side that yields the highest defensible share value, so you cannot mint cheap shares just before pending trader losses settle in. A redeem marks it at the side that yields the lowest, and counts each side's unrealized profit only up to the protocol's per-side payout cap, the most the vault can actually be made to pay, so you cannot dodge a pending payout by leaving just before it lands. The small spread between the two marks accrues to shareholders who stay.

As the vault earns fees and borrowing interest, or absorbs trader losses, share value rises. When traders close in profit, the vault pays out and share value falls. For the protocol-level limits on pending trader PnL, see Risks & Rewards.