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

External review of the litepaper: response, 15 ledger entries, fix rows, open items, four-state rule, miner-app rules, phase-2 gate

Browse source 
docs/review/external-2026-10-03.md holds the reviewer's text verbatim and the
classification: 13 already answered, 15 new, 1 wrong. New ledger entries M22,
F19, F20, P16, P17, E12, E13, E14, E15, G11, X13, X14, X15, X16, X17 with
cross-references on M1, P1, E1, G6, X1, X5, F16. fud-fixes rows 89 to 103.
Open items O-3.15, O-3.16, O-5.9 to O-5.11, O-7.1, O-7.2, O-8.2, O-8.3,
O-X.1 to O-X.3 (count 73). Execution layer 2.4: included, executed, proven,
finalised. Phone app 4.1: net earnings after tariff, two incomes, failed jobs,
release state, isolation. journey.json phase-2 gate: fixed workload, end to
end, no growing backlog, three independent reproductions.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-03 22:29:41 +00:00
parent 51d4d1a652
commit 035a63013e
6 changed files with 233 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
docs/design/execution-layer.md
View file

@ -130,6 +130,19 @@ What each word means to a user, a wallet or an exchange.
A bridge withdrawal waits for proven and locked. `igneum_getTransactionStatus` returns the three flags (section 8.2).
### 2.4 The four states an interface must show
Rule (external review, 3 October 2026; ledger P17, O-7.2). Every surface that reports a transaction (the RPC of 8.2, wallets, the explorer, the phone app) reports exactly one of four states, and never a stronger word than the chain's own state.
| State | Meaning | Shown as |
|---|---|---|
| Included | In at least one block the node holds; not yet in a segment of the selected chain, or in a merged block waiting its turn in the sequence; nothing has executed | "included", with the block count |
| Executed | Section 2.3 | "executed" |
| Proven | Section 2.3 | "proven" |
| Finalised | Locked in section 2.3; the user-facing word | "finalised" |
While `finality_active` is false (spec 3.9) no surface shows "finalised" for any transaction; it shows "finality not active" and the finality-depth wait of spec 2.1 in its place. Proven says the execution is correct and nothing about availability: full blocks are what every full node holds and executes (ledger F13), and a light client in checkpoint mode takes data from nodes under spec 10.1. `igneum_getTransactionStatus` gains a `state` field holding the one word, beside the flags it already returns. Test: the conformance set of O-7.2.
## 3. EVM semantics on a DAG
The environment revm sees is built from the chain block C whose segment is executing. Ported contracts get this table; it is the "documented differences" the FUD ledger entry P5 promises.

14
docs/design/phone-app.md
View file

@ -68,6 +68,19 @@ The Miners screen shows one card per rig as the Windows app's dashboard does (on
The app changes nothing on the rig. Start, stop, pool switching and overclocks stay on the desktop app and the mining OS. This keeps the app's only side effect a signed transaction (A1) and keeps the store review simple.
### 4.1 What the Miners screen must show
Rules from the external review of 3 October 2026 (ledger X17, O-8.2). They bind the phone's display; the desktop client carries the same rules in O-8.2 and the isolation design in O-8.3.
| Rule | Display |
|---|---|
| Net earnings | Per card and per day, after an electricity tariff the user enters in Settings; the gross beside it; "estimate" until the pool or the chain has paid |
| Two incomes | Mining income (coinbase under the user's key) and proving income (proof records naming the user's prover key) in separate columns, never summed into one number without both parts visible |
| Failed jobs | Every failed or retried shard or job the pool or node reports, with its reason, as a list the user can open |
| Release state | The rig's running release and its hash, and any pending release the user has not accepted (spec 8.2 item 4), read from the node card's status lines |
| Isolation | The phone holds no proving job and no key; the Miners screen states that the desktop prover runs apart from the wallet (O-8.3) |
| States | Everywhere the app shows a transaction it uses the four words of `docs/design/execution-layer.md` 2.4 (included, executed, proven, finalised); the three-word status line of section 3 becomes four, and "finality not active" replaces finalised while spec 3.9's flag is false |
## 5. The node card
The desktop app's dashboard already draws a NODE card (state, blocks, headers, blue score, peers, blocks per second, difficulty direction, uptime; `proto-cuda/windows-app/README.txt` item 2). This design gives the card a "Show on phone" action that renders a QR code, and the phone app a scanner that reads it. The desktop side is Designed and not in the launcher today.
@ -151,6 +164,7 @@ No durations for the engineering are given here beyond the journey's phase dates
| P5 | Remote management of rigs from the phone (start, stop, switch pool) was left out of version 1 for store simplicity and to keep the app's only write a signed transaction | Revisit at phase 5 after both stores have approved version 1 |
| P6 | Hardware wallets over Bluetooth | Version 2, after a device vendor's Igneum chain id support, which needs the chain id registered on ethereum-lists/chains (spec 7.1) |
| P7 | The developer entity shown on the store listing | Section 12 |
| P8 | The display rules of 4.1 need fields the pool protocol's `stats` and the node card do not yet carry (the tariff is local; failed jobs, release state and proving income need fields) | Add the fields with O-9.5 and node card version 2; O-8.2 |
## 12. The decision for the project lead

22
docs/fud-fixes.md
View file

@ -141,6 +141,28 @@ Added after `docs/review/round-3-2026-10-03.md`. Rows continue the numbering of
Not yet rowed from round 3: M16, M17, M18, M19, M21, F16, P14, P15, C13, L8, G10, X12. Their fixes are in the ledger entries.
### 2.3 External review entries (3 October 2026, night)
Added after `docs/review/external-2026-10-03.md`. Rows continue the numbering of section 2.2.
| # | Ledger | Issue | Fix | Who | When | EXPOSES |
|---|---|---|---|---|---|---|
| 89 | P16 | Phase 2 gate passable by shrinking the shard (design R2's fallback); no end-to-end standard | J phase 2 gate rewritten 3 October 2026 (night): fixed workload, job received to accepted proof, no growing backlog, three independent reproductions. Left: O-7.1, the benchmark itself; R2's fallback sentence to say a halved shard is a new declared workload, never a pass | Claude (J, done); measurement | before public repo | no |
| 90 | F19 | Bought, borrowed or stolen vote keys carry 30 days of weight; only renters are modelled | O-3.15: `finality_v2.py` key-transfer scenario against the same share as fresh hashrate, with the 40/40/20 row; decide W5 re-earning and weight decay | Claude (sim), cryptographer | before testnet | no |
| 91 | F20 | No statement of what holds during a finality pause; the seed pipeline from uncertified checkpoints is a proposal (O-4.3) | O-3.16: decide O-4.3, write the four pause guarantees into spec 3.7, devnet stall through 3 epoch boundaries | Claude (spec), measurement | before testnet | no |
| 92 | P17 | Three states shown; included is a list | Design 2.4 written 3 October 2026 (night). Left: `state` field in `igneum_getTransactionStatus`, the phone-app and explorer words, the O-7.2 conformance set | Claude (design, done); code, owner execution engineer | before testnet | no |
| 93 | E12 | No stress test of mining against proving under shocks; R8 has not run | O-5.9: R8 extended with 10x external pay, falling price, operator exit, unfulfilled assignments, profit-only clients; then the phase 4 devnet | Claude (sim), measurement | before testnet | no |
| 94 | E13 | No payment-route diagram; the routes are spread over LP Economics, the HP tiles and the customer brief | O-5.10: one figure, one route per row (emission, base fee, priority fee, jobs at launch, jobs after the bridge, client dev fee), in LP Economics and the brief; operator revenue never summed with protocol revenue | Claude | now | no |
| 95 | E14 | No funding table | Cost lines against sources, labelled funded / dependent on revenue / unfunded, with the late-revenue case; internal until counsel reads it; unfunded lines stated in LP | the project lead (numbers), Claude (table) | before public repo | EXPOSES: sources name the entity, never a company the project lead already owns |
| 96 | E15 | Security budget through halvings with low fees, no demand and a flat price: unmodelled | O-5.11 model; the failing year and price stated in LP Supply next to the tail alternative (row 27) | Claude (model) | before mainnet | no |
| 97 | G11 | Repository private; harnesses, vectors, simulators and spec could be public now, labelled experimental | the project lead decides the components, licence and date; section 5 steps 1 to 7 first in any case; one proof-request workflow and one reference app before any app set | the project lead | now (decision) | no |
| 98 | X13 | Phase 4 gate is a signature; the brief says no payment | Brief v0.2: agree workload, proof format, deadline, failure rate and price before the pilot; publish the outcome and the customer's reason; paid pilot added to the J phase 5 line; entity and terms per L4; timing is the project lead's | Claude (brief), the project lead, counsel | before testnet | no |
| 99 | X14 | Independence undefined; concentration in hashing, signing, proving and aggregation unreported | O-X.1: define independence; four concentrations as top-1, top-3 and top-10 shares over 30 days on the live page beside the gate | Claude (observer), the project lead (definition) | before testnet | no |
| 100 | X15 | "The chain runs without its founders" untested | O-X.2: 24-h founder shutdown on the public testnet at a published time; record what continues | measurement | before mainnet | no |
| 101 | X16 | No evidence page; one voice for implemented, team-tested, reproduced and reviewed | O-X.3: one row per public claim with status, version, test, result and one of the four labels; audits tied to versions; ships with the benchmark | Claude | before public repo | no |
| 102 | X17 | Client shows gross earnings only; no mining and proving split, no failed jobs, no isolation design | O-8.2 display rules (client and phone-app 4.1, written 3 October 2026 night); O-8.3 isolation design before the first external job; update control already spec 8.2 item 4 | Claude (design); miner client (code) | before testnet | no |
| 103 | M22 | Bounty has no metric, judge, eligible hardware or fund; 2x is not the economic line | Scoring rules (per-program distribution of hash/s and hash/J, capital per unit of hash rate, longevity, shortcut classes) published with the benchmark; funder, judge and reward are the project lead's; public claim limited to "competitive against the best independently proposed design across tested workloads" | Claude (rules), the project lead (fund) | before public repo | EXPOSES: the payer is the entity (row 50) |
## 3. Overclaims still in public text today
Checked against the files this evening. "present" means the quoted text is still live. "missing" means the item is an addition that has not been made. "fixed" means the replacement is in. Line numbers are from the stripped page text, not the HTML.

155
docs/fud-ledger.md
View file

@ -35,6 +35,8 @@ Answer: Correct that the arithmetic is simple on purpose. Integer only, because
Evidence: `docs/bench-log.md` (RTX 5090 dataset sweep), `proto-metal/TESTS.md` section 8 "Not demonstrated" item 2. Bounty: not yet.
Cross-reference (external review, 3 October 2026, night): the bounty's scoring rules, eligible hardware, judge and funding are M22; "under 2x" is a hash-rate target and not the economic threshold.
### M2. Your own prototype is not memory-hard
"Your TESTS.md says computing the dataset inline runs 110x faster than loading it. You put the 228 Mhash/s number on the website anyway."
@ -277,6 +279,8 @@ Answer: Correct. It is the phase 2 gate, to be measured on a 3060-class card, an
Evidence: `site/journey.json` phase 2 gate. Measurement: not yet. Fix: overclaims list, item 27.
Cross-reference (external review, 3 October 2026, night): the phase 2 gate now carries an end-to-end acceptance standard, P16 and O-7.1; design R2's halve-and-re-measure fallback is no longer a pass.
### P2. Real-time proving needs a hundred GPUs per block
"Succinct needed on the order of 160 consumer GPUs to prove Ethereum blocks in real time in 2025. You have one block a second. Your gas throughput will be a rounding error or your proofs will fall behind."
@ -371,6 +375,8 @@ Answer: True, and the design doc records the choice: "A 1% tail is the Monero mo
Evidence: design doc "Decision: hard cap". Litepaper: "Supply" section states the cap, not the trade-off.
Cross-reference (external review, 3 October 2026, night): the budget through halvings at low fees, no demand and a flat price is modelled under E15, O-5.11.
### E2. Half the coins in two years is an insider schedule
"Nearly a quarter of supply in year one, half by year two, founders mining from genesis with the software they wrote and a month's head start on the benchmark. That is a premine with a GPU."
@ -492,6 +498,8 @@ Answer: Correct. Stratum v2 job declaration lets a hasher choose transactions wh
Evidence: none in repository. Fix: overclaims list, item 45.
Cross-reference (external review, 3 October 2026, night): whether members use declared templates is measured under O-9.5; concentration reporting is X14.
### G7. The one-click app is an update key over the network
"An app that auto-updates on ten thousand machines is an admin key. Whoever signs the update controls the miners, the wallets the app made, and the vote keys."
@ -693,6 +701,8 @@ Answer: Correct. Either the repository goes public with the litepaper or the sen
Evidence: `site/index.html` footer link; CLAUDE.md says private. Fix: overclaims list, item 22.
Cross-reference (external review, 3 October 2026, night): publishing the harnesses, vectors, simulators and spec now, labelled experimental, is G11, a decision for the project lead.
### X2. "Get the miner" with no miner
"A big button that says 'Get the miner' on a chain with no miner, no testnet and no benchmark. Vapourware CTA."
@ -729,6 +739,8 @@ Answer: Correct. "Independent" needs a definition that can be measured: distinct
Evidence: `site/journey.json` phase 5 gate.
Cross-reference (external review, 3 October 2026, night): the definition and the four concentration metrics are X14, O-X.1.
### X6. The one-click app is a honeypot vector
"An installer that creates a wallet, holds keys and mines, promoted to people who have never run a miner. Fake copies will be the first Google result. Defender flags every miner as malware."
@ -1138,6 +1150,8 @@ Answer: Correct as the proposal stands. For an exchange "locked" must be irrevoc
Evidence: spec 3.5, 3.9. Review id R3.17.
Cross-reference (external review, 3 October 2026, night): what holds during a pause, and the seed pipeline through it, is F20, O-3.16.
### F17. Keys are free and the official client mints eight per card
"Your launcher runs 8 identities per vendor, each with its own vote key. For the vote that is harmless by design. For shard sortition, which ranks every eligible key and takes 8, it is the whole game: 1% of hashrate holds 259 keys above dust. And a few thousand PCs cross your 8,192-voter switch, whose construction is open."
@ -1281,3 +1295,144 @@ Status: Conceded, fix now.
Answer: Correct. The bench-log is append-only and the project's rule is that a number exists when it is logged with its command. Tonight's run needs its entry: the step profile, the retarget trajectory from the CSV (134.2 M to 14.2 M expected hashes by DAA 812, further per the brief), the 2-minute block-rate buckets, the epoch-boundary gap, and the launcher's summed status against the block rate, with the gap explained (template age, sibling blocks dropped by the one-block-per-job rule, or queue stalls across eight processes).
Evidence: `/tmp/igneum-devnet/node1.log`, `sim/difficulty/devnet-2026-10-03.csv`, the launcher log on the PC. Review id R3.15.
---
## External review entries (3 October 2026, night): the litepaper
Added by `docs/review/external-2026-10-03.md`, which holds the reviewer's text verbatim and the point-by-point classification (13 already answered, 15 new, 1 wrong). The reviewer is a general-purpose AI assistant; its claims about third parties are approximate. Entries are placed under their section letters and numbered on from the last entry of each section. Count after this block: 122 entries (107 plus 15). Every entry is Open with its experiment or decision named.
### M22. The ASIC challenge has no scoring rules, and 2x is not the economic line
"Your bounty says 'beats a GPU by more than 2x'. Per what? Hashes per second, per joule, per dollar, on the average program or the worst hour? A chip at 1.6x with half the capital cost wins. And nobody has published eligible hardware, funding or a judge."
Status: Open, decision for the project lead (terms, judge and funding) and experiment scheduled (extends O-1.17).
Answer: Correct. M1 and O-1.17 name a bounty for "more than 2x" without a metric, a judge or a fund, and 2x is a design target for the hash, not an economic threshold: a chip at 1.5x per joule and 3x per dollar of capital is an economic ASIC whatever the hash-rate ratio says. The scoring rules go out with the January 2027 benchmark: hashes per second and per joule measured per program over a published set of at least 100 epochs, reported as a distribution (worst decile, median), never as one average; capital cost per unit of hash rate at a stated volume; a longevity term against the instruction-family reserve and the dataset growth of spec 1.13; and the shortcut classes (recomputation, partial storage, weak-program selection) scored separately. Eligible hardware assumptions, the judge, the reward and the payer are the project lead's decisions (fud-fixes row 50: the payer is the entity). The supportable public claim until a design has been scored: across the tested workloads and the stated economic assumptions, consumer GPUs remain competitive against the best independently proposed specialised design. Extends M1, M16 and C13.
Evidence: M1, O-1.17, spec 1.13 and 1.16, M16's arithmetic. Experiment: the scoring rules published with the benchmark, then the first scored submission. Review: external, point 4.
### F19. Old vote keys can be bought; fresh hashrate cannot buy weight
"Weight is 30 days of blocks per key, and keys are free to make and free to sell. I do not rent hashrate for 20 days. I buy, borrow or steal the vote keys of pools that already mined those 20 days. Your simulation models the renter and never the buyer."
Status: Open, experiment scheduled (O-3.15).
Answer: Correct, and the ledger had no entry for it. Spec 3.1 W6 says weight is the only Sybil-resistant quantity because it takes public mining to earn; it does not say what happens when an earned key changes hands. A compromised or sold key carries its whole 30-day history, so the 10-day and 20-day figures of F5 apply only to an attacker who mines; a buyer's day count is zero. What limits it today: W5 moves weight to a successor only by a message the old key signs (O-3.11), equivocation strips a key for 30 days (3.6), and pool keys are few and public (F10). What is missing: the acquisition cost of the top pools' keys against the hashrate cost of F5, whether weight should decay faster than 30 days when a key's blocks stop matching its earlier profile, and whether W5 should make the successor re-earn. Gate 3, in `finality_v2.py`: k% of weight changes hands at day 0 against the same k% arriving as fresh hashrate, for k in 20, 34 and 40, with the 40/40/20 partition row the reviewer asked for under the active-set rules and the floor, reporting time to a conflicting lock under each.
Evidence: spec 3.1 W5 and W6, 3.6; `sim/results_v2.md` (renter scenarios only). Experiment: O-3.15. Review: external, point 2.
### F20. During a finality pause the program must keep advancing, and nothing says which guarantees survive
"Your epoch seed is a VDF of a certified checkpoint. When finality pauses for four days, your own 50% churn figure, which checkpoint seeds hour 50? And when the pause ends, what exactly was still guaranteed in between?"
Status: Open, decision scheduled at gate 3 (O-3.16, with O-4.3).
Answer: Correct on the gap. Spec 4.3 proposes that the seed checkpoint may be the uncertified selected-chain block at the checkpoint blue score, so a pause does not stop mining, and O-4.3 leaves the decision to gate 3; the design document still says an epoch cannot start without a valid proof. No text states what holds during a pause: that blocks, execution and proofs continue (3.7 item 2 says proof of work in practice), that every lock before the pause stands (3.5), that `finality_active` is false and exchanges wait on the 12-hour finality depth (3.9), and that the seed pipeline advances from uncertified checkpoint blocks with the reorg exposure that implies (a 1,200-DAA-s lead plus d). Gate 3 takes the uncertified option or states the stop; this ledger recommends uncertified, as spec 4.3 does, and the four guarantees go into spec 3.7. Test: the devnet with the finality module stalled by a 45% silent set (3.3.1 row C) through at least 3 epoch boundaries, recording that the program advanced on schedule, that no node forked on the seed, and that the pre-pause locks survived the heal.
Evidence: spec 4.3 (O-4.3), 3.3.1, 3.5, 3.7 item 2, 3.9. Experiment: O-3.16. Review: external, point 2.
### P16. The proving gate can be passed by shrinking the shard
"'A mid-range GPU proves a shard in under 20 s.' Your own R2 says: if missed, halve the shard and re-measure. That is the trap. Fix the workload first, measure the whole journey, and have strangers reproduce it."
Status: Open, experiment scheduled (O-7.1). The journey's phase 2 gate was rewritten the same night.
Answer: Correct. P1 conceded that the 20-s figure is a target; this is about how the target is tested. `docs/design/execution-layer.md` 9.1 R2 passes at any shard size by halving `S_p` until the time fits, so a pass says nothing about throughput, and R4 measures the wrapper only. The phase 2 benchmark now has an acceptance standard: a fixed published workload (real transactions, never empty blocks or tiny shards) with its shard plan, proven end to end from job received to proof accepted, including queueing, transfers, aggregation, verification and payment; the median and the slowest 5% and 1%; failure and retry rates; full cost (electricity, host, bandwidth, aggregation, failed work, hardware); results per advertised card with mining and proving compatibility stated separately; sustained with no growing backlog; reproduced by at least three unrelated operators from the published code and configuration. A halved shard is a new declared workload, never a pass. The reviewer's figure for SP1's cluster requirement (NVIDIA, 24 GB, approximate; not checked, SP1 is not in `vendor/`) is why a 12 GB card has to show the whole pipeline, which R2 and R4 already target.
Evidence: P1; execution-layer 9.1 R2 and R4; `docs/bench-log.md` (no shard has been proven on any card). Experiment: O-7.1. Review: external, point 1.
### P17. Interfaces must show four states, and the design shows three
"Included, executed, proven, finalised are four different facts. Your status call returns executed, proven, locked and a list of blocks. A wallet that shows a balance at 'included' is lying by omission."
Status: Open, rule written (3 October 2026, night) in `docs/design/execution-layer.md` 2.4; experiment scheduled (O-7.2).
Answer: Correct. Design 2.3 defines executed, proven and locked; `igneum_getTransactionStatus` carries `included_in` as a list and never as a state; the phone app (phone-app 3 and 9) shows three words. A transaction in a block not yet on a selected chain, or in a merged block waiting its turn in the sequence, is included and nothing more, and on a DAG that gap is routine. The rule now in 2.4: every RPC, wallet, explorer and app reports exactly one of included, executed, proven, finalised (the user-facing word for locked), never a stronger word than the chain's own state, and shows "finality not active" in place of finalised while `finality_active` is false (3.9). Proven says nothing about availability: full blocks are what every full node holds (F13) and a light client takes data from nodes under spec 10.1. Test: a wallet and RPC conformance set on the devnet, one transaction through each state and the three failure paths (skipped, reorged out, finality paused).
Evidence: execution-layer 2.3, 2.4, 8.2; phone-app 3 and 9; spec 3.9, 10.1. Experiment: O-7.2. Review: external, point 2.
### E12. Selfish operators under a price shock
"Outside proving pays ten times more and IGN halves in a week. Every rational operator leaves hashing for jobs. Do your internal proofs go unproven, do queues grow, does anything bring them back? Assume nobody runs your client's scheduler."
Status: Open, simulation and testnet experiment scheduled (O-5.9).
Answer: The premise that the design relies on voluntary scheduling is wrong; the stress test is missing. Nothing in spec 5.3 or 7.2 asks an operator to prove at a loss: the 20% pool is paid per block as a fixed amount divided by proving cost, shards go by sortition then open claiming, and an unproven block delays only its proof (P9). The two base fees re-price when provers leave (spec 5.1: `f_p` rises from the unproven backlog) and the backlog rule of design 4.3 halves `B_p` per 600 blocks of backlog, so the chain carries less gas rather than falling behind. What is not shown is the loop under the reviewer's shocks. R8 simulates `f_e`, `f_p` and the hash-or-prove switch against devnet fee traces; it has not run, and it models no external price ten times the internal one, no falling IGN price, no large operator leaving, no deliberately unfulfilled assignments and no profit-only clients. O-5.9 adds those five to the R8 simulation and then to the phase 4 devnet with profit-only prover clients, reporting backlog depth, time to clear, the `f_p` and `B_p` paths, and income per card under each shock. Extends P8, P9, E6 and R8.
Evidence: spec 5.1, 5.3, 7.2; execution-layer 4.3, 9.1 R8. Experiment: O-5.9. Review: external, point 3.
### E13. One diagram per payment route, or operator income and protocol income blur
"Your customer brief says dollars on the customer's chain; your economics section says IGN with a burn; your tiles said 'at launch'. Draw every route separately: currency, recipient, fee, any IGN purchase, any burn."
Status: Open, document scheduled (O-5.10).
Answer: Correct. P10 fixed the contradiction in words and E11 fixed the tile; no single figure shows the routes. There are five: emission (80% producer, 20% proving pool, per block); base fee (burned in full on both gas dimensions); priority fee (80% miner and provers, 20% called app, unregistered share burned); external jobs at launch (customer's chain, customer's currency, payout contract by miner address, no burn); external jobs after the proof bridge (IGN on Igneum, 90% provers, 10% burn). A sixth is the official client's 1% dev fee to the entity (E5), which is operator income and never protocol income. The diagram goes in the litepaper's Economics section and in the customer brief, one route per row with currency, recipient, fee and burn, and no row that adds operator revenue to protocol revenue. Boundless's documented lifecycle (request, bidding, verification, payment) is the reviewer's comparison and approximate (C10).
Evidence: spec 2.5, 5.1 to 5.4; `docs/commercial/prover-customer-brief.md`; P10, E5, E11. Decision: O-5.10. Review: external, point 5.
### E14. No funding table
"Who pays for development, the independent review, the infrastructure and an incident response, from what, and what happens if revenue is late? You have no fund by design, which means you have no table either."
Status: Open, decision for the project lead.
Answer: Correct. The fund was removed on purpose (E4) and the team earns from the 1% client fee, its pool, its provers and the app share (E5); none of that is costed, and the second client has no funder (fud-fixes row 47), nor do the external reviewers (G1), the bounty (M22), the seed nodes or the public infrastructure. The table: each cost line (development, independent review, infrastructure, incident response, the bounty, the second client) against its source (the entity's own money, the client fee, the proving business, a grant mechanism added by signalling), labelled funded, dependent on future revenue, or unfunded, with the consequence if revenue is late. It assumes a flat IGN price, which is E15's test. The table is internal until counsel has read it (L1, L2); the litepaper states which lines are unfunded.
Evidence: E4, E5, G1, G5; fud-fixes rows 47, 50, 71. Decision: the project lead, before the repository goes public. Review: external, point 6.
### E15. The security budget through successive halvings with low fees and no external demand
"Walk the schedule forward: emission halves every two years, the base fee is burned, the priority fee is small on a quiet chain, and nobody buys proofs. What does a card earn in year 7, and at what price does hashrate leave? Report what reaches miners and provers apart from what is burned."
Status: Open, simulation scheduled (O-5.11); extends E1 and E6.
Answer: Correct that the ledger concedes the cliff (E1) and the halving bet (E6) and has computed neither. O-5.11 is a model: emission per spec 2.5 through year 12; a fee grid (priority fee per block at low, medium and high use; external jobs at zero, low and the brief's launch assumption); hashrate as a function of income per card at a stated electricity price under a flat, a falling and a rising IGN price; reporting per year the payments to miners and to provers apart from the burn, the hashrate that income supports, and the cost of a 51% rental against it. The honest output is the year and the price at which the budget fails under the no-demand, flat-price case, stated in the litepaper's Supply section next to the tail-emission alternative. The flat-price column is the one that counts.
Evidence: spec 2.5, 5.1 to 5.4; E1, E6. Experiment: O-5.11. Review: external, point 6.
### G11. Publish the inspectable components now, labelled experimental
"The organisation has no public repository. Harnesses, test vectors, simulators and the specification could be public tonight, marked experimental. Waiting for January is a choice, and it reads as hiding."
Status: Open, decision for the project lead.
Answer: The fact is conceded in X1 (the repository is private and the site says reproducible) and the pre-publication steps are in `docs/fud-fixes.md` section 5 (ledger out of the tree, CLAUDE.md rewritten, history rewritten, licence). The reviewer asks for an earlier date than January 2027 and a narrower scope: the benchmark harnesses, the test vectors, the simulators and `docs/spec/`, each labelled experimental, with the node fork following when the gate-2 work is in. the project lead decides which components, under which licence, and when; section 5 runs first in any case. The reviewer's companion advice, one proof-request workflow and one reference application before any broader app set, is the same decision's scope: the genesis-app list (G4, O-5.4) is not a prerequisite for the benchmark or the testnet.
Evidence: X1; `docs/fud-fixes.md` section 5. Decision: the project lead. Review: external, point 7.
### X13. One paying customer for a stated reason
"'One rollup signs for testnet' is a letter of intent with no money. A customer who pays once, pays again without a rebate, and then a second unrelated customer, is evidence. A signature is not."
Status: Open, experiment scheduled (the pilot itself), decision for the project lead on timing and terms; extends L4 and the customer brief.
Answer: Correct. The phase 4 gate is a signature and the brief says so ("a signed letter of intent with no payment"). The progression is adopted and the brief carries it at its next version: agree the workload, proof format, deadline, failure rate and price before the pilot; publish the outcome and the customer's own reason for buying; then repeat purchases without reimbursement; then several unrelated customers. The reviewer places the paid pilot before public testnet; the journey has it in phase 5. Phase 4 keeps the signature as its gate and phase 5's line gains the paid pilot; moving it earlier is the project lead's call and needs the entity, terms and tax treatment of L4 first.
Evidence: `site/journey.json` phases 4 and 5; `docs/commercial/prover-customer-brief.md`; L4, L6. Experiment: the pilot, reported in the bench-log with the agreed numbers. Review: external, point 5.
### X14. Concentration is unmeasured in four places
"Define independent for the 1,000-miner gate, then report concentration in hashing, checkpoint signing, proving and aggregation, because a thousand miners behind two pools is two."
Status: Open, measurement scheduled (O-X.1); extends X5.
Answer: Correct. X5 conceded that "independent" needs a measurable definition (distinct ASNs, benchmark hardware fingerprints, pool attestations) and left it to phase 4. The four concentrations can each be computed from chain data: blue blocks per vote key and per pool (hashing), signed weight per key in certificates (checkpoint signing), proof records per prover key (proving, once P12's fix puts the key in the statement), and certificates and proof records per aggregator key (aggregation). The gate reports all four as top-1, top-3 and top-10 shares over 30 days, beside the independence count, on the live page. Transaction choice inside pools is a separate measurement and is already scheduled: whether members of the reference pool use declared templates (spec 9.4.2, mode C) is recorded under O-9.5.
Evidence: X5, F10, P12, spec 9.4.2. Experiment: O-X.1. Review: external, point 6.
### X15. Remove the founders from a test network and show what continues
"'The chain runs without its founders' is a sentence. Take the team's miners, provers, aggregators, seed nodes, observer and site off a running testnet and show what keeps producing blocks, proofs and locks."
Status: Open, experiment scheduled (O-X.2).
Answer: Correct, and it is the right test for the litepaper's sentence (Governance). The test: on the public testnet, at a published time, stop every node, miner, prover, aggregator and seed node the project runs, take the observer feed and the live page down, and record for 24 hours: blocks per second, proof lag, certificates per hour, and a fresh node syncing from the seed list in the client (spec 10.6). What continues is what the sentence may claim. Dependencies the test will expose: the seed list, the release key (G7), the reference pool, the VDF evaluators (every node ships one, 4.5) and the founders' own hashrate share (E2).
Evidence: `site/litepaper.html` Governance; spec 10.6, 4.5; G7, E2. Experiment: O-X.2, before mainnet. Review: external, point 6.
### X16. An evidence page with four labels
"Every claim needs a status, a software version, the test that produced it, the result and whether anyone outside reproduced it. 'Implemented', 'tested by the team', 'reproduced externally' and 'reviewed independently' are four different things, and your bench-log uses one voice for all of them."
Status: Open, publication scheduled (O-X.3).
Answer: Correct. The bench-log records machine, command and number; the spec labels rules Designed, Measured, Target or Decided; neither says who ran a test or whether anyone else has. The evidence page ships with the benchmark release and carries one row per public claim: the claim, its status, the exact version (commit and release), the reproducible test (command or script), the result with its bench-log entry, and one of the four labels, with audits and reviews tied to the version they read. "Tested by the team" is the only label any row can carry tonight; G2's disclosure applies to the whole page. The ledger's own statuses map onto the labels and are not replaced by them.
Evidence: `docs/bench-log.md`; `docs/spec/README.md` labels; G2. Publication: O-X.3. Review: external, point 7.
### X17. The miner app must show net earnings and keep jobs away from keys
"Show me what a card earns after my electricity tariff, mining and proving separately, which jobs failed and why, which release I am on and whether I accepted it, and promise that a proving job can never read my wallet. Your spec covers the update and the seed, and nothing else on that list."
Status: Open, design and measurement scheduled (O-8.2, O-8.3); update control and the seed are answered by design (spec 8.2 item 4, 8.5).
Answer: Update control and the seed are decided (spec 8.2 item 4: no silent updates, the user accepts each release; 8.5: seed confirmed, hardware wallet). The litepaper promises earnings "in IGN and in your currency" and M13 promised projected earnings before mining starts; neither nets off power. New requirements for the official client and the phone monitor: (a) net earnings per card after an electricity tariff the user enters, the gross beside it; (b) mining income and proving income reported separately, per card and per day; (c) hardware compatibility and power limits per card, with mining and proving capability stated separately as the benchmark reports them (P16); (d) every failed or retried job visible with its reason; (e) the running release, its hash and any pending release the user has not accepted; (f) isolation: proving jobs run guest programs supplied by strangers, so the prover process holds no wallet key, no seed and no vote key, runs under a separate OS user or sandbox, and reaches the signer only through a local socket that signs payout claims and nothing else, designed and reviewed before the first external job runs. The phone app carries (a), (b), (d) and (e) as display rules (phone-app 4.1).
Evidence: spec 8.2, 8.5; `site/litepaper.html` For miners; M13; `proto-cuda/windows-app/README.txt`. Experiment: O-8.2 (display rules measured against the pool protocol's `stats` on the phase 4 devnet), O-8.3 (isolation design reviewed, then an escape test with a hostile guest program). Review: external, point 7.

34
docs/spec/06-open-items.md
View file

@ -63,6 +63,8 @@ An item closes when its measurement is in `docs/bench-log.md` or its decision is
| O-3.12 | Vote message and certificate wire formats, aggregation rules, bitmap size at 10^4 keys | Specify with the P2P layer | 3 |
| O-3.13 | `finality_active` flag semantics and exchange guidance (section 3.9) are Designed and untested | Devnet stall test; exchange guidance reviewed by an operator | 3, 4 |
| O-3.14 | Finality simulation with the DAA in the loop under a pulsed rental (ledger M14 and F14, round 3): every run of `sim/results_v2.md` assumed a perfect retarget, and the devnet of 3 October 2026 showed DAA time running 2.9x the wall clock for 17 minutes after a hashrate step | `finality_v2.py` with Kaspa's sampled DAA and the controller chosen at gate 2 (section 2.3) in the loop, a 50x renter pulsing two minutes in every hour, under both forms of W2 and Q1 (DAA-score blocks as simulated; median-time buckets as specified in section 3.1 and 3.3), reporting the day the renter crosses a third and the chain's block rate meanwhile; logged in `docs/bench-log.md`; confirms or reverts the median-time form | 3 |
| O-3.15 | Vote keys with history can be bought, borrowed or stolen; every scenario in `sim/results_v2.md` models a renter who must mine (ledger F19, external review 3 October 2026) | `finality_v2.py` scenario: k% of weight changes hands at day 0 against the same k% arriving as fresh hashrate, for k in 20, 34 and 40, plus a 40/40/20 partition row under the active-set rules and the floor; report time to a conflicting lock; decide whether W5 makes the successor re-earn and whether weight decays when a key's block profile breaks | 3 |
| O-3.16 | What holds during a finality pause: the seed pipeline from uncertified checkpoint blocks (O-4.3, section 4.3), the survival of pre-pause locks (3.5) and `finality_active` false (3.9) are three texts and no statement (ledger F20) | Decide O-4.3 (this specification recommends uncertified-allowed); write the four pause guarantees into 3.7; devnet with a 45% silent set through 3 epoch boundaries: program advances on schedule, no seed fork, pre-pause locks survive the heal | 3 |
## 6.4 Section 4, seeds and the VDF
@ -90,14 +92,31 @@ An item closes when its measurement is in `docs/bench-log.md` or its decision is
| O-5.6 | External job bond size and claim timeout (ledger P9); shards carry no bond since the sortition rule of section 7.2 | Set on the phase 4 devnet | 4 |
| O-5.7 | The provers' proportion of the 80% tip share (section 5.2) | Defined by the chunked proving protocol | phase 2 |
| O-5.8 | Developer registration format at deployment and the re-registration transaction (section 5.2) | Execution-layer specification | decision, execution engineer |
| O-5.9 | Mining against proving under shocks: external proving pays 10x, the IGN price falls, a large operator leaves, assignments go unfulfilled, clients maximise profit (ledger E12); design R8 covers the fee switch only and has not run | R8 simulation extended with the five shocks, then the phase 4 devnet with profit-only prover clients: backlog depth, time to clear, `f_p` and `B_p` paths, income per card | 4 |
| O-5.10 | No single figure shows every payment route (emission, base fee, priority fee, external jobs at launch and after the bridge, the client dev fee) with currency, recipient, fee and burn (ledger E13) | Draw it, one route per row, in the litepaper Economics section and the customer brief; operator revenue never summed with protocol revenue | decision, execution engineer; before public repo |
| O-5.11 | Security budget through halvings with low fees and no external demand at a flat IGN price (ledger E15) | Model of emission per 2.5 through year 12 against a fee grid and an income-per-card hashrate response; payments to miners and provers reported apart from the burn; the failing year and price stated in the litepaper | before mainnet, simulation |
## 6.6 Sections 7 and 8, execution and client security
Section 7 carries no open item of its own: its measurements are O-5.1 (shard sortition parameters) and O-5.2 (the IGN settlement switch), listed above. Section 8 has one.
Section 7 carried no open item of its own at 0.1: its measurements are O-5.1 (shard sortition parameters) and O-5.2 (the IGN settlement switch), listed above. Two were added on 3 October 2026 (night) from the external review, and section 8 gained two beside its one.
| Id | Item | What closes it | Gate |
|---|---|---|---|
| O-8.1 | The release key policy (section 8.2): who the steward is, the hardware, how a signature is produced, rotation and revocation; and the per-platform reproducible-build toolchain of section 8.1 | Publish the policy and the toolchain before the public testnet; a third party reproduces one release from it | decision, the project lead (key custody); before public testnet |
| O-7.1 | The phase 2 gate could be passed by shrinking the shard (design R2's fallback); no end-to-end standard existed (ledger P16) | The benchmark standard: fixed published workload, job received to proof accepted (queueing, transfers, proving, aggregation, verification, payment), median and slowest 5% and 1%, failure and retry rates, full cost, per advertised card with mining and proving compatibility stated separately, no growing backlog, reproduced by three unrelated operators from published code and configuration; `site/journey.json` phase 2 carries it in one sentence | phase 2 |
| O-7.2 | Interfaces show three states (executed, proven, locked); included is a list, not a state (ledger P17; `docs/design/execution-layer.md` 2.4 now states the four-state rule) | Wallet and RPC conformance set on the devnet: one transaction through each of included, executed, proven, finalised and the three failure paths (skipped, reorged out, finality paused); the phone app and the explorer show the same word as the RPC | 2, with phase 2 |
| O-8.2 | The official client and the phone monitor show earnings without netting power, and do not separate mining from proving income, list failed jobs or show the pending release (ledger X17) | Display rules in the client and in phone-app 4.1: net after an entered tariff, incomes separate per card and day, failed and retried jobs with reasons, running release and hash with the pending one; measured against the pool protocol's `stats` on the phase 4 devnet | 4 |
| O-8.3 | Proving jobs run strangers' guest programs on the machine that holds the wallet, seed and vote key; no isolation design exists (ledger X17) | Design: prover process under a separate OS user or sandbox, holds no key, signs payout claims through a local socket only; reviewed before the first external job; escape test with a hostile guest program on the phase 4 devnet | 4 |
## 6.8 Gate 4 and the public product (no spec section)
Added 3 October 2026 (night) from the external review. These items belong to no section of the specification; their letter follows the ledger's launch section.
| Id | Item | What closes it | Gate |
|---|---|---|---|
| O-X.1 | "Independent" for the 1,000-miner gate is undefined (ledger X5) and concentration in hashing, checkpoint signing, proving and aggregation is unreported (ledger X14) | Define independence (distinct ASNs, benchmark hardware fingerprints, pool attestations); compute the four concentrations as top-1, top-3 and top-10 shares over 30 days from chain data; publish on the live page beside the gate | 4 |
| O-X.2 | "The chain runs without its founders" is untested (ledger X15) | On the public testnet, stop every project-run node, miner, prover, aggregator, seed node, observer and the site for 24 h at a published time; record blocks per second, proof lag, certificates per hour, and a fresh node's sync from the client's seed list | 4, before mainnet |
| O-X.3 | No evidence page; the bench-log does not say who ran a test or whether anyone outside has (ledger X16) | One row per public claim: status, version, test, result, and one of implemented / tested by the team / reproduced externally / reviewed independently; audits tied to versions; published with the benchmark | phase 2, standing |
## 6.7 Count
@ -105,11 +124,14 @@ Section 7 carries no open item of its own: its measurements are O-5.1 (shard sor
|---|---|
| 1 | 20 |
| 2 | 9 (O-2.8 closed 3 October 2026 by section 7.1) |
| 3 | 14 (O-3.3 and O-3.7 narrowed to parameters and confirmation on 3 October 2026; O-3.14 added the same evening, round 3) |
| 3 | 16 (O-3.3 and O-3.7 narrowed to parameters and confirmation on 3 October 2026; O-3.14 added the same evening, round 3; O-3.15 and O-3.16 added the same night, external review) |
| 4 | 9 |
| 5 | 8 (O-5.1, O-5.2 and O-5.6 narrowed on 3 October 2026) |
| 7 | 0 |
| 8 | 1 |
| Total | 61 |
| 5 | 11 (O-5.1, O-5.2 and O-5.6 narrowed on 3 October 2026; O-5.9 to O-5.11 added the same night, external review) |
| 7 | 2 (added 3 October 2026, night) |
| 8 | 3 (O-8.2 and O-8.3 added the same night) |
| X (6.8) | 3 |
| Total | 73 |
By gate (an item shared between two gates is counted at the earlier one): 16 belong to gate 1, 11 to gate 2, 22 to gate 3, 4 to gate 4, 3 to phase 2, 3 are decisions with a named owner outside a gate (O-5.2, O-5.8, O-8.1), 1 (O-2.10) waits on a later block-rate step, and 1 (O-1.20) is a note with no consensus consequence.
Added 3 October 2026 (night, external review): 12 items. 2 at gate 3, 1 at gate 2, 5 at gate 4, 2 at phase 2, 1 decision (O-5.10), 1 before mainnet (O-5.11).

2
site/journey.json
View file

@ -15,7 +15,7 @@
"when": "Nov 2026 to Jan 2027",
"status": "active",
"line": "Mining program proven on Apple, NVIDIA and AMD; shard proving benchmark on consumer cards still to run",
"gate": "A mid-range GPU proves a shard in under 20 s and a CPU verifies a hash in 10 ms"
"gate": "A fixed published workload, job received to accepted proof on a declared consumer card, sustained with no growing backlog, reproduced by three independent operators"
},
{
"id": "phase-3",