Standard aggregators optimize each swap alone. Rheon solves all pending swaps jointly using min-cost max-flow. When complementary orders exist, they settle peer-to-peer at mid-market price. The rest routes optimally across external pools.
// edges = all available liquidity
graph = limitOrders + pools + dlmmBins;
// swaps define what needs to flow
settlement = minCostMaxFlow(graph, swaps);
Limit orders and passive deposits live in the same vault. The solver uses them for ring trade settlement. Arb bots can flash-borrow them to exploit price gaps. Your capital works on two fronts instead of sitting idle.
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.
These are limit orders already deposited in the vault, each waiting to be filled. The solver scans for cycles—chains where each order holds exactly what the next one wants. It flash-borrows to prime the loop, settles all orders at mid-market price, and repays in the same transaction. No AMM spread, no LP fees, no slippage. Ring trade frequency grows with the diversity of limit orders in the vault.
A standard aggregator optimizes each swap independently—"what's the best route for THIS trade?" The solver optimizes all pending swaps jointly. Two swaps competing for the same pool? It spreads them optimally. Complementary orders? It settles them peer-to-peer. Everything else routes to the best external AMM.
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.
Concretely: if 10 people want to sell ETH for USDC in the same batch, a naive aggregator routes them all to Uniswap sequentially—each getting worse price impact. The solver spreads them across pools, matches some against people going the other direction, and minimizes total cost.
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 | Savers | |
|---|---|---|---|
| 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 |
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. A centralized solver has full visibility into order flow, which means you're trusting us not to front-run or censor orders. We plan to move toward a competitive solver network, but that's future work—not a launch feature.
Our approach: Flash loans are atomic—if anything fails, the entire transaction reverts. No funds are ever "out" for more than one block. Settlement is deterministic and verifiable on-chain.