Skip to main content
Glama

ASPERN: counterparty checks for agents

What actually left a vault

vault_exits
Read-onlyIdempotent

SEND exitAmountUsd WITH THE POSITION YOU ARE WEIGHING and this answers whether that size has ever cleared here: the schema has carried it since 2026-10-08, and an auditor still had to find it by guessing because this sentence did not say so. Without it the answer still describes the capacity; with it, exitCapacity says covered-now, above-declared or unknown for your amount, and whether a single withdrawal that large has ever been recorded. Before putting capital somewhere, ask what has actually LEFT it. Every liquidity figure elsewhere is a level at an instant — how much could be withdrawn right now. This is the other half: withdrawals that SETTLED, over 7, 30 and 90 days, with the largest single exit we have ever recorded and the day it happened. Measured on the largest vault we read on 29 September 2026: $52.8M declared withdrawable against $265.8M actually withdrawn over thirty days, so a holder reading only the declared figure would badly underestimate what the vault has been able to pay. A LEVEL and a FLOW are never divided by one another and this returns no ratio between them. We see withdrawals that settled and NOT an attempt that reverted, a queue somebody waited in, or a gate that refused them. An empty register therefore has FOUR readings, not two: “nobody withdrew”, “nobody could”, “a reader asked and found nothing at all”, and “no reader has ever asked”. haveFlowHistory separates the first two from the last two and lastReadAt separates those — null there means nobody has ever looked, so the register is not a weak reading of the vault but the absence of one. haveFlowHistory separates the third from the first two, and where it is false every figure is NULL rather than zero. Every answer dates itself: capitalAsOf and declaredAsOf say when each level was read, flowsNewestAt how far our movement history reaches, and windowsEndAt the instant the windows count back from. For a capital decision the age of the record is part of the record. Free.

Input Schema

NameRequiredDescriptionDefault
slugYesThe vault’s slug, or its contract address — either resolves. Until 2026-10-08 this route was the one of eight that took the slug only, so an agent holding an address got a 404 here and a 200 everywhere else.
amountUsdNoThe same thing as `exitAmountUsd`, under the name the rest of this catalogue uses for a position. Send whichever you have; if both arrive, `exitAmountUsd` is the one read.
exitAmountUsdNoOPTIONAL, AND THE ANSWER IS USEFUL WITHOUT IT: send nothing and `exitCapacity` still describes the capacity — what the vault declares withdrawable right now, the largest single withdrawal ever recorded here, the basis and when it was read — with `amountUsd`, `now`, `everThisLarge` and `shareOfDeclared` null, because those are the three answers that need a position and NOBODY ASKED is not the same as nothing here. Send a position, in US dollars, e.g. 500000, and you get the verdict for THAT amount. Turns "can we READ the withdrawable figure" into "could I get THIS much back out". The verdict is deliberately named for what was observed rather than for a promise: `covered-now` means the amount is inside what the vault declares withdrawable AT THE MOMENT WE READ IT, and the answer carries when that was and what it cannot see — queues, notice periods, failed attempts, other holders leaving at the same time.

Output Schema

NameRequiredDescriptionDefault
metaNoHow 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.
saysYesWhat actually left, against what the vault advertises as withdrawable, in one sentence.
slugYesThe vault this register is for, read back so an answer cannot be attached to the wrong vault.
readByNoWhich reader last asked, e.g. `vault-flows`, `morpho-flows`, `solana-flows`.
tvlUsdNoWhat 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.
exitCapNoTHE 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.
windowsYesFLOWS 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.
warningsNoAnything the server wants a caller to know about THIS answer before acting on it. Empty is the normal case and is not a guarantee.
cannotSeeYesWhat this register structurally cannot contain, so an empty one is never read as an easy exit.
exitPhasesNoGETTING 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.
kaminoExitNoHOW 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.
lastReadAtNoWhen 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.
redemptionNoHOW 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.
resilienceNoHOW 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.
sharesLeftNoWHO 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.
capitalAsOfNoWhen `tvlUsd` was read. Same name and same column as `vault_check` uses.
readToBlockNoHow 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.
declaredAsOfNoWhen `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.
exitCapacityNoALWAYS 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.
queueWaitingNoHOW 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.
windowsEndAtYesThe 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.
flowsNewestAtNoThe newest movement of any kind we hold for this vault.
largestEverAtNoWhen `largestEverUsd` was taken out. An old date beside a large figure is the whole point: it says the exit was possible then, not now.
largestEverUsdNoSomebody actually got this much out, on `largestEverAt`. Evidence about the past, never a promise about now.
reconciliationNoCASH 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.
capacityRefusalNoWHY 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.
haveFlowHistoryYesWhether 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.
snapshotAlignmentNoWHICH 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.
venueWithdrawableNoWHAT 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.
settlementObservedNoWHAT 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.
flowsNewestAnywhereAtNoThe 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.
redemptionIntelligenceNoGETTING 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.
declaredWithdrawableUsdNoA LEVEL at this instant. Null where we cannot read it, which is not zero.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / exitCap / description
      Previous value: -"THE CONTRACT ASKED DIRECTLY, ON THE VAULTS THAT DECLARE NOTHING. Present only where `declaredWithdrawableUsd` is null, which is where 33 Concrete vaults holding $1.26bn and the ether.fi Liquid vaults sit: 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."New value: +"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."
  2. Changed1 schema field changed
    • addedOutput schema / properties / kaminoExit
      Added value: +{
      +  "description": "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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  3. Changed1 schema field changed
    • addedOutput schema / properties / resilience
      Added value: +{
      +  "description": "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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  4. Changed4 schema fields changed
    • changedOutput schema / properties / exitCapacity / description
      Previous value: -"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."New value: +"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."
    • removedOutput schema / properties / queueMovement
      Removed value: -{
      -  "description": "HOW THIS QUEUE MOVED SINCE THE PREVIOUS READING, which a single reading cannot say. `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 measured on 2026-10-18 this queue emits nothing when a request is filled, so the two cannot be told apart from the count. `unchanged` does NOT mean the same requests — arrivals and departures can cancel out. Null where the vault has no queue we have found.",
      -  "type": [
      -    "object",
      -    "null"
      -  ]
      -}
    • changedOutput schema / properties / queueWaiting / description
      Previous value: -"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."New value: +"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."
    • removedOutput schema / properties / reconciliationMatters
      Removed value: -{
      -  "description": "WHETHER THE DISAGREEMENT BETWEEN THIS VAULT’S TWO BOOKS MATTERS TO THE POSITION YOU NAMED. `material` is TRUE where the position sits inside the gap between them, 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 instead of ours.",
      -  "type": [
      -    "object",
      -    "null"
      -  ]
      -}
  5. Changed1 schema field changed
    • addedOutput schema / properties / settlementObserved
      Added value: +{
      +  "description": "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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  6. Changed1 schema field changed
    • addedOutput schema / properties / queueMovement
      Added value: +{
      +  "description": "HOW THIS QUEUE MOVED SINCE THE PREVIOUS READING, which a single reading cannot say. `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 measured on 2026-10-18 this queue emits nothing when a request is filled, so the two cannot be told apart from the count. `unchanged` does NOT mean the same requests — arrivals and departures can cancel out. Null where the vault has no queue we have found.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  7. Changed1 schema field changed
    • addedOutput schema / properties / reconciliationMatters
      Added value: +{
      +  "description": "WHETHER THE DISAGREEMENT BETWEEN THIS VAULT’S TWO BOOKS MATTERS TO THE POSITION YOU NAMED. `material` is TRUE where the position sits inside the gap between them, 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 instead of ours.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  8. Changed1 schema field changed
    • addedOutput schema / properties / snapshotAlignment
      Added value: +{
      +  "description": "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.",
      +  "type": "object"
      +}
  9. Changed1 schema field changed
    • addedInput schema / properties / amountUsd
      Added value: +{
      +  "description": "The same thing as `exitAmountUsd`, under the name the rest of this catalogue uses for a position. Send whichever you have; if both arrive, `exitAmountUsd` is the one read.",
      +  "type": "number"
      +}
  10. Changed1 schema field changed
    • addedOutput schema / properties / capacityRefusal
      Added value: +{
      +  "description": "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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  11. Changed1 schema field changed
    • addedOutput schema / properties / queueWaiting
      Added value: +{
      +  "description": "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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  12. Changed1 schema field changed
    • addedOutput schema / properties / reconciliation
      Added value: +{
      +  "description": "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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  13. Changed1 schema field changed
    • changedOutput schema / properties / exitCap / description
      Previous value: -"THE CONTRACT ASKED DIRECTLY, ON THE VAULTS THAT DECLARE NOTHING. Present only where `declaredWithdrawableUsd` is null, which is where 33 Concrete vaults holding $1.26bn and the ether.fi Liquid vaults sit: 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 — per owner, so asked about an address holding no shares it answers zero for every vault in existence, which is why it must never be asked of a stranger — and compare it with what that holder’s shares are worth. READ `verdict` BEFORE ANY NUMBER HERE. `capped` means the contract returned LESS than the holding, so something binds and `maxWithdrawUnits` is where it binds. `shut` means it returned zero to a holder who demonstrably has shares, which is a finding and not an absence. `echoes-balance` means it returned the holding itself: the selector carries NO liquidity cap, so the figure is arithmetic about that holder and not a reading of the vault, and we publish it as a refusal — `maxWithdrawUsd` is null and reading the units as withdrawable capacity would be wrong. `unanswered` is our silence, not the vault’s. `saysSomethingAboutExit` is the single boolean to gate on. 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."New value: +"THE CONTRACT ASKED DIRECTLY, ON THE VAULTS THAT DECLARE NOTHING. Present only where `declaredWithdrawableUsd` is null, which is where 33 Concrete vaults holding $1.26bn and the ether.fi Liquid vaults sit: 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."
  14. Changed2 schema fields changed
    • addedOutput schema / properties / exitCap
      Added value: +{
      +  "description": "THE CONTRACT ASKED DIRECTLY, ON THE VAULTS THAT DECLARE NOTHING. Present only where `declaredWithdrawableUsd` is null, which is where 33 Concrete vaults holding $1.26bn and the ether.fi Liquid vaults sit: 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 — per owner, so asked about an address holding no shares it answers zero for every vault in existence, which is why it must never be asked of a stranger — and compare it with what that holder’s shares are worth. READ `verdict` BEFORE ANY NUMBER HERE. `capped` means the contract returned LESS than the holding, so something binds and `maxWithdrawUnits` is where it binds. `shut` means it returned zero to a holder who demonstrably has shares, which is a finding and not an absence. `echoes-balance` means it returned the holding itself: the selector carries NO liquidity cap, so the figure is arithmetic about that holder and not a reading of the vault, and we publish it as a refusal — `maxWithdrawUsd` is null and reading the units as withdrawable capacity would be wrong. `unanswered` is our silence, not the vault’s. `saysSomethingAboutExit` is the single boolean to gate on. 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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / redemptionIntelligence
      Added value: +{
      +  "description": "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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  15. Changed1 schema field changed
    • addedOutput schema / properties / exitPhases
      Added value: +{
      +  "description": "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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  16. Changed1 schema field changed
    • changedOutput schema / properties / redemption / description
      Previous value: -"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) 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."New value: +"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."
  17. Changed4 schema fields changed
    • changedInput schema / properties / exitAmountUsd / description
      Previous value: -"OPTIONAL, AND THE ANSWER IS USEFUL WITHOUT IT: send nothing and `declaredWithdrawableUsd` is already the largest position this vault says it could cover right now, with `exitCapacity` null because there is no amount to weigh. Send a position, in US dollars, e.g. 500000, and you get the verdict for THAT amount. Turns \"can we READ the withdrawable figure\" into \"could I get THIS much back out\". The verdict is deliberately named for what was observed rather than for a promise: `covered-now` means the amount is inside what the vault declares withdrawable AT THE MOMENT WE READ IT, and the answer carries when that was and what it cannot see — queues, notice periods, failed attempts, other holders leaving at the same time."New value: +"OPTIONAL, AND THE ANSWER IS USEFUL WITHOUT IT: send nothing and `exitCapacity` still describes the capacity — what the vault declares withdrawable right now, the largest single withdrawal ever recorded here, the basis and when it was read — with `amountUsd`, `now`, `everThisLarge` and `shareOfDeclared` null, because those are the three answers that need a position and NOBODY ASKED is not the same as nothing here. Send a position, in US dollars, e.g. 500000, and you get the verdict for THAT amount. Turns \"can we READ the withdrawable figure\" into \"could I get THIS much back out\". The verdict is deliberately named for what was observed rather than for a promise: `covered-now` means the amount is inside what the vault declares withdrawable AT THE MOMENT WE READ IT, and the answer carries when that was and what it cannot see — queues, notice periods, failed attempts, other holders leaving at the same time."
    • changedOutput schema / properties / exitCapacity / description
      Previous value: -"Present ONLY where you sent `exitAmountUsd`, and null otherwise. `basis` names what the verdict 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. 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."New value: +"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."
    • addedOutput schema / properties / sharesLeft
      Added value: +{
      +  "description": "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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / venueWithdrawable
      Added value: +{
      +  "description": "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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  18. Changed7 schema fields changed
    • removedInput schema / exitAmountUsd
      Removed value: -{
      -  "description": "A position to weigh the exit against, in US dollars. Turns \"can we READ the withdrawable figure\" into \"could I get THIS much back out\", which the auditor who asked for it rightly called a different question.",
      -  "type": "number"
      -}
    • addedInput schema / properties / exitAmountUsd
      Added value: +{
      +  "description": "OPTIONAL, AND THE ANSWER IS USEFUL WITHOUT IT: send nothing and `declaredWithdrawableUsd` is already the largest position this vault says it could cover right now, with `exitCapacity` null because there is no amount to weigh. Send a position, in US dollars, e.g. 500000, and you get the verdict for THAT amount. Turns \"can we READ the withdrawable figure\" into \"could I get THIS much back out\". The verdict is deliberately named for what was observed rather than for a promise: `covered-now` means the amount is inside what the vault declares withdrawable AT THE MOMENT WE READ IT, and the answer carries when that was and what it cannot see — queues, notice periods, failed attempts, other holders leaving at the same time.",
      +  "type": "number"
      +}
    • changedOutput schema / properties / exitCapacity / description
      Previous value: -"Present ONLY where you sent `exitAmountUsd`, and null otherwise. 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."New value: +"Present ONLY where you sent `exitAmountUsd`, and null otherwise. `basis` names what the verdict 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. 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."
    • addedOutput schema / properties / meta
      Added value: +{
      +  "description": "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.",
      +  "type": "object"
      +}
    • addedOutput schema / properties / redemption
      Added value: +{
      +  "description": "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) 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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / warnings
      Added value: +{
      +  "description": "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.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedOutput schema / properties / windows / description
      Previous value: -"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."New value: +"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."
  19. Changed2 schema fields changed
    • addedInput schema / exitAmountUsd
      Added value: +{
      +  "description": "A position to weigh the exit against, in US dollars. Turns \"can we READ the withdrawable figure\" into \"could I get THIS much back out\", which the auditor who asked for it rightly called a different question.",
      +  "type": "number"
      +}
    • addedOutput schema / properties / exitCapacity
      Added value: +{
      +  "description": "Present ONLY where you sent `exitAmountUsd`, and null otherwise. 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.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  20. Changed11 schema fields changed
    • addedOutput schema / properties / capitalAsOf
      Added value: +{
      +  "description": "When `tvlUsd` was read. Same name and same column as `vault_check` uses.",
      +  "format": "date-time",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / declaredAsOf
      Added value: +{
      +  "description": "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.",
      +  "format": "date-time",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / flowsNewestAnywhereAt
      Added value: +{
      +  "description": "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.",
      +  "format": "date-time",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / flowsNewestAt
      Added value: +{
      +  "description": "The newest movement of any kind we hold for this vault.",
      +  "format": "date-time",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / haveFlowHistory
      Added value: +{
      +  "description": "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.",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / lastReadAt
      Added value: +{
      +  "description": "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.",
      +  "format": "date-time",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / readBy
      Added value: +{
      +  "description": "Which reader last asked, e.g. `vault-flows`, `morpho-flows`, `solana-flows`.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / readToBlock
      Added value: +{
      +  "description": "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.",
      +  "type": [
      +    "integer",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / windows / description
      Previous value: -"FLOWS over 7, 30 and 90 days: count, total, largest single, most recent. Never a share of the level."New value: +"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."
    • addedOutput schema / properties / windowsEndAt
      Added value: +{
      +  "description": "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.",
      +  "format": "date-time",
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "slug",
      -  "windows",
      -  "says",
      -  "cannotSee"
      -]New value: +[
      +  "slug",
      +  "windows",
      +  "says",
      +  "cannotSee",
      +  "windowsEndAt",
      +  "haveFlowHistory"
      +]
  21. Changed1 schema field changed
    • changedInput schema / properties / slug / description
      Previous value: -"The vault slug, as list_vaults and find_vaults return it."New value: +"The vault’s slug, or its contract address — either resolves. Until 2026-10-08 this route was the one of eight that took the slug only, so an agent holding an address got a 404 here and a 200 everywhere else."
  22. Changed5 schema fields changed
    • addedOutput schema / properties / largestEverAt / description
      Added value: +"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."
    • addedOutput schema / properties / largestEverAt / format
      Added value: +"date-time"
    • addedOutput schema / properties / says / description
      Added value: +"What actually left, against what the vault advertises as withdrawable, in one sentence."
    • addedOutput schema / properties / slug / description
      Added value: +"The vault this register is for, read back so an answer cannot be attached to the wrong vault."
    • addedOutput schema / properties / tvlUsd / description
      Added value: +"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."
  23. Added

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a safe read, so the description earns its keep by disclosing what is and is not counted: settled withdrawals only, never reverted attempts, queue waits or refusals, and NULL rather than zero when `haveFlowHistory` is false. It also flags the limits of the verdict — queues, notice periods, other holders leaving — and explains that every answer self-dates via `capitalAsOf`, `declaredAsOf`, `flowsNewestAt` and `windowsEndAt`.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It opens with an all-caps instruction about one parameter instead of stating what the tool returns, and it spends sentences on meta-narrative about a past documentation failure and an auditor 'guessing', plus a trailing 'Free.' The empty-register paragraph is self-contradictory, asserting that `haveFlowHistory` separates 'the first two from the last two' and then 'the third from the first two', which muddies the one thing it needed to make crisp.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter read whose output schema already documents return fields, this covers the hard parts well: null-vs-zero semantics, the level/flow non-division rule, measurement boundaries and record age. The internal inconsistency in the `haveFlowHistory` passage is the main completeness defect, since it leaves the four-way reading of an empty register ambiguous.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description pushes past it by explaining that omitting the amount yields the capacity reading with `amountUsd`, `now`, `everThisLarge` and `shareOfDeclared` null, and by unpacking the verdict vocabulary (`covered-now`, `above-declared`, `unknown`) in terms of what was observed versus promised. The `amountUsd` vs `exitAmountUsd` precedence rule largely repeats the schema rather than adding to it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource: withdrawals that SETTLED over 7/30/90 days, plus the largest single exit and its date. It explicitly contrasts itself with 'every liquidity figure elsewhere is a level at an instant', so an agent can tell it apart from the level/coverage siblings without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Before putting capital somewhere, ask what has actually LEFT it' gives a concrete decision context, and 'SEND `exitAmountUsd` WITH THE POSITION YOU ARE WEIGHING' tells the agent how to upgrade the call. It never names an alternative tool (exit_screen, simulate_withdrawal, vault_exit_confidence) nor states when NOT to use it, so routing to a sibling is still left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources