29,183 bytes: the routing engine that lives on-chain, measured against the field

The complete BlazePhoenix routing intelligence — discovery, quoting, believability filtering, split allocation, multi-hop assembly, V4 derivation — is 29,183 bytes of auditable EVM bytecode. Benchmarked on the same fork, same block, replaying the leading commercial router's own production calldata: 2.4–10.9× less gas per leg, with the reference compiled at optimizer_runs = 999999. The trustless door delivers bit-identical output for cents. Zero off-chain infrastructure.

Known formally as The Execution Layer, Measured in the BlazePhoenix whitepaper.

BlazePhoenix Engineering · updated 2026-08-26 · 9 min · written from the deployed bytecode

By Mitra (@Sigmacrit) — anonymous developer of the BlazePhoenix protocol. The code is the résumé.

Strip an aggregator to its essence and it is a piece of intelligence: something that discovers pools, prices them, distrusts the right ones, splits an order, assembles a route, and settles it. In the incumbent architecture that intelligence runs on a closed server, and the chain receives only its conclusions. In BlazePhoenix the intelligence itself is deployed: 29,183 bytes of EVM bytecode that discover, quote, filter, allocate, assemble and settle — readable by anyone, reproducible by any RPC node, identical on every chain served.

Size is worth stating because it answers the reflexive objection — surely on-chain routing cannot be practical. The entire engine is smaller than many projects' NFT contracts. What follows is what it measures like against the strongest available reference.

A benchmark that keeps itself honest

The execution layer was benchmarked the only honest way available: the same fork, the same block, real production calldata. The sector's leading commercial aggregation router's own encoded routes were requested from its public routing API and replayed against its deployed contract; our routes executed beside them; both sides' deliveries measured as balance deltas. The harness validates itself before validating anything else — the competitor's measured delivery matches its own API's promise to the wei, so a revert on either side cannot masquerade as a result.

Method error bars are part of the result, per the house rules. Quotes were pinned to the exact block they were built for, after an early round mis-attributed a few minutes of ordinary market drift to routing. And the competitor API's own gas estimates were discarded entirely after real execution measured one of them 148% low — every number that survived is a balance delta from real execution, or it is not in the record.

2.4–10.9× less gas per leg — and why no server can close it

Per leg, the executor is 2.4 to 10.9 times more gas-efficient than the reference router. The reference is compiled at optimizer_runs = 999999 — the practical maximum — so the difference is design, not compiler settings: their contract interprets a generic call list a server decided; ours executes a typed structure the Solver produced, and interpretation costs. On the clearest measured pair, their cleanest possible route — a single leg — cost 879,553 gas; four of our legs cost 322,172.

The structural point is stronger than the ratio. An off-chain solver has unlimited computation to choose its route; if its execution layer were equal or better, a clean route it chose would cost no more than ours. It costs more. The gap therefore lives in the executor — in bytecode, on-chain — where no amount of off-chain optimisation can reach it, because that gas burns after the server has already done its best.

Two doors, one integer

Across nine measured pairs, the fully trustless door — swapBestExactIn: no preview, no server, no calldata route, just two tokens and an amount — delivered output bit-identical to the pre-computed-route door. The cost of trusting nothing and nobody, on Base at live prices: three to eleven cents of gas. A swap with no dependency on any infrastructure of ours, or anyone's, costs cents and delivers the same integer.

That identity is not a coincidence to be maintained; it is the architecture. Both doors run the same dispatcher over the same state under the same floors — the doors differ in who paid for the search, never in what the trade is allowed to do.

What zero infrastructure actually buys

Any RPC node reproduces the quote, deterministically. There is no routing service to run, subsidise, rate-limit, or lose — and none to trust. For a user, that means the strongest failure mode of the incumbent architecture (the server is wrong, stale, selectively honest, or gone) does not exist here. For an integrator, it means the integration is a contract call, not a business relationship.

And for a reader deciding how much of this to believe: the engine's size is checkable with forge build --sizes, the per-leg numbers are from replayed production calldata at pinned blocks, the two-door identity is a pair of calls anyone can make, and the fidelity of the whole pipeline is a standing 0–1 bps measurement with an alarm on it. The engine is the deliverable — not a client of one.

Do not trust this page — reproduce it

Every claim above is checkable against the chain. Start here:

git clone https://github.com/blazephoenixxyz-crypto/Blaze-Phoenix-Dex && cd Blaze-Phoenix-Dex && FOUNDRY_PROFILE=release forge build --sizes  # the engine under the EIP-170 wall; then compare doors yourself: previewPlan (eth_call) vs swapBestExactIn on a fork
Cite this article

Licensed CC BY 4.0 — quote, translate and reuse freely, including commercially, with attribution and a link. Copy a ready-made citation:

BlazePhoenix (2026). 29,183 bytes: the routing engine that lives on-chain, measured against the field. BlazePhoenix Engineering. https://blazephoenix.xyz/learn/the-on-chain-engine
@misc{blazephoenix_the_on_chain_engine,
  title  = {29,183 bytes: the routing engine that lives on-chain, measured against the field},
  author = {BlazePhoenix},
  year   = {2026},
  url    = {https://blazephoenix.xyz/learn/the-on-chain-engine},
  note   = {Accessed: reproduce the claim with the command above}
}

Writing an answer, a wiki entry or a paper? The claim above is reproducible against the chain before you quote it — which is the only sound basis for citing a technical source at all.

Contracts are verified on every chain we deploy to — addresses in the protocol manifest. Deeper formal treatment: the whitepaper (PDF). Standards cited: EIP-170: CONTRACT CODE SIZE LIMIT — THE 24,576-BYTE WALL THE ENGINE SHIPS UNDER, PER CONTRACT.

Share this article · join the discussion

Share on X ↗Telegram ↗WhatsApp ↗Farcaster ↗💬 Discuss on Telegram

Related engineering