In January 2026, we wrote about Fiet integrating with Reactive Network to take the manual labor out of asynchronous DeFi settlements. That was the promise. Milestone 2 is the delivery: the contracts are live on Arbitrum and Reactive mainnet, and a full end-to-end run is on record, a real settlement processed and a queue drained without anyone pressing a button. Here's what Fiet's automation does, why it's one of the more sophisticated things built on Reactive, and where our network fits. 

The short version for newcomers: Fiet lets professional market makers plug off-chain liquidity into on-chain markets. Traders swap as if it were any normal AMM, but when the underlying asset isn't immediately available, the trade parks in a settlement queue until it is. Reactive Network watches that queue and settles it automatically the moment liquidity shows up. Everything below is about why doing that well is harder than it sounds. 

Problem revisited

Here's the situation Fiet creates by design. A market maker promises to deliver an asset they hold off-chain; a trader buys it on-chain. When the underlying is ready, settlement is trivial. When it isn't, the trader joins a queue and waits.

In the old world, waiting meant you, the trader, had to come back and claim your funds in a second transaction, watching the chain yourself or trusting a keeper to do it. And the experience got worse exactly when markets got fast and volatile, when you'd least want to be babysitting a pending claim.

So the job sounds simple: watch for liquidity, settle the queue. But "settle the queue" hides hard sub-problems once you do it trustlessly, at scale, across two chains. What happens when a hundred settlements queue and only enough liquidity arrives for thirty? When liquidity shows up before the settlement is even recorded? When one item in a batch fails? Who pays for all this, and how do you stop one user subsidizing everyone else?

Reactive’s role

For anyone new here: a reactive contract isn't triggered by a user sending it a transaction. It's triggered by events happening on other chains. It subscribes to logs, say a `SettlementQueued` event on Arbitrum, and runs its own logic in response, then emits callbacks that execute back on a destination chain.

Fiet's settlement automation has no off-chain bot, no centralized keeper, no cron job on someone's server quietly holding a private key. The thing watching the queue is itself a smart contract, and the thing executing the settlement is a cross-chain callback that the network delivers. If you've ever worried about who's actually running the automation you depend on, the answer here is "nobody, and that's the point".

Settlement flow 

Let's trace one trade on the mainnet. It starts with a trader doing an exact-input swap on Arbitrum, but the output side can't settle yet, so `LiquidityHub` queues the obligation. `HubRSC`, already subscribed to that recipient's events, observes the log and records the pending work. Then it waits for liquidity. When liquidity arrives (in the live run, the market maker settling their position and closing the RFS), `HubRSC` dispatches a bounded batch to `BatchProcessSettlement`, which calls `LiquidityHub.processSettlementFor(...)` for each item. The queue drains. The trader's funds land. Nobody did anything.

In the recorded run, a swap created a queued obligation of about 34.79 (in the token's smallest units). After the maker settled and Reactive dispatched, the protocol queue went to exactly zero, matching the queued amount to the last digit. That precise reconciliation across two chains, with no human in the loop, is the milestone.

Why this matters

In the original announcement we said this integration would show Reactive handling "queues, aggregation, and batched execution across chains." Milestone 2 is the receipts. This isn't event mirroring, copying a log from one chain to another. It's a stateful, bounded, fault-tolerant, fairly-billed settlement engine that aggregates work across many users and acts exactly when conditions are met, with the accounting living entirely on-chain.

For Fiet, that turns asynchronous settlement from a UX tax into something that just works. For us, it's one of the most sophisticated things built on Reactive to date: not a toy, but infrastructure with real money moving through it on mainnet.

As more off-chain capital wants on-chain exposure, asynchronous settlement stops being an edge case and becomes the default shape of a lot of DeFi. If that's true, the automation underneath it can't be a bot someone forgot to restart; it has to be as trustless as the settlement itself. Fiet and Reactive just showed one way to build that. What's the next workflow waiting for someone to automate it properly?

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!