How much of the way out we can see
exit_lifecycle_coverageHOW MUCH OF THE WAY OUT WE CAN SEE, phase by phase, across every open vault. Getting out has four phases — a request filed, something set aside to claim, money that actually left, and an attempt that failed — and we read THREE. The fourth is on this answer anyway, with its reason: no vault state records a redemption somebody attempted and could not complete, so reading it needs every transaction sent to each contract and its receipt, and a zero there would be the most misleading figure available because it would say nobody was turned away. FOUR STATES PER PHASE and never collapsed into "missing", because two of them look identical and are not: exempt is a phase that CANNOT exist (a synchronous redeem settles in the transaction that asks, so nothing is ever filed and nothing is ever set aside) and subjectRefuses is a phase that EXISTS while the contract will not expose it (an ERC-7540 vault carrying neither standard getter — the holder is in that phase and cannot be told what became of their request). Only unread is work of ours. THERE IS NO SINGLE LIFECYCLE PERCENTAGE: the phases have different denominators, so averaging them would give a number no phase is answerable for. Free, because it is a statement about our own reach.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | How current this answer is and what it was read from: `freshness` and the ages behind it. Present on every answer from this server, whatever the tool. | |
| says | Yes | How many phases we can read, which is thinnest, and why there is no single lifecycle number. | |
| phases | Yes | One per phase, in the order a depositor meets them: `key`, `label`, then `read`, `exempt`, `subjectRefuses` and `unread` each as {vaults, tvlUsd}. `readNoSizeRead` counts the vaults with the reading whose SIZE is unread, and where it equals `read.vaults` the capital share is NULL rather than 0 — the reading covers vaults we cannot weigh rather than vaults that are small, and a 0% would say the opposite; measured on the day this shipped, all 349 vaults whose filed requests we can read were in exactly that state. `byCountApplicable` and `byCapitalApplicable` divide by what the phase COULD exist for, the total less the exempt, and are NULL for a phase we do not read at all rather than 0% — a zero would read as a failure to try instead of a reading nobody can take. `unreadableBecause` is set only on such a phase and says why. `says` gives the four states in prose. | |
| warnings | No | Anything the server wants a caller to know about THIS answer before acting on it. Empty is the normal case and is not a guarantee. | |
| cannotSee | Yes | What no figure here reaches, including who is in a queue as opposed to how much is in it. | |
| measuredAt | Yes | When these counts were taken. The readings behind them were taken earlier: each phase comes from a reader with its own cadence, so this says when they were COUNTED and never when the chain was read. | |
| tvlTotalUsd | No | Capital across them, in US dollars. | |
| vaultsTotal | Yes | Open vaults, the widest denominator. Each phase states its own narrower one. |