Three pools were asked about and one of them has an APY. The LP pool has capital at risk, so a return on capital is the right question for it. The treasury is paid a fee against no capital of its own and the insurance fund fills toward a target and then stops — neither has a yield, and both say so below rather than showing a blank.
How busy the pool is assumed to bethe one control, and the ladder it is chosen from
What that occupancy is, and what it impliesmeasurement · realised.ts::RealisedWindow.utilised — the time-integral of required_reserve over the 146 real closes — divided by what the pool can reserve at once
The venue really did run at 0.07% of its slots for the 9,855 minutes those trades were live. It is a measurement of a BURST, not of demand: those were the founder's own test trades, opened deliberately and several closed early to free slots. Nothing says a day looks like this.
Modelledfrom the program's own parameters, settled by the engine
The LP poolthe only one of the three with capital for a return to be on
The band above is over LUCK, not over the assumption. It is the 10% and 90% percentiles of how this book could fall at a FIXED demand. The demand itself is the control at the top of this page, and its range is the whole ladder — from 0.1% to 90.0% occupancy, which moves this rate by more than an order of magnitude. ADR-0018 §1 settled the shape of this disclosure before it was a rendering question: the honest object here is a range, so the honest disclosure is a range, and ADR-0023 row 3 makes it a precondition of outside money.
Earnings raise lp_assets and the share price with it, so an LP dollar does compound here. What the compounded figure additionally assumes is the SAME DAILY FLOW against the larger pool. At 0.0672 % utilisation this pool is not capacity-bound, so a pool grown by its own earnings would earn the same dollars on a bigger base and the true rate would fall. Read the APR as the floor of the two and the APY as the ceiling.
All three poolseach answered in the shape its balance sheet has
| Pool | Points of stake | Per trade | Per day | APR | APY | Why it does or does not have one |
|---|---|---|---|---|---|---|
| LP pool | 6.4042 | $0.016010 | $0.0620 | NOT OBSERVABLE — The only one of the three with capital at risk, so the only one an APY is the right question for. It is the counterparty on every trade: it keeps the barrier or it pays the rung. per dollar of the $420.00 pool, and per dollar of the $0.28 of it reserved against open positions on average — 0.0672 % of the pool at this demand | NOT OBSERVABLE — The only one of the three with capital at risk, so the only one an APY is the right question for. It is the counterparty on every trade: it keeps the barrier or it pays the rung. per dollar of the $420.00 pool, and per dollar of the $0.28 of it reserved against open positions on average — 0.0672 % of the pool at this demand | The only one of the three with capital at risk, so the only one an APY is the right question for. It is the counterparty on every trade: it keeps the barrier or it pays the rung. per dollar of the $420.00 pool, and per dollar of the $0.28 of it reserved against open positions on average — 0.0672 % of the pool at this demand |
| Protocol treasury | 3.9490 | $0.009872 | $0.0382 | none | none | NO APY, and the absence is structural. The treasury takes an entry leg and an exit leg on every trade whoever wins, against no capital of its own — so there is nothing for a return to be a return ON. Its honest figures are revenue per trade and revenue per day, both below, and both net of nothing: NONE. The treasury deploys no capital: it is paid an entry-fee leg and an exit-fee leg on every trade whoever wins, so there is nothing at risk for a return to be ON. Dividing its revenue by the LP pool would quote somebody else's capital as the treasury's base. |
| Insurance fund | 1.0508 | $0.002627 | $0.0101 | none | none | NO APY, and asking for one is a category error rather than a hard measurement. Nobody deposits and nobody withdraws a yield, it earns ONLY when a trader loses, and it stops at 1000 bps of the pool — after which Vault::accrue_insurance credits nothing and the whole insurance leg overflows to the LPs. A percentage that goes to zero on reaching a target is describing a fill, not a yield. At this demand it fills in 4126.7 days from empty. |
none in a rate column is not a missing measurement. It is the answer: the treasury deploys no capital and the insurance fund is a fill with an end rather than a rate that continues. Raise the occupancy and a hatched cell becomes a number; these two never will.
Realised146 mainnet closes · live · archive tail slot 442145572, 2026-08-27T16:47:05.000Z
The comparison is withheldnot approximated
7 of 146 settled closes carry a rung this model cannot price (100x). The program admits any multiple at or above 2.00x; the projection prices only 2x, 3x, 5x, 10x. The realised column measures every close, so modelling a subset and subtracting would compare two different populations. The comparison is withheld rather than approximated.
Nothing measured is in doubt. The realised take is chain integers and does not depend on the model at all — it is withheld here only because this panel exists to set it beside the modelled column, and half a comparison invites the reader to complete it.
Assumptionsthe SDK's list and this page's, in one table
| Assumption | Value used | Source | Where it comes from | What goes wrong if it is wrong |
|---|---|---|---|---|
| How busy the pool is assumed to be | 0.07 % of 16 position slots — The venue really did run at 0.07% of its slots for the 9,855 minutes those trades were live. It is a measurement of a BURST, not of demand: those were the founder's own test trades, opened deliberately and several closed early to free slots. Nothing says a day looks like this. | measurement | realised.ts::RealisedWindow.utilised — the time-integral of required_reserve over the 146 real closes — divided by what the pool can reserve at once | THE assumption. An annual rate is take-per-trade times trades-per-year, the first is a program property and the second is this. Every rate on the page is linear in it right up to the capacity ceiling of 5493 trades a day, so halving it halves every percentage here. |
| The most trades a day this pool can ever settle | 5493 — 16 slots turning over every 252 s | engine | projection.ts::slotsFor over gates.ts::requiredReserve, and meanLifeSeconds | Not reachable: approaching it drives the Erlang-B refusal rate to 100 %. It is the one bound on the page no assumption can move, and every rate is a fraction of what it implies. |
| When a realised window may be turned into a rate | at least 907 closes AND at least 7.0 hours | engine | apy.ts::annualisationBar — Projection.tradesForDominance, and withdrawal_delay + RedemptionTicket::VALIDITY_S from the program | Both bars are derived and neither is a style choice. Dropping the span bar is how a fifty-minute window becomes a four-digit APY; dropping the trade bar is how noise becomes a projection. |
| Which "utilisation" the rates are quoted at | 0.07 % of SLOTS, which is 0.07 % of the POOL reserved | model | apy.ts::Turnover.poolFractionReserved, beside returns.ts::CapitalAtWork.meanUtilisation | This repository already contains two quantities called utilisation — exposure.ts means slot occupancy and returns.ts means reserved capital over the whole pool. They differ because the slot count floors, leaving capital no arrival rate can ever reserve. A page that says "utilisation" without saying which is quoting an ambiguity. |
| What the realised column is a measurement OF | 28 of 146 closes are priced by the model — 80.8% are not | measurement | realised.ts::realisedWindow over https://knockout-api.asymmetra.xyz/v0/trades | The model prices two outcomes: the barrier and the rung. Almost every real close so far was voluntary or a user timer, which it prices at neither. The two columns are therefore not two readings of one quantity — they are a model and a measurement of DIFFERENT populations, and adding, averaging or blending them would be a category error. |
| The stake the modelled column is computed at | $0.25 — the floor the chain enforces | governed | config.ts::LAUNCH.minCollateral; the rung is the lowest-paying one on the ladder | Chosen to be conservative rather than representative. The gas floor is an absolute amount against percentage shares, so the pool's take per trade is LOWEST at the smallest stake — $0.25 — and every deeper rung pays it more. The real archive holds two stakes and three rungs, which is why the realised comparison prices each close at its own and not at this one. |
| Which edge this projection uses | per-rung, settled at each cell; blended across the mix | engine | risk_engine::settle, through projection.cellOutcome | The published 11.402 % is the 2x RUNG figure and overstates a mixed population; the 15.207 % at 10x understates it. A separate 7.8-point "realised" edge exists in the record, is measured against an unmeasured 55/25/15/5 population mix, is asserted by nothing in this tree, and is NOT used here. |
| How a projected position closes | two outcomes: barrier or rung. Censored share stated at 0.0 % | model | projection.ts; CloseReason has five variants and this weights two | Voluntary closes, user timers and tenor expiries are not priced. A voluntary close is unclamped and pays to the payout cap, so a population that closes voluntarily costs the pool MORE than this shows, not less. |
| How opens arrive, for the refusal model | Poisson, Erlang-B on 16 slots | model | projection.erlangB | Real flow is bursty and correlated across traders, which refuses MORE than Poisson does at the same daily average. Erlang-B is insensitive to the holding-time distribution, so that part is not an assumption. |
| How the percentiles were produced | exact-binomial | model | projection.binomialQuantile / cornishFisher | Exact. The mix is one cell, so the pool is a linear function of a single binomial. |
| The asset's annualised volatility, which sets how fast a position resolves | 33.0 % | measurement | sim/roster.py 7-day realised; canonical.rs publishes the interval 24 %-80 % | Only the position LIFE depends on it, never the odds. It moves capacity and therefore the refusal rate; at 7 observations the relative standard error is 26.7 %. |
| SOL/USD, for the operator's real cost | NOT OBSERVABLE | caller | launchProjectionInput() has no default here on purpose — a market price typed into source is the defect this file exists to refuse (it read a stale $150, roughly double SOL's real price, until 2026-08-11). Pass a live read, e.g. monitor.ts::readSolPrice. | operatorCost and protocolNet below are NOT A NUMBER, on purpose: refusing to show a figure is safer than showing a plausible wrong one, and this repo already prefers that elsewhere (app/'s Money/moneyText already render a non-finite figure as NOT OBSERVABLE). |
| What one settle costs its sender | 15,037 lamports | engine | cover.ts::settleCostLamports, pinned to FeePolicy::LAUNCH by cover.test.ts | Measured at the priority floor on an uncongested network. A congested bid costs more. |
| Settles the operator pays for, per trade | 1.00 | hand-chosen | the caller. At launch there is no keeper, so the honest value is 0 | One settle per trade is the upper bound on the operator cost. Trader-submitted closes cost the operator nothing, and nothing in this tree measures the split. |
| Which rungs traders pick | 2x@$0.25:100% | caller | UNOBSERVABLE until there are traders | The single largest lever on this page. The edge moves 11.40 to 15.21 points purely on the rung mix, and no measurement anywhere in this repository constrains it. |
| The LP pool the projection is run against | $420.00 | caller | Vault::lp_assets | Sets capacity: 16 concurrent positions at a MEAN reserve of $25.01. Below the point where capacity binds, extra demand is refused rather than earned. **The slot count uses the mean reserve across the mix, and the chain does not.** `Vault::withdrawable` is checked against each open individually, so a pool with less free than one $1.00 position needs refuses that open while still admitting a $0.25 one. A single-server-type queue cannot express that, and it errs toward ADMITTING — the optimistic direction — whenever the mix has large stakes in it. |
| The submitter's minimum payment | 5000 base units | governed | ADR-0016; programs/exchange/src/lib.rs launch_for_test().gas_floor | An ABSOLUTE amount against percentage shares, so it moves the per-party SPLIT with the stake even though it cannot move the edge. crates/risk-engine/examples/canonical.rs still computes its published table at the RETIRED 15,000; do not cross-read the two. |
| How the loss tax divides | 2000/4000/1500/2500 bps | governed | TaxSplit::LAUNCH, read live at settlement | Insurance takes exactly its share of the loss tax and nothing else, so it earns only when traders lose. |
| How the exit fee divides between the pool and the treasury | 5000/5000 bps | governed | ADR-0012 | The submitter's gas top-up is charged to the TREASURY's leg before the pool's. |
| How the entry fee divides | 5000/5000 bps | governed | ADR-0010. A separate dial from the exit split, and settle never sees this fee | |
| The insurance target, past which accrual stops and the overflow stays with LPs | 1000 bps of the pool = $42.00 | governed | programs/exchange/src/vault.rs::accrue_insurance | NOT applied to the insurance line below — it is reported as tradesToInsuranceTarget instead. Past that trade count the insurance figure here overstates and the pool figure understates, and the target itself rises with the pool it is a share of. |
| Oracle-deviation leaks, feed drift and entry arbitrage | NOT modelled — zero, and that is a known overstatement | model | docs/ORACLE-COST.md — no figure is quoted, because the published one is retired | This projection prices a correctly calibrated feed. The entry arb costs the pool 4.4500 points per attacked open and the LP-solvency crossing sits at 49.16 % arbitrage share. ui/revenue.html put a number on this and the number was retired; a zero that says it is a zero is more honest than a stale float. |
A row tagged hand-chosen or caller is the loudest thing in this table because it is the one a reader is most likely to mistake for a finding. The occupancy at the top of this page is one of them unless the measured preset is selected, and every percentage below it is linear in that row.