TWAP vs VWAP Execution Algos on Solana DEXs: What Works

Solana's sub-second finality sounds like paradise for execution algos until you build one. The moment you try to port a standard TWAP or VWAP scheduler from a CeFi venue, the block structure fights you in ways that are not obvious from the docs. This is a post-mortem on what we measured running a child-order scheduler across Raydium CLMM and Orca Whirlpool pools, and what the numbers actually say about which algo earns its keep.

The Baseline: What "Arrival Price" Means On-Chain

On a centralized exchange, arrival price is the mid-quote at the moment your parent order is accepted. On Solana DEXs there is no resting quote — price is the current pool state reconstructed from the latest confirmed slot. We define arrival price as the pool spot price at the slot your parent order is first observed by the scheduler, before any child orders are sent.

Implementation shortfall (IS) is then:

IS = (average fill price − arrival price) × direction × notional

Negative IS means you beat arrival. Across 400+ parent orders on SOL/USDC ranging from $5k to $250k notional, our baseline (single-leg market order, no algo) showed IS of roughly +18 to +42 bps depending on size, with the worse tail driven by MEV sandwich activity during periods of high pool utilization.

TWAP: Where Block Cadence Breaks You

A textbook TWAP divides the parent quantity into N equal slices sent at fixed time intervals. On Nasdaq you might slice every 30 seconds across a 10-minute window. Port that to Solana and you immediately hit the first problem: slots are not uniform.

Solana targets 400ms per slot but real-world inter-slot gaps cluster around 420–480ms and occasionally spike past 1.5 seconds during leader transitions or network turbulence. If your scheduler fires on wall-clock time, child orders bunch at slot boundaries unpredictably. In our logs, 11% of child orders across a one-week window landed in the same slot as the previous child, effectively executing two slices at once and spiking IS by 8–14 bps on those trades.

The fix is slot-aware scheduling: maintain a confirmed-slot cursor and only dispatch when currentSlot > lastFilledSlot + slotGap. For a 10-minute window on SOL/USDC, we used slotGap = 30 (roughly one child per ~13 seconds), which gave consistent inter-child spacing and reduced the IS variance from ±22 bps to ±9 bps at $50k notional.

The remaining TWAP weakness is obvious: it ignores volume. On a pool that does 80% of its daily volume in two two-hour windows, uniform time-slicing means you are paying urgency premium during quiet periods and leaving participation on the table during active ones.

Participation-Rate VWAP: The Volume Oracle Problem

VWAP targets a fill fraction proportional to market volume — classically you target P% of each interval's volume where P is your participation rate. On a CeFi venue this is straightforward because the exchange publishes volume ticks. On Raydium and Orca, you reconstruct volume from on-chain swap logs.

Our approach: maintain a rolling 24-slot (roughly 10-second) swap-volume accumulator per pool by subscribing to program account updates via logsSubscribe. Child-order size for interval i is:

childQty_i = participationRate × rollingVolume_i

We capped childQty at 15% of the rolling average to avoid sending a massive child during a volume spike driven by a single whale transaction — those spikes are not representative liquidity.

At $100k parent order size with a 12% participation rate, VWAP consistently beat TWAP on IS by 6–11 bps, primarily because it naturally concentrated fills in the 09:00–11:00 UTC and 20:00–23:00 UTC windows when SOL/USDC volume is highest. The trade-off is timing risk: a VWAP order that gets stuck during a low-volume stretch may hold inventory through adverse price moves while waiting for volume to materialize.

Size Thresholds and Pool Selection

Below $20k notional, neither algo meaningfully outperforms a well-timed single order. Pool depth on Raydium CLMM for the top-five concentrated ranges is usually sufficient, and the round-trip latency of a multi-child schedule adds more risk than it saves. Our threshold for engaging the scheduler is $25k notional minimum.

Between $25k and $100k, TWAP with slot-aware cadence is the simpler choice — lower implementation surface, predictable behavior.

Above $100k, participation-rate VWAP wins on IS. At $200k+ we additionally split the parent across both Raydium and Orca simultaneously using a dynamic routing weight based on real-time pool depth and fee tier. Routing weights update every 10 slots. At $200k this cross-pool routing added another 4–7 bps of IS improvement vs. single-pool VWAP, though it doubled the operational complexity.

MEV and Priority Fees

Neither algo helps you if MEV bots are sandwiching your child orders. On Solana, the practical mitigation is:

• Randomize child sizes ±15–20% around the target quantity so your order flow pattern is harder to fingerprint.
• Jitter dispatch timing within the slot window by ±1–2 slots.
• Set priority fees dynamically using a trailing percentile of recent compute-unit prices rather than a static lamport value. A static fee that was competitive last week may be well below the clearing price during network congestion, causing your children to land in later slots than intended and blowing up your time-weighting.

During high-volatility sessions (3× normal volume) we observed MEV-attributable IS degradation of 12–18 bps on unprotected orders. After adding size jitter and dynamic priority fees, that degradation dropped to 3–5 bps — still present but no longer the dominant cost.

What the Numbers Say

Across the full 400-order sample, summary IS (in bps, positive = cost):

Size bucket	Single order	TWAP (slot-aware)	VWAP (12% participation)
$5k–$25k	+22	+24	+25
$25k–$100k	+34	+19	+14
$100k–$250k	+58	+31	+22

TWAP saves meaningful cost at mid-sizes. VWAP wins at large sizes. Single orders are fine for small sizes where the scheduling overhead is not worth it. Neither algo recovers its cost if you ignore MEV — fix that first.

The execution and scheduling logic we run in production handles slot-aware dispatch, dynamic fee calculation, cross-pool routing, and MEV jitter as standard components across all parent order sizes. The infrastructure is the same whether you are trading SOL, JLP-based instruments, or synthetic perps.

---

If you are working on execution quality for large on-chain orders and want to benchmark your current IS against what slot-aware scheduling delivers, reach out.