Here is an uncomfortable fact about DEX aggregation: a quote is a claim, not a result. Every venue tells you what it thinks you'll receive, and the aggregator traditionally believes the biggest number. On a chain with young liquidity and a lot of freshly deployed tokens, the biggest number is wrong often enough to matter — a route quotes 1,000 and delivers 940, or reverts outright and you pay gas for nothing.

Since this week, Epsilon doesn't believe quotes. It verifies them.

Build, simulate, then serve

When you ask for a route, the engine still races every venue family for a quote. But instead of serving the paper winner, it now builds the actual swap calldata for the top candidates and simulates each one against the current chain state. What comes back from the simulation is the real output after fees, slippage settings and whatever the pool actually does when the trade lands. The route with the highest verified output is the one you get — and the response tells you when the verified winner displaced the self-reported one.

Candidates that revert in simulation are excluded and remembered for a while, so the next request doesn't pay to rediscover a broken route. Candidates that can't be judged (more on that below) never displace a verified one. The whole thing runs inside the same latency budget as before: challengers are built concurrently with the winner, and a slow challenger is dropped rather than making you wait.

The sell-side problem

Simulating a buy is easy — the simulator can pretend you hold USDG. Simulating a sell of some token means pretending you hold that token and have approved the router, which requires knowing where the token contract stores balances and allowances. Standard tokens use known layouts. A lot of what trades on Robinhood Chain does not: launchpad clones, gas-optimized libraries, proxies.

The engine now asks the chain. It executes the token's own allowance getter under a tracing call, records which storage slot it reads, verifies the slot by overriding it with a marker the getter must echo back, and then overrides only that slot for the simulation. The answer is cached per token. Tokens that were previously unjudgeable — and therefore served unverified, sometimes reverting at your wallet — are now simulated like everything else.

Keepers rank fills the same way

A resting order is executed by a keeper at some later moment, against whatever liquidity exists then. The keeper now runs the same ladder: fetch the winner, fetch the in-band runner-up, simulate both as the exact fill, and submit whichever realizes more. Your limit order doesn't just fill at your price — it fills on the route that provably delivers the most at that price.

What you'll notice

• Fewer failed swaps. A route that would revert is caught before it reaches your wallet.
• Occasionally a quote that looks slightly lower than another app's — because ours is what you will actually receive.
• In the API, new fields on every route: the candidates considered, which one won, whether a re-rank happened, and the verified output. Builders can read the reasoning, not just the number.

The details — venue families, re-rank rules, the storage-discovery fallback chain — are in the developer docs. Or just trade and watch the quote hold.