Platform: Code4rena
Start Date: 23/05/2022
Pot Size: $75,000 USDC
Total HM: 23
Participants: 75
Period: 7 days
Judge: GalloDaSballo
Total Solo HM: 13
Id: 130
League: ETH
Rank: 12/75
Findings: 3
Award: $2,118.51
🌟 Selected for report: 1
🚀 Solo Findings: 1
🌟 Selected for report: cccz
1941.948 USDC - $1,941.95
setProposalNumerator and setTeam functions of the VeloGovernor contract can only be called by team without allowing governance to call.
None
Allow governance to call setProposalNumerator and setTeam functions
#0 - GalloDaSballo
2022-06-26T21:23:51Z
I really dislike how the finding is phrased as the variable team doesn't mean much by itself.
That said the finding has validity in that the Governance Contract should be calling to change the proposalNumerator so a check should probably be for address(this)
#1 - WillSaveTime
2023-04-20T12:48:00Z
I don't understand what is proposalNumerator. Can you explain more details?
🌟 Selected for report: 0xf15ers
Also found by: 0x52, Ruhum, WatchPug, berndartmueller, cccz, horsefacts, hyh, minhquanym, pauliax
The notifyRewardAmount function of the Bribe contract can be called by anyone, and can insert any token when rewards.length < MAX_REWARD_TOKENS. An attacker can insert a malicious token, the token's transferFrom function executes normally, but the transfer function reverts. Since the deliverBribes function of the Gauge contract will call the transfer function of all tokens in turn, this will cause the normal rewards in the Bribe contract to be locked in the contract.
https://github.com/code-423n4/2022-05-velodrome/blob/7fda97c570b758bbfa7dd6724a336c43d4041740/contracts/contracts/Bribe.sol#L41-L60 https://github.com/code-423n4/2022-05-velodrome/blob/7fda97c570b758bbfa7dd6724a336c43d4041740/contracts/contracts/Bribe.sol#L83-L90 https://github.com/code-423n4/2022-05-velodrome/blob/7fda97c570b758bbfa7dd6724a336c43d4041740/contracts/contracts/Gauge.sol#L172-L186
None
Added whitelist verification to tokens added by notifyRewardAmount function in Bribe contract
#0 - pooltypes
2022-06-13T15:52:50Z
Duplicate of #182
#1 - GalloDaSballo
2022-07-01T01:46:20Z
Dup of #182
🌟 Selected for report: IllIllI
Also found by: 0x1f8b, 0x52, 0xNazgul, 0xNineDec, AlleyCat, BouSalman, CertoraInc, Chom, Dravee, Funen, GimelSec, Hawkeye, MaratCerby, Nethermind, Picodes, RoiEvenHaim, SooYa, TerrierLover, WatchPug, _Adam, asutorufos, berndartmueller, c3phas, catchup, cccz, cryptphi, csanuragjain, delfin454000, djxploit, fatherOfBlocks, gzeon, hake, hansfriese, horsefacts, hyh, jayjonah8, minhquanym, oyc_109, p_crypt0, pauliax, robee, rotcivegaf, sach1r0, sashik_eth, simon135, sorrynotsorry, teddav, unforgiven, xiaoming90
101.3245 USDC - $101.32
In the _vote function, _poolWeight is calculated according to the following formula
_poolWeight = _weights[i] * _weight / _totalVoteWeight;
But rounding causes voters to lose weight.
Consider the following scenario: _weight = 10 _weights = [1,2,3] so _poolWeight is 1, 3, 5 respectively This will cause the voter to lose 1 weight
None
Consider voting the remaining weights when voting on the last pool
#0 - GalloDaSballo
2022-06-26T21:11:10Z
I believe the finding has some validity, in that indeed calling with small units can cause rounding errors, however the caller could also call with 1e18 precision.
Because of this I believe QA to be more appropriate
#1 - GalloDaSballo
2022-07-02T00:27:45Z
Marking as Low