> 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/monitoring-your-position.md).

# Monitoring Your Position

What you can see about your position, and where to find it.

Your position is a share balance and a share price. The balance is what you hold; the price is what each share is worth, and it is where yield appears.

### What your position consists of

**Your share balance.** It changes when you deposit, redeem, or transfer. Requesting a redemption also moves shares out of your wallet and into the Redemption Manager, so the balance reflects that transfer from the moment you request rather than when the request is serviced. Until the request is serviced or cancelled, those shares are represented by the request.

**The share price.** What one share is worth in the underlying asset. Deposit 500,000 USDC at a share price of 1.00 and you hold 500,000 shares, worth 525,000 USDC once the price reaches 1.05. The price moves with the performance of the vault's facilities.

The vault publishes two share prices, because each side of the trade prices differently: deposits at the optimistic valuation, redemptions at the conservative one. Both are reported to 18 decimals, whatever the underlying stablecoin's own decimals are. See [NAV & Valuation](/qiro-vaults/core-concepts/nav-and-valuation.md).

**Your redemption requests.** Each request carries a pending balance, a claimable balance, or both at once. Tracking them is covered below.

### What the vault publishes

Shown on the vault's page in the app, and readable directly from the vault contract.

| What                   | Getter                     | Meaning                                                                                                                                                                         |
| ---------------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Total assets           | `totalAssets()`            | The vault's optimistic NAV: idle cash plus the value of deployed capital including interest earned so far, less fees and less assets already set aside for serviced redemptions |
| Share price (deposits) | `sharePriceOptimistic()`   | What one share is worth on the optimistic valuation. What deposits and mints price at                                                                                           |
| Share price (exits)    | `sharePriceConservative()` | What one share is worth on the conservative valuation. What the queue converts shares at when your request is serviced                                                          |
| Allocated assets       | `allocatedAssets()`        | The conservative value of capital deployed to credit positions. It follows the curator's mark and updates as the facilities perform                                             |
| Idle cash              | `cashBalance()`            | Stablecoins the vault is free to deploy. It excludes assets already set aside for serviced redemption claims, and fees accrued but uncollected                                  |

### Tracking a redemption

When you submit a request you receive a **request ID**. The Redemption Manager lists every ID you hold:

```solidity
getRequestIdsByController(controller)
```

Two counters give your place in the queue: `requestCounter()`, the total number of requests ever created, and `lastServicedRequestId()`, the ID of the last one serviced. The gap between your ID and the last serviced one is how many sit ahead of you, as an upper bound, since cancelled requests keep their IDs but no longer need servicing.

Each request carries three figures:

| Figure                                    | Getter                                             |
| ----------------------------------------- | -------------------------------------------------- |
| Shares still pending                      | `pendingRedeemRequest(requestId, controller)`      |
| Shares already serviced                   | `claimableRedeemRequest(requestId, controller)`    |
| Assets those serviced shares converted to | `claimableAssetsForRequest(requestId, controller)` |

Pending and serviced can both be non-zero at once, because a large request may be filled across more than one round.

All three take a request ID. Passing `0` instead of an ID returns your total across every request rather than the figure for one. The first two are readable on the vault, which forwards them; all three are readable on the Redemption Manager directly, whose address the vault publishes as `REDEMPTION_MANAGER`.

**Your claimable assets** is what you can withdraw today. `maxWithdraw(controller)` and `maxRedeem(controller)` report the same ceiling in assets and in shares. Neither is affected by a pause: once a request has been serviced, the assets stay claimable.

Where you hold several requests at once, a claim draws on your oldest claimable request first and works forward, so a partial claim empties the earliest before it touches any later one.

***

See [NAV & Valuation](/qiro-vaults/core-concepts/nav-and-valuation.md) for how the share price is determined, and [Redemptions](/qiro-vaults/stakeholders/investors/redemptions.md) for the exit process itself.