Toward a Service-Centered Filecoin Economy: Aligning Protocol Subsidies with Onchain Utility

[jennijuju]

I am hoping to open a discussion around a new model for Filecoin that rewards onchain paid services with protocol incentives, making Filecoin more useful, scalable, and economically aligned.

This work is largely in collaboration with @steven004 and @rvagg; and thanks to design feedback and inputs from other FilOz members, @Schwartz10 and @jnthnvctr.

Background & Current State

• Filecoin’s block rewards are allocated to storage power.
• There is an incentive system on Filecoin, namely FIL+ that awards “DataCap” (subsidy) to clients and Storage Providers (SPs) who claim to store “useful data” to gain more storage power on top of the raw capacity they provided the network.
• There have been ongoing challenges and liabilities with FIL+ program:
  • "Useful Data" is Hard to Define Programmatically: There is no robust programmatic way to reliably identify “useful data” on the network. As a result:
    • Many deals are for "fake" or low-usefulness data, simply to capture rewards.
    • Gaming and loopholes are hard to close without human review.
    • The protocol sees lots of FIL+ activity, but it’s hard to measure or prove that real value is being stored or served, and the Filecoin network itself does not reliably accrue value from this process.
    • In addition, it is being an imperfect signal discounts the legitimate activity that is intermingled. if the network has 100 PiB of questionable activity, people will round down to 0 useful activity- even if its like 50/50 in terms of utility
  • Too Much Human in the Loop: Manual approvals and decision-making are required for DataCap allocation, governance, and dispute resolution. Consequence:
    • Ecosystem resources spent on governance, politicals and social engineering.
    • Bottlenecks and delays in onboarding new clients and datasets.
    • DataCap allocations are subject to committee or review-board processes.
  • Slow Process With Permission Overhead: every significant move, allocating DataCap, approving new clients, handling exception, requires human review or special permissions. Rather than building good tools to enable seamless onboarding, more resources are spending on manual checking. Consequence:
    • Slows down onboarding of real data and useful service providers.
    • Makes the system less scalable and less automated than ideal for a global, permissionless network.
  • Service providers and clients are frustrated by inconsistent rules, fairness and unpredictable timelines.

Known Factors & Pain Points TL;DR:

1. Current payment & incentives are not protocol-native:
   • Many service exchanges and rewards occur off-chain or with minimal or no value accruing to the protocol.
   • There is more export of FIL value than import, driving significant inflation as FIL leaves the protocol ecosystem rather than cycling back in.
2. Subsidies (DataCap, etc.) lack transparent and robust ties to protocol economics:
   • "Useful" storage is subsidized, but in reality, marketplaces for DataCap have emerged, with DataCap typically trading for 1–3 FIL per TiB in private/offline deals - no matter it is useful storage or not.
   • This undermines the intended incentive structure and makes it harder to tie actual value to protocol/subsidy flows.
3. Enforcement and eligibility are overly manual and non-programmatic:
   • Existing proposals and systems rely heavily on client reputation, subjective judgment, and manual review, rather than repeatable, automatable on-chain designs.
4. Consensus-driven service requirements do not always align with customer demand:
   • The protocol’s consensus mechanism (PoRep/sealing, wdpost, gas) mandates services that not all customers want to buy.
   • This imposes higher COGS (cost of goods sold) on SPs, especially from fiat-denominated Capex, making Filecoin storage less cost-competitive unless the customer’s needs align precisely with consensus requirements. When customer demand matches PoRep, miner costs and protocol subsidy are well-aligned; otherwise, they are not.
5. Risk aversion in the SP community makes high-quality, high-risk services hard to launch:
   • Many miners/SPs seek the minimum economic risk for the maximum gain, making them resistant to adopting services involving greater exposure (e.g., more capital locked, stricter legal liability, or higher transparency).
   • This “risk minimization” mindset is a barrier to transitioning a large portion of SPs toward being reliable, high-SLA service providers, since they may be unwilling to assume new risks unless clearly rewarded.

Goals

• Align incentives for all ecosystem actors (clients, SPs, markets) around on-chain, verifiable, service provision.
• Enable Filecoin protocol ARR: Ensure the network itself accrues value from its use, not just SPs or off-chain actors.
• Reduce friction and encourage healthy, dynamic and rational market behaviors for data storage, data retrieval, and other Filecoin services.

---

Proposal: Linking Filecoin Subsidies to Onchain-Paid Useful Services/Utilities

The Core Idea:

All Filecoin services, delivered through programmable markets, are paid via a core on-chain Filecoin payment actor, enabling clients to define utility by paying with FIL.

• Any actor (market, SP, portal, etc.) that wishes to collect payment for Filecoin-based services should do so through the Filecoin payment actor. Each service or market can establish its own “rail” within the payment actor, lightweight payment channels between clients and service providers, governed by programmable logic.
  • These rails should be gated by proof of service, ensuring quality through service-level objectives (SLA/SLI). All interactions are validated programmatically and automated.
  • ✳ Rail: a lightweight payment channel between a client and service, with configurable service terms.
• The protocol charges a flat fee per settlement, where the fee is based on network factors such as block rewards and storage power.
  • ✳ Settlement: the distribution of FIL accrued in a payment rail up to a given epoch, typically triggered by one of the parties involved.
• Incentive alignment: For every X FIL burned during settlement, Y DataCap is minted to the settler’s wallet. This creates a subsidy mechanism tied directly to paid, on-chain service activity.
  • Only services paid and settled using the Filecoin payment actor are eligible for minting, ensuring that DataCap and network incentives reflect actual, onchain verified network utility.
  • ✳ Settlers may include the payer (e.g. end-user, dApp, or on-ramp); the payee (e.g. SP or service/market managing SLA); or the operator (e.g. intermediary service or programmable layer).

---

🔧 Implementation Updates:

• ICYMI, wanna learn more about Filecoin’s evolution toward programmable services and markets, and how we’re expanding beyond just PoRep-based storage? Watch this FDS-6 talk to learn more about the direction and opportunities ahead: Watch here
• The Filecoin Payment Actor is live on the Calibration testnet and scheduled for mainnet deployment in late July or early August, following audit completion.
• A programmable storage service is also in development, with end-to-end PDP-backed storage, CDN gateway retrieval, and full integration into the payment actor. Repo: filecoin-services.
• Builders can test upload and retrieval flows using the Filecoin Synapse SDK. Feedback and feature requests are encouraged!
• SPs can spin up PDP nodes and begin offering verifiable storage services in under 30 minutes
  👉 Get Involved: Have questions or want to try it out? Join the community in #fil-services on Filecoin Slack!

Key Mechanics

• Flat fee per settlement: based on network conditions only and fair for everyone. Avoids SP collusion/gaming overhead with revenue reporting, as total payments can be split, bundled, etc., but each settlement burns the fee.
  • Letting market determine their own price/subsidy split below the flat fee ceiling.
• Burning links protocol utility directly to FIL: As more services are offered and used, more FIL is burned, effectively creating protocol-level ARR (Annual Recurring Revenue) through on-chain activity.
  • As a side effect, efforts to game DataCap translate directly into token burn, which can price out gaming behavior over time.
  • For a SP, service, dApp, onramp, or data market with real clients, the rational path is to work with clients contributing actual payments, rather than relying on CC/FIL+ porep sectors. Because DataCap maintains value, some negative pricing dynamics may still occur, but the cost of exploiting the system becomes explicit.
  • Most SPs have experienced extreme FIL price volatility over time. In this context, working with end-users or a market that offers a steady revenue stream (decoupled from block rewards) becomes an increasingly attractive and stable business path.
• DataCap/QAP only via the payment actor: Prevents off-chain or private markets from minting new DataCap and sidestepping protocol incentives.
• Open to all market structures: the protocol is market-neutral and open by design, services can be provided directly by storage providers, through programmable markets/services, via onramps, dapps, L2s, or through additional relayers, all utilizing the Filecoin Payment Actor. Settlement is informed by service quality, which is natively supported by the payment actor. Each service defines its own proof-of-service requirements to assure and demonstrate quality for every transaction. (”Quality” and “proof” in custom market structures are not externally audited but are left up to the market to define and implement, but are encouraged by the payment actor design.)
• Fork-resistance: To avoid losing protocol revenue to forks or copycat contracts, DataCap minting and network subsidy will be tightly bound to the core, audited payment actor; only on-chain settlements through this actor will mint new DataCap and confer Filecoin incentives.
• Simplifies the L1 protocol: This removes the need for the root key holders’ multisig (f080), eliminates human-in-the-loop processes (no more permissions and manual gating), and makes the protocol less permissioned and more automated by default.

What This Addresses / Why Now

• Aligns protocol success with real service demand: When Filecoin storage, retrieval or other service is used, the protocol benefits, not just miners or service intermediaries.
• Prevents DataCap/Dark Market leakages: No more under-the-table deals or "free riding", everyone (SP, onramps/markets) who wants DataCap for chain subsidy must pay the fee, ensuring at minimum some protocol revenue (via FIL burn), and stronger alignment between network activity (service settlement) and protocol benefit.
• Simple, future-proof, fair: Flat fee is harder to game than percentage systems (which miners can collude to minimize), and easier to reason about than volume/oracle-based models.
• Upgrade path off FIL+: By making DataCap/QAP minting exclusive to the Filecoin payment actor, "rogue" allocators and RKH fade out over time, taking human out of the loop, and naturally converging the market on this canonical path.
• Enables protocol-level innovation: Dynamic fee schedule, permissionless markets, and additional service types (retrieval, CDN, compute) can be deployed on the same rails.
• Encourages on-chain value transfers: For any payment flow that happens offchain today, either between client to SP, client to onramp, onramp to SP; there is an additional incentive to put the payment onchain and the payee needs to buy FIL for burning.
• Strengthens the Filecoin network effect and ecosystem value loop: People are drawn to Filecoin for its decentralized, content-addressable, and verifiable storage technology and global cloud resources. By requiring that all applications, onramps, and L2s seeking network subsidies via Filecoin services settle payments on-chain with FIL burnt to the protocol, every participant directly contributes to the Filecoin economy. This design not only increases demand for FIL and ensures participants have real “skin in the game,” but also means that new ecosystem growth reinforces and sustains the protocol itself, creating a healthy, self-supporting network effect.

📆 Roadmap

1. Short Term (by September 2025 — MVP for experimentation and iteration):
   • Launch the Filecoin Payment Actor with a flat protocol fee per service settlement.
     • The Filecoin Payment Actor is developed and currently undergoing auditing.
   • Integrate one or more programmable services/markets with the Filecoin Payment Actor.
     • A storage service (backed by PDP) with a CDN gateway for retrieval and integrated SDK is actively in development. A working MVP is already deployed on Calibration.
   • Implement an allocator that distributes DataCap based on FIL burned via the Payment Actor, and actively iterate on the mechanism.
   • Continue protocol and research exploration to ensure robustness and identify any potential security vulnerabilities.
2. Medium Term (by End of Year 2025):
   • Transition from a flat fee to a dynamic fee model that adjusts based on network conditions (e.g. block rewards, total storage power).
   • If the experiment proves successful and the model gains community consensus:
     • Propose an FIP to replace the current RKH multisig with the Filecoin Payment Actor as the primary DataCap minter.
     • The Payment Actor would automatically mint and allocate DataCap through the rewardDatacapOnSettlement function, based on on-chain traceable settlement for service exchanges.
   • Begin phasing out independent DataCap allocators.
3. Long Term (Q1 2026):
   • If the related FIP is accepted, include it in a scheduled Filecoin network upgrade.

✳️ Note: Phases 2 & 3 are subject to change based on experiment results and community feedback.

Strategic Benefits

• Creates real, recurring protocol value from actual network use.
• Simplifies and unifies provider and market incentives.
• Prevents incentive gaming - fair to all actors, open and permissionless, but hard to fork away protocol revenue.
• Flexible road to sunset Fil+ and off-chain workaround markets, attracting more organic demand and innovation to the Filecoin L1.

---

Let me guess some FAQs..

Why use a flat (but dynamic to network conditions) fee per settlement instead of a percentage-based fee on transaction volume?

There are several reasons, and they relate both to how Filecoin’s economy really works and to ensuring a fair, robust protocol-level incentive structure:

• Harder to Manipulate & Fair to All: Flat fees prevent actors from gaming the system through under-reporting, transaction splitting, or off-chain value transfer. Every provider pays the same protocol fee per delivered service, creating a level playing field for small and large participants alike.
• Economically Aligned with Filecoin’s Model: Filecoin’s core economy is about storage power and block rewards, not service transaction volume. Flat fees ensure every genuine service contributes to protocol revenue, even if part of the provider’s value is settled off-chain or through other credits.
• Simplicity, Predictability & Auditability: Flat fees based on BR and RBP are transparent and straightforward to automate, making it easy for everyone to understand, budget for, and audit protocol revenue, unlike complex volume-based systems.
• Sustainable & Adjustable: The network can dynamically tune the flat fee in response to changing conditions (block rewards, storage demand), ensuring ongoing sustainability without opening loopholes or incentivizing “race to the bottom” pricing.
• The Right Analogy:
  • Think of it less like a credit card “swipe” fee and more like a shopfront listing fee (e.g., Shopify): every provider pays a transparent, equal fee for entry and access to the protocol’s utility, no matter how much they transact.
  • or It’s more like a highway toll than a GST (goods and services tax) - you pay each time you access the network, not based on how much you haul.

Will this create wash trading?

Wash trading is a core risk for any system that rewards actors purely for on-chain activity. How this proposal addresses it:

• Yes, there still could be wash trading, however, the network will gain from:
  • FIL Burn Requirement: Every eligible settlement requires a real spend/burn of FIL, there is an intrinsic cost to “faking” trades (you have to actually destroy FIL). Burning FIL compounds also, the more FIL burnt, the more expensive to purely speculate and leads to higher incentive to have more focus on real utility.
  • Consensus security: Additional sectors onboarded to the network means additional security. The network benefits even from garbage sectors through increased security and pledge lock-up.
  • Smoother onboarding pipeline: Reducing DataCap-related barriers to onboarding also reduces friction of onboarding of non-garbage data.
• Economic Deterrence: If DataCap is priced such that burning FIL for QAP subsidy is only profitable for legitimate, market-driven demand (i.e., client pays FIL willingly for actual utility), then wash-trading becomes unprofitable.
  • Example: If 1 Datacap = 1 FIL in the market, but the protocol only gives you 0.9 DataCap per FIL burned, you lose money trying to “fake it”.
• Programmable Proof-of-Service**:** The structure of the Payments actor encourages the use of a proof-of-service gate (SLA/SLI, verifiers, oracles), wash trades for non-existent or low-quality service are either rejected or detected.
• As DataCap and QAP become more broadly distributed (i.e., as more SPs and power join the network), block rewards will make up a smaller portion of total income for storage providers. In this scenario, we expect the relative importance of real, on-chain client payments for services to grow over time. SPs that aim to thrive in the long run will likely seek additional income by competing to deliver better service or lower costs to paying clients, not just extract protocol subsidies. The protocol is designed, i.e: BR decreases over time, to support this shift toward more genuine, client-driven utility as healthy market demand grows.
• Adjustable Mint Rate: Protocol can dynamically tune the DataCap/FIL-burn ratio, making it more costly for non-genuine activity via FIPs (this should happen rarely)
• Governance + Monitoring: Ongoing monitoring and community/governance could further mitigate suspicious patterns and adjust rewards or penalties if abuses develop.

How does this prevent miner collusion?

Will miners collude (as they do today around minimum $ and work in return of QAP, etc.) to game the system, set prices/barriers to entry, minimize network fees/sealing, or coordinate DataCap issuance for maximum subsidy with minimal real service?

How this proposal address it:

• Flat Fee Model:
  • Because every settlement pays a flat fee (not a percentage of revenue/volume transacted), colluding to lower prices or “game volume” does not avoid the fee, protocol earns revenue each time.
  • The protocol sets a predictable, rule-based DataCap minting rate per FIL burned. Rather than reactively throttling, sustainability is enforced through economic equilibrium: if abuse arises, FIL cost of burn exceeds DataCap market value/BR FoFR, making manipulation unprofitable by design.
  • Flat fees are harder to manipulate via price-setting than percentage-based surcharges.
• Per-Settlement Cost:
  • Colluding actors can’t generate DataCap for free or at near-zero cost, since every on-chain mint burns FIL. The protocol controls the minimum cost of DataCap.
• Single Canonical Payment Contract (No Forks):
  • By ensuring only the protocol’s canonical contract can mint DataCap (no “fork and remove the fee” loopholes), it closes a typical avenue for collusive “side networks.”
• Open, Permissionless Markets:
  • The market is open for any actor to participate, making cartel formation and enforcement much more difficult compared to closed or “clubby” systems.

How to ensure the Filecoin network doesn’t revert back to a “committed capacity” network rather than a network with useful utility?

That’s an important concern. Here’s how I think about it:

• Filecoin is a blockchain network built around content-addressed, verifiable data and storage services.
• IPFS is a decentralized, peer-to-peer storage system. Filecoin, is created to be a crypto-powered storage network: it uses blockchain primitives to create programmable economic incentives for storage services, and a robust foundation for humanity’s information.
• As a blockchain network with native crypto assets, Filecoin’s security is derived from participant diversity and onboarding volume - the more hardware and collateral committed to the network, the greater the security for all participants.
• The protocol and incentives should be designed first and foremost to support Filecoin’s mission and utility as a storage network.
• Because of this, the Filecoin network shall naturally align with participants who are invested in the storage business. While some actors will inevitably participate primarily for block rewards, the underlying structure of the network tends to attract service providers aiming to build sustainable revenue through storage and related infrastructure services.
• PoRep sectors provide fundamental security and form the backbone of data durability on Filecoin - but they are only part of the story.
• With emerging mechanisms like Proof of Data Possession (PDP) and new market built around it, Filecoin SPs can offer new content-addressed, verifiable storage and retrieval services. These services deliver real utility to users and can be programmatically validated on-chain.
• On top of that, Curio’s newly developed Snark Market introduces a novel category of Service Providers - Snark Providers who supply GPU compute power for proof generation. This allows Storage Providers to offset operational and capital costs, making service provision more efficient and scalable.
• Our broader goal is to expand the network’s definition of “useful service” beyond simply sealing PoRep sectors, supporting a more diverse, programmable, and verifiable ecosystem of storage-related utilities.
• Ultimately, the value of the Filecoin network should not be measured solely by whether sectors are “full,” but by how much genuine, user-facing data utility and service it enables.
• This transition keeps the protocol dynamic, rewarding aligned behavior and enabling Filecoin to support emerging markets and higher-value services.

[lanzafame]

Does USDFC count as FIL in the above scenarios?

[jennijuju]

i don’t quite understand your question tbh. It’s worth mentioning the protocol doesn’t care what currency one uses for payment.

[rvagg]

I think the answer is yes. "flat fee per settlement", where settlement settles whatever token, native or ERC20, is locked up in a payment rail.

[kernelogic]

There was discussion for allowing negative pricing on paid deals (SP pays Client). I think that can be easier to understand.

[steven004]

Thanks, @jennijuju , for tabling such a comprehensive proposal. I participated the discussion, and I’m firmly in support as it is an important step to 1) simplify Filecoin’s core, 2) fully automates the DC storage-onboarding workflow, and at the same time encourages the growth of user-defined service markets.

We’ve long discussed simplifying the core and automating the DataCap process; this is a practical blueprint to make it happen. An added benefit is that, as Layer-2 applications take off, the burn-and-mint mechanism will channel value back to the Filecoin base layer rather than diluting it — a tension Ethereum still wrestles with in its own L2 ecosystem.

[Fatman13]

What will happen to fil+ if this were to be passed?

[beck-8]

@gitgavinzhao f099

[Fatman13]

FIP03 规则定的很细，公证人等等。FIDL 团队 Galen? 直接把他改成 allocator 好像也没有提对应更新的 FIP。

FIDL 团队在这个 FIP 之后会发生什么？

[martapiekarska]

Clarification, since I am the CEO of FIDL.

FIDL never changed the FIL+ to a model with allocators. As a matter of fact - FIDL was launched on March 8th 2024, and Galen was presenting the allocator model during Devconnect in Istanbul in November 2023. I didn't even join Protocol Labs until January 2024.

[martapiekarska]

As far as I understand, the allocator model did not need a FIP as it did not change the core of Fil+ and FIP003. The Allocators play exactly the same role as Notaries. From the FIP:

The primary goal of this proposal is to describe different layers of institutional governance, establish the Principles of the program that all other layers must follow and demonstrate, clarify interfaces between the program and the technical layer, and introduce a work-in-progress repository where more specific Mechanisms and Operations can be iterated on a more frequent basis. Future updates to the Principles and technical implementation should only be made with another FIP.

And the changes to the structure lays under the "Mechanisms and Operations ".

[Fatman13]

Any decisions regarding Filecoin Plus – from approval of Root Key Holders and Notaries, to DataCap allocation decisions, to governance changes – should be easily auditable by someone with no special privileges within the network, and take place within the framework set forth by community-driven governance.

The Filecoin community should collectively decide on the Principles, Mechanisms, Operations, and Markets that will govern the election, rotation, and actions of the Root Key Holders, Notaries, and Filecoin Plus Clients participating in this process.

Do we have an auditable trace that the community had collectively decided to switch from notary to allocator?

[beck-8]

Support this proposal. It's time to make a change.

[beck-8]

我用中文来尝试翻译总结一下几个关键点（如果不准确，我会继续修正此评论）

• 额度可直接链上购买
  • 根据网络情况动态调整单价（比如 1FIL/1TiB ）
  • 具体公式/实现后续补充
  • 费用直接销毁（转到f099）
• 逐步取消fil+公证人制度
• 未来借助PDP/可编程实现更多的可能性

[galen-mcandrew]

It would be great to get a full translation of the FIP, and the subsequent conversations back and forth. Don't want to lose the community feedback! @jennijuju @dannyob is there a way to manage this?

[dannyob]

Hmm. I see what you mean. Not sure how to do this for everyone -- I tend to just Google translate on the fly. We could set up a separate discussion in Chinese, but that would bifurcate the discussion.

I tend to machine translate when what I'm writing has obvious audiences in both major languages here, just to save time for readers.

I'd encourage everyone to include a translation when they're not posting in English, which (for good or bad) is our default here.

嗯。我明白你的意思。我不知道该如何让每个人都这么做——我倾向于随时用谷歌翻译。我们可以单独设立一个中文讨论区，但那样会把讨论分成两部分。

当我写的内容明显同时面向两种主要语言的读者时，我倾向于使用机器翻译，这样可以节省读者的时间。

我鼓励大家在不使用英文发帖时，也提供英文翻译，因为英文（无论好坏）是我们这里的默认设置。

[diogohavendp]

@jennijuju, and remaining contributors, thank you for putting this together.

As a disclaimer, I may be getting some concepts wrong (not technical here), but I wanted to clarify some high-level economic issues.

4. Consensus-driven service requirements do not always align with customer demand:

• what are customers demanding? Is there a report on real customer feedback that can be shared with the community? This is much needed for a broader informed discussion. If this is inferred by market observation I agree with you, but I just want to understand if there's a clear market feedback to make sure the community efforts are aligned and the roadmap tackles real customer feedback.

○ The protocol’s consensus mechanism (PoRep/sealing, wdpost, gas) mandates services that not all customers want to buy

• is it fair to conclude that the consensus mechanism is not aligned with the utility of Filecoin? If not, doesn't the consensus mechanism need to change? Assuming PDP volume will overcome PoRep (meaning, assuming clients pay for PDP, very few or nearly 0 clients pay for PoRep, making PoRep not economic viable for SPs), wouldn’t the consensus mechanism being tied to both PDP + PoRep make more sense? Meaning, SPs should lock FIL for both PDP + PoRep, hence reaching the target of having a decent (currently 30%) of circulating supply locked?

○ This imposes higher COGS (cost of goods sold) on SPs, especially from fiat-denominated Capex, making Filecoin storage less cost-competitive unless the customer’s needs align precisely with consensus requirements. When customer demand matches PoRep, miner costs and protocol subsidy are well-aligned; otherwise, they are not.

• following my last point, is it correct to conclude that given PoRep (the mechanism that brings security to the chain by locking more FIL via sealed sectors) is something real clients are not buying, is there a risk of Filecoin becoming a "thin" L1 with very low security?

Thank you all!

[jennijuju]

@diogohavendp

Thanks for these thoughtful questions and raising the need for more concrete discussion about Filecoin’s service-consensus alignment and real client demand. TL'DR: Id like us to evolve Filecoin's L1 to a place where there is an incentive to build unblock what users want in user land (on FVM) without waiting for protocol changes that takes a long cycle to develop, reduce friction and get SPs offering storage to clients like they’re supposed to.

re customer demand
I agree that we as a community could benefit from more systematic and visible reporting on real-world Filecoin client feedback and user needs. You can refer to some of the talks at recent FDS where those client facing teams/individuals sharing their insights (here. And from that you can hear the need beyond cold deep archival storage. I’d recommend a separate community discussion or ask CSWG to explicitly around sharing and updating “state of Filecoin client demand” with input from onramps, storage providers, and builders.

Filecoin’s consensus (PoRep, sealing, wdpost) is designed around cold, durable storage, and as such, is very efficient for deep archival use cases. However, as seen with onramps like Akave, Storacha, and most pinning/hot storage services, many users want hot or warm storage, rapid access, and more flexible payment/service models.

It’s important not to make this a binary: there is still some real client demand for consensus-focused (PoRep) storage, but it’s clear demand is much lower than supply, and that many modern use cases are not being fully addressed by “only PoRep.” And the supply in the network, SPs can also provide more services along with PoRep storage - and we should allow them to serve those market too.

re change consensus around services:
I would caution against regularly modifying blockchain consensus, as this impacts security and must be done with extreme care. PoSP via PoRep offers consensus security while offers an elegant, verifiable proof for archival storage, but the protocol should remain flexible enough to empower service innovation, allowing SPs and builders to address emerging client needs, regardless of consensus proof type.

It shouldn't be a protocol's job to rigidly define what storage markets should exist or force all services to conform to consensus requirements. Instead, we should enable a diversity of services (including, but not limited to, those directly secured by consensus) and subsidize growth where real demand appears. If eventually, usage patterns shift toward services like PDP or retrieval, the protocol should be able to recognize and reward those services programmatically, without being bottlenecked by the consensus mechanism alone. (i.e some BR/minining reserve may goes to those services, while consensus remain the same)

On Filecoin security risk:
While PoRep-based participation is a core part of Filecoin’s current security, the reality is that if client demand for PoRep-based storage continues to lag supply, participation and locked value may decrease over time. This is a security concern, and the best way to address it is to continually increase the network's utility - that is, support services and use cases that match what users actually want (beyond just PoRep). Otherwise, there is a risk of Filecoin trending toward lower participation and thus lower security as an L1.

[AxCortes]

I agree with the description of the current state, and the motivation for this FIP. I think this FIP is attempting to solve two problems at the same time:


1) The shortcomings of the FIL+ program. This requires large amount of human judgement that make it inefficient, and subject to fraud.




2) The desire to reformulate Filecoin from a PoRep based economy, to one based on a variety of storage related services.

I agree these are two reasonable goals, though they may not need to be solved at the same time.

CEL is also working on a solution to address 1), based on a programable FIL+ allocator (https://hackmd.io/@LV5J5dzWRk2EDJLTFgiyJA/H1jl7g3Slg), that achieves something similar to what is being proposed here: Datacap is allocated based on the amount of fee paid, which, through the inherent competition for a fixed datacap prize, serves as a proxy for the on chain deal revenue. We’ve written a comparison/contrast between this FIP proposal and the programmable FIL+ allocator (https://docs.google.com/document/d/1OE3uEEVU7rmvm9Kt96XiTvt8VylD2fEo8QHITMi0oeo/edit?usp=sharing).

Goal 2) is much more ambitious, and not addressed by CEL’s proposal. I think the core question is: Will rewarding settlers with datacap be enough of an incentive to convince all the service providers to use the native payment rails, and pay the corresponding fee?


To be convinced of this, I would need to see more specific details that are not provided here yet, like what the fee formula is, and how much data cap will be minted (if there are no longer root key holders, will we have an algorithmic Datacap minting curve in its place?) The details of this will determine whether goal 2) can be achieved or not.

[jennijuju]

@AxCortes

ICYMI, I want to highlight that I am also proposing we start with implementing an allocator as an initial step—before a full FIP, precisely to unblock experimentation, accelerate learnings, and enable rapid iteration.

📆 Roadmap
Short Term (by September 2025 — MVP for experimentation and iteration):

• Launch the Filecoin Payment Actor with a flat protocol fee per service settlement.
• The Filecoin Payment Actor is developed and currently undergoing auditing.
• Integrate one or more programmable services/markets with the Filecoin Payment Actor.
• A storage service (backed by PDP) with a CDN gateway for retrieval and integrated SDK is actively in development. A working MVP is already deployed on Calibration.
• Implement an allocator that distributes DataCap based on FIL burned via the Payment Actor, and actively iterate on the mechanism.
• Continue protocol and research exploration to ensure robustness and identify any potential security vulnerabilities.

I’ve looked at CEL’s allocator work in detail, discussed it at FDS-6 with Luca, and I agree with your analysis that our proposals are aligned on some key objectives - both move the system toward programmatic, FIL-based DataCap allocation, and away from the current human-in-the-loop bottlenecks.

Where our approaches differ (and why I see this proposal as a superset of what you’re doing) is scope and extensibility:

• CEL’s auction allocator builds an open market for SPs to “stake and burn” FIL for direct DataCap rewards, removing manual notaries and tying rewards to economic cost. If/when CEL integrates with the Payment Actor, this would make CEL one of the first “services” where SPs can participate directly and transparently.
• This proposal goes further, envisioning a system where not just SPs, but also service creators, markets, and onramps can opt to use on-chain native payment rails for any Filecoin services (PoRep, hot storage, retrieval, compute, etc.). The result is support for dynamic, client-oriented services, not only those suited for current sector-based or auctioned DC allocation for SPs only.
• In the short term, with the network dominated by PoRep SPs and BR-chasing SPs, a FIL-for-DC auction model makes sense. Longer term, as block rewards taper, onboarding scales, and new markets for hot/warm storage and retrieval emerge, real, paying client demand shall become a larger driver. Here, BR-chasing SPs and markets with w/service-focused SPs competing for those users is critical for ecosystem health, and the protocol should subsidize such value, not just SPs’ minimal compliance for block rewards.

Regarding your point about incentive formulas and DataCap minting: absolutely agreed. Iterating on the right allocation curve is essential (e.g., what the base fee is, how much DataCap is minted per FIL burned based on network condition). I hope we can see collaborative input from the CEL team as well in designing that.

To clarify, even if/when the Payment Actor becomes the canonical DataCap minter (replacing RKH), no market force is preventing off-chain deals or alternative payment paths. The difference is, network subsidies will flow only to those using the native rails and contribute to Filecoin's economy, so value flows directly back to the protocol and network participants.

they may not need to be solved at the same time.

I agree with this in principle. However, I strongly believe it’s essential for Filecoin to articulate and pursue a clear upgrade trajectory toward a more client-service-centered network, one where high-quality SPs thrive, rather than one dominated by BR-chasing SPs. To date, I haven’t seen alternative proposals addressing this long-term evolution. I see this proposal as a step toward bootstrapping storage markets and higher-value services, as well as lowering barriers for real builders. Rather than requiring them to navigate a lengthy FIL+ application process, we enable them to put a genuine stake in the network and receive protocol incentives that directly support their business growth.

[Schwartz10]

I'm generally in favor of this proposal. The flat fee and its value are crucial. I'd definitely want to see an economic analysis or forecast - we should be able to pretty accurately predict how much FIL will get burned.

Some thoughts:

• From what I understand, Filecoin mining economics favor sealing large amounts of data quickly. Sealing small chunks (e.g., via micropayments) is less profitable. This proposal could limit more flexible payment models if batch sealing significantly improves PoRep profitability.
• Miners will likely game the system - paying the burn fee just to mint DC -because it's the only way to maintain operations. I think that’s fine: they’re still purchasing storage. But pricing should reward those using the payment rails as intended over those bypassing them.
• It may be worth designing a fee model that incentivizes steady or recurring payments (e.g., micropayments) to offset mining inefficiencies. I’d check with teams talking to customers—I'd bet most legitimate deals follow predictable payment schedules. In that case, burning a large amount of FIL to mint DC upfront could cost more.

One final thought: requiring payment to mint DC means customers should ideally pay before data is sealed - is that right?. I.e. is it acceptable if a customer wants to delay payments (e.g., start payments in month 3 of a long term deal)? That would mean the SP can’t get DC for the first 3 months.

[jennijuju]

thanks for your thoughtful comments!

From what I understand, Filecoin mining economics favor sealing large amounts of data quickly. Sealing small chunks (e.g., via micropayments) is less profitable. This proposal could limit more flexible payment models if batch sealing significantly improves PoRep profitability.

The Payment Actor is designed to support a wide range of payment models - micropayments, subscriptions, batch payments, and more. Crucially, the way funds move from payer to payee (per epoch, per milestone, etc.) is independent from how and when settlements occur on-chain. In practice, this means clients can accumulate micropayments and storage providers can batch-settle these payments on-chain at their preferred cadence. The protocol enables batching to preserve PoRep sealing efficiencies while retaining flexibility in client-facing billing.

It's also important to recognize that Filecoin is architected to mediate storage deals, not to serve as a real-time (e.g., millisecond-level) micropayment railway. Most storage contracts have terms measured in days, weeks, or months. The Payment Actor is agnostic to contract duration and adapts to the actual service and deal terms negotiated off-chain.

I'd bet most legitimate deals follow predictable payment schedules. In that case, burning a large amount of FIL to mint DC upfront could cost more.

Payment schedules, whether predictable or flexible, are defined by the storage service or underlying market, not restricted by the protocol. The Payment Actor supports prepayment, pay-as-you-store, and deferred payment models.

Importantly, the protocol does not require that FIL be paid or settlements occur before sector onboarding. Rather, DataCap is minted only after an SP provides a service and processes a settlement (FIL burn), but that process can be adapted:

• For PoRep-style archival storage, SPs can acquire DC (for example, via a service or proposed market like CEL) before sealing to optimize QAP.
• For ongoing or dynamic services, settlements can follow actual payment flows and client preferences. A provider could, for instance, onboard client data now and receive DataCap later when settlement occurs, either when the customer pays or when the SP chooses to accumulate and then settle payments.

The mega-point: Let the market and participants define what works best for their use cases, and build a protocol that can support and automate those flows programmatically.

It also seems like you are focus on PoRep (f05) services, and think thats the only services SP can offer and users care about.

As mentioned, we are intentionally designing for much more flexible, usage-driven service models and empowering more builders and service creators to do the same. New offerings, such as PDP-backed hot/warm storage with integrated retrieval gateways, are tailored to meet diverse and evolving client needs. For example, as noted by teams like IA and onramps such as Akave and Storacha, many users want to start with a hot storage tier, then selectively archive data as needed. With the new Payment Actor and flexible service rails, Filecoin can now support these dynamic storage market models, enabling solutions that serve a wider range of use cases and client preferences.

Additional thoughts on ecosystem alignment:

This system also helps Filecoin sustainably support public good datasets. In today's FIL+ model, large DataCap grants are allocated up front, often funded by broad network inflation (i.e FF grants). Going forward, DAOs or public data projects will be able to fundraise and pay the protocol (via the Payment Actor) in exchange for DataCap and storage subsidies, shifting costs from the protocol as a whole to those specifically supporting the public good. This is healthier for long-term sustainability.

[maybeLn]

冒泡支持，人工分配效率太低了，还是这提案好，挂钩真实数据自动分配datacap等相关要求，但社区需要快速给与信任与信仰，有一句话就是 牛市来了， 吃屎都赶不上热乎的，散户跑完了，就没多少人推广了，再好也会被市场淘汰，因为客户不买单啊，老百姓是被裹挟走的。老百姓不懂，只晓得 这应用好用，然后就用了，或者身边的人用的多，就一起用了。没发生问题到老百姓身上之前，都属于是小白什么都不懂。要想发展快，就得把这提案的好的快速实现，时间不等人，竞争对手也不会给你时间慢悠悠的混，要居安思危，快速迭代升级。

[dannyob]

Somewhat cruddy machine translation follows, just to save non-Chinese readers time:

"Bubble support, manual allocation is too inefficient, this proposal is better, linking to real data to automatically allocate datacap and other related requirements, but the community needs to quickly give trust and faith. There is a saying that when the bull market comes, you can't catch up with the hot shit. After retail investors run away, there will be few people to promote it. No matter how good it is, it will be eliminated by the market because customers don't pay for it. Ordinary people are swept away. Ordinary people don't understand, they only know that this application is easy to use, and then they use it, or people around them use it a lot, so they use it together. Before the problem happens to ordinary people, they are all white and don't know anything. If you want to develop quickly, you have to quickly implement the good of this proposal. Time waits for no one, and competitors will not give you time to slowly mix. You must be prepared for danger in times of peace and quickly iterate and upgrade."

[Chris00618]

As a SP from China, we OPPOSE this proposal for the following reasons:

1. After years of efforts, we have been able to obtain freely applied datacap. Why should we pay additional costs then?
2. The living environment for SPs is becoming increasingly difficult. Taking FIL from SPs' earnings to purchase datacap and then burn it will only accelerate our escaping from the FIL ecosystem.
3. Why not take out a corresponding proportion of FIL from the PL‘ holdings for burning?
4. Even if we follow the standard of 2 FIL per TiB to purchase datacap and burn it, only about 2000-3000 FIL will be burned every day. This will far from help much in stimulating the currency price; on the contrary, its bad effects will be extremely significant.

我们作为一家来自中国的SP，明确反对这个提议，基于以下几个原因：
1、经过多年的努力，我们已经可以获得免费申请的datacap,为什么还要支付额外的成本；
2、SP的生存环境越来越难，从SP的收益中拿出fil来购买datacap并销毁，只会让我们加速退出fil的生态。
3、为什么不从协议实验室的持仓里，拿出对应比例的fil进行销毁？
4、即使按照2fil/T的标准来购买datacap并销毁，每天也只销毁2000-3000个fil左右，远远不会对刺激币价有太多的帮助，相反，它的副作用会极大。

[beck-8]

只是好奇。。。
你为啥这两天把 allocator 藏起来了

[gitgavinzhao]

This is just a solution to legalize corruption, which is essentially to burn SP's FIL tokens with the help of Datacap. "Useful data" has become a big joke. If FIL needs to be burned to save the ecosystem, FF/PL must burn in the same proportion. Please don't treat SP as a fool.

[luca-nik]

Thanks @jennijuju for this proposal. I agree with you and @AxCortes that AutoCap (https://hackmd.io/@LV5J5dzWRk2EDJLTFgiyJA/H1jl7g3Slg, https://github.com/CELtd/filplus-autocap) and this FIP are aligned on some key objectives. In fact, AutoCap can work hand-in-hand with it. #1176 calls for an algorithm to set a dynamic network wide fee and AutoCap provides an instance of such an algorithm that aims to achieve the same set of objectives.

It is true that #1176 goes further in advocating for making such an algorithm part of L1 implementation. Happy to see that but there will likely be more considerations.
For example, if people can permissionlessly and programmatically get DataCap, it is unclear what the resale price of DataCap will be. It is also unclear if the main use of DataCap is to earn block reward, how much real impact it may create on Filecoin economy.

AutoCap would like to experiment with algorithmic approaches via an Allocator first that could help inform and support a potential #1176 implementation. If it turns out to be successful, the community can decide that such an Allocator is the only Allocator and then it achieves what #1176 wants to achieve - effectively the algorithm in the Allocator is part of the L1.

AutoCap can be an opportunity to contribute to the Filecoin ecosystem by providing a practical testing ground for ideas that may shape how #1176 evolves while remaining very cautious of making L1 changes that may affect many existing participants.

[martapiekarska]

Thank you everyone for a really helpful conversation, I’m glad to see two strong proposals for experimentation around encouraging on-chain paid deals. FIDL’s role is to apply a analyse-propose-enable-measure framework: we look at the state of the incentive model, we propose changes that we think can further align the participants with what is good for the network, we build tooling (when needed) to enable the change and then dashboards for measuring how did the change impact the behaviour of the participants.

In our role we have proposed and enabled a lot of new pathways to align the participants with the network:

• Looking at retrievability for open datasets
• Moving to smart contract client allocations to allow easy removal of DC and tying deals to SPs
• Building smart contract based meta allocators, to ensure smoother flow of Datacap.
• Building faucet for small dc allocations for testing.
• Enabling experimentation with experimental pathway metaallocator
• Encouraging diversity of the clients and SPs to strengthen the network
• Recently, building strong checks on public open datasets to ensure they are indeed available to public to use
• Detecting and preventing onboarding duplicate datasets,
• Verifying the preparation of datasets
• Tracking the usage of old Datacap and enabling removal of unused Datacap to ensure all of the Datacap is allocated to active deals
• And some more
  Another thing that we have been advocating for was verification of proofs of payment for enterprise deals, but until now other than manual checks we had no way to actually verify it. So this proposal, as well as the one coming from CEL are very encouraging 💪

I like, that you are proposing it in milestones and with several guardrails to ensure that, if this turns out to be easily gamable, we will have ways to stop Datacap leakage. As with many things, I will opt for crawling before walking and all that. I think seeing what you are thinking long term is useful, and I think any large decisions about removing all humans from the loop will only be possible when the automation part gets properly defined and tested.

Lastly, I would like to make sure that:

• the success criteria for this allocator become clear: purely having a usage based success metric won’t tell us if this allocation pathway is contributing to Filecoin’s long term health.
• The evaluation of the experiment is not only wrt the generated on chain payments but also the other aspects that are important for longevity of Filecoin (FIDL is considering proposing a scorecard that evaluates an allocator for each metric between -3 and 3: where -3 is “actively deterring from this” 0 is “neither nor” and 3 is “hugely incentivises this” )
• Open datasets incentives are still present and strong. I don’t think that having a payment based Datacap allocation for big open datasets will work. Here we need to ensure that they are retrievable, usable and used.

[dannyob]

(One reply deleted: It wasn't terrible or a secret (it was @gitgavinzhao saying that the last five years have been in vain), but let's try and keep the conversation substantive and on-topic here.)

[dannyob]

An element I like of this proposal is that it includes a iterative, reversible, path to acceptance that allow us to test its assertions. For instance, I'm not entirely convinced that this won't just move the fraud challenges of Fil+ to another set of techniques, which would mean one of its advantages -- escaping from a human-driven, proces -- would end up being overlaid on top of it as it tries to combat misincentivized behaviour. But if we do a progressive roll-out, we can test for that, at least to a certain extent.

I wonder if there's a smaller step we can take, beyond even creating a new unbounded allocator. One suggestion kicking around the CEL proposal was to simply allocate a chunk of datacap for this project, and see what happens if that is allocated under the proposals rules. Could we do this here also?

[martapiekarska]

I think this is better in the way that Jenny is proposing to run it as an Experimental/regular allocator, meaning it would get a bound and limited DC (1 or 5 PiBs respectively), wheras the CEL one wanted a very big allocation from the get-go

[songyongren]

Support the proposal, current datacap acquisition discourages many new SPs from trading in the black market!

[haheihou5]

拒绝任何付费的dc！付费给公证人，来购买dc额度，是中心化的，非常荒谬的行为！

[wdh365]

It’s time for a transformation, otherwise the project may head toward failure. The system needs to become fair, and only with more SPs participating can there be hope.

[maybeLn]

当下的问题就是，散户社区没得信任，观察x的官方媒体，基本上浏览量很少，粉丝增长停滞，项目所谓的生态使用人很少，整个项目进入了螺旋式的抛压，项目方真的该有点作为了，一点担当都没，只顾着埋头做所谓的技术，投资人散户社区，都已经快死了，社区有活力？？活动有热度？飞机上的各种相关的filecoin群死气沉沉，sp在不断的跑路减少，开个会，人数少，线上线下都是人数少。不给散户希望，社区都在劝人离开fil，谈未来理想的被喷的都不想吭声了。就连传销都觉得传销fil没用，因为没信任，新闻负面消息，价格，给人看到的都是低能量无用的东西。一个提案，让官方销毁币，总量减少，先把当前难关度过，创始团队太清高，清高的来让散户觉得，散户就是SB，用来被收割的。没得粘度，也没信任。

[haheihou5]

这个提案还是想割矿工，让矿工付费买dc,只是从付费给公证人，变成了燃烧掉买dc的费用，烧掉矿工手上的筹码，变成算力，他们以后更好出货

[lyjmry]

I suggest simply canceling FIL+ and the tenfold reward. This will encourage SPs to seek out more revenue, and they will find commercial data clients on their own. I also hope to find ways to address algorithmic issues and ensure network security while enabling rapid retrieval and decapsulation of data within sectors.

[lyjmry]

Or you don’t even need to think of a solution, because SP will solve the customer’s needs on its own

I really don't understand why a decentralized project needs too much human intervention.

[lyjmry]

10x computing power is simply the biggest attack on the network, using twice the hardware to deceive the network to get 10x computing power

[brian75235]

First thing first, FIDL and FIL+ have to be ended. They are going CRAZY. Why forcing SP's to use smart contract and DDO to onboard DC data? What on earth does this add to the network, except adding more burden to the SP's, who are already struggling? @jennijuju

[haheihou5]

拒绝任何付费的dc！付费给公证人，来购买dc额度，是中心化的，非常荒谬的行为！

[martapiekarska]

@brian75235 I believe that was a reaction to a situation that is being addressed on slack, but just wanted to close out the loop. There was a misunderstanding in terms of DDO enforcement, FIDL took into account the community feedback and we are reworking the Smart Contract tooling to enable all types of deals. There are strong reasons to use Smart Contract for DC allocation including better control over the datacap from allocators and clients.

[brian75235]

@brian75235 I believe that was a reaction to a situation that is being addressed on slack, but just wanted to close out the loop. There was a misunderstanding in terms of DDO enforcement, FIDL took into account the community feedback and we are reworking the Smart Contract tooling to enable all types of deals. There are strong reasons to use Smart Contract for DC allocation including better control over the datacap from allocators and clients.

When you say "misunderstanding", would you mind clarifying who and who misunderstood what?
Wasn't it true that Smart Contract allocation means the SP's MUST use DDO to seal? And has this situation changed in any way already?

I do NOT deny that there are a lot of advantages of using Smart Contract for DC, but when and only when it is ready and not forcing anybody to do anything within the protocol. In other words, forcing SP's to use DDO just to use this not-ready tool is BREAKING FILECOIN PROTOCOL!

[N314159robort]

那些base在欧美的sp们，你们愿意接受了无端的”扇区税“后，还交“dc税”吗？
欧美的sp不需要通过“黑市”获得dc呢。
哦，难道欧美没有sp了吗？

For those SPs based in Europe and the US, are you willing to accept the unwarranted "sector tax" and then pay the "DC tax"?
European and US SPs don't need to obtain DCs through the ”black market“.
Oh, are there no SPs in Europe and the US anymore?

[N314159robort]

那些从sp端被销毁的FIL，如果从PL和FF的地址以同样的方式和比例去消耗，99%的SP和社区都会大力支持，并且快速推进。
哪个SP不是投了上千万，做企业的没有那么短视，每个团体都销毁同样的比例，是对项目长久有利，谁会不支持？？
只是不服每次被剥削的权益的都是这些SP罢了。

If the FIL slashed from SPs were consumed in the same manner and proportion from PL and FF addresses, 99% of SPs and the community would strongly support it and push the initiative forward quickly.
Which SP hasn’t invested tens of millions already? Businesses are not that short-sighted. If every group burned the same proportion, it would clearly benefit the long-term health of the project — who would object?
The dissatisfaction today comes only from the fact that it is always the SPs whose rights are being sacrificed.

[Fatman13]

Short Term (by September 2025 — MVP for experimentation and iteration):

Do we have a MVP ready?

[MikeH1999]

@jennijuju Is there any new information here?

[sviperj]

I don’t understand how a proposal can be discussed for so long without reaching a conclusion. Shouldn’t there be someone in charge to speak up or hold a vote? Is this what you call team efficiency? Labs and the official teams—are you this lazy and decadent in your everyday lives too? No wonder the FIL project has no future. It perfectly reflects you fat cats who draw big dreams, brag endlessly, and do nothing while collecting salaries.🙄

[dannyob]

So I just want to note a few things here: firstly, one of the reasons why there's not as much response here is that the teams involved are heads-down working to ship code in a couple of weeks, and prep some concrete proposals for discussion and consensus at that event. I could call them all into this discussion, but tbh I think you'd want them to be working on the design, rather than answering each discussion here.

Second: This a fairly deep cryptoeconomic change, and involves a lot of cross-cutting groups. The whole roll-out is not giong to happen quickly, and it's not going to go by a vote (that's not how FIPs work, as you will know). What everyone's working on is a way to experiment with this without going through a FIP process, but that means designing an allocator, and that's where the bulk of the work is going at the moment.

Third: So, @sviperj I notice that you opened your github account just four days before posting this, and you have no other contributions.

Probably the best way of getting responses and feedback here is to keep the discussion collegiate and respectful: when people feel that they are just going to face insults, instead of constructive criticism and suggestions, the conversation moves elsewhere where they feel that is going to happen. I've talked to a bunch of people here in person, in DMs, and private zooms to better gauge their points of view, and inevitably you're all friendly, respectful and smart. It's not surprising that when the tone here is calling people "lazy and decadent", and where people create throwaway accounts, potentially to obfuscate how many opinions there are and who they are, the real discussion slips into DMs and private chats. If a forum fills up with drive-by comments, the forum grows more quiet -- even if those drive-by comments are complaining how quiet the forum is!

[brian75235]

When you say "misunderstanding", would you mind clarifying who and who misunderstood what? Wasn't it true that Smart Contract allocation means the SP's MUST use DDO to seal? And has this situation changed in any way already? I do NOT deny that there are a lot of advantages of using Smart Contract for DC, but when and only when it is ready and not forcing anybody to do anything within the protocol. In other words, doing so is BREAKING FILECOIN PROTOCOL!

…

On Tue, Oct 28, 2025 at 11:11 PM martapiekarska ***@***.***> wrote: @brian75235 <https://github.com/brian75235> I believe that was a reaction to a situation that is being addressed on slack, but just wanted to close out the loop. There was a misunderstanding in terms of DDO enforcement, FIDL took into account the community feedback and we are reworking the Smart Contract tooling to enable all types of deals. There are strong reasons to use Smart Contract for DC allocation including better control over the datacap from allocators and clients. — Reply to this email directly, view it on GitHub <#1176 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BB5CFNUHGGGPH6NX7FJMNLL3Z6BSBAVCNFSM6AAAAACBGFVWDGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOBQGUZTQMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dannyob]

This discussion as split into a few pieces, and (as I said upthread) some of the key participants are busy working on this and other projects to ship in time for FDS-7: so let me try and update everyone, as well as redirect to other sources of information and more relevant conversations.

What's the current status of this proposal?

A lot of the key advocates and proposed developers for this are concentrating on shipping FOC and related tooling right now. There is a funding request in from FilOz for a new Fil+ allocator that would be both practical incentive for FOC and onpaid deals in general, and also be effectively a proof of concept for some of the ideas here. You can read that and comment here. (I admit that it doesn't explicitl mention this proposal, but I personally feel like there's a lot of overlap -- @irenegia may be able to comment more).

Other related initiatives

The Crypto-economic Lab (CEL) mentioned their related proposal, and that was given a grant to research and implement in the last ProPGF round (ProPGF is Filecoin's new process for supporting large-scale infrastructure and research). This would also run as an experimental Fil+ DataCap allocator in its early stages. Both could either ramp up within Fil+ or move to a FIP, depending on how well they are doing.

Also worth keeping an eye on is Tom (from CEL's) proposal to experiment with a staked voting token for treasury management, and a new proto-FIP by Molly designed to incentivize onramps so that SPs don't have to carry the full burden of client discovery. These are in their earlier stages, and you're encouraged to reach out to Tom, or contribute to the separate FIP discussion.

I'd also note that @Reiers has also mentioned working on a proposal (sorry to out you, Nicklas!), the new governance team @Tanisha-fil and Michael Madoff are driving forward with FIP process reforms, and the FIDL team are working on both SLA-based allocators and a new enterprise and public data pathways. For Fil+ news3, I'd steer you to #fil-plus on Slack; for governance, #fil-gov

[haheihou5]

很抱歉作为矿工我曾在这个帖子发表了一些无意义的指责；
我思考之后决定支持这个提议；
dc费用可以给第三方，提供了带宽和分发的平台值得一些回报，但是公证人凭什么用额度来换取收入？（如果他造假的话）；
所以应该推动这个提议，这个方案的后续讨论在哪里？@jennijuju
或者您可以直接在这里回复我

数据导入是在线传输还是离线，再本地导入？
这套系统使用哪些现有的可用组件？（我的意思是指数据传输这一块，毕竟带宽很贵）
费率公式？
甚至乘数倍数是不是需要做出改变？
还给不给cc扇区竞争力？如果还给cc扇区竞争力，是给cc倍数，还是降低dc乘数？

[haheihou5]

让我们首先保证sp的数据流入过程 简单 顺畅；然后讨论降低他们的成本；至于公证人和dc数据的验证，毫无疑问需要一个自动化流程