The Safe queue, decoded

1. What is in the queue right now

Four entries. The Safe's nonce is 27 as last read, because the live read is failing, its threshold is 2, its guard slot is zero and its module list is empty. Three of the four target the governance timelock rather than a protocol contract, which is what the queue looks like after the 2026-08-06 custody handover: the Safe now asks the timelock for changes instead of making them directly.

Every call above is operation 0, a plain CALL, with zero value and zero in every gas field. None of them is a DELEGATECALL, and none of them is wrapped in a MultiSend.

2. The fully signed entry at nonce 0, and why it is inert

This is the entry that looks alarming. It carries two confirmations out of two, it targets the kUSD token, and its payload contains the hash of MINTER_ROLE. A reader who stops there reasonably concludes that a mint-authority grant is one click from executing. It is not, and here is each reason separately, because any one of them is sufficient on its own.

1. Its nonce is spent. Safe transactions consume nonces strictly in order, and the Safe's nonce is 27 as last read, because the live read is failing. A nonce-0 payload cannot be executed there: the nonce is part of the EIP-712 struct that the signatures are checked against, so the existing signatures do not even authorise a re-nonced version of the same call.
2. Its function selector does not exist on kUSD. The payload begins 0x2f2ff15a. The selector for grantRole(bytes32,address) is 0x2f2ff15d. They differ in the last nibble. Searching the deployed kUSD runtime finds 0x2f2ff15d present and 0x2f2ff15a absent, which is an apples-to-apples control rather than a bare absence claim. The 4-byte directory has no entry for it at all.
3. The identical payload has already been executed, and it reverted. On 2026-04-16 the Safe executed this exact call at nonce 0 in transaction 0x46eb8404 at block 44,762,366. The Safe emitted ExecutionFailure, not ExecutionSuccess. So this is not a theoretical argument about selectors: the call was tried on chain and did nothing. The pending entry is a duplicate proposal for the same nonce that was orphaned when the other one consumed it.
4. Its target is a superseded contract that holds no role. The address in the payload, 0x7286200Ba4C6Ed5041df55965c484a106F4716FD, is the original April 2026 peg module, superseded twice since. Its own kUSD() getter still returns a placeholder address, so it was never wired to the live token, and hasRole returns false for it on both MINTER_ROLE and DEFAULT_ADMIN_ROLE today.

3. The three live entries, and what they do

All three are the same shape against a different module. Each one schedules an unpause() call through the governance timelock, and each was submitted on 2026-08-04 and is waiting on a second signature. They exist because of an asymmetry the custody handover created deliberately, and it is worth explaining rather than leaving to be discovered.

Why a pre-armed unpause is needed at all

After the 2026-08-06 handover, pause is instant and unpause is not. Pause runs through the PauseGuardian in a single Safe transaction. Unpause is gated on DEFAULT_ADMIN_ROLE, which the timelock now holds, so restarting a halted module takes the full 48 hours. That is the intended trade: it removes our ability to pause an exit and then quietly resume. The cost is that a module halted in an incident stays halted for two days.

These three transactions pay that cost in advance. Each schedules the unpause now, so its 48 hours elapse while nothing is wrong and the operation then sits ready indefinitely. They cannot fire while the system is healthy: unpause() reverts ExpectedPause() on a module that is not paused. A one-shot valve that only works when it is needed.

They are three separate operations rather than one batch on purpose. The timelock executes a batch atomically, so a single three-module batch would only fire if all three were paused at once, and would revert in the realistic case of the live mint module being halted on its own. One operation per module covers every combination. Only the Safe can execute them, because the executor role is not open to the zero address, so a pre-armed unpause cannot be turned against us.

What already executed, for the record

This page previously described nonces 19 and 20 as pending. Both executed on 2026-08-03. Nonce 19 revoked MINTER_ROLE from the v2 vault at 0x8ccc56B5624e2FDB592F6609d81F4c3798e3292B, which had held it since May 2026 and never used it, leaving the live mint module as the only holder. The vault could not have minted in any case: its deployed runtime contains no kUSD address, no mint selector and no delegatecall opcode. That was a clarity improvement rather than a security fix and we said so at the time. Nonce 20 widened the oracle staleness window on the mint module from 93,600 seconds to 172,800, the maximum the contract accepts. That was a deliberate loosening and it is recorded as one. In a genuine USDC depeg the staleness gate now reacts up to 48 hours late instead of 26. We judged the availability risk of a sub-two-hour margin over the feed's worst observed 24.008 hour heartbeat to be the larger exposure, given the depeg band is a separate check that was not touched. It is reversible by setting the value back, which now takes the timelock delay.

Nonces 21 through 26 were the custody handover itself, executed between 2026-08-03T23:24:07Z and 2026-08-06T17:00:07Z. Section 5 describes what they did.

5. What a decoded queue does not fix

There were two independent routes to that outcome and both are now behind the delay. The first is the one our terms page documents: DEFAULT_ADMIN_ROLE on kUSD can grant the minting role to any address. The second does not touch kUSD's admin role at all: the live mint module already holds MINTER_ROLE, and MANAGER_ROLE on that module gates listing a new collateral asset and pointing it at a price feed. We stated the second route explicitly because a remediation that closed only the first one would have looked like a fix and would not have been one.

The design that puts both routes behind a published delay, while keeping the emergency pause immediate, was written and tested against a fork of Base and executed on 2026-08-06 at 17:00:07Z, in transaction 0xed24d495 at block 49,623,130. The Safe no longer holds DEFAULT_ADMIN_ROLE on kUSD or on any of the three modules, and no longer holds MANAGER_ROLE on any of them. A TimelockController at 0x36A14976980B7Dd33136f6613545EB0A2C0a0D72 holds them, with a 48 hour minimum delay: the Safe is not that contract's admin, so two signatures cannot shorten it. A PauseGuardian at 0xC47adaf51907bB1871D07E18eA21dc75Ae93Cc8E holds MANAGER_ROLE for the single purpose of calling pause, so the emergency stop stayed instant. Fast to stop, slow to restart, deliberately.

Two limits worth stating in the same breath. The delay does not make a drain impossible. It makes it observable, and it gives a holder two days to leave through a redemption path that needs no permission from us. And it does not cover everything: the staking vault skUSD at 0x96F5102C15b839757f811A98CEc3725Ac21DfA14 holds most of the kUSD in existence and the Safe still holds sole admin over it with no delay at all. Extending the timelock to it is the next step and it has not been taken. The full position, including the fee and exit mechanics, is on the anchor terms page.