Standard aggregators route each swap in isolation. Rheon collects every pending swap — across all pairs — into one 300ms batch and solves them as a single flow network. Rheon collects every pending swap into one batch and solves them as a single flow network.
// one graph, all tokens, all pairs
graph = limitOrders + pools + dlmmBins;
// swaps define what needs to flow
settlement = minCostMaxFlow(graph, swaps);
A limit order here works twice: it earns flash loan fees from arbitrageurs while waiting, then fills at mid-market when the solver finds a ring trade match. One deposit, two revenue streams.
On a typical exchange, a limit order sits idle until it fills. Here, the same capital serves double duty: it's available for ring trade settlement and flash-borrowable by arb bots. You keep your limit order. The capital stays productive.
Arb bots pay a fee each time they borrow. Yield depends on arb volume—more market inefficiency means more borrowing.
Flash loans are borrowed and returned in the same transaction. If anything fails, the entire operation reverts. Your capital is never "out."
Three limit orders in the vault form a cycle. The solver detects it and settles all three atomically.
A standard aggregator optimizes each swap independently—"what's the best route for THIS trade?" The solver builds a single flow network where every token is a node and every swap, regardless of pair, is a source and sink. It optimizes all of them at once. Two swaps competing for the same pool? It spreads them optimally. Orders on opposite sides of any pair? It settles them peer-to-peer. And unlike systems that degrade under load, quality here improves with volume—more swaps per batch means more optimization opportunities across every token pair.
Every pending order, vault deposit, and external AMM pool becomes a node in a flow network. Edges carry costs (fees, slippage, gas) and capacities (available liquidity). The algorithm finds the provably optimal way to route all volume simultaneously.
The Trust Guarantee: This algorithm isn't just running on a server—it's running inside a ZK-VM (SP1). The solver cannot execute a route unless it mathematically proves it extracted the maximum possible value for the batch.
Concretely: Alice sells ETH for USDC, Bob sells USDC for AVAX, Carol sells AVAX for ETH. A standard aggregator routes three independent trades through three separate pools—each paying fees and price impact. The solver sees all three as one flow network and settles them peer-to-peer in a ring: no pools touched, no fees, mid-market price for everyone. That's not a special case—it's the default behavior when you optimize across all pairs at once.
Not every settlement needs a flash loan. The solver checks each flow path: if a user is actively swapping (funds in wallet), their tokens flow directly. Flash loans only activate for ring trades between limit orders already sitting in the vault—where each user deposited one token but needs a different one to start the chain.
Alice wants to swap USDC for AVAX right now. She has the USDC in her wallet. The solver routes her funds through the best path—no borrowing needed.
Three limit orders sitting in the vault form a cycle. A deposited BTC (wants USDC), B deposited USDC (wants ETH), C deposited ETH (wants BTC). Each has the token the next one wants—but no one has the right token to start the chain. The solver flash-borrows to prime the loop.
The rule: if a node must send tokens (flow out > 0) but has no external source (user wallet), it gets funded temporarily via flash loan. The loan is repaid within the same transaction—plus a fee that goes to vault depositors. Ring trades are a yield source for the vault, not just a settlement mechanism.
When complementary orders exist—A sells BTC for USDC, B sells USDC for ETH, C sells ETH for BTC—the solver settles all three at mid-market price. No AMM fees, no slippage. This is the strongest edge, and its frequency grows with adoption.
When ring trades can't fill everything, the solver routes the remainder across external pools. The difference from a standard aggregator: it accounts for all pending swaps at once, so your trade doesn't compete with others for the same pool.
The solver doesn't hold inventory. It borrows from the vault via flash loan, executes the settlement, and repays in the same transaction. A temporary accounting mechanism that lets multi-party trades settle atomically without protocol capital.
Traders get better execution through joint optimization. Makers earn variable yield on idle limit orders. Savers lend to arbitrageurs atomically.
The Win: Your Swap Doesn't Compete With Others
The solver considers all pending swaps at once. Your trade isn't routed in isolation—it's part of a global optimization that avoids pool contention and finds ring trades when they exist.
What happens to your swap:
Network effect: As more users swap through Rheon, ring trade frequency increases. More diverse order flow = more coincidence-of-wants cycles.
The Win: Limit Orders That Don't Sit Idle
Place a sell limit order. While you wait for your price, arb bots can flash-borrow your capital and pay you a fee. Yield is variable—it depends on how often arb opportunities arise.
Traditional limit order:
Sell ETH at $5000? Your capital sits locked and earns nothing until it fills.
Rheon limit order:
Your ETH is flash-borrowable by arb bots. You earn variable fees from market inefficiency until $5000 hits and your order fills.
Yield source: Arbitrageurs exploiting price gaps across DEXs. More volatile markets = more arb = more borrowing fees.
The Win: Single-Asset Deposit, No IL
Deposit a single token. Arb bots and the solver flash-borrow it. You earn fees from market inefficiency. Unlike Uniswap LP, you deposit one asset and face zero impermanent loss.
vs. Uniswap LP:
Two-asset deposit. Impermanent loss eats returns. Price moves against you.
vs. Aave lending:
Yield from borrowers. Established, deep liquidity. Rheon vaults are newer and smaller.
Rheon vault:
Single-asset. Flash loans only (atomic, no duration risk). Yield is variable and depends on arb volume through this protocol specifically.
Honest trade-off: Aave has more liquidity and integration. Rheon vaults offer a different yield source (arb fees), but APY will depend on adoption. Start small.
Sandwich bots work by spotting your swap in the public mempool, buying before you (front-run), letting your trade push the price up, then selling after you (back-run). On Rheon, your orders never enter the mempool. They're signed off-chain and submitted directly to the solver.
The trade-off: the solver itself has full visibility into your order flow. This is safe if you trust the solver, but it's a centralization concern we address in Trade-offs.
| Traders | Makers | Passive LPs | |
|---|---|---|---|
| Goal | Best execution | Yield on limits | Passive income |
| Action | Swap instantly | Sell limit orders | Deposit to vault |
| IL Risk | N/A | None | None |
| Yield Source | N/A | Arb bot fees | Arb bot fees |
| Edge | Joint optimization | Variable yield while waiting | No IL, single-asset |
CoW Protocol pioneered batch auctions. UniswapX introduced intent-based filling. Rheon takes the next step: joint optimization across all pending swaps, with cryptographic proof that the solver computed the optimal result.
| Standard Agg (1inch, Paraswap) |
CoW Protocol | UniswapX | Rheon | |
|---|---|---|---|---|
| Optimization | Per-swap, independent | Batch (solver competition) | Dutch auction | Batch (MCMF, jointly optimal) |
| Batch latency | Instant no batch, per-swap |
~30 seconds auction window |
Variable Dutch auction decay |
300ms fast enough to feel instant |
| Ring / P2P trades | × | ✓ (solver competition) | × | ✓ (proven optimal) |
| Fairness enforcement | None | Economic bonding | Market pricing | ZK proof |
| MEV protection | × | ✓ | ✓ | ✓ |
| Scales with volume | Degrades sequential price impact |
Neutral | Neutral | Scales flat 100x swaps → +12% compute |
| Yield on idle orders | × | × | × | ✓ (flash loan fees) |
On the fairness row: CoW solvers compete under economic bonding — a good approximation, but a solver could still extract value up to the bonding limit. UniswapX Dutch auctions settle at market price — fair by competition, not by proof. Rheon's ZK proof constrains the solver to the exact output of the audited MCMF algorithm. Cheating is cryptographically impossible.
No protocol is without trade-offs. Here's what you should understand before using Rheon.
Coincidence-of-wants cycles only form when enough diverse orders exist. Early on, most trades route externally. Ring trade frequency scales with adoption.
Depositors earn when arb bots borrow their capital. Yield is driven by cross-DEX price inefficiencies. Calm markets with tight spreads = fewer arb opportunities = lower yield.
Our contracts are audited by [Auditor], but all DeFi carries execution risk. Start with amounts you can afford to lose.
At launch, we run the solver—but with ZK verification, trust is replaced by math. The on-chain verifier only accepts proofs generated by the audited MCMF code (matched by ImageID hash). The solver cannot submit suboptimal routes or steal funds—the contract rejects any proof from unauthorized code. Centralized execution, decentralized verification.
Our approach: Flash loans are atomic—if anything fails, the entire transaction reverts. Settlement is deterministic and cryptographically verified on-chain via ZK proofs. No trust in the solver required.
The solver runs MCMF off-chain in Rust for speed, then generates a zero-knowledge proof that the solution is optimal. The blockchain doesn't compute—it only verifies. You don't trust the solver. You trust the math.
The min-cost max-flow algorithm runs natively in Rust. No EVM gas limits, no Solidity constraints. Full computational power for complex multi-path optimization.
The Rust code runs inside a zkVM (SP1 by Succinct Labs). It produces a cryptographic proof that the MCMF output is correct—without revealing the internal computation.
The solver sends one transaction: the optimal routing solution and its ZK proof. The chain verifies in microseconds what took the solver seconds to compute.
MCMF_IMAGE_ID is the hash of the audited MCMF Rust code. If anyone tries to run different code (stealing funds, computing suboptimal routes), the hash won't match and the contract automatically rejects the transaction.
No more "trust us not to front-run." The ZK proof mathematically guarantees the solver ran the exact audited MCMF algorithm. Cheating is cryptographically impossible.
Verifying a ZK proof costs ~300k gas on Avalanche, nearly free on Monad. The heavy MCMF computation stays off-chain. Only the tiny proof goes on-chain.
The "shadow price" and duality guarantees from MCMF theory are baked into the proof. Every user can verify on-chain that they received the mathematically optimal route.
Parallel execution and sub-second blocks make Monad ideal for ZK verification. Pairing checks for proof verification run extremely fast. The solver can submit proofs at every block—near real-time settlement.
Standard ZK verification on C-Chain works like Ethereum but cheaper. With a dedicated Avalanche Subnet, you can install a ZK precompile directly into the validator nodes—making verification instant and gas-free.
The result: Blockchain as Judge, not Computer. The solver has full computational freedom off-chain, but every output is cryptographically bound to the audited MCMF algorithm. No trust required.
Every swap benefits from being solved alongside others. Ring trades when complementary orders exist. Optimal routing when they don't. And a ZK proof after every batch—so you don't have to trust the solver. The math proves it played fair.