wen

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Grand Prize: Stablecoin Defi Innovation

Prize Bounty

1st Place: $50k (25% USDC 75% RSR)

2nd Place: $30k (25% USDC 75% RSR)

3rd Place: $20k (25% USDC 75% RSR)

Challenge Description

Reserve Protocol is a permissionless platform for anyone to build, deploy and govern asset-backed stablecoins with shared DeFi yield and backstop-insurance. We think the future could host a variety of stablecoins each with different “jobs to be done.” Eventually, there could arise a global reserve currency that retains its value indefinitely, is not too volatile, and is outside the fumbling of geo-political and big tech manipulation.

Do you have a view on how the future reserve currency of the world should work with existing defi infrastructure? Or for a cool new thing that can now exist because of the Reserve Protocol? Or something that you expect to be useful to others building or actors in the Reserve ecosystem?

Yes? Then read on!

Want to create a product on the platform? Here’s some things to think about:

At Reserve, we see our new protocol as a platform for people to launch products and even businesses on. So go ahead, build and pitch your product idea. Come up with a clever, catchy brand. Figure out the economics for how this can be sustainable for this system, and maybe even for you as a builder. Build new collateral plugins or leverage existing one. Fork the [Register.app](http://register.app/)[Register.app](https://register.app/) repo and create a custom website and interface to mint it, redeem it, and stake/unstake RSR.

Looking for some inspiration? Here are a few financial products that could be interesting:

1. Decentralized High Yield Savings Account
   Currently most crypto savings products are offered by centralized players, but as the trust in centralized players continues to deteriorate, users will look for decentralized alternatives. There is an opportunity to create the leading on-chain high yield savings product. The creator of this product could create its own on-chain savings product, fully backed by a custom basket of yield generating collateral, and then split the yield between the token holders, insurance providers, and the creator.

2. Branded Loyalty Dollar
   Loyalty dollars are extremely common in our society today, with one of the most recognizable example being the Starbucks loyalty program. The way current loyalty currencies are set up, enabling such a program ends up being a cost for the business, as they need to pay Visa or Mastercard to enable this functionality. By using Reserve to create this branded stablecoin, the business could choose to direct the underlying yield to themselves, in turn resulting in revenue generation for the business.

3. Crypto ETF Product
   The Reserve Protocol makes it easy to bundle together various yield generating collateral assets to create a customized financial product, while utilizing an insurance backstop and fully on-chain transparency to protect users. This functionality is perfect for creating crypto ETF, as the deployer can choose their custom basket of underlying assets, and even using yield generating assets to generate revenue.

When designing your defi product, here are some things to consider:

Should there be a flywheel that builds up treasury tokens for increased voting power in defi? Should it instead fund marketing operations? How much AUM and revenue is needed to do that?

What is the “risk / reward” profile of this token? Is it high yield, high risk? Low yield, low risk? Something else? Do the collateral plugins exist? Do they need to be written?

This is for you to decide and invent. Feel free to leverage any and all content we’ve created for inspiration or just use your team’s own 🧠.

Want to create a tool for the ecosystem? Here’s some things to think about:

There are two main constituents in our ecosystem: 1) governors / stakers and 2) RToken holders. These groups have some similar, but many different needs and potential pain points.

There are also other smaller but no less critical roles in the ecosystem: Gaurdians, Pausers, “economic designers”. Economic designers might need to know more than a typical yield-farmer: other risk factors, how those interplay and overlap with other types of collateral, etc. Pausers and Gaurdians need to be on-call with varying SLAs and be able to make fairly quick decisions based on data that is not at their fingertips.

Submission Requirements

• Links to implementation repositories (github, gitlab, etc). Include in that repository:
  • Project description
  • Links to live project, if applicable (recommended)
  • Demo Video

Judging Criteria for your Creation

Our single overriding criterion for judging submissions is the importance of your project to the overall Reserve ecosystem, as determined by the Reserve judges.

The bigger this thing could make the overall ecosystem, the more excited we will be about it. “Importance” is admittedly vague, but is composed mostly of the following subcriteria:

• Completeness of project.
• Anticipated usefulness of project (i.e. viability for a product).
• Safety of project to all constituents.
• Quality of project (code, design, economics).

Winner Announcement Date

Two weeks following the end of the hackathon (Jan 6, 2023).

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.

Resources

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation### Prize Title

That's a terribly silly value, and also it is a very bad case for our recapitalization algorithm.

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Change "This turns out to work for UTF-8 in general" to something that will not astonish a reader that does not get through the entire comment.

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

See #369

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Change Deployer so that, in deploy, we require-fail if owner = address(this)

(Should resolve HAL-01)

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

• subtask1
• subtask2

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Research & Create Content (Essay or Video)
​

Prize Bounty

• 1st place will receive $3,000 USDC, determined by judges
• 2nd place will receive $2,000 USDC, determined by judges
• 3rd place will receive $1,000 USDC, determined by judges
• All other completed submissions meeting the requirements and ranking in the top 50% by community quadratic voting will receive $500 USDC.
• The most innovative-creative storytelling will receive a discretionary bonus of $1,000 USDC, determined by judges
• Writers and video creators may also be promoted by Reserve Protocol’s social media, blog and newsletter

Challenge Description

The objective of this challenge is to introduce new perspectives and start new conversations about the possibilities related to Reserve Protocol. Using your creative storytelling superpowers and your understanding of The Reserve Protocol, create an essay or video, that meets submission requirements, and explores any one or more of the Ten Hackathon Content Topics.

Submission Requirements

• Twitter handle (if any)
• Telegram handle (if any)
• Discord handle (if any)
• Confirm you have reviewed and walked through setting up a new RToken in the Register Dapp which should acclimate you to how easy future stablecoin issuance can be.
• If you are writing an essay
  • You must be an active researcher/writer in topical areas related to DeFi, TradFi, web3 or web2 technologies and applications.
  • Submissions should be a 600 to 2,500 word original essay that you publish to your own Medium, Substack (or your preferred blog platform) or any web3 publication.
  • The essay must be published in English and available free to read on the public internet.
• If you are creating a video
  • You must be an active researcher/video creator in topical areas related to DeFi, TradFi, web3 or web2 technologies and applications.
  • Channels with larger followings will be given extra considertion, but all submissions are welcome.
  • Submissions should be a 5 to 30 minute original video that you publish to your own YouTube channel.
  • The video must be published in English and available free to view on the public internet.
• Submissions should not speculate on RSR token price in any way

Judging Criteria

There will be a quadratic community voting element to the judging process that will commence shortly after the project submission deadline; this will close at 11:59 PM PST on 12/13/2022. Four judges from Reserve Protocol will also assess each project submission by 01/16/2023.
The following criteria will be used to assess bounty deliverables:

• Impact - If content conclusions are realized, how big might the impact be quantitatively?
• Creative Framing and Point of View - How fun and original are the ideas in the content?
• Technical Depth - Does the content author demonstrate a deep understanding of the subject matter?
• Clarity - well structured, well written or spoken, english grammar
  We reserve the right to not pay out prizes if there are copy-pasta submissions.

Winner Announcement Date

Winners will be announced on 01/16/2023, with payouts to be completed ASAP thereafter.

Resources

• Reserve Discord
• Reserve Protocol Docs
• Introduction to Reserve (30 min video)
• Protocol Launch Event (6 hour video playlist)

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

USDT has a weird requirement that either the allowance being set must be 0 or that the already-set allowance is 0.

We use .safeIncreaseAllowance, which won't work with this logic. We probably need to use safeApprove, and make multiple calls?

This also probably impacts allowances elsewhere. Should scan through rest of code and make sure everywhere we grant allowances we use a robust approach.

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

In _deposit, we have:

        if (fromUnderlying) {
            ASSET.safeTransferFrom(depositor, address(this), amount);
            LENDING_POOL.deposit(address(ASSET), amount, address(this), referralCode);
        } else {
            ATOKEN.safeTransferFrom(depositor, address(this), amount);
        }
        uint256 amountToMint = _dynamicToStaticAmount(amount, rate());
        _mint(recipient, amountToMint);

The safeTransferFrom() and deposit() calls are external interactions, but _mint is an effect, so this violates CEI.

Does the _dynamicToStaticAmount call need to happen after the transferFrom and deposit calls, or can these just be inverted? If they can't just be inverted, does this contract need ReentrancyGuard everywhere?

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

From the Solidified audit, item 17, the < in the following line should be a <=.

Save some gas, avoid length reads and length() calls where possible - especially where the read happens repeatedly in loops. (This might run up against the stack size limit; make good choices, if so.)

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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.

See: https://blog.oasis.app/introducing-oasis-earn/
​

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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation

Prize Title

Collateral Plugin
​

Prize Bounty

• $140k total for this category across all plugins.
• 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, 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.

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.
• 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”
  ​

Additionally, static analysis with 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

​
January 16, 2023; about one month after the end of the hackathon.
​
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.
  ​

Resources

​

• How to write a collateral plugin
• Discord Link
• Github Repo
• Documentation