Closed sherlock-admin4 closed 7 months ago
1 comment(s) were left on this issue during the judging contest.
takarez commented:
as per the Readme this should be a valid; medium(5)
1 is an invalid issue.
First, the EIP says that assets can be delegated to address(0)
, not that this must be possible. The assets cannot be delegated to address(0)
here.
Second, it says assets that are delegated to address(0)
should not be tracked. Aside from the should keyword, you'll see that assets are never delegated to address(0)
. They are always delegated to some address, even by default.
2 is also an invalid issue.
"The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119."
"SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
There are limitations that prevent the implementation from meeting this recommendation.
0xkaden
medium
EIP-5805 non-compliance
Summary
EpochBasedVoteToken and EpochBasedInflationaryToken fail to comply with the inherited ERC5805 standard.
Vulnerability Detail
EpochBasedVoteToken and EpochBasedInflationaryToken inherit ERC5805 but are non-compliant in two ways:
a != 0
and all timestampt < clock
,getPastVotes(a, t)
SHOULD be the sum of the “balances” of all the accounts that delegated toa
whenclock
overtookt
." This is not the case with EpochBasedInflationaryVoteToken since unrealized inflation must first be manually realized by calling_sync
to update past balances:Impact
Failure to comply to EIP's can lead to unexpected effects.
Code Snippet
Tool used
Manual Review
Recommendation
Comply to the EIP specifications or otherwise clearly indicate that the contract is not fully ERC5805 compliant.