diff --git a/docs/analysis/security-budget.md b/docs/analysis/security-budget.md new file mode 100644 index 000000000..4ce94283f --- /dev/null +++ b/docs/analysis/security-budget.md @@ -0,0 +1,136 @@ +# Security budget stress: emission through six halvings at three price inputs + +3 October 2026. Arithmetic on the emission schedule of spec 2.5 at three coin prices. The prices are inputs chosen to span two orders of magnitude so the arithmetic can be read; they are assumptions, not predictions, and nothing here says what the coin will be worth. The question the table answers: at each price, in which year does the money reaching miners fall below a stated floor, with low fees and no external proving demand. + +## 1. Inputs + +| Input | Value | Label | +|---|---|---| +| Emission, years 1 and 2 | 1,000,000,000 IGN per year of 365.25 days, minus the 30-day ramp in year 1 (about 37 million IGN never minted) | Implemented, spec 2.5 | +| Halving | Every 63,115,200 DAA seconds (two years), at the start of years 3, 5, 7, 9, 11 and 13: six halvings in the table | Implemented, spec 2.5 | +| Split | 80% to the block producer, 20% to the proving pool | Implemented, spec 2.5 | +| Low price | USD 0.005 per IGN (USD 20 million at the cap) | Assumption | +| Base price | USD 0.02 per IGN (USD 80 million at the cap) | Assumption | +| High price | USD 0.10 per IGN (USD 400 million at the cap) | Assumption | +| Low fees | Priority fees reaching miners and provers: USD 20,000 per year in total. Burns (base fee in both dimensions, unregistered app share): USD 30,000 per year | Assumption, chosen so that fees are too small to matter; both are flat across the years on purpose | +| External proving demand | Zero. No IGN-settled jobs, so no 10% job burn and no job revenue to provers | Assumption | +| Block rate | One block a second at launch; the emission is per DAA second, so the block rate does not change the yearly figure | Spec 2.5 | + +The price stays constant across all 14 years in each column. That is the point of the exercise: the table shows what the schedule alone does, with no appreciation to rescue it. + +## 2. Emission by year + +| Year | Halvings so far | Emission, million IGN | To miners (80%), million IGN | To provers (20%), million IGN | +|---|---|---|---|---| +| 1 | 0 | 963.0 | 770.4 | 192.6 | +| 2 | 0 | 1,000.0 | 800.0 | 200.0 | +| 3 | 1 | 500.0 | 400.0 | 100.0 | +| 4 | 1 | 500.0 | 400.0 | 100.0 | +| 5 | 2 | 250.0 | 200.0 | 50.0 | +| 6 | 2 | 250.0 | 200.0 | 50.0 | +| 7 | 3 | 125.0 | 100.0 | 25.0 | +| 8 | 3 | 125.0 | 100.0 | 25.0 | +| 9 | 4 | 62.5 | 50.0 | 12.5 | +| 10 | 4 | 62.5 | 50.0 | 12.5 | +| 11 | 5 | 31.25 | 25.0 | 6.25 | +| 12 | 5 | 31.25 | 25.0 | 6.25 | +| 13 | 6 | 15.625 | 12.5 | 3.125 | +| 14 | 6 | 15.625 | 12.5 | 3.125 | + +Sum through year 14: 3,931 million IGN of the 4,000 million cap. + +## 3. Dollars to miners, by price input + +Emission only. Add USD 16,000 a year for the miners' part of the low-fee assumption (80% of USD 20,000); it does not change any row. + +| Year | Low, USD 0.005 | Base, USD 0.02 | High, USD 0.10 | +|---|---|---|---| +| 1 | 3,852,000 | 15,408,000 | 77,040,000 | +| 2 | 4,000,000 | 16,000,000 | 80,000,000 | +| 3 | 2,000,000 | 8,000,000 | 40,000,000 | +| 4 | 2,000,000 | 8,000,000 | 40,000,000 | +| 5 | 1,000,000 | 4,000,000 | 20,000,000 | +| 6 | 1,000,000 | 4,000,000 | 20,000,000 | +| 7 | 500,000 | 2,000,000 | 10,000,000 | +| 8 | 500,000 | 2,000,000 | 10,000,000 | +| 9 | 250,000 | 1,000,000 | 5,000,000 | +| 10 | 250,000 | 1,000,000 | 5,000,000 | +| 11 | 125,000 | 500,000 | 2,500,000 | +| 12 | 125,000 | 500,000 | 2,500,000 | +| 13 | 62,500 | 250,000 | 1,250,000 | +| 14 | 62,500 | 250,000 | 1,250,000 | + +## 4. Dollars to provers, by price input + +Emission only. Add USD 4,000 a year for the provers' part of the low-fee assumption. With no external demand this is the whole proving income. + +| Year | Low, USD 0.005 | Base, USD 0.02 | High, USD 0.10 | +|---|---|---|---| +| 1 | 963,000 | 3,852,000 | 19,260,000 | +| 2 | 1,000,000 | 4,000,000 | 20,000,000 | +| 3 | 500,000 | 2,000,000 | 10,000,000 | +| 4 | 500,000 | 2,000,000 | 10,000,000 | +| 5 | 250,000 | 1,000,000 | 5,000,000 | +| 6 | 250,000 | 1,000,000 | 5,000,000 | +| 7 | 125,000 | 500,000 | 2,500,000 | +| 8 | 125,000 | 500,000 | 2,500,000 | +| 9 | 62,500 | 250,000 | 1,250,000 | +| 10 | 62,500 | 250,000 | 1,250,000 | +| 11 | 31,250 | 125,000 | 625,000 | +| 12 | 31,250 | 125,000 | 625,000 | +| 13 | 15,625 | 62,500 | 312,500 | +| 14 | 15,625 | 62,500 | 312,500 | + +## 5. Burns, separately + +Burns reach nobody. They are listed so that nobody adds them to the security budget by mistake. + +| Burn | Rule | Under the assumptions | +|---|---|---| +| Base fee, both gas dimensions | 100% burned (spec 5.1) | Inside the USD 30,000 per year assumption | +| Unregistered app share | The 20% of a priority fee attributed to a contract with no registered developer is burned (spec 5.2) | Inside the USD 30,000 | +| 10% of IGN-settled external jobs | Burned (spec 5.4) | Zero, because external demand is zero | +| The launch ramp | About 37 million IGN never minted (spec 2.5) | Not a burn; listed because it is the only other supply reduction | + +A burn is not security spend. The base fee being burned in full means usage of the chain, by itself, pays miners nothing; only the priority fee does. That is Ethereum's rule and the trade-off is stated here rather than hidden: it removes wash-gas attacks on block space (ledger E3) at the cost of fee revenue to security. + +## 6. The floor + +The floor: USD 1,000,000 per year reaching miners. + +Why that number. It is the electricity, at USD 0.12 per kWh, of about 3,000 consumer cards at 300 W running all year (3,000 x 0.3 kW x 8,766 h x 0.12 = about USD 946,000, approximate). 3,000 cards is the fleet size at which one operator with 1,000 cards, a single mid-size farm, approximate, holds one third of the 30-day vote weight. One third is the threshold the litepaper names: beyond it two locks can coexist under a partition (spec 3.7 item 1). Below the floor the schedule cannot pay for a fleet large enough to keep a single ordinary farm under a third, so finality's safety rests on fewer, larger parties. The floor is about miners because the finality weight is blue blocks, which only miners make; the provers' line is the proving capacity, not the security of history. + +Readers with a different electricity price or card count can scale the floor; the year it is crossed moves by at most one halving for a 2x change in the floor. + +## 7. When the floor is crossed + +| Price input | Years at or above the floor (emission to miners) | First year below the floor | What emission to miners is that year | +|---|---|---|---| +| Low, USD 0.005 | 1 to 6 (years 5 and 6 sit on the floor at USD 1,000,000) | Year 7, after the third halving | USD 500,000 | +| Base, USD 0.02 | 1 to 10 (years 9 and 10 sit on the floor) | Year 11, after the fifth halving | USD 500,000 | +| High, USD 0.10 | 1 to 14 | Not within six halvings; year 15 would be USD 625,000 | USD 1,250,000 in years 13 and 14 | + +Under the low input the chain has six years before the schedule stops paying for the floor fleet. Under the base input, ten. Under the high input, more than fourteen. In every column the crossing comes, because the schedule halves for ever and the price is held flat. + +## 8. What the design relies on by the crossing year, and what it does not + +| Relies on | How much, in the low case at year 7 | Where the rule is | +|---|---|---| +| Priority fees to miners | The shortfall is USD 500,000 a year, which at USD 0.005 is 100 million IGN a year, or about 3.2 IGN of miner priority fee per block at one block a second (100,000,000 / 31,557,600). The chain needs that much tip volume, or the floor is not met | Spec 5.2: 80% of the priority fee to the producer and provers | +| In-chain proving demand through the tip share | The provers' part of the 80% is the same tip volume; it does not add to the miners' line | Spec 5.2, 5.3 | +| External proving demand | Pays provers 90% of job fees and burns 10% once settled in IGN. It does not pay miners and does not count toward the floor. It keeps cards on, which is a proving-capacity benefit and not a hashrate benefit, because the lottery and the proving are separate on purpose | Spec 5.4; CLAUDE.md (Aleo lesson) | +| The block rate steps (4 and 10 blocks a second) | Change nothing: emission is per DAA second, not per block | Spec 2.5 | + +| Does not rely on | Why it is not in the table | +|---|---| +| Price appreciation | The price is flat in every column. A column with a rising price would move the crossing year, and it would be a prediction | +| Burns | They reach nobody (section 5) | +| A tail emission | None exists. Spec 2.5 and the litepaper state the halving schedule as a bet; a tail can be added only by a 90% upgrade signal (spec 5.7). This table is the case for keeping that door open, not a decision to use it | +| A treasury or a fee to the team | None exists | + +## 9. What this analysis does not do + +- It does not model hashrate. Dollars to miners is not hashrate; it is the ceiling on what hashrate can be paid for. +- It does not model fee growth, user growth or proving demand growth. Those are the things the design relies on, and this file says so instead of assuming numbers for them. +- It does not compare with other chains. Bitcoin's and Kaspa's security budgets after their halvings are a known discussion, approximate, and belong in a cited comparison, not here. +- It does not set policy. The decision it informs (whether a tail emission should be specified before genesis or left to the 90% signal) has no open item in `docs/spec/06-open-items.md` yet; today the spec leaves it to the signal, and this file is the reason to add one. diff --git a/docs/benchmarks/proving-e2e.md b/docs/benchmarks/proving-e2e.md new file mode 100644 index 000000000..b501ba7ec --- /dev/null +++ b/docs/benchmarks/proving-e2e.md @@ -0,0 +1,152 @@ +# End-to-end proving benchmark standard + +Version 0.1, 3 October 2026. This standard replaces the "a 12 GB card proves one shard in about 20 s" gate (litepaper Proving, roadmap phase 2, spec 5.1). It is the phase 2 pass mark and the published measurement the prover customer brief points at. Nothing in it has been run. Status: designed. + +## 1. Why the shard gate was the wrong gate + +A per-shard time is met by shrinking the shard. The shard planner cuts a segment at transaction boundaries so each shard's proving cost is at most `S_p` (`docs/design/execution-layer.md` 5.1). `S_p` is the project's own number. Halve it and every shard proves twice as fast, the 20-second mark is passed, and nothing about the chain's capacity has changed: there are twice as many shards, twice the aggregation work, twice the witness traffic, and the per-shard fixed costs (program load, witness fetch, proof emission) are paid twice. The backlog, which is what a user and a customer feel, can grow while the gate reads green. + +The trap is shrinking the shard. The standard below prevents it by fixing the unit of measurement outside the planner's reach: a whole published block, proven end to end, from the moment a prover sees the job to the moment a full node accepts the proof. The planner's choice of `S_p` is inside the measurement. A smaller shard that helps shows up as a shorter end-to-end time and a flat backlog; a smaller shard that only moves cost shows up as the same time and a rising backlog. + +## 2. Fixed published workloads + +Three workloads, published as files under `tools/bench-e2e/workloads/` with a genesis state, a transaction list and a SHA-256 of both, so every operator proves the identical bytes. The files do not exist yet; the execution engineer writes them with the phase 2 implementation. Each workload is one chain block's segment. + +| Id | Workload | Content | Why this one | +|---|---|---|---| +| W1 | Transfers | 200 simple IGN transfers between 200 pre-funded accounts: 21,000 gas each, 4,200,000 gas total, 200 pgas each at the prototype table (40,000 pgas, to be re-stated at calibration) | The cheapest block to prove per transaction. Sets the floor of fixed cost per shard and per proof | +| W2 | Contract calls with keccak | 20 calls to a published contract: each call runs the `hashLoop` pattern of `tools/evm-smoke` at 200 iterations (98,900 gas estimated with the fold on the v3 simnet) plus one storage write with an event; about 2,000,000 gas, pgas from the calibrated table | Keccak is the opcode a zkVM pays most for relative to native execution. This block is the one a per-transaction gate would hide | +| W3 | Full budget | A block whose proving cost is exactly the consensus proving-cost budget `B_p`: the W2 call repeated until the planner refuses the next one, padded with W1 transfers to the gas limit | The worst block the chain can accept. If W3 cannot be sustained, the budget is wrong, not the gate | + +Rules for the workloads: + +1. The genesis state and the transaction bytes are frozen with the proof-system version. A new `ProofSystem` version (design 5.6) republishes all three with new hashes; results under one version are never compared with results under another. +2. `B_p` is set from this benchmark, not the other way round. The first run uses the provisional `B_p` of the phase 2 implementation; W3 is regenerated when `B_p` changes and the standard records the value used. +3. Nobody tunes the planner against the workloads. The planner's parameters (`S_p`, the shard count rule) are fixed in the release before the run and published with it. + +## 3. The measured path + +The clock starts when a prover's client receives the job and stops when a full node that did not produce the proof accepts the proof record. Every stage is timestamped by the prover and the verifying node, and every stage is reported, because an operator who proves fast but queues slow is not sustaining anything. + +| Stage | Starts | Ends | Who stamps it | +|---|---|---|---| +| Queueing | Job received (shard assignment seen, or segment executed for an open shard) | A card starts on it | Prover client | +| Transfer | Witness request sent | Witness bytes complete and checked against the segment hash | Prover client | +| Proving | Card starts | Shard proof emitted | Prover client | +| Aggregation | First shard proof of the segment available | Segment proof emitted (recursion over the shards and the previous segment proof) | Aggregating client | +| Verification | Proof record gossiped | A non-producing full node verifies it and the native-execution veto passes (design 5.5) | The verifying node | +| End to end | Job received | Accepted | Both; the difference of the two wall clocks is reported with the clock-sync method used | + +The wrapped proof (Groth16 or Plonk over bn254, design 5.3) is a fourth stage measured separately for the bridge and light-client case (O-10.7). It is not in the end-to-end figure for the chain, because the chain accepts the segment proof. + +## 4. Reported figures + +Per workload, per hardware configuration, from a continuous 2-hour run in which the workload is issued at the chain's block rate (one segment per second at launch) so that the provers must keep up, not catch up. + +| Figure | Definition | +|---|---| +| Median | The 50th percentile of end-to-end time over the run | +| Slowest 5% | The 95th percentile | +| Slowest 1% | The 99th percentile | +| Per-stage medians | Queueing, transfer, proving, aggregation, verification, each at p50 and p99 | +| Failure rate | Jobs whose proof was never accepted, divided by jobs issued. A failure is counted whether the cause was a crash, an out-of-memory, a bad proof or a timeout | +| Retry rate | Jobs proven more than once by the same operator before acceptance, divided by jobs issued | +| Backlog | Shards issued and not yet accepted, sampled every 10 s for the 2 hours, reported as the series, its maximum, and the slope of a least-squares line through the second hour. A slope above zero is a growing backlog | +| Throughput | Segments accepted per second over the second hour, against the issue rate | + +A run is reported whole or not at all. A run that is stopped early is reported as a failure with the time it stopped. + +## 5. Full cost per proof + +Cost is reported per accepted segment proof, in dollars, with each input stated so that a reader can substitute their own tariff. Nothing is netted against rewards; this is cost only. + +| Component | How it is computed | Stated inputs | +|---|---|---| +| Electricity | Card and host power at the wall, measured with a meter over the run, times the tariff, divided by accepted proofs | The tariff. The standard reports two: $0.12 per kWh and $0.30 per kWh, chosen as a low and a high domestic rate, approximate. The operator also reports their own | +| Host amortisation | Purchase price of the card and the host it needs, divided by an assumed life of 3 years at 24 hours a day, times the run's hours, divided by accepted proofs | Purchase price (a receipt or a listing on the run date) and the 3-year life | +| Bandwidth | Witness bytes in plus proof bytes out, times a per-gigabyte price, divided by accepted proofs | The per-gigabyte price. The standard reports $0.01 per GB and $0.10 per GB, approximate; a metered residential line reports its own | +| Failed work | Electricity and amortisation spent on jobs that were not accepted (failures, retries, work superseded by a faster prover), spread over the accepted proofs | Counted from the same logs; nothing extra | +| Total | The sum of the four, at both tariffs and both bandwidth prices, as a range | | + +The cost of a 20% pool share or an external job fee does not appear here. Those are revenue and belong in `docs/analysis/security-budget.md` and `docs/design/payment-routes.md`. + +## 6. Eligible consumer cards + +Mining compatibility and proving compatibility are reported separately, because they are different workloads: mining is the random-access lottery hash (bench-log), proving is the zkVM. A card can be in one column and not the other. + +| Card | Memory | Mining: lottery hash | Proving: this standard | +|---|---|---|---| +| NVIDIA RTX 5090 | 32 GB | Measured: 229 Mhash/s at 1 GiB, bit-exact (bench-log, 3 October 2026) | Not run | +| NVIDIA RTX 4090 | 24 GB | Not run | Not run | +| NVIDIA RTX 4070 | 12 GB | Not run | Not run; the design's reference card class ("a 12 GB card") | +| NVIDIA RTX 3060 12 GB | 12 GB | Not run | Not run; the phase 2 gate names a "3060-class card" (ledger P1) | +| NVIDIA RTX 3080 | 10 GB | Not run | Not run; below the 12 GB design floor, listed to measure the floor | +| AMD RX 7900 XTX | 24 GB | Not run (discrete AMD never run, O-1.15) | Not run | +| AMD RX 6700 XT | 12 GB | Not run | Not run | +| AMD gfx1036 (Ryzen 7 9800X3D integrated) | shared | Measured: 4.38 Mhash/s on 1 compute unit, bit-exact (bench-log) | Not eligible: shared system memory | +| Apple M5 Max (40 GPU cores) | 64 GB unified | Measured: 45.2 Mhash/s at 1 GiB, bit-exact (bench-log) | Not run | +| Apple M-series, 16 GB unified | 16 GB unified | Not run | Not run | +| Intel Arc A770 | 16 GB | Not run | Not run | + +A card enters the eligible list for proving when three unrelated operators (section 8) have sustained W1, W2 and W3 on it with a flat backlog. Until then the list is a list of candidates, and the litepaper's "12 GB or more proves full shards" is a design target. + +## 7. The acceptance standard + +Verbatim, the pass mark for phase 2: + +> At a declared workload and hardware configuration, independent operators can sustain the advertised throughput without a growing proof backlog. + +Applied to this standard: + +| Term | Meaning here | +|---|---| +| Declared workload | W1, W2 or W3 by hash, under a named proof-system version | +| Declared hardware configuration | Card model, card count per host, host CPU and RAM, driver and toolchain versions, as a published fingerprint | +| Advertised throughput | The issue rate of the run: one segment per second at launch. The project advertises no higher rate than the one sustained in the published runs | +| Independent operators | Three unrelated operators as defined in section 8, each sustaining it on their own run | +| Sustain | The full 2-hour run with a failure rate under 1% and a slowest-1% end-to-end time under the proof lag the litepaper states (60 s at launch) | +| Without a growing proof backlog | The second-hour backlog slope is at or below zero and the maximum backlog is under 60 segments | + +A pass is per workload and per configuration. "Phase 2 passed" means W1, W2 and W3 all passed on at least one consumer configuration from section 6 with at most one card per host. A pass on a multi-card host or a datacentre card is reported but does not pass the phase, because the chain's claim is consumer hardware. + +## 8. Reproduction protocol + +### 8.1 What counts as unrelated + +Three operators are unrelated when every row holds for every pair: + +| Test | Requirement | +|---|---| +| Person | Different natural or legal persons; none is the project, an agent of it, or paid by it for the run (a published fixed reproduction reward, equal for everyone and announced before the run, is allowed and disclosed) | +| Hardware | Bought separately; no shared host, card, rack or power meter | +| Network | Different autonomous systems, verified by the IP in the published logs; not the same residential ISP account | +| Location | Different physical sites | +| Software | The same published release by hash; nobody receives a private build | +| Money | No payment, loan or equipment between them or from the project, beyond the disclosed reproduction reward | + +An operator declares each row in their report and signs it with the vote key that mined on the devnet under the same fingerprint, so a report is tied to a key with a history. + +### 8.2 Steps + +1. The project publishes: the release (binary hashes, source tag), the three workload files with hashes, the run script `tools/bench-e2e/run.sh`, the report format, the proof-system version, `B_p` and `S_p`, and the date range. +2. Each operator runs the 2-hour run for each workload on their configuration, with a wall-power meter and NTP-disciplined clocks, and keeps raw logs. +3. Each operator publishes the report (section 4 figures, section 5 costs, the hardware fingerprint, the declarations of 8.1) and the raw logs, signed. +4. The project publishes all reports unedited, pass or fail, next to its own run, on the bench page, and links each from `docs/evidence.md` row 15 and row 16. A failing run is as public as a passing one. +5. The eligible list (section 6) and the phase gate (section 7) are updated from the published reports only. + +### 8.3 What the project may not do + +- Change `S_p`, `B_p`, the planner or the workloads between the announcement and the end of the date range. +- Pick which reports to publish. +- Count its own run as one of the three. +- Advertise a throughput higher than the lowest of the three passing runs. + +## 9. Open items + +| Item | What closes it | +|---|---| +| The workload files and `tools/bench-e2e/` | Written with the phase 2 SP1 implementation (execution engineer) | +| The provisional `B_p` and `S_p` | The project's own first run, published before the external runs | +| The wrapped-proof stage on consumer hardware | O-10.7, measured in the same campaign | +| The reproduction reward and who pays it | `docs/plans/funding.md`, challenge reward row | +| Whether a 10 GB card can prove W3 at all | The RTX 3080 row of section 6 | diff --git a/docs/design/payment-routes.md b/docs/design/payment-routes.md new file mode 100644 index 000000000..5b29a2d66 --- /dev/null +++ b/docs/design/payment-routes.md @@ -0,0 +1,94 @@ +# Payment routes: who pays whom, in what, and what is burned + +3 October 2026. Every flow of value the protocol and its surroundings define, drawn once and tabulated once. Rules are from spec 2.5 (emission), 5.1 to 5.4 (fees, pool, jobs) and 7.3 (bridges); the client fee is from the litepaper ("What a miner's hour looks like"). Status: the emission split and the gas routes are implemented and tested on the devnets (`docs/evidence.md` rows 20, 22); the pool payout, the job market and the bridge are designed. Nothing in this file is a statement about what the coin will be worth. + +## 1. The diagram + +```mermaid +flowchart LR + subgraph payers [Payers] + U[User sending a transaction] + E[Emission, new coins per block] + C1[External customer at launch, rollup or bridge] + C2[External customer after the proof bridge] + M[Miner on the official client] + end + + subgraph protocol [Protocol routes, fixed at genesis] + BF[Base fee, both gas dimensions] + PF[Priority fee] + POOL[Proving pool, 20% of each block] + JOB[Job fee settled in IGN] + end + + subgraph recipients [Recipients] + MINER[Block producer] + PROV[Shard provers and aggregators] + APP[Registered app developer] + BURN((Burn, nobody)) + CO[Operating company] + PAY[Payout contract on the customer's chain] + end + + U -- IGN --> BF + U -- IGN --> PF + BF --> BURN + PF -- "80%" --> MINER + PF -- "80%, the provers' part" --> PROV + PF -- "20%, per call frame" --> APP + PF -- "20% of frames with no registration" --> BURN + + E -- "80%" --> MINER + E -- "20%" --> POOL + POOL -- "per shard, by consensus proving cost" --> PROV + + C1 -- "customer's currency, on the customer's chain" --> PAY + PAY -- "keyed by miner address" --> PROV + + C2 -- "IGN, bought or bridged" --> JOB + JOB -- "90%" --> PROV + JOB -- "10%" --> BURN + + M -- "1% of rewards, client setting" --> CO +``` + +Three things the picture shows by omission. No arrow reaches a treasury, a foundation or a fund, because none exists (spec 5.5, 5.6). No arrow from the protocol reaches the operating company; the only arrow into it is the client fee, which is outside the protocol and avoidable by running another client. No arrow leaves a burn. + +## 2. The table + +| Flow | Payer | Currency | Recipient | Split | IGN bought? | Burn | Revenue class | Demand for the coin | +|---|---|---|---|---|---|---|---|---| +| Gas on Igneum, base fee | The user sending the transaction | IGN | Nobody | 100% burned, both dimensions (spec 5.1) | Yes: gas is paid in IGN | The whole base fee | None; a burn is not revenue | Yes: every transaction needs IGN for gas | +| Gas on Igneum, priority fee | The user | IGN | The block producer and the provers of that block (80%); the registered developer of each contract frame that ran (20%) | 80 / 20 (spec 5.2); the provers' part of the 80% follows the proving protocol (forward reference); 20% attributed per call frame by gas; an unregistered frame's share is burned | Yes | Only the unregistered app share | Operator revenue (producer, provers); app revenue (developer) | Yes | +| Emission to the block producer | New coins, per block, by the schedule of spec 2.5 | IGN | The miner of each blue block in the mergeset (a red block in the DAA window pays its 80% to the merging block's miner) | 80% of the block's subsidy | No | None | Operator revenue (miner) | No; it is supply, not demand | +| Internal proving pool | New coins, per block | IGN | Shard provers and aggregators of that block, by consensus proving cost per shard; sortition to 8 provers for 10 s, then open (spec 5.3, 7.2) | 20% of the block's subsidy, plus the provers' part of the priority fee's 80% | No | None | Operator revenue (provers) | No | +| External proving job, at launch | A rollup or bridge on another chain | The customer's own currency, on the customer's chain | The miner who delivered, through a payout contract keyed by miner address (spec 5.4) | 100% to the prover; the customer chain's own bond and slashing apply | No | None | Operator revenue (provers), in a currency that is not IGN | No | +| External proving job, after the proof bridge, settled in IGN | A rollup or bridge | IGN, bought on a market or bridged in through the proof bridge (phase two, spec 7.3; the switch is O-5.2) | The provers who delivered (90%) | 90 / 10 (spec 5.4) | Yes | 10% of the job fee | Operator revenue (provers) | Yes: the customer must hold IGN to pay | +| The app share | The user, as part of the priority fee above | IGN | The developer address registered for the contract at deployment; a factory's children inherit its registration (spec 5.2) | 20% of the priority fee, per call frame by gas consumed | Yes (it is part of gas) | The share of frames in unregistered contracts | App revenue. The team collects it only on contracts it deploys, like anyone (spec 5.5) | Yes (part of gas) | +| The client fee | A miner who chooses the official client | IGN, 1% of that miner's rewards (emission and fees) | The operating company | 1%; any other client pays 0% | No | None | Team revenue, off-protocol, the only arrow into the company | No; it moves IGN between holders | +| Burns | Users (base fee, unregistered app share), IGN-settled customers (10% of jobs) | IGN | Nobody | As above | n/a | All of it | None | No arrow; a burn reduces supply and pays nobody, and this file makes no claim about what that does to the price | + +## 3. Labels, in one place + +| Class | Which flows | Who | +|---|---|---| +| Operator revenue | Emission to the producer; the pool; the priority fee's 80%; external jobs at launch and after the bridge | Miners and provers, the people running the hardware. 100% of emission and 80% of tips | +| App revenue | The priority fee's 20% | Whoever registered the contract. The team only where it deployed, as anyone can | +| Protocol revenue | None | There is no address that the protocol pays. A burn is not revenue | +| Team revenue | The client fee only, and the team's own mining, proving and app share earned in the open | The operating company; nothing by rule, everything by competition | +| Demand for the coin | Gas (base fee and priority fee, every transaction); IGN-settled external jobs after the proof bridge | Users and, in phase two, customers. Nothing else in the design creates a reason to hold IGN, and the design does not claim otherwise | + +## 4. What is implemented and what is not + +| Flow | State on 3 October 2026 | Evidence | +|---|---|---| +| Emission 80 / 20 | Implemented in the fork's coinbase; 80/20 exact on 39 of 39 single-payee coinbases on the devnet | `docs/evidence.md` row 20 | +| Base fee burn, priority fee 80 / 20, per-frame app share, unregistered burn | Implemented on the execution-layer branch; receipts on the simnet show the split | `docs/evidence.md` row 22 | +| Pool payout to provers | Designed; the pool output accumulates and nothing draws it | `docs/evidence.md` row 21 | +| External jobs at launch | Designed; no job market code | `docs/evidence.md` row 24 | +| External jobs settled in IGN with the 10% burn | Designed; needs the proof bridge (phase two) and the settlement switch (O-5.2) | `docs/evidence.md` row 24 | +| Client fee | Not implemented; no official client exists | `docs/evidence.md` row 23 | + +## 5. Where the money goes, in dollars + +`docs/analysis/security-budget.md` runs the emission flows of this table through six halvings at three price inputs and names the year the miners' line falls below a stated floor. `docs/plans/funding.md` is the other side: what the team spends and what pays for it. Neither file predicts a price, and this one does not either. diff --git a/docs/evidence.md b/docs/evidence.md new file mode 100644 index 000000000..fb09c4665 --- /dev/null +++ b/docs/evidence.md @@ -0,0 +1,76 @@ +# Igneum evidence: every public claim, with its status + +3 October 2026. One row per claim the homepage (`site/index.html`) and the litepaper (`site/litepaper.html`) make. Every number here is copied from `docs/bench-log.md`, which names the machine, the date and the command; nothing is restated from memory. Where a bench-log figure is approximate, this table says so. + +## The five labels + +| Label | Meaning | +|---|---| +| designed | A decision in the design document or the specification. No code carries it, or the code is a stub | +| implemented | Code exists in this repository with test vectors, and the vectors pass. Not run as a measurement of the claim | +| tested by the team | The claim was measured or exercised by the project's own people and agents on a named machine, and the result is in the bench log | +| reproduced externally | Somebody outside the project ran the published command on their own hardware and got the published result | +| reviewed independently | Somebody outside the project, paid or not, read the code or the rule and published their finding | + +Three rules for reading the table: + +1. Nothing on this chain has been reproduced externally or reviewed independently. Every row's last column says "none yet". The repository is private until January 2027 (`site/journey.json`), so the first two labels are the ceiling today. +2. A status applies to the exact version in the row. An audit of one version never covers a newer one; when the version changes, the status falls back to "tested by the team" until the new version is reproduced or reviewed again. +3. "Tested by the team" on one machine is one machine. The rows say which. Discrete AMD, Intel and a 2019-class CPU core have not run anything. + +Versions in the table: `igneum-pow` is the Rust crate at `igneum-pow/Cargo.toml` version 0.1.0. "Repo" commits are this repository's. "Fork" commits are `vendor/igneum-node` and its worktrees (`-r3`, `-diff`, `-exec`, `-harness`), which are not in this repository's history; the row names the fork commit by its message as the bench log does. The spec is `docs/spec/` version 0.1. + +## The table + +| # | Claim | Where it is made | Status | Version or commit | Reproducible test | Result, date, machine | Independent verification | +|---|---|---|---|---|---|---|---| +| 1 | A new mining program every hour, compiled by the miner, with no human in the loop | Homepage hero and "This hour's mining program"; litepaper Mining | tested by the team | igneum-pow 0.1.0; repo `9812466`; fork "PoW: header-bound lottery engine, real-hash miner modes, genesis bits 0x1e400000" | `igneum-miner mine --engine igneum-pow` against a 3-node `igneumd --devnet`, with `proto-metal/igneum-bench --serve` as the GPU worker; bench-log "first devnet blocks on the real lottery hash" | Epoch change crossed live at DAA 3,600: new seed, a 128-load program compiled by the Metal worker in 129 ms, 0 rejected blocks across the change. 3 October 2026, Apple M5 Max. The epoch seed on the devnet is the epoch block hash; the VDF of row 2 is not wired in yet | none yet | +| 2 | The program seed passes through a 10-minute verifiable delay from a certified checkpoint, so nobody can grind the seed | Litepaper Mining, vs RandomX ("Closed by a verifiable delay") | implemented | repo `792776e`; `proto-vdf/` | `proto-vdf` full 10-minute runs and the tamper cases in `proto-vdf/README.md`; bench-log "proto-vdf" | Class group 1024-bit: 163,000 squarings per second, 10-min eval 585.4 s, prove 9.1 s on 12 threads, verify 4.47 ms, 516-byte proof; wrong checkpoint, flipped seed bit and T+1 all rejected; grinding model gains 0 blocks per epoch with the delay against +3.62 at a 30% advantage without it. 3 October 2026, Apple M5 Max, one core. Prototype only: not in the node, not reviewed against chiavdf (O-4.1) | none yet | +| 3 | The dataset is memory-hard: computing an item costs more than loading it | Litepaper Mining and vs RandomX; homepage vs RandomX ("Memory 2 GB, growing") | tested by the team | repo `58a5a63`; igneum-pow 0.1.0 (`memhard.rs`); `proto-metal/MEMHARD.md` | `proto-metal/igneum-bench --inline-dataset` against the honest run at 1 GiB and 256 MiB; bench-log "memory-hard dataset" | Honest 45.2 Mhash/s, inline (never reads the dataset) 9.49 Mhash/s, ratio 0.21, at 1 GiB; 0.10 at 256 MiB. 3 October 2026, Apple M5 Max. Apple only: the shortcut ratio has not run on NVIDIA or AMD (O-1.5). Review round 3 priced a 256 MiB on-die cache chip at about 2.4x, approximate, which the measurement does not answer (ledger M16) | none yet | +| 4 | The same program produces identical hashes on three GPU vendors, cache and dataset included | Litepaper vs RandomX ("Bit-exact on Apple and NVIDIA, measured"), For miners; homepage | tested by the team | repo `f2e903e`, `0f1fdaf`; pack `proto-cuda/packs/igneum-genesis-mh`; igneum-pow 0.1.0 | The 96 test vectors of the pack through `proto-metal/igneum-bench`, `proto-cuda/host.cu`, `proto-opencl/host.c`; batch fingerprint at `--batch-log2 24`; bench-log entries "RTX 5090, memory-hard dataset", "AMD gfx1036", "RTX 5090 through NVIDIA OpenCL" | 96/96 on Apple Metal (M5 Max), NVIDIA CUDA and NVIDIA OpenCL (RTX 5090, Windows), AMD OpenCL (Ryzen 7 9800X3D integrated gfx1036, 1 compute unit), Apple OpenCL, pocl and two CPU references; batch fingerprint `98af644e993239e2` over 16.7 million nonces identical on the AMD chip and the 5090. 3 October 2026. The AMD device is an integrated chip; no discrete AMD card and no Intel card has run anything (O-1.15) | none yet | +| 5 | A CPU verifies one hash in under 10 ms by simulating one warp | Litepaper Mining ("about ten milliseconds"), vs RandomX; roadmap gate 2 | tested by the team | repo `75cac18`; igneum-pow 0.1.0 (`verify.rs`) | `cargo test` and the crate bench in `igneum-pow/`; bench-log "igneum-pow: Rust crate bit-exact with proto-metal" | 0.411 to 0.579 ms per 32-lane warp steady, 0.41 to 0.87 ms cold, average of 20, 1 GiB dataset, cache held, one M5 Max performance core; the Swift verifier 0.63 to 1.2 ms. Gate margin about 17x on this core. 3 October 2026. Not measured on a 2019-class laptop core (O-1.14) | none yet | +| 6 | The hash is bound to the header: one nonce serves one header, and a wrong nonce is rejected | Spec 1.6; litepaper Mining (implied by "checks a hash") | tested by the team | repo `33f7b33`, `9812466`; igneum-pow 0.1.0 (`bind.rs`, 8 bound vectors, 29 crate tests) | `igneum-miner bad-nonce` against a devnet node; `igneum-pow hash-bound` for the 96-nonce job across the 2^32 lane boundary; bench-log "first devnet blocks on the real lottery hash" | 833 blocks accepted by `igneum-lottery-v1-bound` on 3 nodes, 0 rejections; `bad-nonce` gave Reject(BlockInvalid); Metal, OpenCL and CUDA (emulated) workers bit-exact with the crate on the lane-boundary job. 3 October 2026, Apple M5 Max | none yet | +| 7 | The devnet runs at one block a second | Homepage stats ("1 / s"); litepaper Speed; roadmap phase 3 | tested by the team | repo `9812466`, `e9328c6`; fork worktree `vendor/igneum-node-diff` branch `difficulty` | 3-node CPU devnet, `igneum-miner mine --engine igneum-pow`, 660 s; the dual-lane rule's 3-node test network (ports 26800 to 26821); bench-log "first devnet blocks" and "difficulty controller" | CPU devnet: 1.29 blocks/s over 641 s, 1.03 blocks/s over blocks 610 to 816 after the first retarget, sink identical on 3 nodes at 61 of 64 samples. Kaspa's sampled rule on the overnight devnet did not hold the rate across a hashrate step (5.44 blocks/s for five minutes, 4.7x the schedule for eight minutes). The Igneum dual-lane rule's test network reached 1 block/s within 10% after 132 s, worst gap 7.3 s. 3 October 2026, Apple M5 Max. The phase 3 gate also asks for proofs under 60 s behind the tip; no proof exists (row 15) | none yet | +| 8 | Blocks are mined by GPUs on Apple and NVIDIA | Homepage live strip; journey phase 3 ("GPU miners on three vendors") | tested by the team | repo `9812466`, `e9328c6`; fork as row 1 | Metal worker `proto-metal/igneum-bench --serve` driven by `igneum-miner --worker`, 300 s; the overnight devnet record `sim/difficulty/devnet-2026-10-03.csv`; bench-log "first devnet blocks" and "difficulty controller" | Metal: 506 jobs, 5,636 blocks found and accepted, 0 rejected, 0 CPU/GPU mismatches, 28.2 MH/s wall. NVIDIA: the overnight devnet record shows the PC's RTX 5090 mining at 116 MH/s estimated from the blocks, and the finality follower counted eight RTX 5090 identities at 862 to 936 blocks each. 3 October 2026, Apple M5 Max and the Windows PC | none yet | +| 9 | Blocks are mined by a GPU on AMD | Journey phase 3 ("three vendors") | implemented | repo `0f1fdaf`; bound kernel `kernel_bound.cl` in the pack | `proto-opencl/host.c --serve` on an AMD device against a devnet node | The bound OpenCL kernel is bit-exact with the crate on Apple OpenCL and the memory-hard pack passes 96/96 on AMD gfx1036, but no block count mined by an AMD device is recorded in the bench log. Until one is, the three-vendor mining claim is two vendors mined plus one vendor verified | none yet | +| 10 | Checkpoints lock every 30 s of chain at two thirds of active weight and at least 56.7% of total, and the floor stops conflicting locks in partitions and eclipses | Litepaper Finality, "What Igneum does not claim"; homepage "locked every 30 seconds" | tested by the team | repo `bbb264a` (simulation), `60b1412` (fork run); fork "Finality: BLS12-381 vote keys ..." through "Miner: BLS identity ..."; spec 3.10 | `sim/finality_v2.py` (results in `sim/results_v2.md`); the 4-miner test network `igneum-devnet-7` with `getFinalityCheckpoints` on three nodes; bench-log "finality rule V2" and "igneum-node devnet v2" | Simulation: 0 conflicting locks in every honest partition and eclipse scenario with the floor; without it both sides of a 50/50 split lock after 60 min. Test network: 72 of 72 determined checkpoints locked on all three nodes, lock latency median 0.80 s, p90 1.08 s, 0 conflicting certificates; an equivocating key stripped at index 43 and excluded; with one voter left (39.6% of total) 0 locks for 749 s, then the heal locked 13 checkpoints within 30 s. 3 October 2026, Apple M5 Max, 53 minutes. Not on the live devnet (its miners do not vote yet); the simulation has no DAG; one unexplained stall of all three nodes in the first run, not reproduced | none yet | +| 11 | Hashrate that arrived today has almost no vote: ten days of the whole network's hashrate to reach a third of the weight, twenty for two thirds; 51% never reaches two thirds while honest miners stay | Litepaper Finality; homepage firsts | tested by the team | repo `bbb264a`; `sim/finality_v2.py` | Scenario B of `sim/finality_v2.py`, seeds 7 and 11 | share(t) = (t/30) x a/(1+a) holds to 0.04 points; a renter equal to the whole honest network (a = 1) crosses 1/3 on day 20 and never reaches 2/3; a = 9 crosses 1/3 on day 11.1 and 2/3 on day 22.2. The ten-day figure is a = infinity, honest miners gone. 3 October 2026, Apple M5 Max. A model with 1,000 Pareto keys and no DAG; the harness scenarios against the real node (1b, 3b, 4b) are stubs | none yet | +| 12 | The difficulty rule recovers from a hashrate step within about a minute, where Kaspa's sampled rule never settles | Spec 2.3; litepaper Speed (implied); bench page | tested by the team | repo `e9328c6`; fork worktree `vendor/igneum-node-diff` branch `difficulty`; `sim/difficulty/sim.py` | `sim/difficulty/sim.py` on nine profiles plus the devnet record; the 3-node test network with `"difficulty_rule"` in the override file; `cargo test -p kaspa-consensus --lib difficulty` (9 pass); bench-log "difficulty controller" | Simulator, settled seconds: x50 step 62 (Kaspa 1,542), /50 step 657 (Kaspa 12,296), the devnet's 75x step 79 (Kaspa never). Test network: within 10% of 1 block/s after 132 s warm-up, 214 s on a join, 85 s on a leave. 3 October 2026, Apple M5 Max under load 50 to 98. Monero and LWMA baselines reproduced from memory, approximate; no DAG in the simulator; harness scenarios 2b and 7b are stubs | none yet | +| 13 | Every node executes the ordered transactions natively and reaches the same state root | Litepaper Proving ("Every node executes ... natively"), Building ("runs on Igneum unchanged") | tested by the team | repo `f5f8c80`; fork worktree `vendor/igneum-node-exec` branch `execution-layer`; revm 43.0.3 | `node tools/evm-smoke/smoke.mjs` against a 3-node `igneumd --simnet`; `igneum-exec-diff seq.json`; bench-log "execution layer devnet v3" | 87 of 87 viem checks; state roots identical on 3 nodes at chain blocks 0, 56, 74 and 78; 57 executed transactions and 19 skipped copies agree with plain revm, 0 mismatches; balances match receipts to the wei. 3 October 2026, Apple M5 Max. Simnet skips proof of work, the prover is a stub, state is rebuilt from genesis at start, no EVM transaction relay between nodes | none yet | +| 14 | Ethereum bytecode runs unchanged, with the documented differences of spec 7.1 | Homepage Build card; litepaper Building | tested by the team | as row 13 | `tools/evm-smoke/smoke.mjs`: deploy via viem, `increment`, `hashLoop`, `eth_estimateGas`, `eth_getLogs` | Deployment, calls, reverts, logs and gas estimates behave as viem expects; chain id 4463; the prototype pgas table gives 0.0095 to 0.028 pgas per gas, below the design's band before calibration. 3 October 2026, Apple M5 Max. The `Prover` precompile, proof records and the shard planner are not implemented | none yet | +| 15 | Every block is proven, with the proof landing within about a minute at launch | Homepage stats ("~60 s to a proof"); litepaper Proving; roadmap phase 3 gate | designed | spec 7.2; `docs/design/execution-layer.md` section 5 | None exists. The phase 2 benchmark standard is `docs/benchmarks/proving-e2e.md` | No SP1 shard has been proven on any card in this repository (ledger P1, P3). The devnet prover is a stub that signs claims. The 60-second figure is a design target | none yet | +| 16 | A 12 GB card proves one shard in about 20 s | Litepaper Proving ("The proving budget"); roadmap gate 2 | designed | spec 5.1 (Target) | Replaced as a gate by the end-to-end standard in `docs/benchmarks/proving-e2e.md`: fixed workloads, job-to-accepted-proof latency, no growing backlog | Unmeasured. A per-shard time can be met by shrinking the shard, so the project no longer uses it as a pass mark | none yet | +| 17 | The chip resistance target: a chip gains under 2x over a GPU | Litepaper Mining, "What Igneum does not claim"; homepage "no chip can be built for it" | designed | spec 0.2 (Target); O-1.17 | Public benchmark with a leaderboard by card model and a standing bounty, January 2027 (O-1.17); the on-die-SRAM test on the RTX 5090 (R3.5) | A target, not a measurement. Review round 3 priced a recompute chip with the 256 MiB cache on die at about 2.4x, approximate, before the usual chip-versus-GPU integer gain; the design answer (cache larger than any die) is open (spec 1.16) | none yet | +| 18 | The chip resistance measurements: the program is random-access bound, not bandwidth bound, and sits beyond a card's on-chip cache | Litepaper Mining ("bound by memory bandwidth", to be corrected), vs RandomX "Measured so far" | tested by the team | repo `aba248d`, `f2a1a64`, `4b95c5e` | RTX 5090 dataset sweep 4 MiB to 1 GiB with `proto-cuda/host.cu`; bench-log "RTX 5090 first run" and "dataset sweep" | At 1 GiB: 228.1 Mhash/s, 23.7 G random loads/s, 94.9 GB/s useful against a 1,638 GB/s dataset fill; inside the 96 MiB L2 (4 and 64 MiB) 1,340 to 1,353 Mhash/s, about 5.8x faster; 104 against 128 loads per hash gives 228 against 185 Mhash/s, proportional. 3 October 2026, RTX 5090, Windows, CUDA 12.8. Prototype dataset 1 GiB against 2 GB at genesis; a pure random-read microbenchmark (R3 chip designer, attack 2) has not run | none yet | +| 19 | The lottery hash is sound as a hash: uniform output, deterministic, no out-of-bounds read, fuzzed | Litepaper vs RandomX ("Every number above is measured and logged") | tested by the team | repo `c52307e`, `58a5a63`; `proto-metal/TESTS.md` | `proto-metal/igneum-bench --fuzz --edge --stats --determinism --memcheck`; bench-log "hardening tests" and the re-run on the memory-hard dataset | 10,200 random programs, 1,305,600 hashes, 0 mismatches; 14 of 14 edge cases; bit frequency within 2.90 sigma, avalanche mean 31.99 to 32.04 of 32; deterministic fingerprint across 5 runs; every dataset read masked. 3 October 2026, Apple M5 Max. Statistics are not a security proof; the weak-program census (O-1.3) and the seed derivation review (O-1.4) are open; the fuzz set has run on Metal and the CPU only | none yet | +| 20 | No premine, no pre-sale, no allocation: every coin is minted by the schedule and every coin goes to the block producer (80%) and the proving pool (20%) | Homepage stats and Economics tiles; litepaper Supply, Economics | implemented | repo `6ac80a3`; fork "igneum-node devnet v0"; `consensus/core/src/igneum.rs`, `coinbase.rs` | `cargo test -p kaspa-consensus-core igneum` (8 pass: subsidy table, ramp, split, cap) and `cargo test -p kaspa-consensus coinbase` (8 pass); `igneum-miner inspect 40`; bench-log "igneum-node devnet v0" | Coinbases on the devnet: 80/20 exact on 39 of 39 single-payee blocks, the 20% to the `igneum-proving-pool-v0` output; the per-second schedule sums to under the 4,000,000,000 cap by less than 100 coins; 3,168,808,781 units per DAA second in years 0 to 2, halving at 63,115,200 DAA s. 3 October 2026, Apple M5 Max. The devnet genesis carries no allocation; the mainnet genesis does not exist yet, so the claim is about the code and the stated rule, not a launch that has happened | none yet | +| 21 | The proving pool's 20% reaches shard provers and aggregators | Litepaper Economics; homepage "20% provers" | designed | spec 5.3 | None. The pool output exists (row 20); the payout from it against proof records is unwritten | The escrow accumulated on the simnet (92.55 IGN at the end of the v3 run) and nothing can draw it. Rule decided: per block, divided among shards by consensus proving cost, sortition to 8 provers for 10 s then open (spec 7.2) | none yet | +| 22 | The base fee is burned in full and the priority fee splits 80% to the miner and provers, 20% to the apps whose code ran | Homepage Economics caption and Build card; litepaper "Where fees go" | tested by the team | repo `f5f8c80`; fork worktree `vendor/igneum-node-exec` | `tools/evm-smoke/smoke.mjs` receipt checks; bench-log "execution layer devnet v3" | Transfer receipt: `burnedProvingFee` 200 gwei, `minerTip` 16,800 gwei (80%), unregistered developer share 4,200 gwei burned; contract call: 80% to the miner, 20% credited to the payee the constructor registered, balance delta equal. 3 October 2026, Apple M5 Max simnet. The provers' part of the 80% is not split out (no provers exist); the base fee stayed at the 1 gwei floor throughout | none yet | +| 23 | No fee to any team, foundation or fund; 0 admin keys in consensus | Homepage Economics tiles and caption; litepaper "No fund, no foundation" and Governance | designed | spec 5.5, 5.6 (decided 3 October 2026); spec 08 | Reading: no coinbase output, fee route or consensus key in the fork names any party (`coinbase.rs`, `docs/fork-divergence.md`) | The emission code has two outputs (row 20) and the fee code has three routes (row 22), none to a team. The 1% fee of the official client is a client setting, not a protocol rule, and is not implemented (no client exists). The release key of spec 08 signs client updates and holds no consensus power; its custody policy is open (O-8.1) | none yet | +| 24 | External proving jobs pay 90% to the provers who delivered and burn 10%, once settled in IGN | Homepage "IGN burned from jobs, phase two"; litepaper Proving and Economics | designed | spec 5.4 | None. Needs the proof bridge (spec 7.3, phase two) and the settlement switch (O-5.2) | At launch jobs are paid on the customer's chain in the customer's currency and nothing is burned (ledger P10). No job market code exists | none yet | +| 25 | The 4 billion cap, halving every two years, with a 30-day ramp from 10% | Homepage "4B IGN hard cap"; litepaper Supply and the emission chart | tested by the team | repo `6ac80a3`; fork `consensus/core/src/igneum.rs` | `cargo test -p kaspa-consensus-core igneum`; bench-log "igneum-node devnet v0" | Ramp day 0 paid 10.03% of the full rate (317,767,704 units at DAA 806); the schedule table and the cap assert in the crate's own tests. 3 October 2026, Apple M5 Max. Base unit (8 or 18 decimals) is open (O-2.6); the spec was changed to follow the code's 365.25-day year (ledger E9) and a test that reads the published numbers back is still owed | none yet | +| 26 | A phone or browser verifies the chain from a locked checkpoint, at about 3.44 MB per day in checkpoint mode | Homepage "Browser checks Igneum" card (preview, commit `f874f80`); litepaper Building ("Light clients"), firsts row 6 | designed | spec 10 (10.5 bytes per day: 3.44 MB at 1,000 voters, 6.68 MB at 10,000, derived, approximate); repo `f874f80` for the browser card | None for the byte figure; `site/verify/` for the card. BLS verification on a phone and in WebAssembly is O-10.3; the full-header mode on a phone is O-10.4 | The homepage card verifies the latest certified checkpoint's BLS certificate in the tab against a voter list from the node (light client v0, 3 October 2026). The byte figure is arithmetic on designed sizes (header 400 bytes, proof 400 bytes), measured nowhere; the proof the card would check does not exist (row 15) | none yet | +| 27 | The node survives malformed input, floods, withholding, partitions and eclipses | Litepaper Speed ("GHOSTDAG, the BlockDAG consensus proven on Kaspa"); spec 2 | tested by the team | repo `394030c`; fork worktree `vendor/igneum-node-harness`; `tools/harness/` | `tools/harness/` scenario runner against a private `igneumd` test network (ports 27200+); bench-log "consensus attack harness" | 63 malformed cases, node up on every one; timestamp bounds exact; withholding at 10%, 25%, 33% and 45% released every 5 blocks within 2 sigma of share; partitions of 120 s to 3,700 s healed to one chain in 10 s; eclipse victims rejoined in 10 s; 50x template, submit and mempool floods left template p95 under 4 ms. One FAIL: a 45% withholder releasing every 20 blocks took 50.7% of blues (bound 47.4%). 3 October 2026, Apple M5 Max, load 50 to 61. Finality and difficulty scenarios are stubs until those branches merge | none yet | +| 28 | Headers are validated cheaply before the lottery engine runs, so forged timestamps cannot force 256 MiB cache builds | Spec 2.4; ledger M15 | tested by the team | repo `0953ec7`; fork worktree `vendor/igneum-node-r3` branch `r3-fixes` at `5166ee26` | `measure_m15_attack_before_and_after` (ignored test, release, `--features igneum-pow`); kaspa-pow 8, header_processor 1, p2p `pow_guard` 2 tests | 50 forged headers: before, 50 cold builds in 10,595 ms and the live day evicted; after, 0 builds, all 50 rejected in 14 ms. 3 October 2026, Apple M5 Max under load 60 to 110. Measured through the validate path with `skip_proof_of_work`, not the daemon RPC; not merged into the main fork branch | none yet | + +## Count by status + +| Status | Rows | +|---|---| +| designed | 7 (rows 15, 16, 17, 21, 23, 24, 26) | +| implemented | 3 (rows 2, 9, 20) | +| tested by the team | 18 (rows 1, 3, 4, 5, 6, 7, 8, 10, 11, 12, 13, 14, 18, 19, 22, 25, 27, 28) | +| reproduced externally | 0 | +| reviewed independently | 0 | + +28 rows. The rendered page is `site/evidence.html`, kept in step by hand with this file; the bench page is generated, this one is not, because its text is judgement, not a log. + +## What would move a row + +| From | To | What it takes | +|---|---|---| +| designed | implemented | Code in this repository with test vectors that pass | +| implemented | tested by the team | A bench-log entry with the machine, the date, the command and the number | +| tested by the team | reproduced externally | The repository public (January 2027), the command published, and a third party's run with the same result, linked from the row | +| reproduced externally | reviewed independently | A named reviewer's published finding on that version. Funding for review is `docs/plans/funding.md` | +| any | the row's status falls back | A new version of the code or rule the row names | diff --git a/docs/plans/funding.md b/docs/plans/funding.md new file mode 100644 index 000000000..9e8208453 --- /dev/null +++ b/docs/plans/funding.md @@ -0,0 +1,61 @@ +# Funding plan + +3 October 2026. What the project costs to build, review, run and defend, what pays for it today, what waits on revenue, and what pauses if revenue is late. Every dollar figure is approximate unless it cites a price list, and the basis is stated in the row. Nothing here is a sale of anything and no figure is a price of the coin. + +## 1. What funds the project + +| Source | What it is | Status | +|---|---|---| +| The founder's own means | Private money and the founder's own time. The amount committed is not published and this plan does not pretend to know the ceiling | The only source today | +| The official client's 1% fee | The official miner client charges 1% of a miner's rewards to the operating company (litepaper, "What a miner's hour looks like"). It is a client setting, not a protocol rule; any miner can run another client and pay nothing | Zero until there is mining with value, which is mainnet (November 2027 on the roadmap); then unknown, because it is hashrate times coin price times 1% times the share of miners on the official client | +| The team's own mining, proving and apps | The team mines from genesis like anyone, runs provers in the job market and collects the 20% app share on contracts it deploys (spec 5.5) | Zero until mainnet; competitive, not guaranteed | +| Protocol treasury, protocol fee, emission share | None exists and none will (spec 5.5, 5.6) | Zero, by rule | +| Token sale, pre-sale, allocation, grant from a foundation | None | Zero, by rule | + +So until mainnet every cost below is the founder's. After mainnet the 1% fee and the team's open-market earnings join, and both depend on a chain that has not launched and a coin that has no value today. + +## 2. The table + +Columns: estimated cost with its basis; what is funded today; what depends on future revenue; what happens if revenue arrives late. "Revenue" means the 1% fee and the team's open-market earnings after mainnet, and nothing else. + +| Item | Estimated cost (approximate) and basis | Funded today | Depends on future revenue | If revenue is late | +|---|---|---|---|---| +| Development: founder and agents through mainnet (13 months) | No dollar figure: the founder's time and the agent tooling the founder already pays for. Basis: `CLAUDE.md` team section; `docs/fud-fixes.md` row 29 (method disclosed) | Founder's own means | No | Continues | +| Development: a contracted cryptographer for phases 1 and 2 (lottery hash soundness, VDF code against chiavdf, seed derivation; `docs/fud-fixes.md` row 71, O-1.4, O-4.1) | USD 80,000 to 150,000 for about six months part time. Basis: from memory of contract rates for applied cryptography, approximate | Founder's own means | No | Scope shrinks to the gate 1 review of the fair-lottery properties only; the VDF review moves to the audit row | +| Development: the second independent node client | Not in the 13-month plan (`docs/fud-fixes.md` rows 31, 47). Basis: decision pending | Not funded | Yes, entirely | Does not start | +| Independent review: finality rule v2 (gate 3, phase 4, the rule external review is paid to break) | USD 50,000 to 100,000. Basis: a focused review of one consensus rule plus its simulation by two reviewers over a few weeks, from memory, approximate | Founder's own means | No | Not pausable: the roadmap says the phase 4 gate is "finality design passes external review". If it cannot be paid, phase 4 does not close and the dates move | +| Independent audit: the node fork (consensus delta, p2p, difficulty, header validation, the pow engine) before public testnet | USD 60,000 to 120,000. Basis: the delta is listed row by row in `docs/fork-divergence.md`; the base is rusty-kaspa, already audited upstream, approximate | Founder's own means, second in order after the finality review | Partly: a second pass after the attack harness closes its stubs | The single pass is kept; the second pass waits. Public testnet does not open without the first pass | +| Independent audit: execution layer and proving integration (revm driver, two-dimensional gas, proof records, the veto, the `ProofSystem` version 1 integration) before mainnet | USD 80,000 to 150,000. Basis: an EVM-integration audit of a new client's execution path, from memory, approximate | Not funded | Yes | Mainnet moves until it is paid. Mainnet does not ship with an unaudited execution layer | +| Independent audit: the official client and release process (spec 08: reproducible builds, release key, update path) | USD 20,000 to 40,000. Basis: a short application security review, from memory, approximate | Not funded | Yes | The one-click app ships at testnet unaudited and says so on the download page; the audit lands before mainnet or the app does not carry the mainnet release key | +| Infrastructure: the 20-node cloud devnet | USD 476 per month for 20 nodes (Hetzner API prices of 3 October 2026, net, `docs/plans/cloud-devnet.md`); about USD 6,000 for the 13 months, plus rented GPU hours for the hourly-compile and shard measurements at USD 0.22 to 0.74 per card hour (RunPod, 3 October 2026): under USD 1,000 over phase 2 | Founder's own means | No | Node count drops to 8 (two per location); the rented GPU hours are replaced by the project's own cards | +| Infrastructure: seed nodes, site, observer database, domains | Seed nodes USD 50 to 80 per month for three to five (`docs/plans/seed-nodes.md`); the site and the observer's database are on free or near-free tiers today, approximate; 15 domains at the registrar's renewal price, approximate USD 500 per year | Founder's own means | No | Three seeds not five; nothing else changes | +| Incident response: an on-call second engineer from public testnet, an emergency-release drill, the soundness-bug path of spec 5.7 and design 5.5 rehearsed | USD 3,000 to 6,000 per month retainer from August 2027; about USD 40,000 through the first mainnet quarter. Basis: a part-time retainer at contract rates, from memory, approximate | Not funded | Yes | The founder is the on-call engineer alone; the drill still runs, because it costs time and not money; the retainer starts when the fee pays it | +| Challenge reward: the chip bounty (O-1.17), paid to anyone who shows a chip design that beats a GPU by more than 2x | USD 50,000 standing. Basis: sized to pay for a credible design study with a measured operation count, not a tapeout; the amount is a decision, not a market rate | Not funded; the terms and the payer are the entity's (`docs/fud-fixes.md` row 50) | Yes: the bounty is announced with the January 2027 benchmark and escrowed when the entity has the money | Announced at a lower standing amount (USD 10,000) and raised when revenue allows; a bounty that cannot be paid is not announced | +| Challenge reward: the finality break bounty (litepaper "Questions miners ask") | USD 25,000 standing. Basis: as above | Not funded | Yes | As above | +| Challenge reward: the reproduction reward of `docs/benchmarks/proving-e2e.md` 8.1 (a fixed, equal, disclosed amount per unrelated operator) | USD 1,000 per operator per workload set, three operators, about USD 3,000 per campaign. Basis: covers electricity and a day of attention, approximate | Not funded | Yes | Reproduction is asked for without a reward; the standard allows that | +| Legal: counsel on the entity, the promotions question, the testnet payment terms, the no-custody structure of the job market (`docs/fud-fixes.md` rows 46, 58, 59) | USD 20,000 to 50,000. Basis: from memory, approximate | Founder's own means | No | Continues; it gates public text, not code | + +## 3. Totals + +| Bucket | Approximate total | Funded today | +|---|---|---| +| Development (cryptographer; founder time unpriced) | USD 80,000 to 150,000 | Yes | +| Independent review and audits | USD 210,000 to 410,000 | The finality review and the first node pass: USD 110,000 to 220,000. The execution and client audits, USD 100,000 to 190,000: no | +| Infrastructure | USD 8,000 to 10,000 through mainnet | Yes | +| Incident response | USD 40,000 through the first mainnet quarter | No | +| Challenge rewards | USD 78,000 standing plus USD 3,000 per campaign | No | +| Legal | USD 20,000 to 50,000 | Yes | +| Total | USD 440,000 to 740,000 through the first mainnet quarter, plus standing bounties | About USD 220,000 to 430,000 funded; about USD 220,000 to 310,000 unfunded, all of it after public testnet | + +The unfunded half is the half that comes after the chain exists and before and just after it launches: the execution audit, the client audit, incident response and the bounties. Each row says what pauses. Two things never pause and instead move the date: the finality review (phase 4 gate) and the execution audit (mainnet). The plan is to delay rather than to launch unreviewed. + +## 4. What the 1% fee could be, and why it is not counted + +The fee is 1% of rewards on the official client. Rewards in year one are 963 million IGN (ramp included, `docs/analysis/security-budget.md`). At the low, base and high price inputs of that analysis the fee's ceiling, with every miner on the official client, is USD 48,000, 193,000 and 963,000 a year. Those are inputs, not expectations, and the share of miners on the official client is unknown. Nothing in section 2 is funded against them. + +## 5. Rules + +1. No item is paid from emission or from a protocol fee, because neither exists. +2. A review or audit that is paid for is published whole, pass or fail, and linked from `docs/evidence.md`. +3. A bounty is announced only when it is escrowed. +4. This plan is revised when a number changes; the git history of this file is the record. diff --git a/site/build.mjs b/site/build.mjs index 0418dbd43..5a071ca3b 100644 --- a/site/build.mjs +++ b/site/build.mjs @@ -118,7 +118,7 @@ footer{border-top:1px solid var(--line);padding-block:32px 48px;font-size:13px;c
-
${mark}IGNEUM
+
${mark}IGNEUM

${esc(heading)}

${note}

diff --git a/site/evidence.html b/site/evidence.html new file mode 100644 index 000000000..81f43f682 --- /dev/null +++ b/site/evidence.html @@ -0,0 +1,145 @@ + + + + + +Igneum evidence + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
IGNEUM
+

Evidence

+

Every claim the homepage and the litepaper make, one row each, with one of five labels: designed (a decision, no code), implemented (code with passing test vectors), tested by the team (measured by the project on a named machine, in the engineering log), reproduced externally (a third party ran the published command and got the published result) and reviewed independently (a named outside reviewer published a finding on that version). Nothing on this chain has been reproduced externally or reviewed independently; every row says so. A label belongs to the exact version in the row, and an audit of one version never covers a newer one.

+
+
designed
7

A decision in the design document or the specification. No code, or a stub

+
implemented
3

Code in the repository with test vectors that pass. Not measured as the claim

+
tested by the team
18

Measured or exercised by the project on a named machine, with the command in the log

+
reproduced externally
0

None yet. The repository is private until January 2027

+
reviewed independently
0

None yet. What review would cost and who pays is in the funding plan

+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
#ClaimStatusVersion or commitReproducible testResult, date, machineIndependent verification
1A new mining program every hour, compiled by the miner, with no human in the loop
Homepage hero and "This hour's mining program"; litepaper Mining
tested by the teamigneum-pow 0.1.0; repo 9812466; fork "PoW: header-bound lottery engine, real-hash miner modes, genesis bits 0x1e400000"igneum-miner mine --engine igneum-pow against a 3-node igneumd --devnet, with proto-metal/igneum-bench --serve as the GPU worker; bench-log "first devnet blocks on the real lottery hash"Epoch change crossed live at DAA 3,600: new seed, a 128-load program compiled by the Metal worker in 129 ms, 0 rejected blocks across the change. 3 October 2026, Apple M5 Max. The epoch seed on the devnet is the epoch block hash; the VDF of row 2 is not wired in yetnone yet
2The program seed passes through a 10-minute verifiable delay from a certified checkpoint, so nobody can grind the seed
Litepaper Mining, vs RandomX ("Closed by a verifiable delay")
implementedrepo 792776e; proto-vdf/proto-vdf full 10-minute runs and the tamper cases in proto-vdf/README.md; bench-log "proto-vdf"Class group 1024-bit: 163,000 squarings per second, 10-min eval 585.4 s, prove 9.1 s on 12 threads, verify 4.47 ms, 516-byte proof; wrong checkpoint, flipped seed bit and T+1 all rejected; grinding model gains 0 blocks per epoch with the delay against +3.62 at a 30% advantage without it. 3 October 2026, Apple M5 Max, one core. Prototype only: not in the node, not reviewed against chiavdf (O-4.1)none yet
3The dataset is memory-hard: computing an item costs more than loading it
Litepaper Mining and vs RandomX; homepage vs RandomX ("Memory 2 GB, growing")
tested by the teamrepo 58a5a63; igneum-pow 0.1.0 (memhard.rs); proto-metal/MEMHARD.mdproto-metal/igneum-bench --inline-dataset against the honest run at 1 GiB and 256 MiB; bench-log "memory-hard dataset"Honest 45.2 Mhash/s, inline (never reads the dataset) 9.49 Mhash/s, ratio 0.21, at 1 GiB; 0.10 at 256 MiB. 3 October 2026, Apple M5 Max. Apple only: the shortcut ratio has not run on NVIDIA or AMD (O-1.5). Review round 3 priced a 256 MiB on-die cache chip at about 2.4x, approximate, which the measurement does not answer (ledger M16)none yet
4The same program produces identical hashes on three GPU vendors, cache and dataset included
Litepaper vs RandomX ("Bit-exact on Apple and NVIDIA, measured"), For miners; homepage
tested by the teamrepo f2e903e, 0f1fdaf; pack proto-cuda/packs/igneum-genesis-mh; igneum-pow 0.1.0The 96 test vectors of the pack through proto-metal/igneum-bench, proto-cuda/host.cu, proto-opencl/host.c; batch fingerprint at --batch-log2 24; bench-log entries "RTX 5090, memory-hard dataset", "AMD gfx1036", "RTX 5090 through NVIDIA OpenCL"96/96 on Apple Metal (M5 Max), NVIDIA CUDA and NVIDIA OpenCL (RTX 5090, Windows), AMD OpenCL (Ryzen 7 9800X3D integrated gfx1036, 1 compute unit), Apple OpenCL, pocl and two CPU references; batch fingerprint 98af644e993239e2 over 16.7 million nonces identical on the AMD chip and the 5090. 3 October 2026. The AMD device is an integrated chip; no discrete AMD card and no Intel card has run anything (O-1.15)none yet
5A CPU verifies one hash in under 10 ms by simulating one warp
Litepaper Mining ("about ten milliseconds"), vs RandomX; roadmap gate 2
tested by the teamrepo 75cac18; igneum-pow 0.1.0 (verify.rs)cargo test and the crate bench in igneum-pow/; bench-log "igneum-pow: Rust crate bit-exact with proto-metal"0.411 to 0.579 ms per 32-lane warp steady, 0.41 to 0.87 ms cold, average of 20, 1 GiB dataset, cache held, one M5 Max performance core; the Swift verifier 0.63 to 1.2 ms. Gate margin about 17x on this core. 3 October 2026. Not measured on a 2019-class laptop core (O-1.14)none yet
6The hash is bound to the header: one nonce serves one header, and a wrong nonce is rejected
Spec 1.6; litepaper Mining (implied by "checks a hash")
tested by the teamrepo 33f7b33, 9812466; igneum-pow 0.1.0 (bind.rs, 8 bound vectors, 29 crate tests)igneum-miner bad-nonce against a devnet node; igneum-pow hash-bound for the 96-nonce job across the 2^32 lane boundary; bench-log "first devnet blocks on the real lottery hash"833 blocks accepted by igneum-lottery-v1-bound on 3 nodes, 0 rejections; bad-nonce gave Reject(BlockInvalid); Metal, OpenCL and CUDA (emulated) workers bit-exact with the crate on the lane-boundary job. 3 October 2026, Apple M5 Maxnone yet
7The devnet runs at one block a second
Homepage stats ("1 / s"); litepaper Speed; roadmap phase 3
tested by the teamrepo 9812466, e9328c6; fork worktree vendor/igneum-node-diff branch difficulty3-node CPU devnet, igneum-miner mine --engine igneum-pow, 660 s; the dual-lane rule's 3-node test network (ports 26800 to 26821); bench-log "first devnet blocks" and "difficulty controller"CPU devnet: 1.29 blocks/s over 641 s, 1.03 blocks/s over blocks 610 to 816 after the first retarget, sink identical on 3 nodes at 61 of 64 samples. Kaspa's sampled rule on the overnight devnet did not hold the rate across a hashrate step (5.44 blocks/s for five minutes, 4.7x the schedule for eight minutes). The Igneum dual-lane rule's test network reached 1 block/s within 10% after 132 s, worst gap 7.3 s. 3 October 2026, Apple M5 Max. The phase 3 gate also asks for proofs under 60 s behind the tip; no proof exists (row 15)none yet
8Blocks are mined by GPUs on Apple and NVIDIA
Homepage live strip; journey phase 3 ("GPU miners on three vendors")
tested by the teamrepo 9812466, e9328c6; fork as row 1Metal worker proto-metal/igneum-bench --serve driven by igneum-miner --worker, 300 s; the overnight devnet record sim/difficulty/devnet-2026-10-03.csv; bench-log "first devnet blocks" and "difficulty controller"Metal: 506 jobs, 5,636 blocks found and accepted, 0 rejected, 0 CPU/GPU mismatches, 28.2 MH/s wall. NVIDIA: the overnight devnet record shows the PC's RTX 5090 mining at 116 MH/s estimated from the blocks, and the finality follower counted eight RTX 5090 identities at 862 to 936 blocks each. 3 October 2026, Apple M5 Max and the Windows PCnone yet
9Blocks are mined by a GPU on AMD
Journey phase 3 ("three vendors")
implementedrepo 0f1fdaf; bound kernel kernel_bound.cl in the packproto-opencl/host.c --serve on an AMD device against a devnet nodeThe bound OpenCL kernel is bit-exact with the crate on Apple OpenCL and the memory-hard pack passes 96/96 on AMD gfx1036, but no block count mined by an AMD device is recorded in the bench log. Until one is, the three-vendor mining claim is two vendors mined plus one vendor verifiednone yet
10Checkpoints lock every 30 s of chain at two thirds of active weight and at least 56.7% of total, and the floor stops conflicting locks in partitions and eclipses
Litepaper Finality, "What Igneum does not claim"; homepage "locked every 30 seconds"
tested by the teamrepo bbb264a (simulation), 60b1412 (fork run); fork "Finality: BLS12-381 vote keys ..." through "Miner: BLS identity ..."; spec 3.10sim/finality_v2.py (results in sim/results_v2.md); the 4-miner test network igneum-devnet-7 with getFinalityCheckpoints on three nodes; bench-log "finality rule V2" and "igneum-node devnet v2"Simulation: 0 conflicting locks in every honest partition and eclipse scenario with the floor; without it both sides of a 50/50 split lock after 60 min. Test network: 72 of 72 determined checkpoints locked on all three nodes, lock latency median 0.80 s, p90 1.08 s, 0 conflicting certificates; an equivocating key stripped at index 43 and excluded; with one voter left (39.6% of total) 0 locks for 749 s, then the heal locked 13 checkpoints within 30 s. 3 October 2026, Apple M5 Max, 53 minutes. Not on the live devnet (its miners do not vote yet); the simulation has no DAG; one unexplained stall of all three nodes in the first run, not reproducednone yet
11Hashrate that arrived today has almost no vote: ten days of the whole network's hashrate to reach a third of the weight, twenty for two thirds; 51% never reaches two thirds while honest miners stay
Litepaper Finality; homepage firsts
tested by the teamrepo bbb264a; sim/finality_v2.pyScenario B of sim/finality_v2.py, seeds 7 and 11share(t) = (t/30) x a/(1+a) holds to 0.04 points; a renter equal to the whole honest network (a = 1) crosses 1/3 on day 20 and never reaches 2/3; a = 9 crosses 1/3 on day 11.1 and 2/3 on day 22.2. The ten-day figure is a = infinity, honest miners gone. 3 October 2026, Apple M5 Max. A model with 1,000 Pareto keys and no DAG; the harness scenarios against the real node (1b, 3b, 4b) are stubsnone yet
12The difficulty rule recovers from a hashrate step within about a minute, where Kaspa's sampled rule never settles
Spec 2.3; litepaper Speed (implied); bench page
tested by the teamrepo e9328c6; fork worktree vendor/igneum-node-diff branch difficulty; sim/difficulty/sim.pysim/difficulty/sim.py on nine profiles plus the devnet record; the 3-node test network with "difficulty_rule" in the override file; cargo test -p kaspa-consensus --lib difficulty (9 pass); bench-log "difficulty controller"Simulator, settled seconds: x50 step 62 (Kaspa 1,542), /50 step 657 (Kaspa 12,296), the devnet's 75x step 79 (Kaspa never). Test network: within 10% of 1 block/s after 132 s warm-up, 214 s on a join, 85 s on a leave. 3 October 2026, Apple M5 Max under load 50 to 98. Monero and LWMA baselines reproduced from memory, approximate; no DAG in the simulator; harness scenarios 2b and 7b are stubsnone yet
13Every node executes the ordered transactions natively and reaches the same state root
Litepaper Proving ("Every node executes ... natively"), Building ("runs on Igneum unchanged")
tested by the teamrepo f5f8c80; fork worktree vendor/igneum-node-exec branch execution-layer; revm 43.0.3node tools/evm-smoke/smoke.mjs against a 3-node igneumd --simnet; igneum-exec-diff seq.json; bench-log "execution layer devnet v3"87 of 87 viem checks; state roots identical on 3 nodes at chain blocks 0, 56, 74 and 78; 57 executed transactions and 19 skipped copies agree with plain revm, 0 mismatches; balances match receipts to the wei. 3 October 2026, Apple M5 Max. Simnet skips proof of work, the prover is a stub, state is rebuilt from genesis at start, no EVM transaction relay between nodesnone yet
14Ethereum bytecode runs unchanged, with the documented differences of spec 7.1
Homepage Build card; litepaper Building
tested by the teamas row 13tools/evm-smoke/smoke.mjs: deploy via viem, increment, hashLoop, eth_estimateGas, eth_getLogsDeployment, calls, reverts, logs and gas estimates behave as viem expects; chain id 4463; the prototype pgas table gives 0.0095 to 0.028 pgas per gas, below the design's band before calibration. 3 October 2026, Apple M5 Max. The Prover precompile, proof records and the shard planner are not implementednone yet
15Every block is proven, with the proof landing within about a minute at launch
Homepage stats ("~60 s to a proof"); litepaper Proving; roadmap phase 3 gate
designedspec 7.2; docs/design/execution-layer.md section 5None exists. The phase 2 benchmark standard is docs/benchmarks/proving-e2e.mdNo SP1 shard has been proven on any card in this repository (ledger P1, P3). The devnet prover is a stub that signs claims. The 60-second figure is a design targetnone yet
16A 12 GB card proves one shard in about 20 s
Litepaper Proving ("The proving budget"); roadmap gate 2
designedspec 5.1 (Target)Replaced as a gate by the end-to-end standard in docs/benchmarks/proving-e2e.md: fixed workloads, job-to-accepted-proof latency, no growing backlogUnmeasured. A per-shard time can be met by shrinking the shard, so the project no longer uses it as a pass marknone yet
17The chip resistance target: a chip gains under 2x over a GPU
Litepaper Mining, "What Igneum does not claim"; homepage "no chip can be built for it"
designedspec 0.2 (Target); O-1.17Public benchmark with a leaderboard by card model and a standing bounty, January 2027 (O-1.17); the on-die-SRAM test on the RTX 5090 (R3.5)A target, not a measurement. Review round 3 priced a recompute chip with the 256 MiB cache on die at about 2.4x, approximate, before the usual chip-versus-GPU integer gain; the design answer (cache larger than any die) is open (spec 1.16)none yet
18The chip resistance measurements: the program is random-access bound, not bandwidth bound, and sits beyond a card's on-chip cache
Litepaper Mining ("bound by memory bandwidth", to be corrected), vs RandomX "Measured so far"
tested by the teamrepo aba248d, f2a1a64, 4b95c5eRTX 5090 dataset sweep 4 MiB to 1 GiB with proto-cuda/host.cu; bench-log "RTX 5090 first run" and "dataset sweep"At 1 GiB: 228.1 Mhash/s, 23.7 G random loads/s, 94.9 GB/s useful against a 1,638 GB/s dataset fill; inside the 96 MiB L2 (4 and 64 MiB) 1,340 to 1,353 Mhash/s, about 5.8x faster; 104 against 128 loads per hash gives 228 against 185 Mhash/s, proportional. 3 October 2026, RTX 5090, Windows, CUDA 12.8. Prototype dataset 1 GiB against 2 GB at genesis; a pure random-read microbenchmark (R3 chip designer, attack 2) has not runnone yet
19The lottery hash is sound as a hash: uniform output, deterministic, no out-of-bounds read, fuzzed
Litepaper vs RandomX ("Every number above is measured and logged")
tested by the teamrepo c52307e, 58a5a63; proto-metal/TESTS.mdproto-metal/igneum-bench --fuzz --edge --stats --determinism --memcheck; bench-log "hardening tests" and the re-run on the memory-hard dataset10,200 random programs, 1,305,600 hashes, 0 mismatches; 14 of 14 edge cases; bit frequency within 2.90 sigma, avalanche mean 31.99 to 32.04 of 32; deterministic fingerprint across 5 runs; every dataset read masked. 3 October 2026, Apple M5 Max. Statistics are not a security proof; the weak-program census (O-1.3) and the seed derivation review (O-1.4) are open; the fuzz set has run on Metal and the CPU onlynone yet
20No premine, no pre-sale, no allocation: every coin is minted by the schedule and every coin goes to the block producer (80%) and the proving pool (20%)
Homepage stats and Economics tiles; litepaper Supply, Economics
implementedrepo 6ac80a3; fork "igneum-node devnet v0"; consensus/core/src/igneum.rs, coinbase.rscargo test -p kaspa-consensus-core igneum (8 pass: subsidy table, ramp, split, cap) and cargo test -p kaspa-consensus coinbase (8 pass); igneum-miner inspect 40; bench-log "igneum-node devnet v0"Coinbases on the devnet: 80/20 exact on 39 of 39 single-payee blocks, the 20% to the igneum-proving-pool-v0 output; the per-second schedule sums to under the 4,000,000,000 cap by less than 100 coins; 3,168,808,781 units per DAA second in years 0 to 2, halving at 63,115,200 DAA s. 3 October 2026, Apple M5 Max. The devnet genesis carries no allocation; the mainnet genesis does not exist yet, so the claim is about the code and the stated rule, not a launch that has happenednone yet
21The proving pool's 20% reaches shard provers and aggregators
Litepaper Economics; homepage "20% provers"
designedspec 5.3None. The pool output exists (row 20); the payout from it against proof records is unwrittenThe escrow accumulated on the simnet (92.55 IGN at the end of the v3 run) and nothing can draw it. Rule decided: per block, divided among shards by consensus proving cost, sortition to 8 provers for 10 s then open (spec 7.2)none yet
22The base fee is burned in full and the priority fee splits 80% to the miner and provers, 20% to the apps whose code ran
Homepage Economics caption and Build card; litepaper "Where fees go"
tested by the teamrepo f5f8c80; fork worktree vendor/igneum-node-exectools/evm-smoke/smoke.mjs receipt checks; bench-log "execution layer devnet v3"Transfer receipt: burnedProvingFee 200 gwei, minerTip 16,800 gwei (80%), unregistered developer share 4,200 gwei burned; contract call: 80% to the miner, 20% credited to the payee the constructor registered, balance delta equal. 3 October 2026, Apple M5 Max simnet. The provers' part of the 80% is not split out (no provers exist); the base fee stayed at the 1 gwei floor throughoutnone yet
23No fee to any team, foundation or fund; 0 admin keys in consensus
Homepage Economics tiles and caption; litepaper "No fund, no foundation" and Governance
designedspec 5.5, 5.6 (decided 3 October 2026); spec 08Reading: no coinbase output, fee route or consensus key in the fork names any party (coinbase.rs, docs/fork-divergence.md)The emission code has two outputs (row 20) and the fee code has three routes (row 22), none to a team. The 1% fee of the official client is a client setting, not a protocol rule, and is not implemented (no client exists). The release key of spec 08 signs client updates and holds no consensus power; its custody policy is open (O-8.1)none yet
24External proving jobs pay 90% to the provers who delivered and burn 10%, once settled in IGN
Homepage "IGN burned from jobs, phase two"; litepaper Proving and Economics
designedspec 5.4None. Needs the proof bridge (spec 7.3, phase two) and the settlement switch (O-5.2)At launch jobs are paid on the customer's chain in the customer's currency and nothing is burned (ledger P10). No job market code existsnone yet
25The 4 billion cap, halving every two years, with a 30-day ramp from 10%
Homepage "4B IGN hard cap"; litepaper Supply and the emission chart
tested by the teamrepo 6ac80a3; fork consensus/core/src/igneum.rscargo test -p kaspa-consensus-core igneum; bench-log "igneum-node devnet v0"Ramp day 0 paid 10.03% of the full rate (317,767,704 units at DAA 806); the schedule table and the cap assert in the crate's own tests. 3 October 2026, Apple M5 Max. Base unit (8 or 18 decimals) is open (O-2.6); the spec was changed to follow the code's 365.25-day year (ledger E9) and a test that reads the published numbers back is still owednone yet
26A phone or browser verifies the chain from a locked checkpoint, at about 3.44 MB per day in checkpoint mode
Homepage "Browser checks Igneum" card (preview, commit f874f80); litepaper Building ("Light clients"), firsts row 6
designedspec 10 (10.5 bytes per day: 3.44 MB at 1,000 voters, 6.68 MB at 10,000, derived, approximate); repo f874f80 for the browser cardNone for the byte figure; site/verify/ for the card. BLS verification on a phone and in WebAssembly is O-10.3; the full-header mode on a phone is O-10.4The homepage card verifies the latest certified checkpoint's BLS certificate in the tab against a voter list from the node (light client v0, 3 October 2026). The byte figure is arithmetic on designed sizes (header 400 bytes, proof 400 bytes), measured nowhere; the proof the card would check does not exist (row 15)none yet
27The node survives malformed input, floods, withholding, partitions and eclipses
Litepaper Speed ("GHOSTDAG, the BlockDAG consensus proven on Kaspa"); spec 2
tested by the teamrepo 394030c; fork worktree vendor/igneum-node-harness; tools/harness/tools/harness/ scenario runner against a private igneumd test network (ports 27200+); bench-log "consensus attack harness"63 malformed cases, node up on every one; timestamp bounds exact; withholding at 10%, 25%, 33% and 45% released every 5 blocks within 2 sigma of share; partitions of 120 s to 3,700 s healed to one chain in 10 s; eclipse victims rejoined in 10 s; 50x template, submit and mempool floods left template p95 under 4 ms. One FAIL: a 45% withholder releasing every 20 blocks took 50.7% of blues (bound 47.4%). 3 October 2026, Apple M5 Max, load 50 to 61. Finality and difficulty scenarios are stubs until those branches mergenone yet
28Headers are validated cheaply before the lottery engine runs, so forged timestamps cannot force 256 MiB cache builds
Spec 2.4; ledger M15
tested by the teamrepo 0953ec7; fork worktree vendor/igneum-node-r3 branch r3-fixes at 5166ee26measure_m15_attack_before_and_after (ignored test, release, --features igneum-pow); kaspa-pow 8, header_processor 1, p2p pow_guard 2 tests50 forged headers: before, 50 cold builds in 10,595 ms and the live day evicted; after, 0 builds, all 50 rejected in 14 ms. 3 October 2026, Apple M5 Max under load 60 to 110. Measured through the validate path with skip_proof_of_work, not the daemon RPC; not merged into the main fork branchnone yet
+

Click a column heading to sort; click again to reverse. Versions: igneum-pow is the Rust crate at version 0.1.0; repo commits are this repository's; fork commits are the node fork and its worktrees, named by message as the engineering log names them. Source of every number: the engineering log. The source of this page is docs/evidence.md in the repository.

+

What would move a row

+
+ + + + + +
FromToWhat it takes
designedimplementedCode in this repository with test vectors that pass
implementedtested by the teamA bench-log entry with the machine, the date, the command and the number
tested by the teamreproduced externallyThe repository public (January 2027), the command published, and a third party's run with the same result, linked from the row
reproduced externallyreviewed independentlyA named reviewer's published finding on that version. Funding for review is docs/plans/funding.md
anythe row's status falls backA new version of the code or rule the row names
+
© 2026 Igneum. Statuses are honest as of 3 October 2026 and change only through this page. Nothing on this page is an offer to sell anything.
+
+ + + diff --git a/site/index.html b/site/index.html index e1a4a157d..2b80d5bb6 100644 --- a/site/index.html +++ b/site/index.html @@ -241,6 +241,7 @@ footer .wrap{padding-block:48px 32px} Economics Litepaper Log + Evidence Live Get the miner