Mirrored from filpgf.io — ProPGF Batch 3 (Karma program 1479, application 6a31d660f2d3da25b237fc21, status: pending). Contact details redacted; canonical application lives on filpgf.io. 1.1 Project Name ProofGate 1.2 Project Github https://github.com/tolgayayci/proofgate 1.3 Project Website https://proofgate.app 1.4 Team Lead/Point of Contact Tolga Yaycı, Co-Founder, YK Labs · Telegram @tolga0x 1.5 Category [ "RFP 4 - FIL value accrual: burn and lock mechanisms" ] 1.6 Open Source Status Fully Open Source 2.1 Project Summary **On Filecoin today, a storage provider proves on-chain that it still holds your data, while a separate system pays it. The two never talk, so payment keeps flowing even when the proof stops. ProofGate is the missing link: it makes payment follow proof.** ProofGate is a tool that plugs into Filecoin Pay (Filecoin's on-chain payment system) and decides how much a storage provider actually gets paid. Filecoin already requires every provider to post regular cryptographic proof that it still holds the data; this proof is called **PDP** (proof of data possession). ProofGate reads that proof straight from the chain and **releases payment only for the periods a provider actually proved, withholding payment automatically for any period it missed**. It never holds the money itself, has no operator who could step in, and relies on no outside data source: it only reads what is already on the chain. The effect is that the money set aside to pay a provider is released only after this proof check passes, so it stays **locked to proven storage performance** and frees up only as the chain confirms the data is still held. That is the Area 4 value-accrual angle (Objective #2): committed value is released by proven useful work, instead of flowing automatically whether or not the provider did its job. What makes it distinct: - **Proof-gated, not swap-based.** It accrues value by conditioning payment on proof, not by swapping or burning tokens, so it has no dependence on DEX or stablecoin-market liquidity. - **Non-custodial.** It never holds user funds; it computes how much should settle while custody stays inside Filecoin Pay. - **Oracle-free.** It reads proof state straight from the chain, with no external data feed to trust. - **Zero integration for providers.** It reads the proof record every provider already writes, so any app or customer can gate any provider's payment with nothing for that provider to install or sign. **This is already deployed and verifiable on Filecoin's Calibration test network, not a paper design.** In 4 months, the plan takes this from today's proof of concept to a hardened, independently audited system running on Filecoin mainnet: showing both withheld and released payments live, publishing the headline result (how much payment was correctly withheld versus released) as a real production number, and shipping an integration package any application or storage provider can adopt. 2.2 Who does this work support? [ "Storage Providers", "Application Builders", "Application Users", "Network Infrastructure" ] 2.3 Total Funding Requested (USD) 110000 2.4 Milestones & Budget [ { "title": "M1: Payment-gating contracts, test suite, reproduction tool, and a public dashboard", "description": "**Purpose:** Deliver the proof-gated payment system as a public, fully tested, and independently verifiable package, so any reviewer or developer can read the contracts, run the tests, reproduce the results from the chain, and watch it work live.\n\n\n**Deliverables:**\n\n1. The settlement-gate contract: the on-chain contract that decides how much a storage provider is paid, releasing payment for each period it proves it still holds the data and withholding payment for each period it does not. Deployed with verified source on the block explorer.\n2. The proof-reader contract: reads each provider's proof state directly from the chain (proving, faulted, or open) so the gate's decision rests only on on-chain proof and no outside data. Deployed with verified source.\n3. The shared library both contracts use to turn the chain's proof record into a per-period proving-or-faulted result.\n4. A test suite covering the gate and reader contracts, with a coverage report in the repository.\n5. A reproduction tool: a single read-only command, needing no wallet and no private key, that takes a list of datasets, independently re-derives each one's proof state from the chain, checks it against what the contract reports, and prints the amount the gate would pay for a proving dataset and withhold for a faulted one.\n6. A public dashboard that reads the live on-chain figures (total paid, total withheld, current dispute window) and the proof state across a set of datasets, and shows the current network fault rate.\n\nAll of the above is published in one public repository under the MIT license.", "dueDate": "2026-07-30", "fundingRequested": "30000", "completionCriteria": "- **Contracts:** the public repository opens, and the gate contract, reader contract, and library all show verified source on the explorer at their published addresses.\n- **Reproduction:** running the one command reports a matching proof state for 100% of the datasets it checks, and prints the full amount for a proving dataset and zero for a faulted one.\n- **Dashboard:** the public dashboard URL loads, shows the live on-chain paid and withheld totals, and a block height that advances when refreshed.\n- **Tests:** the coverage report shows at least 95% of lines covered on the gate and reader contracts, and the tests run clean." }, { "title": "M2: Both payment outcomes settled live on-chain (paid when proving, zero when faulted), plus the optional bond contract", "description": "**Purpose:** Show the full payment loop settling live on-chain in both directions. Today the withholding side is already live: a real payment was withheld on-chain from a provider that stopped proving and that we do not control. The paying side is confirmed by the contract' …[truncated] 3.1 Impact pathway **Primary objective: Strengthen Network Profitability & Cryptoeconomics (#2)** **Outputs.** (1) An open-source, non-custodial Filecoin Pay validator + proof-read library that gates settlement on per-proving-period PDP state; (2) a live proving-health dashboard and an on-chain KPI (`totalWithheld` / `totalReleased`) anyone can verify or reproduce; (3) after a third-party audit, a mainnet deployment + an integration package any app or SP can adopt, plus an optional returnable-FIL-bond module. **Immediate outcomes.** Storage payments stop flowing for unproven data; customers and applications can settle with providers on a proof condition **without trusting an operator or the provider**; FIL committed to a rail becomes locked against verified performance, released only on proof, and (via the bond tier) providers can lock returnable FIL that pays a harmed client on a recorded fault. **Impact (Objective #2).** Network payments track genuine, proven useful work rather than leaking to absent providers, and a reusable FIL-locking mechanism ties committed value to proven storage. This strengthens the cryptoeconomic link between payment and proof that underpins Filecoin's core guarantee, making "you don't have to trust the provider, it's proven" true at the money layer as paid storage scales. 3.2 Verification metrics | Metric | Data source | How it's measured | Target (end of grant) | |---|---|---|---| | **USDFC withheld-on-fault vs released** (headline KPI) | `ProofGateValidator.totalWithheld()` / `totalReleased()`; `SettlementGated` events on the explorer | Sum the on-chain counters and settlement events; reproducible by anyone with a one-command read-only script | Both **> 0** from live settles on a controlled-SP rail (withhold and release both proven live on-chain) | | **# datasets / rails under proof-gated settlement** | `ProofGateValidator` immutable rail→dataset bindings; `proofState` reads | Count immutably-bound rails and per-period gated settlements, each resolvable on an explorer | **≥ 10** rails gated and explorer-verifiable | | **Proof-state correctness (oracle-free)** | `ProofGateView.proofState` vs. the chain's raw proof record | A one-command read-only script independently re-derives the state and compares it to the raw chain | **100%** match across all scanned datasets | | **Mainnet deployment** | Mainnet validator contract address | Audited contract deployed and gating at least one real mainnet rail | **1** mainnet rail gated, post-audit, tx-verifiable | 3.3 References 1. **The on-chain artifact itself (verifiable by anyone, no vouching required).** The deployed contracts and the real settled withhold are public on Calibration (Filfox): ProofGateValidator (the settlement gate and KPI counters, `0x3110…102D`), ProofGateView (the oracle-free proof-state reader, `0xeA18…3914`), and the live withhold-settle transaction (rail 17975, dataset #1, showing 0 paid to a faulted provider). A single read-only verification script in the repo lets any reviewer reproduce every claim with one command and no wallet: it re-derives each dataset's proof state from the raw chain and re-reads the on-chain settlement counters. 2. **Potential verifiers and beneficiaries.** ProofGate is fully on-chain and reproducible, so it can be confirmed independently with no vouching required, and reference #1 above is the primary evidence. The parties who could naturally verify or benefit from the work include the FilOz / Filecoin Onchain Cloud team, who maintain the stack ProofGate reads (Filecoin Pay, PDP, FWSS) and could confirm the proof-reading and settlement logic against their own contracts; storage providers, who could be paid automatically and fairly for proven work with nothing to integrate on their side; and application builders and their users, who could settle payments on a proof condition without trusting an operator. 3. We are happy to walk any reviewer through a live reproduction on request. 4.1 Monthly Operating Burn [ "$10-$100K (small team)" ] 4.2 What % of total team monthly burn depends on this grant? ~90%. This grant funds the dedicated full-time build effort for both engineers over the four-month horizon. The deployed testnet core is already public and MIT-licensed, so the work to date is not at risk. The grant is what lets us take it from a verified proof-of-concept to an audited mainnet deployment rather than leaving it as a demo. 4.3 If this grant is not awarded, what happens? The work done so far stays public and MIT-licensed, so it remains available to anyone. But without funding we cannot run a controlled storage provider to demonstrate withholding and release live end to end, commission a third-party security audit, or deploy and operate a mainnet version, so ProofGate would stay a verified proof of concept rather than a production system that applications and storage providers can adopt. 4.4 Core Team YK Labs has delivered projects across more than 20 blockchain protocols, building developer tooling, SDKs, infrastructure, online IDEs, editor extensions, desktop applications, and analytics engines. Our work spans a wide range of ecosystems, including Stellar, NEAR, Arbitrum, IOTA, Hedera, Cardano, and the Internet Computer, with a consistent record of shipping production-grade tools that developers rely on. **Tolga Yaycı, Co-founder and Software Engineer** **GitHub:** https://github.com/tolgayayci · **LinkedIn:** https://www.linkedin.com/in/tolgayayci/ · **Telegram:** @tolga0x Software engineer with over four years of blockchain development experience, focused on developer tooling, infrastructure, and frontend systems. Holds a Bachelor's degree in Computer Science, with a track record of delivering funded projects across multiple ecosystems. **Selected work:** - **NearPlay**, online IDE for NEAR smart contracts: https://nearplay.app/ - **Wizard**, online IDE for Arbitrum Stylus smart contracts: https://thewizard.app/ - **IOTA Playground**, online IDE for IOTA Move smart contracts: https://iotaplay.app/ - **Hedera VS Code Extension**, toolkit for building on Hedera: https://marketplace.visualstudio.com/items?itemName=tolgayayci.hedera-vscode - **Sora**, desktop app for the Stellar network, funded and delivered across two grant rounds: https://github.com/tolgayayci/sora - **ICP Dashboard**, desktop app for the Internet Computer: https://github.com/tolgayayci/dfx-dashboard **Mert Köklü, Co-founder and Software Engineer** **GitHub:** https://github.com/justmert · **LinkedIn:** https://www.linkedin.com/in/mertkoklu · **Telegram:** @mertkklu Holds a degree in Computer Engineering and previously led an engineering team at an NVIDIA partner company. Has received and delivered grants from Arbitrum, Cardano, Stellar, and other ecosystems, with deep experience in SDK architecture, API design, and backend systems. **Selected work:** - **SoroReveal**, decompiles Soroban smart contracts back to readable source: https://sororeveal.com/ - **Timeboost Analytics**, analytics engine for Arbitrum's Timeboost express-lane auctions: https://github.com/justmert/timeboost-analytics - **Arbitrum Python SDK**, the leading community Python SDK for Arbitrum: https://github.com/justmert/arbitrum-python-sdk - **Koios Rust SDK**, a published Apache-2.0 typed async Rust SDK for the Koios Cardano API, with a typed error model and full docs: https://github.com/justmert/koios.rs - **ICP Agent Kit**, SDK for natural-language interaction with the Internet Computer: https://github.com/justmert/icp-agent-kit Together, this background in smart contracts, developer tooling, SDKs, and on-chain infrastructure is the skill set required to build and ship verifiable, developer-ready infrastructure on Filecoin. 4.5 Has your team received a ProPGF grant or funding from PLFIF before? [ "No" ] 5.1 Key risks & dependencies **1 - Live release-settle depends on running a controlled short-proving-period storage provider (Curio)**, the hardest infrastructure piece, scoped into M2. The release *logic* is already proven correct on-chain via the validator's `quote()` function (full for proven periods, 0 for faulted), so M2 is an operational/infra task, not a logic risk; the withhold path is already fully live on-chain. **2 - FOC contracts are beta, upgradeable UUPS proxies.** Read view-contract addresses dynamically (e.g. `viewContractAddress()`), pin ABIs/versions per build, and monitor upgrades. **3 - Custody risk in the optional returnable-bond tier.** The bond module is hard-isolated from the non-custodial core, testnet-only until the M3 third-party audit, and mainnet only after the audit passes. **4 - Client-induced-fault (a payer trying to make an honest provider look faulted).** A non-zero dispute window (currently 30 epochs) plus a multi-period threshold before any withholding/payout takes effect. **5 - USDFC liquidity.** ProofGate settles in USDFC directly over Filecoin Pay and performs no token swaps, so deep DEX liquidity is not required for it to operate. Because settlement reads and moves USDFC natively, market depth and trading conditions do not affect whether ProofGate releases or withholds the correct amount. Anything else you want to share that we didn't ask? **The approach, and what already works today.** ProofGate makes payment follow proof, directly and without an intermediary. Payment committed to a Filecoin Pay rail is released only for the periods in which a storage provider proves on-chain (through PDP, Filecoin's proof of data possession) that it still holds the data, and is automatically withheld for any period it fails to prove. The contract never holds the money: it only calculates how much should settle, while custody stays inside Filecoin Pay. It uses no price oracle or external data feed (it reads proof state directly from the chain), and it performs no token swap and no token burn, so its operation does not depend on market liquidity or trading conditions. Because it reads the same proof record that every storage provider already writes on-chain, it can be applied to any provider with no integration work required from that provider. The faulted provider in our live demonstration is one we do not operate or control. What is already working today, rather than promised for later: on the Calibration testnet, a real payment has been correctly withheld from a genuinely faulted provider and recorded on-chain, and the release path is verified on-chain. A reviewer does not have to take our word for any of it: the figures we cite, such as the cumulative amount withheld, are public values the contract stores on-chain that anyone can read and independently confirm. We scope this deliberately as a testnet proof of concept; mainnet deployment follows only after the third-party security audit in Milestone 3. This is the working, verifiable kind of mechanism Area 4 asks for rather than a paper design, at a maturity appropriate for a payment mechanism built on Filecoin Onchain Cloud, which itself reached mainnet only a few months ago. Objective 1 Indirect Objective 2 Direct Objective 3 N/A Open Source Context **ProofGate is fully open source under the MIT license. Every part of the system is public, and nothing is closed or proprietary.** This covers the complete project, not a partial release: - The **on-chain contracts** that read proof and decide payment (the settlement validator and the proof reader), published with verified source so the code running on-chain matches the code anyone can read; - The **shared library** the contracts use to tell whether a provider is currently proving or has faulted; - The **developer SDK and helper libraries** an application or storage provider uses to set up and read a proof-gated payment; - The **dashboard** that reads live on-chain state; and - The **verification tooling** that lets anyone reproduce ProofGate's results directly from the chain, with no wallet and without trusting us. Keeping all of this open is essential to how ProofGate works, not just a preference. The whole idea is that no one has to trust an operator: payment follows proof, and the proof comes from the chain. That only holds if the code that reads the proof and decides the payment is open for anyone to inspect, audit, and run for themselves. A closed piece anywhere would put people back to trusting us, which is the thing ProofGate is built to remove. The MIT license also means any application, storage provider, or auditor can read, reuse, and build on it freely.