The problem: why LPs lose money
A liquidity provider deposits two assets, say ETH and USDC, into a pool so others can trade between them, earning a fee on each trade. The catch is in how the pool rebalances: when ETH's price rises, the pool sells ETH; when it falls, the pool buys. It sells the thing going up and buys the thing going down, the opposite of what any investor would choose.
Arbitrageurs take the other side and pocket a small, certain profit every time the price moves. The 2022 paper Automated Market Making and Loss-Versus-Rebalancing (Milionis, Moallemi, Roughgarden, Zhang) gave this loss a precise rate:
loss rate = σ² / 8 (per unit of pool value, per unit of time)
where σ is the asset's volatility. For an ETH/USDC pool, that works out to roughly 11% per year handed silently from the LP to arbitrageurs. This is LVR (loss-versus-rebalancing), the sharper cousin of impermanent loss, and the single biggest reason providing liquidity is harder to profit from than it looks.
The solution: the loss is also an income stream
On a perpetual futures exchange, a continuous fee called the funding rate keeps the perp price tied to the real price. A short position collects that funding. The key fact Lambda is built on:
The funding a short collects over time is, statistically, the same size as the LVR an LP loses over the same time. They are the same quantity with the sign flipped.
Both are paid by the same force: people demanding exposure to a moving price. So Lambda measures exactly how much price exposure your position carries, opens a matching short on Hyperliquid so the risk roughly cancels (your position becomes near delta-neutral), and the funding that short collects becomes your yield. The structural loss becomes structural income.
The architecture: one loop, three chains
Lambda is a small system spread across three places, each doing the thing it's best at, talking to each other automatically, with no off-chain bot.
A self-contained Uniswap v4 hook doubles as the protocol's vault. It owns the pool's single position (so its tracked liquidity is exactly the pool's), tracks the precise delta of every position, and emits a HedgeRequested event the instant delta drifts too far. It also charges a directional dynamic fee from beforeSwap, all without touching the swap curve.
A Reactive Smart Contract subscribes to that event from another chain and triggers a transaction in response, entirely on-chain. It decides whether to act and drops replays by nonce.
When the cross-chain callback reaches the hedger, it calls the live CoreWriter precompile at 0x3333…3333, a real system contract that places real orders on Hyperliquid, and the funding the resulting short earns flows back to LPs. On testnet, Reactive's Lasna can't route callbacks to HyperEVM, so the callback lands on a LambdaHedgeReceiver stand-in instead, with the same authorization and monotonic-nonce rules as the real hedger; only the CoreWriter order itself is omitted. Promotion to mainnet follows the checklist in Mainnet readiness.
Partner integrations: where they live in code
Each partner is a real, in-code integration, not a plan. Every claim below maps to specific files you can open in the repo.
The hook is a v4 hook: beforeAddLiquidity / beforeRemoveLiquidity gate the vault, afterSwap tracks exact delta, and beforeSwap returns the Nezlobin directional-fee override on a dynamic-fee pool. Delta math is cross-checked against v4's own getAmount0Delta.
LambdaHook.solDeltaMath.solDirectionalFee.solA Reactive Smart Contract (AbstractReactive) subscribes to the hook's HedgeRequested event on Unichain and fires a cross-chain callback (AbstractCallback) to the hedger, with no off-chain bot and nonce-ordered replay protection on both legs. Verified live on Reactive Lasna → Unichain Sepolia.
LambdaReactive.solThe hedger frames a real perp order and fires it through the CoreWriter precompile (0x3333…3333, sendRawAction) on HyperEVM. The live precompile was verified on-chain. Order bytes are framed by Lambda's own CoreWriterLib, which follows Hyperliquid's CoreWriter action spec (not the official SDK).
LambdaHedger.solCoreWriterLib.solMainnet readiness: a configuration, not a rewrite
Lambda is submitted on testnet, where the live pieces run against real infrastructure: a real v4 hook on Unichain Sepolia and real Reactive automation on Lasna. The Hyperliquid hedge leg is proven against real HyperEVM mainnet state on a fork: the real LambdaHedger fires a correct CoreWriter order, asserted byte-for-byte, and the CoreWriter precompile itself was probed live on-chain. The one limitation is external: Reactive's Lasna routes callbacks to Unichain / Base / Ethereum Sepolia but not to HyperEVM testnet; HyperEVM is a Reactive destination only on mainnet (chain id 999). So on testnet the cross-chain callback lands on the receiver stand-in described in Step ③, an approach the Reactive Network team confirmed directly, noting a setup proven on a supported testnet carries over to HyperEVM mainnet unchanged.
Promotion to mainnet is a documented checklist, not a rewrite. The Reactive leg points at HyperEVM mainnet (DESTINATION_CHAIN_ID=999); the pool is configured with invertedPair=true for USDC/WETH (USDC sorts below WETH), the calibrated price scales (szScaleWad=1e8, pxScaleWad=1e20), and the hedger is seeded via fundMargin(). Same contracts, same code.
The mainnet rails Lambda will use are already live and were probed directly on-chain:
- Unichain Mainnet (130): Uniswap v4
PoolManagerat0x1f98…0004. - HyperEVM Mainnet (999): CoreWriter precompile at
0x3333…3333; Reactive callback proxy at0x9299…FC4.
Why it isn't paid-live yet
The perp leg is fork-proven against real HyperEVM mainnet state for free, and we deliberately haven't paid to make it live on testnet either. A HyperEVM testnet order isn't actually free: every faucet (Chainstack, gas.zip, QuickNode) gates on a real Hyperliquid mainnet deposit, so a "testnet" perp costs ~$5-8 of real money, and what it buys is a fill on toy liquidity with mock USDC, a strictly weaker artifact than the byte-for-byte fork proof already in the suite. The one thing it would add (that HyperCore accepts the order) is exactly what a mainnet fill proves for real, on real liquidity earning real funding.
So the money is saved for the one place it proves something new: the audited mainnet deploy (~$40-55, gated on a security review). Paying ~$8 for a toy-liquidity testnet fill in between would be real money for a weaker copy of the mainnet result.
Full deploy runbook in README → Path to mainnet ↗. The live testnet deployment (Hook, Funding, Reactive, Receiver addresses) is on the landing page's "Live on testnet" section.
The math of the hook
1. Delta: how much price risk a position carries
A v4 position with liquidity L holds, at price P in range [Pₐ, P_b]:
x(P) = L · ( 1/√P − 1/√P_b )
That x(P) is the position's delta. Most tools approximate it with a crude liquidity ÷ 2; Lambda computes the real curve, so the hedge actually matches the position.
2. The hedge, and when to adjust it
Lambda opens a short of size h · x(P), where h is the hedge ratio. To avoid burning value on tiny adjustments, it only re-hedges when delta drifts past a band τ:
re-hedge only when | current delta − hedged delta | > τ
3. The identity that cancels the loss
E[ funding collected over Δt ] ≈ E[ LVR lost over Δt ] = (σ² / 8) · V · Δt
Over a period Δt on a position worth V, the funding you collect is about the loss you'd otherwise eat. Hold both, scaled by h, and the loss routes back to you.
4. Why the hedge ratio is 0.65, not 1.0
A full hedge cancels the most risk, but a short can be liquidated if price spikes against it. Hane (2026) finds the sweet spot:
h = 1.00 → ~19% liquidation risk over 90 days h = 0.65 → ~1.4% risk, still removes 93-97% of impermanent loss
Lambda ships h = 0.65: give up a sliver of hedging to make the position dramatically safer.
5. The directional fee: defending the pool on-chain
Arbitrageurs profit by trading whichever direction drags the pool price toward the already-moved market price. So Lambda charges an asymmetric, direction-aware fee (Nezlobin's MEV-defense model):
fee = base ± sensitivity · |drift| • a trade that continues the drift (likely-informed) → base + surcharge • a trade that reverts the drift (benign flow) → base − discount
The toxic side of order flow ends up paying the LP, a second income stream aimed at the same leak the hedge attacks.
The exact base, sensitivity, and cap parameters are tuned in CALIBRATION.md ↗ and exercised by forge test --match-contract Calibration -vv.
Directional pricing in beforeSwap is becoming a standard v4 pattern. Lambda implements it and fuzz-tests it. Lambda's distinct contribution is the other half: a real, cross-chain, automatic perp hedge on Hyperliquid, which no off-chain bot drives.
Security
- The trading curve is never modified: protection is fees + an off-pool hedge, so swap behavior stays standard.
- Liquidation risk is bounded by design via the
h = 0.65hedge ratio. - Cross-chain messages are authenticated on both legs and replay-protected by nonce.
- An insurance reserve (earning Aave V3 yield on Base while idle) backstops rare tail cases.
References
- Milionis, Moallemi, Roughgarden, Zhang (2022). Automated Market Making and Loss-Versus-Rebalancing. The σ²/8 LVR rate.
- Chitra, Diamandis, et al. (2025). Perpetual Demand Lending Pools. arXiv:2502.06028.
- Hane, A. (2026). Optimal Hedge Ratio for Delta-Neutral Liquidity Provision under Liquidation Constraints. arXiv:2603.19716. Basis for h ≈ 0.65.
- Maire & Wunsch (2024). Market Neutral Liquidity Provision. LEDGER Journal.