Mirrored from filpgf.io — ProPGF Batch 3 (Karma program 1479, application 6a31760e6e2b9bde36d202f4, status: pending). Contact details redacted; canonical application lives on filpgf.io. 1.1 Project Name Filecoin Infrastructure Services 1.2 Project Github https://github.com/ChainSafe/filecoin-snapshot-listing 1.3 Project Website https://forest-archive.chainsafe.dev/ 1.4 Team Lead/Point of Contact Josh Dougall, Head of Infrastructure, Slack 1.5 Category [ "Core Infrastructure" ] 1.6 Open Source Status Fully Open Source 2.1 Project Summary Filecoin Infrastructure Services funds the continued operation, hardening, and cost-reduction of critical, neutral Filecoin infrastructure the network already depends on: the snapshot service (24×7), the historical snapshot archive, bootstrap nodes, the Calibration Network faucet, and an independent Curio-based Calibnet miner. These services support network availability and bootstrap reliability, safe and rapid upgrades, developer and operator onboarding, debugging and research, and operator diversity on Calibnet. This renewal also reduces the network's reliance on a small number of operators and reduces the cost and hardware footprint of the services themselves. Over this term we are migrating the snapshot and bootstrap stack to run on Forest only, retaining a single Lotus reference node per network rather than a full Lotus deployment alongside every service. This lowers RAM and disk requirements substantially (Forest exports a snapshot on ~32 GiB RAM vs. Lotus needing 128–256 GiB), proves Forest's production-readiness for core infrastructure, and advances Filecoin client diversity. The gap addressed is straightforward: without independently operated snapshots, bootstrap nodes, a faucet, and realistic Calibnet power, node onboarding slows, upgrade safety degrades, developer friction rises, and the network centralizes around a few operators. ChainSafe has run these services reliably for years; ProPGF funding keeps them neutral, available, and increasingly efficient. 2.2 Who does this work support? [ "Storage Providers", "Application Builders", "Application Users", "Network Infrastructure" ] 2.3 Total Funding Requested (USD) 77400 2.4 Milestones & Budget [ { "title": "Milestone 1", "description": "Continued operation of all five core services (snapshot service, historical snapshot archive, bootstrap nodes, Calibnet faucet, Calibnet Curio miner) at the SLOs in Section 3, including the 24×7 <30-minute post-upgrade response on the snapshot service. Plus: provision and launch the dedicated Mainnet archival node, begin syncing full chain history from genesis, and grant the Forest team access for archival R&D.", "dueDate": "2026-10-30", "fundingRequested": "12900", "completionCriteria": "N/A" }, { "title": "Milestone 2", "description": "Continued operation of all five core services (snapshot service, historical snapshot archive, bootstrap nodes, Calibnet faucet, Calibnet Curio miner) at the SLOs in Section 3, including the 24×7 <30-minute post-upgrade response on the snapshot service. Plus: Forest-only migration of the snapshot validation pipeline (Lotus validation removed in favor of Forest-native validation).", "dueDate": "2026-11-30", "fundingRequested": "12900", "completionCriteria": "N/A" }, { "title": "Milestone 3", "description": "Continued operation of all five core services (snapshot service, historical snapshot archive, bootstrap nodes, Calibnet faucet, Calibnet Curio miner) at the SLOs in Section 3, including the 24×7 <30-minute post-upgrade response on the snapshot service. Plus: the Mainnet archival node now holds full chain history from genesis and is available to the Forest team for archival-capabilities research (archival-depth baselining, serving from a specific chain height, and more efficient FEVM state serving).", "dueDate": "2026-12-31", "fundingRequested": "12900", "completionCriteria": "N/A" }, { "title": "Milestone 4", "description": "Continued operation of all five core services (snapshot service, historical snapshot archive, bootstrap nodes, Calibnet faucet, Calibnet Curio miner) at the SLOs in Section 3, including the 24×7 <30-minute post-upgrade response on the snapshot service; the Mainnet archival node remains available to the Forest team.", "dueDate": "2027-01-31", "fundingRequested": "12900", "completionCriteria": "N/A" }, { "title": "Milestone 5", "description": "Continued operation of all five core services (snapshot service, historical snapshot archive, bootstrap nodes, Calibnet faucet, Calibnet Curio miner) at the SLOs in Section 3, including the 24×7 <30-minute post-upgrade response on the snapshot service; the Mainnet archival node remains available to the Forest team.", "dueDate": "2027-02-28", "fundingRequested": "12900", "completionCriteria": "N/A" }, { "title": "Milestone 6", "description": "Continued operation of all five core services (snapshot service, historical snapshot archive, bootstrap nodes, Calibnet faucet, Calibnet Curio miner) at the SLOs in Section 3, including t …[truncated] 3.1 Impact pathway **Output → outcome → impact:** We operate snapshots, bootstrap nodes, a faucet, a historical archive, an independent Calibnet miner, and a dedicated Mainnet archival R\&D node for the Forest team (output). This keeps node onboarding fast and upgrades safe, keeps developers unblocked on Calibnet, keeps historical state cheaply accessible, keeps Calibnet power diverse and realistic, and gives the Forest team a production-representative environment to research archival-cost reductions (outcome). The network becomes more resilient, more decentralized across operators, and cheaper to participate in, while reducing dependence on any single institution and strengthening a second production-grade client (impact). The Forest-favoured migration compounds this: lower hardware cost per service makes the infrastructure sustainable at a smaller grant, and demonstrates a second production-grade implementation operating core infrastructure, directly advancing client diversity. 3.2 Verification metrics | Metric | Data source | How it's measured | Target (end of grant) | | :---- | :---- | :---- | :---- | | Latest Mainnet snapshots generated & validated | forest-archive.chainsafe.dev/list/mainnet/latest?format=json | Distinct validated snapshots / week | Avg 83 / week | | Latest Calibnet snapshots generated & validated | forest-archive.chainsafe.dev/list/calibnet/latest?format=json | Distinct validated snapshots / week | Avg 82 / week | | Post-upgrade snapshot latency | Slack upgrade-coordination confirmation \+ R2 upload timestamp | Time between confirmed upgrade and post-upgrade snapshot | \<30 min (incl. emergency upgrades) | | Historical diff snapshots (per network) | .../list/{mainnet,calibnet}/diff?format=json | Distinct diff snapshots / week | Avg 7 / week each | | Historical lite snapshots | .../list/{mainnet,calibnet}/lite?format=json | Distinct lite snapshots / 30,000 epochs | 1/30k (mainnet), 7/30k (calibnet) | | Bootstrap node reachability | 6 peer IDs under chainsafe-fil.io DNS (public WHOIS); ProbeLab | ≥1 node/network reachable at all times | 99% uptime / node | | Faucet availability | faucet.calibnet.chainsafe-fil.io health endpoint | Uptime monitoring | 99% uptime | | Faucet activity | Filfox: wallet t1lo4ajjyeygqn3lkrw6izwz6aft5chshngs6gjxa (t090) transfers | On-chain transfer count | Ongoing tFIL \+ datacap distribution | | Calibnet miner power | Filfox: miner t0181521 | On-chain QAP | 250 TB QAP on-chain | | Calibnet miner reliability | Filfox t0181521 blocks; window PoSt | Uptime \+ consecutive WindowPoSt failures | 99% uptime, ≤2 consecutive WindowPoSt failures | | Mainnet archival node (Forest R\&D) | Internal sync height vs genesis; Forest team confirmation | Node holds full chain history for R\&D use | Full history retained (internal R\&D resource, no public SLO) | 3.3 References - FilOz / Lotus team: depend on ChainSafe-operated bootstrap nodes (our multiaddrs ship in Lotus) and on the snapshot service. - Forest team (ChainSafe): operational feedback loop; infra runs on Forest and the archival R&D node directly supports Forest's archival research; findings flow upstream. - Filecoin Foundation: grantor of the prior 2025 Infrastructure Services; can vouch for multi-year reliable operation. 4.1 Monthly Operating Burn [ "$10-$100K (small team)" ] 4.2 What % of total team monthly burn depends on this grant? 100% of the Filecoin Infrastructure Services are funded through this grant. This includes server/hosting costs, team effort and 24x7 on-call coverage. 4.3 If this grant is not awarded, what happens? *Without this funding, ChainSafe's continued operation of these services becomes unsustainable and they would be wound down at the end of the current grant term. The consequences fall on the wider network:* * *Snapshots: generation cost and time rise sharply, and the 24×7 \<30-minute upgrade response lapses. Teams relying on our snapshots to bootstrap and recover nodes lose a primary source; the network becomes slower and riskier to upgrade.* * *Historical archive: diff/lite archival access disappears, forcing expensive full replay from genesis for research, forensics, and tooling, or risking permanent loss of historical chain data not held elsewhere.* * *Bootstrap nodes: ChainSafe hosts 3 of the 4 bootstrap nodes, whose multiaddrs are hard-coded across all Filecoin implementations. If these nodes go offline, peer discovery and liveness degrade during churn and upgrades.* * *Faucet: calibnet developers and SPs lose a reliable tFIL/datacap source, raising onboarding friction.* * *Calibnet miner: removing it cuts meaningful Calibnet QAP and an independent operator's perspective, reducing operator diversity and making upgrade testing less realistic. The miner was added precisely to mitigate single-point-of-failure risk — when Curio last failed, the entire F3 network went down and had to be restarted, at significant coordination cost.* * *Mainnet archival node: the Forest team loses its dedicated, production-representative environment for archival-capabilities research. Archival-depth baselining, serving-from-height, and efficient FEVM state-serving work slow down or run on under-powered machines with less confidence, increasing uncertainty in production-like deployments and delaying ecosystem cost reductions.* *The Forest-favoured migration funded here is precisely what keeps these services affordable; without it, any operator picking them up inherits the higher Lotus hardware footprint (128–256 GiB RAM vs \~32 GiB on Forest).* 4.4 Core Team - Josh Dougall: Engineering Manager / Head of Infrastructure. Owns the Filecoin infrastructure portfolio and ProPGF delivery. - Aleksey (liveder): Filecoin infrastructure driver; primary operator of the snapshot pipeline, bootstrap, faucet, and miner. 4.5 Has your team received a ProPGF grant or funding from PLFIF before? [ "Yes" ] 5.1 Key risks & dependencies * **Forest-only migration risk:** moving snapshot validation and the bootstrap fleet to Forest-only (one Lotus reference node per network) is the cost-reduction lever and a deliverable. If a Forest-native validation or bootstrap edge case surfaces mid-migration, we retain the Lotus reference node per network as a fallback while the issue is fixed upstream, so service continuity is not at risk. * **Storage / egress cost growth:** full chain history from genesis grows continuously, especially on Mainnet; archive and archival-node storage is the primary cost driver and a standing operational risk. * **Upgrade-response dependency:** the 24×7 \<30-minute post-upgrade SLA depends on timely upgrade coordination signals; we mitigate with on-call coverage and Slack upgrade-coordination monitoring. Anything else you want to share that we didn't ask? **Reduced operating cost via Forest.** *Forest exports a basic chain snapshot in \~34 min on 32 GiB RAM and 200 GiB disk, where Lotus needs 128–256 GiB RAM and 450 GiB disk and takes 232–450 min (figures consistent with the Forest team's Batch 3 benchmark). Forest also compresses snapshots under the hood, further reducing storage cost. Migrating snapshot validation and the bootstrap fleet to Forest-only (one Lotus reference node per network) materially lowers the hardware cost of operating these services, which is what makes the ask sustainable. It also exercises Forest under real core-infrastructure load and advances Filecoin client diversity.*  **Multi-year track record.** *ChainSafe has operated Filecoin bootstrap and snapshot infrastructure reliably for several years (prior Filecoin Foundation SoW, Apr 2025 – Mar 2026, and the current ProPGF Batch 2 grant), with public, reproducible evidence: the snapshot listing JSON API, on-chain miner/faucet activity, and DNS ownership of chainsafe-fil.io with bootstrap multiaddrs hard-coded in Lotus and Forest. This is infrastructure operated by the maintainer of the node it runs on, with years of proven, externally verifiable uptime, not a newly stood-up mirror.* Contributing to Core Infrastructure? ChainSafe operates a set of foundational, neutral, publicly available Filecoin services across Mainnet and the Calibration Network, and is itself the maintainer of Forest, one of the network's three production node implementations. The services in this application are: 1. Network snapshot service: 24×7 availability; response to upgrades in under 30 minutes. 2. Historical snapshot archive: diff \+ lite snapshots 3. Bootstrap nodes: 3 per network, multiaddrs hard-coded in all Filecoin implementations. 4. Calibration Network faucet: an independent Lotus-based faucet operated by ChainSafe Infrastructure at [https://faucet.calibnet.chainsafe-fil.io](https://faucet.calibnet.chainsafe-fil.io) , distributing tFIL and datacap. 5. Independent Curio-based Calibnet miner: maintaining meaningful, realistic storage power. 6. Mainnet archival node for Forest R\&D (new this term): one dedicated, full-history Mainnet Forest node, provisioned and operated by ChainSafe Infrastructure for the Forest team's scoped research into archival capabilities. These services are depended on daily by: node operators bootstrapping or recovering nodes; the Filecoin node implementations that ship our bootstrap multiaddrs (in all Filecoin implementations); developers and SPs onboarding on Calibnet via the faucet; researchers and tooling teams that rely on the snapshot archive to reconstruct past chain state without full replay from genesis. The snapshot service operates under a 24×7 SLA with a sub-30-minute response target for network upgrades, making it a critical part of safe, rapid upgrades across the network. This is operated alongside the team that builds Forest itself, so operational findings flow directly back upstream into the implementation rather than being consumed at arm's length. Mainnet archival host will be used by the Forest Engineering team to research and optimize Forest’s archival capabilities in a production-representative environment. Karma Profile 0x75cc953769675bac82a08eb6d4ebb253824e1520cd880477f07923549a92e7a4 Objective 1 Indirect Objective 2 Indirect Objective 3 Indirect Open Source Context The infrastructure runs on open-source code. The services run primarily on Forest, ChainSafe's open-source Rust Filecoin node, and the team contributes operational fixes and findings upstream to Forest and Curio. Internal Ansible/Terraform that wires these together is kept private for operational-security reasons (host addresses, credentials), consistent with the network's objective of secure, reliable infrastructure.