veToken Finance contest - Hawkeye's results

Lock more veAsset permanently.

General Information

Platform: Code4rena

Start Date: 26/05/2022

Pot Size: $75,000 USDT

Total HM: 31

Participants: 71

Period: 7 days

Judge: GalloDaSballo

Total Solo HM: 18

Id: 126

League: ETH

veToken Finance

Findings Distribution

Researcher Performance

Rank: 43/71

Findings: 2

Award: $155.44

🌟 Selected for report: 0

🚀 Solo Findings: 0

QA

Check that the lengths of the arrays match

Add a require statement to ensure that both _tokenVote and _weight.length are equal :

VoterProxy.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VoterProxy.sol#L207

Variable types are already their default

There's no need to explicitly assign them :

VoterProxy.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VoterProxy.sol#L227

VeAssetDepositor.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VeAssetDepositor.sol#L29

Booster.sol

Remove the initialisation of the isShutdown since it's already implicitly false

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/Booster.sol#L110

BaseRewardPool.sol

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/BaseRewardPool.sol#L66-L68

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/BaseRewardPool.sol#L70-L72

Unnecessary use of SafeMath at various parts of the codebase since solidity 0.8.0 checks for overflow and underflow et al

One is assured that the divisor is not zero since prior to the calculation totalCliff is assigned a non-zero value :

VeTokenMinter.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VeTokenMinter.sol#L29

Also, totalCliff can be made a constant since it is never modified.

Other instances :

VeAssetDepositor.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VeAssetDepositor.sol#L148

Booster.sol

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/Booster.sol#L518-L523

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/Booster.sol#L528

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/Booster.sol#L607-L608

BaseReward.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/BaseRewardPool.sol#L180

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/BaseRewardPool.sol#L328

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/BaseRewardPool.sol#L339

VE3DRewardPool.sol

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/VE3DRewardPool.sol#L187-L194

Maintain uniformity in how constant variables are written

Use uppercase (and or with underscores to delineate multiple words)

VeTokenMinter.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VeTokenMinter.sol#L15

Booster.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/Booster.sol#L33

BaseRewardPool.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/BaseRewardPool.sol#L73

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/BaseRewardPool.sol#L57

VE3DRewardPool.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VE3DRewardPool.sol#L64

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VE3DRewardPool.sol#L59

Utilise addition /subtraction assignment for better readability

VeAssetDepositor.sol

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/VeAssetDepositor.sol#L148-L151

BaseRewardPool.sol

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/BaseRewardPool.sol#L180-L181

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/BaseRewardPool.sol#L204-L205

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/BaseRewardPool.sol#L222-L223

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/BaseRewardPool.sol#L249-L250

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/BaseRewardPool.sol#L296

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/BaseRewardPool.sol#L303

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/BaseRewardPool.sol#L334

VE3DRewardPool.sol

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/VE3DRewardPool.sol#L219-L221

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/VE3DRewardPool.sol#L243-L246

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/VE3DRewardPool.sol#L261-L262

VE3DRewardPool.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VE3DRewardPool.sol#L377

Users’ rewards can be lowered if totalSupply is inflated unnaturally

When a user stakes an amount, this value gets added to the totalSupply and on withdrawal, the opposite is done.The updateReward modifier does a series of calculation to ascertain the rewards due to a specific account. Notable values updated are rewardPerTokenStored and rewards[account].These are derived as such :

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/BaseRewardPool.sol#L157-L159

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/BaseRewardPool.sol#L166-L169

earned() utilises the returned value of RewardPerToken () to obtain the amount earned but this will be flawed. This is due in part to the fact that in stakeFor (), a malicious user can set address(_for) to the BaseRewardPool which will therefore inflate the supply and result in lowered rewards for the user. One might think that attackers’ main impetus is economical but in some instances, it can be due to malicious intent, ie, just causing inconveniences to a group. Now, it is understandable that users’ reward is reduced on the occasion that the totalSupply increases, but this is only acceptable when it is done in a manner that is consistent with the logic written. If a malicious individual forcibly stakes for the contract in question, the supply never gets reduced as the code dictates(through withdraw() which will never occur since the msg.sender ==address(this)).

To illustrate an example, if at a given moment, users had staked and withdrawn and totalSupply should be 10100 but is 11000, that's a 8.2% reduction in rewards.

Use a require statement to ensure that _for != address(this).

It is understood that the protocol wants to allow for one user to stake on behalf of another. But an event like this (not impossible ) could occur.

#0 - GalloDaSballo

2022-07-07T22:59:09Z

Check that the lengths of the arrays match

Valid Refactor

## Variable types are already their default NC

## Unnecessary use of SafeMath at various parts of the codebase since solidity 0.8.0 checks for overflow and underflow et al Valid R

Maintain uniformity in how constant variables are written

Valid R, nice catch

## Utilise addition /subtraction assignment for better readability I don't understand this finding, cannot give it points, please always add a description to your findings as the context is as important as the link to the code

Users’ rewards can be lowered if totalSupply is inflated unnaturally

Nice finding, valid Low, may bump up if it was found by others

Neat report

1L 2R 1NC

Gas

For small gas savings (little goes a long way)

Within the “if” and “require” statement (which necessitates a condition), for readability and to save gas, remove the explicit use of the Boolean terms.

VoterProxy.sol

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/VoterProxy.sol#L93-L97

https://github.com/code-423n4/2022-05-vetoken/blob/main/contracts/VoterProxy.sol#L110-L113

Booster.sol

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/Booster.sol#L352

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/Booster.sol#L498

For eg, Use if(!x) or(x) {

…..

}

and require(x) or (! x)

Use unchecked block

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VoterProxy.sol#L131

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VeAssetDepositor.sol#L148

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VeTokenMinter.sol#L61

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/Booster.sol#L529

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/BaseRewardPool.sol#L332

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VE3DRewardPool.sol#L375

Check whether a non-zero value exists before accessing the state variable

Below, totalWeight is being decremented before anything is added. This would be waste gas when an address is being added for the first time without any weight :

https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VeTokenMinter.sol#L43

Use an if statement prior to reducing the totalWeight which checks whether the specific asset has any weight.

For eg, if (veAssetWeight[_asset] >0){

……

}

#0 - GalloDaSballo

2022-07-14T02:10:53Z

Effectively just a recommendation to use the unchecked block, without the math nor further details.

Would save less than 500 gas overall

Considering marking invalid against 50+ submissions

#1 - GalloDaSballo

2022-07-26T23:57:29Z

Downgrading to 100 gas saved, but maintaing as valid

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter