As part of a marketing campaign, Coinbase will be distributing USDC to protocols for the purposes of marketing usage on BASE. For transparency, Gauntlet has been approached by the Coinbase team to manage these USDC rewards across Compound’s BASE deployments, given Gauntlet’s existing work with Incentive Optimization with Compound.
Compound currently has two BASE comets - USDC and Ether. At this time, Coinbase is considering distributing $50k/mo ($150k/quarter) of USDC for a quarter, with potential to distribute more depending on the results of the campaign.
One initial step would be to spin up a native USDC comet on BASE. Part of the budget can be reserved to compensate this work, if any members of the community are interested in developing and launching this comet.
Next Steps
We welcome community feedback. Some guiding questions:
If you would like to work on developing and launching the native USDC comet on BASE, please comment in this forum thread.
Which BASE comets would you like to see USDC distributed to?
What are your thoughts on distributing USDC to suppliers vs borrowers?
For the quarter - would you prefer seeing reward distribution frontloaded, backloaded, or distributed evenly throughout the quarter?
Disclaimer
By approving this proposal, you agree that any services provided by Gauntlet shall be governed by the terms of service available at gauntlet.network/tos.
The Reserve Core Team would be interested in launching the native USDC comet in an effort to learn more about the process. We’re interested in additional lending markets for tokens on our platforms with various rewards token mechanisms and this will be a good learning process.
Regarding which Comets should get the rewards: I imagine sending it all to the native USDC comet would most effectively assist with migration from USDbC to USDC.
Because Comets can only have a single reward token out of the box, will having the USDC being distributed natively to this comet limit it from getting COMP in the future? Should there be some kind of wrapper that allows for two incentive token mechanisms to future proof?
Personally, I find distributing to borrowers to be the most effective mechanism. There are plenty of yield opportunities in Base ecosystem for idle USDC. However discounted borrowing is more rare.
No strong view on backloaded/frontloaded/evenly - will look to others for thoughts on this.
I’d be happy to help out with this effort as well. I would encourage Gauntlet to run simulations to try to predict the optimal rewards schema–if that is not possible, I think experimenting with some sort of uneven distribution would be interesting to see given that historically rewards have been fixed in Compound.
I do agree that it is most logical to have these awards fully or heavily weighted on the new native USDC market to help with migration to it.
What are your thoughts on distributing USDC to suppliers vs borrowers?
For the first month or two it may be effective to distribute USDC to suppliers to boost the initial growth phase of the USDC comet. The subsequent month(s) could utilise distribution via borrowers or a weighted mix of suppliers and borrowers leaning on the borrowers, in order to increase the utilisation of the comet once there is sufficient liquidity in the comet.
For the quarter - would you prefer seeing reward distribution frontloaded, backloaded, or distributed evenly throughout the quarter?
An even distribution throughout the quarter would be a sensible approach for users that may be new to the protocol. Seeing the reward implemented into the distribution amount would incentivise them to use the protocol.
I’m in agreement that a new native USDC comet is the best utilisation for this incentive program.
This is a really good and important question raised by @mattimost.
Comet was designed with simplicity in mind, so there are only two speeds: one for supplying and one for borrowing. This approach is effective for systems utilizing a single incentive token, such as COMP. However, it falls short in systems with multiple incentive tokens, since each incentive token would need its own speed.
On the technical side, there are a few different ways to support multiple incentive tokens. The approaches are listed below, but would require upgrades to Comet and introduce more complexity and gassiness to the protocol:
Store a list of speeds to support an unlimited amount of incentive tokens.
Move management of speeds and incentive tracking to the rewards contract. This would require Comet to call into the rewards contract using a hook on every state-changing interaction (e.g. supply, withdraw, transfer) to update the tracking variables.
Given the uncertainty around the length and scale of Coinbase’s marketing campaign, the community might need to eventually switch over the COMP incentives regardless. Taking this into consideration, sticking with the status quo of only distributing COMP in this new market might be the more straightforward and practical approach.