The governance queue.

Current state

Nothing is queued

Block 49,795,399, read at 2026-08-10T16:42:25.802Z. Minimum delay 172,800 seconds. Over the contract's whole life: 13 calls scheduled, 13 executed, 0 cancelled, across 1 operation.

Who can act on the queue

Netted from this contract's own RoleGranted and RoleRevoked events rather than asserted from a config file. The uncomfortable line is the third one: the only party who can cancel a scheduled operation is the same party who can schedule it.

What sits behind the delay

Timelock 0x36A14976980B7Dd33136f6613545EB0A2C0a0D72. Operator Safe 0x52d3E450bA6c299B1B07298F1E87DD74732D4877. skUSD is outside the timelock deliberately, and its admin is the Safe directly.

Somebody is receiving this

Since 2026-08-09 a daemon polls this contract every 60 seconds, decodes anything scheduled against the verified ABIs of the contracts the timelock controls, and pushes a plain-language page to the Kerne operator channel. It covers CallScheduled, CallExecuted, Cancelled, a change to the 48 hour delay itself, and every role change on the timelock. Its alarm path is proven by replaying a real historical CallScheduled through the same decoder, rather than by queuing a live privileged call to test it.

Last heartbeat 2026-08-10T16:42:10Z, which was 15s before this page was rendered. Scanned to block 49795385. Budget 180s. Compute it yourself from watcher.heartbeat_at_unix on /api/timelock rather than trusting this sentence, which is a render-time literal and can be served from a cache.

It pages Kerne, not you. That distinction is the first item below and it is not a formality.

What this page does not fix

• This surface is a pull, and the alert behind it is not yours. The queue here is recomputed when it is requested. Separately, since 2026-08-09 Kerne runs an alerting daemon that polls this contract every 60 seconds and pushes a decoded page to the Kerne operator channel when anything is scheduled, executed, cancelled, or when the delay or a role changes; its heartbeat is published under watcher on /api/timelock so you can check it is alive rather than take our word for it. But it pages Kerne, not you. To be notified yourself rather than to look, poll this endpoint and diff pending_count.
• A monitor does not create a canceller. CANCELLER_ROLE on this timelock is held by the operator Safe and by nobody else, which is read from chain and reported under roles.canceller. Seeing a scheduled operation at hour 47 still leaves a holder with no independent party to call. The seat is designed and not deployed, and it is not deployed because there is nobody outside the operator set to hold it.
• The 48 hour delay protects exit, not the contents of the queue. It means a holder has two days to redeem before a privileged operation lands. It does not mean the operation can be stopped.
• A failed read is reported as a failed read. If Base cannot be reached, ok is false and pending is null rather than an empty list, because "I could not look" and "nothing is queued" are opposite statements.
• skUSD is outside the timelock. Its DEFAULT_ADMIN is still the operator Safe directly, and that is by design rather than an oversight.

Check it without us

The machine-readable form of this page is at /api/timelock. It answers HTTP 503 rather than 200 when the read fails, so a watcher treats an outage as an outage instead of as a quiet all-clear. To be told rather than to look, poll it and diff pending_count.

# every five minutes, print the queue state
while :; do
  curl -s https://kerne.fi/api/timelock | jq -c '{ok,pending_count,alarm}'
  sleep 300
done

Most public Base endpoints cap eth_getLogs at a 10,000 block range, which is narrower than this contract's life, so a naive replay silently returns a short list. The Tenderly public gateway serves the full range in one call.

Where this came from

This page exists because somebody outside Kerne said it should. An independent reviewer spent five weeks going through the protocol in public on the Euler governance forum, reproduced the timelock role set himself, and then pointed out that a 48 hour delay is only a notification if someone receives it, and that nothing was watching CallScheduled. Kerne agreed and gave no date. This is the half of that objection a page can close. The other half needs a canceller who is not us.

The thread, in full and undeleted