You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add a contract-enforced minimum delay between announcing and executing upgrades to the FWSS and PDPVerifier contracts.
The FOC WG considered doing this as part of #505 / #533 and decided on 2026-06-30 not to prioritize contract-enforced delay now. For the immediate work, we will keep #505 focused on contract/operator ergonomics. This issue preserves the security-hardening work as an explicit backlog item for future prioritization.
A contract-enforced delay provides a verifiable security guarantee that process alone cannot provide. It gives operators and integrators time to inspect an announced implementation and react to deployment mistakes, malicious upgrades, or a compromised/social-engineered multisig before the new implementation can execute.
We are deferring it because current customer demand is limited, FOC still expects meaningful contract iteration, and the delay would constrain operational response. We should revisit that balance as adoption, funds at risk, and demand for trust minimization grow.
Direction discussed
The leading future shape discussed was:
Apply to both FWSS and PDPVerifier.
Use a simple ramp that reaches approximately 48 hours after a period of stability, rather than the original two-week maximum proposed in feat: UpgradeHardening #533.
Keep the policy understandable and easy to communicate.
Do not assume that rollback can always bypass the delay; rollback may be storage-unsafe.
Preserve the ability to tighten the delay over time without needing to weaken an already-promised security guarantee.
The exact curve, grace period, and implementation remain to be decided when this is prioritized.
Done criteria
Confirm the current customer/integrator requirement and threat model.
Decide the delay shape, ramp period, and maximum delay.
Define behavior for emergency fixes and rollbacks.
Implement the policy for both FWSS and PDPVerifier.
Emit sufficient event data for operators and monitoring systems to determine the earliest execution epoch.
Add contract tests, deployment/tooling support, and operator documentation.
Coordinate with FilOzone/tpm-utils#51 so upgrade announcements are surfaced in Slack. This monitoring improves transparency but does not itself provide a security guarantee.
Summary
Add a contract-enforced minimum delay between announcing and executing upgrades to the FWSS and PDPVerifier contracts.
The FOC WG considered doing this as part of #505 / #533 and decided on 2026-06-30 not to prioritize contract-enforced delay now. For the immediate work, we will keep #505 focused on contract/operator ergonomics. This issue preserves the security-hardening work as an explicit backlog item for future prioritization.
Decision record and trade-off analysis: 202606 Contract upgrade delay decision: FWSS and PDPVerifier
Why
A contract-enforced delay provides a verifiable security guarantee that process alone cannot provide. It gives operators and integrators time to inspect an announced implementation and react to deployment mistakes, malicious upgrades, or a compromised/social-engineered multisig before the new implementation can execute.
We are deferring it because current customer demand is limited, FOC still expects meaningful contract iteration, and the delay would constrain operational response. We should revisit that balance as adoption, funds at risk, and demand for trust minimization grow.
Direction discussed
The leading future shape discussed was:
The exact curve, grace period, and implementation remain to be decided when this is prioritized.
Done criteria
Related