High-level system design
This design outlines the key concepts and basic user process of RIZE.
Architecture
Here is a brief overview of the RIZE smart contract architecture:
User directly interacts with the Ethereum smart contract. There are three interfaces for users to interact with for each asset supported by RIZE:
Deposit
Withdraw (request and claim)
RIZE permissioned token list: currently ETH, USDC, USDT.
Rize protocol handles user deposits / withdrawals, including:
Allocating deposit funds into different pools on different chains
Allocating funds to different pools on each blockchain
Handling withdrawals from pools and chains
Swapping reward tokens to deposit tokens to enable withdrawals
On Ethereum:
RIZE LP pool: issue and burn LP tokens. The LP tokens map to the allocation of the unified RIZE pool across multiple chains
Chain strategy to decide on which chain to allocate to or withdraw funds from
Virtual Pool: Pool info synced with RIZE pools on other blockchain. Synced info includes real TVL
Kiosk to verify, patch, or dispatch user deposits and withdrawal requests
On destination chains:
One pool for each token
An operator is able to distribute the fund into different pools
Auto-compounding to swap reward tokens to pool tokens, and stake back to the pools
Deposit and withdrawal will emit a bridging event / send funds to Ethereum. These are handed by bridging partners such as Wormhole.
LP, Rebase and asset mapping
There will be a map from LP tokens to actual assets summed up on multiple chains
For withdrawals, user LP tokens are burned and will have fund withdrawals that match the mapping assets
The value is assigned at a rebase event
User Process
1. User deposit
After depositing, users receive LP tokens instantly
LP tokens are proportional to user assets deposited vs the total assets from virtual pool data
User deposits are put in the Kiosk. The Kiosk operator triggers the bridge and sends the funds to destination blockchains
When funds arrive on the destination blockchain, the operator distributes and LPs the assets to corresponding protocol to earn yields
2. User stake
User deposits sit in vault on target chains, which will be allocated to established and audited DeFi protocols. These include lending markets and DEXs that utilize price feeds from established oracle providers like Pyth.
The vault auto claims rewards from DeFi protocols (if any), and swaps into the staking assets. These are put back into the staking pool to enable auto-compounding
The total deposit on destination chains increases overtime. The real total TVL is synced to the Ethereum virtual pool during rebase
3. User withdrawals
Users submit withdrawal requests by putting the LP token into the smart contract
The withdrawal request is batched and sent to destination chain
The pool on the destination chain handles the withdrawal request, and batches withdrawal assets back to the Ethereum Kiosk
Users are able to claim withdrawal amounts from the Kiosk
4. Rebasing
There is a rebase mechanism that combines all of these operations.
The rebase process is periodically triggered by the system operator
The rebase takes at least one round trip from the source chain to a target chain
The rebase takes at least 20 mins in its current form
The rebase has the following steps
Update LP tokens according to user withdrawal /deposit request
Forward the withdrawal/deposit request to the destination blockchain, along with the assets in the Kiosk
The allocation of withdrawal or deposit is decided by the operator.
On the destination chain, execute the withdrawal / deposit request.
On destination chain, claim rewards and swap into the staking token.
Send withdrawal assets back to the Ethereum smart contract.
Sync pool info back to the virtual pool on Ethereum.
Last updated