audit: Better Storage and Struct Packing Possible #204
Conversation
Codecov Report
@@ Coverage Diff @@
## main #204 +/- ##
=======================================
Coverage 82.15% 82.15%
=======================================
Files 29 29
Lines 454 454
Branches 114 114
=======================================
Hits 373 373
Misses 65 65
Partials 16 16
|
.forge-snapshots/ProposeSigComp.snap
Outdated
| 150029 |
.forge-snapshots/VoteSigComp.snap
Outdated
| 51840 |
There was a problem hiding this comment.
these are outdated
| // We store the following 3 timestamps for each proposal despite the fact that they can be | ||
| // inferred from the votingDelay, minVotingDuration, and maxVotingDuration state variables | ||
| // because those variables may be updated during the lifetime of a proposal. |
There was a problem hiding this comment.
I believe we should keep that in the code as it's a useful comment for the reader imho
| @@ -16,7 +16,7 @@ contract WhitelistVotingStrategy is IVotingStrategy { | |||
| // The address of the member. | |||
| address addr; | |||
| // The voting power of the member. | |||
| uint256 vp; | |||
| uint96 vp; | |||
There was a problem hiding this comment.
I know this was mentioned in the audit but I don't know how I feel about it. We could imagine some people doing a token + whitelist strategy, and having like 2^100 tokens each. In which case, the whitelist would be too limited...
I guess this is an edge case scenario and 99% of the time, uint96 will do the work so it's fine
There was a problem hiding this comment.
yeah, always possible to just write a new strat too if you really need something specific
closes #177