From 511c092869e1606987266b4bbecaa2aed2cc6629 Mon Sep 17 00:00:00 2001 From: Jordan <45881807+jordaniza@users.noreply.github.com> Date: Fri, 1 Nov 2024 13:40:47 +0400 Subject: [PATCH] Update AUDIT_REPORT.md --- audits/AUDIT_REPORT.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/audits/AUDIT_REPORT.md b/audits/AUDIT_REPORT.md index 1d4eb4a..222b06f 100644 --- a/audits/AUDIT_REPORT.md +++ b/audits/AUDIT_REPORT.md @@ -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. |