How a VWAP order works on Stacked Markets

Contents

1. What VWAP means
2. Why VWAP matters on a CLOB
3. How VWAP execution works algorithmically
4. How the on-chain CLOB enables VWAP-style execution
5. Practical use cases on Stacked Markets
6. Risks and limitations
7. The non-custodial angle: who signs each child order
8. FAQs

What VWAP means

VWAP stands for volume-weighted average price. It is the ratio of total notional value traded to total volume traded over a given period. The formula is:

VWAP = Σ(Price × Volume) / Σ(Volume)

For each trade, multiply price by volume. Sum those products. Divide by total volume. The result is a single price that reflects where most actual trading activity occurred, weighted by size.

Traders use VWAP two ways. First, as a benchmark: did you buy below VWAP or above it? Buying below VWAP means you got better-than-average execution. Second, as an execution strategy: instead of hitting the market with one large order, you slice it into smaller child orders timed to match natural volume patterns, aiming to fill the full position at or near the VWAP benchmark. The second use is the more technically demanding one. That is what this article covers.

Why VWAP matters on a CLOB

A central limit order book matches buyers and sellers at discrete price levels. Every resting order has a price and a size. Send a large market order and it eats through multiple levels in sequence, pushing your fill price progressively worse as it consumes available liquidity. That slippage is not a fee. It is a structural cost that scales with order size relative to available depth.

VWAP execution addresses this directly. Breaking a large parent order into smaller child orders and distributing them over time reduces instantaneous impact on the book. Each child order is smaller relative to available depth, so it fills closer to the mid. The aggregate fill across all child orders converges toward the VWAP benchmark.

This is why VWAP execution is standard practice for institutional equity traders, and why it matters equally for active perp traders working larger size through Stacked Markets. On an AMM, there is no order book to read, no depth to parse, and no meaningful VWAP benchmark to target. The CLOB structure is a prerequisite.

How VWAP execution works algorithmically

Slicing and volume weighting

A VWAP algorithm starts with a parent order: total size, direction, and a time window. It divides that window into intervals — typically one-minute or five-minute buckets — and calculates a target participation rate for each interval based on expected volume. Expected volume is usually derived from historical volume profiles for that asset and time of day. Crypto perps have recognizable intraday patterns: higher activity around major market opens, macro data releases, and periods of elevated funding rate movement. A well-constructed VWAP schedule weights child order sizes toward high-volume intervals and pulls back during thin ones.

At each interval, the algorithm sends a child order sized to match the target participation rate. If the market moves against you, some implementations pause or reduce child order size to avoid chasing. Others hold to schedule regardless. That design choice reflects a tradeoff between benchmark tracking and adverse selection risk.

When execution is clean, the result is a filled position whose average entry price approximates the market's VWAP over the same window. You did not announce your full size to the book at once. You participated alongside natural volume.

VWAP vs TWAP: the key difference

TWAP — time-weighted average price — divides the parent order into equal-sized slices distributed evenly across the window, regardless of volume. Easier to implement, fully predictable. The weakness is that it ignores liquidity. Equal-sized slices sent into thin intervals carry higher market impact per unit than slices sent into deep ones. VWAP weighting solves that by concentrating size where liquidity is naturally available. The tradeoff is that VWAP requires a volume forecast, which introduces model risk. If actual volume deviates significantly from the historical profile, the schedule misfires.

	TWAP	VWAP
Child order sizing	Equal at every interval	Weighted by expected volume
Liquidity awareness	None — ignores depth	Concentrates size in deep intervals
Implementation	Simple, fully predictable	Requires volume forecast
Model risk	None	Misfires if forecast deviates
Best use	Predictable time-distributed execution	Minimising market impact on larger size

How the on-chain CLOB enables VWAP-style execution

Stacked Markets routes all orders through Hyperliquid's on-chain central limit order book. That routing has specific properties that matter for VWAP execution.

• Transparent depth. The live order book shows real resting orders at real price levels. No hidden liquidity pool and no price oracle interpolating between synthetic levels. What you see in the book is what your order interacts with.
• IOC-style slippage-bounded limits. Each child order has a defined worst-case fill price. If the market moves beyond that bound before the child order fills, it cancels rather than chasing. You set the price tolerance; the order respects it.
• On-chain settlement. Every child order's fill is verifiable. Your VWAP benchmark is the arithmetic result of on-chain fills you can audit directly — not a number a broker calculates and reports back to you.
• Keyboard-first workflows. When you are manually managing a VWAP schedule, the responsiveness between decision and order submission matters. Keyboard-first workflows reduce the latency without multiple confirmation dialogs per child order.

Practical use cases on Stacked Markets

• Building a large position without moving the market. If current book depth does not support a single-fill entry at acceptable slippage, a VWAP schedule lets you accumulate over hours rather than minutes. You participate alongside natural volume rather than announcing your full size to the book at once.
• Exiting a position during a trending move. Closing a large position into a move that is already running requires care. Dumping full size into a rally or selloff can accelerate the reversal against you. A VWAP schedule distributes your exit across the move, capturing more of the trend while reducing impact.
• Benchmarking your own execution quality. Even without running a formal VWAP algorithm, calculating the session VWAP after the fact and comparing it to your average fill tells you whether your execution was above or below average. Consistent fills below VWAP on buys and above VWAP on sells is a measurable edge. Stacked Markets' on-chain fill data makes that calculation straightforward.
• Reducing adverse selection on thinner markets. Smaller perp markets on Hyperliquid's CLOB can have meaningful spread and limited top-of-book depth. Spreading a position entry across multiple intervals, each sized to a fraction of available depth, reduces the probability that a single large order triggers a cascade of cancellations.

Risks and limitations

VWAP execution is not free of risk. The failure modes matter as much as the mechanics.

• Volume forecast error. If the historical volume profile does not match actual intraday volume, your child orders will be mis-timed. You may concentrate size in thin intervals and underparticipate in deep ones. The result can be worse execution than a simple TWAP would have produced.
• Trend risk over the execution window. VWAP execution assumes you are indifferent to short-term price movement within the window. If the market moves strongly against your position direction during the schedule, later child orders fill at progressively worse prices. VWAP is not a hedge against directional risk during execution.
• Predictability and front-running. A mechanical VWAP schedule is readable. Sophisticated participants who detect a pattern of same-size, same-interval orders in the book can trade ahead of your schedule. Introducing randomness in child order size and timing reduces this risk but complicates benchmark tracking.
• Cancellation and partial fills. Because Stacked Markets routes child orders as IOC-style slippage-bounded limits, orders that cannot fill within the slippage bound cancel rather than fill at a worse price. In fast-moving markets, this can leave your schedule behind.
• Custody is yours; execution risk is yours. Stacked Markets holds nothing. The risk management decisions around VWAP schedule design, slippage bounds, and execution timing belong entirely to you. There is no counterparty absorbing your execution errors.

The non-custodial angle: who signs each child order

On a centralized exchange, you deposit funds into the exchange's custody. When an algo sends child orders on your behalf, the exchange executes them against your internal balance. You never sign individual orders. You trust the exchange's system to execute correctly and to hold your collateral safely.

On Stacked Markets, your collateral is never pooled and never held by Stacked Markets at any point. You connect an Ethereum wallet, link a signer address, and execute trades directly from your own keys. Each child order in a VWAP schedule requires a wallet approval with a plain-language signing prompt before execution. For manual VWAP execution, each order surfaces a clear approval step — you see exactly what you are signing before anything executes.

For automated execution via delegated signing, the optional delegated signer support in Stacked Markets allows a signing key to submit orders on your behalf without holding your collateral. The delegation is scoped and revocable. Your collateral stays in your wallet. Because Hyperliquid settles all trades on-chain, every fill is verifiable regardless of which key submitted the order.

Vault-style automation and copy-trading with hard risk caps, drawdown halts, and cancel-all hooks are planned features, not yet live. When they ship, the same custody model applies: your keys, your collateral, orders you control.

FAQs

---

VWAP execution is a discipline, not a feature. Your keys stay yours throughout. Hyperliquid handles the matching. You handle the execution decisions.

Try it on testnet at testnet.stackedmarkets.com →