Best execution is a constrained optimization problem under adversarial microstructure. This piece is not a full description of proprietary algorithms, but it’s a faithful sketch of how we think.In practice, that means three things. First, we optimize pathwise: we split and route flow across multiple venues and chains. Second, we optimize informationally: we minimize how much exploitable signal about the order we leak to public mempools and unaligned actors, using private relays, intent-based execution, and atomic cross-chain settlement where appropriate. Third, we optimize structurally: wherever possible, we auction off the right to intermediate user flow among professional, capital-aligned resolvers.
Order Splitting & Path Finding
The importance of path optimization in order execution only makes sense once you take seriously how weird DeFi liquidity actually is. In tradfi, you mostly worry about a small number of lit order books plus some dark pools; in DeFi, you’re routing across a zoo of (literally hundreds) liquidity surfaces with very different microstructure.
Constant-product AMMs (Uniswap v2-style) give you a simple, convex cost curve; concentrated-liquidity AMMs (Uniswap v3, Algebra, etc.) turn that into a set of local order books indexed by price ticks; stable-swap curves (Curve, Maverick, etc.) are effectively low-volatility, high-depth regions around a peg; RFQ / off-chain market makers are streaming quotes with inventory and balance-sheet constraints; CEXs are off-chain books with entirely different latency and fee profiles. On top of that, all of this is fragmented across chains and L2s with different gas regimes and different validator sets. “Best path” in that environment is not “pick the tightest pool” but “solve a multi-venue execution problem under gas, reversion, and MEV risk.”
Formally, you can think of the DeFi landscape at a point in time as a directed graph where nodes are assets and edges are executable primitives: one edge might be “swap USDC→WETH in Uniswap v3 0.05% at tick range [a,b],” another might be “hit a 1inch RFQ quote from a specific market maker,” another “swap via a stable pool on Curve,” another “go through a bridge-like route or cross-chain atomic flow.”
Each edge has (i) a deterministic marginal price function (how much output do I get as a function of input size) and (ii) a nondeterministic cost structure (gas, protocol fees, potential MEV side effects). Path optimization is choosing a flow over this graph that decomposes the user’s size into pieces routed over different edges and paths, such that (a) the sum of outputs is maximized net of fees and gas in expectancy, and (b) the whole plan is robust to adversarial microstructure (reorgs, MEV, partial reverts).
In practice, that means splitting a big trade over several pools to stay in the “flat” part of each curve, favoring concentrated ticks where there is real depth, tapping RFQ liquidity when inventory-rich counterparties are effectively crossing the spread for you, and avoiding paths where the marginal dollar of volume is paying mostly for slippage instead of actual fill.
MEV & MEV Resistant Routing
At a high level, a Proof-of-Stake Ethereum-style blockchain is just a replicated ledger that moves from state 𝑆0 → 𝑆1 → 𝑆2 … via blocks. Users submit signed transactions; validators collect those pending transactions into a block, choose an ordering, and append that block to the chain if it’s valid. Validators are the entities who have staked the chain’s native token (ETH, etc.) and are allowed to propose and attest to blocks; they earn rewards from protocol issuance and from users’ transaction fees.
Before a transaction is included in a block, it lives in the mempool (memory pool): a public queue of valid but unconfirmed transactions held by nodes. Economically, the mempool is a global pre-trade tape: everyone can see the flow of incoming orders in near real time, simulate their effects on on-chain liquidity, and decide how to trade around them. Validators (or specialized block builders) then select and order a subset of mempool transactions to maximize their revenue, including not just base fees but also any profit they can make by inserting their own transactions.
That incremental profit is what in DeFi is refered to as MEV (maximal extractable value): the extra value available purely from ordering rights, not from taking price risk.
Most MEV you care about in swaps comes from the structure of AMMs and from the fact that your trade is visible in the mempool before it executes. Everyone watching the mempool can see your transaction and read it from the latest block. A MEV bot can then construct a sandwich: it front-runs you with a buy lets your full order execute at a worse rate, then back-runs you by selling back its position once your trade has moved the price. At equilibrium, competitions bounds how much MEV validators will extract; in particular, any sandwich/arbitrage strategy with payoff Π gets bid down via gas and bribes until expected profit is close to zero (minus risk premia) – if one bot tries to take “too much,” others outbid it on priority fee and capture the trade instead, capping extractable surplus at roughly “max value consistent with breaking even after gas and failure risk.”
Private or “MEV-protected” RPCs tackle MEV exploitation at the transport level by removing your transaction from the public pre-trade tape. When you initiate a swap with us, the signed transaction is sent first to a private relay rather than to the public Ethereum mempool. That relay inspects and simulates the swap; if there is little or no sandwich risk (often the case if the trade is small), it can forward the transaction normally into the public mempool.
If its heuristics detect that the swap would be a profitable sandwich target (large trade size, shallow liquidity, wide slippage) it forwards the transaction privately to a set of validators/builders (Flashbots, bloXroute, Eden, Manifold, etc.) who proceeds to validate the transaction without reordering it (for a price). From the perspective of mempool-based MEV, this is basically a dark pool: bots watching the public mempool never see the raw swap at all, so they have no opportunity to solve the optimization problem “what sandwich should I place around this user?” in the first place.
Price-Improvement Auctions
In normal DeFi usage, you broadcast an executable path: “call this router method with these exact parameters,” i.e. an instruction to perform a specific swap now. However, it is possible to replace this with an intent: “I am willing to sell this much of token A for token B, subject to these constraints on price and time.” Concretely, this is now no longer a swap transaction to an AMM but rather a limit-order-like object.
For sufficiently large orders from benign counterparties it is often the case that we broadcast to whitelisted resolvers (professional counterparties) who compete on the order flow via a Dutch auction. This typically result in price improvement for the user and if not then the transaction can be reverted and standard routing attempted. Crucially, if price-improvement is offered then the price is set for the user and the resolver then bears the inventory risk of the order as the entity that eventually sends the heavy multi-hop swap to the chain is the resolver, not you.
Cross-Chain Swaps
The cross-chain problem is: you want to sell token A on source chain C(src) and receive token B on destination chain C(dst), with no trusted intermediary and no wrapped tokens. This can be done in a trustless way with hash-time-locked escrows. At intent time, a secret s is chosen and hashed to h = H(s).
The user signs a order that specifies source/destination chains, tokens, amounts, a Dutch auction schedule, and the hash h. This order is distributed to resolvers and kicks off the same kind of Dutch auction described above, but now resolvers must consider multi-chain liquidity and gas when evaluating the response. When a resolver decides to accept the order, it instantiates two escrow contracts via deterministic deployment: E(src) on the source chain, which will hold the maker’s input tokens, and E(dst) on the destination chain, which will hold the resolver’s output tokens.
Both escrows are parametrized by the same hash h and by timelocks T1 and T2. The timelocks are chosen so that the source-chain lock expires after the destination-chain lock by at least some safety margin Δ.
Operationally, the user’s tokens are moved into E(src) under the condition “releasable to whoever reveals a preimage s such that H(s) = h before time T1, otherwise refundable to the maker after T1.” The resolver funds E(dst) similarly, with its own liquidity, releasable to the holder of s before T2, refundable afterward. A small safety deposit can be attached to penalize non-completion.
Once both escrows are funded and confirmed, the user (or protocol on their behalf) reveals s on the destination chain to claim the output tokens from E(dst). That revelation makes s public; the resolver then uses the same s to unlock the input side from E(src). If something goes wrong (no reveal, or resolver fails to act) timelocks ensure both parties can eventually recover their funds.
Why DeFi Routing
The complexities of DeFi routing invites the natural question of why users shouldn’t just use a centralized exchange. The practical answer is that DeFi prices can often be objectively better than what you see on a centralized exchange screen, especially for mid-sized and retail-sized flow. This is because a large fraction of DeFi liquidity is not “smart money”; it’s passive LPs, yield farmers, and concentrated-liquidity ranges that are constantly drifting out of equilibrium.
A good pathfinder can route into that “dumb” liquidity at exactly the moments when it’s underpricing your trade relative to CEX or RFQ, split your order to stay inside the flat parts of multiple curves, and harvest what is effectively option value for you instead of leaving it to arbitrageurs. On a CEX, by contrast, you are almost always trading directly against professional market makers on a centralized book; the spread you see already bakes in their inventory costs, risk premia, and whatever fees and PFOF arrangements the venue is running.
For large, toxic, or information-rich orders, it’s still more efficient to auction flow to professional resolvers and let them internalize risk. But for the vast majority of non-toxic flow, a router that can see across heterogeneous AMMs, RFQs, and chains can often deliver lower slippage and better realized prices than a single centralized book.
Disclaimer
The information provided on TheLogbook (the “Substack”) is strictly for informational and educational purposes only and should not be considered as investment or financial advice. The author is not a licensed financial advisor or tax professional and is not offering any professional services through this Substack. Investing in financial markets involves substantial risk, including possible loss of principal. Past performance is not indicative of future results. The author makes no representations or warranties about the completeness, accuracy, reliability, suitability, or availability of the information provided.
This Substack may contain links to external websites not affiliated with the author, and the accuracy of information on these sites is not guaranteed. Nothing contained in this Substack constitutes a solicitation, recommendation, endorsement, or offer to buy or sell any securities or other financial instruments. Always seek the advice of a qualified financial advisor before making any investment decisions.
