Maestro was the fifth of the six projects in our look at the UHI9 hookathon, and it points a reactive contract at something none of the others touched: the real market price, sitting on a different chain. The full project is open here.

Maestro is a Uniswap v4 hook whose pool has a manager. The manager's job is to keep the pool's liquidity concentrated around the live market price and to set the swap fee, and it pays rent to the liquidity providers (the people who deposit the two tokens so others can trade between them) for the privilege. The whole reason for Reactive to be involved is that this manager is not a person or a server. It is a reactive contract that watches a price feed on another chain and moves the pool's liquidity to match.

A pool that trades a step behind

A normal automated market maker is passive. Its price only changes when someone trades against it, so it is always a little behind wherever the real market has already moved to. Traders who watch both notice the gap and trade against the stale pool price until it catches up, and the small, repeated profit they take comes straight out of the liquidity providers' pockets. This has a name, loss-versus-rebalancing, and on a lively pair like ETH/USDC it is estimated to cost providers somewhere around 5 to 10 percent a year.

What would fix it is easy to say: keep the pool's liquidity sitting where the price actually is right now, instead of where it was at the last trade. But a hook can’t do that on its own. It only runs inside a swap, so between trades it has no idea where the market has gone, and it certainly has no way to read a price feed living on another chain.

A manager you rent, not a bot you run

Maestro's answer is to hand that job to a manager, and to sell the role in a continuous auction. Anyone can bid a per-block rent to become the manager. Each bid has to beat the last, and after a short delay the winner takes over and pays rent every block until someone outbids them or their deposit runs dry. That rent does not go to Maestro. It is shared out to the liquidity providers, who can claim their portion whenever they like. The party best placed to profit from steering the pool ends up paying the providers for the chance to do it.

While it holds the role, the manager does two things: it concentrates the pool's liquidity into a tight band around the live price, and it sets the fee. Doing that well is what makes the rent worth paying. And the manager doing it is a reactive contract.

What the reactive contract watches

Every earlier project in this series pointed its reactive contract at the pool's own activity: swaps, withdrawals, a clock. Maestro points it somewhere else entirely, at a price oracle. Pyth is a service that publishes real market prices on-chain, and Maestro's reactive contract, `MaestroManagerRC`, subscribes to Pyth's price-update event for the ETH/USD feed. It then does nothing at all until that price moves.

// Watch Pyth's PriceFeedUpdate event for one feed (ETH/USD) on the origin chain.
service.subscribe(
    originChainId, originPyth, PRICE_FEED_UPDATE_TOPIC_0,
    uint256(priceId),                  // filter: only this one price feed
    REACTIVE_IGNORE, REACTIVE_IGNORE
);

Laid out end to end, that is three chains in one line. Pyth publishes the ETH/USD price on Ethereum Sepolia and emits it as an event; `MaestroManagerRC` on Reactive Lasna testnet is subscribed to that event and forwards each new price across chains; and on Unichain the manager callback takes the delivered price and repositions the pool around it. Only the middle box is the reactive contract's own work, and it is worth looking at what that work amounts to when a price actually arrives. 

Carrying the price across

When the Pyth price updates, `react()` runs. It pulls the new price out of the event and asks Reactive to deliver it to the pool's manager contract on the other chain. That is the whole of it. The reactive contract holds no state and makes no decision about where the band should go.

function react(LogRecord calldata log) external vmOnly {
    // PriceFeedUpdate carries (publishTime, price, conf); we only want the price.
    (, int64 price,) = abi.decode(log.data, (uint64, int64, uint64));

    // Deliver the live price to the manager callback on the destination chain.
    emit Callback(destinationChainId, managerCallback, CALLBACK_GAS_LIMIT,
        abi.encodeWithSignature("repositionToPrice(address,int64)", address(0), price));
}

The leading zero address is a placeholder that Reactive fills in with the caller's identity when the call lands, so the destination can check who sent it. The band math, turning that raw price into a tick range the pool can use, runs on the destination side where the Uniswap libraries live. The reactive contract's only job is to carry a price it observes on one chain over to another.

On the destination the call arrives at `ManagerCallback` on Unichain, which is strict about who it will listen to: it takes the price only from Reactive's official callback proxy, and only when the call carries the identity of the exact reactive contract it expects. Then it repositions the pool's liquidity around the delivered price.

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!