Activity Log
Date: 05/08/2026 - 06/08/2026
- [05/08 - 15:22 CET] - @jensei created a Safe transaction on Base to claim the Merkl accrued rewards on behalf of the Timelock, as authorized by [SIP5.24].
- [05/08 - 15:22 CET] - @jensei posted into the Telegram and Signal DM Groups.
- [05/08 - 15:33 CET] - @jensei followed up in both groups to flag that the transaction was non-emergency but time sensitive, as it reverts once a new Merkl reward root is published.
The transaction did not reach quorum before its reward root was superseded and therefore expired without being executed.
- [06/08 - 13:06 CET] - @jensei created a rejection transaction to clear the expired transaction from the queue, and a resubmitted claim transaction against the current root.
- [06/08 - 13:06 CET] - @jensei posted into the Telegram and Signal DM Groups, noting the approximately two hour window in which claim transactions remain valid and asking signers to simulate and sign at their earliest convenience.
- [06/08 - 13:43 CET] - Rejection transaction was executed on Base.
- [06/08 - 13:46 CET] - Resubmitted claim transaction was executed on Base.
Claimed into the DAO Treasury:
| Asset | Amount |
|---|---|
| SUMR | 762,887.1296 |
| USDC | 17.4189 |
Background
Scope of the action:
[SIP5.24] authorized the Guardian Operator to claim SUMR and USDC accrued through Merkl on behalf of the Timelock. The claim routes the rewards directly to the DAO Treasury; the Guardians have no discretion over the destination or the amount, both of which are fixed by the Merkl distribution and the claim calldata itself.
Why the first transaction expired:
Merkl claims are validated against a Merkle proof that is periodically refreshed. Once the proof is superseded, any claim transaction built against the previous one reverts. In practice this leaves a window of roughly two hours in which a queued claim remains executable.
The transaction proposed on 05/08 at 15:22 CET did not collect enough signatures before its proof expired, so it could no longer be executed and had to be refreshed and resubmitted. No funds were at risk and no value was lost as a result (an expired claim simply reverts), and the underlying rewards remain claimable against the refreshed proof. The stale transaction was left in the queue overnight and cleared the following day.
Resolution:
On 06/08 a rejection transaction was proposed to clear the stale nonce, followed by a fresh claim built against the then-current root. Both reached quorum and executed within 40 minutes of being posted, and the rewards were claimed into the Treasury as authorized.
Signer threshold:
These were the first transactions executed under the 4/8 signer threshold adopted on 24/07/2026, replacing the previous 6/8. Both the rejection and the resubmitted claim reached quorum and executed within 40 minutes of being posted to the signer groups, against 216 to 240 minutes for the non-urgent transactions proposed on 24/07 under the old threshold.
The comparison should be read with the usual caveat that response time depends heavily on signer availability at the moment of proposal, and a single data point is not evidence on its own. It is nonetheless consistent with the reasoning raised during the [SIP0.3] discussion, that assembling quorum rather than reviewing the transaction has been the binding constraint on Guardian response time.
Note for future claims:
This was the first claim executed under [SIP5.24] and the expiry is a useful data point: the two hour validity window is short relative to normal Guardian coordination time. Future claims will be flagged in advance in the signer groups so that signers can be on hand when the transaction is proposed, rather than the transaction waiting on signer availability.