Skip to content

Commit

Permalink
Update AUDIT_REPORT.md
Browse files Browse the repository at this point in the history
  • Loading branch information
jordaniza authored Nov 1, 2024
1 parent 853d031 commit 511c092
Showing 1 changed file with 2 additions and 1 deletion.
3 changes: 2 additions & 1 deletion audits/AUDIT_REPORT.md
Original file line number Diff line number Diff line change
Expand Up @@ -102,6 +102,7 @@ Aragon Audits were conducted by various team members.
| Severity | Issue | Status | Comment or PR |
| -------- | -------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| U | New Note-1 | Acknowledged | This is correct and is acknowledged in the same manner as HAL-12. The voting power of votes in the withdrawal queue is active until the end of the current interval, but it cannot be used as the NFT is held by the escrow, so in the current implementation we don't believe this is a problem. Blocksec is correct to acknowledge that this should be addressed in future implementations. |
| U | New Note-2 | Acknowledged | Allowing the users to change votes during the voting period is intended behaviour in this implementation. |
| U | New Note-2 | Acknowledged | Allowing the users to change votes during the voting period is intended behaviour in this implementation. |
| U | New Issue-2 | Acknowledged | Adding support for Global checkpoints is currently in development and will be added in a future release. A WIP Branch can be seen in this repo but we are exploring alternative implementations due to known gas and complexity issues with Curve-style checkpointing systems. |
| U | New Question-1 | Acknowledged | The purpose of the warmup period is to function as a minimum buffer before users can vote. In the current implementation, voting power starts accumulating from the start of the upcoming deposit interval (weekly by default), but to avoid someone opportunisitically locking 1 second before voting starts, we add a minimum period where they cannot vote. The intended behaviour is that the voting power _should_ still accumulate during this time. |
| U | New Question-2 | TBC | Reviewing this in depth I believe the behaviour you mentioned is intended. The resolveEpochVoteXXIn function uses the sentinel value "0" to indicate "has started" (startsIn) or "has ended" (endsIn), else it returns a positive value. In the example you give, if one is outside the voting window. `EndsIn` should return 0 and `StartsIn` should return the seconds until the next voting window (including the buffer). That said, I agree this needs to be approached with care, the above semantics may not be well understood, and perhaps a different way of expressing active should be fetched. It's telling that the `resolveVotingActive` doesn't use the zero sentinel value, so again, it's not particularly clear. |

0 comments on commit 511c092

Please sign in to comment.