Constants should be defined rather than using magic numbers
There are several occurrences of literal values with unexplained meaning .Literal values in the codebase without an explained meaning make the code harder to read, understand and maintain, thus hindering the experience of developers, auditors and external contributors alike.
Developers should define a constant variable for every magic value used , giving it a clear and self-explanatory name.
File: /contracts/WardenPledge.sol
//@audit: **balacne** instead of **balance*
292: * @param targetVotes Maximum taget of votes to have (own balacne + delegation) for the receiver
File: /contracts/WardenPledge.sol
//@audit: **ot** instead of **to**
295: * @param maxTotalRewardAmount Maximum total reward amount allowed ot be pulled by this contract
296: * @param maxFeeAmount Maximum feeamount allowed ot be pulled by this contract
365: * @param maxTotalRewardAmount Maximum added total reward amount allowed ot be pulled by this contract
366: * @param maxFeeAmount Maximum fee amount allowed ot be pulled by this contract
411: * @param maxTotalRewardAmount Maximum added total reward amount allowed ot be pulled by this contract
412: * @param maxFeeAmount Maximum fee amount allowed ot be pulled by this contract
File: /contracts/WardenPledge.sol
//@audit: **Minmum** instead of **Minimum**
523: * @param minRewardPerSecond Minmum amount of reward per vote per second for the token
File: /contracts/WardenPledge.sol
//@audit: **Minmum** instead of **Minimum**
539: * @param minRewardsPerSecond Minmum amount of reward per vote per second for each token in the list
File: /contracts/WardenPledge.sol
//@audit: **Minmum** instead of **Minimum**
558: * @param minRewardPerSecond Minmum amount of reward per vote per second for the token
File: /contracts/WardenPledge.sol
//@audit: **Minmum** instead of **Minimum**
568: * @param minRewardPerSecond Minmum amount of reward per vote per second for the token
File: /contracts/WardenPledge.sol
//@audit: Platfrom instead of Platform
621: * @notice Updates the Platfrom fees BPS ratio
622: * @dev Updates the Platfrom fees BPS ratio
File: /contracts/WardenPledge.sol
//@audit: Missing @param _chestAddress
125: /**
126: * @dev Creates the contract, set the given base parameters
127: * @param _votingEscrow address of the voting token to delegate
128: * @param _delegationBoost address of the contract handling delegation
129: * @param _minTargetVotes min amount of veToken to target in a Pledge
130: */
131: constructor(
132: address _votingEscrow,
133: address _delegationBoost,
134: address _chestAddress,
135: uint256 _minTargetVotes
136: ) {
Event is missing indexed fields
Index event fields make the field more quickly accessible to off-chain tools that parse events. However, note that each index field costs extra gas during emission, so it's not necessarily best to index the maximum allowed per event (three fields). Each event should use three indexed fields if there are three or more fields, and gas usage is not particularly of concern for the events in question. If there are fewer than three fields, all of the fields should be indexed.
Some constructs deviate from this recommended best-practice: External/public functions are mixed with internal/private ones
Ordering helps readers identify which functions they can call and to find the constructor and fallback definitions easier.
Functions should be grouped according to their visibility and ordered:-
constructor
receive function (if exists)
fallback function (if exists)
external
public
internal
private
Our code does not seem to follow this recommendations . We have public functions declared before external functions
QA
Missing checks for address(0x0) when assigning values to address state variables
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L137-L140
Constants should be defined rather than using magic numbers
There are several occurrences of literal values with unexplained meaning .Literal values in the codebase without an explained meaning make the code harder to read, understand and maintain, thus hindering the experience of developers, auditors and external contributors alike.
Developers should define a constant variable for every magic value used , giving it a clear and self-explanatory name.
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L626
Typos - see audit tags
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L292
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L365
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L523
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L539
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L558
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L568
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L621-L622
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L650
Natspec is incomplete
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L125-L136
Event is missing
indexed
fieldsIndex event fields make the field more quickly accessible to off-chain tools that parse events. However, note that each index field costs extra gas during emission, so it's not necessarily best to index the maximum allowed per event (three fields). Each
event
should use threeindexed
fields if there are three or more fields, and gas usage is not particularly of concern for the events in question. If there are fewer than three fields, all of the fields should be indexed.https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L85-L92
The nonReentrant modifier should occur before all other modifiers
This is a best-practice to protect against reentrancy in other modifiers
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L195
Code Structure Deviates From Best-Practice
Order of Functions
Some constructs deviate from this recommended best-practice: External/public functions are mixed with internal/private ones Ordering helps readers identify which functions they can call and to find the constructor and fallback definitions easier.
Functions should be grouped according to their visibility and ordered:-
Our code does not seem to follow this recommendations . We have public functions declared before external functions
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L153
Internal functions are also mixed with external functions rather than be ordered accordingly
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L222
Recommendation: Consider adopting recommended best-practice for code structure and layout. See Documentation