Create process to vet new Opportunity's

Why

A part of decentralizing RAY is to allow the community to take over decision making on what opportunities can be added. New opportunities are required to be added to RAY to match the market and evolve RAY over time. RAY should have simplify this process as much as possible by providing useful tools the community can use initially, at least to start with.

Solution

Guidelines and Patterns

RAY should set a clear document with guidelines and required or suggested patterns for writers and reviewers alike to follow. Some examples:

Opportunities are required to follow a specific interface to properly work with RAY.
Opportunities also follow certain access permissions, and specific security and upgradeability patterns.
Use of suggested compiler versions

Bytecode Verification

As mentioned above, Opportunities are required to implement a specific interface, along with certain access permissions. To make reviewing easier, RAY can verify the bytecode of a proposed Opportunity contains the bytecode for these specific patterns. UMA uses this technique on their Economically Incentivized Oracle design as detailed in their whitepaper:

4.2 Registering Known Contracts

The PfC can be measured if all contracts relying on the oracle are known and accounted for. To support this, the DVM requires all contracts to be constructed using an oracle-approved bytecode template. This template enforces a standard interface that: i) registers each contract upon its initial creation, ii) pays fees to the system as required, and iii) and maintains a publicly accessible function to accurately calculate a contract’s PfC contract.

Templates are added, updated, and removed from the system by vote; token holders have an incentive to only approve templates that have been thoroughly vetted to accurately calculate and report their PfC values.

Contracts that do not use known and approved bytecode templates cannot access the oracle’s data or initiate data requests. Data requests from an un- known contracts are denied, potentially freezing the contract and preventing its settlement. Methods to avoid registration, otherwise known as tax evasion, are discussed in §8.1.

The important take-away is RAY can use an on-chain process that assists in vetting contracts for the community. This would be auto-run upon submission of a new Opportunity proposal against the compiled bytecode, and deliver a report. I don't think this is a full solution - it won't be able to vet things such as contract addresses called (which could be malicious and need manual review), etc. An aside, UMA's use-case doesn't send value to third-parties so they don't have that specific concern.

Manticore Tests

Manticore is a symbolic execution tool for analysis of smart contracts and binaries. Trail of Bits has suggested to incorporate a custom set of tests for properties standard to an Opportunity contract into this process.

Echidna Tests

Echidna is a Haskell program designed for fuzzing/property-based testing of Ethereum smarts contracts. Trail of Bits has suggested to incorporate a custom set of tests for properties standard to an Opportunity contract into this process.

Slither Analysis

Slither is a Solidity static analysis framework. It should be used to run against a proposed Opportunity contract, and display the printed results. Slither doesn't need any specific development of tests, besides potentially customization of the detectors being run. It is very useful to catch difference common security exploits, and provides other useful code-quality suggestions.

Considerations

The individual vetting components should be incorporated into the proposal process for a new Opportunity, with some component displaying the results. Each component should also be open-sourced and allow community members to run them standalone locally.

Additional Info

This is backwards-compatible and only requires new features to be built.

Stakedllc / robo-advisor-yield