Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Judging Criteria #8

Open
6 tasks
anastasiabusygina opened this issue Nov 13, 2022 · 1 comment
Open
6 tasks

Judging Criteria #8

anastasiabusygina opened this issue Nov 13, 2022 · 1 comment

Comments

@anastasiabusygina
Copy link
Member

​If there are multiple submissions in this category that meet all acceptance criteria, we will decide the grant winner based on the following judgments:​

  • The implementation is clear, clean, and solidly-engineered
  • How clear, clean, and solidly-engineered is the implementation?
  • The implementation is gas-efficient.
  • How gas-efficient is the implementation? The Reserve protocol makes heavy use of the refresh(), price(), and status() functions, for users’ sake these need to be especially efficient.
  • How easy is it to reason about what these Collateral plugins do?
  • Do we see technical or economic vulnerabilities in these plugins, and how severe are they?
  • Could these plugins be deployed and used on mainnet immediately, or are they missing prerequisites? For instance, do they require price feeds or trading mechanisms that don’t already exist?
  • How large is the range of significant, natural use cases covered by this set of Collateral plugins? Example of this further described below.​

For an illustration of “range of use cases,” when we implemented our Compound collateral plugins, we thought it important to implement three different kinds of Collateral contracts to capture three substantially different kinds of Compound-wrapped tokens:

  • Tokens where the underlying token is a fiatcoin, and the Collateral plugin should default if the underlying token’s price diverges from the target unit’s price. For instance, cUSDC is redeemable for USDC, and the plugin should default if USDC loses its peg to USD.
  • Tokens where the underlying token is pegged to some unstable asset, and the Collateral plugin should default if the underlying token’s price diverges from the target unit’s price. For instance, cWBTC has underlying token WBTC, and the plugin should default if WBTC loses its peg to BTC.
  • Tokens where the underlying token simply is the target asset, and requires no default check. For instance, cETH has underlying token ETH, and so the underlying token itself needs no default check.
    ​If we had implemented only one or two of these, the range of use cases would be notably smaller. The degree to which each Collateral plugin is configurable will also contribute to the range of use cases covered by the set of plugins. Again, we expect the already-existing Collateral plugins should be a good guide here.​
@anastasiabusygina
Copy link
Member Author

В readme

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant