Prize Title
Collateral Plugin
Prize Bounty
- $33k total for this category across all plugins.
- Award for plugin is $3,000 USD paid 50/50 in USDC and RSR
Challenge Description
Our protocol is a platform that allows anyone to permissionlessly define an asset-backed currency. These currencies can be more creative, and potentially more successful, if there are more building blocks from which to choose.
An important goal of this hackathon is to create as many safe, usable collateral plugins as possible to cover the entirety of possibilities in the defi landscape.
Write a collateral plugin, or collection of plugins, for the defi protocol specified in the title, so that people can use collateral from the protocol as collateral in an RToken.
Submission Requirements
The submission must include:
- Twitter handle (if any)
- Telegram handle (if any)
- Discord handle (if any)
- Source code for your Collateral plugin or plugins
- An open source license
- Documentation (e.g, a README file), describing the following for each plugin:
- What are the collateral token, reference unit, and target unit for this plugin?
- How does one configure and deploy an instance of the plugin?
- If the deployer should plug in price feeds, what units does your plugin expect those price feeds to be stated in?
- Why should the value (reference units per collateral token) decrease only in exceptional circumstances?
- How does the plugin guarantee that its
status()
becomesDISABLED
in those circumstances?
- Tests demonstrating the behaviors checked by our example Collateral plugin test, which we encourage you to use as a starting template for your own testing. Particular behaviors must include:
- Deployment
- Issuance, appreciation, and redemption of an RToken with this Collateral in its basket
- Claiming rewards (or, if no rewards are available for this token, tests demonstrating that the claim-reward functions do nothing and don't revert)
- Correct behavior for
price()
when any price sources return invalid values - Correctly changing
status()
whenever that's needed in order to flag sudden or impending default
Acceptance Criteria
Each Collateral plugin must:
- Fully implement the ICollateral interface
- Satisfy the correctness properties given in the Collateral plugin-writing howto
- Be fully permissionless once deployed
- Be documented with cogent explanations of its economics.
- Be deployable with USD as its Unit of Account
- Not be prone to relatively simple economic attacks or cough cough "highly profitable trading strategies"
Judging Criteria
If there are multiple submissions in this category that meet all acceptance criteria, we will decide the grant winner based on the following judgments:
- How clear, clean, and solidly-engineered is the implementation?
- How gas-efficient is the implementation? The Reserve protocol makes heavy use of the
refresh()
,price()
, andstatus()
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.
Winner Announcement Date
Approximately May 15, 2023; one month after the deadline.
To accept the prize, winners will need to complete and sign one of the following on Docusign:
- W-9 (for US citizen/resident or company)
- W-8BEN (for non-US person)
- W-8BEN-E (for non-US company/entity)
We are quite secure in how we collect KYC information and will never share PII with anyone outside of necessary tax authorities.