Golom contest - 0xackermann's results

An NFT marketplace that offers the lowest industry fee, a publicly available order-book along with analytical tools.

General Information

Platform: Code4rena

Start Date: 26/07/2022

Pot Size: $75,000 USDC

Total HM: 29

Participants: 179

Period: 6 days

Judge: LSDan

Total Solo HM: 6

Id: 148

League: ETH

Golom

Findings Distribution

Researcher Performance

Rank: 139/179

Findings: 1

Award: $35.17

馃専 Selected for report: 0

馃殌 Solo Findings: 0

Ensure Minimum Lock Duration is not greater than Maximum Lock Duration

Code Link: 2022-07-golom/GolomAirdrop.sol at main 路 code-423n4/2022-07-golom (github.com)

Impact / Proof of concept

The impact is that it may affect the wrong calculation in calculating the rewards for users to claim their airdrops. The minimum lock duration should not be greater than the maximum lock duration. From the function changeLockDuration of GolomAirdrop.sol#L180-L183, we should ensure that the minimum duration is less than or equal to the maximum lock duration before assigning them to the variables. This helps to ensure the owner of the contract does not put wrongly minimum and maximum lock duration values.

How to fix

Add require(min <= max, 'Owner: Minimum lock duration is greater than maximum lock duration'); before assigning values to the variables.


Total Supply of Reward Token Should Be Positive Value

Code Link: 2022-07-golom/RewardDistributor.sol at main 路 code-423n4/2022-07-golom (github.com)

Impact / Proof of concept

There might be cases where the total supply of reward token is zero, this makes the function addFee of RewardDistributor.sol#L98-L138 to divide zero while calculating tokenToEmit and stakerReward.

How to fix

We should add require(rewardToken.totalSupply() > 0, 'total Supply of reward token is 0'); on line 104 to avoid the calculation of dividing zero.


Ensure Total Epoch Fee is Always Positive

Code Link: 2022-07-golom/RewardDistributor.sol at main 路 code-423n4/2022-07-golom (github.com)

Impact/Proof of concept

If the total epoch fee is not positive, this will impact the calculation of traderClaim, exchangeClaim, traderRewards and exchangeRewards as all of these involve the calculation of diving total epoch fee. We would not like to have dividing zero occurs.

How to fix

From RedeemDistributor#L126, we must ensure that there is ETH balance in contract at epoch 0. Besides, we also need to ensure the parameter fee of addFee function is positive as fee is the only variable to update for total epoch fee of the current epoch which is at RedeemDistributor#L136. Add require for the address(this).balance and fee to be positive should be able to solve this issue.

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