Wired is not demonstrated: the difference between a venue family the code supports and one exercised against real chain state

Integration counts are the most reliably inflated number in this industry, and the inflation is usually not a lie. It is a category error. "Supported" is treated as a single predicate over a venue family when it is the conjunction of three independent ones, and a table that reports any of the three as if it were all of them will overcount without anybody deciding to overcount.

The three stages are: discovery has to be able to find the venue, the solver has to be able to price it, and the router has to be able to execute against it. A family that fails any one of the three is not supported. Listing it as such is the ordinary way this number gets inflated, and it is checkable — the failure modes are different at each stage and each leaves a different trace in the source.

The decomposition, and what each stage can fail at independently

Discovery failure means the scanner never emits an identifier for that family, so no route is ever assembled that uses it. The pricing and execution code can be present and correct and it will never run. This failure is invisible from the code alone: every function you read works.

Pricing failure means the solver produces a number for the family that does not match what the venue will actually do. This is the dangerous stage, because a wrong model produces a confident number rather than an error. Execution failure means the swap call itself does not work — the loudest and least harmful of the three, because it reverts.

Applied to our own venue table, five of eight kinds work end to end and are what the protocol genuinely trades against: constant-product, concentrated-liquidity, stableswap, the Solidly-style volatile/stable dual, and the singleton style. The other three fail at one stage each, and they are the honest part of the table.

kind                    found     priced                executed
constant product         yes       yes                   yes
concentrated liquidity   yes       yes                   yes
stableswap               yes       yes                   yes
Solidly dual             yes       yes                   yes
singleton                yes       yes                   yes
dynamic fee              yes       FLAWED (fee = 0)      yes
weighted-pool alias      yes       as constant product   as constant product
cryptoswap               NO        yes                   yes

The three failing rows, named

The cryptoswap kind is unreachable. The scanner that discovers this family labels everything it finds as the plain stable kind, so the cryptoswap identifier is never emitted by discovery. The pricing and execution code for it is present and correct; nothing ever produces a route that uses it. It is dead weight, not a feature — and a reviewer reading only the pricing library would conclude the opposite.

The weighted-pool kind is an alias, not an integration. There is no weighted-pool math anywhere in the source. A venue registered under that identifier is priced and executed as an ordinary constant-product pair, which is correct behaviour only if the venue actually is one. This is the row we would most like to have found differently, and mislabelling it as support would be worse than dead code: dead code does nothing, while a wrong model produces a number a user acts on.

The dynamic-fee kind prices with the wrong fee. Venues of that family are registered with their fee forced to a sentinel value of zero, and that zero flows into the concentrated-liquidity quote. The quote therefore prices the trade as though the venue charged nothing, while execution asks the venue and pays whatever its live fee turns out to be. The realised output is short by exactly that fee, systematically and in one direction. It is reachable, it executes, and its quote is optimistic — which is a genuine quote-versus-execution seam in a protocol whose central claim is the absence of one. It was found while sourcing the venue chapter and is reported here rather than after somebody else finds it.

The second, sharper distinction: wired versus demonstrated

The table above says which families the code supports. It does not say which have been observed working against real chain state, and those are different claims — the first is a property of the source, the second is a property of the evidence. Fork tests exercise swaps for four of the five working families: the constant-product and concentrated-liquidity families, the stableswap family, and the singleton family. There is no fork test that swaps through the Solidly-style family, none for the dynamic-fee family, and none for the aliased row. One fork job's title advertises a family whose contract does not appear anywhere in its match list.

So: five families are wired and correct by construction, four have been demonstrated. Publishing both numbers costs us the larger one and is the only defensible way to publish either. A reader who wants a single number should take four.

Why the non-fork test suite cannot close this gap

The obvious objection is that the whole test suite covers all of it, and the objection fails for a structural reason worth understanding, because it generalises well beyond our repository. The mock venues used throughout the non-fork suites compute their output by calling the very same library function the quoter calls — one of them says so in its own header, that quote and execution agree by construction.

Every quote-versus-execution assertion outside the fork tests therefore reduces to checking that a function equals itself. It cannot fail. It is not a weak test; it is a test that establishes nothing at all about the property this protocol most wants to claim, and it will stay green through any change that breaks that property in the same way on both sides. A green run proves that the policy invariants and the emission mathematics hold. It does not prove that the quote a user is shown is the one that executes.

The exception is worth naming because it is the strongest test in either repository: one fork suite prices against a real venue's own pricing function on real chain state, which is a genuine independent oracle rather than a mirror. That single suite is the entire evidentiary basis for the demonstrated column, which is why the column is four and not eight.

The evidence ladder, and what a green badge is worth

The general form of the argument is a ladder, and every rung is a strictly weaker claim than the one above it. Code exists for a family. The code type-checks and deploys. A unit test exercises it against a mock. A unit test exercises it against a mock that is not derived from the code under test. A fork test exercises it against the real contract at a live block. A fork test pinned to a specific block, so the result is reproducible rather than drifting with the chain.

Two of our sixteen fork suites are pinned to a specific block; the rest would drift with the chain, which means a future failure could be a chain change rather than a regression and a future pass could be luck. And on the verification side generally, what matters is which jobs can block a merge, which merely report, and which pass without having tested anything. In the router repository the build, the non-fork suite, the fork tests, a bytecode size guard set at 24,000 bytes — deliberately stricter than the 24,576-byte protocol limit — a static-analysis gate that fails on high-severity findings, and two symbolic proofs under Halmos all block. A third symbolic specification times out rather than completing, and a timeout is not a proof. A commercial verification job exits successfully when no licence key is present, so a green check there means the job was skipped. In the staking repository there is no prover and no static analyser at all.

How to apply this to any protocol, including this one

For each integration a protocol advertises, ask the three questions separately and demand a different artefact for each. For found: point me at the discovery code path that emits this family's identifier, and at a transaction where it did. For priced: point me at the pricing branch, and tell me whether it calls the venue's own function or reimplements it — reimplementation is where quotes and executions come to disagree, and asking removes an entire class of error at the cost of a second call. For executed: point me at a fork test, pinned to a block, that swaps through it.

Then ask the question that catches the tautology: is the thing the test compares against derived from the code under test? If the expected value and the actual value flow from the same function, the test is a mirror. That single question invalidated most of our own quote-versus-execution coverage, and writing the missing test — one that compares a preview against an actual execution — is the single highest-value piece of work outstanding on our codebase.

Related engineering

• Which DEXes BlazePhoenix routes across, on every chain — and how to verify it yourself ›
• A quote is a statement about the past: what an in-transaction solver fixes, and what it does not ›
• Verify your instrument: the research discipline that decides whether your findings are real ›
• On-chain or off-chain? The one difference that decides who you trust ›