Yield Improvement Proposals (YIPs) describe standards and features for the RAY platform, including core protocol specifications, client APIs, contract standards and product improvements.
We encourage anyone to propose a YIP. Please follow the instructions here to start putting together your first YIP.
A large part of proposing a successful YIP is the validation of added value - driven by the data supplied that such as alpha (extra yield), liquidity, frequency, etc. These are required in the Yield Evaluation & Risk Evaluation sections of a YIP.
Sources of data are evaluated on data collection methodologies and accuracy. Below are priority lists of different sources. RAY will provide out-of-the-box code that can be used to pull data from these different sources.
Historical Rate Data
Loanlist.io - Collect historical and real-time lending/borrowing rates across different coins and protocols.
Loanscan.io - Collect historical and real-time lending/borrowing rates across different coins and protocols.
Use this section to clearly explain the value add to RAY using historical data.
This section needs to clearly explain the risk attached to the opportunity and potential mitigation techniques using historical data.
Below are some requirements for adding a new coin:
Sufficient support: Needs to be supported by a minimum of two existing opportunities.
Sufficient liquidity: Opportunities markets should have sufficient liquidity. Generally, this is an equivalent of minimum $200,000 USD.
Sufficient demand: A clear demand for the coin should be present. This can be proven through community consensus and surveys.
Below are some requirements for adding a new opportunity:
Risk-minimized: RAY is not appropriate for speculative opportunities. All speculative opportunities should be relatively atomic in nature (Ex. arbitrage, liquidations, etc.). An example of a risk-minimized category is lending.
Sufficient liquidity: Opportunities markets should have sufficient liquidity, generally this is an equivalent of minimum $200,000 USD.
Coin support: Support one of the coins approved by RAY - currently ETH, DAI and USDC
For an on-chain opportunity implementation to be valid and accepted it needs to follow a few criteria, detailed below:
Security: Run without issue on the static analyzer Slither with all analyzers enabled. Note, some flagged detection's are acceptable, but will need manual review.
Interface support: Follow the appropriate Opportunity interface. Currently RAY only has one, tailored for multi-block opportunities such as lending or liquidity providing. Input on tailored interfaces for other opportunity types is welcome as we look to add them.
Dynamic settings: Open support for any valid coin to be added in the future.
Good design: Be able to provide a sufficient explanation of any questions regarding design and implementation choices. Key considerations include trade-offs between gas complexity, modularity, features (ie. upgradability), and security.
Written in Solidity 0.4.25 / 0.5.11
Follow the same access control patterns as existing Opportunity contracts. Note, contributors don't need to add RAY-specific fallbacks (ex.
A single Opportunity contract should be able to support any number of ERC20 coins if the underlying opportunity supports more. This instead of having a different Opportunity contract per coin.
Dynamically call dependency contracts that may change, either RAY's or external. An example of one unlikely to change is a coin implementation such as DAI. An example of one that may change is Compound's interest rate model contract.
Where possible, use RAY's registry of addresses. Generally, this is for coins, RAY system contracts, and other opportunities (Compound, dYdX, etc.).
Good examples to follow these criteria are existing Opportunity contracts, which can be found here. Focus on Opportunity-specific integration.
For an opportunity off-chain implementation to be valid and accepted it needs to follow a few criteria, detailed below:
Interface Support: Follow the appropriate Opportunity Interface, generally detailed in the Specification of the YIP being implemented.
Coin Configuration: Implementations should be configured to run per coin/market.
Dependency Versions: For existing used dependencies, use the same version. Examples are
truffle. Existing dependencies can be found here.
Written in JS
No hard-coded values. Any variable component should be dynamically fetched. Example: The fee a platform takes shouldn't be hard-coded to the current, say 5%. It should be fetched from the smart contract function and used.
Some Opportunity contributions require more work than building a smart contract. Contributors will be aware of this when undertaking a task. See this example.