# 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 onchain execution. You can use it for trading tokens, stocks, and earning yield onchain. ## What makes Rift unique? **Best price:** Rift builds the optimal route by tapping into liquidity across 20+ venues to guarantee best price execution. You can trade millions in a single clip for assets like BTC, ETH, USDC, USDT, and HYPE and 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:** Unlike other protocols that are secured by multisigs or staking, Rift uses TEEs to programmatically execute orders through a sequence of protocols. The Rift team cannot steal or arbitrarily freeze user funds. **0 added fees:** Unlike other aggregators and trading APIs, Rift charges 0 added or hidden fees. You just get the rate of all our integrated venues. We only make money if our solver offers the best price vs every other venue. ## Supported chains and assets | Chain | Assets | | --- | --- | | Arbitrum | All major tokens | | Base | All major tokens | | Bitcoin | BTC | | Ethereum | All major tokens | | Hyperliquid | BTC, ETH, HYPE, USDC, USDT | | Ink | All major tokens | | Polygon | All major tokens | | Robinhood | All major tokens | ## Supported trading venues | Venue | | --- | | Across | | CCTP | | Chainflip | | CoW Swap | | Fly.trade | | Hyperliquid | | Kyberswap | | Li.fi | | Mayan | | Near | | Nordstern | | OKX | | Relay | | Rift | | Transit | | Uniswap | | Unit | | Velora | ## Supported yield venues | Venue | | --- | | Aave | | Euler | | Morpho | | Tydro | | UltraYield | ## Supported stock venues | Venue | | --- | | Coinbase | | Ondo | | Robinhood | | xStocks | ## Multichain Execution Engine Source: https://www.rift.trade/docs/multichain-execution-engine Rift’s core innovation is a multichain execution engine. Every protocol is a hook that executes in a sequence inside the TEE. This is how we’re able to tap into the liquidity of every onchain protocol, creating an optimized route that no single protocol can offer, while having every action be just 1 click. ## 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 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 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 ## The basics ### Is Rift an aggregator? Yes, and more. We’re an execution API - so you can use Rift for anything you want to do onchain, like trading, bridging, and earning yield. Essentially every onchain protocol becomes a hook that can be called inside our execution engine. ### What’s the difference between Rift and <X> aggregator? Rift offers the best prices, zero added fees, and 1 click trading. We figured out multichain execution so we can tap into more liquidity sources and build more complex routes than any other aggregator, while making every action 1 click. ### Is Rift a bridge? Yes, and more. You can bridge then swap then deposit all with 1 transaction by using our API. ### Is Rift the counterparty for trades? No, Rift is a peer-to-peer protocol for matching takers with makers. Our non custodial execution engine leverages onchain liquidity to fill orders to/from any asset. ### How do I know I’m getting the best rate? 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. You can compare rates from every provider using our [rate comparison tool](https://rift.trade/). ### If Rift doesn’t charge fees, how do you make money? We have a solver that competes to win the trade. If we offer the best price, we make money. If not, you get routed to the best market rate and we make nothing. ### How much volume has been traded so far? Check live stats [here](https://www.rift.trade/transactions). ### 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! ### Can Rift comarket my product? Yes, if you integrate Rift we’re happy to comarket your product on Twitter. Reach out to our [team](https://t.me/riftsupportbot) to coordinate this. ## Integrating ### Do I need an API key to use Rift? You don’t need an API key to start using Rift! ### What are the API rate limits? 1 request/second with no key. If you need more, reach out to our [team](https://t.me/riftsupportbot) to get an API key. ### How do I get an API key for Rift? Message our [team](https://t.me/riftsupportbot) to get an API key. ### Are quotes exact? Quotes are indicative, not exact. Rates onchain change in real time, so you are subject to volatility during execution. Rift will route you to whichever venue has the best rate when you send funds. ### How do I set slippage on Rift? Rift doesn’t have a max slippage concept. We instead force execution at the best available price so your order always completes instead of reverting. ### If Rift doesn’t have slippage, how do I ensure I’m getting a good price? Rift plugs into many liquidity sources for every route, and dynamically determines the best price / route at each step. The assumption is that if you want to execute now, you’re inherently subject to some volatility for the next N seconds while your trade executes. The best we can do is match you with the best available provider, and at least 1 should have a good rate. If it doesn’t, you’re trading something extremely illiquid and if you were trying to dump it you still want to execute regardless. ### Does Rift have MEV/front running risk? Rift submits transactions to a private mempool (Flashbots) for MEV protection on EVM chains. ### What’s Rift’s quote latency? There are 2 quote modes: fast and optimal. Fast is ~1-2s. Optimal is ~5-10s. Your mode doesn’t affect execution quality - everything is re-quoted on optimal once funds are sent. ### Are 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 `amount_in`, 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 the deposit amount is too small and the order can’t be filled, the order is `underfunded` and will be refunded. ### Can I restrict the API to whitelisted addresses? Yes, enterprise deployments support arbitrary whitelisting. ### Can I set an additional “integrator fee” on top of the trade? Yes. Add `integrator_fee_bps` and `integrator_fee_recipient` to the quote request, and Rift pays you that share of each order's output when it delivers. See [integrator fees](/docs/integration/integrator-fees). ### Who has integrated Rift so far? We’re working with many of the top fintechs in the space, check [here](https://x.com/rifthq) for the updated list. ### Does Rift have a referral program? Yes, we pay when an approved integrator goes live with our API. Reach out to our [team](https://t.me/riftsupportbot) for details. ## Security and reliability ### 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. ### 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 audited? No third party audit yet, but soon. ### What if the order fails halfway through? How do refunds work? Rift will try all possible venues for a route if one is down during execution. For a refund to occur, every venue for a leg of the route must fail. If this happens, and none come back online during the timeout window, the user will be refunded back to their original asset. This refund means going through a venue, so they will receive back less than their starting amount. ### What’s the failure rate on bridge and swap routes? As of now, 98.9% of orders completed successfully with 1.1% being refunded to the original asset. ## Supported assets and routes ### What chains and assets are supported? [Full list of supported chains and assets](/docs#supported-chains-and-assets) We’re actively integrating new chains, protocols, and assets. We prioritize support based on volume and customer demand. ### How does the router resolve assets? 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 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 on our [frontend](https://rift.trade) or by calling our [quote](/docs/api/get-a-quote) endpoint. ### Is zero fee end to end true even when the order lands in a vault or a tokenized stock? 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, because many venues don’t quote them during off hours. But if there is any liquidity available in DEXs, you can trade them. ### 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. ### Is there an advantage to routing through Rift versus integrating stock 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. ## OTC ### What routes are currently supported by Rift OTC? We currently support Bitcoin.BTC<>Ink.kBTC. ### Can I be a solver on Rift’s OTC protocol? Reach out to our [team](https://t.me/riftsupportbot) 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 ### How do I get a new route supported by Rift OTC? You can reach out to our team about what route you want. Generally we’re prioritizing based on what the volume looks like on that route and if a better rate can be offered than existing protocols. ## 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. An API key is optional, and you don't need a wallet connection. You send `amount_in` 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"; // Your API key is optional, but without one, requests are limited to 1 per second. const RIFT_API_KEY = process.env.RIFT_API_KEY; // POSTs `body` as JSON, or GETs without one, and returns the parsed response. export async function rift(path, body) { const headers = { "content-type": "application/json" }; if (RIFT_API_KEY) headers["x-api-key"] = RIFT_API_KEY; const response = await fetch(`${RIFT_API}${path}`, { method: body ? "POST" : "GET", headers, 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