Bug found in the AAVE-forked smart contracts used for rewards emissions in Seamless Protocol
Bug involves the use of loew precision factor for rewards calculation, this impacts all markets and reward tokens but is most notable on markets with fewer asset decimals, notably USDC (6 decimals)
Proposed fix requires smart contract upgrade via on-chain voting
Fix to be proposed as a PR contribution back to the aave-v3-periphery repo
Community discussion open on potentially boosting rewards for USDC market next month
Context & Motivation
The Seamless DAO and Community have enabled rewards since the DAO was launched in December. Since then, multiple new markets and new kinds of reward tokens have been enabled for the protocol.
Recently, Native USDC rewards have been issued in an ongoing grant provided by Gauntlet Network. Community members, users and contributors have noticed slight discrepancies in reward emission rates between front-end calculations and smart contract calculations.
Upon further investigation, a bug was discovered affecting reward accrual precision, especially for reward tokens denominated with fewer decimals (USDC has 6 decimals). A fix has been identified and proposed below. This is not a unique issue to Seamless, as it affects any protocols who have forked the RewardsController smart contracts from AAVE, and so the fix will be contributed back to AAVE to benefit other users of the open source software.
If this proposal passes, this should no longer be an issue for future rewards on the Seamless protocol platform.
The community must vote to upgrade the current implementation to use this new rewards controller implementation. This can be done by calling the setAddressAsProxy method on the PoolAddressesProvider contract.
Next Steps
If there is sufficient support here is Discourse, I propose we move quickly to an onchain vote since this would fix a bug that is currently impacting users.
Additionally, either in this discussion or a separate thread, the community can consider discussing a boost to the USDC market rewards in the following month to account for this initial accounting error.
The fix makes sense to me fwiw and really appreciate the quick work of the team to put this together. That said, I think that the right thing to do wrt rewards is to actually do a backward-looking drop to users who supplied USDC during the program. I know this is a bit more involved (though should not be too difficult), but I think it’s the fairer solution, given that users using the UI were supplying liquidity with a different advertised rate (particularly for USDC). To me, a “boost” to future USDC rewards is a separate matter that the community can consider after considering the backward-looking rewards for users who missed out on the USDC rewards but who have already provided liquidity to the protocol
I am in full support of this to be patched as soon as possible. For the sake of speed, it is my opinion to push forward the fix as is in order to simplify the changes. I believe it’s not too big of a deal to boost the USDC rewards to make up for it, since the majority of boosted rewards were emitted properly. Keeping things simpler instead of additional complexities would be my vote, since the leftover amounts shouldn’t be that significant.
For the avoidance of doubt, I’m 100% in agreement that the contract be upgraded ASAP to solve the rounding off problem. I’d separate out the issue of compensating users who have already provided liquidity what they’re owed to be a separate vote for the DAO (similar to go-forward rewards). Definitely don’t want anything to hold up this fix
Definitely support fast tracking this - and agree maybe a separate discussion can occur on the best way to execute a reward top up. It will be fairly complicated to do this calculation - if someone in the community has that expertise to write a transparent query on Dune or similar that would help.
But yes for now advocate for fast tracking the bug fix
Yes in favor of fast tracking this. Generally in terms of fixes and bugs fast tracking the fix is the right approach and in this instance applying the fix quickly is the best course of action.
Thank you for highlighting the problem @wes_fred! I fully support it.
As for the fast track @richyRNG it was suspended a couple of months ago, so I suppose that a way out could be to move it to the vote immediately after 5 days discussion period pass (since there will definitely be no amendments). Additionally, as onchain voting requires
As a follow up to the above, i believe the bug fix proposal was approved and executed onchain with tremendous support, tally page here.
Now that the bug fix is completed, it seems like a good time to circle back on 986box’s suggestion and concerns above.
A few thoughts from my end (these are personal opinions and don’t necessarily represent the opinions of any larger group):
After getting some estimates from technical contributors, it appears a solution to back-calculate rewards could range from hours to days/weeks of work depending on the level of fidelity that we would wish to achieve on this exercise. (i.e. rough estimates are easier to calculate than exactness - the more exact, the more it would require smart contract logic to be represented through dune queries - something dune is not necessarily well built to do)
Core contributors are working on a variety of high-priority and high pace initiatives (hopefully the communtiy has observed the high rate of proposal creation and updates - with more to come) - as such it may be difficult to balance a very precise calc exercise with parallel efforts (would require slowdown across board on other initiatives)
Two potential solutions (that optimize for bandwidth but also impact) would be:
1. Simply increase rewards emissions (maybe both on USDC and esSEAM sides) on the impacted USDC market for x period of time into the future
2. Have the SCGP provide a bounty, maybe something like 4% of the impacted rewards, for a community member who has bandwidth and Dune expertise to write a public query “solving” this issue. The best submission would get the bounty and be leveraged to do an airdrop of rewards. (<70k USDC rewards was impacted, so for example this SCGP bounty could be something like 4% or 2,800 USDC) - this would also allow a “bake off” to see if folks from the community can compete on who can create a more accurate query
Given it would be beneficial to the community to come to a timely conclusion on this matter, my suggestion is to tee-up a (non-binding) snapshot vote for SEAM/esSEAM holders to express their opinions on the matter. If there is no feedback to the above I can volunteer myself to start a snapshot vote in the next 12 hours or so to get a temparate check across a few options:
(Temporarily) increase rewards emissions on the impacted USDC market
SCGP backed bounty for community queries on calc + airdrop
Abstain / None of the above / Other
Note: the above would be a temperature check since the SCGP committee has it’s own mandate on how to utilize funds. Additionaly, the bandwidth and resources required for a dune query depend on the desired precision of the query. Other feedback or options to be included in the poll are welcomed for discussion.