DEV Community: BlazePhoenix

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