Summary
Woof Software would like to build a solution that allows to incentivize lenders and borrowers with more than one token at the same time.
Motivation
Currently, Compound markets are incentivized only with COMP. More and more ecosystems and projects are willing to incentivize Comets with their native tokens (e.g. Aribtrum and Optimism). However, Compound lacks the functionality of rewards distribution in more than one token at the same time.
Thus, Woof Software proposes a wrapping solution described in detail below.
Requirements
- Ability to incentivize Comet with 2 or more tokens at the same time.
- Seamless transition: users shall not perform any actions to start receiving rewards in additional tokens.
- Do not upgrade existing smart contracts.
- Ability to relaunch incentivization program for the same token (for example: distribute 100K USDC in Q1 2024, then stop distribution and redistribute another 200K USDC in Q3 2024).
- Reusable code: the solution shall be reusable for future Comets and applicable to existing Comets.
Challenge
Current CometRewards.sol allows only one incentivization token per Comet. It prevents the utilization of any other rewards, since it cannot be reset and the coefficient constant cannot be changed.
Comet.sol stores Accrued Value (baseTrackingAccured) and constantly increases it. CometRewards.sol distributes rewards based on the Accrued Value of the user. The current approach has one accrued value and no additional accrued values could be added without changing Comet.sol which is not allowed by requirement 3. The accrued value is an infinite line, that starts when the user performs supply and never ends.
Incentivization campaign with new token(from third parties like Arbitrum) will not last forever, but will start and end periodically. Which means, that for the correct calculation of the multiple rewards for every user, the multiple rewards flow should track the accrued value of every user at the start and at the end of each incentivization program for each token.
Features
CometRewardsV2 contract:
- Will utilize CometRewards contract, as it already contains some token rewards.
- Will get the existing reward info from the CometReward during the setup.
- Will have the same interface as CometReward + new functions for the CometRewardsV2 functionality.
- Will redirect any calls connected to the existing reward to CometRewards. It will redirect calls connected to the existing reward in the rewardConfig mapping.
- Will store Merkle tree root hash for every incentivization program start and end.
- Will verify Merkle tree proofs.
- Will contain functionality for multiple rewards - new storage structure and new functions to store several reward tokens (except the one already set in BaseRewards).
- From this moment all new rewards will be added to the CometRewardsV2.sol, while CometRewards.sol will work for the compatibility.
Back-end:
- Generate Merkle tree hash from all users using OpenZeppeling/merkle-tree lib for the specific comet at the moment of generation of new rewards campaign.
- Call CometRewards to start/finish a new incentivization program. Or the admin can make it manually.
- Update the Merkle tree hourly/daily (should decide) to track new users who appeared in the protocol during the new incentivization program.
- Export list of proofs for Merkle tree hash.
Use cases
Start/end new incentivization program
The back-end will generate a Merkle tree hash from all the users in particular Comet and store it into CometRewardsV2 on the admin call. The back-end can also generate a Merkle tree and return it. Admin could set up the hash manually. We assume that start and end point hash will be generated and settled via governance proposal pipeline in every incentivization campaign
New users appear during the incentivization program
In case when the user was not a participant in Comet before the campaign started, the accrued value will be received directly from SC. If the user’s address was not in the Merkle tree, but it exist in Comet, the user appeared during the campaign.
Note: CometRewardsV2 will call CometRewards only for legacy rewards (publicly available in the config). All new rewards will be processed directly via the new CometRewardsV2.sol contract.
Flows comparison
Old
for front-end
New
for front-end
Front-end Integration
Flows of integration CometRewardsV2 in existing frontends:
Read flow
- dApp calls the backend and gets proof for a particular campaign for a particular user
- dApps reads the CometRewardV2 with proof parameter
Write flow
- dApp calls the backend and gets proof for a particular campaign for a particular user
- dApps calls the write method the CometReward with proof parameter
- user sign the transaction
To make the proof system maximum clear, we are going to upload this information into Github.
Library
Additionally, we are going to create TypeScript library that is going help to integrate new functionality into existing dApps. Library will help with generation of proofs.
Milestones
M1: Smart contract development
- Define the new functions and storage structure for the new contract.
- Add integration of the existing contract - for the re-calls for legacy rewards.
- Keep the existing interface for compatibility.
- Implement new functions to support multiple rewards with independent settings - while keeping the original config structure as a reference.
- Implement new admin methods, to store Merkle tree hash into CometRewardsV2.sol.
- Provide 100% unit test coverage.
- Provide integration fork tests checking the support of the legacy rewards.
- Provide a testing stage with testnet deployment and end-to-end testing scenarios.
- Deployment scripts.
- Documentation update.
M2: Back-end development
- Development of collecting user data service.
- Development of Merkle trees generation service.
- Development of functionality to start a new campaign.
- Development of functionality for updating Merkle root.
- Development of functionality for setting up final Merkle root and stop campaign.
- Development of call transaction system.
- Back-end and SC integration.
- Integration fixes.
- Unit test coverage.
- End-to-end testing.
- Create documentation.
M3: Post audit fixes
- Post-audit fixes and production launch.
M4: Production deployment
- Mainnet deployment
- Back-end production deployment
Deliverables
- Smart contracts codebase on GitHub
- Back-end codebase on GitHub
- Post-audit fixes
- Smart contracts deployment
- Back-end deployment
- Smart contract connection assistance
- Documentation update
Out of scope
Compound front-end and back-end are closed-source. Thus, we won’t be able to connect our solution fully to Compound front-end. We assume that our documentation and consultations will be useful for Compound team and teams like DeFi Saver. Alternatively, we can complete the front-end and back-end as soon as we get such access. We can accomplish this within the scope of the current proposal, or as a separate proposal, depending on the complexity of the existing Compound codebase. Audit is not included to the scope.