Dependencies between a selection of protocol changes related to storage utility and flexibility: reducing onboarding frictions, improving programmability, while maintaining safety and network revenue. Some proposals support or are required by some others.

This is not intending to be a complete list of protocol changes for consideration or prioritisation, just a view of some of them related to storage utility and safety.

graph TD
  DataPenalty -->|supports| TerminationFee[Simpler Termination Fees]
  DataPenalty[Data Termination Penalty] -->|required by| FreeCommD
  FreeCommD[Free CommD] -->|required by| DirectFIL+[Direct FIL+]
  FreeCommD -->|required by| ScalableFIL+[Scalable FIL+]
  FreeCommD -->|required by| DataApps

  CommDOnChain[CommD On Chain] -->|supports| DataApps[Data Applications]
  SyncActivation[Sync Activation] -->|required by| SectorEvents[Sector Events]
  SectorEvents  -->|supports| DataApps

  StorageFees[Storage Fees] -->|required by| GasLanes[Pseudo Gas Lanes]

Outcomes

Change Direct beneficiaries Impact Work
Data termination penalty SPs, Clients, Core Devs Low (but a pre-req) Low
Simpler termination fees SPs, Core Devs Med Low/Med
Free CommD SPs, Clients, FVM Devs, Core Devs Med/High Med/High
Direct FIL+ SPs, Clients High/med Med
Scalable FIL+ SPs, Clients High/med Med
CommD on chain FVM Devs Med long term Low
Synchronous activation Safety Med short and long term Low
Sector events FVM Devs Med long term Med
Data applications FVM Devs High long term Low
Proof fees Holders, Core Devs High long term Med/High
Pseudo gas lanes SPs, Clients (indirect) High Med

At best guess, none of these are super complicated changes, but they haven’t been designed in detail yet. Dragons may lurk.

Because miner API change is costly, we might try to make one API change that supports all the planed improvements at once, then deliver functionality incrementally.