Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardcoding numbers is error-prone #203

Open
code423n4 opened this issue Sep 22, 2021 · 1 comment
Open

Hardcoding numbers is error-prone #203

code423n4 opened this issue Sep 22, 2021 · 1 comment
Labels
0 (Non-critical) Code style, clarity, syntax, versioning, off-chain monitoring (events etc), exclude gas optimisation bug Warden finding sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")

Comments

@code423n4
Copy link
Contributor

Handle

pauliax

Vulnerability details

Impact

Hardcoding numbers that depend on other variables is error-prone, e.g.
require(newOwnerSplit <= 2e17); // 20%
You must not forget to update this if you decide to change the BASE value.

Recommended Mitigation Steps

Better define a separate constant that directly depends on the BASE, e.g.:
uint256 private constant MAX_OWNER_SPLIT = BASE / 5; // 20%
require(newOwnerSplit <= MAX_OWNER_SPLIT);

@code423n4 code423n4 added 0 (Non-critical) Code style, clarity, syntax, versioning, off-chain monitoring (events etc), exclude gas optimisation bug Warden finding labels Sep 22, 2021
code423n4 added a commit that referenced this issue Sep 22, 2021
@frank-beard frank-beard added the sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") label Nov 6, 2021
@GalloDaSballo
Copy link
Collaborator

100% agree with the warden, Magic Values can cause big issues, recently I've seen a UniV2 fork forget a 0 in 10_000 (because they weren't using CONSTANTS) and get completely rekt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0 (Non-critical) Code style, clarity, syntax, versioning, off-chain monitoring (events etc), exclude gas optimisation bug Warden finding sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Projects
None yet
Development

No branches or pull requests

3 participants