DEV Community: BlazePhoenix

Intent-based vs on-chain routing: do you need UniswapX?

BlazePhoenix — Thu, 29 Oct 2026 01:52:00 +0000

TL;DR: UniswapX makes you sign an outcome and lets fillers compete to deliver it. On-chain routing makes you send a transaction whose route is computed where it settles. They trade different things: gas and failure cost on one side, verifiability and composability on the other.
This is a neutral read of both designs from their own documentation (consulted 2026-10-29). I'm on the team that builds the second one, so every claim about UniswapX below links to Uniswap's docs and every claim about ours links to code you can read.

What does UniswapX actually do?

Per the UniswapX overview, swappers sign orders that specify the outputs they want, and fillers compete to satisfy them. You don't submit the order on-chain yourself: you sign a message using Permit2, it is broadcast, and any filler can settle it when it is economically viable. The docs list gas-free swapping and no cost for failed transactions among the properties.

The auction itself, from Auction Types:

On Ethereum the flow is RFQ plus an exclusive Dutch auction. Uniswap Labs asks a set of quoters for a price; the docs say that set is permissioned and known to Labs. The winner gets a short exclusivity window (about 24 seconds, 2 blocks), then the order decays in an open Dutch auction down to the minimum you signed.
Base, Arbitrum and Robinhood Chain (among others) use the same model with timing counted in blocks (the DutchV3 reactor). As of my reading, Optimism does not appear in that table.
Gas is wrapped into the final price and paid by the filler.
Cosigners adjust auction parameters inside your signed limits; the docs say the Uniswap Interface and API currently set the cosigner to Uniswap Labs.

One more detail from AMM vs UniswapX Routing: through the Uniswap API, UniswapX is included when the order is worth more than 300 USDC equivalent, or when it improves on the AMM route by at least 0.2%, and UniswapX quotes "may be unavailable when solvers cannot or choose not to fill".

What does on-chain routing do instead?

In BlazePhoenix the quote is a free eth_call to a Quoter contract (previewPlan is a view function). The 2.0.0 Router source also has an entry point, swapBestExactIn, that takes no route at all: it calls the Solver inside the same transaction and then executes against the same block state. The contract comment says it plainly, "solve and execution read the same block state, atomically", and also says what it does not fix: "in-tx solving removes plan staleness, not sandwich exposure". That is why userMinOut is mandatory there, and zero reverts.

Status, so nobody is misled: the deployment registry lists 2.0.0 as pending (its addresses are zero today). What is deployed is 1.0.0, where the Quoter works as described but the route travels as calldata. The protocol is pre-launch and an independent external audit is scheduled.

Here is everything a user commits to in that entry point. It runs offline:

import { decodeFunctionData, parseUnits, size, type Address } from 'viem';
import { ROUTER_ABI, encodeSwapBestExactIn } from '@blazephoenix/sdk';

const WETH: Address = '0x4200000000000000000000000000000000000006';
const USDC: Address = '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913';
const me: Address = '0x000000000000000000000000000000000000dEaD';

const data = encodeSwapBestExactIn(
  WETH, USDC, parseUnits('0.5', 18),
  1_000_000_000n,                                   // userMinOut: 1,000 USDC (6 decimals), YOUR number
  me, BigInt(Math.floor(Date.now() / 1000) + 120),  // recipient, deadline
);

const { functionName, args } = decodeFunctionData({ abi: ROUTER_ABI, data });
console.log(functionName, `(${size(data)} bytes)`);
['tokenIn', 'tokenOut', 'amountIn', 'userMinOut', 'recipient', 'deadline'].forEach((n, i) =>
  console.log(' ', n.padEnd(10), String((args as readonly unknown[])[i])));

swapBestExactIn (196 bytes)
  tokenIn    0x4200000000000000000000000000000000000006
  tokenOut   0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
  amountIn   500000000000000000
  userMinOut 1000000000
  recipient  0x000000000000000000000000000000000000dEaD
  deadline   1793236722

(npm i @blazephoenix/sdk viem tsx, save as order.mts, run npx tsx order.mts. The deadline is "now + 120 s", so yours will differ.)

Who do you trust in each design?

	UniswapX (per its docs)	On-chain routing (BlazePhoenix source)
What you sign	A Permit2 order with outputs and auction parameters	A transaction with six arguments
Who finds the price	Quoters (permissioned) and fillers, in an auction	A Solver contract, in your transaction
Who pays gas	The filler, priced into the order	You
Cost of a failed swap	None (per the docs)	The gas of the reverted transaction
Who settles	Any filler, after the exclusivity window	You, in your own transaction
What you can replay	The signed order and the on-chain fill	The quote, at any block, with `eth_call` on your RPC
Services in the default path	Uniswap Labs' API, cosigner and quoter set	Your RPC node
Status	Documented for many chains	Pre-launch; audit scheduled, not done

Where does UniswapX win?

Be honest about this, because it is a lot:

Gasless for the swapper, and failed attempts cost nothing. On-chain routing offers neither.
Fillers can bring their own liquidity and "their own filling strategies" (overview), not only what sits in public pools.
Competition over price is the point of the auction. If your priority is the last basis point on a large order, measure both designs on your trade; don't take either side's word.
It is documented by Uniswap Labs for many chains, with filler tooling and an orders API.

Where does on-chain routing win?

Composability. swapBestExactIn is an ordinary external function, so a contract can call it and use the result in the same transaction. A signed order that some filler settles later is not something you can await mid-call. (This follows from the function signature; I have not built that integration for this article.)
Nothing off-chain to trust for the price. Quote and execution are the same bytecode; anyone can recompute a quote on their own node, with no key and no signup.
Predictable failure. userMinOut is yours; below it, the transaction reverts. The cost is gas, which is the price of that guarantee.
Fewer moving parts for scripts and agents, which need an RPC URL rather than an order pipeline.

So, do you actually need UniswapX?

Use it if most of these are true:

Your users should not need the chain's gas token.
A failed swap must cost them nothing.
Your orders are large enough that filler inventory could beat pool prices, and you will measure that.
You are fine with Uniswap Labs' services being in the default path.

Use on-chain routing if most of these are true:

A contract of yours must perform the swap and continue in the same transaction.
You want to re-derive the quote yourself, at a block of your choice.
Your caller is a script or an agent that holds a key and an RPC, not a UI.
You accept paying gas for a bounded, verifiable outcome, and you accept an unaudited, pre-launch protocol.

They are not mutually exclusive: nothing stops an application from offering both and letting the user choose.

FAQ

Is UniswapX gasless?
For the swapper, per the docs: gas is wrapped into the price and paid by the filler, and failed swaps incur no fees.

Can I quote a swap without an API key?
With BlazePhoenix, yes: the quote is an eth_call on your own RPC. The Uniswap API examples in the docs send an x-api-key header.

Does in-transaction solving prevent sandwiches?
No. The source says so itself: it removes stale plans, not ordering risk, which is why userMinOut is mandatory.

Is BlazePhoenix on-chain routing available today?
The Quoter (previewPlan) is readable on the deployed 1.0.0. swapBestExactIn is in the 2.0.0 source, listed as pending. The protocol is pre-launch.

Verify it yourself

Read the UniswapX pages linked above (consulted 2026-10-29; docs change), then compare with the Router source and the longer intents vs on-chain routing note. The design is specified in the whitepaper (DOI 10.5281/zenodo.23084091).

Try the read side: connect an agent to the MCP server (no key) and call prepare_quote, or run the snippet above. Tell me in the comments which of your swaps needs gasless and which needs composability.

I'm on the BlazePhoenix team. BlazePhoenix is pre-launch; an independent external audit is scheduled before launch. UniswapX is a product of Uniswap Labs; this is an architectural comparison, not a price or security ranking, and not advice.

Your swap reverted with 36 bytes of hex. Here is the dictionary (viem, 30 lines)

BlazePhoenix — Thu, 29 Oct 2026 01:51:11 +0000

execution reverted. That is all most wallets tell you. The chain told them more: 36 bytes, and every one of them means something.

0x62b0a386
0000000000000000000000000000000000000000000000000000000000000005

Four bytes of name, 32 bytes of argument. Below: how to get those bytes out of a failed eth_call, how to turn them into a sentence, and why the sentence is often good news.

What a custom error looks like on the wire

A Solidity custom error is encoded like a function call: the first four bytes are the start of keccak256 of its signature, followed by the ABI-encoded arguments. BlazePhoenix's contracts declare RouterE(uint16 code), SolverE(uint16), QuoterE(uint16) and HubE(uint16) (you can see the first in src/BlazePhoenixRouter.sol). RouterE(5) is therefore the selector of RouterE(uint16) plus the number 5 padded to 32 bytes. The generic Error(string) and Panic(uint256) have fixed selectors, 0x08c379a0 and 0x4e487b71; anything else is a custom error and needs the declaring contract's ABI to be read.

The project publishes that dictionary at https://blazephoenix.xyz/api/abi?contract=errors (the response carries the source revision it was generated from; background in learn/reading-a-revert).

Step 1: the dictionary, and what each code means

// lib.mjs — turn revert bytes into a name. Node 20+, viem.
import { decodeErrorResult } from 'viem';

// The dictionary: the project publishes its errors ABI and names the source revision it came from.
const res = await fetch('https://blazephoenix.xyz/api/abi?contract=errors');
export const { abi, revision, generation } = await res.json();

// What each RouterE code means: Whitepaper v2.3.0, section 11.7, copied by hand.
const ROUTER = {
  1: 'unauthorised control call', 2: 'paused', 3: 'bad input (zero address, hop or leg count, discontinuity)',
  4: 'deadline passed', 5: 'output below a floor (per-leg, per-hop, route or userMinOut)',
  6: 'callback not authorised', 7: 're-entrancy', 8: 'swap failed (zero output, unknown kind, fee >= amount)',
  9: 'V4 hook alters deltas', 10: 'userMinOut == 0 with amountIn > 0',
  13: 'fee-on-transfer token on a concentrated-only route', 14: 'rescue not queued or inside its 48-hour delay',
  15: 'settled without paying the protocol fee', 16: 'fee paid twice on an anchored route',
};

export function explain(data) {
  const sel = data.slice(0, 10);
  if (sel === '0x08c379a0') return { kind: 'Error(string)', note: 'a require() with a message' };
  if (sel === '0x4e487b71') return { kind: 'Panic(uint256)', note: 'a compiler-inserted check' };
  try {
    const e = decodeErrorResult({ abi, data });
    const code = Number(e.args?.[0]);
    return { kind: e.errorName, code, meaning: e.errorName === 'RouterE' ? (ROUTER[code] ?? 'unassigned') : undefined };
  } catch {
    return { kind: 'UNKNOWN ' + sel, note: 'not in this ABI: do not guess' };
  }
}

The meaning column is the table of §11.7 "The Router's refusals" in the whitepaper v2.3.0 (DOI), copied by hand. Codes 11 and 12 are unassigned there, and the paper says why that matters: it adds that a revert surface this enumerable is what lets the paper's tests judge every row by one rule: settle, or refuse with a selector of the project's own.

Step 2: selectors are just hashes, check them yourself

import { keccak256, toHex, encodeErrorResult } from 'viem';
import { abi, revision, generation } from './lib.mjs';
import { explain } from './lib.mjs';

console.log('errors ABI: revision', revision.slice(0, 7), '· generation', generation);
for (const sig of ['RouterE(uint16)', 'SolverE(uint16)', 'QuoterE(uint16)', 'HubE(uint16)', 'Error(string)', 'Panic(uint256)'])
  console.log(sig.padEnd(17), keccak256(toHex(sig)).slice(0, 10));

const five = encodeErrorResult({ abi, errorName: 'RouterE', args: [5] });
console.log('\nbytes of RouterE(5):', five);
console.log(explain(five));
console.log(explain('0xdeadbeef'));

errors ABI: revision 6323963 · generation 2.0.0
RouterE(uint16)   0x62b0a386
SolverE(uint16)   0x3d0ccdde
QuoterE(uint16)   0x765afc20
HubE(uint16)      0x9a3fb915
Error(string)     0x08c379a0
Panic(uint256)    0x4e487b71

bytes of RouterE(5): 0x62b0a3860000000000000000000000000000000000000000000000000000000000000005
{
  kind: 'RouterE',
  code: 5,
  meaning: 'output below a floor (per-leg, per-hop, route or userMinOut)'
}
{ kind: 'UNKNOWN 0xdeadbeef', note: 'not in this ABI: do not guess' }

Nothing in that output needs trust. The hashes come from your local keccak256, the table comes from a paper you can open, and an unknown selector is reported as unknown instead of being matched to the nearest name.

Step 3: getting the bytes out of a failed `eth_call`

viem wraps an RPC error several levels deep. walk() returns the first level that carries hex data:

// extract.mjs — get the revert bytes out of a failed eth_call with viem.
// The RPC here is a throwaway local mock that answers every eth_call with a revert,
// so the exact error path of viem runs without a network or a chain.
import http from 'node:http';
import { createPublicClient, http as vhttp, RawContractError, BaseError, encodeErrorResult } from 'viem';
import { base } from 'viem/chains';
import { explain } from './lib.mjs';

const abi = [{ type: 'error', name: 'RouterE', inputs: [{ name: 'code', type: 'uint16' }] }];
const data = encodeErrorResult({ abi, errorName: 'RouterE', args: [5] });

const srv = http.createServer((req, res) => {
  let b = ''; req.on('data', c => (b += c)); req.on('end', () => {
    const { id } = JSON.parse(b);
    res.setHeader('content-type', 'application/json');
    res.end(JSON.stringify({ jsonrpc: '2.0', id, error: { code: 3, message: 'execution reverted', data } }));
  });
}).listen(0);
const url = `http://127.0.0.1:${srv.address().port}`;

const client = createPublicClient({ chain: base, transport: vhttp(url) });
try {
  await client.call({ to: '0x0000000000000000000000000000000000000001', data: '0x12345678' });
} catch (err) {
  // viem wraps the RPC error several levels deep; walk() returns the first level that carries hex data
  const hit = err.walk(e => typeof e?.data === 'string' && e.data.startsWith('0x'));
  console.log('revert bytes:', hit.data);
  console.log(explain(hit.data));
}
srv.close();

revert bytes: 0x62b0a3860000000000000000000000000000000000000000000000000000000000000005
{
  kind: 'RouterE',
  code: 5,
  meaning: 'output below a floor (per-leg, per-hop, route or userMinOut)'
}

Honesty note: the RPC in that script is a throwaway local mock that answers every eth_call with a revert, so what ran is the real viem error path, not a real BlazePhoenix revert. Point client at your own RPC and a quote or a simulated swap that the contract refuses will land in the same catch.

Reading the verdict: three codes you will meet first

Code	Whitepaper §11.7	What to change
`RouterE(5)`	output below a floor: per-leg, per-hop aggregate, route floor or `userMinOut`	size, slippage or route; the floor did its job
`RouterE(4)`	deadline passed	re-quote, sign again
`RouterE(10)`	`userMinOut == 0` with `amountIn > 0`	the Router refuses a swap with no minimum on every door (INV-6)

RouterE(5) covers four different floors under one code, so the code tells you a floor stopped the trade, not which. That is a limit of the code, not of the decoder; the learn article on refused trades explains why a refusal at a floor beats a bad fill.

Check it yourself

curl -s 'https://blazephoenix.xyz/api/abi?contract=errors' | jq '.revision, .abi[].name'
cast sig 'RouterE(uint16)'          # Foundry: 0x62b0a386
node selectors.mjs && node extract.mjs

Status

BlazePhoenix is pre-launch; the V2 Router whose refusals §11.7 lists is not deployed (§19), and an independent external audit is scheduled before launch. The decoder is generic: it works on whatever ABI the endpoint returns for the revision it names.

Sources: learn/reading-a-revert, whitepaper v2.3.0 §11.7 and INV-6, src/BlazePhoenixRouter.sol, the errors ABI endpoint. Learn and whitepaper text: CC BY 4.0, credit BlazePhoenix, https://blazephoenix.xyz.

Majority vote is free to fake: three attempts at deciding which DEX pool to believe

BlazePhoenix — Thu, 29 Oct 2026 01:50:18 +0000

Two dead pools agreed that a trade was worth 910. One pool holding $401,000 said 1,633. A median filter that counts votes threw the honest pool out as an outlier.

That is not a thought experiment. It is the measured case behind the design of BlazePhoenix's Solver, and the way it got fixed is more instructive than the fix: the first fix was also wrong, and a researcher showed it.

The problem: quoting is free, holding tokens is not

A pool contract can answer a quote request with any number it likes, because a quote is arithmetic over whatever the contract says its reserves are. So an aggregator that asks eight pools for a price and "trusts the majority" has a voting system where votes cost nothing. The learn article on phantom liquidity has the measured case; the whitepaper (v2.3.0, DOI 10.5281/zenodo.23084091, §10.3) gives the rule that replaced it.

Below are three rules and three attacks. The numbers for pools and reserves are mine (toys); the rules are the ones the whitepaper describes, and the 910 / 1,633 pair is the learn article's measured case.

The code

"""phantom.py — three ways to decide whose price to believe. Toy numbers, real rules.
Rules copied from: Whitepaper v2.3.0 E25 / section 10.3 (depth-weighted median, band +-500 bps)."""
from dataclasses import dataclass

@dataclass
class Pool:
    name: str
    rate: float      # what the pool QUOTES (free to forge)
    reserve: float   # depth in the pool's own accounting (a plain transfer does not move it)
    balance: float   # balanceOf(pool): a plain transfer (donation) DOES move it

def band(pools, centre, bps):
    lo, hi = centre * (1 - bps / 1e4), centre * (1 + bps / 1e4)
    return [p.name for p in pools if lo <= p.rate <= hi]

def median_by_count(pools):                      # one pool, one vote
    r = sorted(p.rate for p in pools)
    return r[(len(r) - 1) // 2]

def anchor_largest_balance(pools):               # "balanceOf cannot be faked without capital"
    return max(pools, key=lambda p: p.balance).rate

def depth_weighted_median(pools):                # E25: first rate where cumulative depth >= ceil(total/2)
    ps = sorted(pools, key=lambda p: p.rate)
    total, acc = sum(p.reserve for p in ps), 0
    for p in ps:
        acc += p.reserve
        if acc >= -(-total // 2):
            return p.rate

def report(title, pools, bps_anchor=200):
    print(f"\n{title}")
    for label, centre, bps in [
        ("median by count            ", median_by_count(pools), 500),
        ("anchor = largest balanceOf ", anchor_largest_balance(pools), bps_anchor),
        ("depth-weighted median (E25)", depth_weighted_median(pools), 500),
    ]:
        print(f"  {label} centre {centre:>7.0f}  admits {band(pools, centre, bps)}")

# Case 1 -- the measured case from the learn article: two dead pools agree on ~910, one deep pool says 1633.
# (910 and 1633 are the article's numbers; the reserves/balances are mine, only their ORDER of size matters.)
report("Case 1: two dead pools agree on 910, the deep pool quotes 1633", [
    Pool("dead-1", 910, 2_000, 2_000),
    Pool("dead-2", 910, 3_000, 3_000),
    Pool("deep",  1633, 401_000, 401_000),
])

# Case 2 -- a donation: the attacker's pool quotes 2000, holds almost nothing in its reserves,
# and is sent 5,000,000 by a plain transfer, recoverable later, so it costs nothing at risk.
report("Case 2: a forged 2000 quote plus a donated balance", [
    Pool("honest-a", 1633, 401_000, 401_000),
    Pool("honest-b", 1630, 120_000, 120_000),
    Pool("attacker", 2000, 1_000, 5_000_000),
])

# Case 3 -- count is free to fake: six dust pools quote the same forged 2000.
report("Case 3: six dust pools agree on a forged 2000", [
    Pool("honest-a", 1633, 401_000, 401_000),
    Pool("honest-b", 1630, 120_000, 120_000),
] + [Pool(f"dust-{i}", 2000, 100, 100) for i in range(6)])

Run it with plain python3 phantom.py:


Case 1: two dead pools agree on 910, the deep pool quotes 1633
  median by count             centre     910  admits ['dead-1', 'dead-2']
  anchor = largest balanceOf  centre    1633  admits ['deep']
  depth-weighted median (E25) centre    1633  admits ['deep']

Case 2: a forged 2000 quote plus a donated balance
  median by count             centre    1633  admits ['honest-a', 'honest-b']
  anchor = largest balanceOf  centre    2000  admits ['attacker']
  depth-weighted median (E25) centre    1633  admits ['honest-a', 'honest-b']

Case 3: six dust pools agree on a forged 2000
  median by count             centre    2000  admits ['dust-0', 'dust-1', 'dust-2', 'dust-3', 'dust-4', 'dust-5']
  anchor = largest balanceOf  centre    1633  admits ['honest-a', 'honest-b']
  depth-weighted median (E25) centre    1633  admits ['honest-a', 'honest-b']

Attempt 1: one pool, one vote

Case 1 is the measured one: the median by count centres on 910 and admits only the two dead pools. Case 3 is the cheaper attack: six pools holding a hundred units each can quote the same forged number, and by count they outvote two honest pools holding hundreds of thousands. Votes that cost nothing are not evidence.

Attempt 2: anchor on the biggest real balance

The next idea sounds airtight: balanceOf(pool) cannot be faked without holding the tokens, so anchor the band on the pool with the largest real balance. The learn article (updated 2026-07-17) describes that design and sums it up as "balanceOf is sworn testimony."

It survives Case 1 and Case 3. It dies in Case 2. A plain transfer to a pool raises its balanceOf without moving its reserve or its price, and the donor can get it back later (the Solver's source names V2 skim and a V3 LP claim), so it is not capital at risk. The whitepaper (§10.3) records that an external researcher demonstrated the earlier balance anchor being captured by a donation, and that the anchor was replaced. In the toy: a pool quoting 2,000 with 1,000 in its reserves, plus a 5,000,000 donation, becomes the centre of the band and the honest pools fall outside it.

Attempt 3: a median weighted by depth that a donation cannot move

The rule that stands is the depth-weighted median, equation E25 in Appendix A: sort candidates by rate, carry each one's depth along, and return the first rate at which the cumulative depth reaches half of the total. Two properties matter:

The depth is not balanceOf. For reserve pools it is the reserves, for concentrated pools the active liquidity, for V4 pools measured liquidity: quantities a plain donation does not move.
The breakdown point is half the depth mass. To move the centre you must out-weigh half of the real liquidity of the pair; six hundred-unit pools get no say.

Then candidates whose marginal rate departs from that centre by more than MEDIAN_FILTER_BPS = 500 (±5 %) are dropped before anything is sent. The constant is in src/BlazePhoenixSolver.sol, and the comment on it states the cost out loud: the band is symmetric, so a pool 5 % worse is admitted too, and because weights follow depth, a deep pool that is 5 % worse can take a large share.

The same source file carries a second admission. Its comment records that for a long time the documentation said "median" while the code used the rate of the single deepest pool, an estimator with a breakdown point of zero, and that this was corrected on 2026-08-21, moving the breakdown point from 0 to 50 % of the mass. The prose was more reassuring than the code. A comment that says so is worth more than a clean history.

Where `balanceOf` is still the right tool

If a donation can inflate balanceOf, why does the Solver still read it? Because a different question needs a different instrument. The band asks a relative question (is this rate believable next to the others?), which a donation can skew. The capacity clamp asks a physical one: can this pool actually pay this much? A donation really does raise what the pool can pay. So concentrated legs are clamped to MAX_CONC_DRAIN_BPS = 3,000, 30 % of the pool's measured output-token balance (§10.4), and when the quote exceeds the pool's entire holdings the leg's committed input is cut in the same ratio.

Two measured numbers from the same section are worth carrying around. A single-tick concentrated-liquidity formula on a thin pool once promised 117× more than the pool ever held. And in a WETH/USDC case, splitting 50/50 between a 790-WETH pool and a 0.34-WETH dust pool returned 1,302 USDC, concentrating in the deep pool returned 1,638, and the depth-weighted allocation returned 1,638.

Check it yourself

python3 phantom.py (above). Change the reserves and see which rule breaks first.
On any Uniswap-V2-style pair, compare balanceOf(pair) with getReserves() for the same token. The gap is value the pair's accounting does not count yet. That gap is what Case 2 weaponises.
Read E25 in the whitepaper (Appendix A), then _depthWeightedMedian in the source.

Status

BlazePhoenix is pre-launch. The code in this article is my own toy. The Solver rules it imitates are described by the whitepaper for V2, which is not deployed (§19), and an independent external audit is scheduled before launch. Nothing here is a claim about volume or users; it is a claim about a rule you can run.

Sources: learn/phantom-liquidity, learn/capacity-clamp, BlazePhoenix Technical Whitepaper v2.3.0 §10.3–10.4 and E25 (DOI). Text of the learn articles and whitepaper is CC BY 4.0, credit BlazePhoenix, https://blazephoenix.xyz.

A preflight for on-chain swaps: four rehearsals, three refusals, zero transactions

BlazePhoenix — Thu, 29 Oct 2026 01:49:28 +0000

Many swaps that fail on-chain, and burn gas doing it, would have shown the same failure in a free eth_call first.
Here is a ~30-line preflight for swaps built with the BlazePhoenix SDK, run through four situations. Three get refused. None of them cost a wei.

The idea

A swap transaction is a function call. A node can execute any function call against current state without mining it, and tell you exactly what would have happened: the return value, or the revert. Many wallets do a version of this under the hood; bots and agents often skip it. Put it in front of the signing step and a whole class of mistakes turns into a log line.

The SDK already does this in execute() (approve → simulate → swap, simulation on by default). Below I pull it apart so you can see what each layer catches.

Layer 1: the SDK's `simulate()`

const plan = await blaze.buildSwap({ chain: 'base', tokenIn: 'WETH', tokenOut: 'USDC', amount: '0.5',
                                     recipient: me, from: me, slippageBps: 50 });
console.log('steps to send     :', plan.steps.length, '(approve + swap)');
console.log('simulate(plan)    :', JSON.stringify(await blaze.simulate(plan, me)));

steps to send     : 2 (approve + swap)
simulate(plan)    : {"ok":false,"error":{"contract":"unknown","name":"allowance","reason":"the Router is not approved for tokenIn yet — send plan.approval.tx first"}}

Passing from makes buildSwap read the allowance, and the plan then has two steps. simulate() notices the Router isn't approved and says so before it even spends an RPC call on the swap. Easy mistake, clear message.

Layer 2: rehearse from a wallet that isn't funded yet

An approval and a balance don't exist until they exist, so how do you test the swap step in advance? eth_call accepts a state override: write a fake balance and allowance into storage for that one call only. For WETH on Base (WETH9 layout), balances sit in storage slot 3 and allowances in slot 4:

import { getAddress, createPublicClient, http, keccak256, encodeAbiParameters, parseUnits, type Address, type Hex } from 'viem';
import { BlazePhoenix, decodeBlazeError, type SwapPlan } from '@blazephoenix/sdk';

const RPC = process.env.BASE_RPC_URL ?? 'https://mainnet.base.org';
const WETH: Address = '0x4200000000000000000000000000000000000006';
const me = getAddress('0x00000000000000000000000000000000000a11ce');   // holds nothing on-chain
const blaze = new BlazePhoenix({ rpc: { base: RPC } });
const client = createPublicClient({ transport: http(RPC) });
const req = { chain: 'base', tokenIn: 'WETH', tokenOut: 'USDC', amount: '0.5', recipient: me, slippageBps: 50 } as const;

const slot = (k: Address, s: bigint) => keccak256(encodeAbiParameters([{ type: 'address' }, { type: 'uint256' }], [k, s]));
const word = (n: bigint) => ('0x' + n.toString(16).padStart(64, '0')) as Hex;
const rehearse = (p: SwapPlan, weth: bigint) => client.call({
  account: me, to: p.tx.to, data: p.tx.data,
  stateOverride: [{ address: WETH, stateDiff: [
    { slot: slot(me, 3n), value: word(weth) },                                                        // balanceOf[me]
    { slot: keccak256(encodeAbiParameters([{ type: 'address' }, { type: 'bytes32' }],                 // allowance[me][router]
                      [p.tx.to, slot(me, 4n)])), value: word(weth) },
  ] }],
});

async function preflight(label: string, p: SwapPlan, weth = parseUnits('1', 18)) {
  try { await rehearse(p, weth); console.log(label.padEnd(26), '-> passes, nothing reverted'); }
  catch (e) {
    const d = decodeBlazeError(e);
    console.log(label.padEnd(26), '-> BLOCKED:', d && d.contract !== 'unknown'
      ? `${d.contract}E(${d.code}) ${d.reason}`
      : 'reverted, not a protocol error: ' + (e as Error).message.split('\n')[0].slice(0, 80));
  }
}

await preflight('fresh plan', await blaze.buildSwap(req));
await preflight('deadline 60 s in the past', await blaze.buildSwap({ ...req, deadline: BigInt(Math.floor(Date.now() / 1000) - 60) }));
await preflight('wallet holds only 0.25 WETH', await blaze.buildSwap(req), parseUnits('0.25', 18));

The override trick needs an RPC that supports state overrides (the public Base endpoint I used does). Run it with npm i @blazephoenix/sdk viem tsx and npx tsx preflight.mts.

What it printed

fresh plan                 -> passes, nothing reverted
deadline 60 s in the past  -> BLOCKED: RouterE(4) deadline passed
wallet holds only 0.25 WETH -> BLOCKED: reverted, not a protocol error: Execution reverted with reason: BPC:transferFrom.

Fresh plan: passes.
Expired deadline: RouterE(4). In the 2.0.0 Router source the deadline is compared with block.timestamp (if (block.timestamp > deadline) revert RouterE(4)), and decodeBlazeError turns the raw revert into a readable reason. This is the classic "the transaction sat in the mempool too long" case, caught before sending.
Underfunded wallet: the revert isn't a BlazePhoenix error at all. It's the token transfer failing (BPC:transferFrom, the Router's transfer helper). The decoder honestly says "not a protocol error" rather than inventing one.

SDK buildSwap defaults to a 120-second deadline (configurable between 10 and 3,600 seconds), which is why I had to pass an explicit past deadline to provoke the refusal.

A preflight you can paste in front of a signer

const log = console.log;
async function safeToSign(p: SwapPlan): Promise<boolean> {
  const sim = await blaze.simulate(p, me);            // allowance gate + real eth_call
  if (!sim.ok) return log('refused', sim.error), false;
  if (sim.amountOut! < p.minOut) return log('output below the signed minimum'), false;
  return true;                                        // only now hand p.steps to the wallet
}

Pair it with a calldata check (verifySwapExactIn compares the bytes with what you asked for) and the order becomes: quote → build → verify → simulate → sign. Each step is free and each can say no.

What a simulation cannot tell you

I would be lying if I sold this as a guarantee:

It's a snapshot. The dry-run executes against one block's state. Your real transaction lands later, after other transactions. A rehearsal can pass and the swap can still revert or fill worse by then. The thing that protects you at execution time is the minimum output you signed, which the Router enforces on-chain; a preflight can't replace it. (Background on the on-chain floors: the iron floor article.)
It can't see ordering. A simulation has no sandwich in it.
State overrides are a lie by design. The "wallet" above holds a faked balance. That's right for rehearsing the logic and wrong as proof that a real wallet is funded; check the real balance separately.

So treat it as a seatbelt, not a force field: it catches mistakes, not markets.

Project: blazephoenix.xyz · SDK: @blazephoenix/sdk · contracts: gitlab.com/blazephoenix-group/dex.

BlazePhoenix is pre-launch and an independent external audit is scheduled. The outputs above are a dry-run sample against Base and not advice.

The swap with no route in it: 196 bytes of calldata, and the solver runs inside the transaction

BlazePhoenix — Thu, 29 Oct 2026 01:45:36 +0000

There are two ways to execute a routed swap: send the route, or send the question. One of them has a gap between "the route was good" and "the route runs". The other doesn't.
This is a byte-level look at both, using the public contract source and a real route read from Base.

Entry A: the route is calldata

The Solver contract exposes findBestRoutePlan(tokenIn, tokenOut, amountIn) as a view function. Anyone can run it with a free eth_call. Here it is against Base through a public node (the Solver address is the one the SDK pins for generation 1.0.0):

import { createPublicClient, http, parseUnits, size, type Address } from 'viem';
import { SOLVER_ABI, EMBEDDED_DEPLOYMENTS, encodeSwapExactIn, encodeSwapBestExactIn, routeFingerprint } from '@blazephoenix/sdk';

const RPC = process.env.BASE_RPC_URL ?? 'https://mainnet.base.org';
const WETH: Address = '0x4200000000000000000000000000000000000006';
const USDC: Address = '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913';
const me: Address = '0x000000000000000000000000000000000000dEaD';
const solver = EMBEDDED_DEPLOYMENTS.versions.find((v) => v.version === '1.0.0')!.chains['8453'].solver as Address;

const client = createPublicClient({ transport: http(RPC) });
const block = await client.getBlockNumber();
const read = () => client.readContract({ address: solver, abi: SOLVER_ABI, functionName: 'findBestRoutePlan',
  args: [WETH, USDC, parseUnits('1', 18)], blockNumber: block });

// "Entry A": the Solver is a view function, so the plan comes out of a free eth_call
const plan = await read();
console.log('solver', solver, '@ block', block);
console.log('best route: hops', plan.best.hops.length, '| legs', plan.best.hops.reduce((n, h) => n + h.legs.length, 0));
console.log('same block, second call, identical route:', routeFingerprint(plan.best) === routeFingerprint((await read()).best));

// What travels in the transaction bytes
const deadline = BigInt(Math.floor(Date.now() / 1000) + 120);
const A = encodeSwapExactIn(plan.best, parseUnits('1', 18), 2_324_000_000n, me, deadline);
const B = encodeSwapBestExactIn(WETH, USDC, parseUnits('1', 18), 2_324_000_000n, me, deadline);
console.log('swapExactIn      calldata:', size(A), 'bytes (route + 5 legs inside)');
console.log('swapBestExactIn  calldata:', size(B), 'bytes (tokens, amount, minOut, recipient, deadline)');

solver 0xB1902990260975dD4C89ad74B1f317bc100CB830 @ block 53223035n
best route: hops 1 | legs 5
same block, second call, identical route: true
swapExactIn      calldata: 2308 bytes (route + 5 legs inside)
swapBestExactIn  calldata: 196 bytes (tokens, amount, minOut, recipient, deadline)

(Run it as npx tsx solve.mts after npm i @blazephoenix/sdk viem tsx. The 2,308 bytes are not mysterious: swapExactIn carries a Route struct holding the hops and, for each leg, the pool address, hooks address, venue kind, fee, tick spacing, direction, amounts and an aux id.)

So with entry A, the flow is: read the plan from the Solver at block N, send it inside a transaction that lands at block N+k. In between, pools move. The contract can't re-plan for you; what it can do is refuse to settle a plan that no longer delivers (floors, minimums). That's the "quote-to-execution seam".

Entry B: the route is computed in the swap

In the 2.0.0 Router source (swapBestExactIn), there is no route parameter at all:

function swapBestExactIn(
    address tokenIn, address tokenOut, uint256 amountIn,
    uint256 userMinOut, address recipient, uint256 deadline
) external whenLive nrEntrant returns (uint256) {
    if (amountIn == 0 || amountIn > type(uint128).max) revert RouterE(3);
    if (userMinOut == 0) revert RouterE(10);
    RoutePlan memory plan = _solve(tokenIn, tokenOut, amountIn);
    // ...both ends of the plan are checked against tokenIn / tokenOut, then the input is pulled...
    return this.selfExecutePrePulled(plan.best, received, userMinOut, recipient, deadline, msg.sender);
}

The Router calls the same Solver view function, inside the transaction, against the state the swap is about to trade in. The source comment says what that buys: "no quote-vs-execution seam at all — solve and execution read the same block state, atomically." It also says what it does not buy: userMinOut stays mandatory, because "in-tx solving removes plan staleness, not sandwich exposure — the tx can still be ordered behind an attacker's."

Three engineering details I found worth the read:

The solve has a fixed gas budget. SOLVE_GAS = 14_700_000 is forwarded to the Solver; if the search exhausts it, the Router reverts with RouterE(17) instead of dying in an out-of-gas for the whole transaction. The test file for this entry says why a cap and not an optimisation: how many pools on a route's reach are fragmented is an attacker's choice, so no optimisation can bound it, "a fixed budget that reverts can."
Both ends of the solved plan are checked. The plan must start in tokenIn and end in tokenOut, or the call reverts with RouterE(3). The Solver is immutable, but this is the one door where the route isn't the caller's, so the Router double-checks.
A self-call re-encodes memory to calldata. The Solver returns Route memory, while the hot execution path takes Route calldata, so the plan crosses through selfExecutePrePulled, which only the Router itself may call (RouterE(1) otherwise).

The property the tests pin down

The header of the Router's solve-budget test states the invariant in one sentence: entry B executes exactly the plan entry A quotes for the same state, or it reverts. Never a different plan. There is a fuzz test for that equality and one for the budget cap never degrading a plan ("a capped solve returns the uncapped plan or nothing").

The trade-off, stated plainly

The source comments are candid: entry B "costs the solve on top of execution" (they describe it as cheap on L2s), and the calldata-plan entry points "remain the gas-lean path". Entry B buys a smaller transaction, no stale plan and nothing for a front-end to tamper with in the route; entry A buys lower gas. Both require a real minOut.

Status

This is where I have to be careful. Version 2.0.0, the generation that has swapBestExactIn, is listed as pending in the deployments registry; its addresses are zero there today. The Base output above comes from the 1.0.0 deployment the SDK pins, which has the view-function Solver (entry A). What I'm describing for entry B is the public source (contracts) and its tests, not something you can call on a chain today. In the SDK it is mode: 'best', flagged 2.x-only. The encodeSwapBestExactIn helper above only builds the bytes.

Background on on-chain solving: DEX_ROUTING in the repo and the on-chain quoting article. Everything starts at blazephoenix.xyz.

BlazePhoenix is pre-launch and an independent external audit is scheduled. Source reading, not advice.

I signed minOut = 1 in a dry-run and a forged route delivered 14% under the quote: five simulations of one swap

BlazePhoenix — Thu, 29 Oct 2026 01:40:08 +0000

The only slippage protection that is yours is a number you type into the calldata. I wanted to see exactly what it does, so I broke it on purpose.
Five dry-runs of the same 0.5 WETH → USDC swap on Base. Nothing is sent, nothing is signed; every result is an eth_call.

The setup

BlazePhoenix swaps carry a userMinOut in the calldata: an absolute amount of the output token. The Router checks it on what the recipient actually received, and reverts with RouterE(5) (slippage) otherwise. That is what the public source says, in the 2.0.0 Router:

uint256 recipBefore = BPC.balanceOf(tokenOut, recipient);
BPC.safeTransfer(tokenOut, recipient, net);
uint256 delivered = BPC.balanceOf(tokenOut, recipient) - recipBefore;

// Slippage protection is enforced on the DELIVERED amount
if (delivered < userMinOut) revert RouterE(5);

Before that line, the Router computes an effective minimum as the strictest of three numbers: your userMinOut, the route's own singleOutFloor, and a protocol floor it recomputes on-chain. if (amountOut < effMin) revert RouterE(5). And on every entry point that moves value, userMinOut == 0 reverts with RouterE(10), so "no protection" is not something the 2.0.0 source lets you sign.

That is the source. The experiments below run against the 1.0.0 deployment that the SDK pins today for Base (2.0.0 is listed as pending in the deployments registry). So I report what that deployment did, not what the 2.0.0 source says it will do.

The script

import { getAddress, createPublicClient, http, keccak256, encodeAbiParameters, parseUnits, formatUnits, type Address, type Hex } from 'viem';
import { BlazePhoenix, decodeBlazeError, decodeSwapExactIn, encodeSwapExactIn } from '@blazephoenix/sdk';

const RPC = process.env.BASE_RPC_URL ?? 'https://mainnet.base.org';
const WETH: Address = '0x4200000000000000000000000000000000000006';
const me = getAddress('0x00000000000000000000000000000000000a11ce');   // holds nothing: its balance is faked inside the eth_call

const blaze = new BlazePhoenix({ rpc: { base: RPC } });
const client = createPublicClient({ transport: http(RPC) });

// 1. a normal plan, 0.50 % slippage; then take its calldata apart
const plan = await blaze.buildSwap({ chain: 'base', tokenIn: 'WETH', tokenOut: 'USDC', amount: '0.5', recipient: me, slippageBps: 50 });
const c = decodeSwapExactIn(plan.tx.data);
const usdc = (n: bigint) => Number(formatUnits(n, 6)).toLocaleString('en', { minimumFractionDigits: 2, maximumFractionDigits: 2 });
console.log('quote net', usdc(plan.quote.amountOut), '| minimum signed', usdc(c.userMinOut));

// 2. dry-run any calldata as `me`, with 1 WETH + approval written into the call's state (nothing is sent)
const slot = (k: Address, s: bigint) => keccak256(encodeAbiParameters([{ type: 'address' }, { type: 'uint256' }], [k, s]));
const word = (n: bigint) => ('0x' + n.toString(16).padStart(64, '0')) as Hex;
const dryRun = (data: Hex) => client.call({ account: me, to: plan.tx.to, data, stateOverride: [{ address: WETH, stateDiff: [
  { slot: slot(me, 3n), value: word(parseUnits('1', 18)) },
  { slot: keccak256(encodeAbiParameters([{ type: 'address' }, { type: 'bytes32' }], [plan.tx.to, slot(me, 4n)])), value: word(parseUnits('1', 18)) } ] }] });

async function sim(label: string, route: typeof c.route, minOut: bigint) {
  try { const r = await dryRun(encodeSwapExactIn(route, c.amountIn, minOut, me, c.deadline));
        console.log(label.padEnd(40), 'ok     delivers', usdc(BigInt(r.data!))); }
  catch (e) { const d = decodeBlazeError(e);
        console.log(label.padEnd(40), 'REVERT', d ? `RouterE(${d.code}) ${d.reason.split(':')[0]}` : (e as Error).message.split('\n')[0].slice(0,90)); }
}

const net = plan.quote.amountOut;
await sim('A  honest route, minOut as built', c.route, c.userMinOut);
await sim('B  honest route, minOut = quote + 1 %', c.route, net + net / 100n);

// C/D: the route is only calldata. Push the whole order into the smallest pool and rewrite every
// number the route "attests" to 1: a hostile front-end could send exactly this.
const hop = c.route.hops[0];
const small = [...hop.legs].sort((a, b) => Number(a.amountIn - b.amountIn))[0];
const bad = { ...c.route, singleOutFloor: 1n, totalOut: 1n, singleOut: 1n,
  hops: [{ ...hop, expectedOut: 1n, legs: [{ ...small, amountIn: hop.amountIn, expectedOut: 1n }] }] };
await sim('C  bad route, minOut = 1 (dust)', bad, 1n);
await sim('D  same bad route, minOut as built', bad, c.userMinOut);
await sim('E  honest route, minOut = 0', c.route, 0n);

Two notes on the trick: stateOverride writes a fake WETH balance and allowance into that single eth_call (WETH9 storage layout: balances in slot 3, allowances in slot 4), so a wallet that owns nothing can still rehearse. And it needs an RPC that supports state overrides; the public Base endpoint I used does.

What came back

quote net 1,168.54 | minimum signed 1,162.70
A  honest route, minOut as built         ok     delivers 1,171.83
B  honest route, minOut = quote + 1 %    REVERT RouterE(5) slippage
C  bad route, minOut = 1 (dust)          ok     delivers 1,001.96
D  same bad route, minOut as built       REVERT RouterE(5) slippage
E  honest route, minOut = 0              ok     delivers 1,171.83

Reading it line by line:

A. The honest swap clears its minimum. (It delivers a little more than the quote's net figure; I haven't traced why on this deployment, so I make no claim about it.)
B. Ask for 1 % more than the quote and the swap reverts with RouterE(5) instead of filling short. That is the whole promise of minOut: it turns "a worse price" into "no transaction".
C. The uncomfortable one. I rewrote the route so the entire order goes through the smallest pool, and set every number the route attests to as 1. With minOut = 1 the dry-run succeeds and delivers 1,001.96 USDC, about 14 % below the quote's net of 1,168.54. The route is calldata. Whoever builds your calldata chooses it, and a dust minimum signs away your right to object.
D. Same hostile route, but with the minimum the SDK built for you: RouterE(5). One honest number was enough to stop it.
E. On the 1.0.0 deployment, minOut = 0 was accepted by the dry-run. The 2.0.0 source refuses it with RouterE(10). Either way, you should never be the one sending it.

What this means in code

The Router also enforces floors of its own (per-leg and per-route; see the iron floor article), and the site is explicit that they are a backstop, not the protection to rely on day to day. Experiment C is the practical version of that sentence. Two habits follow:

Derive minOut from a quote you read yourself, as in the quote-by-eth_call pattern, and never accept calldata whose minimum you didn't compute. The SDK's buildSwap refuses a userMinOut below the quote net of slippage (min_implausible), and verifySwapExactIn compares decoded calldata to your intent.
Dry-run before you sign. If the rehearsal doesn't pass, the real thing won't.

On execution surplus: in the 2.0.0 source, after the floor checks the recipient is paid the Router's measured output (the code comment is literally "Everything left over goes to the recipient"). The site's surplus doctrine page describes the surplus promise for the deployed generation; the SDK source notes the separate Surplus event is 1.x-only. Check which generation you integrate against.

Install: npm i @blazephoenix/sdk viem tsx, run as npx tsx minout.mts. SDK source: gitlab.com/blazephoenix-group/sdk; contracts: gitlab.com/blazephoenix-group/dex.

Status: BlazePhoenix is pre-launch and an independent external audit is scheduled. These are simulations of one block's state on one deployment generation, not a performance claim, and not advice.

I asked two different Base nodes for the same DEX quote. Both returned the same 3,008 bytes.

BlazePhoenix — Thu, 29 Oct 2026 01:34:32 +0000

If a price can only be fetched from one server, you can only ever believe that server. If it's a contract call, you can ask anyone.
So I did: same block, two independent Base RPC providers, one question. Here is the whole experiment, including the curl version.

The question is 100 bytes

BlazePhoenix is an on-chain DEX aggregator. Its Quoter is a contract, and previewPlan(address,address,uint256) is a view function on it: give me the plan for swapping X of token A into token B. Because it is a view function, the "API" is just eth_call. The calldata for 1 WETH → USDC on Base is a 4-byte selector plus three 32-byte words:

0x49d5f197
  0000…4200000000000000000000000000000000000006   WETH
  0000…833589fcd6edb6e08f4c7c32d4f71b54bda02913   USDC
  0000…0de0b6b3a7640000                           1e18

You can send it with nothing but curl (the Quoter address is the one the SDK pins for Base, generation 1.0.0):

curl -s https://mainnet.base.org -H 'content-type: application/json' -d '{
  "jsonrpc":"2.0","id":1,"method":"eth_call","params":[{
    "to":"0x4cEF0615614B212895F45Aa1D4833B16666E18d3",
    "data":"0x49d5f1970000000000000000000000004200000000000000000000000000000000000006000000000000000000000000833589fcd6edb6e08f4c7c32d4f71b54bda029130000000000000000000000000000000000000000000000000de0b6b3a7640000"
  },"latest"]}'

What comes back is one long hex string: the ABI-encoded Preview struct (route, gross output, fee, net output, floors…). Decoding it by hand gets old fast, so let's use viem.

Pin a block, ask two nodes

import { createPublicClient, http, parseUnits, formatUnits, encodeFunctionData, keccak256 } from 'viem';
import { QUOTER_ABI, EMBEDDED_DEPLOYMENTS } from '@blazephoenix/sdk';

const RPCS = (process.env.BASE_RPCS ?? 'https://mainnet.base.org,https://base-rpc.publicnode.com').split(',');
const WETH = '0x4200000000000000000000000000000000000006';
const USDC = '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913';

// The Quoter the SDK pins for Base (chain id 8453), generation 1.0.0
const quoter = EMBEDDED_DEPLOYMENTS.versions.find((v) => v.version === '1.0.0')!.chains['8453'].quoter as `0x${string}`;

// 1. calldata for previewPlan(WETH, USDC, 1e18)
const data = encodeFunctionData({ abi: QUOTER_ABI, functionName: 'previewPlan', args: [WETH, USDC, parseUnits('1', 18)] });

// 2. pin ONE block, then ask every node the same question at that block
const first = createPublicClient({ transport: http(RPCS[0]) });
const block = (await first.getBlockNumber()) - 2n;          // 2 blocks back: every node has it

for (const url of RPCS) {
  const c = createPublicClient({ transport: http(url) });
  const { data: raw } = await c.call({ to: quoter, data, blockNumber: block });
  console.log(new URL(url).host.padEnd(26), 'block', block, 'keccak256(result)', keccak256(raw!).slice(0, 18), `(${(raw!.length - 2) / 2} bytes)`);
}

// 3. decode once, on the first node
const [pv] = await first.readContract({ address: quoter, abi: QUOTER_ABI, functionName: 'previewPlan',
  args: [WETH, USDC, parseUnits('1', 18)], blockNumber: block });
const bps = (Number(pv.protocolFee) / Number(pv.grossOut)) * 1e4;
console.log('gross', formatUnits(pv.grossOut, 6), '| fee', formatUnits(pv.protocolFee, 6), `(${bps.toFixed(3)} bps)`,
            '| net', formatUnits(pv.netOut, 6), '| floor', formatUnits(pv.ironFloor, 6));
console.log('hops', pv.hops, 'legs', pv.legs, 'impact bps', pv.route.expectedImpactBps, 'canExecute', pv.canExecute);

The SDK package is used here only for two constants (the ABI and the pinned address, both embedded in the package). The script makes no request to blazephoenix.xyz: the only network traffic is JSON-RPC to the nodes you list.

npm i @blazephoenix/sdk viem tsx
npx tsx quote.mts      # .mts so top-level await works without "type": "module"

What it printed

mainnet.base.org           block 53222961n keccak256(result) 0x561a6dde8b88f1c5 (3008 bytes)
base-rpc.publicnode.com    block 53222961n keccak256(result) 0x561a6dde8b88f1c5 (3008 bytes)
gross 2343.754198 | fee 6.562511 (28.000 bps) | net 2336.49053 | floor 2058.519312
hops 1n legs 5n impact bps 17n canExecute true

Two providers I don't control, one block, the same 3,008 bytes, the same hash. The numbers are that block's sample and will have moved by the time you read this; the point is that anyone can reproduce them for that block.

Two details worth checking yourself in that output:

The fee is a visible line, not a spread. 6.562511 on a gross of 2,343.754198 is 28.000 bps. 0.28 % is the constant PROTOCOL_FEE_BPS = 28 in the contract source, not a setting on a server.
The floor is part of the answer. ironFloor is the minimum output the Router enforces for that plan, and the quote carries it. (Background: the iron floor article.)

Why bother hashing?

Because "I trust my RPC provider" is the same sentence as "I trust the quote server", one hop removed. Asking a second, unrelated provider about the same block turns trust into comparison. If two nodes ever disagree on a pinned block, you have found something worth looking at, and you found it without anyone's permission.

What this does not show

A quote is a snapshot. The block moves, so the price moves; nothing in a read can promise what a later transaction receives. That is the job of the minimum output you sign, not of the quote.
Matching bytes prove two nodes agree on chain state, not that the route is the best one available. The route logic lives in the contracts, and the source is public to read.

Docs and the machine-readable index are linked from blazephoenix.xyz; the SDK is @blazephoenix/sdk (source).

Status: BlazePhoenix is pre-launch and an independent external audit is scheduled. Read-only quote sample, not advice and not a performance claim.

Your swap calldata lies to you until you check it: 12 lines of TypeScript that catch a swapped recipient

BlazePhoenix — Thu, 29 Oct 2026 01:32:07 +0000

A swap transaction is just bytes. If one field is wrong (the recipient, the minimum output) your wallet will happily sign it.
Here is a small, runnable pattern that makes a program refuse bad bytes before anything gets signed.

The idea in one sentence

Don't trust the calldata a service hands you. Decode it and compare it field by field with what you asked for.

The BlazePhoenix SDK (@blazephoenix/sdk) ships two helpers for this: encodeSwapExactIn and verifySwapExactIn. BlazePhoenix is an on-chain DEX aggregator: the Quoter you call is a contract, and the quote is an eth_call on your RPC, with no API key and no signup. The route is computed inside the transaction that executes it (how it works).

The script

import { BlazePhoenix, encodeSwapExactIn, verifySwapExactIn, minOutFor } from '@blazephoenix/sdk';

const blaze = new BlazePhoenix({ rpc: { base: 'https://mainnet.base.org' } });
const q = await blaze.quote({ chain: 'base', tokenIn: 'WETH', tokenOut: 'USDC', amount: '1' });

const me       = '0x000000000000000000000000000000000000dEaD';
const attacker = '0x1111111111111111111111111111111111111111';
const deadline = BigInt(Math.floor(Date.now() / 1000) + 120);
const minOut   = minOutFor(q.amountOut, 50, q.preview.ironFloor);   // 0.50 % under the net quote

// what I want, written down independently of the bytes
const want = { tokenIn: q.tokenIn, tokenOut: q.tokenOut, amountIn: q.amountIn,
               recipient: me, deadline, minOutAtLeast: minOut, route: q.route };

const good = encodeSwapExactIn(q.route, q.amountIn, minOut, me, deadline);
console.log('honest bytes  ->', verifySwapExactIn(good, want).userMinOut === minOut ? 'accepted' : '?');

// same route, but a dust minimum and somebody else's address
const evil = encodeSwapExactIn(q.route, q.amountIn, 1n, attacker, deadline);
try { verifySwapExactIn(evil, want); } catch (e) { console.log(e.code, '\n', e.message); }

What it printed

I ran this against Base through a public RPC (read-only, nothing is sent or signed):

honest bytes  -> accepted
calldata_mismatch
 Quoter calldata refused — it does not execute what you asked for:
 recipient 0x1111111111111111111111111111111111111111 ≠ 0x000000000000000000000000000000000000dEaD;
 userMinOut 1 < required 2324691258

Two independent checks fired at once: the recipient differs, and the minimum output is below the one I required (2,324.691258 USDC for that block's quote). The error is a BlazeError with the stable code calldata_mismatch, so you can branch on it without parsing text.

Why `minOutFor` takes a floor

export function minOutFor(netOut: bigint, slippageBps: number, floor: bigint): bigint {
  if (!Number.isInteger(slippageBps) || slippageBps < 0 || slippageBps > 5_000) throw new BlazeError('bad_request', /* … */);
  const bySlip = netOut - (netOut * BigInt(slippageBps)) / 10_000n;
  return bySlip > floor ? bySlip : floor;
}

That is the SDK source. Your slippage can push the minimum up toward the quote; it can never take it below the protocol floor (q.preview.ironFloor). In the run above the floor was 2,058.415872 USDC and the 50 bps minimum was 2,324.691258.

Where this fits

Wallet-side apps and bots: call verifySwapExactIn on whatever bytes you are about to sign, including bytes from a server you don't control.
AI agents: an agent that relays "here is your transaction" should run the same check first. The MCP server is read-only and never signs; it returns calldata for you to review.
CI: put the tamper test in your test suite. If a refactor stops refusing evil, the build fails.

Run it

npm i @blazephoenix/sdk viem tsx
BASE_RPC_URL=https://your-base-node npx tsx verify.mts

Source, docs and the whitepaper are linked from blazephoenix.xyz; machine-readable index at /llms.txt.

Status, so nobody is misled: BlazePhoenix is pre-launch and an independent external audit is scheduled. Quote numbers above are one block's sample and move constantly. Nothing here is financial advice.

The route is computed on-chain, inside the swap transaction: how BlazePhoenix quotes DEX trades

BlazePhoenix — Thu, 15 Oct 2026 01:00:50 +0000

Most DEX aggregators compute the route on a private server and hand you a transaction to sign. Between the quote and the execution the pool state can move, and the server's answer is something you have to take on trust.

BlazePhoenix is an on-chain DEX aggregator on Base, Ethereum, Optimism, Arbitrum and Robinhood Chain that removes that step. The route is computed inside the transaction that executes it. There is no off-chain router to trust.

What the contract enforces

Minimum-out: the swap reverts unless you receive at least the minimum you signed.
Surplus to the user: any execution surplus goes to you, not to the router.
Verifiable quotes: the price comes from the Quoter contract, so anyone can reproduce it with a plain eth_call on their own RPC. Nothing is proxied through our servers.

Try it, no API key and no signup

SDK: npm i @blazephoenix/sdk
MCP server for AI agents: https://blazephoenix.xyz/mcp. The prepare_quote tool returns the exact eth_call to run on your node; decode_quote turns the result into the quote, a solvency check and verified calldata.
Raw eth_call against the Quoter on your own RPC.

Status: pre-launch. An independent external audit is scheduled before launch.

Links: https://blazephoenix.xyz · https://blazephoenix.xyz/llms.txt · whitepaper https://blazephoenix.xyz/docs/BlazePhoenix_Whitepaper.pdf (DOI 10.5281/zenodo.23084091) · X @blazephoenyx · contact@blazephoenix.xyz

For bot builders: would you take an on-chain quote over a quote API?

BlazePhoenix — Mon, 12 Oct 2026 20:36:48 +0000

Looking for blunt feedback from people who run bots or backends that swap.

Context: I'm on the BlazePhoenix team. We are a small team building an on-chain DEX aggregator. Our quotes come from a contract (the Quoter), so you read them with a plain eth_call on your own RPC. No API key, no account. There is also an SDK (npm i @blazephoenix/sdk) and an MCP endpoint if you are wiring up agents.

The trade-offs as I see them:

For the eth_call approach

no key to rotate, no vendor rate limit
deterministic per block, so you can replay a quote when a fill looks wrong
the swap computes its route inside the executing transaction and reverts below your signed minimum

Against it

you depend on your own RPC being healthy
on-chain route search has to fit in gas, so it cannot be as wide as an off-chain solver
we are pre-launch, and the contracts are not yet audited by an external firm; an independent external audit is scheduled

So the question: if you run a bot today, what would make you move one call path from a hosted API to an eth_call? Or what would stop you, regardless?

Not trying to recruit anyone. I would rather hear "this is pointless because X" now than after we have built the wrong thing.

Stop Calling Quote APIs. Make an eth_call

BlazePhoenix — Mon, 12 Oct 2026 20:34:39 +0000

Look at your swap integration and find the line that fetches a quote.

There is a good chance it is an HTTPS request to someone else's server, with an API key in a header and a rate limit you discovered in production.

That line is the least decentralised thing in your stack.

What that dependency really costs

A quote API gives you three problems you did not ask for:

Availability. Their outage is your outage. Their rate limit is your ceiling.
Identity. An API key ties every request to an account. For a bot, a backend or an agent, that is a credential to store, rotate and leak.
Verifiability. The response is a JSON number. Your code cannot tell a correct quote from a wrong one. It can only trust it.

The third one is the expensive one. You built on a chain so you would not have to trust a server, and then you put a server in front of your most important number.

The alternative: the quote is a view

If the quote is computed by a contract, fetching it is a read call. No account, no key, no vendor. Your RPC, your block, your result.

That is how BlazePhoenix works. (Disclosure: I am on the team.) Quotes are computed on-chain by the Quoter contract, and you can read them three ways:

a plain eth_call on your own RPC;
the SDK: npm i @blazephoenix/sdk;
the MCP server at https://blazephoenix.xyz/mcp, if the caller is an AI agent.

None of them needs an API key or a signup.

The shape of the call

Here is the pattern with viem. Treat the names in capitals as placeholders: the addresses and ABI for each chain come from the project docs, starting at llms.txt, or from the SDK.

import { createPublicClient, http, encodeFunctionData, decodeFunctionResult } from "viem";
import { base } from "viem/chains";

const client = createPublicClient({ chain: base, transport: http(MY_RPC_URL) });

const data = encodeFunctionData({
  abi: QUOTER_ABI,
  functionName: QUOTE_FUNCTION,
  args: QUOTE_ARGS, // tokenIn, tokenOut, amountIn, ...
});

// Pin the block so the result is reproducible.
const { data: raw } = await client.call({ to: QUOTER_ADDRESS, data, blockNumber: BLOCK });

const quote = decodeFunctionResult({ abi: QUOTER_ABI, functionName: QUOTE_FUNCTION, data: raw! });

Three things changed compared to the REST version:

the request went to your node;
the result is deterministic for a given block: anyone running the same call gets the same answer;
there is nothing to authenticate.

What the call does not solve

A quote is still a snapshot. State can move before your swap lands. The difference here is what happens next: on BlazePhoenix the route is computed inside the transaction that executes it, and the swap reverts unless the recipient gets at least the minimum signed. Surplus from a better fill goes to the user. The protocol fee is 0.28 % per swap, a constant in the core contract.

And honestly: the protocol is pre-launch. The contracts are not yet audited by an external firm; an independent external audit is scheduled. If you integrate early, integrate the way you would integrate anything unaudited.

Try it

Swap one REST call for one eth_call in a test branch. Start from the guide at blazephoenix.xyz/llms.txt. Then delete an API key from your secrets manager, which is a nice feeling.

One evaluator for the quote and the execution: a map of how BlazePhoenix routes swaps on chain

BlazePhoenix — Mon, 12 Oct 2026 17:37:58 +0000

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_call on 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

DEV Community: BlazePhoenix

Intent-based vs on-chain routing: do you need UniswapX?

What does UniswapX actually do?

What does on-chain routing do instead?

Who do you trust in each design?

Where does UniswapX win?

Where does on-chain routing win?

So, do you actually need UniswapX?

FAQ

Verify it yourself

Your swap reverted with 36 bytes of hex. Here is the dictionary (viem, 30 lines)

What a custom error looks like on the wire

Step 1: the dictionary, and what each code means

Step 2: selectors are just hashes, check them yourself

Step 3: getting the bytes out of a failed eth_call

Reading the verdict: three codes you will meet first

Check it yourself

Status

Majority vote is free to fake: three attempts at deciding which DEX pool to believe

The problem: quoting is free, holding tokens is not

The code

Attempt 1: one pool, one vote

Attempt 2: anchor on the biggest real balance

Attempt 3: a median weighted by depth that a donation cannot move

Where balanceOf is still the right tool

Check it yourself

Status

A preflight for on-chain swaps: four rehearsals, three refusals, zero transactions

The idea

Layer 1: the SDK's simulate()

Layer 2: rehearse from a wallet that isn't funded yet

What it printed

A preflight you can paste in front of a signer

What a simulation cannot tell you

The swap with no route in it: 196 bytes of calldata, and the solver runs inside the transaction

Entry A: the route is calldata

Entry B: the route is computed in the swap

The property the tests pin down

The trade-off, stated plainly

Status

I signed minOut = 1 in a dry-run and a forged route delivered 14% under the quote: five simulations of one swap

The setup

The script

What came back

What this means in code

I asked two different Base nodes for the same DEX quote. Both returned the same 3,008 bytes.

The question is 100 bytes

Pin a block, ask two nodes

What it printed

Why bother hashing?

What this does not show

Your swap calldata lies to you until you check it: 12 lines of TypeScript that catch a swapped recipient

The idea in one sentence

The script

What it printed

Why minOutFor takes a floor

Where this fits

Run it

The route is computed on-chain, inside the swap transaction: how BlazePhoenix quotes DEX trades

For bot builders: would you take an on-chain quote over a quote API?

Stop Calling Quote APIs. Make an eth_call

What that dependency really costs

The alternative: the quote is a view

The shape of the call

What the call does not solve

Try it

One evaluator for the quote and the execution: a map of how BlazePhoenix routes swaps on chain

One evaluator, two frames

The route is scored as a product

Two details worth reading

What this is for

Status

Step 3: getting the bytes out of a failed `eth_call`

Where `balanceOf` is still the right tool

Layer 1: the SDK's `simulate()`

Why `minOutFor` takes a floor