# Rift Documentation OpenAPI specification: https://www.rift.trade/docs/openapi.json ## What is Rift? Source: https://www.rift.trade/docs Rift is an API for executing anything onchain in 1 click, at the best price, with 0 added fees. Unlike other protocols that are secured by multisigs or staking, Rift uses secure hardware (cloud based TEEs) to programmatically move money through a sequence of protocols. What makes Rift unique? **Best price for every asset:** Rift builds the optimal route across 20+ venues to guarantee best price execution with 0 added fees. You can verify you’re getting the best price with our [**rate comparison tool**](https://rift.trade). **One click UX:** Any onchain action is now one click. Send money to your deposit address to kick off the order, and your desired asset magically appears in your wallet on the other side. No more approvals, blind signing call data, or waiting for transactions in a multi step flow to complete. **Non custodial:** Every deposit address is a one time wallet that the TEE controls. The Rift team cannot steal or arbitrarily freeze user funds. **Deep liquidity:** Rift taps into liquidity from every venue, so you can trade millions in a single clip for assets like BTC, ETH, USDC, USDT, and HYPE. ## Supported chains and assets | Chain | Assets | | --- | --- | | Arbitrum | All major tokens | | Base | All major tokens | | Bitcoin | BTC | | Ethereum | All major tokens | | Hyperliquid | BTC, HYPE, USDC | | Ink | All major tokens | | Robinhood | All major tokens | ## Supported venues | Venue | Type | | --- | --- | | Aave | Yield | | Across | DEX | | CCTP | Bridge | | Chainflip | DEX | | Coinbase | Stocks | | CoW Swap | Aggregator | | Fly.trade | Aggregator | | Hyperliquid | DEX | | Kyberswap | Aggregator | | Li.fi | Aggregator | | Mayan | DEX | | Morpho | Yield | | Near | DEX | | Nordstern | Aggregator | | OKX | Aggregator | | Ondo | Stocks | | Relay | DEX | | Rift | DEX | | Robinhood | Stocks | | Transit | Bridge | | Uniswap | DEX | | Unit | Bridge | | Velora | Aggregator | | xStocks | Stocks | ## Multichain Execution Engine Source: https://www.rift.trade/docs/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. ```pseudocode // 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. ## Use Cases Source: https://www.rift.trade/docs/use-cases Let’s talk about use cases of the execution engine. Fundamentally, every use case is just an order outputting a specific asset. Any starting asset can be the input for any use case. ## Swaps and Bridging By routing through multiple DEXs and bridges, any native asset swap is possible with Rift. This includes single chain swaps, cross chain swaps, and bridging assets. Below is an example multi hop route to buy 100k of BTC with USDC: 1. Ethereum.USDC -> Hyperliquid.USDC (via CCTP) 2. Hyperliquid.USDC -> Hyperliquid.BTC (via Hyperliquid Spot) 3. Hyperliquid.BTC -> Bitcoin.BTC (via Unit) ![Ethereum USDC to Bitcoin BTC through CCTP, Hyperliquid Spot, and Unit](/docs/images/use-cases-swaps-route.png) ## Payments Multichain routing means accepting payments in any starting asset is now possible. Since every order is just a deposit address, Rift is ideal for QR code payment flows. Below is an example payment route to pay in USDT on Polygon and receive USDC on Ethereum: 1. Polygon.USDT -> Polygon.USDC (via Velora) 2. Polygon.USDC -> Ethereum.USDC (via CCTP) ![Polygon USDT to Ethereum USDC through Velora and CCTP](/docs/images/use-cases-payments-route.png) ## Tokenized stocks and RWAs Every major tokenized financial asset is available in Rift’s routing. Buying and selling any stock works the same as any cross chain swap. Below is an example route to buy tokenized Apple stock on Robinhood with ETH on Ethereum: 1. Ethereum.ETH -> Ethereum.USDG (via KyberSwap) 2. Ethereum.USDG -> Robinhood.USDG (via Transit) 3. Robinhood.USDG -> Robinhood.AAPL (via Uniswap) ![Ethereum ETH to tokenized Apple stock on Robinhood through KyberSwap, Transit, and Uniswap](/docs/images/use-cases-stocks-route.png) ## Vaults Depositing into vaults has typically been a point of friction, since the vault lives on a single chain and only accepts certain assets. With Rift’s multichain routing, depositing into a vault from any starting asset becomes 1 click. Migrating between vaults is just as easy. Below is an example route to deposit USDT on Ethereum into a Morpho USDC vault on Base: 1. Ethereum.USDT -> Ethereum.USDC (via KyberSwap) 2. Ethereum.USDC -> Base.USDC (via CCTP) 3. Base.USDC -> Base.GauntletUSDC (via Morpho) ![Ethereum USDT to Morpho USDC vault shares on Base through KyberSwap, CCTP, and Morpho](/docs/images/use-cases-vaults-route.png) ## OTC Certain routes have Rift’s OTC protocol as a supported venue. This matches the taker with a third party maker directly, leveraging the TEE as escrow until the maker’s payment has been confirmed. Since this avoids paying fees to third party DEXs and works for any asset, it is often the best rate for routes where its offered. Below is an example OTC route to trade 1 BTC for cbBTC: 1. Bitcoin.BTC -> Ethereum.cbBTC (via Rift OTC) ![Bitcoin BTC to Ethereum cbBTC through Rift OTC](/docs/images/use-cases-otc-route.png) ## Security Model Source: https://www.rift.trade/docs/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. ## Frequently asked questions Source: https://www.rift.trade/docs/faq ## How does integrating Rift make me more money? Rift gets you the best price possible for any onchain action by aggregating liquidity and not charging a fee on top. By using Rift, you are not paying a middleman fee to a router and are executing at the best price available. This is more money for you! ## How do I know I’m getting the best rate when I use Rift? You can compare rates from every provider using our [rate comparison tool](https://rift.trade). We’re the best because we aggregate every major source of onchain liquidity with no added fee. Our execution engine also enables multistep routes offered nowhere else. ## What’s the difference between Rift and <my favorite aggregator>? Rift has two unique features: no fees and multichain execution. No fees means the underlying execution provider rate is exactly what you will pay. Multichain execution means we can perform multistep transactions involving multiple protocols, unlocking new liquidity nobody else can. ## So is Rift competitive with <my favorite aggregator>? Everyone wants order flow, so we want you to integrate us like any other aggregator. Where Rift is unique is providing routes that nobody else can. We actually work with many aggregators so they can grow their user base by offering larger size, more assets, and order types. Our goal is fundamentally to make all our partners more money, whether they view themselves as a competitor or not. ## If Rift doesn’t charge fees, how do you make money? We make money by sourcing liquidity from market makers and providing OTC execution for popular routes. We only make money if our execution is a better rate than all of the existing providers. If we are not the best execution provider for a swap, we simply pass you to the best execution provider and take no fees. We believe we should only make money when we’re creating new value for our users. ## Who has integrated Rift so far? We’re working with 50+ fintechs and the list keeps growing. Check the updated list [here](https://x.com/rifthq). ## Does Rift have a referral program? Yes, we pay when an approved integrator goes live with our API. Reach out to our [BD](https://t.me/janjancz) [team](https://t.me/JaviArroyo) for details. ## How much volume has been traded so far on Rift? You can see a live tracker of our total volume [here](https://rift.trade). ## What’s the max swap? The maximum swap depends on the route, but for major pairs such as Bitcoin/USDC and ETH/USDC, it’s $10m+ in a single clip. Check live liquidity at [rift.trade](https://rift.trade). ## What chains and assets are supported? We support Arbitrum, Base, Bitcoin, Ethereum, Hyperliquid, Ink, and Robinhood. Asset coverage varies by chain. You can find the details in [Supported chains and assets](/docs#supported-chains-and-assets). We’re actively adding new chains and assets, and are prioritizing support for new assets based on volume and integrator demand. ## How do I know Rift is bug-free? There is no guarantee Rift is bug free :) But Rift has been heavily tested by our protocol team and has put millions of dollars of our own money through it (as have others!). Enterprise clients can inspect the code base for themselves. No third party audit has taken place yet. ## Is Rift a bridge? Rift aggregates bridges, so you can use it for trading any asset across chains. ## Is Rift controlled by a multisig? The Rift protocol runs in TEEs. Code upgrades are timelock gated by an onchain multisig controlled by the Rift team with hardware keys. Enterprise deployments can have their own instances with custom upgrade rules. ## Are universal deposit addresses per order or reusable? Every order has a unique deposit address. ## Do I have to send the exact quoted amount? No. You can send more or less than `from_amount`, and Rift uses everything you send to complete the order. The rate may differ from the quote if the amount is significantly different from what was quoted. If far below `from_amount` arrives at the deposit address and the order can't be filled, the order is `underfunded`. Contact our team using **Support**. ## Can a partner restrict the API to whitelisted addresses only, so orders only execute for wallets they’ve approved? Yes, Enterprise deployments support arbitrary whitelisting. ## Zero fee end to end is true even when the order lands directly in a vault or a tokenized stock, right? Yes. ## Does Rift support tokenized stocks? Yes, on multiple venues: Robinhood, Base, Ondo, xStocks. Check [terms](https://rift.trade/terms) for region and IP restrictions. ## Can tokenized stocks be traded at any time? Certain tokenized stocks are only liquid 24/5. Most venues don't quote them during off hours. ## How does the router resolve assets? Is it registered tickers only, or can it take just a contract address? You can pass any contract address to Rift, but for convenience we have a list of [registered popular tickers](/docs/integration/token-list) so you don’t need to look them up. ## What’s the failure rate on bridge + swap routes? So far, 100% of orders have completed successfully. 99.9% were executed and 0.1% were refunded. We’ve achieved this by aggregating multiple venues and removing the concept of slippage. Orders execute at the best rate/venue available at runtime, rather than being locked into a specific venue/slippage tolerance. While this is promising, sample size is small as we are still early. Check live metrics [here](https://rift.trade). ## What’s Rift’s quote latency (how long /quote takes to come back)? There are 2 quote modes: fast and optimal. Fast is ~1s. Optimal is ~5s. Check live metrics [here](https://rift.trade). ## What are the API rate limits? The default rate limit is 1 request per second. If you need a key with a higher rate limit, contact our team using **Support**. ## Does Rift support pre-IPO stocks? If there’s any contract address that’s available in major DEXs, you can pass it. But we don’t offer any as a registered asset. ## A partner can use Rift as the route and add their own fee on their side, right? Not yet, but integrator fees will be added soon. ## Is Rift the counterparty for trades? No, Rift is a peer-to-peer protocol for matching takers with makers. We aggregate onchain liquidity and protocols to offer execution to/from any asset. ## Can I plug into Rift’s OTC protocol? Reach out to our [BD](https://t.me/janjancz) [team](https://t.me/JaviArroyo) if you’re interested to be a maker with: - What routes you are most competitive on - What your rates are on that pair and your max size - What chains you support ## Is there a real advantage to routing through Rift versus integrating stocks providers directly? Rift supports trading to/from any asset into stocks, and guarantees you the best rate by integrating all the providers directly. It’s free to use us, so it’s the same prices as using any stocks provider for any routes they offer, plus all the new routes we offer. ## Quickstart Source: https://www.rift.trade/docs/integration/quickstart Every trade is three requests: 1. `POST /quote` prices the trade and returns a quote `id`. A quote can be turned into an order for ten minutes, until its `expires_at`. 2. `POST /order` binds the quote to your recipient address and returns a fresh `deposit_address`. 3. `GET /order/{id}` tracks the order once you send the deposit. You don't need an API key or a wallet connection. You send `from_amount` of the `from` asset to the order's `deposit_address`, and Rift delivers the output to your `to_address`. Assets are named `.`, for example `ethereum.eth`, `bitcoin.btc` or `base.steakhouseUSDC`. The chain is always spelled out (`ethereum`, not `eth`). The [token list](/docs/integration/token-list) has every registered name. > Replace the example addresses with your own before you run anything. Rift delivers to exactly the `to_address` you set, and transfers can't be reversed. ## Set up The examples are JavaScript modules for Node.js 22 or later. They call the Rift API, `https://api.rift.trade`, through two helpers. Save them as `rift.mjs` next to the examples: ```js const RIFT_API = "https://api.rift.trade"; // POSTs `body` as JSON, or GETs without one, and returns the parsed response. export async function rift(path, body) { const response = await fetch(`${RIFT_API}${path}`, { method: body ? "POST" : "GET", headers: { "content-type": "application/json" }, body: body ? JSON.stringify(body) : undefined, }); const text = await response.text(); if (!response.ok) throw new Error(`${path} failed (${response.status}): ${text}`); return JSON.parse(text); } // Checks the order every 10 seconds until it settles, logging each new status. export async function waitForOrder(id) { const settled = ["delivered", "refunded", "expired", "frozen"]; let status; while (true) { const order = await rift(`/order/${id}`); if (order.status !== status) console.log(`Order ${order.status}`); if (settled.includes(order.status)) return order; status = order.status; await new Promise((resolve) => setTimeout(resolve, 10_000)); } } ``` The deposits are sent with [viem](https://viem.sh) on EVM chains and Hyperliquid, and with [@scure/btc-signer](https://github.com/paulmillr/scure-btc-signer) on Bitcoin. Install both with `npm install viem @scure/btc-signer`. The paying wallet's key goes in `PRIVATE_KEY` (`0x`-prefixed hex) or, for Bitcoin, `BITCOIN_WIF`. Keep them in a `.env` file and run each script with `node --env-file=.env