Mirrored from filpgf.io — ProPGF Batch 3 (Karma program 1479, application 6a31d897f2d3da25b237fc23, status: pending). Contact details redacted; canonical application lives on filpgf.io. 1.1 Project Name RailBurn: Service-Commission Burn Recipient for Filecoin Pay Rails 1.3 Project Website https://www.crackdevs.org 1.4 Team Lead/Point of Contact Ayomide Ojutalayo 1.5 Category [ "RFP 4 - FIL value accrual: burn and lock mechanisms" ] 1.6 Open Source Status Fully Open Source 2.1 Project Summary RailBurn is a Filecoin Pay-compatible service-commission burn recipient for routing configurable service/operator commission flow into FIL burn. Filecoin Pay already supports payment rails with commissionRateBps and serviceFeeRecipient; RailBurn uses that existing service-fee recipient surface rather than creating a new Filecoin protocol fee or modifying Filecoin Pay core contracts. A service operator can create a storage-style Filecoin Pay rail with RailBurn as the serviceFeeRecipient; when settlement credits operator commission, RailBurn harvests the available commission, accounts for the burn-eligible share, and routes it into a Filecoin-native auction where bidders burn FIL to claim accumulated stablecoin service fees. The project will ship RailBurnRecipient.sol, ServiceFeeBurnAuction.sol, DemoStorageRailOperator.sol, a minimal FilecoinPayV1 interface, tests, a Calibration deployment, a capped Filecoin mainnet beta, an economic model, a public dashboard, and an operator integration guide. The specific gap addressed is that Filecoin Pay operators can already charge service commissions, but there is no reusable public-good recipient that lets independent operators route a share of their own service-level commission into a transparent FIL burn path. This directly supports Filecoin’s shift toward paid onchain usage and stronger cryptoeconomics by making a portion of paid rail activity measurable and burn-linked. 2.2 Who does this work support? [ "Onramps", "Storage Providers", "Application Builders", "Application Users", "Network Infrastructure", "Network Governance", "Other" ] 2.3 Total Funding Requested (USD) 20000 2.4 Milestones & Budget [ { "title": "Mechanism spec, non-duplication map, and economic model", "description": "This milestone defines the RailBurn mechanism in detail and publishes the technical/economic basis for the implementation. The spec will identify Filecoin Pay’s commissionRateBps and serviceFeeRecipient fields as the integration surface, and it will explicitly explain why RailBurn does not duplicate Filecoin Pay’s built-in 0.5% network fee, Filecoin Pay’s existing burnForFees auction, FWSS payment rails, or FIP-0100’s protocol-level value-accrual mechanism.\n\nThe milestone will also include a conservative economic model for 10 bps, 25 bps, and 50 bps effective burn-rate scenarios. The model will not claim guaranteed adoption or immediate large FIL burn; it will show how service-commission burn scales if Filecoin Pay-compatible operators adopt the primitive.\n\n\n- Public GitHub repository\n- RailBurn mechanism specification\n- Non-duplication map covering:\n - Filecoin Pay 0.5% network fee\n - Filecoin Pay burnForFees auction\n - Filecoin Pay service/operator commission surface\n - FWSS dataset/payment rails\n - FIP-0100 protocol-level per-sector fee\n- Economic model for 10 bps, 25 bps, and 50 bps effective burn scenarios\n- Initial dashboard metric schema\n- Initial security and scope note", "dueDate": "2026-08-16", "fundingRequested": "4000", "completionCriteria": "- Spec clearly identifies commissionRateBps and serviceFeeRecipient as the integration surface.\n- Spec clearly states RailBurn does not modify Filecoin Pay core contracts.\n- Spec clearly states RailBurn does not duplicate Filecoin Pay network-fee burning.\n- Economic model is published as a spreadsheet, notebook, or reproducible script.\n- Dashboard metrics map to emitted contract events or Filecoin Pay rail data." }, { "title": "Smart contracts and storage-style demo rail flow", "description": "This milestone implements the core contracts and proves the mechanism through a storage-style Filecoin Pay rail flow on Calibration. The work will include RailBurnRecipient.sol, ServiceFeeBurnAuction.sol, DemoStorageRailOperator.sol, and a minimal IFilecoinPayV1 interface.\n\nThe demo operator is included to make the proposal concrete rather than theoretical. It will create a Filecoin Pay-compatible storage-style rail with a payer, payee, payment rate, lockup period, nonzero commissionRateBps, and RailBurnRecipient as the serviceFeeRecipient. The demo flow will show rail activity producing service commission, service commission being harvested by RailBurnRecipient, burn-eligible stablecoin fees being routed to auction, and FIL being burned through the auction path on Calibration.\n\n\n- RailBurnRecipient.sol\n- ServiceFeeBurnAuction.sol\n- DemoStorageRailOperator.sol\n- Minimal IFilecoinPayV1 interface\n- Unit tests\n- Mock Filecoin Pay settlement tests\n- Ca …[truncated] 3.1 Impact pathway Output: RailBurn will deliver open-source smart contracts, a Filecoin Pay-compatible service-fee recipient, a service-fee burn auction, a storage-style demo rail operator, an economic model, a Calibration deployment, a capped mainnet beta, a dashboard, and an operator integration guide. Outcome: Filecoin Pay-compatible service operators will have a reusable way to route a configurable share of their service/operator commission into FIL burn without modifying Filecoin Pay core contracts, introducing a new Filecoin protocol fee, or depending on DEX liquidity in v1. Reviewers and governance participants will also have a public dashboard showing service-commission flow, burn-eligible stablecoin amount, auction clearing, FIL burned, and rail-level demo activity. Impact: As paid Filecoin Pay rails grow across storage, retrieval, CDN, and other services, RailBurn can make a share of service-level payment activity structurally burn-linked and publicly measurable. This contributes directly to Objective 2 by strengthening FIL value accrual, and indirectly to Objectives 1 and 3 by improving the economic instrumentation available to paid onchain service operators. 3.2 Verification metrics | Metric | Data source | How it’s measured | Target end of grant | | ----------------------------------- | ---------------------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------: | | Public mechanism specification | GitHub repository | Published Markdown/spec document | 1 | | Non-duplication map | GitHub repository | Document mapping RailBurn against Filecoin Pay network fee, `burnForFees`, FWSS rails, and FIP-0100 | 1 | | Economic model | GitHub repository | Spreadsheet, notebook, or reproducible script | 1 | | Smart contracts | GitHub repository | Solidity contracts committed and documented | 2–3 | | Demo storage-style rail operator | GitHub repository + Calibration | Contract and transaction sequence proving demo flow | 1 | | Test suite | GitHub CI/local test output | Unit and integration tests passing | Passing | | Calibration deployment | Calibration chain + repo docs | Deployed contract addresses and demo transactions | 1 | | End-to-end demo rail flow | Contract events + dashboard | Rail settlement → commission harvest → auction → FIL burn | At least 1 | | Successful burn-auction demo | Contract events | `ServiceFeeAuctionCleared` event with token amount and FIL burned | At least 1 | | Total commission harvested | RailBurn events …[truncated] 3.3 References n/a 4.1 Monthly Operating Burn [ "< $10K (basic solo operation or part-time team)" ] 4.2 What % of total team monthly burn depends on this grant? For the RailBurn project scope, this grant would fund the majority of dedicated development time for the 3-month delivery window. As a share of CrackDevs’ broader monthly operating burn, the dependency is moderate and limited to this specific grant scope. 4.3 If this grant is not awarded, what happens? If this grant is not awarded, CrackDevs is unlikely to build RailBurn as a dedicated public-good primitive inside the Batch 3 horizon. Filecoin Pay’s existing network-fee burn mechanism will continue to exist, but the ecosystem would still lack a small open-source service-commission burn recipient, storage-style demo rail, public dashboard, and operator guide focused specifically on the separate service/operator commission layer. Without grant support, we may still keep the concept in backlog or produce a lighter design note, but we would not be able to commit the same level of smart-contract implementation, Calibration deployment, capped mainnet beta preparation, dashboard work, and documentation during this round. 4.4 Core Team CrackDevs is a small technical team focused on developer tooling, blockchain software, and infrastructure-oriented products. Ayomide Ojutalayo — Project Lead Ayomide is a developer engineer with experience building developer tooling and blockchain-focused software. For RailBurn, he will lead the smart-contract implementation, Filecoin Pay interface work, demo storage-style rail flow, test suite, repository delivery, and technical execution. GitHub: https://github.com/ojutalayomi Aje Damilola — Documentation & QA Engineer Aje is a full-stack software developer with experience across Node.js, JavaScript/TypeScript, React, Electron, PHP/Laravel, Flutter, AdonisJS, PostgreSQL, and MongoDB. For RailBurn, he will support documentation, QA review, dashboard verification checks, test coverage review, report validation, and maintenance documentation. GitHub: https://github.com/ajedamil Ifedimeji Omoniyi — Technical Product Manager Ifedimeji is a technical product manager with experience across developer tooling, protocols, and infrastructure. For RailBurn, he will coordinate project delivery, milestone tracking, scope control, reviewer communication, integration-guide quality, and final handoff. LinkedIn: https://www.linkedin.com/in/ifedimeji-omoniyi-948132233/ 4.5 Has your team received a ProPGF grant or funding from PLFIF before? [ "No" ] 5.1 Key risks & dependencies Risk 1: Filecoin Pay interface alignment RailBurn depends on the currently deployed Filecoin Pay rail and account interfaces, especially the service/operator commission surface exposed through commissionRateBps and serviceFeeRecipient. To manage this, the project will use a minimal IFilecoinPayV1 interface, pin development to the Filecoin Pay version used for Calibration and mainnet beta, and document all interface assumptions in the repository. If interface details differ between environments, the integration layer will be isolated so the RailBurn contracts can be adapted without changing the core service-commission burn logic. Risk 2: Native FIL burn-path validation RailBurn’s mainnet beta requires a precisely documented native FIL burn path from FEVM contracts. The project will validate the burn flow on Calibration before mainnet activation and publish a short burn-path note with the exact method, transaction evidence, and contract behavior. Where feasible, the implementation will follow the native-token burn pattern already used by Filecoin Pay’s fee-auction design, while keeping RailBurn’s accounting separate from Filecoin Pay’s existing network-fee mechanism. Risk 3: Safe parameterization for capped mainnet beta Because RailBurn handles service-fee tokens and native FIL burn execution, the first mainnet deployment should use conservative limits. The mainnet beta will include supported-token allowlists, per-harvest caps, per-auction caps, and aggregate token caps. These controls keep the deployment appropriate for a reference implementation while still proving the full path from Filecoin Pay service commission to burn auction to public dashboard verification. Risk 3: Safe parameterization for capped mainnet beta Because RailBurn handles service-fee tokens and native FIL burn execution, the first mainnet deployment should use conservative limits. The mainnet beta will include supported-token allowlists, per-harvest caps, per-auction caps, and aggregate token caps. These controls keep the deployment appropriate for a reference implementation while still proving the full path from Filecoin Pay service commission to burn auction to public dashboard verification. Risk 4: Accurate event indexing and dashboard verification The dashboard must reflect contract state accurately, because it is the public verification layer for the mechanism. RailBurn will emit explicit events for service configuration, commission harvesting, burn-eligible routing, auction opening, and auction clearing. The dashboard will compute metrics from those events and provide a CSV or JSON export so the reported data can be independently checked against onchain activity. Risk 5: Scope control within the grant budget The project is intentionally scoped to a narrow reference implementation: RailBurnRecipient.sol, ServiceFeeBurnAuction.sol …[truncated] Any feedback you have on the application process? The project’s main proof is an end-to-end storage-style demo on Calibration: Filecoin Pay rail activity → service/operator commission → RailBurnRecipient → service-fee burn auction → FIL burned → public dashboard verification This makes the proposal practical, bounded, and directly aligned with the FIL value-accrual RFP. Contributing to Core Infrastructure? N/A — this application is submitted under RFP 4: FIL value accrual: burn and lock mechanisms, not the Core Infrastructure maintenance category. Objective 1 Indirect Objective 2 Direct Objective 3 Indirect