Deprecate FIL+ and Fund Services via Block Reward Split

[irenegia]

The Problem

Any decentralised storage network needs incentives to solve a common challenge: convincing independent operators to store other people's data. In particular, incentives are needed to bootstrap supply, to be price-competitive relative to centralised solutions, and to maintain consensus security. On top of these motivations, Filecoin needs incentives to support evolving from a storage-capacity blockchain into a service economy centered on onchain storage services.

Currently, Filecoin addresses all of these needs with a single system: Filecoin Plus (FIL+). FIL+ worked well to accumulate supply and lower storage price, but has shown clear limitations. The core problem is well-documented in Discussion #1176: you cannot programmatically detect "useful data." FIL+ tried to solve this with human review root key holders, allocators, and compliance checks. The result is a system that is slow, hard to scale, and vulnerable to gaming. Today, FIL+ activity is not guaranteed to reflect real client demand, some deals may be genuine, but the system has no mechanism to ensure they are. Moreover, as already noted in Discussion #844 SPs who want to compete for block rewards through consensus mining are locked out by datacap gatekeeping, posing network growth and therefore consensus security at risk.

For these reasons, we believe that we need a replacement of FIL+ that can meet all the needs of Filecoin as a blockchain AND service economy.

Could we just remove FIL+ and let the market work? That would free consensus mining, and block rewards could still act as an indirect subsidy for competitiveness. But we would lose any protocol-level tool to support the transition to a service economy. Client payments are still too small relative to the cost gap between storing real data and pure mining; without a protocol premium, rational SPs will choose mining over service. And beyond economics, this is about network identity: Filecoin is not simply a consensus chain that uses storage, it is also a storage service network.

The Proposed Solution

We propose replacing FIL+ with a simple, explicit mechanism:

1. Deprecate datacap. Give all new sectors 10x QAP automatically. All new sectors automatically get 10x QAP regardless of content. No datacap needed. The gatekeeping that has blocked new entrants is removed entirely. Deprecation is going to be gradual: no new datacap minted, but the existing datacap can still be used (ie, allocated) until natural expiration.

2. Block reward split. At every epoch, a fraction α of the block reward goes to a new Service Rewards Actor (an FEVM smart contract). The rest (1−α) goes to the miner actor as consensus reward, same as today. This cleanly separates consensus incentives from service incentives.

3. Initial parameters:

• α starts at 10%:
  • Why 10%? We think this is an optimal initial balance between generating meaningful share for the service incentives (at α = 10%, the service rewards share is ~6,700 FIL per day, roughly a subsidy of $2.5M/year at $1/FIL) and not negatively impacting SP financial viability. To put it in concrete terms: for 10 TiB of QAP, the service incentives share at α = 10% is ~0.0035 FIL, which is comparable to what SPs already pay implicitly through datacap cost ( 5 FIL/TiB amortized over 5 years ~ ~0.0025 FIL/day). Furthermore, if, as result of this proposal, the service economy and the network grow, the resulting higher network value benefits all participants including consensus SPs.
• Then, gated step-up to 40% max: α increases by 10 percentage points every 12 months, but each step only activates if a security gate confirms consensus health.
  • The gate is a small multisig (same model as FIP-0099/F3) that can only pause, not increase or change the schedule.
  • The N signers will be representatives of the core Filecoin development community: implementation teams (e.g., Lotus, Forest, Curio) and security experts. Each step-up activates automatically at the scheduled epoch. If the signers determine that the consensus layer cannot safely absorb a further reduction in its reward share, they submit a single multisig transaction that delays the next step-up by 12 months.
  • Why the step up? We propose to gradually increase the service incentive share beyond the initial 10% for two reasons:
    • Economic Rationale: To align the subsidy budget with the growth of the service economy, providing increasing funds for onboarding new clients (POCs/discounts) and service-related investments.
    • Identity Rationale: To confirm Filecoin's long-term commitment as a service network, signalling that this direction is structural and not merely a bootstrap experiment, which builds confidence for ecosystem participants.
  • Why a cap at 40%?
    • First, having a cap is necessary as a secondary security measure, given the critical role of the consensus incentives in the L1 consensus secure with the current consensus protocol. While a cap could be avoided by leaving control entirely to the gate mechanism, we believe this safeguard is essential for safely implementing the proposed change now.
    • Second, the 40% value is a deliberate trade-off. Determining the exact consensus floor analytically is challenging because it relies on uncertain future factors, such as network size and, more significantly, the volatile FIL price. Past attempts, like estimating network growth for baseline minting, have been unsuccessful. So our practical approach here is to propose a trade off that aims to be ambitious enough to signal long-term commitment to service incentives, conservative enough to protect network security. This parameter can be easily adjusted by a future FIP if network conditions require it.
      • While we considered a more complex, dynamically adjusting system (eg, such as a "datcap auction" where the market influences the split) we opted for a simpler, quickly shippable solution. We prioritize timely deployment and simplicity over a theoretically "perfect" but overly complex design, given the network's current state.

As already noted in Discussion #1238 (Daybreak), this proposal builds on years of community discussion about FIL+ reform. See there for a comprehensive recap.

What Changes for SPs

For all SPs: an immediate 10% reduction in direct block reward income, applied universally from the activation epoch.

• No more datacap applications, allocator dependencies, or compliance overhead. Every sector gets 10x. The gatekeeping is removed entirely.
• SPs who serve clients can earn back the reduction through deal payments for services subsidized by the service reward actor.
• SPs who primarily provide consensus security continue earning 60-90% of block rewards. Mining remains a valid mode.

Service Rewards Allocation: An Open Design Question

The Service Rewards Actor collects funds, but those funds need to flow to the entities that actually connect clients with storage providers. We call these service operators teams that run smart contracts implementing storage services on top of the Filecoin network. Examples include the recently shipped Filecoin Warm Storage Service and services within Filecoin Onchain Cloud. As more services launch, each implemented as its own smart contract, the allocation mechanism needs to work across different service types.

There are two levels to the allocation design: (1) how service reward funds flow from the FEVM actor to service operators, and (2) how each service operator deploys those funds internally (e.g., as deal subsidies flowing to SPs). This proposal focuses on the first level; the second is specific to each service and out of scope here.

So our key design question here is: how should service reward funds be allocated across service operators? We are evaluating different directions:

Direction A: Committee grants. A trusted committee reviews quarterly applications from service operators and decides allocations. Simple to launch, but less scalable as it relies entirely on human judgment.

Direction B: Metrics-driven allocation. On-chain and off-chain metrics per service type produce a default allocation. A committee designs and certifies the allocation formula, and may adjust individual allocations within bounds. More automated and accountable, but requires careful metric design.

Direction C: Permissionless governance. Rather than a trusted committee, allocation is governed by a broader set of participants who stake tokens and vote on service operator performance, with mechanisms to incentivise truthful evaluation. More decentralised, but significantly more complex to design safely.

Direction D: Hybrid / phased. Start with a mix of A and B to get moving quickly, evolve toward C as the service economy matures and we learn what works.

We welcome feedback on the protocol design: the block reward split, initial parameters, step-up schedule, and security gate. On the service rewards allocation, we are working through these directions to better evaluate their pros and cons. We welcome initial inputs on this as well.

[Fatman13]

SPs who serve clients can earn back the reduction through deal payments for services subsidized by the service reward actor.

Isn't this just another form of fil+? Who gets to decide which miner is eligible for the subsidy? To quote from Rick and Morty, "this proposal sounds like fil+ with extra steps".