From 68dd4c47de0aa7f90e7653ea16a8bbf486b27f70 Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Mon, 5 Oct 2026 18:27:37 +0000 Subject: [PATCH] Ledger decisions for the project lead: eleven decision requests with recommendations (docs/plans/ledger-decisions.md); the ledger entries M1, M22, F16, X5, E14, X13, L1, L3, L4, L5, P9, P21 point at them Co-Authored-By: Claude Fable 5.1 --- docs/fud-ledger.md | 12 +++++++++ docs/plans/ledger-decisions.md | 49 ++++++++++++++++++++++++++++++++++ 2 files changed, 61 insertions(+) create mode 100644 docs/plans/ledger-decisions.md diff --git a/docs/fud-ledger.md b/docs/fud-ledger.md index bb157ed31..c2a833192 100644 --- a/docs/fud-ledger.md +++ b/docs/fud-ledger.md @@ -30,6 +30,7 @@ Evidence locations referenced below: `docs/bench-log.md`, `proto-metal/TESTS.md` "Eleven integer ops, 64 instructions, 8 iterations, a splitmix register init. That is not RandomX. RandomX leans on a superscalar out-of-order CPU with floating point and branches. Yours is a sea of 32-bit ALUs and a memory bus. A chip for that is a weekend." Status: Open, program space counted, the claim stands as a target (5 October 2026, evening sweep). Was: Open, experiment scheduled. Sweep (5 October 2026): nothing runnable; the bounty, the public benchmark and a chip design are M22's decisions and hardware. The nearest number stays M16's arithmetic. +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 1 (5 October 2026, night). Sweep (5 October 2026, evening): the program space, swept as arithmetic from the version 2 generator (`igneum-pow/src/generator.rs`: 16 load slots as a uniform 16-subset of instructions 1 to 63, then nine draws per instruction, 592 draws per program; 10 non-load operations with weights 12/10/8/8/8/7/6/6/6/4; 8 registers; a 31-way rotation, a 32-way bit and a 5-way mask per instruction; two 32-bit immediates). Counting choices: the slot subset is 48.4 bits; the operation draw carries 3.26 bits of entropy (of log2 10 = 3.32); operations and registers alone give about 770 bits per program; with the rotation, bit and mask fields about 1,550 bits; with the immediates about 5,650 bits, all capped by the 256-bit seed, so the space a chip has to serve is 2^256 distinct programs drawn from a structure of about 2^1550 shapes, and the critic is right that it is a small instruction set: 12 operations, 8 registers, no floating point, no branches, by design (vendor-identical rounding). What the sweep adds to the ledger's answer is the number that matters for a fixed-function design, the spread a chip must absorb: under generator version 2 every accepted program does 120 to 128 distinct loads per hash (median 128.00, 20,000-program census), so the per-program hash-rate spread on a memory-bound device is the 1.10x residual the census measured, not the 2.7x of version 1; the chip's advantage therefore cannot come from the program (it is one fixed memory-bound shape) and must come from the memory system or from the recompute route, which is M16's cost model (`docs/analysis/m16-recompute-attacker-2026-10-05.md`: 1.5x to 2.4x at equal integer budget before any fixed-function factor, 3x to 6x with one, and the mixer-cost lever that cuts it below 1x). The experiment that closes M1 is unchanged: the bounty and the public benchmark (M22, decision owner the project lead). @@ -376,6 +377,7 @@ Evidence: design doc "Proving speed on consumer GPUs" risk item and Finality v2 "Claim a shard with a small bond and never prove it. Repeat. Finality waits on you." Status: Answered by design, parameter table written from the live numbers (5 October 2026, evening sweep). Was: Answered by design, parameters open. Sweep (5 October 2026): the parameters (O-5.6) are phase 4 devnet work; the economy simulator's lever study found the claim timeout a market parameter and recommends starting the devnet at 120 s (`docs/analysis/economy-2026-10-04.md` section 6). +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 10 (5 October 2026, night). Sweep (5 October 2026, evening): shards carry no bond (spec 7.2, P13), so shard griefing is a prover sitting on an exclusive window; the only bond is the external job's. The table, from the live devnet at 16:00 UTC (`igneum_getProvingStatus` on the Mac node: 352 shards paid, pool 19 entries, 0 failed, 0 pending, 154 verified; the task's figure of 215 paid was the morning's) and the measured shard times: @@ -711,6 +713,7 @@ Evidence: CLAUDE.md rules (privacy rejected). Fix: overclaims list, item 68. "A founder's company earns a dev fee, runs a pool and a proving business, seeds the DEX, pays 'launch grants', and the roadmap ends in 'exchange listings after'. Expectation of profit from the efforts of others, in writing." Status: Open, counsel not yet engaged. Sweep (5 October 2026): counsel; nothing runnable. +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 6 (5 October 2026, night). Decision owner (5 October 2026, evening sweep): the project lead, with counsel; nothing runnable here. Answer: There is no sale, no premine, no allocation and no promise of return, and nothing in consensus is controlled by the team and no protocol fee reaches it (the development fund was removed on 3 October 2026), which is the structure that regulators have treated most favourably (approximate: compare the SEC's own framework on sufficiently decentralised networks and MiCA's exemption for tokens created automatically as a reward for maintaining a distributed ledger, approximate quotation). The weak points a lawyer will circle are the ones quoted: founder-run pool and proving business, founder-seeded DEX, launch grants, and the phrase "exchange listings after". None is in consensus; all are promotional. The litepaper must drop the listing sentence and counsel must review the founder-business paragraph before v0.2. The legal entity is "offshore, parked" in the design doc, which is not an answer. @@ -731,6 +734,7 @@ Evidence: none. Fix: overclaims list, item 77. "Fifteen domains at a US registrar on US nameservers behind a US host. One court order and igneum.network is a parking page." Status: Conceded, mitigation scheduled. Sweep (5 October 2026): a deSEC token now sits in `~/.config/igneum` (mode 600), so the nameserver move of fud-fixes row 44 has started; the registrar move waits for December. +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 7 (5 October 2026, night). Decision owner (5 October 2026, evening sweep): the project lead, with counsel; nothing runnable here. Answer: True. GoDaddy and Vercel are both US companies and have both complied with takedowns. Mitigations: an ENS or equivalent name and an IPFS mirror of the site and litepaper, the site's content hash published in the repository and in the genesis block, at least one non-US registrar for a second TLD, and the chain itself never depending on any domain (seed nodes are addresses in the client, not DNS only). Phase 5. @@ -741,6 +745,7 @@ Evidence: CLAUDE.md "Domains". Mitigation: not yet. "'Testnet miners are paid real money for real proofs from phase five.' That is a business paying contractors in crypto across borders with no entity." Status: Open. Sweep (5 October 2026): counsel and entity; nothing runnable. +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 6 (5 October 2026, night). Decision owner (5 October 2026, evening sweep): the project lead, with counsel; nothing runnable here. Answer: Correct that it needs an entity, terms and tax treatment before it happens. The payments come from the customer rollup on its own chain, not from Igneum, but the arrangement is organised by the project. Counsel before phase 5. @@ -751,6 +756,7 @@ Evidence: design doc "The first six months". "Igneum. Have you checked EUIPO, USPTO and the UK IPO? There is no evidence you did." Status: Open. Sweep (5 October 2026): a person's search, recorded outside the repository; nothing runnable. +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 6 (5 October 2026, night). Decision owner (5 October 2026, evening sweep): the project lead, with counsel; nothing runnable here. Answer: No clearance search is recorded in the repository. One is required before the name is used commercially, in all three registers and in Nice classes 9, 36 and 42, approximate. Until then the name is provisional and the litepaper should not claim otherwise. @@ -816,6 +822,7 @@ Evidence: litepaper "Roadmap"; design doc "Team". "Your testnet gate is 1,000 independent miners for 30 days. One person with a script is 1,000 miners." Status: Conceded, measurement defined from the vote-key window and today's numbers (5 October 2026, evening sweep); decision owner the project lead (O-X.1). Was: Conceded, measurement to define. +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 3 (5 October 2026, night). Sweep (5 October 2026, evening): the definition, measurable from chain data plus two attestations, and today's reading. Unit: a vote key with at least the dust count of blue blocks in the 30-day weight window (W3), which is the smallest thing the chain can count. Independence: two keys are independent when they differ in all three of (a) the autonomous system of the address their blocks' nodes announce (seed and peer tables, the observer's address field), (b) the machine fingerprint the miner app sends with its log uploads (`machine_id`, already in every STATUS line's run id), and (c) the pool attestation, a signed statement by a pool operator listing the keys it runs (absent for solo keys). N_ind = the number of distinct (ASN, fingerprint, pool) classes among eligible keys; the gate of `site/journey.json` phase 5 reads "N_ind >= 1,000 over the same 30 days with top-10 share of window weight under 50%". Today's reading from the live window (Mac node, `getFinalityWeights` at DAA 112,395): 22 keys, 21 voters above dust (dust 5 on the devnet), total weight 7,196 of 7,200 blue blocks; top-1 share 8.3%, top-3 20.3%, top-5 31.9%, top-10 60.3%; the console counts 5 machines and 21 identities in 10 minutes, so the fleet runs 4.2 keys per machine (the launcher's one key per worker, F17's client default) and N_ind by fingerprint alone is 5, by ASN at most 3 (two home networks and one US household, approximate). That is the Sybil ratio the critic means, measured: 21 "miners" are 5 machines. The hashing concentration of X14 (top-1 12.8%, top-3 34.5% over 8,090 blocks on 4 October) and tonight's weight shares agree within the window's drift. What the observer must add (O-X.1): the ASN per announcing address, the fingerprint per key (the app already has both), and the pool statement format. @@ -1242,6 +1249,7 @@ Evidence: the files above. Review id R3.2. "Section 3.5: two certificates at one index, strike the equivocators, re-evaluate, and if neither or both still lock the index is uncertified. So the lock my node reported and I credited on is revocable." Status: Open, the two options priced, one recommended (5 October 2026, evening sweep); decision owner the project lead (gate 3, O-3.17). Was: Open, decision at gate 3 (extends O-3.6). Sweep (5 October 2026): a decision item (O-3.17); nothing runnable. +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 2 (5 October 2026, night). Sweep (5 October 2026, evening): the two options, with their measured cost. @@ -1417,6 +1425,7 @@ Added by `docs/review/external-2026-10-03.md`, which holds the reviewer's text v "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). Sweep (5 October 2026): nothing runnable; the terms, judge and funding are the project lead's decision. +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 1 (5 October 2026, night). 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. @@ -1491,6 +1500,7 @@ Evidence: spec 2.5, 5.1 to 5.4; `docs/commercial/prover-customer-brief.md`; P10, "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, with a placeholder table: `docs/plans/funding.md` (3 October 2026, marked PLACEHOLDER on 4 October) lists the sources (the founder's own means today, the 1% client fee, the team's own mining and proving, no protocol fee) and the cost lines; the project lead parked funding on 4 October 2026 and the decision stays his. Was: Open, decision for the project lead. +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 4 (5 October 2026, night). 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. @@ -1518,6 +1528,7 @@ Evidence: X1; `docs/fud-fixes.md` section 5. Decision: the project lead. Review: "'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. Sweep (5 October 2026): a decision and a customer; nothing runnable. +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 5 (5 October 2026, night). 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. @@ -1605,6 +1616,7 @@ Evidence: `docs/bench-log.md`, 4 October 2026 "difficulty rule: timestamp attack "Your proof records pay provers, and the node pays a record whose statement matches its own execution whether or not the SP1 proof behind it verifies. A prover can sign the native statement without proving anything." Status: Open, stated in spec 7.7 item 4 (4 October 2026). Branch `proving` of the fork, `igneum/exec/src/proving.rs`. Sweep (5 October 2026): stated; the in-consensus verifier is a build item (execution engineer). +Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 11 (5 October 2026, night). Answer: Correct for v0, and by design for now. The consensus check on a carried record is the native-execution veto (spec 7.2 item 5): the statement must equal the node's own 328-byte shard statement for that shard and payout address, so no record can move state or pay for a wrong claim. The SP1 proof is verified off the consensus path by the proof pool's verifier (`igneum-prove-host --mode verify`), and a producer offers only verified records to its templates; a producer that includes unverified records (trust mode, test networks only) can pay a prover who did not prove. The damage is bounded to that prover's payout. What closes it: the aggregated segment record of design 5.4 verified in consensus, which needs the SP1 verifier inside the node (the SDK dependency the node does not carry today) or a bounded in-consensus verification budget. Until then the devnet runs v0 with every producer verifying. diff --git a/docs/plans/ledger-decisions.md b/docs/plans/ledger-decisions.md new file mode 100644 index 000000000..b46cbe6c7 --- /dev/null +++ b/docs/plans/ledger-decisions.md @@ -0,0 +1,49 @@ +# FUD ledger: decisions for the project lead + +Written 5 October 2026, night, by the ledger closer (branch `fud-close`). One paragraph per ledger item that cannot close without the project lead: the question, the facts the ledger already holds, the recommendation, and what the decision unblocks. The ledger entry for each says "Decision owner: the project lead" and points here. Nothing here is decided until the project lead says so; when he does, the ledger entry gets the dated "Decided" line and this file keeps the paragraph with the outcome appended. + +Items owned by other agents tonight (C4, M20, F21 and F22 with the N3 switch, the transaction relay, GPU hot-plug) are not here. + +## 1. M1 and M22: the ASIC challenge, its terms, judge and funding + +Question: what the standing bounty scores, who judges it, what it pays and who pays. Facts: M1's "under 2x" is a hash-rate target with no scoring rule; M22 lists the metrics the benchmark should publish (hashes per second and per joule per program over at least 100 epochs, reported as worst decile and median, never 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; recomputation, partial storage and weak-program selection scored separately); M16 prices the recompute attacker at 1.5x to 2.4x at equal integer budget and 3x to 6x with a fixed-function factor, with the mixer-cost lever that brings it under 1x at zero honest cost. Recommendation: publish the scoring rules with the January 2027 benchmark exactly as M22 lists them; the payer is the entity (Igneum Labs LTD), never a person; the judge is a named external reviewer paid from the review line of the funding table (item 4 below), not the team; the reward is a fixed sum in fiat announced with the rules; eligible hardware is any design with a public bill of materials and a reproducible simulation or a working part; the public claim until a design has been scored is the one M22 words ("consumer GPUs remain competitive against the best independently proposed specialised design across the tested workloads and the stated economic assumptions"). Unblocks: the M1 status moves from "Open, target" to "Open, bounty terms published, unclaimed since ", and the litepaper's bounty sentence gets a date. + +## 2. F16: a lock that can become uncertified after a heal (gate 3, O-3.17) + +Question: option A (spec 3.5 as first proposed: strike the equivocators, re-evaluate, uncertify the index if neither or both lock) or option B (spec 3.11.4: a verified certificate is never withdrawn, the node reports the conflict, finality pauses until an operator resolves it with a trusted certificate). Facts: the ledger's F16 table prices both; the state needs a 34% equivocator or a partition longer than a window; under option A every lock in that state (2 to 69 indices in the simulations, 23 on the cloud devnet) was reported locked and then withdrawn, which makes a lock a confirmation count; under option B no reported lock is ever withdrawn and the price is an operator-length pause. Note: the `c4-fix` branch (another agent, tonight) rewrites spec 3.5 with the certificate-driven reorg rule for C4; that rule is about following a certificate over a block off the node's chain and does not decide F16, but the two paragraphs sit in the same section, so the F16 text should be written after `c4-fix` merges. Recommendation: option B, as the ledger already recommends; it is Kaspa's rule for a finality conflict and the only reading under which an exchange can credit on a lock. What it needs after the decision: the 3.5 paragraph replaced by 3.11.4's text, `finality_conflict` and the `finality_active` clear in the node, the forced double-certificate test of 3.11.7. Unblocks: F16 moves to "Decided, fix scheduled"; the node work is one consensus-engineer item. + +## 3. X5 and X14: what "independent" means for the 1,000-miner gate (O-X.1) + +Question: adopt the definition the evening sweep wrote. Facts: the unit is a vote key above the dust count in the 30-day window; two keys are independent when they differ in all three of the autonomous system of the announcing address, the machine fingerprint the miner app sends with its log uploads, and the pool attestation; N_ind is the number of distinct classes; the gate reads "N_ind >= 1,000 over 30 days with top-10 share of window weight under 50%". Tonight's reading: 21 keys above dust are 5 machines (4.2 keys per machine) and at most 3 autonomous systems. Recommendation: adopt it as written, with one addition: a key whose machine fingerprint is absent (a miner that sends no logs) counts as its own class only if its address is in an autonomous system no other key uses, so a silent fleet cannot inflate the count. What it needs: the observer stores the autonomous system per announcing address and the fingerprint per key, and a pool statement format (a signed list of keys per pool operator). Unblocks: X5 moves to "Decided, measurement scheduled", the observer columns become one app-owner item, and the phase 5 gate in `site/journey.json` gets the definition. + +## 4. E14: the funding table + +Question: whether `docs/plans/funding.md` leaves PLACEHOLDER status, and which lines are published. Facts: the fund was removed by design (E4); the sources are the founder's own means today, the 1% client fee, the team's own mining, proving and apps after mainnet, no protocol fee; the cost lines in the plan are approximate estimates (a contracted cryptographer USD 80,000 to 150,000, the finality review USD 50,000 to 100,000, the node audit USD 60,000 to 120,000, from memory, approximate). Recommendation: keep the table internal until counsel has read it (L1, L2), but publish one sentence in the litepaper now that names which lines are unfunded (the second client, the external reviewers, the bounty), because E14's critic is right that "no fund by design" without a table reads as no plan. Unblocks: E14 moves from "Open, placeholder" to "Decided: internal table, public unfunded-lines sentence", and G1, G5 and M22 can point at the funded line that pays them. + +## 5. X13: the first paying proving customer, timing and terms + +Question: whether the paid pilot moves from phase 5 to before the public testnet, as the external reviewer asked, and on what terms. Facts: the phase 4 gate is a signed letter of intent with no payment; the brief now carries the progression (agree workload, proof format, deadline, failure rate and price before the pilot; publish the outcome and the customer's own reason; repeat purchases without reimbursement; then several unrelated customers); payment before launch needs the entity, terms and tax treatment of L4. Recommendation: keep the phase 4 gate as the signature, put the paid pilot in phase 5 as written, and do not move it earlier until counsel has answered L4; a paid pilot before the entity's terms exist is the thing L4 warns against. Unblocks: X13 stays "Open, experiment scheduled (the pilot)" with a dated phase and no earlier promise in public text. + +## 6. L1, L2, L4, L5: counsel and the trademark search + +Question: engage counsel in the entity's jurisdiction (DIFC) for the Howey and promotions review of the founder-business paragraph and the launch grants (L1, L2), the testnet payment arrangement (L4), and record a trademark clearance search in classes 9, 36 and 42 at EUIPO, USPTO and the UK IPO (L5). Facts: nothing is runnable by an agent; the ledger's "offshore, parked" is now an entity with an address (Igneum Labs LTD, DIFC); the inducement wording is being removed from the litepaper tonight (L2 text half, group A); the trademark search of 3 October 2026 (recorded outside the repository) found IGNIUM UK00918212492 as the obstacle. Recommendation: one engagement letter covering all four, before litepaper v0.2 and before any public repository; the trademark result recorded in the repository as a dated one-line entry (found or clear per register) with the search itself kept outside. Unblocks: L1, L2, L4 move to "Open, counsel engaged "; L5 moves to "Searched : ". + +## 7. L3: the registrar move + +Question: the deSEC nameserver move has started (a token sits in `~/.config/igneum`, mode 600); the Vercel records must be recreated at deSEC and every domain re-verified in the Vercel project; the registrar move waits for the transfer lock to end in December 2026. Recommendation: do the nameserver move in one sitting with every domain's Vercel verification checked afterwards, because a half-moved zone takes the site down; the December registrar choice is the project lead's (a non-US registrar that accepts the entity). Unblocks: L3 moves to "Mitigated in part (nameservers, ); registrar December 2026". + +## 8. G14: the history rewrite date + +Question: when the rewrite of `docs/plans/history-rewrite.md` runs. Facts: 291 of 363 commits carry the +0100 offset, 40 carry the personal name, the intake key is in 6 tracked files across 8 commits and the dl token in 1; the dry run on a throwaway mirror is done; the rewrite breaks every open worktree and branch and so must run when no agent is mid-work. Recommendation: the morning after the last of tonight's branches merges, with every worktree removed first and both secrets rotated regardless; the rewrite is a precondition of the public repository (fud-fixes section 5), not of the testnet. Unblocks: G14 moves to "Scheduled ". + +## 9. X29: the live node's RPC on every interface + +Question: `igneumd` on this Mac listens on `*:26610` so that PC 2 can reach it. Facts: the file modes are fixed; the live node is read-only for agents tonight. Recommendation: `--rpclisten=127.0.0.1:26610` on the Mac node and PC 2 on its own node (it runs one for mining already) or an SSH tunnel; done by the operator at the next planned restart of node 1, never mid-run. Unblocks: X29 closes once the restart is logged. + +## 10. P9: the shard-market parameters (O-5.1, O-5.6) + +Question: the values of the 8 assignees, the exclusive window (10 DAA s today, 25 s proposed), the job claim timeout (120 s proposed by the economy simulator) and whether external jobs carry a bond. Facts: the parameter table is written from the live numbers (P9 sweep); the simulator found the claim timeout a market parameter and recommends starting the devnet at 120 s; shards carry no bond since the sortition rule. Recommendation: take the table as the phase 4 devnet's starting values (8 assignees, 25-s window, 120-s claim timeout, no shard bond, external job bond set on the devnet) and let the devnet measurement move them; nothing in public text names a value until then. Unblocks: P9's "parameter table written" becomes "values set for phase 4". + +## 11. P21: the SP1 verifier in consensus + +Question: whether the node carries the SP1 SDK (the verifier inside consensus) or a bounded in-consensus verification budget, or stays on v0 (every producer verifies off the consensus path) through the public testnet. Facts: on v0 the native-execution veto stops any wrong state; the damage of an unverified record is one prover's payout; the live devnet runs v0 with every producer verifying. Recommendation: stay on v0 through the public testnet and state it in the litepaper's proving section with the label Open, because carrying the SDK in the node is a dependency decision (size, build time on the PCs, the audit surface) that belongs to the execution engineer's plan and not to a night fix. Unblocks: P21 stays "Open, stated in spec 7.7 item 4" with the public testnet as the next date rather than no date.