Mirrored from filpgf.io — ProPGF Batch 3 (Karma program 1479, application 6a19d96db12c5f4c96a1cbcb, status: pending). Contact details redacted; canonical application lives on filpgf.io. 1.1 Project Name Curio Core + Lantern // pure-Go Filecoin Onchain Cloud infrastructure 1.2 Project Github https://github.com/Reiers/curio-core 1.3 Project Website https://curiocore.io 1.4 Team Lead/Point of Contact Nicklas Reiersen (TSE Reiersen) 1.5 Category [ "Core Infrastructure" ] 1.6 Open Source Status Fully Open Source 2.1 Project Summary **Curio Core + Lantern is the pure-Go Filecoin Onchain Cloud stack:** a Filecoin SP implementation small enough to run on a single VM (one ~90 MB static binary, ~55 MB RSS at idle), with the chain backend (Lantern) embedded directly in-process so the operator never has to stand up a separate Lotus or Forest node. This work supports two beneficiary classes at once. For **storage providers**, it removes the largest cost-of-entry to the FoC market: a hot-storage operator can buy a small VM, run one binary, and be a `synapse-sdk`-compatible SP serving paid USDFC deals. The alternative today is a seven-component cluster (Lotus + Yugabyte + Curio + Boost + Ethereum RPC + IPNI + dashboard). For **application builders and client tooling**, Lantern's embedded daemon means any Go program can verify Filecoin chain state in-process without trusting a third-party RPC. The Filecoin-specific gap is concrete. The canonical FoC operator profile today still depends on `filecoin-ffi` and a Rust toolchain through Curio's sealing pipeline. That is the right answer for sealed-deal SPs and the wrong shape for hot-storage-only operators in the Onchain Cloud era. The 2026 Filecoin Network Strategy's first objective (*Drive Paid Onchain Deals*) and the FoC mainnet-readiness milestone both require dramatically lowering the operator activation cost. **Curio Core is that lowering**, and Lantern is the chain-side prerequisite that makes the one-binary form factor possible. **Grant start: 2026-07-01. Grant end: 2026-12-31.** This is the program's default 6-month funding horizon; the milestone schedule below (M1 due 2026-07-31 through M6 due 2026-12-31) fits inside that window with monthly cadence. If the kickoff date shifts later than 2026-07-01, we will compress the schedule to land M6 by 2026-12-31 rather than extend past the 6-month default. The 6-month scope (2026-07-01 → 2026-12-31): * Ship Curio Core to public mainnet beta with at least one external operator running it. * Harden Lantern through the next set of mainnet network upgrades, keeping 0-epoch sync lag. * Absorb upstream FoC contract drift (PDPVerifier upgrades, FWSS changes, `synapse-sdk` evolution) so the FoC ecosystem has a maintained alternative implementation ready when operators ask for it. > **Note on repository history and pre-public provenance.** > > Both source repositories ([Reiers/lantern](https://github.com/Reiers/lantern), [Reiers/curio-core](https://github.com/Reiers/curio-core)) were opened to public visibility on **2026-05-28**, the same day this application was drafted. The work itself is not new — the repositories were private during initial buildout to keep the carve-out scope contained while it stabilised. The following are externally verifiable signals that the work pre-existed: > > * **Lantern v1.2.1 tag dated 2026-05-22** — [github.com/Reiers/lantern/releases/tag/v1 …[truncated] 2.2 Who does this work support? [ "Storage Providers", "Application Builders", "Network Infrastructure", "Onramps" ] 2.3 Total Funding Requested (USD) $130,000 USD 2.4 Milestones & Budget [ { "title": "Milestone 1 - Mainnet-readiness review and gap closure (Curio Core)", "description": "Get Curio Core to the point where it can boot against mainnet end-to-end against a real `lotus` peer, with the import surface independently reviewed and any blocker-tagged findings closed.\n\nThe work in this milestone:\n\n* Commission an independent third-party security review of the curio-core import surface (~3 weeks lead time + 1 week reviewer-to-author iteration).\n* Triage every finding into blocker / non-blocker; close all blocker-tagged issues in the repo.\n* Cut **v0.2.0-alpha** — the first mainnet-eligible binary, verified booting against a real `lotus` peer (calibration remains the rehearsal stage).\n* Publish a public mainnet-readiness report including the third-party reviewer's findings and our responses.", "dueDate": "2026-07-31", "fundingRequested": "$23,475 USD", "completionCriteria": "* Public release tag **v0.2.0-alpha** on github.com/Reiers/curio-core.\n* Public mainnet-readiness report (markdown in the repo + linked from curiocore.io).\n* All issues labelled `audit-blocker` closed.\n* A reproducible `curio-core probe --network=mainnet` succeeds against a real `lotus` peer, captured in CI." }, { "title": "Milestone 2 - Upstream Filecoin Onchain Cloud contract absorption", "description": "Track and adopt the upstream Filecoin Onchain Cloud contract changes that land during the milestone window: any PDPVerifier release after v3.4, FWSS upgrades, and `synapse-sdk` surface drift. The work isn't about adding new features in Curio Core; it's about staying compatible with the canonical FoC reference deployment so any client that drives the FoC stack also drives Curio Core unchanged.\n\nConcrete tasks:\n\n* Mirror upstream ABI / surface changes into Curio Core's `pdpwire` and `synapsecompat` packages.\n* Run regression tests against the FilOzone reference deployment for every change.\n* Document any cases where Curio Core deliberately diverges from the canonical implementation (there should be very few; we want full surface parity).\n* Ship a public compatibility matrix on curiocore.io showing which versions of each upstream component Curio Core targets.", "dueDate": "2026-08-31", "fundingRequested": "$19,450 USD", "completionCriteria": "* `synapse-sdk` compat test suite passes 100% against Curio Core HEAD.\n* Every upstream PDPVerifier method we support is exercised in CI against the canonical reference.\n* Compatibility matrix published at `curiocore.io/compat` (or equivalent path).\n* No open `upstream-drift` labelled issues at end of milestone." }, { "title": "Milestone 3 - Lantern through the next mainnet network upgrade", "description": "Maintain Lantern through whatever Filecoin `nv` mainnet upgrade lands during the milestone window. Lantern's F3 trust anchor and actor-bundle tabl …[truncated] 3.1 Impact pathway **Objective 1 — Drive Paid Onchain Deals (Direct).** Curio Core IS the SP runtime that takes paid onchain PDP deals. Every operator running Curio Core on mainnet is, by definition, a direct contributor to Objective 1. The verification metrics in § 3.2 measure this directly: on-chain `ServiceProviderRegistry` entries whose endpoints resolve to Curio Core builds, on-chain `Proven(setId, …)` events submitted by those SPs, and on-chain FilecoinPay `settleRail` events attributable to those SPs. No interpretation needed — the chain logs the activity. **Objective 2 — Strengthen Network Profitability & Cryptoeconomics (Indirect).** Curio Core lowers the operator activation cost from a seven-service cluster to one ~90 MB static binary. Output: more solo and small-team operators can credibly run a paid PDP SP without the multi-month sealing-cluster on-ramp. Outcome: the FoC supply side grows beyond the existing sealed-deal SP set, drawing in operators (hobbyist DePIN, AI-data-archive teams, university research groups) who would otherwise sit out the network. Impact: more USDFC payment flow on FilecoinPay rails, more PDP proofs landing on-chain, healthier marginal economics per FIL of locked collateral. The KPI move is upstream of the network revenue line — we add operators who run with much lower fixed cost, so the per-operator break-even on paid deals drops, so more deals are profitable to take. **Objective 3 — Scale Paid Onchain Flagship Client Adoption (Indirect).** Curio Core is `synapse-sdk` wire-compatible end-to-end, which means any integration a flagship client builds against the canonical FoC stack (FilOzone FWSS + FilecoinPay + PDPVerifier) drives Curio Core unchanged. Output: a flagship client doesn't have to maintain a separate integration path for smaller SPs; the `synapse-sdk` call surface IS the integration surface. Outcome: when flagship clients expand provider sets (which Network Objective 3 explicitly contemplates), they can include Curio Core operators without engineering work on the client side. Impact: faster flagship onboarding velocity, because the long tail of new operators isn't a custom integration each time. **Per-milestone objective mapping.** Each milestone's primary objective contribution: * **M1** (mainnet-readiness + audit + v0.2.0-alpha) → *Objective 1* (Direct). Audit and gap closure are the prerequisites for any paid onchain deal landing on a Curio Core SP. * **M2** (upstream FoC contract absorption) → *Objective 1* (Direct) + *Objective 3* (Indirect). Staying wire-compatible with the canonical FoC stack is what keeps Curio Core eligible for flagship-client integrations without per-client engineering work. * **M3** (Lantern through the next mainnet nv upgrade) → *Objective 1* (Direct, infra prerequisite). A chain-node that breaks on nv upgrade means the SP stops settling rails; this milestone keeps th …[truncated] 3.2 Verification metrics | Metric | Data source | How it's measured | Target (end of grant) | |---|---|---|---| | Mainnet SPs running Curio Core | On-chain ServiceProviderRegistry + Curio Core operator self-report opt-in | Count of `ServiceProviderRegistry` entries whose service endpoint resolves to a Curio Core build (verifiable via the daemon's `web3_clientVersion` returning a `curio-core/` user-agent) | **≥ 3 mainnet providers** | | PDP proof cycles completed via Curio Core | On-chain PDPVerifier event log | Sum of `Proven(setId, …)` events where the submitting SP runs Curio Core (cross-referenced via 1) | **≥ 100 proof cycles** | | USDFC settled through Curio Core operators | On-chain FilecoinPay `settleRail` events | Sum of USDFC settlement amounts in events emitted by rails attributed to Curio Core SPs | **≥ 1,000 USDFC** | | Lantern release adoption (independent verification) | GitHub release downloads + Lantern beacon network self-report | Count of distinct Lantern peer IDs on the libp2p network running a release ≥ v1.6.0 | **≥ 25 distinct peers** | | synapse-sdk compat test suite pass rate | Public CI on github.com/Reiers/curio-core | Percentage of synapse-sdk-emitted RPC calls Curio Core handles correctly against the FoC reference | **100% of the documented surface** | | **(Objective 2)** Curio Core operator monthly infra cost vs. seven-service baseline | Operator self-reports in the public outreach log + author's own sp.reiers.io operating cost | Median monthly infra spend (USD-equivalent) for Curio Core operators (VM + bandwidth + storage), compared to a documented baseline cost for the canonical Lotus+Yugabyte+Curio+Boost+RPC+IPNI+dashboard stack. Both numbers published with line items. | **≥ 60% reduction in median monthly infra cost** vs. baseline, with ≥ 3 operator data points | | **(Objective 3)** Non-author client/tool integrations driving Curio Core or embedding Lantern | Public reference list on curiocore.io / golantern.io + linked external repos | Count of distinct, non-author-controlled GitHub repos that (a) call a Curio Core SP via synapse-sdk in CI, or (b) embed Lantern via `pkg/daemon`, with a working integration commit | **≥ 2 distinct non-author integrations** by 2026-12-31 | All metrics are externally verifiable - every signal is either on-chain, in a public registry, or in a public reference list with linked external repos. The two Indirect-objective rows are added so Objective 2 and Objective 3 are measurable inside the 6-month window rather than left as narrative. **Attribution + contingency.** *(1) How Curio-Core-operated SPs are attributed reliably.* We maintain a **public, opt-in operator registry** at `curiocore.io/operators` (mirrored in the curio-core repo under `OPERATORS.md`) where each Curio Core operator commits a signed self-attestation: their on-chain SP actor ID, the public RPC endpoint, and a signatur …[truncated] 3.3 References 1. Andrew Jackson (@snadrus) - Curio core team (FilOz). Co-designed Curio Core's bundle architecture in the public issue thread at https://github.com/Reiers/lantern/issues/11 (5 substantive comments from Day 1 onward) and reviewed the docs site (curio-core#66). Contact via Slack (@snadrus). 2. LexLuthr - Curio core team. (FilOz) Independent architecture review of Lantern's chain-node design at https://github.com/Reiers/lantern/issues/10 (closed clean 2026-05-22). Listed as named advisor on both repos. Has reviewed and signed off on the structural separation between Lantern and the Curio Core operator surface. Contact via Slack (@LexLuthr). 4.1 Monthly Operating Burn [ "$10-$100K (small team)" ] 4.2 What % of total team monthly burn depends on this grant? ~50% (covers the project-specific cost - lead engineer salary + the 6 servers dedicated to Curio Core + Lantern work for the 6-month window). Broader team operations and the remaining fleet are covered separately. 4.3 If this grant is not awarded, what happens? The lead engineer goes back to chasing paid work that competes for bandwidth, and the 6 servers we'd dedicate to Curio Core + Lantern get redirected to other paying workloads in the datacenter. Result: the lighter PDP/FoC client the Curio core team has said they want still arrives, but on a substantially slower timeline that doesn't align with the FoC mainnet schedule. 4.4 Core Team **Lead engineer:** Nicklas Reiersen (TSE Reiersen) — full-time on Curio Core + Lantern. * 8+ years in the Filecoin ecosystem. SAFT participant 2017; community contributor since 2019. * Protocol Labs (2021–2023): Lotus + Boost technical-support engineer. * Curio core team (2023–2026): contributor through engagement close-out May 2026. * Shipped Lantern through v1.5.7 (10 mainnet release tags between v1.2.1 and v1.5.7) and Curio Core v0.1.0-alpha.1. Also operates faucet.reiers.io (Plumbline), calix.reiers.io and calix-mainnet.reiers.io (Calix upgrade dashboards), filcensus.reiers.io (operator-level network intelligence). All live, all public. * **SP community reach:** active member of all the MinerX cohorts; first-name relationships with a substantial fraction of the current mainnet SP set across Europe, North America, and APAC. This is the relationship surface the M4 external-operator engagement programme runs on — the "who actually picks up the call" question is not a cold-outreach problem for this proposal. * **Marketing degree** (alongside the engineering work). Relevant because Curio Core's adoption isn't just an engineering problem; it's a client-onboarding problem. Knowing how to position a new SP runtime to operators who already have a working stack, and knowing how to onboard them once they're interested, is part of the work that makes the M4 + M6 external-operator targets credible. * GitHub: [github.com/Reiers](https://github.com/Reiers) * LinkedIn: [linkedin.com/in/nicklas-reiersen](https://www.linkedin.com/in/nicklas-reiersen/) * Website: https://reiers.io/ **Infrastructure footprint (Norwegian datacenter):** * **~30 servers** across the production fleet: GPU compute tier (RTX 6000 × multiple, Blackwell RTX 5080), storage tier, mainnet SP host (`f03678816` / sp.reiers.io), Yugabyte cluster (3-node) backing the mainnet Curio stack, and edge nodes for the public services. * **Three independent internet providers** for redundancy at the colocation site. This is what gives the mainnet SP, the public faucet, and the Lantern gateway their uptime story. * **Datacenter operations partner** maintains the physical fleet on a colocation contract; software-side operations sit with TSE Reiersen. **Honest project-specific budget for this proposal (6 months):** This is what the grant pays for, broken down without the hand-waving: | Line item | Per month | 6 months | |---|---|---| | Lead engineer salary (Nordic market rate, fully loaded with social fees + pension + holiday) | $16,167 | $97,000 | | Third-party security review at M1 (independent reviewer commissioned for the curio-core import surface + mainnet boot path; one-off, billed at milestone close) | — | $11,000 | | 6 servers dedicated to Curio Core + Lantern work (mainnet SP host, calibration dev box, CI runner, storage tier nodes, Yugabyte cluster share) — amortised hardware + …[truncated] 4.5 Has your team received a ProPGF grant or funding from PLFIF before? [ "Yes" ] 5.1 Key risks & dependencies External dependencies: - PDPVerifier / FWSS / synapse-sdk upstream churn. The FoC contract surface is still evolving; v3.4.0 ABI changes landed during the curio-core build-out. We absorb upstream changes inside the milestone budget, but a major redesign of the FoC contract layer mid-grant would compress M2 (upstream absorption). Mitigation: M2 is intentionally an absorption milestone, not a feature milestone, with budget for the work. - Filecoin network upgrades. Lantern's F3 trust anchor and actor bundle table need re-pinning at every nv upgrade. Mitigation: dedicated milestone (M3) with calibration-first dry-run captured in writing before mainnet. Technical risks: - The pgx-shaped harmonytask DB interface in upstream Curio is still evolving; we maintain the SQLite seam through Reiers/harmonyquery, which needs to keep parity with upstream pgx semantics for the parts of the task graph Curio Core uses. Mitigation: the seam is small (1300 LoC) and versioned; we pin upstream Curio commits explicitly in go.mod. - Cross-platform CGo edge cases. We commit to CGO_ENABLED=0 everywhere; any upstream change that introduces a hard CGo path inside the curio-core import graph is a blocker. Mitigation: CI on every push enforces CGO_ENABLED=0 builds, and we maintain the carve-out in Reiers/curio (forked from filecoin-project/curio) for any path that needs to be excluded behind a build tag. Team risks: - Solo operator. Bus factor is 1. Mitigation: everything is public, every decision is captured in writing (issue threads + memory notes + CHANGELOGs); a successor could pick up the codebase from the README and the open issues. The two named advisors (LexLuthr, @snadrus) have deep enough context to reorient a successor if needed. - Single funding source for the engineering time. The grant is the primary income source for this work during the 6-month window. Mitigation: milestone-based disbursement aligns operator cashflow with delivery; no upfront over-commitment. - External-operator dependency for M4 ("at least one non-author SP on mainnet"). Mitigation already baked in: (a) the M4 acceptance criterion has a fallback ("two operators have attempted onboarding with documented outcomes") so the milestone doesn't pivot on one operator's schedule; (b) the lead engineer's SP-community reach is the actual delivery mechanism here — active in all MinerX cohorts, on first-name terms with a meaningful share of current mainnet SPs, with a marketing degree that informs the positioning + onboarding work. The outreach programme is built on existing relationships, not on cold outreach hoping someone responds. Any feedback you have on the application process? The form is well-structured. One small note: section 3 (Objectives & KPIs) asks for both Direct/Indirect/N/A and asks for a verification-metrics table only when "Direct" is selected — it would help reviewers if the form rendered the verification-metrics field as conditional on at least one Direct selection (or made it visually clearer which sub-prompts apply to which selection). Not a blocker; just a small UX note. Anything else you want to share that we didn't ask? Three things worth surfacing for reviewers: (0) Minimum viable scope at lower funding levels. At $100,000 (instead of $130,000): keep M1-M4 only. That delivers (1) Curio Core mainnet-readiness + third-party security review + v0.2.0-alpha, (2) upstream FoC contract absorption + public compatibility matrix, (3) Lantern through the next mainnet nv upgrade at 0-epoch sync lag, and (4) Curio Core v0.3.0-beta + mainnet activation runbook + the external- operator engagement programme. The two cuts (M5 client tooling / IPNI / Session Key Registry, and M6 v1.0 + video + 30-min install target) move to post-grant or community-supported work. The shippable mainnet-ready beta still lands. At $150,000 (instead of $130,000): keep all M1-M6 as written and fund a second part-time contributor in M5-M6 dedicated to docs and operator tooling, plus expand the operator incentive pool from ~$1,000-equivalent USDFC starter float per operator to ~$3,000-equivalent. That materially raises the probability of >= 1 non-author mainnet operator by 2026-10-31 and turns the M4 fallback acceptance criterion into the primary one. We're explicit about this so reviewers calibrating the program's $200K average have a clean cut-down and an additive variant on hand without having to reconstruct them. (1) Track record. Previous milestone-based engagements through Filoz / Blueshift / PLFIF were delivered on time and accepted, with payments disbursed cleanly. The operator-to-payer relationship is established, the delivery cadence is known, and the milestone / payment workflow has already been exercised at scale. (2) The "Onchain Cloud" framing. Filecoin Onchain Cloud is explicitly identified in the 2026 Filecoin Network Strategy as the primary product surface for paid deals (Objective 1). Lantern + Curio Core is the only fully-open-source pure-Go implementation of the FoC operator stack today. Even setting aside what we ship next, the existence of an alternative implementation that's not maintained inside FilOz is a structural good for the network — it widens the implementation set, lowers the risk of single-implementation bugs, and gives PL/FilOz a credible reference point when evaluating whether their canonical implementation has the right shape. Contributing to Core Infrastructure? A pure-Go Filecoin light node (Lantern) and a single-binary FoC hot-storage SP (Curio Core), used today by the mainnet SP f03678816, the gateway.lantern.reiers.io public IPLD gateway, and the Curio core team as the reference for a lightweight PDP/FoC client. Objective 1 Direct Objective 2 Indirect Objective 3 Indirect Open Source Context N/A. Both Lantern and Curio Core are fully open source under **Apache-2.0 OR MIT** (contributor's choice). The dependency forks (Reiers/lotus, Reiers/harmonyquery, Reiers/curio) are also public and license-compatible with their upstream Filecoin Project repositories. No closed components. - https://github.com/Reiers/lantern - https://golantern.io