Time-delayed execution and staged upgrades
Development status: Being explored — The design is being explored; its public interface and support are not settled. Time-delayed, reviewable execution of approved governance decisions and staged protocol upgrades with review and rollback safeguards are being explored, but no decision is executed through governance and no upgrade mechanism operates on any available network, and there is no upgrade calendar. Nothing is publicly available for live use.
Before you read: Governance, compliance and assurance.
Would governance decisions and protocol upgrades take effect immediately, and how would upgrades be made safe? Short answer: they are not intended to take effect immediately. Approved decisions are intended to take effect only after a delay that allows review, and protocol upgrades are intended to be introduced in stages with safeguards for reversing them. This page explains both intentions, what they would mean for operators and developers, and their limits. It gives no delays, upgrade mechanics, compatibility rules or schedules.
Why not immediately
- Time to review and prepare. An approved change that takes effect at once leaves no time for those affected to review it, prepare for it or raise concerns.
- Containing defects. Introducing a software change everywhere at the same moment can let a single defect affect everything at once.
- Established practice. Delay and staged introduction are established safety practices for shared systems. This page describes Cubane’s intent to apply them, not a mechanism.
Time-delayed, reviewable execution
Being explored. The design is being explored for time-delayed, reviewable execution of approved governance decisions.
- Approved governance decisions are intended to take effect only after a delay.
- During the delay, the pending change is intended to be visible and open to review before it takes effect.
- The length of any delay, who could act during it and what could happen to a pending change are not described.
- No governance decision is executed on any available network today, with or without a delay.
Staged upgrades with rollback safeguards
Being explored. The design is being explored for staged protocol upgrades with review and rollback safeguards: an upgrade would be introduced in stages rather than all at once, and safeguards would be intended to allow a problematic upgrade to be reversed.
- How stages would be defined, what would lead to a reversal and which compatibility rules would apply are not described.
- There is no upgrade calendar. No upgrade dates, versions or schedules are published.
What operators and developers would do while a change is pending
Conditional — once delayed execution and staged upgrades are implemented, enabled and publicly released.
- Follow and prepare. Follow announced changes during the delay, and prepare nodes and applications before a change takes effect.
- Read compatibility notices. Read compatibility and deprecation notices; their policy is on Versioning, compatibility and deprecation.
- Plan operator work together. Operators would plan upgrade work alongside backup and recovery; see Deployment, backup and recovery: what operators would plan for.
- Know where to look. How changes would be announced, and where they could be followed, would be documented with a release.
Related safeguards
- Emergency controls are a separate topic, being explored on Emergency controls and protocol safeguards.
- Approved decisions come from the process described on Governance proposals and decisions.
- Records of significant actions are described on Audit trails and tamper-evident logging.
Assumptions, trust and limitations
- A delay helps only if someone reviews pending changes during it.
- Reversing an upgrade would not necessarily undo every consequence, particularly actions taken outside the network in response to it.
- Staged introduction limits the impact of some defects. It does not ensure that every defect is caught.
Not yet available, and how this page will grow
Once implemented and released, this page would describe how pending changes are announced and reviewed, how upgrades are staged and what operators and developers need to do. Exact procedures, delays and compatibility rules would accompany that release. Further technical reference is not yet available, and status changes would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- any delay length, role, schedule, upgrade calendar, compatibility rule, approval rule or reversal condition;
- that any delayed-execution or upgrade mechanism operates on any network.
Anything not stated here as available should be treated as unavailable.
Related pages
- Governance proposals and decisions — where approved decisions come from.
- Emergency controls and protocol safeguards — the separate emergency topic.
- Versioning, compatibility and deprecation — versioning and compatibility policy.
- Deployment, backup and recovery: what operators would plan for — operator concerns around upgrades.
- Audit trails and tamper-evident logging — records of significant actions.
Glossary
References
No approved public references yet.
