Skip to main content

Delta Hedging

The core mechanism behind zero impermanent loss. Every swap is hedged atomically — same transaction — using HyperCore perps.

How It Works​

When a swap executes:

  1. Swap fills on EVM — Trade executes against the Valantis sovereign pool
  2. Hedge order submitted — Same transaction, hedge order goes to Core via CoreWriter
  3. Hedge fills on Core — Fills on Core's order book ~800-1000ms later

The hedge is submitted within the swap transaction. No separate tx, no keeper needed for the initial hedge.

Why only on Hyperliquid?

Hyperliquid connects EVM to Core via CoreWriter. EVM contracts can submit orders to Core's perp order book in the same transaction. No other chain has this level of integration between an EVM and a high-performance exchange.

What Gets Hedged​

Depends on the pool type:

Pool TypeHedge DirectionGoal
NEUTRALShort perpCancel spot exposure → delta-neutral
BULLLong perpAmplify to full token exposure → delta-1

After every swap shifts the pool's spot balance, the hedge position adjusts to maintain the target delta.

Execution Details​

  • Submission: Atomic, within the swap tx via CoreWriter
  • Execution: Async on Core, ~800-1000ms after
  • Order type: Limit orders with configured slippage bounds
  • Reconciliation: Partial fills or failures get corrected by the Reconciler keeper

Residual Risk​

Hedging eliminates the vast majority of IL, but small residual risks remain:

  1. Execution lag (~800-1000ms) — Price can move between swap and hedge fill
  2. Partial fills — Hedge orders may not completely fill in one block
  3. ADL (Auto-Deleveraging) — In extreme conditions, Core may force-close positions
  4. Funding costs — Perp positions have ongoing funding payments

The keeper system actively monitors and corrects drift. These risks are small compared to the IL they replace.