igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

docs: the paid pilot (Igneum 2.0, proving ladder step two): customer profile from the code, three ranked candidate classes with public prices, the pilot shape and pass condition, the missing-pipeline checklist, the outreach brief

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-08 15:45:41 +00:00
parent e35dc94d5b
commit 20106d7292
1 changed files with 88 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

88
docs/plans/paid-pilot.md Normal file
View file

@ -0,0 +1,88 @@
# The paid pilot: one external customer's exact workload, with repeat paid jobs
Pin: Igneum 2.0, "Architecture and product", the proving business ladder, step two. Written 8 October 2026, 16:5x BST, from the code and the landed measurements; nothing here assumes demand. The external proving market is unbuilt and stays out of every revenue assumption until a customer has paid for repeat jobs. Prices quoted from public sources carry their URL; where a market publishes no price the cell says "no public price". Chip percentages are not published.
## 1. The customer profile that fits the fleet's demonstrated edge
What the pipeline proves today, from the code:
- One program only. The host embeds two guests and refuses to run with any other: the shard program (program id 0x2b1a81cb..., 2,832,504 bytes) and the aggregator (0x474678f3...), both pinned in `proving/igneum-prove/elf/manifest.json` (SP1 crate 6.8.1, circuit v6.1.0) and checked at every start (`proving/igneum-prove/host/src/pinned.rs`, `include_bytes!` of the committed ELFs and verifying keys). The shard program is the Igneum chain's own EVM block transition: a range of transactions over a state witness, with rewards, the proving-pool credit and payouts applied by shard 0 (`proving/igneum-prove/core/src/shard.rs`, `ShardInput`, `shard_statement`). There is no path for an outside program.
- Inputs are a block fixture cut from a node's `igneum_exportSegments` dump by `igneum-prove-export` (`proving/igneum-prove/export/src/main.rs`); the plan cuts shards at the consensus proving budget `S_p`.
- Proof stages: execute, core, compressed; the aggregator folds shard proofs by recursion into one block proof and chains it to the previous segment's (`proving/igneum-prove/core/src/agg.rs`; `--mode chain`, `aggregate`, `verify-segment` in the host). The on-chain wrap (Groth16 or Plonk over bn254) is a trait method that returns an error and is not run (`proving/igneum-prove/host/src/proof_system.rs`).
- Verification: SP1's light verifier with the pinned verifying key (`--mode verify`); the node re-executes every carried record natively and drops a record whose result differs (litepaper, "How a block gets proven").
- The job loop is the chain's own: every 10 s the app asks its node for shards assigned to its vote keys (`igneum_getAssignedShards`), exports, cuts, proves `--mode compressed`, signs and submits (`igneum_submitProofRecord`) (`app/igneum-app/src/prover.rs`). No job enters from outside.
- Hardware, measured: NVIDIA only (SP1's CUDA prover is Linux x86_64; Windows runs it in WSL2). The fixed 4,717,439-cycle shard (`proving/fixtures/fees-v1-shards2.json`, shard 0) proves compressed on the patched server at threshold 2^26 in 13.2 s on an RTX 3060 12 GB (7,525 MiB peak) and 8.2 s on an RTX 4060 8 GB (7,532 MiB), 6.3 s on an RTX 4090 and a 5090 (8.0 GB) (`docs/analysis/prover-tiers-real-cards.md`, 6 October; the 8 and 12 GB rows re-measured 8 October, v6-coexist). At the 5.5 GiB dataset floor an 8 GB or 12 GB card cannot hold the miner and the prover at once (13.6 GB together) and time-shares them; 24 GB and 32 GB cards hold both.
- Proof delivery on the devnet today: shards assigned by sortition to eight provers for a 10 s exclusive window, then open to anyone; no bond, no deadline beyond the record window of 600 chain blocks (`docs/spec/07-execution.md` 7.2, 7.7).
The profile that fits that edge, stated as constraints rather than a market claim:
1. The workload is an SP1 program (the one well-tested backend; a second backend only where justified, never interchangeable). Programs for other zkVMs are out of the pilot.
2. The job is sized in the fleet's proven range: shards of a few million cycles each, proved compressed in seconds to tens of seconds on one consumer card, and aggregated by recursion. A job that needs one proof of hundreds of millions of cycles on one card inside a wall-clock bound of seconds does not fit a consumer fleet.
3. Delivery is minutes, not seconds. A customer whose product needs a proof under 10 s of a large block (Ethereum real-time proving) needs a cluster; the fleet's edge is many independent cards on domestic power, so the fit is throughput with latency in minutes.
4. The customer verifies the proof on its own chain with its own verifier, under a program id it pins. Igneum delivers a compressed proof (or the customer's own aggregation of ours); the final wrap for an EVM verifier is either run by the customer's existing pipeline or is the first item the pilot builds (section 4).
5. The customer pays on its own chain in its own currency (the launch rule of `docs/spec/05-fees-and-economics.md` 5.4; route 4 of `docs/commercial/prover-customer-brief.md`). Settlement in IGN waits for the proof bridge.
6. Repeat is intrinsic: the customer has a steady stream of the same program with new inputs (blocks, batches, light-client updates), so "repeat paid jobs" is the normal shape of their demand, not a favour.
## 2. Three candidate customer classes, ranked
The founder's word on who is "no idea who". These are classes with one named example each, chosen for fit to the constraints above, not for known interest. Every example is from public sources as of 8 October 2026 and has not been contacted. Nothing here claims demand.
| Rank | Class | Named example | Why they would pay | What they pay today |
|---|---|---|---|---|
| 1 | OP Stack rollups proving with OP Succinct (SP1 range proofs of their own blocks, aggregated and wrapped for L1) | Celo mainnet (OP Succinct Lite on SP1 Hypercube since 26 May 2026, per the Celo forum: https://forum.celo.org/t/op-succinct-sp1-hypercube-upgrade-live-on-celo-mainnet/13349); Mantle is the other named production user (https://blog.succinct.xyz/succinct-2025-recap/) | Their workload is the closest thing to ours that exists: SP1, EVM block execution, shard-sized range proofs, compressed then aggregated, with latency in minutes. A second supplier is a liveness and price story for a chain that depends on one prover network. | No fixed public price. Succinct's network sells by reverse auction in PROVE per PGU plus a dynamic base fee, no published rate (https://docs.succinct.xyz/docs/protocol/spn/auction). Succinct's own figure for OP Succinct: average proving cost 0.5 to 1 cent per transaction (https://blog.succinct.xyz/op-succinct/). A community estimate used for budgeting is USD 1.50 per billion PGU (https://hackmd.io/@damian666/rkqyehOOge); treat as an assumption, not a rate. |
| 2 | SP1 light-client bridges (sync-committee and storage proofs on a fixed program, one job per update, on a timetable) | Gnosis OmniBridge on SP1 Helios (Succinct reports more than USD 40 million TVL and USD 1.5 billion of stablecoin flow verified by its consensus proofs: https://blog.succinct.xyz/succinct-2025-recap/); IBC Eureka connects 120 Cosmos chains the same way | A fixed program, small inputs, a clock (every sync period or every update), tolerance for delivery in minutes: the exact "repeat paid jobs" shape, and a customer that cares more about a proof arriving every period from independent operators than about raw speed. | No public price per update. Paid through the Succinct network's auction (above); no per-proof rate is published. |
| 3 | Ethereum L1 block proving for the Ethereum Foundation's zkEVM programme (optional execution proofs today, mandatory later) | The ethproofs.org provers: ZisK on 8 x RTX 5090 and Axiom OpenVM 2.1 on 16 x 5090 (https://ethproofs.org/) | The programme is the largest standing demand for SP1-class proofs and it is public and measured. The buyer class (staking operators, client teams, the Foundation) would pay for proofs from independent operators once proofs are mandatory. | Cost, not price: USD 0.0057 (ZisK, 8 x 5090) and USD 0.0068 (Axiom, 16 x 5090) per block on ethproofs.org; no one pays per proof today (provers are funded, not paid per block). Ranked third because the real-time target (10 s per block on a rig under USD 100,000) is a cluster workload, not a consumer-card one; the fleet fits only the non-real-time tier. |
Taiko, the first proving customer named in `CLAUDE.md` (a based rollup whose multi-proof design accepts SP1 proofs, per `docs/commercial/prover-customer-brief.md`, approximate), belongs to class 1 and stays a candidate inside it; Celo is the named example because its OP Succinct deployment is the exact SP1 range-program shape the pilot pins, on the public record.
Not ranked, noted for the record: Kaspa's EVM layers (Igra, Kasplex) share the node lineage and a miner community (`docs/commercial/prover-customer-brief.md`), but neither publishes an SP1 workload today, so there is no exact workload to pin.
## 3. The pilot shape
One workload, one program id, one price, one clock. Everything below is the proposal the outreach brief carries; the numbers are ours to change before signature and are not a market claim.
| Item | The pilot |
|---|---|
| Workload | The customer's SP1 range program as deployed (rank 1: the OP Succinct range program; rank 2: the SP1 Helios update program). One program, one version, for the whole pilot. |
| Program identity | The customer's verifying key hash (the SP1 `vk` hash their on-chain verifier pins), recorded in the job and checked by the prover before any work (the same rule as `pinned.rs`: setup must derive the pinned id or the job is refused). A version change is a new pilot. |
| Inputs | The customer supplies the SP1 stdin blob per job (for a range proof: the L1 head, the L2 block range and the witness their own tooling produces); Igneum does not reconstruct inputs for a foreign chain. Inputs are content-addressed (sha256 in the job) so a re-run is reproducible. |
| Output | A compressed SP1 proof of that program over those inputs, plus the public values, returned to the address and endpoint the customer names. The customer's own pipeline aggregates and wraps for L1 as it does today; a wrap by Igneum is a phase-two item (section 4). |
| Verification rule | The customer verifies every proof with SP1's verifier against the pinned vk before it is counted; a proof that fails verification is not a delivered job and is not paid. Igneum keeps the same check on its side before sending (`--mode verify` generalised to the customer's vk). |
| Delivery time | 30 minutes from job receipt to proof returned, measured on the customer's clock. Reasoning: a range of OP Stack blocks is a few shards of our measured size (seconds each on one card) plus queueing across independent operators; minutes is the honest unit for a fleet, and 30 minutes leaves room for a reassignment after one failed card. |
| Price per job | Cost-based, quoted per billion cycles of the program's execution, with a floor per job. From the measured rows: a 4060 proves 4.7 M cycles in 8.2 s at 115 W, so one billion cycles is about 29 minutes of card time, about 0.06 kWh (USD 0.01 at USD 0.15 per kWh) plus about USD 0.005 of card amortisation (USD 300 over three years); a 5090 does the same in about 22 minutes at 330 W (USD 0.018 of power, USD 0.035 of amortisation). Pilot quote: USD 0.25 per billion cycles, minimum USD 2 per job, so the operator's margin is several times its cost on every card tier and the quote sits well under the USD 1.50 per billion PGU budgeting figure the SP1 community uses. Priced in dollars, paid on the customer's chain (route 4), never a fixed number after the pilot: the launch rule prices a job at or above the subsidy the card forgoes, which moves with network hash. |
| Repeat cadence | One job per hour for rank 1 (a range proof an hour is a small slice of a chain's stream and leaves their existing supplier in place); one job per update for rank 2 (about one per sync period). |
| Pass condition | 500 paid jobs over 4 weeks, at least 99 percent delivered inside 30 minutes and every one verified by the customer, paid at the quoted rate with no job disputed. Reasoning: four weeks crosses more than 600 hourly program epochs and the operators' own churn, so a pass is not one good week; 500 jobs resolve the on-time rate to a fifth of a percent and are enough for the per-card cost table to be read back against real power bills; "paid" means money moved on the customer's chain for every counted job, so a subsidised or waived job does not count. Fewer than 500 paid jobs, or any week under 99 percent, is a fail, published either way. |
## 4. What the pipeline is missing to serve it
Checklist from the code, each item with the file or crate it touches. Nothing below is built; the first three are the gate for accepting a single job.
- [ ] External program identity. The host accepts only the embedded guests (`proving/igneum-prove/host/src/pinned.rs`; `proving/igneum-prove/elf/manifest.json`). Needed: a permitted-programs registry (program id, vk hash, SP1 circuit version) that the host loads for a job, with the same "setup must derive the pinned id" refusal; the protocol pins the list (Igneum 2.0 pin: program identities and verifier versions pinned in the protocol).
- [ ] Generic inputs. The fixture path is Igneum's block fixture (`proving/igneum-prove/export/src/main.rs`, `proving/igneum-prove/core/src/fixture.rs`). Needed: a job input blob (SP1 stdin bytes, content-addressed) fed to `prove_shard` in `proving/igneum-prove/host/src/proof_system.rs` without the shard statement wrapper.
- [ ] Verification against the customer's vk. `--mode verify` uses the pinned key (`host/src/main.rs`). Needed: verify with the job's vk before sending.
- [ ] Job intake. The only job source is the chain's shard assignment (`igneum_getAssignedShards`, `igneum_exportSegments`, `igneum_submitProofRecord`, consumed by `app/igneum-app/src/prover.rs`). Needed: a job object (program id, input hash, deadline, price, payout address, customer endpoint), an intake endpoint in the node's proof pool (the node repository, `igneum-node`), and a second branch in the app's prover loop that takes a customer job when no chain shard is assigned (spec 7.2's sortition stays untouched: external jobs never pre-empt the chain's own proofs).
- [ ] Aggregation and wrap. The aggregator guest is Igneum's segment statement (`proving/igneum-prove/core/src/agg.rs`, `aggregator/src/main.rs`); `wrap` is unimplemented (`proof_system.rs`). For the pilot the customer aggregates and wraps; phase two is a generic aggregation program and the bn254 wrap, so Igneum can deliver an on-chain-verifiable proof.
- [ ] Payment. Route 4 (customer chain, payout contract keyed by miner address) is "Designed" with no code (`docs/spec/05-fees-and-economics.md` 5.4; `docs/commercial/prover-customer-brief.md` route 4); `pool/src/payout.rs` pays IGN inside Igneum's pool only. Needed: the payout contract on the customer's chain, the job-to-payout record, and a receipt the app shows; settlement in IGN waits for the proof bridge (spec 7.3) and is out of the pilot.
- [ ] SLA. The chain has a 10 s exclusive window and open claiming with no bond and no job deadline (`docs/spec/07-execution.md` 7.2, items 3 and 4); the brief's bond and timeout are open (O-5.6). Needed for a customer: a deadline on the job, a reassignment rule when the first operator misses it, a retry budget, and a delivered-on-time log that produces the pass condition's numbers (the app's `/api/state` tile and the node's `igneum_getProvingStatus` are where the counters live today).
- [ ] Memory profile shipped. The patched `sp1-gpu-server` that fits 8 and 12 GB cards (threshold 2^26) is a served artefact, not in the shipped app (litepaper, "Proving"); the served sm_89 tarball still carries the stock server in `home/.sp1/bin` (found 8 October, with the floor lane). Needed: the patched server in the app payload for every tier, and the time-sharing rule for 8 and 12 GB cards (mine or prove, never both at the dataset floor).
- [ ] Reporting. A per-job record (program id, input hash, cycles, card, seconds, verified, paid) kept by the operator and summarised for the customer; today's RESULT lines go to a log only (`host/src/main.rs`).
## 5. Outreach brief (one page, served text rules: no founder name, UK English)
**Igneum proving pilot**
A GPU-secured network for Ethereum-compatible applications and verifiable computation.
Igneum is a proof-of-work network mined on consumer graphics cards, where the NVIDIA cards that secure the chain also prove its blocks with SP1 and can prove yours. We are looking for one customer with one exact workload for a paid pilot.
What we have measured. The chain's own block shards (about 4.7 million cycles each) prove compressed in 8 to 13 seconds on 8 GB and 12 GB cards and in 6 seconds on 24 GB and 32 GB cards, on rented hardware from eleven card models, with every proof verified. Shard proofs are aggregated by recursion into one proof per block. Proving runs on NVIDIA cards; AMD and Apple cards mine. Proven execution is not finality, EVM compatibility is not Ethereum security, and zero-knowledge proofs are not privacy.
What the pilot is. One SP1 program of yours, one version, pinned by its verifying key. You send inputs per job; we return a compressed proof you verify with SP1's verifier against that key before it counts. Delivery inside 30 minutes of receipt. One job an hour, or one per update, for four weeks. A proof that fails your verifier is not a delivered job and is not paid.
What it costs. A pilot quote of USD 0.25 per billion cycles of your program, minimum USD 2 per job, paid in your currency on your chain to a payout contract keyed by the operator who delivered. The quote is built from measured power and card cost on the fleet and is stated plainly so you can compare it with what you pay now.
What we ask of you. The program and verifying key as deployed; at least 100 historical inputs with expected public values so our provers and your verifier agree before any job carries value; the deadline and the maximum cycles per job; the address that receives proofs; and a published pass or fail at the end: 500 paid jobs over four weeks, 99 percent inside the deadline.
What we do not claim. The external proving market is not yet built and is not in our revenue assumptions. Your pilot would be the first external workload on the network; the job intake, payment contract and delivery log are built for it and published with their measurements. Nothing in this brief is an offer to sell a token.
Contact: through the repository and the site's team page.