Security Model
The security model of Rift’s multichain execution engine is fundamentally different from a smart contract on a single chain like Ethereum, although the goal is the same: programmatic execution that cannot be altered (e.g. stealing or selectively freezing user funds) by an operator. Unlike smart contracts, which require persistent state, execution is transient, and only requires ephemeral state. This significantly reduces risk surface area to only in-flight funds.
Permissionless systems are expensive
In Ethereum, or other proof-of-stake blockchains, security comes from node operators staking capital that is slashed via social consensus if they violate protocol rules. The idea is that a malicious actor will lose more money via slashing of their ETH than they could theoretically gain by the attack. While this provides means the network is permissionless because anyone who has enough ETH can be a validator, it comes at a large cost: idle capital. In the case of Ethereum, there are billions of dollars sitting with the sole purpose of being used as collateral in case the protocol rules are broken. This is a very inefficient use of capital, and one of the core reasons why non custodial systems have failed to beat centralized alternatives for pricing most major pairs.
Core Dependencies
Rather than allowing anyone to stake on any hardware, Rift leverages trusted execution environments (TEEs), which are specialized hardware running in a data center that enforce execution of specific code and do not allow anyone without physical machine access to read confidential data they operate on. This is extremely powerful because it eliminates the need for staking. There is no capital needed to enforce protocol rules. Instead, it introduces trust on the hardware manufacturer of the TEE and the data center where the node is running. This is an explicit tradeoff made to optimize for capital efficiency and multichain composability over permissionless, software-only nodes.
In addition to the risk of the infrastructure stack, there is venue risk. As an example, if there was an active order placed through Rift on Hyperliquid, and Hyperliquid was hacked, funds from this transaction would be lost. Essentially, by using an execution engine, you are inheriting risk of the execution venues as a dependency. This is similar to a user inheriting risk from a Morpho vault if an Ethereum contract they deposited into utilized it.
Finally, there is also risk in the underlying Rust protocol code. Whether written by the team or an open source dependency, all of this human-written code is additional implementation risk for the entire system’s security, in the same way that on Ethereum you are inheriting the full software supply chain risk, including smart contract code, compiler, and execution client.
Cloud Infrastructure
Rift runs our production environment in Phala’s data centers, utilizing Intel TDX via Dstack. Any one of these three components failing could mean the loss or extraction of private keys from the instance. You must assume that the hardware manufacturer, in this case Intel, does not get enclave attestation keys compromised or have a critical vulnerability, and the cloud provider, Phala, is not actively tampering with the hardware and is ensuring physical security of its data centers.
Upgrades and Key Management
Contract upgrades are gated by a smart contract on Ethereum. The contract has the hash of the system image that should run in the TEE. For an upgrade to be accepted, the hash stored in the contract must be updated to match the new proposed image. This operation is gated by a multisig, which is currently hardware keys managed by the Rift team.
This set can be customized for deployment partners, so the deployment partner also maintains hardware keys that must sign off on upgrades. Additionally, custom timelocks can be set on this upgrade going live into production. If a malicious upgrade were deployed due to the majority of hardware signers being compromised, users can still withdraw funds with a single non-compromised hardware signer calling an emergency refund operation for active orders.
Future Improvements
The core failure modes of the system are vendor based: either a compromise of the TEE hardware, a compromise of the data center, or extended outages across all nodes. The way we can reduce dependency on infrastructure providers, namely Phala and Intel initially, is by going multi-cloud and multi-hardware.
The first step would be replicating the existing TDX setup on other major clouds that support it (e.g. GCP / Azure). The ideal design would use 2/3 signing on all execution operations from multiple cloud providers running the node. This would greatly decrease risk of a compromise, as 2/3 of the data centers would need to be compromised simultaneously to perform an attack.
There is still risk of a 0-day or Intel compromise in this example. Taking the same idea a step further, all execution steps could require 2/3 across TEE architectures and cloud providers (AWS offers programmable enclaves, Nitro, and Azure offers AMD SEV-SNP). This would now require 2/3 of the architectures and data centers to be compromised simultaneously to perform an attack. Additionally, the chance of a liveness failure is greatly reduced, empirically to near zero, as all instances at 2 major cloud providers would need to simultaneously go down.
A further level of customization would be to choose your own cloud provider and hardware configuration. So for example, if you’re based in China and you do not want to use an American cloud provider, there could be a custom deployment utilizing other reputable cloud providers that are using reputable hardware execution environments.
Another risk is the entity running the cloud infrastructure (e.g. Rift) shut it down, or have their accounts shut down. Allowing partners to self host nodes on whitelisted cloud providers and hardware would reduce the fragility of the system by eliminating the risk that a single entity’s cloud instances are shut down.
