Quiver

Your AI agent will act on a number it cannot check. Quiver computes that number and attaches proof, so you can re-run the math yourself, or let a smart contract verify it on-chain.

Comment

Inspiration

An AI agent will tell you a liquidation price with total confidence. It has no idea whether it is right.

That is fine when the agent is drafting an email. It is not fine when the number decides whether a position survives the night — because when it goes wrong, a person has to explain what happened. Today the only explanation available is "the model said so."

We started from a real event. On 10 October 2025, about $19 billion of crypto positions were liquidated in roughly forty minutes. We went back and rebuilt a census of 4,426 wallets that actually died in that cascade. 79.7% of them were already sitting in a correlated-stress danger zone 24 hours before they were liquidated. We then tested the same flag on two later crashes it had never seen, with the rule written down before we looked: it fired at 14.3x and 13.3x relative risk.

The information needed to avoid it existed. Nothing was computing it, and nothing could have been checked if it had.

One honest note, because it belongs next to that number: our own ablation showed the flag reduces mostly to raw distance-to-liquidation, which is a figure the venue already publishes. So the study validates the quantity, not our arithmetic on it. That distinction is in our paper too.

What it does

Quiver is a risk engine that AI agents can pay per call, and that shows its work.

Twenty-two services are live, priced between $0.005 and $0.05 per call: liquidation and funding risk, position sizing with probability of ruin, options greeks and scenario margin, LP divergence loss, stablecoin treasury concentration, execution-quality and sandwich detection, cross-venue portfolio risk, plus market intelligence for options, DeFi and prediction markets.

The point is not the maths. The maths is standard and old. The point is that you never have to take our word for the answer.

Every response carries an envelope with the echoed inputs, the exact code identity, a content hash, and self-checks. Seven of the twenty-two go further and return a Plonk zero-knowledge proof over BN254. So a caller has four independent ways to check us:

  1. Clone the repo, rebuild, and confirm the engine hash matches the codeHash in the response.
  2. Re-run the open engine on the echoed inputs and get the same number, byte for byte.
  3. Verify the zk proof against the published verification key, without re-running anything.
  4. Hand the proof to a contract and let the EVM decide.

Route 4 removes us from the loop completely. QuiverProofRegistry at 0xd50A91E36673443749Ee22031cb2Ff09d4Bb8D60 on X Layer, with a PlonkVerifier at 0x59F6Aa860eE0d26Db873f7c7015CE869170b3b25, checks a Quiver proof inside the EVM. Both are live, and we published both directions: a proof accepted in transaction 0x50397d71…f368a at block 66,412,787 costing 468,459 gas, and the same proof rejected in 0x97502c78…4cb4aac at block 66,412,794 costing 333,155 gas, after we moved the certified price by a single grid step.

That rejection is the part we care about most. A verifier that cannot refuse proves nothing, so we shipped the refusal alongside the acceptance rather than only the happy path.

Payment is x402 over HTTP 402, on two rails: USD₮0 on X Layer and USDC on Base. No API keys, no accounts, no subscription. An agent with a wallet pays for one answer and gets one answer.

The one piece of maths worth showing

Impermanent loss for a constant-product pool at price ratio $r$ is usually written

$$ IL(r) = \frac{2\sqrt{r}}{1+r} - 1 $$

Almost everyone forecasts the expected loss by numerically integrating that against a lognormal price distribution. We don't, because the integral has a closed form that nobody seems to use. Substituting $r = e^{X}$,

$$ \frac{2\sqrt{r}}{1+r} = \frac{2}{e^{X/2} + e^{-X/2}} = \operatorname{sech}!\left(\frac{X}{2}\right) $$

and under the martingale condition $\mathbb{E}[r] = 1$ with $X \sim \mathcal{N}(-v/2,\, v)$,

$$ \mathbb{E}\left[\operatorname{sech}!\left(\frac{X}{2}\right)\right] = \mathbb{E}\left[\sqrt{r}\right] = e^{-v/8} $$

so the expected impermanent loss over total variance $v$ is exactly

$$ \mathbb{E}[IL] = e^{-v/8} - 1 $$

We checked it against an independent fine midpoint rule at $v = 0.5, 1, 5, 20, 50, 100, 200$ and it agrees to $1.3 \times 10^{-13}$ or better. Certifying the closed form inside a circuit costs 3,854 constraints instead of the 36,613 the quadrature version needs. That is the difference between a service you can prove and one you cannot.

How we built it

The engine is plain Node.js with no framework magic, because a stranger has to be able to re-run every line of it. Determinism is enforced rather than hoped for: the engine hash q1-e1fa99d08887d6cc is computed by walking every file under src/engine, and /build publishes the hashing rule alongside the hash, so you can verify the rule describes the tree it claims to hash.

The proving stack is circom 2.2.3 and snarkjs 0.7.6, Plonk over BN254, compiled against the public Hermez powers-of-tau ceremony. We chose Plonk over the faster Groth16 deliberately: Groth16 needs a per-circuit ceremony, ours would have had exactly one participant, and it would have been our own machine. A proof under that setup is forgeable by us. Plonk costs 13% more gas and 22x the proving time, and it does not ask anyone to trust a ceremony we ran alone.

Proofs are built in a forked child process. On the main thread, proving froze the event loop for 506 ms and pushed production p95 to a full second — for callers who had asked for no proof at all. After the fork, p95 came back to about 400 ms.

Everything is gated. A pre-deploy preflight runs 37 checks against the live service, npm test runs 386 tests, and a docs-consistency tool holds 266 documents to facts read from the running system rather than from each other.

Challenges we ran into

A green check that could not fail. Our x402 payment rail was completely dead for at least seventeen hours and every instrument we owned said it was healthy. The listing validator passed. The platform's compliance checker passed 22 of 22. Every endpoint returned a well-formed 402 in under half a second. What none of them could see: settlement never landed. The facilitator answered success: true with no transaction hash, our code correctly refused to serve, and every buyer got a payment challenge instead of an answer. We found it in the container logs, and confirmed it by scanning 63,000 blocks of the token's transfer log and finding zero transfers arriving. The lesson is narrow and permanent: a correct payment challenge tells you nothing about whether payment lands.

One character. A single em dash in an HTTP response header crashed the container. Node rejects any non-Latin-1 byte in a header value, the exception landed in an async Express handler with nothing to catch it, and it killed the process. Seven of twenty-two calls failed in the first full paid sweep before we found it.

Our own instruments lying to us, repeatedly. A gate compared two JSON documents with JSON.stringify and reported a mismatch that was only key ordering. A sweep fired sixty-six requests at a service that rate-limits at sixty a minute and read the resulting 429s as broken endpoints. A proof counter read a field on every row including failed ones and reported eight proofs where seven were served. Each one was found, fixed in the instrument, and written down.

The defect that kept coming back. Twice, the engine published a display-rounded number while the circuit certified the rounded value — which means the proof was true about a slightly different position than the one the caller saw. Both times the fix was the same: recompute at full precision from the snapped inputs, and add a guard that refuses rather than certifies. Both times it was found by sweeping against the real engine, never by re-deriving the formula, because a formula always agrees with itself.

What we learned

Determinism is not a feature you add. It is a discipline you enforce, and the enforcement has to be able to fail. Nearly every serious defect here was caught by an instrument that could report bad news. Nearly every one that slipped through was hiding behind an instrument that structurally could not.

We also learned how much of "verifiable computation" is really about the inputs. A zero-knowledge proof of a liquidation price is airtight about the arithmetic and says nothing about whether the mark price we were fed is the mark price the venue published. We publish that limit instead of papering over it: services reading live venues ship a signed observation envelope that states plainly it is our word, and only the deterministic services claim reproducibility. Closing that gap needs zkTLS or a hardware enclave, and we say so rather than implying we already did it.

What is measured, and what is not

Every number here was measured, not remembered.

  • 22 services live, 22 of 22 passing the platform's own x402 compliance checker
  • 7 services emitting Plonk zk proofs, verifiable off-chain and inside the EVM
  • A full paid sweep of all 22 services with real money, reconciling exactly: 0.360000 USD₮0 claimed by receipts, 0.360000 out of the buyer wallet, 0.360000 into the operator wallet, with an independent scan of the transfer log finding every receipt hash present and none missing
  • 386 tests, 381 passing, 0 failing, 5 skipped
  • 37 pre-deploy checks

And the counterweight, which matters more than any of it: almost nobody is paying us. Over the service's whole life, eight external addresses have sent 39 payments totalling 0.360000 USD. Against that, our own quality-assurance desk accounts for 1,785 calls and about 20 USD. That is roughly fifty-five parts our money to one part theirs. The engineering is far ahead of the distribution, and pretending otherwise would undermine every other claim on this page.

What's next

Three things, in order, and each one can fail publicly.

1. Fix what our own paper calls wrong. The cross-venue portfolio service uses an isolated-margin model that our documentation itself describes as wrong by orders of magnitude for cross-margin accounts. That is a concrete, admitted, checkable repair.

2. Close the input gap instead of describing it. zkTLS or a hardware enclave, so a proof covers where the number came from and not only what was done to it.

3. Find out who actually pays — with an instrument that can say no.

That last one is the real problem, and we treated it like a research question rather than a marketing one. We built a discovery instrument and ran it: fifteen domains where ordinary people move money, crossed with seven surfaces where they leave a trace (money already spent badly, post-mortems, published loss data, complaint databases, spreadsheets and glue, court and ombudsman rulings, job listings). 105 cells, every one worked. The rule was that nothing may be proposed from imagination — every item has to trace to a source that was actually retrieved, and name what would prove it wrong. It returned 313 real, evidenced problems, spread evenly across all fifteen domains, and it passed 21 of 21 blind control cells.

Then it refused our own result. Its thresholds were frozen in a dated file before any evidence was collected, and one of them said: if more than four candidates survive the cheap filters, assume the filters are broken. One hundred and thirty-two survived. So the cycle is void, and we can name the filter that failed — the one that checks what happened when somebody else made a similar offer killed nothing in 168 attempts, because we had built it to require a documented failure, and failures don't get written up.

None of those 313 problems is named here. Not one has been through the deep gates yet, and naming one as our next product would be exactly the failure the instrument exists to prevent — in a project whose whole argument is that you should not take a number on trust.

The step that actually decides it is not a smarter model. It is ten real contact attempts per surviving problem, with a reply as the threshold. A reply is a physical event produced by somebody who is not us, and no amount of confident reasoning manufactures one.

Built With

Share this project:

Updates

Submission history