03 — The feed
Every proposal, on the table.
Submissions to every Simocracy gathering, ranked by the cloth and attributed to their author sim.
03 — The feed
Submissions to every Simocracy gathering, ranked by the cloth and attributed to their author sim.
June 16, 2026·by Filecoin PGF
ProPGF Batch 3ProPGF Batch 3 application. Requested: $230,000. Stax-Infra operates an independent Filecoin chain snapshot service that produces verified daily mainnet snapshots (full/live and a growing lite-archival history) plus calibnet snapshots, served over HTTPS with resumable downloads and an off-datacen…
Mirrored from filpgf.io — ProPGF Batch 3 (Karma program 1479, application 6a2ac976c970c3f33b070d3e, status: pending). Contact details redacted; canonical application lives on filpgf.io. 1.1 Project Name Stax-Infra Filecoin Snapshot Service 1.2 Project Github https://github.com/quriustus/Stax-Infra 1.3 Project Website https://stax-infra.com 1.4 Team Lead/Point of Contact Vegard Kristiansen 1.5 Category [ "Core Infrastructure", "RFP 1 - Customer-facing products built on Filecoin", "RFP 2 - Storage provider economics and growth", "RFP 3 - AI infrastructure products on Filecoin", "RFP 4 - FIL value accrual: burn and lock mechanisms" ] 1.6 Open Source Status Not Open Source 2.1 Project Summary Stax-Infra operates an independent Filecoin chain snapshot service that produces verified daily mainnet snapshots (full/live and a growing lite-archival history) plus calibnet snapshots, served over HTTPS with resumable downloads and an off-datacenter failover mirror. Today the network relies heavily on a single snapshot provider (ChainSafe); we add a redundant, lower-cost, independently-operated source that improves resilience for everyone syncing a node. Our PoC is already live: Forest + Lotus nodes synced to chain head, automated daily export/replication across three sites (DC location 1 primary on a 20 Gbit uplink, off-DC Location 2 failover), and public serving at snapshots.stax-infra.com. This grant funds hardening the service to production: monitoring, automated failover, documented public endpoints, and a maintained lite-archival archive. The gap we address is snapshot/retrieval infrastructure redundancy, a core dependency for network reliability and for onboarding new storage providers and clients. 2.2 Who does this work support? [ "Storage Providers", "Application Builders", "Network Infrastructure" ] 2.3 Total Funding Requested (USD) $230,000 2.4 Milestones & Budget [ { "title": "Monthly snapshot service operation & maintenance. Month 1", "description": "Continuous operation and maintenance of the Stax-Infra Filecoin snapshot and params service. The service is live from day one: we generate, verify, and serve daily mainnet and calibnet chain snapshots (full/live plus a maintained Full-archival history) at `snapshots.stax-infra.com`, with resumable HTTP range downloads and an off-datacenter failover mirror.\n\nEach month covers the full operational scope:\n• Infrastructure: run Forest + Lotus nodes synced to chain head; daily snapshot export, multi-site replication (DC location 1 primary on 30 Gbit → off-DC location 2 failover on 10Gbit), storage/disk management, and OS/node patching.\n• Monitoring: snapshot freshness (lag from chain head), service uptime, download integrity, and storage health are monitored continuously, with alerting on stale snapshots or downtime and a public status/health endpoint.\n• DevOps: version tracking and upgrades of Forest/Lotus through network upgrades, automated failover, SHA256 verification published per snapshot, infrastructure-as-code (Ansible) for reproducibility, and incident response.\n\nOngoing incremental improvements (e.g. diff snapshots, throughput, docs) are delivered as part of normal operations without interrupting availability.", "dueDate": "2026-08-01", "fundingRequested": "$19,167", "completionCriteria": "Month 1 is complete when, for the full month, the service met its operational targets, externally verifiable:\n\n • Daily mainnet and calibnet snapshots were generated and downloadable at `snapshots.stax-infra.com`.\n • Snapshot freshness ≤ 24h from chain head (visible in the public manifest).\n • Service uptime ≥ 99.5% (visible on the public status page / health endpoint).\n • SHA256 published per snapshot and verifies on download (integrity = 100%).\n • Off-DC failover remained ready (health-checked); any failover events documented.\n \nA short monthly operations report (uptime, freshness, snapshots served, integrity, any incidents) is published to confirm delivery." }, { "title": "Monthly snapshot service operation & maintenance. Month 2", "description": "Continuous operation and maintenance of the Stax-Infra Filecoin snapshot and params service. The service is live from day one: we generate, verify, and serve daily mainnet and calibnet chain snapshots (full/live plus a maintained Full-archival history) at `snapshots.stax-infra.com`, with resumable HTTP range downloads and an off-datacenter failover mirror.\n\nEach month covers the full operational scope:\n• Infrastructure: run Forest + Lotus nodes synced to chain head; daily snapshot export, multi-site replication (DC location 1 primary on 30 Gbit → off-DC location 2 failover on 10Gbit), storage/disk management, and OS/node patching.\n• Monitoring: snapshot freshness ( …[truncated] 3.1 Impact pathway **Output**: A production, independently-operated snapshot service (daily verified mainnet + calibnet snapshots, full-archival history) and params hosting with monitoring, failover, and public HTTPS endpoints. **Outcome**: Node operators, new storage providers, and developers gain a second, lower-cost, trustworthy source to sync from chain head instead of depending on a single provider. **Impact**: Reduced single-provider risk and lower cost for core retrieval/sync infrastructure → a more resilient network and a smoother on-ramp for the SPs and clients the 2026/27 strategy aims to scale. 3.2 Verification metrics | Metric | Data source | How it's measured | Target (end of grant) | |---|---|---|---| | Snapshot freshness (lag from chain head) | Our export logs / public manifest | Time between latest snapshot epoch and chain head | ≤ 24h, daily | | Service uptime / availability | Cloudflare LB health-checks + our monitoring | % successful HTTP HEAD `/healthz` | ≥ 99.5% | | Snapshots served / unique downloaders | Web server access logs | Count of completed downloads | report monthly | | Snapshot integrity | Published SHA256 per file | Verified checksum match on download | 100% verified | | Lite-archival coverage | Public manifest | # of archival points maintained | report monthly | 3.3 References Nicklas Reiers, Lex Luther, Andy Jackson 4.1 Monthly Operating Burn [ "$10-$100K (small team)" ] 4.2 What % of total team monthly burn depends on this grant? 40% 4.3 If this grant is not awarded, what happens? Without the grant we cannot fund the production hardening (monitoring, automated failover, maintained archival depth, public SLA) and would have to turn off the services. 4.4 Core Team **Vegard Kristiansen** - Datacenter owner/operator (Drammen DC, Filecoin SP infra: Curio/SDR/SupraSeal, storage, GPU). **Nicklas Reiersen** - Filecoin developer; leads the snapshot service + application. **Eystein Nes Kolstad** - Hardware/physical infrastructure. Team runs production Filecoin storage-provider infrastructure today; the snapshot service is built on that operational base (multi-site replication, 20 Gbit uplink, off-DC backup). 4.5 Has your team received a ProPGF grant or funding from PLFIF before? [ "No" ] 5.1 Key risks & dependencies **Mitigation:** capture available history now; seek alternate mirrors (e.g. glif.io archival) for gaps. **Infra:** off-DC failover is 10 Gbit (Telenor), adequate for short failover windows but not full-volume serving; primary on 30 Gbit. **Team**: small team — bus-factor risk; mitigated by documented. Anything else you want to share that we didn't ask? PoC already live (snapshots.stax-infra.com), and we materially underbid the incumbent. A note on grant term and pricing. This is an ongoing operations & maintenance service — all snapshots are live and downloadable from day one — so it is naturally suited to a continuous engagement rather than a fixed build project. We understand Batch 3's standard term is 3–6 months, and we're happy to structure it either way: Preferred: 12-month term: $230,000 total (~$19,167/month). A full-year commitment lets us guarantee continuous, dependable snapshot availability and offer our best rate, since the cost of operating the infrastructure is amortized across the whole year. Alternative: 6-month term: $138,000 total ($23,000/month, a 20% higher monthly rate). We can deliver the identical service over a 6-month term to fit the standard Batch 3 window; the higher monthly rate reflects the shorter amortization period and the renewal overhead. In both cases the service, milestones, and completion criteria are the same — only the term and effective monthly rate differ. We'd welcome guidance from the reviewers on which structure best fits the program. Contributing to Core Infrastructure? We operate a Filecoin chain snapshot service built on Forest + Lotus, producing verified daily mainnet .car.zst snapshots (live + lite-archival history) plus calibnet snapshots. New nodes and storage providers depend on fast, trustworthy snapshots to sync from the chain head instead of re-deriving state from genesis. This is the same role ChainSafe's snapshot service fills. We provide a redundant, independently-operated source so the network is not reliant on a single provider. Objective 1 Indirect Objective 2 Indirect Objective 3 Indirect Open Source Context Tooling (snapshot export/replication/serving automation, health-checks) will be published under the Stax-Infra org. Underlying components (Forest, Lotus) are already open source. Internal datacenter operational configs (firewall, host inventory) remain private for security reasons but are not part of the deliverable.
Sign in to comment.