20 KiB
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.
12. M8, M11, P16: hardware the measurements need
Question: whether to buy or borrow a discrete AMD card (M8: bit-exactness and the honest rate on RDNA, the one vendor not yet run), a multi-card mixed-generation rig with ROCm (M11: hourly runtime codegen on the rig a farm runs), and a 12 GB mid-range NVIDIA card (P16: the phase 2 proving gate end to end on the card the gate names). Facts: every other vendor and machine class has run (Apple, NVIDIA discrete, AMD integrated, Intel integrated); the ledger's answers on these three items are honest about the gap and nothing an agent can run on this fleet closes them; the public benchmark in January 2027 will also need them for the leaderboard. Recommendation: one discrete AMD card (a 16 GB RDNA 3 or 4 part, approximate class) and one 12 GB NVIDIA card (a 3060-class part) bought for PC 2 before the public benchmark; the multi-card rig borrowed from a farm operator for a week at the HiveOS package's first test rather than bought. Unblocks: M8 and P16 move to "measurement scheduled "; M11 moves to "rig borrowed ".
13. F3, F17, X5: the three gate-3 parameters proposed in spec 3.4.2 (round 2)
Question: adopt, at gate 3, the three values the ledger-tails round wrote into docs/spec/03-finality.md section 3.4.2 as Proposed. Facts, from the fork's encodings and the live devnet's coinbase sizes (3.4.2 item 1): a vote item is 281 bytes, so a checkpoint's 8,192 votes at the S2 switch are 2.3 MB, 4.6x one block's compute mass, and no per-block bound lets one block carry a checkpoint; spread over the 30 blocks of a checkpoint interval the average is 274 votes per block (15.4% of the mass). The bitmap indexes the canonical voter list at one bit per key: 1,024 bytes at 8,192 voters against a 1 MiB wire bound today. The client defaults to 8 identities per large card, 2 per small, 1 on Apple silicon and integrated GPUs, which is why tonight's fleet runs 4.2 vote keys per machine. The hostile-aggregator simulation (scenario O, 3 seeds) shows the attack works under the certificate reading the simulation used until tonight and does nothing under the block reading spec 3.3 Q2 fixes. Recommendation: (a) the per-block vote bound at the value item 2 proposes, sized so a checkpoint's votes fit in its interval with headroom; (b) the bitmap wire bound at 8,192 bytes (65,536 voters, 8x the switch) in place of 1 MiB; (c) the client default of one vote key per machine (not per card or per identity), with the identity count kept as a worker setting that shares the key. Unblocks: O-3.3, O-3.5 and O-3.12 move from Proposed to Decided; the F17 and X5 Sybil arithmetic then rests on a default that matches the rule.
Outcomes (6 October 2026, 17:25 UTC, the project lead's decisions, relayed by the coordinator)
| Item | Decision | Ledger lines written |
|---|---|---|
| 1 (M1, M22) | CORRECTED at 17:35 UTC: NO device bounty (the 17:25 tiers of USD 250,000 and USD 100,000 are withdrawn: a team with a real 2x chip earns more mining than any bounty, so those tiers attract nobody). The claim "under 2x" is backed by the paid independent cryptanalysis (the Monero route: four paid reviews, no bounty) and the public benchmark with M22's metrics. Optional, the project lead's call later: a single cryptanalysis prize of USD 50,000 for a published 2x+ shortcut in the mixer, the chained cache or the acceptance rule, escrowed before it is named. Every public mention of a bounty is struck from the litepaper, the evidence page, spec 06 O-1.17 and the funding plan (this commit); the Counter ASIC 2.0 document's USD 20,000-a-day issuance trigger on the ca2-coord branch now points at the paid cryptanalysis and the benchmark's next round (applied there in commits 6141e01 and 8c5b02f, 6 October 2026, with every other bounty sentence on that branch struck) |
M1, M22 |
| 2 (F16) | YES, option B | F16 |
| 3 (X5, X14) | YES as written, with the silent-fleet addition | X5, X14 |
| 4 (E14) | YES: internal table, one public unfunded-lines sentence | E14 |
| 5 (X13) | YES: the pilot stays in phase 5 | X13 |
| 6 (L1, L2, L4, L5) | IN PROGRESS: counsel engaged | L1, L2, L4, L5 |
| 7 (L3) | YES | L3 |
| 8 (G14) | YES: the morning after the last branch merges | G14 |
| 9 (X29) | YES at the next planned node 1 restart: localhost bind, the wallet's node too | X29 |
| 10 (P9) | YES | P9 |
| 11 (P21) | YES: v0 through the public testnet | P21 |
| 12 (M8, M11, P16) | DONE 6 October 2026: a 9070 XT and a 4070 on order; the mixed rig borrowed later | M8, M11, P16 |
| 13 (F3, F17, X5 spec 3.4.2) | YES | F3, F17 |
Public text that follows from these and is not yet written (next round): the unfunded-lines sentence in the litepaper Economics (item 4); spec 3.4.2 moved from Proposed to Decided and spec 3.5 replaced by 3.11.4's text after c4-fix merges (items 2 and 13).
Standing decisions (6 October 2026, 22:3x UK, the project lead, at the Horizon close)
Recorded by the Horizon closer (branch horizon-close) from the project lead's three lines of 22:3x UK, verbatim first, meaning after. The one page is docs/analysis/horizon-2026-10.md section 1; the measurements are lane 4 (docs/analysis/horizon/economy-and-utility.md) and lane 6 (docs/analysis/horizon/polish.md).
| Line, verbatim | Standing decision |
|---|---|
| "Fees cannot fund security for a decade" | Fee revenue is never assumed as the security budget in any model or public sentence. Lane 4 measures fees at USD 450 a day at launch and USD 4,200 a day in year 5 against USD 54,800 and 13,700 of daily emission, so fees stay small for a decade or more. Self-sustaining means the emission curve keeps mining worth doing on its own for as long as fees are small; emission never decays on a schedule that assumes fees take over. the project lead rejected "first decade" as a bound: there is no end date on emission carrying security. |
| "Miners need to be the security" | Miners are the security always: no time bound, no stake, no outside checkpoints, no committee, no external security of any kind in the design (the 3 October rulings against stake and Bitcoin anchoring stand). The chain pays its own miners from emission plus fees; nobody pays upkeep, not the founder, not a treasury, not a dev fund. |
| "Wrong constants and claims in our own text" | the project lead's acknowledgement of lane 6's finding (polish.md: the public text carried constants and claims that did not match the spec or the measurements). The fix is the nine ledger rows M32, M33, F26, E19, E20, G15, P24, E21, P25, each Conceded and stated on master on 6 October 2026, plus X31 to X33 (the testnet date, the roadmap months, the benchmark month). |
Still owed from the project lead after the close: the cryptanalysis spend (funding.md: two independent reviews, USD 80,000 to 160,000, before the testnet genesis); the testnet date word (the site says "weeks away"); the N ladder at genesis (the era-draw ladder of the algorithm lane, each step by 90 percent signal); the activation of the verification switch proving_consensus_verify_daa (off by default in 0.3.16).
Decisions (6 October 2026, 23:2x UK), the project lead's answers to the seven questions
| # | Question | the project lead's word | Meaning |
|---|---|---|---|
| 1 | Emission shape | "As i said, find a solution" | The tail is the baseline; the economy lane models the revolutionary candidates (thermostat, settled-value targeting, the hybrid) and the supply, coins-per-block and halving comparison against Kaspa and the field; nothing that penalises a holder; the recommended shape ships as genesis parameters with code. |
| 2 | Latency-shadow ladder | Explanation requested | Answer pending; the six-step ladder, every step by 90 percent signal, never unconditional, verifier-bounded at 10 ms, is being implemented behind its switch meanwhile. |
| 3 | Proof verification in consensus | On | proving_consensus_verify_daa = 0 in the testnet genesis. Devnet stays off. |
| 4 | Finality leave item | On | finality_leave_activation_daa = 0 in the testnet genesis. Devnet stays never until the 95 percent signal. |
| 5 | Base unit | 18 | 18 decimals on the testnet (O-2.6 Decided, pending the implementation lane's gate); the devnet keeps 8. |
| 6 | Cryptanalysis spend | Yes | An outside team attacks the hash class after class v4 has run a week of real hash; bounded (lane 2's USD 80,000 to 160,000); the procurement plan is owed. |
| 7 | Testnet date | Leave open | No month anywhere; the go checklist is the date. |
Standing rulings of the same hour: "We dont want to penalise holders" (dormant-coin rent and anything that takes from a balance or taxes inactivity is refused for ever); vote-or-burn is implemented only if 95 percent or more of the mining community would respect it (the weigh-up lane decides between the burn and the signing bonus).