Deprecate FIL+ and Fund Services via Block Reward Split #1249
irenegia
started this conversation in
Enhancements - Technical
Replies: 1 comment
-
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". |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
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.
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.
Beta Was this translation helpful? Give feedback.
All reactions