Multichain Execution Engine

Rift’s core innovation is a multichain execution engine.

Order Execution

An order is a request to go from asset A->B. To start execution, send money to the order deposit address. The best route to fulfill the order is determined upon receipt of funds, and then each leg of the route is executed. Orders have state and can track in progress transactions like swaps, bridges, and vault deposits/withdrawals. Notably, this means Rift can create and execute orders involving any asset, with any protocol, on any chain.

For example, imagine an order for selling Bitcoin.BTC for Ethereum.USDT. A user sends the BTC to the deposit address, and the engine determines the best route to execute this trade. Let’s say the best price for BTC is on Hyperliquid, then the route would be to bridge the BTC to Hyperliquid through Unit, execute a BTC/USDC spot trade on Hyperliquid, bridge the USDC out to Ethereum through CCTP, and finally trade the USDC for USDT on Uniswap, sending the output to the recipient address.

// The engine has an approved program for execution
ExecutionEngine {
    hash, // hash of execution image
    signers, // signers who control upgrades to the contract
    timelock,  // time before approved upgrade goes live
}

// Optimal route is determined at runtime
Order {
    depositAddress, // where to send money
    toAddress, // recipient of completed order
    route, // request for asset A->B
    state // progress of order
}

// example Bitcoin.BTC -> Ethereum.USDT path
[
    { step: "Bitcoin.BTC -> Hyperliquid.BTC", venue: "Unit" },
    { step: "Hyperliquid.BTC -> Hyperliquid.USDC", venue: "Hyperliquid" },
    { step: "Hyperliquid.USDC -> Ethereum.USDC", venue: "CCTP" },
    { step: "Ethereum.USDC -> Ethereum.USDT", venue: "Uniswap" },
]

Under the hood, execution nodes run Dstack to interface with TDX enclaves running docker images in cloud data centers. The explicit tradeoff in this design is trusting the hardware and data center to not have an exploit or execute a side channel attack at the data center to extract keys. Assuming this is true, the result is a multichain contract that can call any blockchain, protocol, and API on the internet!

Operational security benefits

In practice, users and teams often blind sign complex calldata, making it easy to accidentally sign malicious payloads. Instead, a universal entry point for every operation, users explicitly sending money to an address, is both operationally simpler and safer. User intent is more clear: you don’t send funds without thinking, so blind signing is unlikely to occur. And there is no operational complexity involved with signing or executing multiple onchain operations - a normal transfer kicks off an arbitrarily complex sequence of transaction signing to receive funds on the other side.

In addition to executing onchain, managing what code actually runs onchain is inevitably dynamic. Financially important code evolves over time, so immutability is impractical. Instead, Rift allows for a configurable group of signers to agree to code upgrades, gated by a specified time lock. Rift maintains hardware keys in addition to the deployment partner keys for maximum security. Refunds of all user funds can be triggered by any single admin key during the time lock window.