We decided to design rDAI in a very simple and straightforward way. We allow users to deposit their DAI, get back an equal amount of rDAI, and choose who gets the interest.
The core things we tried to optimize for were:
- rDAI must be easily transferable, and completely fungible
- The interest must be easily programmable
- Must work out-of-the-box with existing infrastructure
- The underlying investment must be liquid enough
The fourth point is in some ways the hardest, as it is totally out of our hands.
Thankfully, the DeFi movement has given some extraordinary projects to build upon.
Compound.Finance
Our Contracts currently use Compound Finance, and cDAI, as our interest generating system.
Compound lends out the DAI you supply with a variable interest rate, incentivizing the market to always keep enough reserves for users to be able to redeem at any time.
The value of rDAI tokens depends on them being completely backed and redeemable. While Compound can’t guarantee liquidity, cTokens are always backed by borrower collateral, and the market in general is sufficiently liquid.
While we love Compound, and the wave of new ideas it has brought with it, something may change in the future, and a better option may appear. For this reason we have designed rDAI to be completely agnostic regarding the underlying interest generating asset.
The Allocation Strategy
The Allocation Strategy defines the way rDAI interfaces with other DeFi protocols to use the DAI users deposits to generate an interest yield, while also allowing redeemability.
Our contract is designed with a very simple and (we hope) flexible way of integrating any interest generating protocol (or meta-protocol) to our system.
The IAllocationStrategy.sol interface, that you can find in its current draft here: https://github.com/decentral-ee/rtoken-contracts/blob/master/contracts/IAllocationStrategy.sol allows any protocol that issues fungible shares of some kind to investors to be used in the backend. These shares don’t necessarily need to be tokens, but all shares must have the same exchange rate to the underlying token.
On a very basic level, this sums up the whole of the rDAI contracts:
RToken.sol contract. This handles all the basic functionalities and stores all balances and data:
- ERC20 functions: transfer, approve, balanceOf, etc.
- Interest beneficiary functions: create, choose & change pools (called hats in the contract)
- Enter and exit functions: mint, redeem & payInterest
IAllocationStrategy.sol interface. These are the functions that allow the RToken contract to be interoperable with the Allocation Strategy contract
- exchangeRateStore: should return current exchange rate between underlying asset and saving asset
- accrueInterest: this function is called every time there is a transfer, and it should bring the exchange rate up to date
- investUnderlying: this function takes the DAI, and should use it to invest in the chosen interest generating asset
- redeemUnderlying: this function should take the interest generating asset, and exchange it for DAI
CurrentAllocationStrategy.sol contract.
This is where the interactions with external protocols happen, and in its current incarnation (CompoundAllocationStrategy.sol) interfaces only with Compound.
Building new Allocation Strategies
rDAI was started by a small team, but we want it to become a community project.
This is why we have designed the allocation strategy as an open system, where many different contracts can be built, vetted by the community, and deployed.
The allocation strategy itself is referenced in the rToken contract, and changing it is a function that doesn’t require redeploying the contract.
This function can be called by the “admin”. This admin will initially be held by the rDAI founding team, but in the not-too-distant future will be handled directly by the community through a DAO.
Would you like to help us integrate other protocols? Don’t be shy! Join us in our telegram group or get in touch on twitter!
