Lambda was the fourth of the six projects in our look at the UHI9 hookathon, and it puts a reactive contract to the use Reactive Network is most literally built for: turning an event on one chain into a transaction on another, with no server in between. The full project, contracts and tests included, is open here.

Lambda is a Uniswap v4 hook that tries to cancel the price risk a liquidity provider (an LP, someone who deposits two assets into a pool so others can trade between them) carries. It does that by holding a matching short position on a perpetual futures exchange, and it keeps that short the right size automatically, even though the pool and the exchange live on different chains.

The loss that is also an income stream

An LP slowly loses value to arbitrage. When the price moves, the pool sells the asset that is rising and buys the one that is falling, and traders on the other side pocket the difference. Researchers named and measured this (they call it loss-versus-rebalancing, the precise cousin of "impermanent loss"), and for a volatile pair it is not small.

The idea Lambda is built on is that this loss has a mirror. A short position on a perpetuals exchange collects a recurring fee, called funding, and over time that funding is roughly the same size as the loss the pool suffers, with the opposite sign. Both are paid by the same thing: people wanting exposure to a moving price. So Lambda holds the pool position and a matching short at once. The loss and the income meet in the middle, and the combined position barely cares which way the price goes. That last property has a name: delta-neutral.

The short is deliberately partial, sized at about 0.65 of the position's exposure rather than a full 1.0, because a full hedge is far more likely to get liquidated on a sharp move. Hedging most of the risk gives up little protection for a lot more safety.

The fix lives on another chain

A Uniswap hook only runs when someone trades. Between trades it is blind, and it can’t start anything on its own. Lambda's hook does what it can while a swap is passing through: it recomputes the position's exact exposure (its delta) and, if that has drifted too far from the last hedged level, emits a single event asking for the hedge to be resized.

// Every swap, recompute the live delta; if it has drifted past the band tau,
// emit one HedgeRequested carrying a strictly increasing per-pool nonce.
if (DeltaMath.shouldRehedge(ps.hedgedDelta, live, ps.tau)) {
    ps.hedgedDelta = live;
    uint64 nonce = ++ps.hedgeNonce;
    emit HedgeRequested(id, nonce, DeltaMath.hedgeSize(live, ps.hedgeRatioWad), live, sqrtPriceX96, block.timestamp);
}

But the thing that has to happen next, adjusting a real short, happens on a different chain and a different venue. The usual way to bridge that gap is an off-chain bot: a server watching for the event and signing the hedge transaction. That server is a trusted operator, a point of failure, and something that has to stay online. Lambda removes it. A reactive contract does the bridging instead, entirely on-chain.

What the reactive contract does

The whole loop fits on two chains. On Unichain, the hook follows each swap, tracks the position's exact delta, and when that drifts too far it emits a single `HedgeRequested` event. Over on Reactive's Lasna testnet, `LambdaReactive` is subscribed to that event: it checks if the event is new, then routes a callback back across chains. On testnet that callback lands on a stand-in receiver on Unichain, which re-checks the sender and the nonce and records the hedge at 0.65 of the position's delta. On mainnet, the same callback would drive a real perp instead, which is the honest gap the diagram's "testnet receiver" label is pointing at. 

The reactive contract subscribes to the hook's event on the origin chain, and optionally to the network's periodic CRON tick for funding checkpoints: 

// Watch the hook's HedgeRequested event over on the origin chain...
service.subscribe(originChainId, hook, HEDGE_TOPIC0, ...);

// ...and, optionally, the network's periodic CRON tick.
if (cronTopic != 0)
    service.subscribe(block.chainid, address(service), cronTopic, ...);

When the event arrives, `react()` runs. Its job is small and careful: check the event is genuinely newer than the last one it acted on, then ask Reactive to deliver a call to the hedger on the other chain.

function react(LogRecord calldata log) external vmOnly {
    bytes32 poolId = bytes32(log.topic_1);
    uint64  nonce  = uint64(log.topic_2);

    if (nonce <= lastNonce[poolId]) { emit HedgeDropped(poolId, nonce, lastNonce[poolId]); return; }
    lastNonce[poolId] = nonce;                       // drop replays and out-of-order events

    // Ask Reactive Network to deliver a call to the hedger on the destination chain.
    emit Callback(destinationChainId, hedger, callbackGasLimit,
        abi.encodeWithSignature("applyHedge(address,bytes32,uint64,uint256,uint160)",
            address(0), poolId, nonce, targetSize, sqrtPriceX96));
}

Emitting that `Callback` is the whole cross-chain step. Reactive Network's relayer picks it up and turns it into a real transaction on the destination chain, filling in the leading zero-address placeholder with the caller's identity as it goes. The reactive contract itself moves no money and trusts nothing in the event beyond what it can verify: it forwards, and it keeps a per-pool nonce so a repeated or stale signal goes nowhere.

Where the callback lands, and who is allowed to send it

The call arrives at a small contract on the destination chain, and that contract is strict about who it listens to. It accepts the call only from Reactive's official callback proxy, and it re-checks the nonce itself rather than trusting the payload it was handed.

function applyHedge(address, bytes32 poolId, uint64 nonce, uint256 targetSize, uint160 sqrtPriceX96)
    external
    authorizedSenderOnly // only the official Reactive callback proxy
{
    if (nonce <= lastNonce[poolId]) revert StaleNonce();  // re-check; never trust the payload
    lastNonce[poolId] = nonce;
    // ...size and place the short...
}

On mainnet that contract is the real hedger on HyperEVM, and the last step is a genuine order placed on Hyperliquid's perpetuals exchange through its on-chain `CoreWriter` system contract. The short is opened or resized to match `0.65 x delta`.

There is an honest wrinkle worth stating plainly. Reactive's testnet does not route callbacks to HyperEVM's testnet, so the live testnet demo can’t place a real perp there. Instead the callback is routed back to Unichain Sepolia, where a stand-in receiver applies the exact same two checks (authorized sender, then nonce) and records the hedge it was asked to make, without sending an order. The perp leg itself is written and tested against real HyperEVM state on a fork, but it is not running live. What is proven live is the part this article is about: the cross-chain automation, firing with no bot.

About Reactive Network

Reactive Network is an EVM automation layer built around reactive contracts, event-driven smart contracts for cross-chain, on-chain automation. It runs on CometBFT consensus, providing instant finality and roughly 1-second block times while maintaining full EVM compatibility.

Reactive contracts subscribe to event logs across EVM chains and execute Solidity logic automatically when matching events occur, deciding autonomously when to send cross-chain callback transactions. This model supports conditional cross-chain state changes and continuous cross-chain workflows.

Website | Blog | X | Telegram | Discord | Docs

Build once — react everywhere!