conceptualv0.1 · skeleton docs
Upgrade policy
Who can change what, how fast, and how you find out.
Powers, separated
| Power | Holder (planned) | Delay | Scope |
|---|---|---|---|
| Pause | Guardian multisig | Immediate | Stop new execution globally or per hook. Cannot move funds or change logic. |
| Registry edits | Hook namespace owner | Immediate for pause; 48h for adapter changes | Only their own namespace |
| Contract upgrade | Admin multisig behind timelock | 7 days | Router, gateway, registry |
| Emitter registration | Admin multisig behind timelock | 7 days | Which router and gateways trust each other |
Pause is fast because stopping is safe. Everything that changes behaviour is slow, so integrators can react.
Pilot vs. steady state
During a pilot, contracts may be upgradeable with a shorter delay so bugs can be fixed quickly. This will be:
- stated on the Security page and in the registry entries;
- time-boxed, with a published date for moving to the steady-state delays above;
- visible on-chain (timelock queue).
How you find out
- Queued upgrades and registry changes are shown on Status (planned).
- Schema deprecations get at least one full timelock window plus 30 days of dual support.
- Hook deprecations are shown on the hook's registry page with a link to its successor.