TWAP vs VWAP Execution Algos on Solana AMMs Explained

Routing a large order through Orca or Raydium without telegraphing your size to MEV bots is genuinely harder than doing the same on a CEX. TWAP and VWAP execution algos on Solana AMMs share the same conceptual goal as their CEX counterparts — slice a parent order into child orders to reduce market impact — but the mechanics of concentrated liquidity pools, ~400 ms average block times, and Jito's block-building auction change almost every implementation decision.

Why CEX Execution Intuitions Break on Solana AMMs

On a CEX, TWAP means sending equally-sized child orders at fixed time intervals against a central limit order book with known depth. VWAP means weighting those slices by expected volume, pulling that from historical intraday volume curves.

On Raydium v3 or Orca Whirlpools, you are trading against a pricing function, not a book. The pool's effective depth at any tick range depends on how much concentrated liquidity LPs have deployed between the current price and your target price. That depth can shift materially between blocks — LPs add and remove positions at will, and a single large fee-tier migration can drain a range in one transaction. Pulling a volume curve from yesterday tells you very little about depth right now.

The second break is block-time variance. Solana's slot time targets 400 ms but can stretch to 800 ms or more under load. A naive time-sliced algo that assumes fixed-interval landing guarantees will drift, causing uneven impact across slices.

TWAP on Solana: Where It Still Works

TWAP is the right default when price is your primary constraint and you have no reliable real-time depth oracle. If you need 500,000 USDC worth of a mid-cap token over four hours and you do not care whether each slice lands at 400 ms or 600 ms, a TWAP runner is simple and robust. The logic is:

• Divide notional evenly into N slices (typically 20–60 for a four-hour window).
• Compute a target dispatch slot based on start_slot + (i * slots_per_interval).
• For each slice, fetch the current pool state, compute expected slippage for that notional size, and only execute if slippage is below your threshold.
• If slippage exceeds threshold, skip or halve the slice and carry the remainder forward.

The skip-and-carry logic is critical on concentrated pools. If a tick range empties between your slices, shoving through anyway compounds your impact on the next active range. Skipping and redistributing the missed notional into subsequent slices keeps your realized average close to TWAP without blowing through thin ticks.

Practical numbers: on a Raydium Whirlpool pool with ~$2M in-range liquidity, a $10K slice typically lands inside 5 bps of the oracle mid. At $50K per slice on the same pool you are looking at 25–60 bps depending on tick density. Above $100K per slice you need to be routing across multiple pools or using an aggregator inside each child order.

VWAP on Solana: Building a Volume Proxy

Classical VWAP requires a volume distribution to weight slices. On-chain Solana has no pre-trade volume schedule in the CEX sense, but you can construct a useful proxy:

1. Historical swap count per slot window — index swap instructions for your target pool across the last 30 days and extract a by-hour-of-day distribution. Solana block explorers and Helius's enhanced transactions API make this straightforward to backfill.
2. Real-time fee accumulation rate — fee revenue per slot is a direct proxy for current swap volume in the pool. A spike in fee accumulation signals a high-volume window; a quiet period signals low volume.
3. Aggregator quote spread — if Jupiter's quote for your token widens more than ~15 bps from the pool mid, it means fragmented liquidity and lower effective depth. Reduce slice size.

With those three signals you can build a simple VWAP schedule: larger slices during historically high-volume hours (typically 14:00–18:00 UTC for Solana memecoin pairs), smaller slices during thin periods. In production we weight by a blend of historical volume distribution (60%) and real-time fee rate (40%), recalculated every 10 minutes.

The key difference from CEX VWAP: you are not targeting a benchmark against a continuous price series. You are minimizing total slippage cost against a non-stationary liquidity surface.

MEV Exposure: The Variable That Overrides Everything Else

Both algos share an exposure that has no CEX equivalent: sandwich attacks via Jito bundles. On Solana, a searcher watching the mempool (or co-locating with an RPC to read the transaction queue) can see your child order, insert a front-run buy before it and a back-run sell after it, capturing a slice of your impact.

The practical mitigations are:

• Use Jito bundles for your own child orders. Bundling your transaction with a tip makes it harder for searchers to sandwich because they would need to displace your bundle in the same block — the economics rarely work in their favour for moderate-sized slices.
• Randomize slice timing. A predictable 30-second cadence is trivially detectable. Adding ±20% jitter to your dispatch interval destroys the pattern searchers build signals on.
• Route through multiple pools on the same slice. If your child order is split between Orca and Raydium, the searcher needs to front-run two pools atomically. This materially raises the complexity and cost of a sandwich.
• Set a tight slippage tolerance at the contract level. A 30 bps max slippage instruction will cause the transaction to revert rather than execute at a sandwiched price. Combine with the skip-and-carry logic above.

TWAP vs VWAP: Which to Use

Consideration	TWAP	VWAP
Implementation complexity	Low	Medium–High
Best when volume is predictable	Neutral	Yes
Handles sudden depth changes	Via skip-and-carry	Via real-time fee proxy
MEV surface	Equal	Equal
Requires historical data pipeline	No	Yes

Use TWAP for tokens where hourly volume is erratic or you lack a depth oracle. Use VWAP when you have an indexer running on the target pool and are executing a regular, large programme — think daily rebalancing of a treasury position or systematic accumulation over days. The VWAP weighting meaningfully reduces your benchmark slippage in back-tests when the volume proxy is accurate; in our testing on Orca SOL/USDC, a VWAP schedule reduced average slippage by 18–22% compared to uniform TWAP on $500K+ programmes, with the advantage disappearing below $100K where TWAP's lower overhead wins.

Implementation Checklist for Production

Before shipping either algo on mainnet:

• Depth snapshot before every slice — call getAccountInfo on the pool state account, not a cached quote. Stale quotes are responsible for most production blowouts.
• Slippage guard in the instruction — always set minimumAmountOut computed from current depth, not a round number.
• Jito tip calibration — monitor landed vs submitted rate and adjust tips dynamically. A static 50,000 lamport tip that worked in January will not land reliably during high-congestion periods.
• Circuit breakers — if the oracle mid moves more than X% between slices, pause and alert rather than chasing. Chasing is how a TWAP runner turns into a market-order disaster.
• Persistent state for child orders — slices must survive a process restart. Store dispatched, pending and filled notional in a database, not in memory.

Our Solana MEV and arbitrage work informs how we build these guards — the same adversarial model that applies to arb bots applies to large-order execution.

---

If you are running a programme large enough that execution quality matters, get in touch — we build and operate these algos in production and can scope what the right approach is for your pool, size and timeline.