Security
Security & audits
Reserve aims to establish a robust and stable asset-backed currency platform. However, this necessitates the implementation of an additional layer of smart contracts, introducing an extra level of smart contract risk.
The Reserve team is aware of these tradeoffs and has prioritized security by undergoing multiple audits conducted by the world's leading security firms.
Smart contract security audits
Bug bounty
In addition to undergoing numerous audits, the Reserve team would like to motivate the community to undertake their own audits and will reward individuals who responsibly disclose any vulnerabilities they find.
Bug bounty of $10,000,000
Reserve has partnered with Immunefi for establishing a bug bounty program. See additional details of the program, or report any findings here:
https://immunefi.com/bounty/reserve/
Risks
For a detailed overview of potential risks and risk-mitigation strategies, see the Risks page:
https://reserve.org/protocol/risks/
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 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 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 that do not adhere to the ERC20 standard in general
Advanced RToken parameters
When deploying an RToken, the deployer can configure many advanced parameters. The following sections describe what these parameters do and factors the deployer should consider when setting them.
As many of these parameters concern the Protocol Operations, it is advised to read that section of the documentation first for necessary context:
https://reserve.org/protocol/yield_dtfs/protocol_operations/
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 a robust market of MEV searchers exists. It is expected this parameter can be set to zero later on once a robust market of MEV searchers is established.
FAQ (links)
Last updated