Mirrored from filpgf.io — ProPGF Batch 3 (Karma program 1479, application 6a3184a413ef2aeed7ce0d91, status: pending). Contact details redacted; canonical application lives on filpgf.io. 1.1 Project Name FIL Accrual Verifier: Filecoin Pay Fee Auction Monitoring Tools 1.4 Team Lead/Point of Contact Abdulkareem Oyeneye . Telegram: supercoolkay 1.5 Category [ "RFP 4 - FIL value accrual: burn and lock mechanisms" ] 1.6 Open Source Status Fully Open Source 2.1 Project Summary FIL Accrual Verifier will build open-source monitoring and keeper tooling for Filecoin Pay’s existing fee-auction burn mechanism. Filecoin Pay deducts a 0.5% network fee from payment-rail settlements, places non-native ERC-20 fee balances in the payment contract’s own account, and uses a Dutch auction where participants can burn FIL through `burnForFees` to claim accumulated fee tokens. The gap this project addresses is not the fee mechanism itself. The gap is the missing public liveness and verification layer around that mechanism. This project will ship a verification indexer, keeper bot, public dashboard, stale-balance alerts, settled-fees-versus-claimed-fees reconciliation, and third-party operator runbooks. This project directly helps with the FIL value-accrual RFP's goals by making it clear how things are going with burn rate, fee inventory, payment-rail activity, and auction liveness. The RFP clearly says that having public dashboards and on-chain tools to show burn rate, locked supply, and what's driving activity in real-time is important. It also says that this work can be useful on its own if it comes with a roadmap for how to make it happen. For example, this could be paired with a specific plan for how to use the data from the dashboards to make decisions about the project. By making this information visible, the project can help support the goals of the RFP and provide value to the community. This is especially important for projects like Filecoin, where transparency and accountability are key to building trust and ensuring the project's success 2.2 Who does this work support? [ "Network Infrastructure", "Application Builders", "Pods", "Network Governance", "Storage Providers", "Application Users" ] 2.3 Total Funding Requested (USD) 34000 2.4 Milestones & Budget [ { "title": "Mileston 1 - Fee-auction metric specification, architecture, repo setup, and MVP data readere 1", "description": "* Verify the list of approved Filecoin Pay contract addresses and confirm they are operating on the correct networks.\n* Define supported token configuration.\n* Map required Filecoin Pay events, state reads, and transaction/call inspection.\n* Define fee-inventory methodology.\n* Define auction-price calculation methodology.\n* Define settled-fees-versus-claimed-fees reconciliation methodology.\n* Define stale-balance thresholds.\n* Publish public repository and technical specification.\n* Build MVP scripts to read `auctionInfo[token]`, fee inventory from `accounts[token][address(FilecoinPay)]`, and settlement eve", "dueDate": "2026-07-31", "fundingRequested": "$3,500", "completionCriteria": "* Public repo is live.\n* Metric specification is published.\n* The MVP data reader is able to access and display the current auction state and fee inventory for tokens that have been set up in the system.\n* Initial dry-run keeper output is demonstrated." }, { "title": "Verification indexer or subgraph-compatible indexing layer", "description": "* Index `RailSettled` events.\n* Index `RailOneTimePaymentProcessed` events.\n* Keep track of important changes in your account, like when money is added or taken out.\n* Track fee inventory by token.\n* Track auction state by token.\n* Track successful `burnForFees` calls.\n* Track FIL sent into successful `burnForFees` calls.\n* Track claimed fee inventory through internal-account balance deltas and token Transfer logs where available.\n* Add settled-fees-versus-claimed-fees reconciliation logi", "dueDate": "2026-08-18", "fundingRequested": "$7,500", "completionCriteria": "* Indexer can reconstruct settlement volume, network fees, fee inventory, auction state, and successful auction clears for monitored contracts.\n* The indexer makes its data available in a few different ways, including through a special set of instructions called an API, a database schema, a GraphQL endpoint, or an export format that other systems can understand.\n* Known limitations are documented" }, { "title": "Fee-auction keeper bot with dry-run and live modes", "description": "* TypeScript keeper CLI.\n* Filecoin mainnet configuration.\n* Calibration configuration where endpoints and deployed contracts are available.\n* Dry-run mode.\n* Live mode.\n* Per-token threshold configuration.\n* Minimum fee-inventory threshold.\n* Minimum auction-age threshold.\n* Maximum FIL spend cap.\n* Wallet balance check.\n* Current estimated auction-price calculation.\n* Structured logs and JSON status output.\n* Operator runbook.", "dueDate": "2026-09-05", "fundingRequested": "$7500", "completionCriteria": "* The Keeper can be set to run in a dry-run mode, which allows it to …[truncated] 3.1 Impact pathway **Output:** FIL Accrual Verifier ships an open-source verification indexer, keeper bot, public dashboard, stale-balance alerts, reconciliation checks, and operator runbooks for Filecoin Pay fee auctions. People who build, run, and take part in the Filecoin ecosystem can now see a few important things. They can check how much fee inventory has built up, if auctions are working properly, how much FIL is being used for `burnForFees` calls that are successful, and if fee balances are getting old and stale. This information helps them understand what's going on with fees in the system. **Impact:** Filecoin Pay’s existing fee-auction burn mechanism becomes more transparent, monitorable, and operationally usable. This strengthens the network’s ability to verify FIL value-accrual activity as paid storage, retrieval, and payment-rail usage grow. This project is focused on measurement and liveness, and it's not meant to directly boost the number of deals or guarantee a specific amount of FIL burn. Its main goal is to provide a way to measure and assess certain aspects, rather than driving up numbers or achieving a particular burn amount 3.2 Verification metrics The project primarily measures and verifies onchain activity rather than directly causing new onchain volume. The following metrics will be externally verifiable through Filecoin Pay events, public contract state, transaction data, and dashboard outputs. | Metric | Data source | How it is measured | Target at end of grant | | -------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ | | Indexed Filecoin Pay settlement volume | Filecoin Pay settlement events | Sum settlement amounts from monitored `RailSettled` and one-time payment events | Displayed by token for monitored contracts | | Network fees emitted in settlement events | Filecoin Pay settlement events | Sum emitted network-fee fields from monitored settlement events | Displayed by token and time period | | Current fee inventory by token | Filecoin Pay public account state | Read `accounts[token][address(FilecoinPay)]` or equivalent contract state | Displayed for configured monitored tokens | | Auction state by token | Filecoin Pay public auction state | Read `auctionInfo[token]` and compute current estimated auction price based on documented decay | Displayed for configured monitored tokens | | Successful fee-auction clears | Transaction/call data | Detect successful `burnForFees` calls | Displayed with transaction links | | FIL sent into successful `burnForFees` calls | Transaction/call data | Read FIL value sent with successful `burnForFees` calls | Displayed per auction clear and aggregated | | F …[truncated] 3.3 References Reference 1 — Filecoin Foundation / Retrieval Utility Grant Reference: Filecoin Foundation grant/program contact Relationship: Previous grant funder / ecosystem stakeholder Relevant work: Dapps over Apps received support for building the Filecoin Retrieval Utility, a tool for testing CID retrieval performance across multiple public gateways. Project link: https://www.retrievaltester.com The Filecoin Foundation reference can speak to our ability to deliver Filecoin ecosystem tooling, communicate progress, and complete a grant-funded technical product to a high standard. Reference 2 — IPFS / DASL Fuzz Testing MVP Reviewers References: Juan Caballero, Theresa Therriault, and Robin Berjon Relationship: IPFS ecosystem stakeholders / MVP reviewers Relevant work: Dapps over Apps built an MVP for DASL Fuzz Testing and received strong positive feedback from the IPFS-side reviewers. These references can speak to our ability to scope and deliver a technical MVP, respond to ecosystem needs, and build useful tooling for protocol-adjacent developer workflows. . 4.1 Monthly Operating Burn [ "$10-$100K (small team)" ] 4.2 What % of total team monthly burn depends on this grant? Approximately 45% of our team’s monthly operating burn for the grant period would depend on this grant. The remaining operating capacity is supported by existing team resources and ongoing ecosystem/developer tooling work. The grant would primarily fund the dedicated engineering time required to complete the Filecoin Pay fee-auction indexer, keeper bot, dashboard, verification checks, and runbooks within the proposed 10-week timeline. 4.3 If this grant is not awarded, what happens? If we don't get this grant, Dapps over Apps can still create a basic version of our product, but it won't be as comprehensive. We'll likely have to delay or scale back some key features, such as the verification indexer, keeper bot, public dashboard, reconciliation checks, and operator runbooks. The main consequence of this is that it will be more difficult for third parties to track and verify Filecoin Pay's fee-auction burn path using a single, public tool. This could limit transparency and make it harder for users to monitor the platform's activity. As a result, the development of our project might be slower and less robust, which could impact its overall effectiveness and user experience 4.4 Core Team **Dapps over Apps** is a group that works on making tools for Web3 developers and teaching them new things. They make tools that make it easier for developers to do their job and start programs that help new developers get into the blockchain world. Relevant team work includes: * **Zeckit** is a tool that helps developers work with Zcash. It's like a guide that shows them how to get started and how to make Zcash work with other things. The project has a website with lots of information, step-by-step guides, and other helpful stuff that makes sure everything works together smoothly. Docs: `https://docs.zeckit.xyz/` Docs repo: `https://github.com/Supercoolkayy/zeckit-docs` * **VoxBridge** — a VoxEdit-to-Unity/Roblox asset converter for Sandbox creators and gamers. Repo: `https://github.com/Supercoolkayy/voxbridge/` We've been doing some local testing work, called **Ox-rollup**, to add support for Arbitrum precompiles. This includes things like ArbSys at `0x64`, ArbGasInfo at `0x6c`, and a specific type of transaction, `0x7e` deposits. Our goal is to get these features working smoothly with Hardhat and Foundry/Anvil workflows. By doing this, we're making it easier for developers to work with Arbitrum and its precompiles in their daily workflows. Website: `https://www.ox-rollup.com` * **A Helpful Tool for Filecoin** - this is something that tests how well different public gateways can find and get files, using something called CID. It's like a test to see which gateways are the best at retrieving files. Link: `https://www.retrievaltester.com/` * **Arbitrum Stylus VS Code Extension** — a VS Code extension designed to improve the coding experience for Arbitrum Stylus smart contract development. Repo: `https://github.com/Supercoolkayy/Abitrum-stylus-extension/tree/main` * The Portable Sandbox Identity Toolkit is a command-line tool that helps turn Sandbox characters into a format called VRM. This format lets you use your characters in lots of different virtual world platforms. It also checks who really owns the character using blockchain before it does the conversion. Package: `https://pypi.org/project/avatar-everywhere-cli/` ### Core contributors **Abdulkareem Oyeneye — Project Lead** Developer tooling engineer and project manager with experience leading Web3 ecosystem tooling initiatives. Abdulkareem will coordinate delivery, milestone execution, technical scoping, stakeholder communication, and final reporting. LinkedIn: `https://www.linkedin.com/in/abdulkareem-oyeneye-82a6aa277` **Gospel Ifeadi — Smart Contract / Backend Engineer** Engineer with experience across Rust, C++, JavaScript, and Python. Gospel will contribute to keeper logic, contract-state reads, backend indexing, automation, and test coverage. X/Twitter: `https://x.com/gospel70800` **Musa Abdulkareem — ZK / Protocol Engineer** Musa is an engineer who specializes i …[truncated] 4.5 Has your team received a ProPGF grant or funding from PLFIF before? [ "No" ] 5.1 Key risks & dependencies Key risks are limited to implementation and data-availability risks. Some Filecoin Pay fee-auction data may require a hybrid indexing approach using events, public contract state reads, transaction inspection, and token balance-delta checks. Auction activity may also be limited during the grant period, so the system will track fee inventory, auction state, stale balances, and keeper dry-run status even when few auction clears occur. Service attribution may be incomplete, so the dashboard will only show attribution where indexed data supports it and will clearly label unknown rails or addresses. Keeper live mode will include conservative safety controls, including dry-run mode, maximum FIL spend caps, token thresholds, auction-age thresholds, and wallet balance checks. Contract addresses, token lists, and network settings will remain configurable so the system can adapt as Filecoin Pay usage evolves Anything else you want to share that we didn't ask? This project has a limited scope. It doesn't try to change the way Filecoin tokens work, create a new payment system, or launch a one-time campaign to buy and burn tokens. Instead, it aims to make it easier to keep track of, check, and use the existing fee-auction burn mechanism in Filecoin Pay. This project also addresses a specific need in the Filecoin Pay repository. The goal is to make sure the fee auction is working correctly. To do this, a keeper needs to be run, and the fees that have been settled need to be compared to the fees that were auctioned for each token. A webpage will be created to display this information, and runbooks will be added to help with the process. You can find more details about this on GitHub. Contributing to Core Infrastructure? N/A — this proposal is submitted under RFP 4, not the Core Infrastructure category. Objective 1 Indirect Objective 2 Direct Objective 3 Indirect