FIP-0118: Last Call clarifications

[irenegia]

This PR batches the pending Last Call clarifications. Most items write down behavior that was already agreed in review discussions or in the Aug 17 SRA re-design doc; the binding-timing items in topic 5 change SRA measurement behavior and are flagged for review.

Main changes per topic:

1. ExtendSectorExpiration3 UpgradeSectorQuality mechanics

Specification, Section 1 (Datacap Deprecation)
Replaces the one-line mention of this method with its full mechanics: a method that upgrades any sector below 10x QAP (including partially verified sectors), optional extension in the same call, pledge raised at most once (sectors at 10x are skipped, not a failure), the shared SnapDeals/extension daily-fee rule (pre-FIP-0100 sectors get a fresh fee, so an upgraded sector is treated exactly like a post-FIP-0100 sector of the same power). Fee debt must clear in the same message or the whole call aborts, and the batch is atomic. SnapDeals recompute the pledge only on a QAP increase, so "raised at most once" holds in either order of the two paths.

2. SetGateParams and volume targets

Specification, Section 3.1.1 (volume gate)
Removes the rounding ambiguity in the volume targets, as agreed: the table and the formula entry * ratio^steps did not quite agree because the table was rounded. The rounded table is replaced by the exact values, and a new Precision paragraph states that the formula is exact arithmetic, coinciding with 18-decimal fixed point for these parameters; a future retune that breaks this exactness must state its rounding rule. The "fixed schedule" wording becomes the escalation map defined by (VOL_TARGET_ENTRY, VOL_TARGET_RATIO).

Specification, Section 3.1.1
Writes down the validation rules raised in slack: steps is bounded by the gate count, the write's effective epoch must be later than the last executed gate check, and a retune applies to the next check after its effective epoch. Please @rvagg check the wording matches what was intended.

3. MIN_LOT formula and pricing parameters

Specification, Section 2.3; SRA state list in Section 3.2.
Replaces the "few hundred USD" MIN_LOT guidance with the formula agreed in filecoin-project/solstice#7; the reference term is glossed as a scale reference for lot sizes, not the realized average lot (FIL fees burn and never reach the auctions), and N(Q-1) = 0 falls back to the floor.
Band seeding (first-print anchoring): no FIL volume is priced until five fee-auction claims have met every qualifying condition except the band check.
Print ordering and "strictly after".
Writes down the four bit-exactness rules agreed in filecoin-project/solstice#7.
Parameter and admitted-list writes now apply from the next quarter boundary (topic 4). SetPricingParams stores nothing: the write only emits the parameter event (eng sync, Aug 18).
One wording choice to check in review: the definition of N(Q-1), the number of auction claims that actually cleared in Q-1.

4. SRA governance redesign

Specification, Sections 2.2, 2.3, 2.4.4, 3.2, 4.1 to 4.4, 安全 Considerations

• No governance hold on SRA methods. Every registry change is a both-multisigs write that binds at once, emits an event, and requires a published rationale.
• The protection is transparency plus the remedy: rogue signers are replaced from the level above (FIP plus SWA re-point). The one exception is the SRA code upgrade, which keeps its hold. CancelPending and the pending queue are gone.
• Freeze is deleted; removal is the single sanction. RemoveOrchestrator burns the slice immediately (map entry repointed to f099); income accrued before it stays claimable; bindings are released; survivors gain only at the next SubmitShares.
• Wallet and multisig rotation. ReplaceWallet needs a public request co-signed by the Orchestrator (old wallet for rotation; new wallet as liveness proof when the old key is lost) and is prospective, so accrued balances never move.
• ReplaceOwner is the cooperative multisig rotation, now at both tiers: the SWA gains the mirror method (Section 3.1), binding at once, the one SWA power needing no FIP.
• Admission timing: registry effect at once; an Orchestrator admitted in Q first posts volume for Q+1 and is first paid from Q+2, anchored on the admission itself: no binding applies before the admission does (topic 5).
• 安全 Considerations state the two costs accepted by design: a removal is not clawback (accrued income stays claimable, so Orchestrators should claim often), and a hostile replace by two rogue Registry multisigs is rate-limited by the remedy, not prevented (a hold would only have delayed it, since the cancel rights would belong to the same captured multisigs).

5. Binding timing and the removal guard

Specification, Sections 2.2, 2.3, 3.2, 安全 Considerations, Test Cases

• RemoveOrchestrator reverts while an ended quarter awaits its share map. Closes a corner where an Orchestrator removed between the posting close and SubmitShares re-entered the fresh map and kept earning up to a quarter. The zero-FPV no-op now marks the quarter submitted.
• Binding timing, redesigned after the Aug 25 eng call. This supersedes the Aug 20 quarter rule (which had superseded the settlement-epoch rule): under the quarter rule every client appearing mid-quarter went unmeasured for its whole first quarter. Now attribution is pointwise again: a settlement counts for the pair's holder at the settlement epoch, rebuilt from registry events. A registration also covers the pair's unbound past inside its own quarter, so registration lag loses no volume; a registration in the last REGISTRATION_CUTOFF of a quarter (proposed 7 days, a governance-repo value) applies from the boundary, so governance always has the cutoff to contest a claim before any quarter it covers is measured. ReassignBinding(pair, orch, inherit): prospective from the execution epoch for a client migration; with inherit = true, for a claim adjudicated wrongful, it adopts the displaced registration's call epoch, so the rightful holder gets exactly the span it would have had and the claimant keeps nothing; a binding that already applied in an earlier quarter only ever moves prospectively. Admitted lists and pricing parameters keep the next-quarter rule; determinism sits at the quarter close (every FPV input is an event at or before Q's last epoch). Quarter 1 needs no special case: only the initial governance writes need the pre-activation window, and client pairs registered during Q1 count from activation. 安全 Considerations gain a Claim racing bullet.
• Both are SRA behavior changes, not clarifications; flagged for @rvagg @wjmelements @tanLang @tmaciej-neti. History and rationale in spec for the indexer (ie, how to calculate Filecoin Pay volume per orchestrator) solstice#7.

6. Miner and market alignment with the implementation

PR #1280 by @rvagg, merged into this PR 2026-08-24.

Specification, Sections 1.1 to 1.5, Product/Incentive Considerations

• ES3 renamed UpgradeSectorQuality;
• FULL_QA_POWER flag on SectorOnChainInfo specified as the QAP mechanism; SIMPLE_QA_POWER kept on-chain but no longer read.
• Supersedes the QAP parts of FIP-0045 and FIP-0084: verified_allocation_key stays on the wire but is ignored.
• Explicit reject lists for every state-mutating DataCap and Verified Registry method (USR_FORBIDDEN); reads keep serving the frozen state; no VerReg events after the upgrade.
• Market: pending_deal_allocation_ids removed in migration; BatchActivateDeals return type simplified (miner-only caller, no external use).
• SnapDeals data-presence question resolved: deal weights still record actual data, so the existing check stays valid and no new signal is needed.

7. "Safe" was shorthand: governance multisig terminology, and Question 6

Specification, Sections 2.4.7, 3.1, 3.2, 4.1 to 4.4; Design Rationale; 安全 Considerations

• As confirmed on FIP-0118: add design rationale for two-"SAFE" governance #1278: "Safe" was (mis-)used as shorthand for "governance multisig", not a Safe{Wallet} requirement. Section 4.2 now defines governance multisigs (the two SWA multisigs, the two Registry multisigs), states that the contracts identify each one by its address, and that no specific multisig implementation (e.g., Safe{Wallet}) is required. Every governance use of "Safe" is renamed accordingly; the two remaining Safe{Wallet} mentions are deliberate examples.
• Adds Question 6 to the Design Rationale (why hold-plus-veto in the governed contracts instead of a multisig of multisigs), adapted from @BigLep's FIP-0118: add design rationale for two-"SAFE" governance #1278, which this supersedes. Amended per his review here: the hold is what makes the unilateral veto realistic (the pending write is public for its full duration), the choice of host for that logic is secondary, and f02 enforcement preserves the delay, not the veto, under a compromised contract.
• Also carries one small 4.4-table clarification: volume corrections bind at window close (Section 4.3). The Implementation section now points at the Solstice project board.

8. In-flight messages at the upgrade boundary

Specification, Section 1.5; Backwards Compatibility
Writes down the boundary behavior agreed on the Aug 25 eng call: an in-flight message that directly calls a disabled DataCap or Verified Registry write method rejects after the upgrade, acceptable because these are standalone messages; miner- and market-actor datacap pathways become no-ops, so nothing in flight to them breaks, it just no longer has a datacap effect. @rvagg to confirm against filecoin-project/builtin-actors#1760.

Open questions

1. Should the ES3 method be renamed, e.g. ExtendUpgradeSectors, now that extension is optional and the main effect is the upgrade? If yes, I will add the rename to this PR. Resolved.
2. REGISTRATION_CUTOFF initial value: 7 days proposed, 10 was also floated on the call. Reviewers pick.

[BigLep]

Meta note on the timeline above: this PR was briefly and accidentally force-pushed from 64e77f8 to 2e257ba (wiping the branch back to master's tip) and closed, as a side effect of tooling used while preparing #1278 (using github PR stacks PR adding a Design Rationale entry on top of this one). That event will stay visible in this PR's history since GitHub's timeline doesn't retroactively remove force-push records, but the branch has since been fully restored to 64e77f8 and the PR reopened — all 10 commits and the full diff are intact, verified directly via git and the GitHub API. No content from this PR was lost. Backup refs of the pre-incident commit were also kept as an extra safety margin.

Apologies for the noise, @irenegia.

[BigLep]

@irenegia : I left a couple of suggestions when reviewing again the multisig plan and implementation references.

[irenegia]

@rvagg in-flight language from today's call is in (1952fd9): two bullets in Section 1.5 (after the no-event bullet) plus one clause in Backwards Compatibility. Direct f06/f07 writes reject like post-upgrade calls; miner and market calls do not fail, references are accepted and ignored.

[rvagg]

I pushed 717cb6b with some technical clarifications regarding f099 handling in shares, the UpgradeSectorQuality suggestion I made above (resolved) and a missing noop re DealProposal.verified_deal.

[rvagg]

TODO: consider removing this since it's only on the preseal path and an internal detail that nobody should care about

[tmaciej-neti]

Let's make sure that BoundVolume(Q) (for each Q for which aggregated FPV was bound) is also either part of SRA state or an event (preferably). Or both. This is to ensure that tooling like the indexer can properly calculate MIN_LOT(Q). Don’t know if that was highlighted in previous discussion or if it needs to be a part of the spec.

[tmaciej-neti]

Let's make sure that REGISTRATION_CUTOFF is defined and treated as other SRA state or parameters and is indexable. Unless it's supposed to be a constant changeable only by another FIP.