Platform: Code4rena
Start Date: 11/05/2022
Pot Size: $150,000 USDC
Total HM: 23
Participants: 93
Period: 14 days
Judge: LSDan
Total Solo HM: 18
Id: 123
League: ETH
Rank: 12/93
Findings: 2
Award: $5,338.63
🌟 Selected for report: 1
🚀 Solo Findings: 1
🌟 Selected for report: Kumpa
5188.7624 USDC - $5,188.76
Without restriction on the type of address that lock the token, a bad actor could lock the token through the smart contract. Doing so enable him to make the lockedToken becomes liquidate by tokenize his smart contract which defeat the purpose of the lockedToken that is supposed to be untransferable. Moreover, a bad actor could attract people to lock the token through his smart contract instead of directly locking with AuraLocker by injecting better short-term incentives to his wrapper token. This enable the bad actor to accumulate voting power that could dictate the future of the protocol.
-A bad actor creates a smart contract
-A contract calls lock in AuraLocker and locks the token
-A bad actor tokenizes the contract
-A bad actor attracts people to lock the token through his smart contract by offering a wrapper tokens or additional incentives like high apy etc.
-A bad actor dictates the smart contract to delegate its vote to his preferred address.
It would be best to check whether the locker is the smart contract or the wallet and, if the protocol wants the smart contract to be the locker, it can implement the whitelist or blacklist.
#0 - 0xMaharishi
2022-05-28T12:27:23Z
Given no user funds are at risk I don't think this is a super high risk, but i do agree that there is a governance risk there and it's something to be concerned about if/when there is no multisig intermediary between aura voters and execution. With that being said, I think a good solution would be to have a blacklist that the owner can set to block non-eoa's from making any further locks: bool canLock = isEOA(address) || !isBlacklisted(address)
#1 - 0xMaharishi
2022-05-30T21:03:02Z
#2 - dmvt
2022-06-20T16:25:39Z
I'll leave this in place as a medium risk because there are external factors involved. High risk is too severe.
🌟 Selected for report: IllIllI
Also found by: 0x1f8b, 0x4non, 0xNazgul, 0xNineDec, 0xf15ers, 0xkatana, 242, AlleyCat, BouSalman, BowTiedWardens, CertoraInc, Chom, Cityscape, FSchmoede, Funen, GimelSec, Hawkeye, JC, JDeryl, Kaiziron, Kthere, Kumpa, MaratCerby, MiloTruck, Nethermind, NoamYakov, PPrieditis, QuantumBrief, Rolezn, Ruhum, SmartSek, SooYa, Tadashi, TerrierLover, WatchPug, Waze, _Adam, asutorufos, berndartmueller, bobirichman, c3phas, catchup, cccz, ch13fd357r0y3r, cryptphi, csanuragjain, cthulhu_cult, defsec, delfin454000, ellahi, fatherOfBlocks, hansfriese, hubble, hyh, jayjonah8, joestakey, kenta, kenzo, kirk-baird, mics, oyc_109, p_crypt0, reassor, robee, sach1r0, samruna, sashik_eth, sikorico, simon135, sorrynotsorry, sseefried, tintin, unforgiven, z3s, zmj
149.8665 USDC - $149.87
The penalty calculation, when a user does not lock his reward, encounters precision loss when reward cannot be completely divisible. This could lower the amount of penalty that the protocal expects to receive. The severity of the issue increases when a user getReward when his reward is small. And if a bulf of users decide to do the same thing, the protocal could potentially miss a huge penalty.
-A user getReward when his reward is at around 99
-The penalty will be 198/10 or 19.8 but, since there is no float point in solidity, the penalty will be rounded down to 19
-The penalty's percentage will be at around 19.1% instead of 20% as stated
Since the severity will decline as accumulated reward goes up, it would be best to set the minimum reward that a user must first accumulates before getReward
#0 - 0xMaharishi
2022-05-28T12:28:18Z
1 base unit (i.e. 0.00000000000000001 of a token) is an acceptable rounding error
#1 - dmvt
2022-06-22T15:46:47Z
I'm lowering this to QA. It is technically true, but the loss is insignificant.