Published on Sat Nov 01 2025 00:00:00 GMT+0000 (Coordinated Universal Time) by Orkid Labs

A user swaps 1000 USDC for WETH on MetaMask. The quote looks good: 0.58 WETH at current market price. They click confirm. Thirty seconds later, they receive 0.573 WETH. They just paid 8.70 dollars in slippage—87 basis points—because a bot sandwiched their transaction. Buy before them, sell after them, pocket the spread. The user doesn’t know what happened. They just know DeFi feels expensive and unpredictable.

We believe that execution quality matters deeply. When users experience high slippage and unpredictable outcomes, they lose confidence in DeFi. We believe that performance—reliable, predictable execution—is a critical component of trust. Transparency and decentralization are important, but they’re not sufficient if execution is poor. Performance is the new trust layer.

ORKID went from zero to production in ten weeks. Not a testnet demo with simulated volume. Not a research paper with promising charts. Production infrastructure executing real swaps with real capital. Not through toxic MEV extraction where we’re the ones sandwiching. Not through subsidy or loss-leader pricing that burns investor capital. Through orchestration: private lanes that eliminate sandwich risk entirely, predictive signals that route where paths will actually clear, and execution policies that turn intent into bounded risk.

We believe there are two different approaches to MEV: extraction and orchestration. Extraction-based MEV strategies maximize profit per transaction, which can create high variance and unpredictable outcomes for users. Orchestration-based MEV strategies maximize realizability and predictability, which creates low variance and stable outcomes. We believe orchestration creates more sustainable value because it aligns incentives and focuses on coordination rather than competition.

The architecture is three layers, each solving a coordination problem that extraction ignores. The first layer is detection, built on proprietary signals that quantify fill probability, safe size bands, and route stability before you commit capital. This isn’t reactive spread-scraping where you grab quotes from DEXs at time T and hope they’re still valid when you execute at time T plus thirty seconds. That’s how you get reverted or sandwiched. Our detector is predictive—it models pool state, depth distribution across price ranges, venue microstructure like fee tiers and tick spacing, and recent fill history to tell you where the path will actually clear at time T plus delta, at the size you can safely move, without inviting toxic flow. The inputs are on-chain pool data from Uniswap V2, V3, and V4, plus Balancer and Curve. The outputs are probability-of-fill bias that tells you which routes are safer, safe size bands that tell you how much you can move without excessive slippage, and route stability metrics that tell you how likely the path remains valid over the next few blocks. The objective is maximizing Rate of Realizability, which measures the probability that a quoted price will actually be realized after accounting for gas, slippage, and execution risk. A quote that looks five basis points better but has 60 percent realizability loses to a quote that’s three basis points worse but has 95 percent realizability.

The second layer is routing, which does multi-hop, cross-venue planning with policy constraints and real execution costs baked in from the start. The edge isn’t best quote—it’s fillability at target size net of all costs. Consider a direct USDC to WETH swap on Uniswap V3 that quotes five basis points better than a USDC to DAI to WETH route via Balancer plus Curve. Static optimization picks the direct route because the quote is better. Dynamic optimization picks the multi-hop route because the Uniswap pool is thin and slippage risk is high, while the Balancer and Curve pools are deep and stable. Slightly longer path, slightly worse quote, but better realized price after you account for slippage and execution risk. This is the difference between optimizing for what looks good on paper and optimizing for what actually works in production. One gets you reverted. The other gets you filled.

The third layer is execution, which uses Tycho private lanes exclusively with no public mempool exposure and simulate-then-execute validation on every route. The public mempool is an MEV honeypot. Every transaction you broadcast is visible to searchers running bots that scan for arbitrage opportunities, validators who can reorder transactions for profit, and block builders who can insert their own transactions before and after yours. They can sandwich your swap by buying before you and selling after you to pocket the spread. They can frontrun your arb by seeing your opportunity and executing it first. They can backrun your trade by extracting value from the state change you created. Private lanes eliminate this exposure entirely. Your transaction goes directly to the block builder via Tycho’s private routing infrastructure. No public broadcast, no MEV extraction, just execution. Before we send anything, we simulate the route with REVM and tycho-simulation to enforce minOut and staleness constraints. If the simulation fails or the state is stale beyond 250 milliseconds, we reject the execution and re-simulate. No hope-and-pray execution. Simulate then execute. After execution, we generate deterministic audit metadata with venues used, gas consumed in USD, realized price, and Rate of Realizability achieved.

Execution without guardrails is gambling, and gambling with other people’s capital is how you lose design partners and investor confidence. We implement multiple layers of policy to turn intent into bounded risk. First, dynamic profit floors that reject executions below favorable conditions. This prevents right-too-early executions that burn gas without meaningful profit. You don’t execute just because you can—you execute because conditions are favorable. Second, slippage caps calibrated to market conditions by pair and venue. If realized slippage exceeds the cap, the transaction reverts before you lose capital. This prevents catastrophic slippage from thin pools or stale state. Third, circuit breakers that disable execution on degraded signal freshness or RPC health. You don’t execute on stale data. Fourth, freshness gates that reject executions if state is stale. Fifth, budget and rate limits to prevent runaway execution from bugs, infinite loops, or unexpected market conditions. No exceptions.

The numbers prove the approach works and the proof is production data, not backtests. We have production infrastructure with zero MEV exposure because we only use private lanes. The consistency matters as much as the mean. Retail wallets have wide ranges because they’re getting sandwiched unpredictably. Our execution comes from predictable, policy-gated execution that only fires when conditions are favorable. This isn’t luck. This is orchestration.

In practice, this works by combining three layers: detection identifies safe routes and sizes, simulation validates execution before sending, and private lanes eliminate MEV exposure. The detector identifies routes with high probability of fill and safe size bands. Simulation confirms that execution will succeed and slippage will be within acceptable bounds. Private lanes ensure that no sandwich bots or frontrunners can intercept the transaction. The result is predictable, low-variance execution that users can rely on.

Integration is white-glove and done-for-you for design partners because we want proof points and case studies, not engineering bottlenecks. Week zero is embed: we integrate the ORKID SDK into your stack via Rust, gRPC, or WebSocket with no code changes required on your side and feature flags guarding all new behavior. Week one is policy alignment: we define profit floors, slippage caps, venue allowlists based on your risk tolerance and execution goals, configure keys and proxies and wallets, and set up observability and alerting so you can see exactly what’s happening. Week two is shadow mode: we run ORKID without real executions and audit performance, slippage, and Rate of Realizability versus your current router, then flip to production when KPIs hit targets. Week three and beyond is production: you graduate to production routing, monitor KPIs like execution cost and Rate of Realizability and slippage and gas, and iterate on policy and venue coverage as markets evolve. Design partners get this for free. Limited slots available because we’re optimizing for quality, not quantity.

For DEXs and wallets: If you’re interested in offering better execution to your users, ORKID provides private, MEV-protected routing. We can help you prove execution quality with data. Lower realized slippage can mean better user outcomes and improved retention.

For trading desks and funds: If you’re experiencing execution quality issues or inconsistent profit-and-loss outcomes, ORKID offers private routing with policy guardrails. We can pilot the SDK in shadow mode first so you can audit performance without risk, then move to production when you’re ready.

For investors: ORKID is production infrastructure with proven performance: eleven fills on Base at 2-13 basis points total execution cost. We’re opening a small round to expand coverage and signal depth. Contact for data room and live demo.

The technical stack is Rust for production code because performance and safety matter, TypeScript for legacy systems that we’re migrating away from, Tycho Router for private lane execution, REVM and tycho-simulation for pre-execution validation, Alchemy for RPC and WebSocket infrastructure, and support for Ethereum, Base, and Unichain with Uniswap V2, V3, and V4 plus Balancer and Curve as venues. Observability is structured logging with tracing that captures network, venues, gas cost, latency, and status. Every execution generates a complete audit trail with full transparency into what happened and why. No black boxes.

Performance is the new trust layer. Transparency without performance is theater. We’re live, we’re proven, and we’re scaling. Contact jacob@orkidlabs.com for design partner slots, SDK pilots, or investor data room access.

Written by Orkid Labs