Network Version 15 (OhSnap) and SnapDeals

SnapDeals allows providers to inject data into existing Committed Capacity (CC) sectors, converting them to deal sectors without a full reseal. Provider deal-flow software must be updated to handle the new ProveReplicaUpdates method and the associated sector state transitions. Teams should verify that their pipeline correctly manages the new sector lifecycle, including the transition from CC to a deal sector and the updated termination and fault rules. Chainscore can review your deal-flow logic for SnapDeals compatibility and state transition correctness.

SnapDeals introduces a new proof type, ProveReplicaUpdate, which is computationally intensive and requires a GPU with sufficient memory. Providers must ensure their hardware is provisioned to handle this new proof within the tight WindowPoSt deadlines to avoid slashing. The addition of this proof type also changes the operational profile of a sealing node, potentially requiring dedicated hardware or scheduling to prevent contention with other sealing tasks. A pre-upgrade hardware audit is strongly recommended.

The ability to convert CC sectors to deal sectors changes the economic calculus for providers. Previously, CC sectors were a sunk cost for future deals. Now, they represent an inventory of immediately addressable capacity. This can reduce the need for over-provisioning and change how providers model their return on investment for new hardware. Teams should update their financial models to account for the reduced onboarding cost and time for deals into existing capacity. Chainscore can assist with an economic impact analysis of your sector portfolio.

While the core transaction format for FIL transfers is unchanged, the upgrade to Network Version 15 is a breaking change for all node operators. Exchanges and custody providers must upgrade their nodes to a compatible Lotus or Venus version before the activation epoch. Failure to do so will result in a fork and service disruption. Teams should schedule a maintenance window, validate the new release on a testnet, and monitor the activation epoch to ensure their node remains in sync with the canonical chain.

After the upgrade activates, operators should monitor for successful ProveReplicaUpdate messages and a healthy rate of sector state transitions from CC to deal sectors. Key metrics include the time taken for the new proof, the rate of failed updates, and any unexpected increase in missed WindowPoSt submissions. A sudden spike in gas costs for the new methods could also indicate a misconfiguration in deal-pricing logic. Chainscore can build custom monitoring dashboards to validate operational stability post-activation.

For clients and deal brokers, SnapDeals changes the negotiation dynamic. A provider with a large CC inventory can now offer faster data onboarding since they bypass the time-consuming PreCommit and ProveCommit steps for a new sector. Integration logic that queries a provider's available capacity must now distinguish between raw CC sectors and those already containing deals. This requires updates to deal-making UIs and market actor queries to accurately reflect a provider's true ability to accept new data.

The Filecoin FIPs repository is the primary source for protocol proposals that define consensus, actor, and market behavior. For OhSnap and SnapDeals, engineering teams should use the repository to identify the proposal text, review the rationale for onboarding data into existing committed-capacity sectors, and distinguish normative protocol requirements from implementation-specific guidance. Treat the FIP text as the baseline for compatibility analysis, then cross-check it against the relevant client release notes and actor implementation before updating provider deal pipelines.

Lotus release notes are the operational source for node operators and storage providers because they identify which releases include support for network-version activations and related migrations. For Network Version 15, teams should review the historical OhSnap-compatible release notes, confirm upgrade instructions, and compare any local patches or forked builds against upstream behavior. Providers running archival or legacy infrastructure should also use the release history to reconstruct the exact client behavior expected around activation and SnapDeals workflows.

The specs-actors repository is the canonical implementation reference for Filecoin built-in actors used during the pre-FVM era, including miner and storage-market actor behavior relevant to sector lifecycle and deal handling. Teams analyzing SnapDeals should inspect the actor code and tests around sector updates, deal activation, and state transitions rather than relying only on summary material. This is especially important for providers, indexers, exchanges, and risk teams that need to understand how existing committed-capacity sectors became eligible for data-bearing deal updates.

The Lotus repository is useful for tracing how the protocol change was exposed through node, miner, sealing, and storage-provider workflows. Operators should use it to review historical issues, pull requests, tests, and command behavior connected to SnapDeals adoption. This helps identify whether an operational problem is caused by protocol rules, Lotus implementation behavior, sealing-pipeline configuration, or provider automation. Teams maintaining custom deal-making software should compare their assumptions against upstream Lotus behavior before enabling or modifying SnapDeals-related flows.

The official Filecoin documentation should be used as the starting point for current storage-provider concepts, deal-making terminology, and operational context. Because documentation pages evolve, teams reviewing Network Version 15 should not assume that current docs exactly describe the historical OhSnap activation state. Use the docs for current terminology and onboarding concepts, then verify historical protocol details in the FIPs, Lotus release notes, and actor repositories before making production decisions or building compatibility checks.