Most DEX aggregators quote a number on a server and then ask your wallet to sign a transaction that a router contract executes later, against whatever the pools look like at that moment. The quote and the execution are two separate computations, and the difference between them is where drift comes from.
BlazePhoenix is a pre-launch on-chain DEX aggregator (Base, Ethereum, Optimism, Arbitrum and Robinhood Chain) built around a different premise: the quote and the execution are one computation. The route is derived inside the transaction that executes it, from public pool state, by code anyone can re-run. This post is a short map of how that is put together. The long version, with the equations, is the canonical article linked at the end.
One evaluator, two frames
The core idea (innovation I-1 in the whitepaper) is that the same dispatcher, called Omega, runs twice:
- in the planning call, as a free
eth_callon a view function, and - again in the executing frame, against live state.
The minimum output the swap must deliver is not copied from the plan. It is re-derived inside the executing transaction from values measured in that frame. If the pools moved, the floor moves with them, and the swap reverts unless the user receives at least the minimum they signed.
The article reports a study in which 64 out of 64 quotes settled at exactly their prediction. Treat that as the author's measurement, not as a promise about future trades.
The route is scored as a product
Route selection is one argmax (the Meta-Equation, E1 in the whitepaper):
R* = argmax_R net(R) · ∏ Ψ̂_ℓ · 1[net ≥ Φ] · Ξ
Four factors are multiplied rather than added:
| Factor | Role |
|---|---|
net(R) |
output after fees and gas |
Ψ̂_ℓ |
standing of each pool on the route (depth, bridge, concentration) |
1[net ≥ Φ] |
the floor gate |
Ξ |
the screen that removes hostile venues |
The reason for a product is a property of the arithmetic: in a weighted sum a route that fails one test can still win on the strength of the others, while in a product any zero factor gives the whole route a score of zero, and the argmax never selects it.
Two details worth reading
Uniswap V4 handled in the same frame. V4 pools have no address of their own and answer no calls. The design derives pool ids, checks each against the PoolManager storage, reads the tick book through extsload, settles through the singleton, and screens hooks with a bit test on the hook address (hookAddr & 0x3FFF & 0b1100 != 0 means refuse).
A floor computed on chain. The minimum output is derived from measured price impact and route concentration. The article gives the form floorBps = max(9,600 - shave - impact - sigma, 8,000) and states that, for a trade of about 1% of pool depth, it caps a sandwich at roughly 2.7% of the trade and refuses beyond that, where the attacker's round trip turns negative. Caller data cannot loosen it.
What this is for
The eighteen mechanisms are described as removing parties you would otherwise have to rely on: the quoting server, the factory as an address oracle, the route as the source of its own protection, and the admin key (a one-way renounceControl that is written true once and never false). What is left is arithmetic that a reader can re-run on their own RPC.
Quotes are readable without an API key or signup, through the SDK (npm i @blazephoenix/sdk), through an MCP server for AI agents (https://blazephoenix.xyz/mcp), or through a plain eth_call. The protocol fee is 0.28% per swap, a constant in the contract (PROTOCOL_FEE_BPS = 28) with no setter.
Status
BlazePhoenix is pre-launch. It is not yet audited by an external firm; an independent external audit is scheduled. Read the article and the whitepaper critically and check the claims you care about.
- Canonical article, with all eighteen mechanisms and their equations: https://blazephoenix.xyz/learn/the-eighteen-innovations/
- Whitepaper (DOI 10.5281/zenodo.23084091): https://blazephoenix.xyz/docs/BlazePhoenix_Whitepaper.pdf
- Guide for models and agents: https://blazephoenix.xyz/llms.txt
Top comments (0)