Escrow

The Escrow contract acts as the central settlement point for bridging transactions on Most. Its primary responsibilities are to securely hold user funds, validate that an order has been fulfilled on the destination chain, and release those funds to the Market Maker (MM) once the proof is confirmed. It also supports pre-bridge token swaps, allowing users to deposit in one asset and have it converted before bridging.

Intent Creation

The bridging process begins when a user creates an order to send funds to another chain. This can happen in two ways:

• Direct deposit using createOrder, where the user sends either native ETH or an ERC20 token directly to the contract.

• Swap then deposit using swapAndCreateOrder, where the user’s ERC20 tokens are swapped through a series of hooks before being deposited into the Escrow.

In both cases, the contract records the source and destination details, the amount to be bridged, and an expiry time after which the order can be refunded if not fulfilled. Each order is hashed and stored in the contract’s state, with its initial status set to pending.

If the order is created via the swap function, a HookExecutor is deployed using CREATE2 and executes the swap instructions on-chain. Once the swap is complete, the resulting tokens and amounts are stored and used as the source assets for the order.

Proving Fulfillment and Withdrawing

Once the funds have been delivered on the destination chain, the Market Maker responsible for fulfilling the order must prove this to the Escrow contract. This is done through a single call to proveAndWithdrawBatch, which both validates the proof and releases the funds.

Under the hood, the proof is verified using the Herodotus Data Processor (HDP). The contract prepares the order hashes, destination chain details, and the block number at which fulfillment occurred, and sends these as inputs to the HDP program. The HDP checks that each order exists in the payment registry on the destination chain, which is only possible if the order was actually fulfilled there, and returns a Merkle root of the result. The Escrow contract computes its own Merkle root from the expected output and compares it against the HDP’s result, ensuring that the proof is authentic.

If the verification passes, all orders in the batch are marked as completed, and the aggregated amounts owed to each Market Maker are released. This flow allows multiple orders to be proven and withdrawn in one call, reducing gas costs and operational overhead.

Refunding Expired Orders

If an order isn’t fulfilled before its expiry time, the user who created it can reclaim their funds by calling refundOrder. The contract verifies that the caller is the original depositor, that the order is still pending, and that the expiry time has passed. If these checks succeed, the order is marked as reclaimed and the original funds are returned, whether they were deposited in ETH or ERC20 tokens. Refunding is never subject to the contract’s paused state, ensuring users can always retrieve their expired orders.

Additional Contract Features

The Escrow contract supports both native ETH and ERC20 tokens, integrates seamlessly with the HDP for proof verification, and allows orders to be created with or without an initial swap step. The initial swap is used to protect MMs from being exposed to price volatility over extended periods of time. The Escrow also includes safety features such as pausing functionality, reentrancy protection, and strict validation of all order data before any state changes occur. Destination chain connections for the HDP can be added by the contract owner, enabling the system to expand to new networks over time.

This design allows the Escrow to operate as a secure, flexible bridge settlement layer, capable of handling straightforward deposits, complex swap flows, and batched cross-chain settlement proofs, all while maintaining strict cryptographic guarantees that only real, fulfilled orders can be paid out.