Connect ›
The Meta-Equation — the whitepaper in one equation

Whitepaper v2.3

Mitra · v2.3, 2026-09-24 · CC BY 4.0 · PDF · full text (markdown)

Download PDF ↓.md

PDF editionsPTESFRDERUTRARHIJAZHKOIDBN

Full text inPortuguêsEspañolFrançaisРусскийالعربية中文한국어日本語Bahasa Indonesia

Digest inPortuguêsEspañolFrançaisDeutschРусскийTürkçeالعربيةहिन्दी日本語中文한국어Bahasa Indonesiaবাংলা

Abstract

BlazePhoenix-Dex is an on-chain liquidity aggregator built on one claim: a quote and its execution are the same computation. The route is derived inside the transaction that executes it, from public pool state, by a stateless library any reader can re-run; the number that binds at settlement is re-derived by the same dispatcher in the executing frame. There is no routing service, no price oracle, no keeper and no upgrade path. This paper specifies the five contracts — Core, Hub, Solver, Router, Quoter — and the operators of the Meta-Equation: the Eightfold Dispatcher Ω, the Deterministic Derivation 𝒟, the Iron-Law floor Φ, the Vitality Field Ψ and the anti-scam projector Ξ. Behind them sits one discipline, Metrological Design: measure every coordinate that can be measured, and make the rest monotone so a false input hurts only its supplier. Every guarantee is stated with its enforcement site and its limit. The verification apparatus is printed with its denominators: 1,609 declared tests across 236 files, 268 of 268 curated mutants killed, 14 of 15 mutants aimed at 43 stateful invariants noticed, covering arrays of strength 2 (63 rows, 258 pairs) and 3 (168 rows, 1,636 triples), 14 + 5 metamorphic relations, three optimiser builds in agreement, and a 240-sample study of how a quote ages. Eighteen named innovations carry the design, from the Meta-Equation to immunity by exhaustion; each is catalogued with its mathematics before the specification begins. The generation live on Base, Ethereum, Optimism, Arbitrum and Robinhood Chain is V1; this paper specifies V2, exercised end to end on forks of live liquidity on every chain it serves.

The eighteen innovations

Each is specified in the paper with its equation and the test that checks it. The map, with the mathematics: /learn/the-eighteen-innovations.

  1. I-1 Quote ≡ Executionone evaluator plans and settles every leg
  2. I-2 The on-chain solvera trustless best route for a free eth_call
  3. I-3 The Meta-Equationthe whole aggregator as one product-form maximisation
  4. I-4 The Eightfold Dispatcher Ωsix venue kinds, four families, one table
  5. I-5 Deterministic Derivation 𝒟pools computed by CREATE2 arithmetic
  6. I-6 Uniswap V4 in-framederive, prove, price, screen and settle V4 on chain
  7. I-7 The Solidly stable solverk = x³y + xy³, bounded Newton, fail-closed
  8. I-8 The Monoslota pool's routing state in one 256-bit word
  9. I-9 The Self-Healing Registry and Ψthe protocol learns liquidity by trading it
  10. I-10 The Capital-Anchored Splita split never pays less than the best single pool
  11. I-11 The Iron-Law floor Φa minimum re-derived on chain at execution
  12. I-12 Measurement at every seamevery transfer is a measured balance delta
  13. I-13 The One-Callback Doctrineone fallback for every V3-shaped venue
  14. I-14 The Surplus Rule and immunity by exhaustionno fee term on the quote–fill gap
  15. I-15 The byte–gas exchange rate ρ*the cheapest door on every chain
  16. I-16 The anti-scam projector ΞV4 hooks screened by address bits, never called
  17. I-17 The One-Way Doorrenunciation written in bytecode
  18. I-18 Metrological Designevery number beside its denominator

The paper, section by section

The opening paragraph of each section. Full text: /whitepaper.md · PDF.

Status: what this paper describes, and what is deployed

The Version 2 tree this paper describes is in the repository and is not deployed; the deployed generation is Version 1, pinned by codehash on every network so the two are never conflated. Every number in the paper is measured on main 8949a9d and printed beside its denominator; full text in English at https://blazephoenix.xyz/whitepaper.md.

§1 The problem: a quote is a promise someone else computed

Imagine selling a car in a city with twenty dealers. A good broker visits all twenty, finds the best price, and perhaps splits the sale across two of them. Most on-chain "brokers" check prices on their own database — possibly stale — and show you a result. You cannot verify that they looked at all twenty, or that they showed you the best one. You can only verify that they have, so far, been honest.

§2 The answer and the discipline

BlazePhoenix-Dex has an entry point that takes six values — the two tokens, the amount, your minimum, a recipient, a deadline — and works out the route inside the transaction that executes it, from pool reserves that are public state: which venues, how much to each, in what order. Because the route was derived from public state by public code, anyone can re-derive it.

§3 The Meta-Equation and the dependency budget

The whole aggregator can be read as the maximisation of one expression. Given an input token t_in, an output token t_out and an amount x, the Solver searches the admissible routes for the one maximising net received value, subject to a feasibility floor and an anti-scam gate.

§4 The Eightfold Dispatcher Ω

Plain: one function that knows how to price every kind of pool. Precise: universalQuote(QuoteCtx, amountIn) in the Core is the quote dispatcher for the Solver and for the Quoter's preview; it returns the expected output and a token-denominated depth for the split allocator, and a pool it cannot price returns zero and is dropped before anything is sent.

§5 Uniswap V4 end to end

Uniswap V4 is not a new pool contract; it is a new shape of venue, and it invalidates four assumptions every router built between 2020 and 2024 rests on. Pools have no addresses — they are entries in one singleton's storage, keyed by a hash. Arbitrary code runs inside the swap — a hook executes at defined points of the settlement the router is performing. Fees need not be constant. And pools may hold the chain's native currency, which has no balanceOf. This section answers all four structurally, so that a V4 leg is — to the Solver, to the floors and to the trader — indistinguishable from any other leg.

§6 The Solidly solver

Some invariants have no closed form simple enough to reproduce safely, and reproducing them is exactly the replication risk the protocol refuses elsewhere. For such venues the dispatcher asks the pool, through the narrowest honest channel the venue exposes — and holds a replica in reserve for forks that do not answer.

§7 Deterministic Derivation 𝒟

Before a pool can be quoted it must be found. The industry's answer is to ask: a call to the venue's factory reads a storage mapping and returns an address, and the caller takes the factory's word. BlazePhoenix supports that answer — four factory-call modes cover the venues whose deployments are not reproducible — and prefers a stronger one wherever the arithmetic allows: compute the address, with no external call. An address that is computed can be verified by anyone with the same three inputs; an address that is fetched can only be trusted.

§8 The Monoslot

Storage is the dominant cost of doing anything on the EVM: a cold SLOAD is 2,100 gas, and a registry that scattered a pool's attributes across separate slots would pay it again for every attribute, for every pool, on every route evaluated. BlazePhoenix packs a pool's entire routing state into a single 256-bit word — the Monoslot — read once and decoded by pure arithmetic.

§9 The Self-Healing Registry and the Vitality Field Ψ

Most aggregators know their venues because a keeper indexes pools off-chain and pushes lists on-chain — a trusted process, a staleness window and an operational dependency, three things a protocol that solves routes on-chain cannot accept. BlazePhoenix takes the opposite stance: the registry learns liquidity by trading it.

§10 Routing and the Split Allocator

A constant-product pool prices by one rule: its two reserves, multiplied, may never shrink. Pour Δ in with fee retention γ (a 0.30 % venue fee means γ = 0.997) and you receive yγΔ / (x + γΔ), with your own input in the denominator: the more you push through one pool, the worse each further token pays. Slippage is arithmetic, and so is its cure: splitting the same order across pools of the same pair moves each pool less.

§11 The execution layer and the Iron-Law floor Φ

The Solver proposes; the Router disposes — atomically, or not at all. The Router is the only contract that moves funds, holds none between transactions, and is built on one principle: one mechanism per concern, applied universally. It assumes nothing it can measure.

§12 Quote surfaces, and how a quote ages

There are two places a number called "your quote" can come from, and they are different code paths: the Quoter, a read-only preview contract an interface calls before you sign, and the in-frame path, where the Solver and Router compute quotes inside the executing transaction. §4.4 gave the per-kind truth; this section gives the surfaces and measures the gap between them.

§13 Fee policy: the two regimes and the Surplus Rule

Plain: the protocol takes 0.28 % once, from one measured amount, in a coin the treasury wants to hold, and counts that it did. Precise: PROTOCOL_FEE_BPS = 28 is a compile-time constant in the Core with no setter anywhere in the deployed bytecode; the fee is mulDivUp(base, 28, 10,000) — rounded up, so a zero fee is unreachable for any non-zero base — split TREASURY1_SHARE = 3,000 bps to the first treasury and the remainder to the second (computed as fee − t1, so the two always sum to the fee with no dust), the treasuries fixed at construction and freezable for ever by the One-Way Door.

§14 Security model

Plain: the Router holds nothing between transactions, every swap is all-or-nothing, and each attack class this repository has considered is answered by a named check or named as out of scope. Precise: the threat catalogue is docs/assurance/threats.json, 23 classes drawn from the public record of exploits; each names the guard symbol that refuses it, and a CI script fails the build if the symbol leaves src/ or the named test leaves test/. Coverage of a catalogue is a floor on what has been considered, never a ceiling on what exists.

§15 The verification apparatus, measured

Plain: every number here is printed beside the denominator it was measured against, is recomputed from a clean checkout by a script or a named forge command (Appendix C), and is followed by what it does not establish. Precise: the tree measured is main at 8949a9d and the branch that became it, on the release profile (optimizer_runs = 300, via_ir), 2026-09-05.

§16 Architecture and sizes

Plain: five contracts, one of which is pure mathematics imported by the other four, and no piece of mathematics is defined twice. Precise: the Core is a stateless library with no storage, no owner and no upgrade path; Hub, Solver, Router and Quoter import it and none redefines a primitive, so one audit of the mathematics covers every consumer.

§17 Measured performance

Plain: everything in this section was measured on forks of real chains — real venues, real reserves deposited by strangers, one bytecode — and is labelled as exactly that. Precise: a number appears here only if a public harness in the repository reproduces it; the harness, the chain and the date are printed beside it. A fork measurement is evidence about behaviour, not a deployment record; the deployment record is §19. The measurements of §12 and §15 are from 2026-09-05; the campaign of this section was run in August 2026 and its harnesses are in test/fork/.

§18 The DEX, stripped to the bone

Seventeen sections of mechanism, reduced to one page. One job: take two tokens, an amount, your minimum, a recipient and a deadline, and return the most output the chain's public liquidity can deliver — or refuse, with a code that says why. Five contracts share one mathematics (Core, Hub, Solver, Router, Quoter); six venue kinds are priced by one dispatcher; four doors reach one executor; three floors and your own minimum stand under every trade; one 0.28% fee is compiled in, and nobody can move it.

§19 Deployment status

This paper documents the repository, and the repository is canonical: where this text and the source disagree, the source wins. Two generations exist and they are never conflated.

§20 Token — BZPX

One billion BZPX, fixed for ever, as a plain ERC-20: 18 decimals, no mint path, no fee-on-transfer, no rebasing, no transfer hooks, no pause or blacklist. Allocation in Version 2.3: market liquidity 520,000,000 (52%), staking emission 180,000,000 (18%), Airdrop & Bounties 130,000,000 (13% — the former 50,000,000 airdrop, the former 50,000,000 research pool and 30,000,000 moved out of market liquidity), team 103,000,000 (10.3%), partners 60,000,000 (6%), marketing 7,000,000 (0.7%).

§21 Research programme and security record

Before this project had a research programme worth the name, independent researchers read the source hostilely — unasked, with nothing promised — and disclosed what they saw privately. The code this paper describes is the code that survived their reading. What each of them reported, and what became of it, lives where such records belong: in the repository's SECURITY.md and SECURITY_HALL_OF_FAME.md, next to the code, where every entry can be checked in both directions. This section records who they are, what hostile reading pays, and the shape of what it found.

§22 What you must trust, and what you need not

Every protocol claims to be trustless; almost none can enumerate its exceptions. Here is the full list, each power stated with the line that bounds it.

§23 Related work

Routing. Angeris, Evans, Chitra and Boyd cast routing across constant-function market makers as a convex program whose optimum equalises marginal prices across venues; Diamandis, Resnick, Chitra and Angeris give an efficient dual-decomposition algorithm for it.

§24 Conclusion

We set out to build an aggregator on one discipline — measure, do not believe — and to hold it at every point where a number could instead have been taken on someone's word: the route, the price, the floor, the fee base, the venue set, the pair a pool claims to trade, even the protocol's own cost model.

How to cite

Cite a numbered object, not the document: the appendices give every primitive equation (E1–E26) and enforced invariant (INV-1–INV-22) a stable identifier. The staking engine keeps its own enumeration in its own paper. Machine-readable claims from the paper live in /facts.json; the zero-argument on-chain ones re-execute live at /api/verify.

Cite this document

Mitra. (2026). BlazePhoenix Technical Whitepaper (Version 2.3.0). BlazePhoenix. https://doi.org/10.5281/zenodo.23084091

@misc{blazephoenix_whitepaper_2026,
  author       = {Mitra},
  title        = {BlazePhoenix Technical Whitepaper (Version 2.3.0)},
  howpublished = {\url{https://blazephoenix.xyz/docs/BlazePhoenix_Whitepaper.pdf}},
  year         = {2026},
  month        = {10},
  note         = {Text CC BY 4.0. Machine-readable text: https://blazephoenix.xyz/whitepaper.md}
  doi          = {10.5281/zenodo.23084091},
  url          = {https://blazephoenix.xyz/research/whitepaper/}
}

DOI: 10.5281/zenodo.23084091 — the Zenodo record archives this version permanently. · Machine-readable text: /whitepaper.md

Questions, a partnership or a bug to report? Contact us or email contact@blazephoenix.xyz