Protocol

Rift runs a Bitcoin node and EVM light client (helios) inside a TDX enclave to escrow and release BTC and cbBTC upon verification of a receipt of funds.

Since security is enforced by hardware rather than staking, Rift has best-in-class capital efficiency for Market Makers and users.

How Swaps Work

ERC20 → BTC

Step 1: User requests quote from Market Makers

Users starting with ERC20s (ETH, USDT, USDC, etc) are routed through an on-chain pool to cbBTC. Market Makers quote a cbBTC↔BTC exchange rate.

Step 2: User accepts quote and requests an Ethereum wallet

The TEE creates a new Ethereum private key for this trade. This key is only revealed to the Market Maker if they send the exact agreed-upon BTC amount to the user’s wallet.

Step 3: User sends asset to TEE-generated wallet

Any ERC20s are swapped to cbBTC to send to the Market Maker.

Step 4: Market Maker sends BTC to user

After 4 Ethereum confirmation blocks, the Market Maker sends BTC to the user.

If the MM doesn’t send BTC within 24 hours, the user can withdraw their funds from the TEE.

Step 5: TEE reveals wallet private key to Market Maker

After 2 Bitcoin confirmation blocks, the TEE reveals the Ethereum wallet private key to the Market Maker. This allows MMs to bundle sends and optimize gas fees around low network traffic times.

BTC → ERC20

BTC→ERC20 swaps work the same way, with the order of actions flipped:

• The TEE creates a one-time-use Bitcoin wallet
• Market Maker sends ERC20
• TEE reveals Bitcoin private key after confirmations

Initially, the only output ERC20 is cbBTC. In the future, post-swap hooks will route you to any token.

Security Model

Our goal is to achieve maximum security for native asset swaps. We’ve done this by reducing our attack surface area to “in-flight” funds, and eliminating multi-sigs for custody.

However, TEEs come with inherent risks. We’ve outlined these (as well as our mitigations) below:

Risk: TEE goes offline after User has sent funds

Consequence: Funds are frozen until back online. Assuming the machine is able to be restarted, this is simply a minor delay in the user being paid out. In the case of a catastrophic cloud failure (machine blows up) or nation state level freeze (US govt tells cloud provider to freeze the instance), funds can be frozen indefinitely. Since risk is limited to in flight swaps, the maximum exposure is the last 20-30 minutes of trading, which means users can be made whole in the worst case.

Current mitigation: User verifies TEE is online before sending funds. Fail case is extremely unlikely, as TEE would need to go offline during the exact ~20 min clearing window after the user sent funds, and stay offline indefinitely.

Future mitigation: Create a network of TEEs, where any 1 of N can execute an order. This greatly reduces the risk of frozen funds, as it would now require every node on the network to be offline indefinitely.

Risk: MM never pays user

Consequence: User funds are locked for 24 hours, at which point they can be refunded.

Current mitigation: Working with reputable MMs that fill orders they commit to + blacklisting any that break this SLA

Future mitigation: Allow users to specify the counter party to fill their order

Risk: Dstack (Confidential VM OS) or Phala (TEE IaaS provider) have a critical vulnerability or backdoor

Consequence: Private keys can be extracted by root user

Current mitigation: Dstack is open source and audited. Phala is audited and uses bare-metal signatures, which we verify in the browser to ensure they are running the confidential VM image they claim in the cloud.

Future mitigation: Expand support to all major cloud providers (AWS, GCP, Azure, etc). Removes vendor reliance outside of user’s chosen cloud provider and processor manufacturer.

Risk: Hardware side channel attack on TEE at data center during swap

Consequence: Private keys can be extracted by attacker

Current mitigation: Enforce that TEE is run on a major cloud provider with good physical security. Makes an attack extremely difficult since the attacker would need access to the physical machine in the data center and execute the hardware side channel attack during the swap clearing window. This is ~20 mins for BTC↔ETH.

Risk: Cloud provider Hypervisor has a backdoor/access to VM

Consequence: Private keys can be extracted by cloud provider admin

Current mitigation: Exclusively using cloud providers that offer bare-metal TEE access from a confidential VM, making it impossible for the cloud provider to decrypt the disk, unless they perform a hardware attack on their customer (which will be publicly visible for eternity)

Risk: TEE operator withholds blockchain data from machine, creating a stale full node

Consequence: Operator can create a fraudulent transaction to the user to claim funds from the TEE

Current mitigation: User can hit a trusted RPC to get the latest block data and verify the TEE has the same chain tip before sending funds. This is automatically handled in the browser.