Collateral Plugin - Llama Airforce - uCRV / uFXS / uCVX | $3,000
### Prize Title
### Prize Bounty
- $140k total for [this category across all plugins](https://docs.google.com/spreadsheets/d/1zzO9BYE-xYe4JOdrarrNAlUgyaG6QFc3tb9PIFnb3VA/).
- Amount for this particular plugin is in the title. You have a choice of RSR, USDC, or DAI.
- We have listed $120k of bounties in this category and will be awarding the extra $20k to the best submissions across the category, as determined by the judging criteria.
### 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. We sourced this list from Defillama and our research.
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 submitted repository 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()` becomes `DISABLED` in those circumstances?
- Tests demonstrating the behaviors checked by our [example Collateral plugin test][example-test], which we encourage you to use as a starting template for your own testing. Particular behaviors must include:
- 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.
*Edit: A video for this submission is no longer required; it has been replaced by the testing requirement.*
*Note: In the Additional Info field, specify the hash of the git commit that you want considered for this bounty. This will help us be sure of the order in which plugin submissions were completed.*
### Acceptance Criteria
Each Collateral plugin must:
- Fully implement the [ICollateral interface][icoll].
- Satisfy the correctness properties given in the [Collateral plugin-writing howto](https://github.com/reserve-protocol/protocol/blob/master/docs/collateral.md).
- Be fully permissionless once deployed.
- Be documented with cogent explanations of its economics.
- Be deployable with USD as its [Unit of Account](https://reserve.org/protocol/monetary_units_baskets/#monetary-units).
- Not be prone to relatively simple economic attacks or *cough cough* “highly profitable trading strategies”
Additionally, static analysis with [slither](https://github.com/crytic/slither) over your whole codebase should not yield avoidable issues of moderate or greater severity. If some slither report is not sensibly avoidable, your documentation should note that, and explain either how we can see that the report is spurious, or that the problem it’s reporting is unavoidable in this circumstance.
### 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()`, 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.
### Winner Announcement Date
Two weeks following the end of the hackathon (December 22, 2022).
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.
- [How to write a collateral plugin](https://github.com/reserve-protocol/protocol/blob/master/docs/collateral.md)
- [Discord Link](https://discord.gg/jY9dGHKc)
- [Github Repo](https://github.com/reserve-protocol/protocol)