A Filecoin hot-storage SP in one binary.

Curio Core bundles PDP, payments, a WebUI, and an embedded chain node into one ~90 MB static Go binary. One VM. One operator. No Yugabyte, no filecoin-ffi, no Rust.

What is Curio Core

7 services → 1 binary

Today, running a Filecoin Onchain Cloud SP means standing up a small datacenter. Curio Core collapses it onto one machine.

Today's stack
  • ×Lotus full node (~76 GB)
  • ×3-node Yugabyte cluster
  • ×Curio
  • ×Boost
  • ×Eth RPC provider
  • ×IPNI indexer
  • ×Dashboard / monitoring
7 services. Multi-host. Sealing-era assumptions baked in.
Curio Core
  • Embedded chain node (Lantern, ~1 GB)
  • SQLite — single file
  • PDP task pipeline (v0 + v1)
  • HTTP piece upload + download
  • FEVM signing + USDFC payments
  • IPNI content routing
  • Operator + client WebUI
1 binary. 1 VM. Hot storage only. No sealing.
Proof of life

8 PDP cycles. Zero ops.

The proof loop is self-sustaining on calibration. Deal accept → piece park → proof submit → settle, on a schedule, signed by the binary itself.

Dataset
#13977
live on calibration FilOzone
Provider ID
26
calibration / self-registered
Successful cycles
8 / 8
overnight, unattended
Settle txs
5
USDFC rail, confirmed on-chain
// first on-chain tx (1-wei self-transfer)
calibration block 3,742,933
// first prove tx
0x8dae0bab……1a02d  tx_success=1
// loop self-recovered after 70-epoch lag during a 108-min wait
postmortem fixed in lantern v1.5.3 + curio fork retry budget → 25 min
What's in / out

Opinionated, on purpose

Curio Core is the hot-storage half of an SP — and only that. The scope is small so the binary stays small and the operator surface stays human.

In scope
  • · PDPv0 + v1 task pipeline
  • · HTTP piece upload + download
  • · FEVM tx signing + broadcast
  • · FilecoinPay rail settlement
  • · USDFC payments
  • · IPNI content routing
  • · Operator + client WebUI
  • · synapse-sdk wire-compatible
Out of scope — forever
  • · Sealing, PoRep, SDR
  • · filecoin-ffi syscalls
  • · WindowPoSt / WinningPoSt
  • · mk12 / Boost market deals
  • · Yugabyte / Postgres / clustering
  • · Multi-node failover
  • · Separate full Lotus node
Inside the binary

One process, four jobs

⛓  Embedded chain node
Lantern compiled in as a Go module. End-to-end cryptographic verification — BLS, F3, DRAND, IPLD. No external RPC dependency for proofs.
📦  Storage pipeline
HTTP upload → local piece park → PDPv0 task scheduler → proof submit. Pure Go from end to end. SQLite-backed state.
💸  Payments
FEVM tx signing, FilecoinPay rail discovery, USDFC settlement on a 10-minute tick. Five settles confirmed on calibration so far.
🖥  WebUI
Server-rendered operator + client dashboards. Dark mode. Zero JS framework. Loads in one round-trip.
Status

Pre-alpha. Not yet public.

Curio Core runs end-to-end on calibration today. Mainnet readiness is a Q3 milestone. The repo opens when the API surface stabilises — drop your email and you'll be first in line.

No spam, no list rental. One mail when alpha opens.
Curious about the chain-node half? Meet Lantern →
FAQ

Honest answers

Is this a fork of Curio? +
It's a downstream of Curio's PDP pipeline with the sealing surface removed and an embedded chain node added. Upstream pins are tracked in internal-notes/SCOPE-DIFF.md.
Will it support sealing? +
No, by design — forever. Sealing pulls in filecoin-ffi, Rust, multi-host assumptions. Curio Core is the hot-storage layer. Run Curio classic for sealed-deal SPs.
Why SQLite, not Postgres? +
Single-server is the whole point. If you outgrow SQLite, you've outgrown Curio Core — run the full Curio stack instead.
Why pure Go, no CGo? +
Cross-compile to any platform from any platform, one static binary, no toolchain drift. The whole point of Curio Core is "one operator, one VM, one weekend".