Reserve platform risks
This section is dedicated to explaining risks associated with using the Reserve platform. Whenever you interact with the Reserve platform, you as the user assume the risk of doing so. We believe that making best efforts to comprehensively outline risks creates accountability and empowers users. Any time you are uncertain about a particular risk, we invite you to ask on Discord.
We encourage all users to familiarize themselves with these risks and continually stay updated about changes that may affect the protocol.
Reserve platform risks - Smart contracts
The Reserve platform is built using smart contracts. If there were undiscovered bugs or vulnerabilities in these contracts, they could be exploited leading to loss of user funds. Although the protocol's contracts have undergone multiple security audits, no audit can guarantee complete security.
Smart contract-related risks can manifest in a variety of ways. A number of pertinent examples and categories are detailed below.
Oracle risks
The Reserve Yield Protocol uses oracles to fetch real-time price data. If these oracles fail or deliver incorrect information, or if the usage of oracles on Reserve is otherwise incorrect, it could impact the protocol's ability to maintain accurate accounting and lead to other operational disruptions. For example, if Chainlink misreports the price of USDC, a Yield DTF may consider a collateral asset to have defaulted and attempt to swap to emergency collateral, potentially at a loss.
Sandwich attacks and MEV
MEV searchers are constantly scanning the Ethereum blockchain to look for profitable opportunities to extract value. When interacting with AMMs (such as Curve Finance for trading DTFs), users should exercise caution and consider the slippage, which dictates the degree to which searchers can extract from users’ transactions. There are other ways for users to independently seek MEV protection, such as through the Flashbots RPC.
Governance risks
The Reserve team has deployed a suggested governance systems for DTFs, which enable fully onchain governance to DTFs. The scope of the powers are broad, so it is possible for governance attacks to happen. These potential attacks could involve an attacker accumulating enough governance power to enact a malicious upgrade allowing them to steal funds.
This type of attack is mitigated through the existence of special roles; however, these special roles must be wielded effectively and benevolently in order to offer meaningful protection. When using an DTF, it’s a good idea to familiarize yourself with who holds each of these special roles, which you can do on the Details + Roles page and the Governance page on the Reserve app.
Collateral asset risks
Issuer/Custodian
It is possible for stablecoin (and other) issuers to impose restrictions on transferability, through blacklists. Although commonly intended to target sanctioned individuals, it is possible for these powers to extend to DeFi protocols. Additionally, stablecoin issuers are relied on for maintaining healthy reserves of real world assets. The strategies used to maintain these reserves may sometimes fail, or the custodians themselves may not always act in good faith. The best way we are aware of to familiarize yourself with the risks for any given underlying stablecoin is to review the report on that asset published on Bluechip, if they cover that asset.
Price
DTFs inherit the weighted price of all of their backing collateral assets. Where one or more underlying assets deviate in price (even where they are meant to be pegged), the aggregate price of the DTF will be affected. Fluctuations in DTF price should be anticipated where volatile collateral is present.
A slightly distinct price consideration involves that of the RSR overcollateralizing Yield DTFs. Based on the amount of RSR that must be sold to re-collateralize a default, significant market movements may neutralize the effectiveness of the overcollateralization stemming from a weaker mark to market price.
Underlying protocols
Reserve DTFs leverage assets from external protocols, like Compound, Aave, Flux, and many more. Users therefore assume all of the risks of these underlying protocols (smart contract, governance, or otherwise) when holding DTFs.
Reserve platform risks - Interfaces
Front-end operator risks
The Reserve platform can be interacted with directly through its smart contracts, or through third party-created user interfaces. The Reserve app, for example, is run by a third party company, and has not yet undergone a technical audit. Users must always be vigilant for malicious or compromised frontends, such as in Badger’s case. Even in normal operation, bugs in front-end code may be responsible for requesting erroneous transactions which could result in user losses.
Anyone can create an RToken
In a similar way as how anyone can create a new trading pair on Uniswap, anyone can permissionlessly create a new Reserve stablecoin (RToken) by interacting with Reserve Protocol’s smart contracts. The protocol applies a system of factory smart contracts that allows anyone to deploy their own smart contract instance.
Creating an RToken can be done either by interacting directly with the Reserve Protocol’s smart contracts or any user interface that gets built on top of it. The first user interface for these smart contracts will be released by ABC Labs the company that's leading protocol development. Besides the creation of RTokens, this user interface will also support exploring usage and stats related to RTokens, RToken minting & redeeming, and RSR staking.
Non-compatible ERC20 assets
The following types of ERC20s are not supported to be used directly in an RToken system. These tokens should be be wrapped into a compatible ERC20 token to be used within the protocol. A concrete example is the use of Static ATokens for Aave V2.
- Rebasing Tokens that return yields by increasing the balances of users
- Tokens that take a "fee" on transfer
- Tokens that do not expose the decimals() in their interface. Decimals should always be between 1 and 18.
- ERC777 tokens which could allow reentrancy attacks
- Tokens with multiple entry points (multiple addresses)
- Tokens with multiple entry points (multiple addresses)
- Tokens that do not adhere to the ERC20 standard in general
Advanced RToken parameters
When deploying an RToken, the deployer has the ability to configure many different advanced parameters. The following list goes into detail about what these parameters do and some of the factors the deployer should keep in mind to set them.
As many of these parameters concern the Protocol Operations, we advise reading through that section of the documentation first—as it will give the deployer the necessary context to fully understand all parameters.
Trading delay(s)
The trading delay defines how many seconds should pass after the basket has been changed before a trade can be opened.
A collateral asset can instantly default if one of the invariants of the underlying DeFi protocol breaks. If that would happen, and we would not apply a trading delay, the protocol would react instantly by opening an auction. This would give only auctionLength seconds for people to bid on the auction, making it very possible for the protocol to lose value due to slippage.
The trading delay parameter may only be needed in the early days - before we get to a point where there is a robust market of MEV searchers. We expect that this parameter can be set to zero later on (once a robust market of MEV searchers is established).
