# Quiver — Technical Documentation — part 3 of 7

> The complete document, split only because a single fetch truncates. **Nothing is abridged**: the
> parts below concatenate to the whole text, cut at section boundaries. Every part is served as plain
> markdown.
>
> - **Part 1** — `/paper/1` — Abstract  |  At a Glance  |  Contents  |  1. Introduction  |  2. System Architecture  |  3. Design Principles
> - **Part 2** — `/paper/2` — 4. Service Catalogue
> - **Part 3** — `/paper/3` — 5. Methodology
> - **Part 4** — `/paper/4` — 6. Verification and Testing  |  7. Worked Walkthrough  |  8. Limitations and Honest Disclosures
> - **Part 5** — `/paper/5` — 9. Related Work and Positioning  |  10. The Build: Story, Process, and a User Scenario
> - **Part 6** — `/paper/6` — 11. Roadmap: Operating Quiver After the Hackathon  |  12. Conclusion
> - **Part 7** — `/paper/7` — Appendix A · API Reference  |  Appendix B · Reproducibility  |  Appendix C · Checkable Artifacts  |  References
>
> Whole document in one response (247 kB, may truncate in your client): `/paper/full`
> Typeset edition with figures: `/paper`
> Live service: https://quiver-production-c3a8.up.railway.app · Source: https://github.com/Tristan-tech-ai/Quiver

---

## 5. Methodology

This section gives the mathematics behind the options, microstructure, and safety services. It defines notation once and uses it consistently. Deribit crypto options are quoted on the forward, so the pricing model throughout is Black-76 [1] rather than spot Black-Scholes [2],[3].


### 5.1 Black-76 and the option greeks

Let `F` be the forward, `K` the strike, `T` the time to expiry in years, `σ` the implied volatility, and `r` the continuously compounded discount rate. Write `φ` and `N` for the standard normal density and distribution. The Black-76 call price and the moneyness terms are

The first-order greeks follow by differentiation. Delta is `e^−rTN(d₁)` for a call, gamma is `e^−rTφ(d₁)/(Fσ√T)`, and vega, the sensitivity to volatility, is

Dealer hedging is driven not only by these but by the second-order volatility greeks, so the service computes them in closed form and, because a closed form is only as good as its verification, checks each against a finite difference of the first-order greek. Vanna, the cross-derivative of price in forward and volatility, and volga, the convexity of value in volatility, are

Both are identical for calls and puts, as they must be, since they are curvature terms in strike and volatility rather than direction. The test suite asserts this identity and asserts that the analytic vanna equals the numerical derivative of vega with respect to the forward to a tolerance of one part in a thousand.


### 5.2 The arbitrage-free volatility surface

A real options chain does not have one volatility; it has a smile, a function `σ(K)` that must be estimated from a finite set of quoted strikes. Interpolating linearly in log-strike is easy and wrong: it admits butterfly arbitrage and can produce a negative risk-neutral density in the wings, which makes any probability read from it meaningless. The service instead fits the raw SVI parameterisation of Gatheral [5],[7] to each expiry's total variance `w(k) = σ²(k)T` as a function of log-moneyness `k = ln(K/F)`,

The five parameters are fitted by Nelder–Mead minimisation [30] of squared volatility error, but with the no-arbitrage conditions of Gatheral and Jacquier [6] enforced as penalties inside the objective, so a converged fit is arbitrage-free by construction rather than by inspection. The butterfly condition is the non-negativity of the Durrleman function,

checked on a grid of log-moneyness, and the large-strike wing is bounded by the Roger Lee moment condition `b(1+|ρ|) < 2` [8], which is equivalent to the density decaying at infinity. A slice whose fit exceeds a root-mean-square gate of 1.5 volatility points, or whose no-arbitrage checks fail, is rejected, and the caller is told the disclosed fallback was used rather than being served a bad surface silently.

One consequence of taking the model seriously is knowing where it does not apply. Near-expiry smiles are dominated by jumps, not diffusion, and a diffusive parameterisation such as SVI cannot describe them; the residual root-mean-square rises from under a volatility point at two or more days to several volatility points inside a day. The service excludes those slices by design and says so, rather than force-fitting a model outside its regime.

To price an event whose date is not a listed expiry, the surface is interpolated in the maturity direction. The correct interpolation is linear in total variance at fixed moneyness, because the calendar no-arbitrage condition is exactly that total variance be non-decreasing in maturity [6]; interpolating volatility, or snapping to the nearest expiry, can violate it. For a target maturity `T` bracketed by fitted slices `T_a < T < T_b`,

Outside the fitted range the service holds volatility flat across the gap and discloses the extrapolation per row.


### 5.3 Risk-neutral density and the full distribution

The risk-neutral distribution of the terminal price is implicit in the option prices. Breeden and Litzenberger [4] showed that the risk-neutral cumulative distribution and density are the first and second derivatives of the call price in strike,

With a strike-dependent volatility the strike derivative of the call carries a term in the smile slope. Differentiating (1) with `σ = σ(K)` and substituting into (7) gives the exact probability,

The plain `N(d₂)` is the first term alone. On a flat smile the second term vanishes and the two agree; on a real skewed crypto smile the second term is material, and it changes sign where the smile slope changes sign. We measured the omission on a constructed seven-day BTC smile with realistic skew (a constructed surface, not a venue capture, so that the bias is measured against a known answer): `N(d₂)` overstates the probability by 3.3 points at one strike and 5.0 at another, and understates it in the opposite wing. Reporting `N(d₂)` to one-tenth of a point while carrying a five-point error is not a simplification; it is a defect, and the service uses (8).

Integrating the density (7) over a strike grid gives the full distribution. The service reports the quantiles from the 5th to the 95th percentile by inverting the resulting cumulative distribution, the tail expected shortfalls `E[S | S ≤ q₅]` and `E[S | S ≥ q₉₅]` [19], and the distribution's volatility, skew, and excess kurtosis. Correctness is checked by an identity that requires no external data. Under the risk-neutral forward measure the terminal price is a martingale, so its expectation equals the forward:

The service computes the residual `E[S_T]/F − 1` and reports it as a self-check. On a live BTC expiry it reads 0.001%, and the raw integral of the density reads 1.000, which together certify that the numerical density is a proper density and that the integration is correct. The distribution is withheld when these checks fail.


### 5.4 Variance risk premium and honest significance

Implied variance tends to exceed subsequently realised variance; the difference is the variance risk premium, the compensation option sellers earn for bearing volatility risk [16],[17],[18]. The service estimates it as the median ratio of realised to implied volatility over a rolling horizon. Realised volatility over a window is the annualised standard deviation of daily log returns; implied volatility is the DVOL index. The subtlety is significance. Overlapping windows are highly correlated, so the number of windows badly overstates the number of independent observations. Using the raw count would manufacture significance. The service deflates to an effective sample,

and tests whether realised is below implied more often than chance with a one-sided binomial test at `n_eff`. On live BTC the median ratio is 0.881, which looks like a premium, but at the honest effective sample the p-value is 0.254. Deflating the sample to `n_eff` is a deliberately blunt correction. The standard treatment for overlapping windows is a HAC or Newey–West variance with a bandwidth set by the overlap, and it would be the right thing to run here; a non-parametric block bootstrap over the ratio series would be better still, since the statistic is a median rather than a mean. Neither is implemented. What can be said for the crude version is the direction of its error, and an earlier draft of this passage got that direction backwards. Collapsing correlated observations into a smaller independent count costs power, which *raises* the p-value: 0.254 is therefore a *ceiling*, not a floor, and a properly HAC-corrected test — whose effective sample sits between `n_eff` and the full count — would return something smaller and could well reject at the same level. So nothing follows about what the sharper test would say; the earlier claim that a premium failing this test would also fail a HAC-corrected one is simply invalid, and is withdrawn. What the crude test does support is the refusal itself: we decline to sell a premium we have not established, and a conservative test is the right instrument for that decision even though it is the wrong instrument for the opposite one. The service reports that the premium is not statistically distinguishable from zero and marks every real-world-calibrated probability it derives as indicative only. Computing a plausible number and then refusing to over-claim it is the behaviour a quantitative reviewer looks for, and it is enforced here in code.


### 5.5 Tape microstructure estimators

Three estimators summarise the order flow in a DEX tape. Let a block be a set of consecutive trades; for block `j` let `r_j` be the log return across the block, `V_j` the dollar volume, and `q_j` the signed dollar flow with buys positive and sells negative. Kyle's lambda [10], the permanent price impact per unit of signed flow, is the slope of the regression of block return on signed flow,

reported with its R-squared and sign-agreement so a weak relationship is visible. Amihud illiquidity [11] is the average price move per dollar traded,

The reporting scale is written into the equation because without it the figures below cannot be reproduced from it, and an earlier draft omitted it. In its raw form `ILLIQ` is a fractional return per dollar, so a value of 0.303 in those units would mean a thirty-percent move per dollar traded, which is nonsense; every Amihud figure in this document is in the field's own units of *percentage move per thousand dollars of volume*, which is what the response names it. Both figures quoted below are on that same scale, so the comparison between them is meaningful.

VPIN [12] is the mean absolute buy-minus-sell imbalance across equal-volume buckets, a number in [0,1] where zero is perfectly two-sided flow and one is fully one-sided.

The choice of block rather than tick is not cosmetic; it is a correction that ground-truthing forced. A per-trade Amihud ratio divides by the dollar size of a single trade, and a DEX tape contains sub-cent dust trades whose near-zero denominator sends the ratio to enormous values. On a live memecoin tape the per-trade estimator returned an Amihud figure of order 1.6 × 10^9, obvious nonsense. Two facts caused it: the dust denominators, and the observation that the exchange returns a sampled large-trade feed for a hot token, so two consecutive trades can be hours apart and their return reflects drift rather than impact. Aggregating into equal-count blocks removes both problems, because a block aggregates real volume and a real time interval, and it is the faithful period form of both Amihud and Kyle. On the same token the block estimator returns an Amihud of 0.303, a sane price move per thousand dollars. The tape-density diagnostic that surfaces the sampled feed is reported alongside, so the caller can see when the impact read rests on thin ground.


### 5.6 Dealer gamma exposure and barrier probabilities

Two further constructions support the options service. Gamma exposure summarises how much delta dealers must hedge as spot moves. The dollar gamma of a strike is its Black-76 gamma scaled by open interest and by the square of spot, and the net across the chain applies the dealer-sign convention of Section 4.1,

Net positive gamma means dealer hedging dampens moves toward the largest strikes; net negative gamma means hedging amplifies them. The gamma-flip is the spot level at which `GEX(S)` crosses zero, found by scanning a spot band and interpolating the crossing. The convention is an assumption, disclosed as such in Section 8; the construction itself is exact given the convention.

The cross-market service prices reach-by-date questions with the one-touch barrier probability. Under the driftless forward measure, the reflection principle gives the probability that the forward touches a barrier at any time before expiry,

with `d₁ = [ln(F/B) + ½σ²T]/(σ√T)` and `d₂ = d₁ − σ√T` for the barrier `B`. A touch probability is always at least the finish-above probability, since a path that ends beyond the barrier must have crossed it; the test suite asserts this inequality. Because a one-touch is path-dependent, no single volatility is smile-consistent, so the service reports the model-uncertainty span between the barrier and at-the-money volatilities rather than implying false precision.


### 5.7 Transaction and signature safety

The transaction path decodes calldata and, given the full unsigned transaction, executes it against live state with `eth_simulateV1`, extracting asset and approval changes from the emitted Transfer and Approval events. Upgradeability is checked by reading the proxy implementation slot: the EIP-1967 slot [22], its beacon variant, and the pre-standard OpenZeppelin slot used by early proxies. A non-zero implementation flags a contract whose logic its admin can replace after approval.

The signature path parses an EIP-712 typed-data payload [20]. EIP-712 binds a signature to a domain and a typed struct through a hash of the form `keccak256("\\x19\\x01" ‖ domainSeparator ‖ hashStruct(message))`; a signature that a wallet displays as harmless can authorise a transfer through a Permit or Permit2 grant. The service recognises the Permit2 [25] and EIP-2612 [21] permit shapes, extracts the spender, amount, and expiry, checks the domain against the canonical Permit2 deployment, and flags an unlimited allowance, a non-expiring permit, a batch that touches many tokens, or a spender that resolves to an externally owned or EIP-7702-delegated wallet [23] rather than an audited contract. Because these grants are signatures and never transactions, no amount of transaction simulation can see them; a service that stops at simulation leaves the dominant drainer vector uncovered.


### 5.8 Model-free calendar bounds by martingale optimal transport

A single expiry's smile pins down the risk-neutral law of the terminal price at that one date; it says nothing about the joint law across two dates, which is exactly what a forward-starting or calendar payoff needs. The classical response is to assume a dynamics — Heston, local volatility, a jump model — and inherit its misspecification. Martingale optimal transport instead asks for the entire range of prices consistent with the two marginals and no arbitrage, and returns a hard interval rather than a point (Beiglböck, Henry-Labordère and Penkner [39]). Work in the martingale coordinate `X = S/F(T)`, in which each fitted marginal has mean one. Let `μ` be the earlier date's law and `ν` the later's, both recovered from the fitted smiles by Breeden–Litzenberger and discretised to grids `{x_i}` and `{y_j}` with probabilities `{μ_i}`, `{ν_j}`. A joint law is a coupling `π_ij ≥ 0`, and the no-arbitrage price of a payoff `c` is bounded by the linear program

The first two constraints reproduce the quoted marginals; the third is the martingale condition `E[Y | X = x_i] = x_i` that no-arbitrage imposes between the two dates. The program is feasible if and only if `μ` and `ν` lie in convex order, written `μ ⪯ ν`, which by Strassen's theorem is precisely the existence of a martingale coupling — equivalently, that the two smiles carry no calendar arbitrage. The same linear program that prices the payoff therefore certifies the surface: infeasibility *is* a calendar-arbitrage detector, agreeing with the total-variance monotonicity check of Section 5.2 by a completely independent route. Two identities gate the result before it ships. The later marginal must itself have unit mean, `∫ y dν = 1`, and the transport must preserve it, so `E_π[Y − X] = 0` to numerical tolerance. When either fails — the signature of a mis-discretised or crossed marginal — the bounds are withheld rather than served, in keeping with the refuse-to-fabricate principle.


### 5.9 Concentrated-liquidity value and divergence loss

A Uniswap-V3 position supplies liquidity `L` across a price range `[P_a, P_b]` and earns fees only while the pool price sits inside it. At a price `P` within the range the position holds

token0 vanishing at the top of the range and token1 at the bottom. lp-desk fixes `L` from the caller's capital at entry, then replays the pool's real swap sequence read from chain: at each in-range swap it credits the position's pro-rata fee share `L / (L_active + L)` of the tier applied to that swap's volume, and re-marks the holdings by (16) at the new price. The profit-and-loss against simply holding the entry bundle decomposes as

where the divergence loss is the concentrated-liquidity form of loss-versus-rebalancing — the value the position sheds to arbitrageurs as price crosses it, growing as the range narrows. The replay is exact for *ranking* strategies at small size, where the pro-rata share is faithful; it is a relative measure, not absolute PnL at scale, because public swap logs expose only aggregate active liquidity and not the per-tick order book, and the service discloses this limit in its own output. The empirical result across the replayed windows is that fees never overtake divergence loss for the narrow ranges an optimiser would recommend, which is why lp-desk reports the measurement and declines to name an optimum it cannot honestly defend.


### 5.10 Perpetual liquidation and funding

The `perp-gate` liquidation price is not copied from a venue's formula — it is *derived* from the stated liquidation condition and then verified against it on every call. A venue liquidates an isolated position when its account value falls to the maintenance margin. With posted margin `M`, size `q` in base units, entry `P_0`, side `s∈{+1,−1}`, and a maintenance rate `mmr` (half the initial rate at maximum leverage, so `mmr = 0.5 / maxLeverage`), the account value at price `P` is `M + s·q·(P−P_0)` and the maintenance requirement is `q·P·mmr`. Equating the two and solving gives

which for a long is `(P_0 − M/q)/(1 − mmr)`. On every call the engine substitutes `P_liq` back and confirms that account value equals the maintenance requirement there — the same condition it solved — so a wrong derivation fails loudly (residual of order 10^−11 to 10^−12 against a tolerance scaled to notional; the worked example in Appendix C shows 2.05×10^−12 against a tolerance of 0.064) rather than shipping a confident wrong number. This is the discipline in action: deriving from the primary source, rather than a widely-repeated secondary formula that dropped the maintenance term and reported roughly double the true buffer. Funding is projected separately on the notional at the venue's cadence (hourly on Hyperliquid). The maintenance rate is not a single constant: on Hyperliquid it steps up with position notional through the venue's margin tiers, so a large position is measured against the tighter rate its size actually incurs rather than the headline one, and the identical derivation is driven by a second venue's live parameters when a leg sits on dYdX, whose maintenance-margin fraction is published directly. Figure 2 shows how the liquidation buffer collapses with leverage.

[FIGURE — rendered in the typeset edition at /paper] Figure 2 — move-to-liquidation for a BTC long at maintenance margin 1.25%, computed by perp-gate across leverage.


### 5.11 Position sizing and the probability of ruin

Over-betting, not a bad thesis, is what ruins a leveraged agent, so `size-gate` converts an edge into a fraction of capital and reports the probability that fraction ever ruins it. Full Kelly maximises expected log-growth: for a discrete edge (win probability `p`, net odds `b`) it is `f* = (p(b+1)−1)/b`, the argmax of `g(f)=p·ln(1+fb)+(1−p)ln(1−f)`; for a continuous edge, `f* = μ/σ^2`. Full Kelly is growth-optimal but its drawdowns are violent, so the engine bets a fraction `λ` of full Kelly (default a quarter). The probability of *ever* drawing down to a fraction `α` of capital is derived, not recalled: under fractional-Kelly `λ` log-wealth is a Brownian motion with drift `g=(μ^2/σ^2)λ(1−λ/2)` and variance rate `s^2=λ^2μ^2/σ^2`; the probability that a drifting Brownian motion ever reaches a level `−L` is `exp(−2gL/s^2)`, and with `L=ln(1/α)` this collapses to

which at full Kelly (`λ=1`) reduces to the classic result `RoR=α`. The engine self-checks the returned fraction against the first-order condition `g′(f*)=0` that *defines* Kelly, the half-Kelly identity (growth ×0.75, volatility ×0.5), and the ruin anchor, and it flags when the recommended bet exceeds the bankroll (Kelly implying leverage, where the ruin figure understates the true risk of a forced liquidation). Figure 3 shows why professionals under-bet: ruin risk falls super-linearly as the Kelly fraction shrinks.

[FIGURE — rendered in the typeset edition at /paper] Figure 3 — probability of ever reaching a given drawdown at full, half and quarter Kelly, from size-gate. Full Kelly is linear in the drawdown; quarter Kelly is `α^7`.


### 5.12 Execution quality and adverse fills

"Filled within slippage tolerance" is not protection — a sandwich completes the trade inside the tolerance while extracting value the caller never sees. For a constant-product pool with pre-trade reserves `(x,y)` and fee `f`, the honest output for input `Δx` is

which exactly preserves the fee-adjusted product, `(x+Δx(1−f))(y−out)=xy` — the invariant `exec-verify` asserts whenever it is given pool reserves — in the alternative mode the benchmark is a price the caller supplies, so there is no pool model to assert against and the response now reports that check as not-run rather than as a pass. The realised fill's shortfall against this honest figure is reported as adverse-execution basis points, separated from the unavoidable fee and the caller's own price impact; a favourable fill is labelled as such rather than mislabelled adverse. The engine discloses that its benchmark is only as good as the reserve snapshot's timing (block-start versus immediately-pre-transaction), because that choice determines whether a front-run is inside or outside the measured baseline.


### 5.13 Options-book greeks and scenario margin

An options book's risk is not the sum of its legs' notionals. `options-risk` aggregates the position-weighted greeks (`Σ q_i·greek_i`) on Black-76 and computes a SPAN-style scenario margin — the worst repriced profit-and-loss over a grid of price and volatility shocks, which is the loss the book must be held against. Its self-check is the most exacting in the catalogue: the analytic portfolio greeks are verified against finite-difference derivatives of the *actually repriced* book, so `dV/d(shock)` must equal `Σ q_i·δ_i·F_i` and the second difference `Σ q_i·γ_i·F_i^2`. Enforcing that to a tight tolerance surfaced a latent flaw: the pricing used an Abramowitz–Stegun [31] normal CDF whose numerical derivative disagreed with the exact-density greeks at ~5×10^−4, flooring any greek self-check. Rather than widen the tolerance to make the red turn green, we replaced the CDF with a machine-precision (Hart) algorithm, restoring price–greek consistency to ~4×10^−8 and improving every options service that shares the pricer. Figure 4 shows the scenario surface of a short straddle.

[FIGURE — rendered in the typeset edition at /paper] Figure 4 — SPAN-style scenario P&L of a short BTC straddle across the price×volatility grid, from options-risk; the worst cell is the scenario margin.


### 5.14 Liquidity-provision divergence and its LVR rate

Where lp-desk replays history, `lp-risk` forecasts. For a full-range position the impermanent loss at a realised price ratio `r` is

verified at the token level against explicit constant-product amounts (the position holds `2√(kP_1)` in value against the held bundle). Expanding to leading order, `IL ≈ −(ln r)^2/8`, so the expected divergence over a horizon under a lognormal underlying is `E[IL] ≈ −σ^2T/8` — which numerically matches the loss-versus-rebalancing rate of a constant-product pool [44]. That coincidence has been a source of confusion in this document and the confusion is worth clearing up, because a reviewer was right to press on it. **Impermanent loss and loss-versus-rebalancing are not the same quantity.** IL is a function of the *terminal* price ratio alone: path-independent, and bounded in (−100%, 0]. LVR is the running loss to arbitrageurs against a rebalancing portfolio: it accrues monotonically along the path, never returns anything, and is therefore *unbounded*. On a path that ends where it began, IL is exactly zero while realised LVR is strictly positive. They agree only in expectation, only to leading order, only under a driftless lognormal — which is precisely the regime in which this expansion was derived, and precisely why the two names get used for one number. An earlier version of this passage then rejected the expansion because "at large total variance the rate returns a loss that cannot happen". That reasoning was wrong in an instructive way: an unbounded loss is exactly what LVR is, so unboundedness is not evidence that the *rate* is broken — it is evidence that the rate is measuring the other quantity. The boundedness at −100% belongs to impermanent loss, and impermanent loss is what this service reports. The headline is therefore the exact expectation of (21) under `ln r ~ N(−σ^2T/2, σ^2T)`, evaluated numerically, with the expansion beside it and the gap between the two reported so a caller can see where the approximation left its range. A boundedness check runs on the value actually served. This was a defect found in live testing, not a design choice made in advance; Section 11.5 gives the number it used to return. Given a fee yield the engine returns the net forecast and the break-even volatility above which fees no longer cover the bleed — also solved against the exact expectation, so re-running at that volatility nets zero, which the engine asserts as a self-check. Figure 5 shows the loss is symmetric in log price ratio and always non-positive.

[FIGURE — rendered in the typeset edition at /paper] Figure 5 — impermanent loss versus price ratio, from lp-risk; zero at no move, symmetric under `r→1/r`.


### 5.15 Stablecoin-treasury concentration and depeg

A treasury's real risk is concentration and depeg, not its headline yield. `treasury-risk` measures concentration as the Herfindahl index over USD shares, `HHI = Σ w_i^2`, whose reciprocal is the effective number of independent exposures; any single share above a limit is flagged as a breach. Depeg loss for an asset marked at price `p` against peg `q` is `Σ amount_i(q−p)/q`, exact and independently re-checked on the worst-single-depeg scenario, and the risk-adjusted yield subtracts the annualised expected depeg loss wherever probabilities are supplied. Because depegs are not independent — the March 2023 weekend pulled USDC and the DAI it backs down together — the service also stresses a *correlated* depeg in which every stable falls to a common floor at once, the systemic loss a worst-single scenario hides, and reports a correlation-adjusted effective-exposure count `1/(w^Tρw)` that drops below the independent Herfindahl figure once a correlation matrix is supplied — identity by default, so no `ρ` is ever fabricated. The same Herfindahl lens deepens `poly-desk`, turning a flat list of prediction-market positions into a book with a concentration grade and a directional skew.


### 5.16 Event-implied expected move

A macro calendar gives a date and a "high impact" label; it does not give the market's priced-in magnitude. `event-vol` supplies it. For spot `S`, at-the-money implied vol `σ` and horizon `T`, the one-standard-deviation move is `Sσ√T`, and — since for a driftless forward the ATM straddle price is the risk-neutral expected *absolute* move — the straddle equals `E|S_T−S_0| = 2S(2Φ(σ√T/2)−1)`, which the engine verifies against a numerical integral of `|S_T−S_0|` over the martingale lognormal. Given the volatility term structure across the event — an expiry just before and just after — the event's own contribution is isolated as

the event-day options technique: the post-event expiry carries the baseline diffusion plus the event, the pre-event expiry carries the baseline alone, and the difference in total variance is the jump the market is pricing. A non-positive event variance means the term structure does not isolate the event, and is disclosed rather than reported as a fabricated move. This is `macro-sentry`'s new depth: with a coin's spot and ATM vol it reports not just that an FOMC is ahead but that the market is pricing, say, a ten-percent one-sigma move into it.


### 5.17 Batched attestation

To make many computations cheaply and permanently attestable, `risk-attest` combines their content hashes into a single Merkle root (sha256 over packed 32-byte words, sorted pairs, with leaves tagged `0x00` and internal nodes `0x01` so a node cannot be presented as a member). One on-chain anchor of that root — broadcast from the caller's own wallet, never Quiver's — attests every member of the batch at once, and any single computation is later provable with a small inclusion proof. The engine self-checks both directions of a Merkle proof: completeness (every leaf verifies against the root) and soundness twice over — a fabricated non-member must not verify, and neither must a real internal node presented as a member leaf. The second check exists because the first one cannot fail structurally, and a reviewer broke the earlier tree through exactly that gap (Section 11.5). The tree is deliberately *not* OpenZeppelin `MerkleProof`-compatible, since that library folds keccak256 without a domain tag; the response says so and ships a five-line Solidity verifier for this tree instead of leaving the caller to infer the encoding.


### 5.18 Cross-venue portfolio exposure and correlated-crash stress

The services above price one position at a time; an agent's real risk lives in the whole book, and the book is often spread across venues. `portfolio-gate` aggregates a set of perpetual legs — on Hyperliquid, dYdX, or both — into four book-level numbers, reusing the `perp-gate` derivation of Section 5.10 for each leg so the aggregate inherits per-leg correctness. Write leg `i` with side `s_i ∈ {+1,−1}`, size `q_i`, and mark `P_i`, so its signed notional is `s_iq_iP_i` and its gross notional `q_iP_i`. The *net* exposure to an underlying `a` sums the signed notionals of that underlying's legs,

so a long on one venue and a short of the same size on another net to zero real exposure rather than counting as two positions — a distinction a per-instrument tool cannot draw. Concentration is the Herfindahl index over gross notional by underlying, `H = Σ_a(G_a/G)²` with `G_a` the gross in underlying `a` and `G` the book total; its reciprocal `1/H` is the effective number of independent bets, which collapses toward one when a nominally diversified book is really a single directional wager. The binding constraint is the *nearest* liquidation — the smallest adverse move to liquidation over all legs, each move computed by the Section 5.10 condition,

with `s_i` the leg's sign, so that `m_i` is the *adverse* move still available before leg `i` liquidates: `m*` is the whole book's true distance to first blood. The restriction to non-negative `m_i` is not cosmetic. A leg whose mark has already passed its liquidation price has `m_i < 0`, and an earlier version took a minimum over absolute distances, which ranked such a leg as the book's nearest *future* liquidation when the event was in fact already past. Those legs are now reported separately, with an explicit below-maintenance status, as something to reconcile rather than to protect; Section 11.5 records how that was found. The catastrophic mode, though, is not one leg but many at once: in a crash, correlations go to one and independently-sized bets liquidate together — October 10, 2025 saw single-day liquidations reported between roughly $9 billion and $19 billion across trackers as exactly this unfolded. The correlated-crash stress moves the entire market by a uniform `±x%` and counts the legs crossing maintenance *simultaneously*: a down move with `x ≥ m_i` liquidates long leg `i`, an up move the shorts, and the fraction of the book breaching at each shock is the honest measure of how concentrated the tail truly is. The stress assumes co-movement, so a leg on a genuinely uncorrelated asset would not breach in reality; that assumption is disclosed with the result rather than buried.

Four exact identities guard the aggregation on every call: the per-asset net exposures sum to the reported book net, so a mis-bucketed leg fails loudly; every per-leg liquidation still satisfies its own maintenance invariant from Section 5.10; the reported nearest liquidation is genuinely the minimum distance across the legs that are still live; and the count of legs breaching under the correlated down-crash is monotone non-decreasing in the shock size. Isolated per-leg margin is assumed by default — a true cross-margin account shares equity across legs, and that is modelled by passing account context, never silently presumed.

The uniform-shock stress is deliberately an upper bound, and the service now brackets it from both sides. A *factor-beta* view scales each asset's move by an empirical crash beta — measured, not guessed, from the October 10 event itself as each coin's Hyperliquid 4h peak-to-trough drawdown against BTC's −17.7% anchor (ETH 1.5, SOL 2.2, XRP 3.3, the meme cohort near 5; a first-pass prior table had understated alt betas two-to-threefold and was corrected against the recorded prices, which is the point of measuring). These are severe crash-regime betas that embed liquidation-cascade feedback, and the response says so. The same construction was validated at population scale: replaying it over every open perp position on the venue (79,386 accounts, $14.6 billion notional, real margins and the venue's own liquidation prices, from the public Reservoir archive) at T−24h before the October 10 cascade, the accounts it flagged were subsequently wiped at 3.9× the rate of those it cleared, and the flagged band sitting 10–17.7% out — safe under routine volatility, reachable only by a correlated crash — was wiped at 7.4× the rate of everyone further out. The betas themselves then survived a *pre-registered* cross-event test — hypotheses and pass thresholds fixed in published files before any number was computed — the pass bars and thresholds appear as literal constants in the query files, and the calibration set contains only 2025 episodes — with a hard temporal cutoff: betas calibrated on 2025 episodes predicted 2026 episodes' per-asset risk ranking (median Spearman 0.657 across five events), and on the two never-before-seen 2026 crashes the same flag, computed a day early with calibration-only betas against censoring-free victim sets from the full fill stream, carried a relative risk of 14.3× (June, 16,492 liquidated addresses in the fill stream, of which 12,115 belong to accounts present in the T−24h snapshot and therefore enter the tables; the remaining ~4,400 opened and were liquidated inside the window and cannot be scored by a flag computed a day earlier) and 13.3× (February, the archive's deepest event at −24.1% peak-to-trough in BTC, 19,541 addresses in the fill stream, of which 13,383 were in the snapshot and scored, leaving 6,158 — 31.5% of that crash's victims — outside anything the flag could have said) — both with perfectly monotonic dose-responses, and the consistency across independent events is itself the robustness evidence. The service exposes these cross-validated betas as severity tiers (`betaTier`), each response carrying the validation record; the worst-case single-event table remains the labeled default. A *cross-margin* view then computes the account-level liquidation for a shared-equity book — the market move at which pooled equity falls to total maintenance — under which a hedged book survives far beyond its scariest isolated leg, the real diversification an isolated view cannot see. The three views ship together, each labelled with its assumption.

The book itself no longer has to be typed in. Passing a single Hyperliquid address pulls the account's full live book through the keyless `clearinghouseState` API — positions, entry prices, margins and margin modes, account equity, and the venue's own per-leg liquidation prices — and runs everything above on it. Because that answer embeds a live fetch, it ships the observation envelope of Section 5 — an adversarial review pass caught the first build wearing the deterministic proof envelope here, an overclaim by this paper's own two-envelope doctrine, and it was corrected the same day — with the frozen book echoed in the envelope's inputs and the useful property stated precisely: the risk *mathematics* re-runs deterministically from that snapshot, while the snapshot itself is a committed observation. The venue's liquidation prices serve a second purpose: they are the one verifier the engine does not control. For isolated legs the venue's number and the engine's model the same quantity, so the response cross-checks them and the self-check fails beyond a small tolerance; for cross-margined legs the venue's price embeds the shared pool, the comparison is labelled rather than forced, and the per-leg deviations remain visible. On a real five-leg, $2.2 million account observed during development, the isolated view read "nearest liquidation 3% away" while the venue's cross-margin prices sat 240% to 62,000% away — the gap between the two models, shown side by side with each one's meaning, is precisely the information a margin desk wants.


### 5.19 The proof envelope: correctness you re-derive

Every risk computation ships a *proof envelope*, and because the engines are deterministic the envelope is a reconstruction, not a promise. It carries the exact inputs, the code identity, a content hash `H(engine, code, inputs, result)`, and the self-check results, so a caller re-runs the open-source engine on the echoed inputs and reproduces the number bit-for-bit — correctness re-derived, not trusted. When a signing key is configured the content hash is additionally signed with secp256k1 over its EIP-191 digest, so a proof recovers to a known address — Quiver's published attestation signer `0x946324E0E5d7D77206731E35Ef4044a383e2a8C2` — and a tampered result no longer does. Signing, though, is only table stakes — a policy gate can sign its policy. The deeper guarantee is the one underneath: each engine tests its own output against an invariant — the liquidation condition, the Kelly first-order condition, the constant-product `k`, the martingale `E[S_T]=F`, the arbitrage-free density — so an answer that does not satisfy the condition it was solved from fails its own check *before* it is ever signed. That the checks bite was tested rather than asserted: a reviewer with live access copied the engines aside, corrupted one formula in each, and every corruption was caught, six for six, at tolerances tight enough that a one-percent error moves the residual by hundreds of units.

The same reviewer then named the limit of that guarantee, and this document carries it here rather than the flattering summary it used to. **These checks establish that the closed form matches the condition as coded. They do not validate the inputs, and they do not validate the choice of model.** If the maintenance-margin rate is wrong for the venue, `perp-gate` computes a wrong liquidation price and the invariant still passes at a residual near machine epsilon — because both sides of the comparison use the same wrong rate. They catch implementation error; they cannot catch specification error. An earlier draft called all five "ground-truth invariants" and concluded that Quiver "proves it is right rather than merely proving it spoke"; the first phrase oversells the distinction and the second is not earned by a check that shares its assumptions with the thing it checks. Two of the five do reach further, and are worth naming as the exceptions: the `options-risk` greeks are checked against finite differences of an *independently repriced* book, and the recovered density's martingale residual tests a numerical integration against a quantity derived by a completely different route. Each of those two has caught a real defect. The external check that is not ours at all — the venue's own published liquidation price, compared against our computed one — is described in Section 5.18, and it is the only one in this system whose disagreement we cannot explain away.

```
// Every T1 proof signs its content hash with secp256k1 over the EIP-191 digest,
// so anyone can recover the signer from a paid response and check it is Quiver's.
import { verifyMessage } from "ethers";

const QUIVER_SIGNER = "0x946324E0E5d7D77206731E35Ef4044a383e2a8C2";
const { contentHash, signature } = response.proof;   // signature = { signer, signature, ... }
const recovered = verifyMessage(contentHash, signature.signature);

recovered === QUIVER_SIGNER;   // true => the number came from Quiver, untampered
// The deeper check needs no key at all: re-run the open-source engine on
// proof.inputs and confirm sha256(canonical{engine, codeHash, inputs, result})
// reproduces contentHash — correctness re-derived, not trusted.
```

Live-market services cannot make the re-run promise — the market moves between calls — and pretending otherwise by signing everything and implying reproducibility is exactly the costume this design refuses. They ship the honest sibling instead: an *observation envelope*, which commits to what was observed and served at a stated instant. It carries the same content hash and the same secp256k1 signature, plus the observation timestamp, and its semantics field states outright that the answer is *not* re-runnable and why — the re-run claim is reserved for the deterministic services. One serialisation detail matters for anyone implementing verification: the hash is taken over the response's *wire form* (one JSON round-trip), because JSON serialisation drops undefined-valued keys and stringifies dates, so a hash over the raw in-memory object would false-fail for the consumer recomputing from the response they actually received. The SDK's `verify()` accepts both envelope kinds; its `reproduce()` refuses observation envelopes with the reason stated. Every paid response that delivers an answer therefore carries a verifiable, signed, on-chain-anchorable commitment, and the two claims are never conflated.

---

**Continues in part 4 of 7: `/paper/4` — 6. Verification and Testing  |  7. Worked Walkthrough  |  8. Limitations and Honest Disclosures**