QA Report #460
Labels
bug
Something isn't working
QA (Quality Assurance)
Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
sponsor acknowledged
Technically the issue is correct, but we're not going to resolve it for XYZ reasons
Summary
Low
[L01] A floating pragma is set.
[L02] A different pragma is set.
Non Critical
[NC01] Use of block timestamp
Low
[L01] A floating pragma is set.
Description
The current pragma Solidity directive is >=0.8.0" for some contracts. It is recommended to specify a fixed compiler version to ensure that the bytecode produced
does not vary between builds.
This is especially important if you rely on bytecode-level verification of the code.
Mitigation
Lock the pragma.
Lines in the code
IBondCallback.sol#L2
IHeart.sol#L2
IOperator.sol#L2
[L02] A different pragma is set.
Description
The current pragma Solidity directive is "0.8.15" but there is others contracts that is using a different pragma version ">=0.8.0".
It's cleaner to use the same versions.
Lines in the code
INSTR.sol#L2
MINTR.sol#L2
TRSRY.sol#L2
RANGE.sol#L2
PRICE.sol#L2
VOTES.sol#L2
Kernel.sol#L2
KernelUtils.sol#L2
TreasuryCustodian.sol#L2
Operator.sol#L2
BondCallback.sol#L2
Heart.sol#L2
Governance.sol#L2
PriceConfig.sol#L2
VoterRegistration.sol#L2
IHeart.sol#L2
IOperator.sol#L2
IBondCallback.sol#L2
Non Critical
[NC01] Use of block timestamp
Description
Block timestamps have historically been used for a variety of applications, such as entropy for random numbers (see the Entropy Illusion for further details),
locking funds for periods of time, and various state-changing conditional statements that are time-dependent.
Miners have the ability to adjust timestamps slightly, which can prove to be dangerous if block timestamps are used incorrectly in smart contracts.
Recommendation
Block timestamps should not be used for entropy or generating random numbers—i.e., they should not be the deciding factor
(either directly or through some derivation) for winning a game or changing an important state.
Time-sensitive logic is sometimes required; e.g., for unlocking contracts (time-locking), completing an ICO after a few weeks,
or enforcing expiry dates. It is sometimes recommended to use block.number and an average block time to estimate times;
with a 10 second block time, 1 week equates to approximately, 60480 blocks. Thus, specifying a block number at which to change
a contract state can be more secure, as miners are unable to easily manipulate the block number.
Lines in the code
Heart.sol#63
Heart.sol#94
Heart.sol#131
Governance.sol#L171
Governance.sol#L212
Governance.sol#L227
Governance.sol#L231
Governance.sol#L272
PRICE.sol#L143
PRICE.sol#L146
PRICE.sol#L165
PRICE.sol#L171
PRICE.sol#L215
RANGE.sol#L85
RANGE.sol#L92
RANGE.sol#L136
RANGE.sol#L138
RANGE.sol#L148
RANGE.sol#L150
RANGE.sol#L191
RANGE.sol#L200
RANGE.sol#L207
RANGE.sol#L231
RANGE.sol#L233
Operator.sol#L210
Operator.sol#L216
Operator.sol#L404
Operator.sol#L456
Operator.sol#L708
Operator.sol#L720
The text was updated successfully, but these errors were encountered: