Warden
Status: testnet only, not audited yet.
You already have a Knot council. This page is the wait before an Atlas name points at a different contract.
Atlas does not delay set_service. Warden does, because warden is the guardian. Knot proposals stay a generic executor: the proposal's target is the warden id, and the function is schedule_service.
Live ids: Deployments. Every method: docs/warden.md.
Two delays
| Delay | Where | What it covers | Who cannot delete it in one transaction |
|---|---|---|---|
delay_blocks | warden | schedule_service, set_delay, set_scheduler, set_guardian | The scheduler |
timelock_blocks | Atlas | set_guardian, set_timelock | The warden |
A guardian change waits twice: warden queues set_guardian for delay_blocks, then Atlas waits timelock_blocks before it applies. set_timelock is forwarded to Atlas in the same transaction, and Atlas waits on it. An immediate set_timelock(0) would let the guardian replace itself in the same transaction, so that Atlas wait stays.
Until the guardian wait finishes, the old warden is still the guardian, and service repoints still wait delay_blocks. A service scheduled under the old delay keeps that execute_at.
init_warden and Atlas init_guardian are the only immediate writes of each delay. Do not leave either at 0.
Who may call
| Call | Who |
|---|---|
init_warden | Deploy owner, direct, once |
schedule_service, set_delay, set_scheduler, cancels, forwards | The scheduler |
execute_service, execute_admin | Anyone, after execute_at |
An external scheduler must be the key itself, not a contract inside that key's transaction. A contract scheduler is accepted when caller is that contract. The proposals API qualifies, because finalize's caller is the proposals API.
Warden is not the committee, not a second directory, and not an open proxy. A new warden is a new contract id, installed with set_guardian.
What is wired on testnet today
Atlas's guardian is a Warden contract, and that Warden waits 30 blocks before a service change applies. These are lab values. The scheduler is one ordinary key, not a group. The shared Proposals contract has no group bound yet, so a group cannot start a change. Ids are on Deployments. Who holds which power: Who can change what.
Warden and its encoding crate build only next to an Atlas checkout.
Install it
| Step | Call | Direct owner? |
|---|---|---|
| 1 | Registry book + API. Atlas knot-registry names the API. init_data | Yes |
| 2 | Proposals book + API. init_data, init_registry, set_authorized_account | Yes |
| 3 | init_warden with the Atlas id, the proposals API as scheduler, and the service delay | Yes |
| 4 | Atlas init_guardian with the warden id and a timelock above 0 | Yes |
Then the council proposes schedule_service aimed at the warden. Finalize only schedules. After execute_at, anyone calls execute_service. That transaction calls Atlas set_service.
Events
| Topic | When |
|---|---|
atlas_set, scheduler_set, delay_set | init_warden |
service_scheduled / service_executed / service_cancelled | A repoint |
admin_scheduled / admin_cancelled | Delay or scheduler change |
guardian_forwarded, timelock_forwarded, atlas_cancel_forwarded | After the Atlas call |
The payload is the value that was written. Atlas still emits its own events when the directory changes. Subscribe to warden for the wait, and to Atlas for the directory.