Status

• 2026-07-01: updated with meeting notes made at [2026-06-30 FOC Eng & CX Sync Meeting Notes](https://app.notion.com/p/2026-06-30-FOC-Eng-CX-Sync-Meeting-Notes-390dc41950c1809493b7f71eec7ae020). The 2026-06-30 Decision was also added.
• 2026-06-29: there has been some reading and perspective sharing. @Steve (biglep) is supportive of the proposal made by Rod: . The intent is to close this out 2026-06-30.
• 2026-06-25: initial drafting by @Steve (biglep) that was then shared in slack to get user input.

Purpose

This document is intended to drive a concrete decision for FWSS and PDPVerifier having a contract-enforced upgrade delay (independent of our usual release process delays). Please leave inline comments where possible. If your feedback is broader or you want a single place for notes, use User and maintainer feedback

<aside> ℹ️

Decision timing: target async input over the next couple days, with the 2026-06-30 FOC working group sync as a backstop if alignment is not reached asynchronously.

</aside>

Background

2026-05-28 Hotfix FWSS v1.2.0 compatibility with PDPVerifier v3.4.0 surfaced friction in our two-step upgrade flow. Operators had to pick a specific future epoch in the announce step, and small miscoordination between multisig signers caused the announce step to revert. The postmortem action item was to make announcePlannedUpgrade more forgiving for emergency rollouts so that multisig timing does not slow us down during a critical fix. Specifically: rather than have operators provide an absolute epoch, allow operators to provide a relative minimum delay. William agreed to take that on; tracked in https://github.com/FilOzone/filecoin-services/issues/505.

William's draft implementation is in https://github.com/FilOzone/filecoin-services/pull/533. The PR delivers the original ask, but it also introduces a contract-enforced minimum delay that grows over time since the last upgrade. That second piece goes beyond #505 and requires a deliberate decision before we land code.

Why is it even a discussion about adding contract-enforced delay?

A few things made this feel like the right moment to ask the question:

• We are already refactoring the upgrade contract surface in #533; if we are going to add hardening at all, doing it as part of the same change is cheaper than a follow-up.
• Post-GA, integrators are committing to building on top of FOC contracts. "How mutable are the contracts" becomes a real consideration.
• At least one customer (Arkadiy / Internet Archive) has explicitly asked for a 48-hour minimum delay. William believes a second customer has made the same ask (unconfirmed).
• Real-world incidents elsewhere (social-engineered multisig signers approving bad transactions that looked correct on hardware wallets) have made the "multisig is sufficient" argument less absolute.

These are reasons to consider it. They are not, on their own, reasons to do it. Hence this document.

There is also an asymmetric perception problem worth naming up front: tightening upgrade delay later is usually easy to explain as increased maturity; loosening a deployed delay later may look like a security regression, even if the original value was too restrictive. Whatever we ship first sets the floor on perception.

Key question 1: do we enforce a contract-induced delay at all right now?