Protocol Security Cluster
Protocol Upgrade Safety with Invariant Monitoring
This page explains how teams should treat upgrades as controlled production experiments rather than one-time binary events. It focuses on invariant catalogs, canary rollout discipline, and pre-committed containment actions when live behavior drifts outside approved safety bounds.
Within this cluster
Invariant monitoring helps protocol teams detect whether a live upgrade is moving the system into an unsafe state, even after audits and simulations are complete. Strong upgrade safety combines pre-release review with runtime checks, staged rollout, and a defined containment path if assumptions fail in production.
Why Is an Audited Upgrade Still Not Enough?
Audits reduce defect risk, but they do not prove the live system will remain inside safe operating bounds once real state, liquidity, users, and integrations begin interacting with the new logic. Upgrade safety depends on whether the deployed system stays inside approved invariants after release.
This page sits at the center of the protocol-security cluster because upgrades interact directly with governance integrity, authorization boundaries, and containment design.
| Invariant class | Main question | If breached |
|---|---|---|
| Asset safety | Can value move in unauthorized ways? | Possible direct loss |
| Authorization | Can new roles or paths do more than intended? | Hidden control expansion |
| Pricing / economic | Do outputs stay within approved bounds? | Silent economic drift |
| Liveness | Do core actions still work under realistic load? | Production degradation or outage |
What Should Teams Define Before Writing Upgrade Code?
Define the invariant catalog first, not last. Each invariant should have a measurement source, threshold, owner, and containment action. If an invariant has no direct action attached, it is not a control yet. The catalog should also distinguish between pre-upgrade checks, live post-upgrade checks, and rollback gates so every team knows what must pass before exposure increases.
- State the invariant in plain operational language.
- Define the data source that proves or disproves it.
- Set thresholds that trigger containment, not just dashboards.
- Assign an owner for response.
{
"invariant": "unauthorized_asset_movement",
"threshold": 0,
"dataSource": "execution_telemetry",
"containment": "pause_high_risk_lane"
}Which Upgrade Checks Belong Before and After Deployment?
Pre-upgrade checks should verify code provenance, selector scope, state migration safety, and simulation outputs. Post-upgrade checks should verify that production behavior still matches those assumptions under real traffic, liquidity, and dependency conditions. Teams get into trouble when they treat monitoring as a dashboard problem instead of a release-control problem.
- Pre-upgrade: artifact review, lane approval, state migration simulation, signer authorization review.
- Post-upgrade: invariant detectors, dependency health checks, exposure limits, and rollback readiness.
- Escalation: any critical mismatch should move the system into a predefined containment state.
Why Does Canary Rollout Need a Real Risk Budget?
A canary phase is useful only if it constrains exposure. Teams should limit value-at-risk, narrow the user or pool segment, define an observation window, and wire automatic freeze behavior to critical invariant breaches.
- Limit risk exposure during the canary window.
- Promote only after the observation period passes cleanly.
- Escalate to stronger containment if critical invariants breach.
A real canary budget should name the maximum affected assets, routes, or pools that can be exposed before the next approval step. If exposure is effectively full-system from the start, the canary is symbolic rather than protective.
What Should Containment Look Like?
Containment should be pre-committed by breach class: freeze risky lanes for asset safety issues, revoke or constrain authority for authorization drift, tighten route limits for economic breaches, and roll back or degrade safely for liveness failures.
- Critical asset breach → immediate containment lane.
- Authorization drift → isolate roles and privileged selectors.
- Economic drift → tighten limits and route sets.
- Liveness breach → rollback or controlled degraded mode.
Containment logic should explicitly connect to pause design and to the approval model described in governance timelock bypass defense. If the team cannot say who is allowed to contain, who is allowed to resume, and which evidence changes that state, the upgrade path is not operationally safe yet. Bridge teams applying the same logic at route level should also review the bridge route risk scoring framework, because invariant breaches matter differently when route trust assumptions and liquidity exposure are uneven.
New in this cluster
Frequently Asked Questions
Why is an audited upgrade still not enough?
Because real production state, liquidity, and cross-system interactions can drift away from test assumptions after deployment. Audits reduce bug risk, but invariants prove live safety.
What should teams implement first?
Define the invariant catalog before coding, then connect each critical invariant to a measurable detector and an explicit containment action.