> For the complete documentation index, see [llms.txt](https://docs.viperexecution.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.viperexecution.com/research/event-driven-execution.md). # Why Event-Driven Execution Outperforms Everything Else **March 2026 · Public** The shift from time-driven to liquidity-driven execution represents the single largest structural improvement available in crypto trading infrastructure today. This document examines why — and how Viper's execution algorithms are built on these principles. *** ## The Problem with Time-Driven Execution The vast majority of algorithmic execution in crypto markets today is time-driven. TWAP slices fire every N seconds. Polling loops check the order book at fixed intervals. The implicit assumption is that time is the relevant axis along which execution should be scheduled. In traditional finance — where exchanges operate on fixed hours and liquidity follows predictable intraday patterns — this assumption was reasonable. Crypto markets are a fundamentally different environment. They run 24/7 with no session boundaries. Liquidity can evaporate and reappear in seconds. A single large order can wipe an entire side of the book, and the rebuild time is unpredictable. There are no designated market-making obligations guaranteeing minimum depth. Time-driven execution is blind between ticks. A TWAP that fires every 30 seconds has no awareness of what happened at second 14 — whether the spread compressed to a tenth of its average, whether a block of resting liquidity appeared, or whether a large sweep just destroyed the side of the book it's about to hit. {% hint style="info" %} A time-driven algo placing a slice into a thin book right after a large sweep will pay significantly more slippage than one that detected the sweep, paused, and waited for the book to rebuild. Same order, same timeframe — materially different cost. {% endhint %} ### The Execution Paradigm Landscape | Paradigm | Mechanism | Limitation | | ------------------------ | ------------------------------------------------------ | ------------------------------------------------------- | | Time-Driven (TWAP, VWAP) | Execute on fixed intervals or predicted volume curves | Blind between ticks; no adaptation to conditions | | Static / Passive | Place-and-forget limit orders at fixed levels | Zero reactivity; no adjustment to market shifts | | Rule-Based / Threshold | Fixed if/then rules checked on a polling loop | Latency between poll cycles; brittle logic | | Model-Driven | Internal quantitative model triggers execution | Signal latency; execution layer often still time-driven | | **Event-Driven** | **React to market events in real time as they arrive** | **Higher implementation complexity** |
Time-driven vs event-driven execution comparison
*** ## From Event-Driven to Liquidity-Driven Event-driven execution inverts the control flow. Instead of an internal clock deciding when to act, the market itself drives execution decisions. The system maintains persistent WebSocket connections to the exchange — order book updates, trade streams, fill notifications — and the execution engine reacts to these events as they arrive. But event-driven is an architecture, not a strategy. The critical question is: which events matter? For execution quality, the answer is overwhelmingly **liquidity**. The availability, depth, and distribution of resting orders is the single strongest predictor of fill quality. Liquidity-driven execution is the philosophy that sits on top of the event-driven architecture. ### The Three Layers {% tabs %} {% tab title="Observation" %} Continuous monitoring of the liquidity landscape. Order book depth at relevant price levels, spread dynamics, fill rates, large order detection, and trade flow imbalance. The system maintains a live model of where liquidity exists, how it is moving, and how fast it is being consumed. {% endtab %} {% tab title="Decision" %} The observation layer feeds execution decisions. Pace up when the book is deep. Pause when depth is thin. Sweep when a block appears offering favourable fill. Pull back when flow toxicity spikes. Every decision is a direct function of the current liquidity state — not a timer. {% endtab %} {% tab title="Adaptation" %} The feedback loop. Each fill updates the system's understanding of current conditions. Was the fill better or worse than expected? Did the book absorb the order or did it move? This information refines subsequent decisions within the same execution. {% endtab %} {% endtabs %} ### Why This Outperforms **Slippage avoidance.** Concentrating execution into periods of adequate depth rather than firing blind slices into thin books. Over a large order, cumulative slippage savings compound. **Opportunistic capture.** Blocks of resting liquidity appear and disappear episodically. A time-driven algo checking every 30 seconds may miss a block that lived for 15. A liquidity-driven system captures it the moment it appears. **Adverse selection reduction.** Executing during high flow toxicity results in consistently worse fills. Detecting toxic conditions and pausing directly reduces the adverse selection cost embedded in the final average price. *** ## Execution in Practice The performance gap between time-driven and liquidity-driven execution is not theoretical. Consider a 500,000 USDC position entry on a mid-cap perpetual pair.
Time-Driven TWAP10 equal slices, every 60 seconds. Most slices fill adequately, but slice 4 lands after a sweep thins the ask — walks 4 price levels. Slice 7 fires into a spread blowout. One slice catches heavy directional flow. The 2–3 bad slices drag the average.Avg fill: 0.18% above mid
Est. cost: ~$900
Liquidity-Driven · ViperMonitors depth and trade flow continuously via WebSocket. Pauses after the sweep — resumes when depth rebuilds. Holds through the spread blowout. Detects the toxic flow period and waits. Avoids the bad windows entirely.Avg fill: 0.07% above mid
Est. cost: ~$350
> **\~$550 saved · \~11 bps improvement** on a single 500K execution.
500K USDC execution cost comparison
### The Crypto-Specific Case 24/7 operation eliminates the predictable session patterns that make time-based scheduling viable in equities. Thin order books mean the cost difference between executing into thick versus thin depth is dramatically larger than in traditional markets. The absence of market-making obligations means quotes can disappear instantly during volatility — precisely when a time-driven algo would fire its scheduled slice. In traditional finance, the shift from time-driven to liquidity-driven execution played out over more than a decade. First-generation algos sliced evenly. Second-generation introduced VWAP volume prediction. Third-generation became adaptive — Implementation Shortfall algorithms adjusting pace on real-time conditions. Each generation reduced cost. The adaptive approach is now table stakes in equities. {% hint style="warning" %} Crypto execution infrastructure is still at generation one. Most tools are time-driven at best, static and passive at worst. The gap between what institutional participants expect and what is available is where the performance advantage lives. {% endhint %} *** ## Viper's Execution Algorithms Every Viper algorithm maintains persistent WebSocket connections to Hyperliquid, reacts to real-time market events, and makes execution decisions based on the current state of liquidity. The platform provides six execution algorithms, each designed for a specific execution profile. ### GlideMaker (GM) — Passive Maker Execution The purest expression of liquidity-driven execution in the Viper toolset. GlideMaker places passive limit orders and continuously manages them based on real-time book state. When a fill occurs, the system immediately assesses current conditions before placing the next order — adjusting price, size, and timing based on spread, depth, and fill velocity. * Reactive re-placement after fills based on live book state * Spread-aware pricing — tightens in narrow spreads, widens in volatile conditions * Configurable aggression profiles from deep passive to near-aggressive * Full crash recovery with execution state persistence ### GhostSweep (GS) — Stealth Aggressive Execution Designed for large position entries where minimising market footprint is critical. GhostSweep breaks a large order into randomised clips and executes with variable timing, preventing pattern detection. Each clip's size and delay is determined by current book depth — not a fixed schedule. * Randomised clip sizing within configurable bounds * Variable inter-clip delays driven by book rebuild speed * Depth-aware execution — larger clips when thick, smaller when thin * Automatic order clipping for clips exceeding exchange limits ### Pacemaker (PM) — Adaptive TWAP Time-weighted execution with liquidity-aware adjustments. Pacemaker follows a duration-based schedule but adapts slice timing and sizing based on real-time conditions — TWAP's predictable distribution with the quality benefits of liquidity awareness. * Duration-based execution with configurable timeframe and slice parameters * Liquidity-responsive timing — accelerates in thick books, decelerates in thin * Maker/taker mode selection per slice based on spread conditions * Progress tracking with estimated vs actual completion time ### FlowScale (FS) — Scaled Order Execution Ladder of orders across a defined price range with configurable size distribution. Unlike static grid placement, FlowScale monitors fills in real time and re-places consumed levels, adjusts range based on book movement, and manages overall position as a coordinated execution. * Configurable range with linear or weighted size distribution * Real-time fill monitoring with optional level re-placement * Range adjustment based on book drift * Position-aware total size management across all active levels ### FlowBand (FB) — Band-Based Execution Executes within a defined price band — placing orders when price enters the target zone, pausing when it drifts outside. Designed for executions with a specific favourable price zone. * Upper and lower boundaries with immediate activation on zone entry * Automatic pause when price exits the band * Configurable behaviour at band edges: aggressive capture vs patient limits * Re-entry logic when price returns after excursion ### Smart Exit (SE) — Intelligent Position Unwinding Purpose-built for closing positions with minimal impact. Configurable urgency profiles balance speed against slippage — from patient passive unwinding to aggressive immediate exit. * Urgency-based pacing from passive to aggressive * Depth-awareness prevents dumping into thin liquidity * Partial exit support for scaling out in defined tranches * Integrates with Trade Monitors for automated TP/SL execution *** ## Algorithm Summary | Algorithm | Profile | Event-Driven Behaviour | Best For | | --------------- | ------------------ | ---------------------------------------- | ------------------------------------------------ | | GlideMaker (GM) | Passive maker | Re-places on fills; spread-aware pricing | Patient accumulation with minimal footprint | | GhostSweep (GS) | Stealth aggressive | Depth-aware clip sizing; variable timing | Large entries requiring low detectability | | Pacemaker (PM) | Adaptive TWAP | Liquidity-responsive slice timing | Duration-based execution with quality safeguards | | FlowScale (FS) | Scaled ladder | Range adjustment on drift; re-placement | Multi-level entries across a price range | | FlowBand (FB) | Band-targeted | Activate on zone entry; pause on exit | Price-zone-specific execution windows | | Smart Exit (SE) | Intelligent unwind | Depth-aware pacing; urgency profiles | Position exits with minimal impact |
Viper execution algorithms overview
*** ## Beyond Algorithms ### Trade Monitors Trade Monitors extend the event-driven architecture to post-execution position management. Each monitor watches a live position and reacts to market events with configurable triggers — price-based, PnL-based, funding rate, or time-based. When a trigger fires, the monitor executes a predefined action: close using any Viper algo, adjust TP/SL levels, or alert. {% hint style="info" %} Trade Monitors turn static TP/SL into a dynamic, event-driven position management layer. Trail a stop based on unrealised PnL, tighten take-profit as funding rates shift, or trigger a Smart Exit on a time threshold — all without manual intervention. {% endhint %} ### Execution Baskets Execution Baskets coordinate multiple execution levels as a single strategy. A Layered GlideMaker basket places passive orders at multiple price levels below market (for buys) or above (for sells), each operating as an independent execution sharing a common group identity. The basket can be paused, resumed, or stopped as a unit — enabling sophisticated accumulation across a range of levels with each one independently reacting to its local liquidity conditions. ### Infrastructure **24/7 VPS execution.** Algorithms run on dedicated VPS infrastructure. Executions continue through browser disconnects, network interruptions, and system restarts. **Crash recovery.** Every execution writes state to disk. On restart, the engine recovers all active executions and resumes exactly where it left off. **Telegram control.** Full remote control via Telegram bot. Start, stop, pause, and monitor executions from a phone. **WebSocket-first.** Persistent connections for book data, trade streams, and fill notifications. Sub-second reaction to market events across all active executions. **Agent wallet security.** Hyperliquid agent wallet model — the platform can trade but cannot withdraw. Credentials encrypted at rest with AES-128-CBC. *** ## Conclusion The case for event-driven, liquidity-driven execution is not about marginal optimisation. It is about eliminating a structural inefficiency that exists because crypto execution infrastructure has not yet matured to the standard that traditional markets established over the past fifteen years. Time-driven execution assumes a clock determines the right moment to execute. Liquidity-driven execution assumes the market determines the right moment. In fragile, 24/7, obligation-free order books, the second assumption produces materially better results. Viper's execution algorithms, Trade Monitors, and Execution Baskets implement this philosophy across every execution profile — from patient passive accumulation to stealth sweeps to coordinated multi-level strategies. Every component is reactive, liquidity-aware, and built for institutional reliability. *** *Institutional-grade algorithmic execution on Hyperliquid.*\ [**viperexecution.com**](https://viperexecution.com)