Open code423n4 opened 2 years ago
I have upgraded the following finding as Medium risk, so I have created a separate issue (https://github.com/code-423n4/2022-03-volt-findings/issues/130) for it for judging and awarding purposes:
Besides the first issue (upgraded to Medium), I find the risk level of other issues suitable.
Low Risk Issues
Division by zero
calculateDeviationThresholdBasisPoints()
was important enough to be in a separate library rather than being just a normal function of another contract so it should be generic enough for other contracts to use it. If the input argumenta
is zero then the function performs a division by zero and will throw an exception. If this behavior is what is wanted, the NatSpec should make this explicit and arevert()
should be added with an appropriate error message.Unsafe calls to
decimals()
decimals()
was optional in the original ERC20 specification, so there are functions that do not implement it. It's not safe to cast arbitrary token addresses in order to call this function. IfIERC20Metadata
is to be relied on, that should be the variable type of the token variable, rather than it beingaddress
, so the compiler can verify that types correctly match, rather than this being a runtime failure. See this prior instance of this issue which was marked as Low risk. Do this to resolve the issue.Cross-chain replay attack
See this issue from a prior contest for details.
File: contracts/volt/Volt.sol (lines 11-36)
Missing checks for
address(0x0)
when assigning values toaddress
state variablesExtrapolation, not interpolation
The NatSpec says that the code is doing an interpolation, which is finding a value between two endpoints. The code however is doing extrapolation - projecting a future value based on prior values. From the judging criteria guidelines:
Low: Assets are not at risk. State handling, function incorrect as to spec, issues with comments.
Modifier does not always execute
_;
It is dangerous to have
_;
only be executed from some code paths. If the function using it hasreturn
values, they'll remain uninitialized, which can lead to unexpected behaviorNon-critical Issues
Fei is not the only underlying token
The variable name
amountFeiToTransfer
is misleading because it is not only Fei. It should be named something likeamountStablecoinToTransfer
Inconsistent CPI/CPI-U terminology
The code refers to both CPI and CPI-U in various places, using CPI-U for calls to
getMonthlyAPR()
. It should consistently use one or the other in all placesAPR is Annual Percentage Rate
CPI is an index not an interest rate and is monthly not annual, so using 'APR' is misleading. Rename to something like
getMonthOverMonthPercentageChange()
public
functions not called by the contract should be declaredexternal
insteadContracts are allowed to override their parents' functions and change the visibility from
external
topublic
.constant
s should be defined rather than using magic numbersUse a more recent version of solidity
Use a solidity version of at least 0.8.12 to get
string.concat()
to be used instead ofabi.encodePacked(<str>,<str>)
Variable names that consist of all capital letters should be reserved for
const
/immutable
variablesIf the variable needs to be different based on which class it comes from, a
view
/pure
function should be used instead (e.g. like this).Non-library/interface-only files should use fixed compiler versions, not floating ones
Code should use the same solidity versions
Typos
overriden -> overridden
NatSpec is incomplete
File: contracts/utils/MultiRateLimited.sol (lines 327-332)
Missing:
@return
File: contracts/volt/Volt.sol (lines 58-70)
Missing:
@param v
@param r
@param s
File: contracts/peg/NonCustodialPSM.sol (lines 217-230)
Missing:
@return
File: contracts/peg/NonCustodialPSM.sol (lines 257-270)
Missing:
@return
Event is missing
indexed
fieldsEach
event
should use threeindexed
fields if there are three or more fieldsMultiplication on the result of a division
All multiplications should be done first before doing any divisions, to avoid loss of precision
Non-exploitable reentrancies
Follow the best-practice of the Checks-Effects-Interactions pattern