3.8 KiB
3.8 KiB
Consequence decisions for the project lead (night of 5 October 2026)
Sibling of ledger-decisions.md. Each is a consequence of a measured number that needs the project lead: money, a public claim, or a consensus parameter outside tonight's delegation. The row number points at consequences-2026-10-05.md. Recommendation first, then the options.
| # | Row | What needs deciding | Recommendation | Why |
|---|---|---|---|---|
| D1 | C1 | The fee switch lands at H = 210,000 about 19:50Z on 6 October, and the 0.3.10 node's export does not carry the switch, so every app prover's shards are refused or vetoed from H. Move H, or race 0.3.11 onto every prover first | If 0.3.11 (with the proving-v1 fork, whose export carries daaScore and feesV1ActivationDaa) is not on every prover by 16:00Z on 6 October, republish the override with H = tip + 86,400 rounded to the next thousand, re-read the digest on a scratch node, every node in one sweep (the fee-switch plan's own rule for a later H). The coordinator holds the devnet delegation; this note is so the morning does not find proving dark |
A dark proving pool on the devnet costs nothing on chain (the escrow keeps it) but every coverage, latency and fleet number measured after H is void |
| D2 | C3 | The litepaper says "12 GB or more proves full shards"; the only measurement puts the prover alone at 13.8 GB on a 32 GB card | Keep the sentence only if the sweep lands a full v1 shard under 11.5 GB with the SP1 knobs; otherwise change to "24 GB proves and mines on one card; 12 and 16 GB cards prove with the miner paused" until the RTX 3060 on order measures it | A public number that the first 3060 owner disproves is the FUD the ledger exists to prevent |
| D3 | C8, C13 | The homepage says "Any 4 GB card" and the litepaper says a 4 GB card mines for about four years and an 8 GB card for more than a decade; the tile says "4B hard cap" while the rule mints about 3.96 billion | Replace with the lifetime table's numbers once the sub-agent lands it: "4 GB cards mine at launch; 8 GB for about six years; 12 GB for about fourteen; the dataset grows half a gigabyte a year" and "cap 4 billion, about 3.96 billion ever minted" | The schedule is public and the arithmetic is one line; a reader will do it |
| D4 | C9 | Index mapping at gate 1: (a) multiply-shift fades every card one year at a time; (b) power-of-two steps end 8 GB and 12 GB cards together at the 8 GiB step (about year 12) | (a), with the new 1 GiB vectors cut now while the vectors are private | A cliff that retires two tiers on one day is a miner-relations event; a fade is a schedule |
| D5 | C10 | The site's "under 2x" chip claim: the scratch layer leaves the on-die-cache recompute chip at 2.4x at every share; the mixer multiplier x2 brings it to 1.2x at twice the CPU verify cost (about 0.9 ms per warp, half the pool members per core) | Carry the mixer x2 into class v3 on the devnet tonight (the coordinator's gates apply, the verify time per warp measured) and keep the claim; if the coordinator judges it outside the delegation, qualify the claim in level 3 until the project lead says | The claim is the project's first public sentence on chips; it is either true by a measured lever or it is marked |
| D6 | C11 | Whether class v3 should favour AMD (fewer, wider loads per hash) at a cost to the 5090's latency-bound share, or accept that AMD cards mine at about a seventh of a 5090 and 4.5x the electricity per hash | Accept it for v3 and say so on the miners page ("NVIDIA first; AMD mines at a lower rate per watt on this class"); open the AMD question as a Counter ASIC 3.0 item with its own measurement | Tonight's rule was the project lead's and the 5090 margin is the anti-chip argument; AMD's position is a public-copy question, not a gate |
| D7 | C13 | Same as D3's supply wording | with D3 |