Smart Contract Overview


The core primitive in the Rift Protocol is a Vault.
A Vault is a smart contract that accepts deposits and manages return profiles for a pair of tokens: token0 and token1.
token0 is the asset of profit-motivated depositors. token0 may be an arbitrary ERC20, or the native asset of the chain.
token1 is the asset of liquidity-motivated depositors. token1 must be some arbitrary ERC20.
A Vault pairs token0 and token1 deposits and provides liquidity to the token0 / token1 pool in some DEX.


Due to the nature of providing liquidity in DEXs today, vault deposits / withdrawals immediately forwarded to the DEX pool would be exposed to price manipulation attacks from arbitrageurs. To prevent this, Vaults employ an epoch system.
A Vault will perpetually split its lifespan into repeated epochs. Initially, this epoch duration is set to 30 days. All deposits and withdraws requested during some epoch are collected, but not yet paired in the DEX. At the end of an epoch, deposits and withdraws are aggregated, and either paired in or unpaired from the DEX pool.
A user can deposit either token at any time. In order to withdraw, a user must submit a withdrawal request. That withdraw request will be resolved by the Vault at the end of the epoch, t which point the users share of tokens will be available to claim.
To prevent any price manipulation attacks, these interactions must be executed within certain constraints. In order to ensure these constraints are met, there is a vault manager account with the ability to advance the vault to the next epoch.

Return Management & Lazy Accounting

Fees & rewards earned by the Vault's LP position are distributed evenly to all token0 depositors. If the Vault's LP position suffers significant impermanent loss that exceeds yield, token1 deposits (DAOs) are used to make token0 depositors (LPs) whole again, according to the rules defined in the How It Works and Risk and Return pages.
Given the Vault's established position in a DEX, the amount of token0 or token1 to which a depositor has claim will change over time. Instead of using staking tokens, which would require users to later return to the vault to check and claim their balances, we employ a method that minimizes users' costs by tracking just a few global variables: the exchange rates for token0 and token1, and their values across past epochs. Since the changes in balance are distributed proportionately across all accounts, we can just use these internal variables that track each user's deposit balance over time. The next time an individual user wants to make a deposit or withdraw, they will cover the gas cost of actually updating their balance according to the recorded global variables.