“Orchestration” is a fancy word for an execution environment that allows for composing protocols on arbitrary chains. Conceptually, this can be thought of as a “multichain smart contract” that you send an asset and it automatically executes the steps to complete your order. For example, imagine a contract that accepts Bitcoin. The contract can bridge the BTC to Hyperliquid through Unit, execute a BTC/USDC spot trade on Hyperliquid, bridge the USDC out to Arbitrum through the native bridge, bridge that USDC to Ethereum through CCTP, trade the USDC for USDT on Uniswap, and send the USDT to the user’s wallet. 
Contract {
    send: Address, // sender
    receive: Address, // receiver
    route: Router, // execution path
    hash: String, // hash of docker image
    signers: Address[], // signers who control upgrades to the contract
    timelock: Timestamp,  // time before approved upgrade goes live
}

// example market order route
[
    { step: "Bitcoin.BTC -> Hyperliquid.BTC", venue: "Unit" },
    { step: "Hyperliquid.BTC -> Hyperliquid.USDC", venue: "Hyperliquid" },
    { step: "Hyperliquid.USDC -> Arbitrum.USDC", venue: "Native Bridge" },
    { step: "Arbitrum.USDC -> Ethereum.USDC", venue: "CCTP" },
    { step: "Ethereum.USDC -> Ethereum.USDT", venue: "Uniswap" },
]
A multichain smart contract has state, such as an in progress swap/bridge, a limit order to be executed at a venue at a specific price, or a vault receipt token. This means Rift can execute orders that aggregators cannot. Under the hood, protocol nodes run Dstack to interface with TDX enclaves running docker images in Google data centers. The explicit tradeoff in this design is trusting the hardware provider and data center operator not to execute a hardware attack at the data center to extract keys. Assuming this is true, the result is a “smart contract” that can call any blockchain protocol and API on the internet.

​
Operational security benefits

A single entry point for any contract, sending money to an address, is useful for safety of funds because manually signing transaction calldata is hazardous. In practice, users and teams often blind sign complex calldata, making it easy to accidentally sign malicious payloads. Payments to contracts make specifying intent clearer because you do not send funds without thinking, and make complex behaviors more secure because chained signing of transactions and orchestration of actions is handled for you. You simply receive funds at an address on the other side. Additionally, financially important code evolves over time. Immutability is impractical. Instead, a trusted group of signers must agree to code upgrades, and their upgrades are gated by timelocks. Blockchains are actually about making trust explicit, not eliminating it. Specifying the parties that have control of the code of this contract is ideal. Rift maintains hardware keys in addition to the deployment partner to make deployments more resilient. Refunds of all user funds can be triggered by any single admin key during the timelock window.