> For the complete documentation index, see [llms.txt](https://qiro.gitbook.io/qiro-vaults/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://qiro.gitbook.io/qiro-vaults/stakeholders/investors/redemptions.md).

# Redemptions

How to exit a vault: request, servicing, and claiming.

Exiting a vault takes three steps: you **request**, a servicer **services** the queue, and you **claim**. The vault follows ERC-7540 for asynchronous redemptions.

Serviced assets wait for you to collect them; they do not arrive automatically.

### Step 1: Request

```solidity
requestRedeem(shares, controller, owner)
```

Your shares are transferred into the Redemption Manager, which holds them while the request is outstanding, and you receive a `requestId`.

`owner` is the address the shares come from. `controller` is the address entitled to manage and later claim the request, usually the same address, though they can differ for custodial or contract-held positions.

Three limits apply at this step:

* A minimum request size, set per vault, which keeps dust out of the queue.
* A cap on how many requests a single owner may have active at once.
* A cap on how many a single controller may have active at once.

The owner's address must be verified, and the vault must be unpaused.

### Step 2: Servicing

A servicer processes the queue in submission order. This is an operator action and requires nothing from you.

When your request is reached, its shares are burned and converted to assets at the **conservative** valuation prevailing at that moment. Your request then holds a claimable balance.

Requests can be filled across more than one round. Where that happens, your request holds a pending balance and a claimable balance at the same time, and the pending balance keeps its place at the front of the queue.

Servicing runs against a target of 7 days from request, set per vault. It is a commitment by the curator, not a timer enforced by the contracts, and follows the rate at which deployed capital returns to the vault.

### Step 3: Claim

```solidity
redeem(shares, receiver, controller)     // claim by share amount
withdraw(assets, receiver, controller)   // claim by asset amount
```

Either call moves your assets from the vault to the `receiver` address you name. You can claim as soon as a balance becomes claimable, including a partial fill.

Claiming stays available while the vault is paused, and to an address that has been removed from the whitelist.

### Cancelling

A request that has not been serviced can be cancelled, returning the shares held against it. Where a request has been partially serviced, cancelling returns the pending shares and pays out the claimable assets.

You name where each goes:

```solidity
cancelRequest(requestId, sharesReceiver, assetsReceiver)
```

The vault owner can also cancel a request administratively, for example where an investor's compliance status has changed.

### Delegating to an operator

You can authorise another address to act for you:

```solidity
setOperator(operator, approved)
```

An approved operator can request, claim, and cancel on your behalf as controller, which is useful for custodial arrangements and contract-held positions.

You can also pre-set where shares and assets should go, so proceeds route correctly without naming them on each call:

```solidity
setSharesAndAssetsReceiver(controller, sharesReceiver, assetsReceiver)
```

***

See [Monitoring Your Position](/qiro-vaults/stakeholders/investors/monitoring-your-position.md) for tracking a live request.