| 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 | What actually left, against what the vault advertises as withdrawable, in one sentence. | |
| slug | Yes | The vault this register is for, read back so an answer cannot be attached to the wrong vault. | |
| readBy | No | Which reader last asked, e.g. `vault-flows`, `morpho-flows`, `solana-flows`. | |
| tvlUsd | No | What the vault holds, for scale beside the withdrawals. A LEVEL, never to be divided into the flow figures in `windows`. Null means unread, not empty. | |
| exitCap | No | THE CONTRACT ASKED DIRECTLY, ON THE VAULTS THAT DECLARE NOTHING. Present only where `declaredWithdrawableUsd` is null, which is where, on 26 October 2026, 33 Concrete vaults holding $1.26bn and the ether.fi Liquid vaults sat: a strategy vault deploys its capital rather than holding it, so there is no free balance to read and the venue publishes no withdrawable figure. We call `maxWithdraw` on the LARGEST HOLDER WE KNOW — it is per owner, so asked about an address holding no shares it answers zero for every vault in existence — and compare it with what that holder’s shares are worth. READ `verdict` AND `mechanic` BEFORE ANY NUMBER HERE, because ONE SELECTOR ANSWERS TWO DIFFERENT QUESTIONS. On a SYNCHRONOUS vault `maxWithdraw` is capacity: `capped` means it returned LESS than the holding, so something binds and `maxWithdrawUnits` is where; `shut` means it returned zero to a holder who demonstrably has shares, which is a finding; `echoes-balance` means it returned the holding itself, so the selector carries NO liquidity cap and the figure is arithmetic about that holder rather than a reading of the vault, published as a refusal with `maxWithdrawUsd` null. On an ASYNCHRONOUS vault (ERC-7540, request-and-claim, request-via-queue) the SAME selector reports the CLAIMABLE amount from an already settled request instead: `claimable` means that much is set aside for that one holder, and `nothing-claimable` is zero, which is the ORDINARY STATE of somebody who has not asked to leave and says nothing whatever about whether they could. An earlier pass of this reader applied the synchronous meaning everywhere and called 53 vaults shut, among them Lagoon vaults holding $23.3m and $9.6m; that was our error and the verdict now depends on the mechanic. `mechanic-unread` means we could not establish which of the two questions was answered and are claiming neither. `saysSomethingAboutExit` is the single boolean to gate on and it is true for `capped` and `shut` only. It is ONE HOLDER at ONE BLOCK, never a vault-wide total and never a promise; `raw` carries the three words so the verdict can be re-derived rather than believed. | |
| windows | Yes | FLOWS over 7, 30 and 90 days plus all time: count, total, largest single, most recent. Never a share of the level. Every figure is NULL where `haveFlowHistory` is false, because a zero would claim we looked. Each window carries `window` as well as `days`: `7d`, `30d`, `90d` or `allTime`. `days: 0` is the all-time one and reads as a zero-day window if you only look at the number, which is why the name is there. | |
| 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 this register structurally cannot contain, so an empty one is never read as an easy exit. | |
| exitPhases | No | GETTING OUT HAS THREE STEPS AND THEY ARE NOT THE SAME EVENT: a request FILED, an amount set aside to be CLAIMED, and a withdrawal SETTLED. Each carries its own `basis` and its own refusal. `filed` reads `queue-requests` where the vault leaves through a separate queue - a FLOOR, since a request whose only event predates our window is open and unseen - or `share-burns` where it is read from the token being burned. `claimable` IS USUALLY UNREADABLE AND THAT IS THE FINDING: where a vault takes a request and carries neither ERC-7540 getter, nothing can be seen of the middle step at all and a zero there would be an answer we did not read; where both getters exist it is readable one holder at a time and NO TOTAL is published, because summing a per-holder getter across holders we do not enumerate is a figure nobody could check; a synchronous vault has no middle step to begin with. `settled` is money that LEFT, over the register’s own window, not money that was promised. | |
| kaminoExit | No | HOW MUCH OF A KAMINO STRATEGY CAN LEAVE TODAY, read from its position and its pool rather than assumed from its size. `measured` false carries `refused`, the reason (a Meteora pool, whose bin layout is not decoded, or an account that did not answer). Measured, `share` is the part that can leave today: the position’s tokens are checked to be in the pool’s own vaults, and the strategy’s daily withdrawal cap per token is applied, so `boundBy` is `withdrawal-cap` where the cap is tighter than the holding. `withdrawableUsd` is the size times that share, less the exit fee, and is the figure the vault’s withdrawable column carries. Null for every vault that is not a Kamino strategy. | |
| lastReadAt | No | When a reader last ASKED about this vault, found or not — which `flowsNewestAt` cannot tell you. Eighteen withdrawals with the newest eleven months ago is a vault that went quiet OR a vault we stopped reading, and only this separates them. NULL MEANS NO READER HAS EVER ASKED: the vault is outside what our flow readers cover, so an empty register is not a weak reading of it, it is the absence of one. | |
| redemption | No | HOW a holder gets out, read from the contract, and the question no liquidity figure answers. `mechanic` is `synchronous`, `request-and-claim` (ERC-7540: you ask and are paid when the vault settles it), `request-via-queue` (the vault takes deposits and carries no exit: you approve a SEPARATE queue contract and file a request there for somebody else to fill) or `unread`. `paused` is the contract’s own switch. `hours` is a notice period the contract STATES, null where it states none, which is NOT zero. Same object and same wording as `vault_check` returns. | |
| resilience | No | HOW THE WAY OUT HELD UP, WHICH IS THE ONLY FIGURE HERE ABOUT A PERIOD. Every other exit reading on this answer is a LEVEL at an instant: how much could be withdrawn now. This is whether that level has BEEN there. `state` is `read`, `too-short` or `nothing-to-read`, and TODAY IT IS `too-short` ON EVERY VAULT: the daily series began on 2026-10-16 and is about six days deep, so `days` says how many we hold and `daysShort` how many more before this answers. It opens by itself as the series grows and needs no release. Thirty days because the windows on this same answer are 7, 30 and 90, and because a worst day out of six reads as though it were the worst of a quarter. Where it is `read`, `worstShare` is the LOWEST daily share of capital that could have left and `medianShare` the middle day, never an average, and a day whose share reads outside 0 to 1 is dropped rather than averaged in. `coveredDays` is null unless a position was named, which is NOT zero. Every figure is what the venue declared that day and never a test of whether it would have paid. | |
| sharesLeft | No | WHO LEFT, WHERE OUR FLOW REGISTER CANNOT SEE IT, read from the chain. A `Flow` row is written when a reader recognises a venue’s withdrawal, and some venues pay out by BURNING the holder’s shares and emitting nothing we recognise — one $14M vault had 885.30 shares leave in sixty days while the register held six deposits and not one exit. A share burned is a holder leaving, because nothing else destroys supply. `burns` and `shares` are the exits that settled, `shareOfSupply` scales them against what the vault holds in shares TODAY (so it is a scale, not a rate: the two are of different moments). `filed` is requests to leave read in the same window, NULL where the vault has no queue to file one in rather than zero. `oldestWaitingDays` is how long the front of the queue has waited with no payout behind it and `medianSettlementDays` how long a wait that ended actually took — both under ONE assumption which `assumes` states: requests settle in the order filed and one payout settles one. Both are FLOORS, because a request filed before the window is older than this can see. NO DOLLAR FIGURE on purpose: pricing a burn needs the share price at that block and the asset’s price at that moment, and a number built from two interpolations would be the most confident thing in the answer. Published BESIDE the register and never summed into it. | |
| capitalAsOf | No | When `tvlUsd` was read. Same name and same column as `vault_check` uses. | |
| readToBlock | No | How far through the chain that pass actually got. Not the same as `lastReadAt`: a reader that ran a minute ago but is 400,000 blocks behind looked recently at an old part of the chain, and only this says so. Null where the reader has no block to report. | |
| declaredAsOf | No | When `declaredWithdrawableUsd` was read. NULL means we hold no stamp for it rather than that it is fresh — 180 of the 809 declared levels we hold come from a writer that does not stamp them. | |
| exitCapacity | No | ALWAYS PRESENT for a vault we hold. `basis` names what it rests on: `observed-liquidity` means a figure the VENUE declared and we read at `declaredAsOf`, and nothing else — it is not a promise, not a test of whether the vault would pay, and not a reading of any queue. WITHOUT `exitAmountUsd` it is the capacity alone: `declaredWithdrawableUsd` and `largestEverUsd`, with `amountUsd`, `now`, `everThisLarge` and `shareOfDeclared` all null because no position was named. WITH one, those four answer the fit. TWO READINGS, NEVER AVERAGED: `now` is `covered-now`, `above-declared` or `unknown` against what the vault declares withdrawable at this instant — THEIR figure, an instant and not a promise, and not a queue or a notice period; `everThisLarge` is whether a single withdrawal at least that size has ever been recorded here, and it is NULL rather than false where we hold no flow history, because never having seen one is not evidence it cannot happen. `shareOfDeclared` is the position as a share of that declared figure, null where there is nothing to divide by. `cannotSee` names what no withdrawable figure contains: queues, notice periods, failed attempts, and other holders leaving at the same moment as you. WHETHER THAT DISAGREEMENT MATTERS TO YOUR POSITION is on `exitCapacity.reconciliationMatters`, nested here and NOT a top-level field: `material` is TRUE where the position you named sits inside the gap between this vault’s two books, so which reading is right decides whether it clears; FALSE where the gap is too small to move it either way; NULL where no amount was sent or the vault declares no capacity to measure one against, and null is NOT a pass. Computed from the amount actually asked about, never a constant: Euler evUSD’s books differ by $14,381, which cannot change a $50 withdrawal and entirely decides one sitting $1,000 under the declared figure. The figures themselves are on `reconciliation`, so a caller can apply its own tolerance. | |
| queueWaiting | No | HOW LONG THE PEOPLE ALREADY IN THE QUEUE HAVE BEEN THERE, where the vault is left through an AtomicQueue. `openRequests`, `holders`, `oldestWaitingDays`, `medianWaitingDays`, `oldestFiledAt`, `boundedByWindow`, `basis: open-requests-age`. THIS IS NOT A SETTLEMENT TIME AND THERE IS NONE TO HAVE: measured 2026-10-18, the queue emits AtomicRequestUpdated and nothing else over 150,000 blocks, and of 190 request triples only 4 ever reached zero — every one a cancellation with no token reaching the user. A fill leaves no event at this contract, so "how long does a request take" cannot be answered and is not. What this answers is the question a depositor is actually standing in front of: how long the holders ahead of them have ALREADY waited. Every figure is a FLOOR, because those holders are still waiting. `boundedByWindow: true` means `oldestWaitingDays` sits against the 90-day log sweep rather than against the queue, so a request filed before it is invisible and the true longest wait may be far longer — never quote a bounded figure as the longest anybody has waited. Null where the vault has no queue we have found, which is not a vault with no queue. HOW THE QUEUE MOVED SINCE THE PREVIOUS READING is on `queueWaiting.movement`, nested here and NOT a top-level field, because one reading cannot say it: `direction` is `clearing`, `growing`, `unchanged` or `first-reading`, `changed` is the difference in open requests and `overHours` the window. IT IS NOT A SETTLEMENT TIME AND MUST NOT BE QUOTED AS ONE: a request that leaves was filled OR cancelled, and this queue emits nothing when one is filled, so the two cannot be told apart from the count. `unchanged` does NOT mean the same requests, since arrivals and departures can cancel out. Null until a second reading exists to compare against. | |
| windowsEndAt | Yes | The instant every window counts back from, so the 7-day and 30-day figures share an edge and either can be reproduced. It is a window boundary and NOT a freshness claim: the ages of the data are `capitalAsOf`, `declaredAsOf` and `flowsNewestAt`, and `meta.freshness` is computed from those. | |
| flowsNewestAt | No | The newest movement of any kind we hold for this vault. | |
| largestEverAt | No | When `largestEverUsd` was taken out. An old date beside a large figure is the whole point: it says the exit was possible then, not now. | |
| largestEverUsd | No | Somebody actually got this much out, on `largestEverAt`. Evidence about the past, never a promise about now. | |
| reconciliation | No | CASH AGAINST THE BOOKS, AND THE TWO CLOCKS THEY WERE READ ON. `idleUsd` (what is not lent out) and `tvlUsd` (what a depositor has) are written by DIFFERENT JOBS ON DIFFERENT CADENCES, and on 56 open vaults the first reads higher than the second. READ `safeAsCapacity` BEFORE ANY EXIT SHARE ON THIS VAULT: false means a figure built from this pair is arithmetic and not a reading of what could leave, however it is worded elsewhere. `verdict` says which case it is: `consistent` (cash inside the books), `within-rounding` (over by under a hundredth of a point, which is float noise on two sums), `stamps-apart` (over, and the two readings are far enough apart for a deposit or a withdrawal to sit between them — a gap in OUR clocks, not a finding about the vault), `unexplained` (over by more than rounding with no gap in time to account for it), `unreadable` (we hold one figure or neither). `differenceUsd` and `differenceShare` are published UNCLAMPED: a share over one hundred per cent is not a vault that would pay you more than it holds, and rounding an impossible number into a plausible one is the worst of the three available outcomes. `stampsApartMinutes` is how far apart the two readings were, null where we do not hold both. | |
| capacityRefusal | No | WHY THERE IS NO CAPACITY FIGURE, WHERE THERE IS NONE, and the one field to read before concluding we have a gap. Null wherever capacity IS readable: a declared figure, a `capped` reading or a `shut` door are findings, not absences. Measured over $2.4bn of open vaults with no withdrawable figure, that one blank was FIVE different readings, and `whose` separates them. `the-contract` means the answer does not exist to be read: asking again, or writing another adapter, returns the same thing. `ours` means we have not established it and the work is ours. `neither` means the exit IS read and is simply not on this contract, so nothing is missing at all. `reason` is the specific one. `selector-carries-no-cap`: `maxWithdraw` returned the holder’s whole holding, so no liquidity cap is inside the answer (60 vaults / $391.2M, plus the Concrete group below). `exit-is-not-on-this-contract`: a BoringVault takes deposits through a teller and pays exits through a SEPARATE queue, so the ERC-4626 selector does not exist here and its silence is not a finding (4 vaults / $443.5M, ether.fi Liquid and Veda) — `lookInstead` names the fields on this same answer that do carry it. `a-different-question`: on an async vault the selector reports what a settled request set aside, and zero is the ordinary state of somebody who has not asked to leave (57 vaults / $114.1M). `asked-and-established-nothing` and `never-asked` are both OURS. `postedValue` IS THE STRONGEST READING ON THIS ANSWER and travels independently of `reason`: where the strategy walk ended in `attested-accounting`, the contract the vault deploys into does not derive what it is worth from what it holds — a party POSTS the figure, and `postedBy`, `lastPostedAt`, `validForSeconds` and `expired` are the limits on the POSTING rather than checks on the number. `selectorReturnedThePosting` is TRUE only where what `maxWithdraw` answered IS that posted figure to within rounding, which is verified on 4 of the 8 attested vaults including the $740.3M one, where the two integers agree byte for byte: what a reader would take for exit capacity there is the number one party entered, converted into shares and back. IT IS NEVER FALSE. A figure that does not match may be the strategy’s own decimals or a vault deploying into several strategies while the accounting describes one, so a non-match is OUR uncertainty and is published as null rather than put in the vault’s mouth. `holdsAnyAssetItself` is false where every unit of the vault’s capital is deployed away from it. | |
| haveFlowHistory | Yes | Whether we hold ANY movement for this vault, of either direction. FALSE means the empty register is our silence and not the vault’s: it says nothing about whether anybody got out. Of 3,672 open vaults on 2026-10-10, 2,673 are in this state. | |
| snapshotAlignment | No | WHICH MOMENT EACH FIGURE HERE CAME FROM. `verdict` is `one-moment`, `minutes-apart`, `hours-apart`, `days-apart` or `unknown`; `parts` names each figure beside its stamp; `oldestPart` is the one to look at and `spanMinutes` the gap. An auditor read this vault’s capital as two different figures minutes apart and could not tell which was right — both were, and the capital had moved 0.016% between the calls. NOTHING HERE IS A NEW READING: every stamp already travels under its own key. A part with NO stamp makes the verdict `unknown` and stays in the list, because an absence must never read as agreement. | |
| venueWithdrawable | No | WHAT THE VENUE’S OWN ACCOUNTING SAYS ABOUT FREE LIQUIDITY, AGAINST OURS. Null where no venue API has been read for this vault. `theirShare` and `ourShare` are both shares of the vault, never dollars — ours is derived in dollars and theirs is in asset units, and converting one would put a third party’s price into a comparison of two first-party readings. `agreement` is `agrees` (within a tenth of each other), `ours-is-higher`, `ours-is-lower` or `not-compared`, and a missing reading is NEVER an agreement. Measured on the first pass over Morpho V2: 112 vaults agree, and on 87 holding $1.73bn ours is on average 40.7 percentage points HIGHER than the vault’s own figure — read the lower one before planning an exit. `timelockSeconds` is a notice period the VENUE states, which is a different kind of evidence from the one our own contract walk measures and is reported as theirs. | |
| settlementObserved | No | WHAT WE WATCHED HAPPEN WHEN HOLDERS LEFT, and NOT a redemption mechanic. In the withdrawals we opened on chain, `paidInSameTransaction` counts the ones where the holder received another token in the very transaction that burned their shares, and `burnedWithoutPayout` the ones where nothing reached them there. `examined` is the denominator. THIS IS WEAKER THAN READING THE PROGRAM and is published as such: a program can settle this way a thousand times and queue the next one, so nothing here may be read as `synchronous`. The strategy account’s own terms are on `kaminoStrategy` beside it and carry no mechanic deliberately, because that account does not state one. Null where no withdrawal has been examined, which is our reach rather than a vault nobody leaves. | |
| flowsNewestAnywhereAt | No | The newest movement we hold for ANY vault. Read beside the field above it tells a quiet vault from a stopped reader, which is what every zero here turns on. | |
| redemptionIntelligence | No | GETTING OUT, AS ONE ORDERED THING. The same readings as the sibling blocks, composed in the order a depositor meets them and computing nothing of its own, so it cannot disagree with them: mechanism (how leaving works here at all), capacity (whether there is anything to leave with), filed (whether a request has to be made and who is ahead of you), claimable (whether what is owed has been set aside), settled (whether anybody has actually been paid). START HERE and read the parts for detail. Each step carries `applies`, `readable`, `basis`, `reading`, `usd` and `says`, and the two flags are NOT the same thing: `applies: false` means the step does not exist on this vault at all — a synchronous redemption settles in the transaction that asks for it, so there is no request and nothing is ever set aside — while `readable: false` on a step that applies is a gap in OUR reading or the contract’s silence. `weakestLink` names the first step that exists here and that we cannot see, and is the single most useful field on this answer: a chain is only as good as its first unreadable step, and every step after it is conditional on something we could not establish. `readableSteps` of `applicableSteps` says how much of the sequence we have. | |
| declaredWithdrawableUsd | No | A LEVEL at this instant. Null where we cannot read it, which is not zero. | |