diff --git a/docs/plans/igneum-2.0-plan.pdf b/docs/plans/igneum-2.0-plan.pdf new file mode 100644 index 000000000..1dc9cb4bb Binary files /dev/null and b/docs/plans/igneum-2.0-plan.pdf differ diff --git a/docs/plans/igneum-2.0-plan.txt b/docs/plans/igneum-2.0-plan.txt new file mode 100644 index 000000000..82c59da20 --- /dev/null +++ b/docs/plans/igneum-2.0-plan.txt @@ -0,0 +1,2292 @@ + STRATEGY EDITION + 08 OCTOBER 2026 + PLAN / 2.0 + + + + +THE GPU-FIRST EXECUTION PLAN + + + + +2.0 +A durable home +for GPU owners. +Competitive hardware. Verifiable computation. +Independent operators. + + + + +GPU EVM + ZKVM INDEPENDENT +COMPETITIVENESS ARCHITECTURE VERIFICATION + + + +The complete strategy, research programme and delivery gates. +Includes the full supplied leadership and architecture source. + STRATEGY / 2.0 + + + +DOCUMENT MAP + + + +The complete 2.0 plan. +Direction, hardware research, application architecture, security, economics and execution. The supplied +document is retained in full at the end. + + +DIRECTION APPLICATION AND OPERATORS + +The governing objective 3 Proofs and paid demand 17 + +The leadership case 4 Mining / proving coexistence 18 + +Evidence and status 5 + SECURITY AND INDEPENDENCE + +MINING FOUNDATION Finality and recovery 19 + +Hardware baseline 6 Wallets, receipts and state 20 + +Keep progress. Remove noise 7 Operational independence 21 + +Define competitiveness 8 + EXECUTION PROGRAMME + +The resource-coupling experiment 9 + Past and future reference points 22 + +Memory and shortcut attacks 10 + Delivery gates 1-3 23 + +Rotation without rescue 11 + Delivery gates 4-5 24 + +The programmable opponent 12 + Acceptance scorecard 25 + +Coexistence economics 13 + Risk and ownership 26 + +APPLICATION AND OPERATORS Leadership and claims 27 + +Ember and operator control 14 + SOURCE AND ARCHIVE + +EVM and zkVM architecture 15 + Completeness map 28 + +Consensus proof enforcement 16 + Source register 29 + + Research references 30 + + + FULL SOURCE APPENDIX + + A / Leadership assessment 31 + + B / EVM and proving strategy 34 + + + + +How to read this plan. Team-reported results and modelled estimates remain labelled. Proposed work is not marked complete. +Role labels are suggestions, not appointments. This is the 8 October 2026 source snapshot, not a fresh technical audit. + + + + +IGNEUM 2.0 / 08 OCT 2026 2 / 37 + STRATEGY / 2.0 + + + +01 / THE OBJECTIVE + + +Built to remain competitive. +The system we are trying to earn. Not a claim that the work is already complete. + + + THE GOVERNING STATEMENT + + + Someone can build one, but ordinary GPU owners remain + competitive, the supplier cannot obtain a lasting overwhelming + advantage, and the network does not depend on emergency + intervention to survive. + + +Igneum 2.0 is the consolidated plan for a GPU-secured network with Ethereum-compatible applications, +verifiable execution and a proving service that can serve customers beyond the chain. The success +condition is durable participation by ordinary operators, even when specialised hardware exists. + + W HAT YOU DELIVER W HY IT MATTERS + + + GPUs remain economically competitive against Miners can invest without depending on emergency + realistic specialised hardware algorithm changes to protect them. + + + A straightforward, efficient miner with reliable Ordinary owners can participate successfully, not just + payouts and retained operator control sophisticated mining businesses. + + + Useful proofs that outside customers repeatedly You establish demand for a service, rather than relying + purchase exclusively on enthusiasm for the coin. + + + Secure execution, finality and independently Developers and customers have a reason to trust the + operated infrastructure network with meaningful activity. + + +Deliver all four. The result would be a serious leadership candidate, not merely another GPU-minable coin. +Shipping features is not the same as demonstrating that these outcomes hold. + +S1: supplied 2.0 document. S2: supplied leadership screenshot. C2: consolidated research discussion. + + + + +IGNEUM 2.0 / 08 OCT 2026 3 / 37 + STRATEGY / 2.0 + + + +02 / STRATEGIC POSITION + + +A credible route to leadership. +The ceiling is category leadership. Adoption, sustained demand and trust still have to be earned. + + A REA T HE PROPOSED END-STATE + + + A potential leadership position once independent hardware analysis confirms + GPU competitiveness + the result against programmable, multi-epoch competitors. + + + Reproducible measurements and realistic adversarial designs. Economics that + Resistance evidence + do not assume chips automatically expire. + + + Straightforward installation, effective tuning, transparent earnings, reliable + Miner experience + payouts and retained control. + + + The same accessible hardware can potentially earn from genuinely purchased + Useful hardware + proving work as well as securing the chain. + + + A credible contender after independent review and failure testing. A feature + Security and decentralisation + list does not establish security. + + + Profitability and market Demand, competition, liquidity and operating costs determine the outcome. + position Protocol design alone cannot guarantee them. + + + + MINER PROPOSITION CUSTOMER PROPOSITION + + Useful hardware. Retained control. Correct results. Reliable delivery. + My hardware remains useful and competitive. I I receive a correct result at a competitive price + can earn from more than the mining subsidy and reliable delivery time, without needing to + without surrendering control. choose which independent operator produced it. + + +Leadership requires miners who stay through difficult conditions, customers who repeatedly pay for output +and a network that works without the founding team holding it together. The complete package is the +advantage, not one supposedly unbeatable hash. + +S1: leadership assessment, proposed end-state and miner/customer propositions. S2: leadership requirements. + + + + +IGNEUM 2.0 / 08 OCT 2026 4 / 37 + STRATEGY / 2.0 + + + +03 / EVIDENCE AND BASELINE + + +What the evidence shows. +This edition preserves the source snapshot. It does not certify a deployment, an audit or a +completed benchmark. + + E VIDENCE CLASS M EANING IN THIS PLAN + + + A result supplied by the team or recorded in the earlier discussion. Not + TEAM-REPORTED + independently reproduced for this PDF. + + + An estimate conditional on hardware, implementation, cost and lifetime + MODELLED + assumptions. Not a measured manufactured product. + + + An architectural recommendation or research hypothesis. It needs an acceptance + PROPOSED + test before adoption. + + + Evidence or implementation was outstanding at the source snapshot. No later + PENDING + completion is assumed. + + + A rejected approach retained in the record. It is not silently returned to the + EXCLUDED + roadmap. + + +The current foundation +The discussion records consumer-GPU proof generation, development-network mining, execution +consistency and proving payouts. These support a technical proof of concept. They do not yet establish a +fully enforced, independently validated or commercially proven network. + +The next boundary +Consensus-enforced proof verification, finality under long disruptions, sustained end-to-end proving +capacity, independent operation and repeat external demand are separate gates. A successful test in one +category does not satisfy another. + + + STATUS DISCIPLINE + + Designed, implemented, activated, team-tested, independently reproduced and independently + reviewed are different states. Every release should make the difference visible. + + +The full source text is retained in the appendix. References to current conditions in that text describe the source snapshot, not a fresh +status check performed during typesetting. + + +S1: implementation caveats. C1: team update. C3: earlier litepaper review and evidence discussion. + + + + +IGNEUM 2.0 / 08 OCT 2026 5 / 37 + STRATEGY / 2.0 + + + +04 / HARDWARE SNAPSHOT + + +The honest hardware baseline. +Latest team update in the conversation. Figures remain conditional on the declared comparison +and outstanding measurements. + + R EPORTED SPECIALISED + C OMPARISON AT THE KNEE + A DVANTAGE + + + + GPU and chip on the same process node 2.0× per joule + + Chip one process node ahead 2.4× per joule + + Chip two process nodes ahead 2.8× per joule + + Apple comparison tier 1.2× per joule + + L EVER OR ASSUMPTION S OURCE SNAPSHOT + + + Reported reduction of 34-41% in Blackwell/Ada power draw for under 2% + Ember core-clock lock + loss of rate. This saving is already in the tuned baseline. + + + Reported k change from 0.56 to 0.78 against a chip one node ahead; parity + 64-register window + on the GPU's own node. GPU-side cost was still being measured. + + + 5.5 / 8.5 / 11.5 GiB proposed. The update says the 8 GB tier would be retired + Dataset schedule + at year two. This is a policy cost, not automatically a success. + + + The update reports thirty-odd measurement rows across rented 5090, 4090, + Evaluation coverage + H100, 3090 and PC 1 cards. + + + Register-window GPU cost; PC 1 memory-clock ladder; placed chip core; 5.5 + Still owed in the update + GiB rows on the 8 GB card. + + +The same-DRAM assumption must be tested against the adversary's best feasible memory configuration. A +larger register file on the GPU is not proof that using it has zero marginal cost. Synthesis and physical- +design estimates must be kept separate. + + + DO NOT PROMOTE THE MODEL INTO A GUARANTEE + + The earlier $23M and $340M annual-revenue thresholds, $20-75M development-cost range + and chip-arrival probabilities are source assumptions or claims, not validated safety boundaries. + Chip lifetime must be tested, not assigned. + + + +C1: latest team chip-status update. C2: interpretation, outstanding tests and modelling limits. + + + +IGNEUM 2.0 / 08 OCT 2026 6 / 37 + STRATEGY / 2.0 + + + +05 / DECISION REGISTER + + +Keep progress. Remove noise. +The 2.0 baseline starts with measured work and a short list of falsifiable experiments. + + E LEMENT D IRECTION R EASON + + + Reduce honest operating cost without adding + Ember tuning Keep + consensus complexity. + + Measure unavoidable live-state cost and the + 64-register window Keep and test + complete GPU penalty. + + Preserve measured settings and address-quality + 16-byte reads / index fold Retain baseline + fixes. Reopen only with a new hypothesis. + + Re-optimise the adversarial architecture after every + Operation mix Conditional + change. + + Price the ASIC burden against excluded cards and + Dataset progression Reconsider + proving-memory pressure. + + Require measured versatility benefits and acceptable + Hourly program Conditional keep + compilation cost. + + Each boundary must earn its implementation and + Weekly / family layers Simplify if redundant + testing cost. + + Useful for genuine vulnerabilities; not the basis of + Bring-forward mechanism Govern carefully + normal competitiveness. + + Not a committed fix. Require deterministic, cross- + Mixed integer/FP32 Research branch + vendor results. + + The apparent advantage did not survive realistic + Long programs / select trees Exclude + implementation. + + SM gating, wider reads, sealed classes, random + Other rejected knobs Exclude epoch lengths, per-tier scoring and VRF draws + remain out. + + A programmable adversary can implement known + Automatic chip expiry Remove assumption + changes in firmware. + + +Retain rejected variants as controls. A sound evaluation should continue rejecting the long-program result +when instruction memory is implemented as shared SRAM rather than flip-flops. + + ONE ACCEPTANCE RULE + + A change passes only when the best adversarial implementation becomes worse relative to the + best practical GPU implementation, within pre-agreed cost and verification limits. + + +C1: chosen and rejected levers. C2: consolidated keep/change/remove recommendations. + + + + +IGNEUM 2.0 / 08 OCT 2026 7 / 37 + STRATEGY / 2.0 + + + +06 / DEFINE THE TARGET + + +Measure real competitiveness. +A single joules-per-hash ratio cannot establish durable access to mining. + + + EXISTING OWNER NEW ENTRANT + + Does running the card make sense? Can accessible hardware be purchased? + Include electricity, wear, fees, failure risk and Include purchase price, financing or annualised + alternative uses. Existing hardware does not cost, operation and realistic resale value. A + need to recover its historical purchase cost in the healthy installed fleet can hide poor replacement + same way as a new investment. economics. + + + + CORE MEASURE + + Cost per accepted unit of work = annualised hardware cost, power, hosting, failures and + fees divided by annual accepted work. + + +Use accepted work rather than kernel hashrate. Include rejected submissions, downtime, epoch +preparation, compilation, host power and network delays. Publish the reference population before +optimising against it: several generations, vendors and memory capacities, including realistic used +hardware. + + E NERGY TARGET W HAT THE ARITHMETIC ACTUALLY SAYS + + + About 33.3% less electricity per hash. This can still be commercially + 1.5× specialist efficiency + meaningful. + + + With the ASIC unchanged, the GPU would need a further 37.5% + 2.4× down to 1.5× energy reduction. The existing clock-lock saving cannot be counted + twice. + + + Under the earlier assumed 1.2× node multiplier, reaching 1.5× one + Same-node research gate node ahead implies about 1.25× at the same node. Recalculate for + each design. + + +Separate specialisation advantage from electricity and scale advantages. No hash can guarantee that every +domestic tariff is competitive with every industrial tariff. The target is a bounded additional barrier from +hardware specialisation, not equal profitability everywhere. +Figures above are calculations from assumptions already discussed. They are targets and illustrations, not achieved results. + + +C2: competitiveness definition, energy-ratio calculations and comparison boundaries. + + + + +IGNEUM 2.0 / 08 OCT 2026 8 / 37 + STRATEGY / 2.0 + + + +07 / ARCHITECTURAL EXPERIMENT + + +Make simplification expensive. +Investigate a compact execution core that connects live state, dependent reads, arithmetic and +communication. + + + CANDIDATE EVALUATION PATH + + Live state → memory address → returned data → arithmetic and lane interaction → + updated live state → next address. + + +Start by reorganising, not expanding +Hold approximate instruction count, read count and dataset size constant for the first experiment. Change +dependency structure so the adversary cannot cheaply isolate storage, arithmetic and scheduling into +independent small engines. Make the final result depend on the necessary intermediate work. + +Prove the state is necessary +The useful question is not whether the reference program declares 64 registers. It is how much +independent information must remain available across memory waits, how often it is accessed and what +the cheapest implementation pays to service it. Permit banking, SRAM, time-multiplexing, compression +where possible and selective recomputation. + + E XPERIMENT P ASS EVIDENCE + + + Lower whole-system specialist advantage after the adversary is + Connected existing resources + redesigned, without an unacceptable honest-card cost. + + + Reducing, reconstructing or moving the state creates a quantified + Persistent live state + performance, energy or area penalty. + + + A separate integer/FP32 prototype improves the result after exact + Broader resource mix semantics, compiler behaviour and adversarial simplification are + included. + + +The mixed-resource prototype is optional. Avoid approximate operations and architecture-dependent +results. A restricted floating-point domain may be much cheaper for a specialist than a general floating- +point unit, so the hardware reviewer must be allowed to exploit it. + + + RESEARCH STATUS + + These are hypotheses, not an established recipe for 1.5×. A negative result is useful evidence + and must remain publishable. + + + +C2: resource-matching programme and research qualifications. R5-R8: carried-forward research context. + + + + +IGNEUM 2.0 / 08 OCT 2026 9 / 37 + STRATEGY / 2.0 + + + +08 / MEMORY AND ATTACK SURFACE + + +Price the cheapest alternative. +Large memory capacity alone is not a complete energy-resistance argument. + + A DVERSARIAL PATH W HAT TO TEST + + + Several engines amortise dataset storage, construction and updates. + Shared dataset + Analyse many concurrent hashes, not only one. + + + Store selected data, recompute the rest and choose the best time-memory + Reduced memory + trade-off. + + + Distribute data across processors and move computation or intermediate + Data-local computation + state towards the next read. + + + Mine only favourable programs or families. Include idle periods, fallback + Selective participation + execution and difficulty response. + + + Try to reuse an expensive intermediate state across many cheap winning + Reusable expensive work + attempts. Review nonce, template and output binding. + + + Allow different devices, channels, banking, caches, packaging and + Alternative memory system + operating points rather than fixing the GPU's layout. + + +The register window has a specific job +Price the cheapest combination of moving state, moving data, recomputing values and adding local +resources. A larger necessary state may make distributed execution less attractive, but it can also penalise +the GPU. The complete comparison decides. + +Every accepted program must carry the intended cost +Study both the average advantage and its distribution. A family bank with occasional weak periods can +support a profitable intermittent specialist. Require an unavoidable resource floor and examine whether +each lottery attempt really pays for it. + + + ANALYSIS DELIVERABLE + + Map the actual Igneum evaluation process into an explicit memory-capacity, bandwidth, energy + and amortisation model. State which results are bounded formally and which depend on + physical-design estimates. + + + +C2: memory sharing, selective participation, data-local execution and shortcut review. R6-R10: context retained from the research +discussion. + + + + +IGNEUM 2.0 / 08 OCT 2026 10 / 37 + STRATEGY / 2.0 + + + +09 / ROTATION AND MEMORY POLICY + + +Competitive without rescue. +Known scheduled changes are part of the adversary's design brief. Future emergency changes +are not a profitability assumption. + + L AYER IN THE TEAM PLAN 2 .0 ACCEPTANCE REQUIREMENT + + + Show the anti-specialisation benefit after compilation, setup and easy- + Hourly program + program selection costs. + + + Demonstrate a distinct cost to the adversary. Remove redundant + Weekly parameters + complexity. + + + Evaluate one programmable opponent supporting the entire published + 180-day family / 18-family bank + bank. Crossing the boundary is not proof of chip retirement. + + + Specify activation, coalition behaviour, partition handling and old-client + Miner-voted bring-forward + behaviour. "No veto" requires a mechanism, not a label. + + + Measure adversary burden against commodity exclusion, upgrade costs + Dataset schedule + and mining/proving coexistence. + + + Protect the intended seed-selection property and define behaviour + Seed/VDF pipeline + when finality is unavailable. + + +The no-rescue test +Evaluate several years with no newly invented instruction families or emergency anti-chip upgrades. +Published program changes and scheduled transitions can continue, but the hardware designer knows +them all. The system must remain competitive against a design that survives them. + +A conservative memory support horizon +Prefer a bounded, epoch-defined dataset and a declared hardware-support horizon. Grow memory only +where the extra adversary cost justifies the burden on ordinary operators. Treat retirement of the 8 GB tier +as a cost to evaluate, not an achievement. + +Do not credit live chain-state coupling as an ASIC exclusion mechanism merely because stale state gives +wrong answers. Price update bandwidth, synchronisation, recovery and adversarial state growth. Keep it +only where the measured benefit survives those costs. + +C1: four-layer plan and dataset sizes. C2: no-rescue evaluation and dataset-policy recommendations. + + + + +IGNEUM 2.0 / 08 OCT 2026 11 / 37 + STRATEGY / 2.0 + + + +10 / INDEPENDENT HARDWARE BRIEF + + +Build the strongest opponent. +Commission an independent, programmable, multi-epoch design. Do not force it to imitate a +graphics card. + +The reviewer should minimise total cost and energy while remaining compatible with the published +program space. Permit changes in clock, lane count, execution width, pipelines, state storage, instruction +sharing, memory configuration and supporting hardware. + + A DAPTATION R EQUIRED RESULT + + + Firmware update Throughput, energy and cost before and after each family transition. + + + Measured or modelled penalty for missing native operations. Slower + Emulation + does not automatically mean unprofitable. + + + Board cost, bandwidth, power and survival through the dataset + Memory expansion or overprovisioning + schedule. + + + Companion CPU, GPU or FPGA Complete-system economics, including hybrid mining and proving. + + + Favourable-period mining Revenue after idle periods, re-entry and difficulty response. + + + Incremental revision cost, reusable design work and realistic + Silicon revision + development delay. + + +Evidence standard +Use realistic SRAM macros, port requirements, wiring, memory interfaces, switching activity and complete- +board overhead. Logic synthesis is one input, not a manufactured-chip measurement. Keep same-node +and advanced-node results separate and publish uncertainty ranges. + + + THE LIFETIME RULE + + Assume a capable programmable design can survive several epochs. Award a retirement benefit + only when the cheapest adaptation loses economic competitiveness. Compatibility, efficiency + and investment return are separate outcomes. + + +Public challenge incentives should reward a better adversary and a reproduced shortcut, not only +confirmatory results. Independent reproduction and independent security review answer different +questions. + +C2: adversarial brief, transition matrix and physical-design requirements. + + + + +IGNEUM 2.0 / 08 OCT 2026 12 / 37 + STRATEGY / 2.0 + + + +11 / COEXISTENCE ECONOMICS + + +Economics after chips arrive. +A failed development investment can still leave an efficient installed fleet. The model must +include that world. + + + NORMAL INVESTMENT CASE ALREADY-FUNDED CASE + + Price the full project. Treat development as sunk. + Include development, initial fleet, later Assume research has already been paid for or + purchases, power, operations, financing reused elsewhere. The opponent still pays + assumptions and residual value. Test private manufacturing, deployment and operation. Can + mining and hardware sales. accessible GPUs compete? + + +Let operators react +Model entry and exit, used-card prices, replacement cycles, changing difficulty and alternative workloads. +Do not hold everyone's revenue share constant while comparing margins. A GPU upgrade is not free, and a +chip revision need not repeat the entire original development bill. + + S CENARIO AXIS R EQUIRED RANGE OF BEHAVIOUR + + + Small, growing and successful high-revenue networks; falling token + Network revenue + revenue as well as expansion. + + + Multi-year programmable survival plus demonstrated transition + Hardware lifetime + penalties. + + + Different electricity tariffs, hosting, failure rates, purchase prices and + Operator costs + resale values. + + + Declining issuance, fee income, internal proving demand and external + Reward structure + jobs. + + + Private supply, public hardware sales, multiple suppliers and + Market structure + concentration. + + +The earlier $340M and $23M annual-revenue thresholds belong in a sensitivity workbook with their +assumptions. They are not general safety boundaries. The revised goal is not to make every specialised +investment lose money; it is to prevent a lasting overwhelming barrier to accessible mining. + + + SUCCESS CONDITION + + A specialised supplier may earn a normal return. Ordinary GPUs remain sufficiently close in total + cost, widely obtainable and useful outside mining that new operators can still compete. + + + +C1: source thresholds and development-cost assumptions. C2: five-year coexistence model and sunk-cost stress case. + + + + +IGNEUM 2.0 / 08 OCT 2026 13 / 37 + STRATEGY / 2.0 + + + +12 / MINER AND OPERATOR EXPERIENCE + + +Make good operation ordinary. +Desktop-first on Windows and macOS. A mining-console experience, not a web app disguised as +a desktop product. + + P RODUCT REQUIREMENT W HAT THE OPERATOR SHOULD RECEIVE + + + Straightforward install, hardware detection, compatibility explanation and + Easy entry + safe default tuning. + + + Separate mining, internal proving and external proving income. Show net + Honest economics + estimates using the operator's entered electricity tariff. + + + Clear power limits, pause/stop controls, job selection and explicit + Control + software-update acceptance. + + + Rejected work, failed proofs, queue delays, memory pressure and missed + Failure visibility + payments are visible and actionable. + + + Reliable, noncustodial payment paths that do not make small operators + Accessible payouts + impractical. + + + Isolate proving workloads from wallet secrets and signing authority. + Safe execution + Publish the security assumptions. + + +Pool payment variance without surrendering authority +Investigate a verifiable binding between performed work and the miner's retained voting key. Pooling +payments should not silently hand transaction selection, governance or finality control to the pool. Test key +substitution and actual template selection rather than relying on a protocol label. + +Make the best implementation accessible +Publish optimisations, compiler settings and safe tuning logic. Measure home-connection performance +against datacentre performance using accepted work. Evaluate decentralised pooling and job declaration +where they fit Igneum's own protocol. + + + DO NOT ADD + + Hardware whitelists, trusted-device attestation, self-reported GPU bonuses or per-address + reward quotas do not establish economic equality. Keep hardware profiling in the client, not + self-attested consensus privilege. + + + +C2: operator-control programme, pooling and software requirements. Earlier project context: native desktop miner and wallet. + + + + +IGNEUM 2.0 / 08 OCT 2026 14 / 37 + STRATEGY / 2.0 + + + +13 / APPLICATION ARCHITECTURE + + +EVM is the right front door. +A sovereign GPU-mined L1 with a flexible, carefully versioned proving layer. Not simply another +zkEVM label. + + D ECISION 2 .0 DIRECTION P URPOSE + + + Reuse familiar contracts, languages, + Developer interface EVM-compatible execution + wallets and tooling. + + + General-purpose zkVM; initially the Prove the EVM implementation without + Execution proof + SP1-based implementation creating a bespoke proof system. + + + Keep responsibility for consensus, data + Security and finality Igneum's sovereign GPU-mined L1 + availability and recovery explicit. + + + Supported customer proving Serve other networks without requiring + External service + workloads application migration to Igneum. + + +The supplied plan identifies revm for EVM execution and SP1 behind a versioned proving interface. A zkVM +can prove a program that implements EVM execution; zkVM and zkEVM are not competing choices in this +composition. + +Compatibility is a test suite +Document differences in block context, timestamps, randomness and two-dimensional fees. Test +representative contracts, wallet fee estimation, indexing, reverted transactions, receipts and application- +level economic assumptions. Bytecode execution is not proof that every application behaves unchanged. + +Sovereignty is deliberate +Do not move to an Ethereum L2 merely for the category label. An L2 may be appropriate for Ethereum- +settlement objectives, but the supplied strategy is an independent home for GPU operators. Igneum +therefore keeps its own consensus, availability and cross-chain verification obligations. + + + POSITIONING + + A GPU-secured network for Ethereum-compatible applications and verifiable computation. + + + +S1: architectural choices, EVM compatibility and sovereign-L1 recommendation. + + + + +IGNEUM 2.0 / 08 OCT 2026 15 / 37 + STRATEGY / 2.0 + + + +14 / PROVING CORRECTNESS + + +Enforce every proof. +Official producers doing the right thing is not the same as ordinary validators enforcing it. + +The supplied source describes proving v0 as checking the statement against native execution without +requiring the carried SP1 proof to verify in consensus. Under that source snapshot, a modified producer +could obtain a proving payout without doing the corresponding valid proof work. This plan does not assume +the issue remains open or has been fixed; it requires version-specific closure evidence. + + N EGATIVE TEST R EQUIRED VALIDATOR BEHAVIOUR + + + Correct statement, invalid proof Reject the proof record and pay no proving reward. + + + Wrong program or verifier identity Reject under the pinned release configuration. + + + Wrong chain, epoch or statement binding Reject replayed or misbound work. + + + Changed payout identity Reject unauthorised payout changes. + + + Duplicate proof reward Enforce exactly the permitted payment outcome. + + + Authenticate their derivation, not just execution over supplied + Incorrect rewards or consensus inputs + inputs. + + +One well-tested backend first +Pin permitted program identities, verifier versions and security parameters. Preserve a controlled +replacement interface without treating several immature proof systems as interchangeable. Include +soundness analysis, security margins and the cost of verification in the acceptance process. + +Keep authority separate +Producing a proof should not make a provider the authority over ordering or finality. Test whether a +concentrated provider can stall useful operation by withholding service. Replacement operators need +usable inputs, reassignment and explicit behaviour during delays. + + + BOUNDARY + + A proof of execution is not automatically a proof of authenticated consensus inputs, canonical + history or data availability. + + + +S1: four conditions for the proving architecture. C3: P21/P22 review and proposed negative tests. + + + + +IGNEUM 2.0 / 08 OCT 2026 16 / 37 + STRATEGY / 2.0 + + + +15 / USEFUL WORK + + +Turn proofs into paid demand. +Start with one complete workload. Add breadth only where the operator fleet has demonstrated +an advantage. + + + COMPLETE PIPELINE + + Request → input availability → assignment → execution → shard proving → aggregation → + verification → inclusion or delivery → payment. + + + + S TAGE R EQUIRED EVIDENCE + + + Sustained proofs for a fixed, meaningful workload. Correct acceptance and + Igneum execution + payment. + + + An agreed proof format, deadline, price, failure policy and customer reason + First external pilot + for choosing the service. + + + Repeat purchases Genuine repeat paid jobs without the project reimbursing the customer. + + + Each service has validated inputs, program identity, verification rules and + Broader workloads + measured delivery economics. + + +Publish the complete benchmark +Report workload size, input transfer, memory, energy, waiting time, proving time, aggregation, verification, +failed attempts and payment delay. Publish typical and tail latency. A small shard that finishes quickly is +not a commercial result if total queues keep growing. + +Keep revenue categories separate +Mining subsidy, internal proving rewards and external customer revenue are different streams. +Development-network payouts prove an accounting path; they do not prove willingness to pay. Operator +revenue is also not automatically protocol revenue or demand for IGN. + + + INITIAL COMMERCIAL GATE + + One repeat customer purchasing useful proofs at a price that supports reliable delivery and + operator margin. Igneum does not first need to win the largest application ecosystem. + + + +S1: external proving sequence and commercial qualification. C2/C3: complete-pipeline benchmark and pilot gates. + + + + +IGNEUM 2.0 / 08 OCT 2026 17 / 37 + STRATEGY / 2.0 + + + +16 / COMBINED WORKLOAD + + +Mining and proving, together. +Do not combine isolated benchmark wins into a final configuration that has never been tested. + +The earlier review recorded the following team results for a fixed 4,717,439-cycle shard on a patched SP1 +implementation. These are historical discussion figures, not independently reproduced measurements for +this edition. + + C ONSUMER HARDWARE P ROVING ALONE A LONGSIDE MINING + + + RTX 3060 / 12 GB 14.4 s 37.5 s + + + Not reported for full compressed-proof + RTX 4060 / 8 GB 18.4 s + coexistence + + + RTX 4070 / 12 GB 12.1 s 27.3 s + + +The earlier coexistence configuration had a reported miner resident set around 1.4 GB. A 5.5 GiB mining +dataset changes the memory budget. Re-test the final dataset, register allocation, clocks and prover +together. Time-sharing or eviction may work, but their delay and opportunity cost belong in the result. + +Let operators maximise their own returns +Allow mining, internal proving, external proving and switching off. Test external-demand spikes, token- +price declines, a large operator disappearing and specialisation entering either market. The protocol +should not rely on the official scheduler choosing a less-profitable task. + +Pay for internal capacity +Clarify the recurring compensation for internal proof generation as issuance falls. Resolve any discrepancy +between the published fee table and prose before modelling security income. Burning a fee is not an +operator payment; external jobs do not automatically finance internal chain work. + + + ASSIGNMENT FAIRNESS + + Calibrate exclusive proving windows against real completion distributions. The earlier + provisional 10-DAA-second window must be tested against actual consumer-card latency, + failures and wasted work, not merely fair assignment counts. + + + +C3: historical proving results and assignment review. C1: new dataset plan. C2: joint incentive and fee tests. + + + + +IGNEUM 2.0 / 08 OCT 2026 18 / 37 + STRATEGY / 2.0 + + + +17 / CONSENSUS AND FAILURE BEHAVIOUR + + +Preserve the meaning of final. +Safety and liveness need explicit assumptions, authenticated authority and deterministic +recovery rules. + +The earlier review distinguished a corrected two-thirds total-weight rule from a later authority-set +problem. It recorded a frozen-table simulation in which conflicting locks appeared around expiry during a +prolonged partition. This is a version-specific source finding, not a fresh assertion about the deployed +node. + + F AILURE SCENARIO A CCEPTANCE EVIDENCE + + + No conflicting final histories within the stated fault assumptions. Any + Prolonged partition + loss of liveness is explicit. + + + Verifiable continuity from the last certified history. A timeout alone is + Authority-set transition + not evidence that missing voters no longer exist. + + + Defined checkpoint, weight and recovery behaviour without + Signing stops, mining continues + contradictory certificates. + + + Old voting keys compromised A distinct analysis from newly arriving hashrate. + + + Finality unavailable at a seed A documented seed and mining path that does not accidentally depend + boundary on an unavailable certificate. + + + Deterministic recovery. No quiet reversal of a guarantee previously + Partitions reconnect + labelled irreversible. + + +Test the real integration +The implementation and network tests must exercise ordering, finality, proof queues, voter tables and seed +transitions together. Passing simplified simulations is useful but does not replace testing the actual fork- +choice and recovery rules. + + + USER-FACING RULE + + Included, executed, proven and finalised are distinct states. A safe pause must be visible as a + pause, not presented as an unchanged guarantee. + + + +C3: finality, authority-table and seed-pipeline review. C2: independent failure-testing programme. + + + + +IGNEUM 2.0 / 08 OCT 2026 19 / 37 + STRATEGY / 2.0 + + + +18 / USER VERIFICATION + + +Verify what the label promises. +Light clients, receipts and cross-chain demos are valuable only within their actual verification +boundaries. + + S URFACE F INISH THE GUARANTEE + + + Authenticate the starting point, voter weights and subsequent authority + Light wallet changes. Signatures from supplied keys are not proof those keys were entitled + to certify the history. + + + Verify the permitted proof and authenticate its inputs. Do not substitute a + Execution proof + trusted aggregator statement for a stronger claim. + + + Prove a successful transfer with the asset, recipient and amount. Transaction + Payment receipt + inclusion alone does not establish successful execution. + + + Verify authority changes and the required execution statement. Remove or + Cross-chain oracle + disclose deployer-installed trust anchors and unchecked signatures. + + + Explain how the necessary state can be obtained and reconstructed. Valid + Data availability + execution does not by itself make the data available. + + +Preserve useful demos, narrow the labels +The earlier review treated browser verification, receipts and the Sepolia oracle as meaningful integration +work with unfinished trust assumptions. Keep those demonstrations, but name the actual verified property. +"Transaction-inclusion receipt" is more accurate than "successful payment proof" where execution status +is still node-reported. + + + BOUNDARY 01 BOUNDARY 02 + + EVM is not Ethereum security. ZK does not imply privacy. + An Ethereum-compatible application on Igneum Public transaction and state data remain public + depends on Igneum's security and availability unless a separate privacy design changes that. + model. + + +These surfaces are not prerequisites for proving mining competitiveness. They become trust products only +when their verification paths match their claims. + +S1: positioning boundaries. C3: light-wallet, receipt, oracle and availability review. + + + + +IGNEUM 2.0 / 08 OCT 2026 20 / 37 + STRATEGY / 2.0 + + + +19 / OPERATIONAL INDEPENDENCE + + +Operate without founder rescue. +A permissionless specification needs an operational counterpart. + +Distribution is not consensus authority +The earlier review noted development-network activation and state changes distributed through a signed +update manifest. Mainnet readiness requires separation between software delivery, operator acceptance +and consensus activation. A fleet that automatically accepts a release key can remain operationally +centralised. + + C ONTROL OR DEPENDENCY R EQUIRED OUTCOME + + + Reproducible builds, pinned source and binaries, explicit operator + Software release + acceptance and a signing-key incident procedure. + + + Independent discovery, node operation, proof inputs and payment paths + Public infrastructure + continue without the founder's services. + + + Replacement operators can take over without unpublished files, + Mining / proving / aggregation + privileged coordination or hidden configuration. + + + Secrets are isolated from untrusted workloads. Recovery and updates do + Wallet and worker execution + not quietly change signing authority. + + + Network identity and rules One authoritative release manifest states exactly what a node enforces. + + +Publish a machine-readable release manifest +Include network identity, source commits, mining class, dataset parameters, finality rule, program/verifier +identities, activation state and fee schedule. Generate current-status pages from it and label historical +records clearly. The earlier chain-ID and threshold discrepancies illustrate why this matters. + + + THE NO-FOUNDER EXERCISE + + Remove founder mining, proving, aggregation and public infrastructure from a test network. + Cross boundaries and inject failures. Show what continues to work, what pauses and how + independent participants recover. + + + +C3: release-manifest and update-control review. C2: no-founder network exercise. + + + + +IGNEUM 2.0 / 08 OCT 2026 21 / 37 + STRATEGY / 2.0 + + + +20 / REFERENCE LANDSCAPE + + +Learn from the mechanism. +Historical and future-hardware context retained from the research discussion. No new market +ranking is asserted here. + + R EFERENCE POINT L ESSON CARRIED INTO 2.0 + + + Specialised hardware existing and GPUs remaining viable are not mutually + Ethash + exclusive. Coexistence is the relevant target. + + + Bind work to useful general-purpose resources. Treat frequent emergency + RandomX + tweaks as a weaker foundation than a sound baseline. + + + The goal of keeping GPUs competitive without repeated algorithm forks + KAWPOW / Ravencoin + already has a serious precedent. + + + Benchmark an operating GPU-oriented system, including pooling, emissions + Ergo + and difficulty behaviour, not just a whitepaper. + + + Open, competitive reference mining software is part of accessibility. Treat + Firo + reported performance as source-reported. + + + + F UTURE OPPONENT TO ALLOW W HY IT CHANGES THE TEST + + + Programmable compute without Supports the whole family bank while removing unrelated + graphics graphics functions. + + + Reuses design work and changes components without funding an + Chiplets and modular revisions + entirely new project. + + + Survives known dataset growth without automatically replacing + Denser or excess memory + the compute core. + + + Chooses the cheapest balance of memory, movement, + Data-local and hybrid systems + recomputation and companion processors. + + + Specialises proving separately from the mining lottery. Useful + Proof accelerators + proving is not permanently GPU-exclusive. + + +These are stress-test opponents, not predictions of shipment dates or evidence that an Igneum chip exists. Credit future improvement +to commodity hardware and specialised hardware consistently. + + +S1: Ravencoin, Ergo and Firo context. C2: historical research and future-hardware stress cases. R1-R14. + + + + +IGNEUM 2.0 / 08 OCT 2026 22 / 37 + STRATEGY / 2.0 + + + +21 / DELIVERY PROGRAMME + + +The hardware delivery gates. +Proposed work packages. Owners, dates, budgets and numerical acceptance tolerances still +require approval. + + +G1 / FROZEN BASELINE + +Reproduce the real system. +Publish the exact v6 generator, verifier, dataset policy, compiler configuration and measurement harness. +Close the pending register, memory-clock, placed-core and 8 GB-card measurements. Test final mining +and proving together. + +Pass: independent operators reproduce the baseline within declared tolerances. Report wall power, device +telemetry, accepted/rejected work, compilation, memory and sustained thermal behaviour. +Lead role: GPU engineering. Evidence review: independent operators. + + + + +G2 / TWO ARCHITECTURAL EXPERIMENTS + +Test resource coupling and memory alternatives. +Reorganise existing work to increase unavoidable live-state and execution costs. Attack the candidate and +v6 with sharing, recomputation and data-local execution. Keep mixed-resource FP32 work separate and +optional. + +Pass: the candidate improves against re-optimised adversaries across the reference GPU population, +within a pre-agreed honest-card and verifier cost budget. +Lead roles: GPU engineering and cryptography. Reviewer: independent hardware team. + + + + +G3 / PROGRAMMABLE ADVERSARY + +Let the opponent survive. +Build a realistic multi-family, multi-epoch design with physical memory and complete-board costs. Permit +firmware updates, emulation, overprovisioning and hybrid devices. Separate process-node advantage from +architectural advantage. + +Pass: the strongest supported whole-system advantage remains inside the approved competitiveness +envelope. Publish uncertainty, unsuccessful designs and any shortcuts found. +Lead role: independent hardware reviewer. Decision: protocol and GPU leads. + + + +C2: five-deliverable research programme. Role labels are planning placeholders, not staff assignments. + + + + +IGNEUM 2.0 / 08 OCT 2026 23 / 37 + STRATEGY / 2.0 + + + +22 / DELIVERY PROGRAMME + + +The durability delivery gates. +Commercial validation runs alongside the network programme. None of these gates is marked +complete in this edition. + + +G4 / FIVE-YEAR COEXISTENCE MODEL + +Model the network after specialisation arrives. +Use measured and modelled hardware results rather than an assumed expiry date. Include rising and +falling revenue, lower issuance, different power costs, already-funded development, GPU resale/ +replacement and changes in proving demand. + +Pass: identify credible conditions for sustained accessible participation and state the failure regions. A +result that requires a small network, token appreciation or guaranteed chip death has not met the +objective. +Lead role: economic modelling. Inputs: independent hardware and operator data. + + + + +G5 / NO-RESCUE NETWORK EXERCISE + +Operate without founder intervention. +Use independent builds and operators. Remove founder infrastructure, cross program and family +boundaries, interrupt signing, partition the network, withdraw major providers and submit hostile proof +records. + +Pass: ordinary validators reject invalid work and the network exhibits documented safety, availability and +recovery behaviour without an emergency anti-chip rule or privileged intervention. +Lead roles: protocol engineering and independent security review. + + + + COMMERCIAL TRACK / IN PARALLEL + + Secure one genuine paid proof pilot. Progress to repeat purchases without reimbursing the + customer. Document the workload, service guarantee, total cost and customer's reason for + choosing Igneum. + + +Before mainnet, the intended release also needs complete proof enforcement, a resolved finality/recovery +model, operator-control tests, a compatible application test suite and an adequately funded maintenance +plan. A compressed exercise cannot substitute for years of operational evidence. + +C2: coexistence and no-rescue deliverables. S1/C3: commercial and mainnet-readiness conditions. + + + + +IGNEUM 2.0 / 08 OCT 2026 24 / 37 + STRATEGY / 2.0 + + + +23 / ACCEPTANCE SCORECARD + + +Evidence for every gate. +This is an acceptance checklist, not a completion dashboard. + + G ATE E VIDENCE REQUIRED D O NOT SUBSTITUTE + + + Pinned code and independently reproduced system- A favourable isolated + Hardware baseline + power results. benchmark. + + Best realistic multi-epoch adversary, complete cost One reference ASIC or a + Specialist competition + boundaries and uncertainty. synthesis artefact. + + Current owners and new entrants across the + Commodity access The newest flagship alone. + reference cohort. + + Unmodified validators reject invalid, replayed and Official producers behaving + Proof enforcement + misbound proofs. correctly. + + Declared workload, bounded backlog and tail- Fast shards with unbounded + Sustained proving + latency distribution. queues. + + Consistent authority changes and documented + Finality and recovery A timeout labelled irreversible. + partition behaviour. + + Authenticated roots, execution outcomes and trust Signatures over + User verification + anchors. unauthenticated authority. + + Pooled payments without hidden transfer of + Operator control A pool protocol name. + governance/finality control. + + Independent operation No-founder exercise on the real implementation. A centrally supported demo. + + Repeat paid external jobs and workable operator Devnet payouts or subsidised + Commercial demand + margins. volume. + + Internal proving/security payments and maintenance Burn accounting or assumed + Long-term funding + runway. appreciation. + + Comparative results, adoption, retention and A roadmap or unsupported + Leadership + reliability over time. rank. + + + + RELEASE EVIDENCE PACKET + + A source commit, exact parameters, test procedure, raw result, independent-reproduction + status, review scope and unresolved limitations should accompany every material claim. + + + +S1/S2: leadership outcomes. C2/C3: consolidated technical, economic and commercial acceptance tests. + + + + +IGNEUM 2.0 / 08 OCT 2026 25 / 37 + STRATEGY / 2.0 + + + +24 / RISK AND OWNERSHIP + + +Keep the hard risks in view. +Suggested lead roles. This document does not appoint individuals or invent delivery dates. + + R ISK P RIORITY RESPONSE L EAD ROLE + + + Residual specialist cost Run physical, programmable multi-epoch GPU + independent + advantage evaluation. Do not promise chip expiry. hardware + + Set GPU-cost and memory-accessibility limits + Defence harms honest cards GPU + product + before experiments. + + Make valid proof verification mandatory in ordinary + False proving reward Protocol + proving + validators. + + Resolve authority transitions and long-partition + Conflicting final histories Consensus + security + recovery. + + Preserve miner keys and transaction control Protocol + pool + Concentrated authority + through pooling. integration + + Provider withdrawal stalls Reassignment, usable inputs, replacement + Proving + operations + chain aggregation and failure tests. + + Model lower issuance and explicit recurring + Reward economics decay Economics + protocol + capacity payments. + + One paid workload, repeat customers, costs and + No external demand Commercial + proving + service guarantees. + + Explicit updates, reproducible builds and an + Release-key dependence Release engineering + incident/recovery process. + + Single release manifest and source-versioned + Status and claim drift Release + documentation + evidence pages. + + +Spend in the right order +Complete consensus proof enforcement and resolve finality boundaries while closing the v6 evidence +packet. Run hardware research and a narrow customer pilot in parallel. Delay broad ecosystem expansion +until the core path is secure, reproducible and useful. + +Publish a maintenance plan covering engineering, audits, infrastructure and incident response. Distinguish +committed funding from income that depends on future adoption. Preserve the fair-launch principle +without treating it as a funding strategy. + +C2/C3: prioritisation and risk themes. S1: adoption and proof-enforcement conditions. Owner roles are editorial planning labels. + + + + +IGNEUM 2.0 / 08 OCT 2026 26 / 37 + STRATEGY / 2.0 + + + +25 / LEADERSHIP AND PUBLIC CLAIMS + + +Leadership through outcomes. +Verified engineering earns consideration. Competitive economics and real demand earn +adoption. Sustained operation earns leadership. + +The commercial and adoption tests +Track whether miners remain active through weak market conditions, whether customers repurchase +without subsidies and whether independent developers can deploy useful applications. Reliability, +operator margin, liquidity and support all affect the outcome. None can be guaranteed by an algorithm. + + P UBLIC WORDING W HAT MUST SUPPORT IT + + + Designed for GPU competitiveness A clear objective and design rationale. Not a measured guarantee. + + + Team-tested Published procedure, version and team result. + + + An unaffiliated operator reproduces the stated result and + Independently reproduced + boundaries. + + + Independently reviewed A scoped review of the relevant release and its unresolved findings. + + + Comparative engineering evidence plus a credible operating and + Top-tier contender + customer proposition. + + + Sustained adoption, demand, reliability and retention. No + Category leader + unsupported numerical ranking. + + + + THE CLAIM TO EARN + + Igneum remains competitive on accessible commodity GPUs even when specialised mining + hardware is assumed to exist, remain compatible and seek profit. Its security does not rely on + identifying that hardware or retiring it through emergency changes. + + +Claims to leave out +Do not publish guaranteed chip death, a universal ASIC-efficiency ceiling, precise chip-arrival probabilities +without a calibrated model, guaranteed profits, Ethereum security by compatibility or automatic +transaction privacy from using ZK technology. + +The strongest proposition combines competitive commodity mining, application execution, verifiable +proving, an accessible operator application and meaningful miner control. Execute the evidence gates first. +Let the ranking follow the results. + +S1: leadership assessment and architecture boundaries. S2: adoption risks. C2: final competitiveness claim. + + + + +IGNEUM 2.0 / 08 OCT 2026 27 / 37 + STRATEGY / 2.0 + + + +26 / COMPLETENESS MAP + + +Everything has a home. +The operational plan is consolidated here. The supplied document is preserved in full in the +appendix. + + S OURCE THEME W HERE IT APPEARS + + + Four leadership requirements and screenshot + The objective (p. 3); leadership and claims (p. 27). + context + + Complete supplied leadership assessment Strategic position (p. 4); full source appendix A (p. 31). + + Application architecture (p. 15); full source appendix B (p. + Complete supplied EVM / zkVM strategy + 34). + + + Latest team chip figures and outstanding work Hardware snapshot (p. 6); decision register (p. 7). + + Architectural experiment (p. 9) through independent + GPU-first architecture, dataset and rotation + hardware brief (p. 12). + + Past, present and future threat model Reference landscape (p. 22); reference register (p. 29). + + Economic survival, ASIC coexistence and proof Coexistence economics (p. 13); useful work (p. 17); + demand combined workload (p. 18). + + Miner experience, pools and retained authority Ember and operator control (p. 14). + + Evidence baseline (p. 5); proof enforcement (p. 16) + Proof-of-concept limits and security gaps + through operational independence (p. 21). + + Delivery programme (p. 23) through risk and ownership (p. + Delivery, acceptance and risk + 26). + + + +Editorial boundaries +The first part converts the discussion into a usable plan without marking proposed work as completed. The +appendix retains the supplied document's organisation, argument, qualifications and level of detail. +Typography, punctuation and table structure are normalised for readability. The source title's spelling is +recorded rather than silently treated as the official brand spelling. + +No delivery dates, staff assignments, budgets or new performance claims have been invented. Historical +source statements have not been silently updated to a later status. + +S1/S2 and C1-C3: source coverage and editorial method. + + + + +IGNEUM 2.0 / 08 OCT 2026 28 / 37 + STRATEGY / 2.0 + + + +27 / PROVENANCE + + +Source register. +This is a designed compilation, not a new research or verification pass. + +S1 and S2 are the materials supplied with this request. C1-C3 are the preceding conversation. B1 is the +original brand kit recovered from the file library. References R1-R18 are reading links carried forward from +the discussion; they have not been independently rechecked for this formatting edition. + +S1 IGNEUM 2.0.rtf + Supplied document. Complete substantive text retained in appendices A and B. + +S2 Screenshot 2026-10-08 at 16.30.15.png + Supplied four-outcome table and leadership context. Re-typeset on the mission page. + +C1 Team chip-status updates in this conversation + Reported hardware figures, chosen class-v6 changes, four-layer rotation, rejected levers and pending measurements. + +C2 GPU competitiveness research discussion + Consolidated research recommendations, economic stress cases, future opponents and five delivery gates. + +C3 Earlier litepaper and proof-of-concept review + Historical reported proving results and version-specific security, finality, wallet and operations findings. + +B1 Igneum brand kit, 7 October 2026 + Original mark and lockups; Unbounded, IBM Plex Sans and IBM Plex Mono; obsidian, ember, graphite, bone and + molten palette. + +R1 Igneum litepaper, ledger, evidence and economics + Project references carried forward from the supplied material and discussion. + +R2 Ethereum: Ethash + Historical GPU/ASIC coexistence context. + +R3 Monero: a note on scheduled protocol upgrades + Earlier anti-ASIC changes and the transition to RandomX. + +R4 Ravencoin, Ergo and Firo reference landscape + Comparative project descriptions in the supplied source. See also Ergo Autolykos and Firo miner-release material in + the discussion. + +R5 RandomX design and design v2 + Device binding, program selection and tightly connected resource use. + +R6 ProgPoW design and independent audit + Resource matching, state movement and alternative implementations. + +The source text includes date-sensitive descriptions of project status and competitors. Those are retained as source statements. Their +presence in a polished document does not convert them into independently verified findings. + + +Source register. Reading links are retained for traceability, not represented as a fresh source audit. + + + + +IGNEUM 2.0 / 08 OCT 2026 29 / 37 + STRATEGY / 2.0 + + + +28 / READING LINKS + + +Research references. +Use the linked primary material when reproducing experiments, reviewing claims or updating +the plan. + +R7 HashCore + Processor-resource-matching research direction. + +R8 NVIDIA CUDA best practices + Registers, occupancy, memory behaviour and reproducible numerical execution. + +R9 Memory-hardness research discussed earlier + Distinguishes memory-capacity cost from bandwidth/energy properties. + +R10 EIP-1057 and related evaluation discussion + Proof-of-work structure and questions about reusable expensive work. + +R11 Vortex GPU architecture + Programmable compute as a future-adversary category. + +R12 UCIe specifications + Modular interconnect and packaging as future-adversary context. + +R13 Samsung 24 Gb GDDR7 announcement + Memory-density evolution; not a claim that arbitrary boards are upgradeable. + +R14 PipeZK + Proof-specific accelerator research, not a measured Igneum advantage. + +R15 SP1 documentation and RSP + General-purpose zkVM execution and EVM proving composition. + +R16 Ethereum: ZK-rollups and zkEVM programme + Execution proofs, settlement, availability and privacy boundaries. + +R17 Stratum V2 and Monero P2Pool + Job declaration, payout variance and retained operator control. + +R18 Ethereum receipt and account-proof interfaces + Inclusion, execution status and state-root authentication are distinct properties. + + + + UPDATING THIS DOCUMENT + + Update the evidence against a pinned release before changing a status label. Preserve + superseded results as historical records and distinguish new research from the supplied source. + + + +Carried-forward research references. Full supplied document begins on the following pages. + + + + +IGNEUM 2.0 / 08 OCT 2026 30 / 37 + STRATEGY / 2.0 + + + +APPENDIX A / SUPPLIED DOCUMENT + + + +Leadership assessment. +Complete source text. The original source title is INGEUM 2.0. + +Retained from IGNEUM 2.0.rtf. Formatting and punctuation normalised. Source statements are not newly +verified. + + + + +Yes - if the programme delivers the independently verified results we defined, my judgement is that Igneum +would belong in the top tier of GPU-first mining projects, with a credible case for technical leadership. +That is different from automatically becoming the largest, most profitable or most trusted GPU network. You +can engineer a leading system; adoption and sustained demand still have to follow. +The distinction is between shipping the proposed changes and demonstrating that they achieve the +objective. The latter is what would earn that position. + + +Where successful execution would put you + + A REA M Y ASSESSMENT OF THE PROPOSED END-STATE + + + A potential leadership position, provided independent hardware + Keeping ordinary GPUs competitive analysis confirms the result against programmable, multi-epoch + competitors. + + + A major strength if you publish reproducible measurements, realistic + Quality of the resistance evidence adversarial designs and economics that do not assume chips + automatically expire. + + + Potentially top-tier: straightforward installation, effective tuning, + Miner experience + transparent earnings, reliable payouts and retained control. + + + A compelling proposition if the same accessible hardware can earn + Usefulness of the hardware + from genuinely purchased proving work as well as securing the chain. + + + A credible contender after independent review and failure testing - not + Security and decentralisation + something a feature list establishes. + + + Miner profitability and market Still dependent on demand, competition, liquidity and operating costs. + leadership These cannot be guaranteed by protocol design. + + +The strongest potential advantage is the complete package - not one supposedly unbeatable hash. + + +You would be competing with serious projects +The space is not empty, and I would not claim Igneum had surpassed these projects merely because its +design is newer. +Ravencoin already expresses a closely related objective. Its KAWPOW approach is intended to keep +consumer GPUs competitive, explicitly allows for future ASIC development, and does not envisage further +algorithm forks as the normal defence. Igneum would need to demonstrate a stronger result or a more +valuable overall offering - not just restate that goal. + + +IGNEUM 2.0 / 08 OCT 2026 31 / 37 + STRATEGY / 2.0 + + + +Ergo already has a GPU-oriented, memory-hard mining design, with implemented changes to pooling, +emissions and difficulty adjustment. That gives you an operating system to benchmark against, rather than +merely a competing whitepaper. +Firo is actively improving commodity mining accessibility. Its September 2026 reference-miner release +supports NVIDIA and AMD, charges no developer fee, and reports performance within roughly 1% of +popular closed-source alternatives. That performance figure is Firo’s own report, but it illustrates the +practical standard Ember would need to meet. +Those are useful reference points, not an exhaustive league table. They also show why “GPU-friendly” is the +entry requirement, not sufficient differentiation. + + +What could make Igneum stand out +Your proposed combination is more interesting: +Competitive commodity mining + application execution + verifiable proving + an accessible operator +application + meaningful miner control. +The litepaper already frames mining, proving and Ethereum-compatible execution as separate but +connected parts of the system. The opportunity is to make that combination work reliably and economically +- not simply to have more features than another chain. +For a miner, the strongest proposition would be: + + “My hardware remains useful and competitive, I can earn from more than the mining subsidy, and + I do not have to surrender control to participate.” + +For a customer buying proofs: + + “I receive a correct result at a competitive price and reliable delivery time, without needing to care + which independent operator produced it.” + +Deliver both, and Igneum would have a strong reason to exist beyond attracting miners from another coin. +However, the proving-income distinction matters enormously. The current economics page describes +internal proving payouts on a valueless devnet and says the external proving market is not yet built. Internal +reward distribution demonstrates the mechanism; repeat purchases by outside customers would +demonstrate demand. + + +What separates “top-tier technology” from “the leading +network”? +I would look for three outcomes. +Miners stay through difficult conditions. Not because the launch is temporarily lucrative, but because +hardware compatibility, operating costs, payouts and control remain attractive. +Customers repeatedly pay for the output. Not subsidised pilots or partnership announcements: useful work +purchased at prices that support reliable service and operator margins. +The network works without the founding team holding it together. Independent operators build the +software, enforce the rules, survive failures and continue operating without emergency intervention. +Those would be my tests for leadership. A small specialist-hardware advantage alone would not establish +any of them. + + + + +IGNEUM 2.0 / 08 OCT 2026 32 / 37 + STRATEGY / 2.0 + + + + +My direct answer +The ceiling is category leadership. Successful, independently validated execution would put Igneum in +serious contention for the top of the GPU-mining space on engineering and operator proposition. +But I would not give it an unsupported “number one” ranking before comparative results and real-world +adoption exist. +The progression I would expect is: +Demonstrated technical advantage → credible top-tier project → repeat customer demand and miner +retention → potential category leader. +You have a plausible route to the top. The decisive move is now to prove that ordinary operators can +succeed on the system - not to make the design sound more ambitious. + + + + +IGNEUM 2.0 / 08 OCT 2026 33 / 37 + STRATEGY / 2.0 + + + +APPENDIX B / SUPPLIED DOCUMENT + + + +EVM and proving architecture. +Complete second section of the supplied document, in its original order. + +Retained from IGNEUM 2.0.rtf. Proposed architecture and source-snapshot qualifications are preserved. + + + + +Yes - EVM-compatible applications with ZK-proven execution are the right default for Igneum. But I would +position and build it as a GPU-secured L1 with a flexible proving layer, not simply “another zkEVM chain.” +The architecture I would choose is: + + EVM for developers. A general-purpose zkVM for proving. Igneum’s own consensus for security. + External customers for additional proving demand. + +Those choices fit together, but they are not the same decision. + +1. Separate the three architectural choices + + M Y RECOMMENDATION FOR + D ECISION W HY + I GNEUM + + + Let builders use familiar contracts, + What developers build + EVM-compatible execution languages and tools rather than requiring + against + them to learn a new application platform. + + + Prove the EVM implementation without + An established general-purpose + developing an entirely new proof system + How execution is proved zkVM, initially your SP1-based + yourselves. Preserve a carefully versioned + implementation + replacement path. + + + This preserves your actual objective: an + Where the network Your sovereign GPU-mined L1, independent network secured by + obtains consensus and subject to the security gates we accessible hardware, rather than a proving + finality discussed service attached to someone else’s + settlement system. + + +Your litepaper already points broadly in this direction: it identifies revm for EVM execution and SP1 behind a +versioned proving interface. I would refine that architecture rather than restart it. +A zkVM and a zkEVM are not competing choices here. SP1 proves programs compiled for RISC-V; one such +program can implement EVM execution. Succinct’s RSP project demonstrates this composition using Reth +and SP1, although that repository explicitly warns that it is not audited or production-ready. + +2. Why EVM is a sensible application layer +I would not make attracting developers harder while you are already solving difficult mining, consensus and +proving problems. +EVM compatibility lets developers reuse familiar languages and infrastructure. Ethereum’s documentation +identifies precisely that benefit: applications can use established tooling while gaining proof-based +verification. + + + +IGNEUM 2.0 / 08 OCT 2026 34 / 37 + STRATEGY / 2.0 + + + +For Igneum, my preferred developer experience would be: + + “Deploy familiar contracts, understand a small, clearly documented set of differences, and obtain + verifiable execution.” + +That is a stronger starting point than asking developers to adopt a new language, wallet model, execution +environment and security model simultaneously. +However, compatibility needs to be demonstrated, not described as “everything runs unchanged.” Your +ledger already acknowledges differences in block context, randomness and two-dimensional fees. Those can +matter to application behaviour even where the bytecode executes successfully. +I would therefore make compatibility testing a product deliverable: representative contracts, wallet fee +estimation, indexing, failed transactions, receipts and application-specific assumptions. + +3. ZK-proven execution is also aligned with where the technology +is going +This is not a case of choosing an architecture whose only purpose is Ethereum rollups. +The Ethereum Foundation’s current zkEVM programme is working towards proof-based verification of +Ethereum’s own L1 execution, beginning with optional execution proofs and aiming later for mandatory +proofs. Its approach explicitly involves general-purpose zkVMs. +That supports your architectural direction: +Keep a familiar application environment, while changing how execution is verified. +It does not establish that Igneum’s implementation is secure or that customers will choose it. It does mean +you can build on a substantial shared engineering direction rather than invent every component. +My recommendation is to benefit from that work while concentrating your own effort on what is distinctive: +accessible operators, distributed proving, reliable payments and the GPU-mined base layer. + +4. I would not turn Igneum into an Ethereum L2 by default +Using EVM execution and ZK proofs does not require moving Igneum “onto Ethereum.” +A conventional Ethereum ZK-rollup uses Ethereum to enforce state updates and make the necessary state- +reconstruction data available. That is a different security and settlement arrangement from operating a +sovereign L1. +An L2 could be the better choice for a project whose primary objective was Ethereum settlement and an +Ethereum-facing application. But it would not automatically be a better implementation of your objective: an +independent, durable home for GPU operators. +There is a real cost to choosing sovereignty: you must establish your own consensus security, data +availability and credible cross-chain verification. Adding execution proofs does not make those +responsibilities disappear. +My preferred commercial relationship is: + + Serve Ethereum and other networks without requiring Igneum to become subordinate to one of + them. + +Customers should be able to purchase supported proofs for their existing systems. Requiring every customer +to migrate its application to Igneum would unnecessarily narrow the business. + + + + +IGNEUM 2.0 / 08 OCT 2026 35 / 37 + STRATEGY / 2.0 + + + + +5. The proving business should be broader than your own zkEVM +This is the most important strategic refinement. +Make EVM the main application interface, but do not make EVM execution the only useful work your proving +infrastructure can eventually support. +A general-purpose zkVM gives you a potential route to additional verifiable workloads. It does not make +every proof format interchangeable: each supported service still needs its own validated program, inputs, +verification rules, performance measurements and delivery requirements. SP1’s general-purpose execution +model supports that broader direction. +I would start narrowly: +First: reliably prove Igneum’s own execution. +Next: support one external customer’s exact workload, with repeat paid jobs. +Then: add further workloads where the existing operator fleet has a demonstrated advantage. +Your economics page still describes the external proving market as unbuilt. That is an opportunity to shape +correctly - not established demand that should already be included in revenue assumptions. +Igneum should not need to win a contest for the largest application ecosystem before its operators can sell +useful computation. + +6. The conditions that make this the right choice +I would keep this architecture only while enforcing four requirements. + +Proofs must become a protocol guarantee +Your ledger currently states that proof verification occurs outside the consensus path in proving v0; a +modified producer can include a matching statement without the valid proof and cause an undeserved +payout. +Closing that gap is essential. Otherwise, the network is demonstrating proving activity rather than enforcing a +permissionless proving economy. + +The hardware requirements must match the miner promise +The litepaper currently distinguishes NVIDIA proving from AMD and Apple mining support. That is an +important limitation to preserve in the product language. +I would judge the proving stack on the complete pipeline: inputs, proving, aggregation, verification, payment, +memory footprint and mining income forgone. +A fast shard result is not sufficient when aggregation or memory pressure makes ordinary operators +uncompetitive. + +Proof-system flexibility must not become arbitrary acceptance +Keep the implementation replaceable, but pin the permitted program identities, verifier versions and security +parameters in the protocol. +My recommendation is one well-tested backend first, a clean replacement interface, and independent +implementations where justified later - not several immature backends accepted interchangeably. +The Ethereum Foundation’s security work emphasises that proving speed is insufficient without soundness +analysis and appropriate security margins. That is directly relevant to deciding which optimisations and +versions Igneum can safely adopt. + +Proving must not become the authority to control the chain +I would preserve your separation between winning the mining lottery and producing proofs. + + +IGNEUM 2.0 / 08 OCT 2026 36 / 37 + STRATEGY / 2.0 + + + +But also test whether a concentrated proving provider could stall useful operation by withholding service. +The design needs replacement operators, usable inputs, reassignment and explicit behaviour during proof +delays. +Separate responsibilities on paper are not enough; they must remain separable during a failure. + +7. What “zkEVM” should - and should not - mean in your +positioning +I would not lead with: +“We are another zkEVM.” +I would lead with: + + “A GPU-secured network for Ethereum-compatible applications and verifiable computation.” + +Then explain the proof architecture underneath it. +Also keep three boundaries explicit: +Proven execution is not automatically finality. +EVM compatibility is not Ethereum security. +ZK technology does not automatically make transactions private. Ethereum’s rollup documentation explicitly +notes that published state-reconstruction data is public; privacy requires additional application or protocol +design. +And none of these choices, by itself, solves specialised-hardware competition. Your mining-resistance +programme remains a separate obligation. + +My judgement +Yes: stay with EVM-compatible, ZK-provable execution. I would not switch to a new application VM, develop +a bespoke proof system, or convert Igneum into an Ethereum rollup just to follow a category label. +The strongest architecture for your stated purpose is: + + A sovereign GPU-mined L1, familiar EVM applications, an established and versioned zkVM proving + engine, and a proving service capable of serving customers beyond Igneum. + +EVM is the right front door. Verifiable computation is the broader opportunity. Keeping ordinary operators +competitive is the differentiator you still have to prove. + + +END OF SUPPLIED SOURCE + +The original document is preserved in full across appendices A and B. + + + + +IGNEUM 2.0 / 08 OCT 2026 37 / 37 + \ No newline at end of file diff --git a/docs/plans/igneum-2.0.md b/docs/plans/igneum-2.0.md index 7a4bb1e72..7e8329e4c 100644 --- a/docs/plans/igneum-2.0.md +++ b/docs/plans/igneum-2.0.md @@ -144,3 +144,59 @@ Owner: site lane. | Secure execution, finality and independently operated infrastructure | Developers and customers trust the network with meaningful activity | Each row is served only with its evidence beside it. What stops number one: losing on customer acquisition, developer adoption, operator economics or reliability; and GPU competitiveness is a contested claim (Ravencoin states it already), so the site shows a better result, never a more ambitious description. + +## Addendum from the complete plan (IGNEUM_2.0_Plan_Light.pdf, 8 October 2026, 37 pages) + +The PDF is the complete reference and supersedes the .rtf where they differ; both are kept beside this file (igneum-2.0-plan.pdf, igneum-2.0-plan.txt). These pins were missing above. + +### Evidence classes and status discipline (plan p. 5, 25, 27) +- [ ] Every served claim carries one label: TEAM-REPORTED, MODELLED, PROPOSED, PENDING or EXCLUDED. Status words are distinct and never collapsed: designed, implemented, activated, team-tested, independently reproduced, independently reviewed. +- [ ] Public wording ladder, each rung with what supports it: "designed for GPU competitiveness" (objective and rationale only); "team-tested" (published procedure, version, result); "independently reproduced" (an unaffiliated operator); "independently reviewed" (a scoped review with its unresolved findings); "top-tier contender" (comparative evidence plus operating and customer proposition); "category leader" (sustained adoption, demand, reliability, retention; never a numerical rank). +- [ ] Claims never published: guaranteed chip death, a universal ASIC-efficiency ceiling, chip-arrival probabilities without a calibrated model, guaranteed profits, Ethereum security by compatibility, privacy from ZK. +- [ ] Release evidence packet beside every material claim: source commit, exact parameters, test procedure, raw result, independent-reproduction status, review scope, unresolved limitations. + +### Decision register additions (p. 7) +- [ ] Also excluded, kept as controls: SM gating, wider reads, sealed classes, random epoch lengths, per-tier scoring, VRF draws. The long-program result stays rejected when instruction memory is modelled as shared SRAM, not flip-flops. +- [ ] The one acceptance rule for any hash change: it passes only when the best adversarial implementation becomes worse relative to the best practical GPU implementation, within pre-agreed cost and verification limits. +- [ ] Accepted work includes rejected submissions, downtime, epoch preparation, compilation, host power and network delays. + +### Rotation mechanisms (p. 11) +- [ ] Miner-voted bring-forward is specified as a mechanism: activation rule, coalition behaviour, partition handling, old-client behaviour. "No veto" is a mechanism, not a label. +- [ ] Seed and VDF pipeline: the seed-selection property it protects is stated, and behaviour when finality is unavailable at a seed boundary is defined and tested. + +### Independent hardware brief (p. 12) +- [ ] The adversary's transition matrix, each row a required result: firmware update (throughput, energy, cost before and after each family transition); emulation (penalty for missing native operations; slower is not unprofitable); memory expansion or overprovisioning (board cost, bandwidth, power, survival through the dataset schedule); companion CPU, GPU or FPGA (complete-system economics including hybrid mining and proving); favourable-period mining (revenue after idle, re-entry, difficulty response); silicon revision (incremental cost, reused design work, realistic delay). +- [ ] Evidence standard: realistic SRAM macros, ports, wiring, memory interfaces, switching activity, complete-board overhead; same-node and advanced-node results kept separate; uncertainty ranges published. +- [ ] The lifetime rule: a capable programmable design survives several epochs; a retirement benefit is awarded only when the cheapest adaptation loses economic competitiveness. +- [ ] The disclosure prize rewards a better adversary and a reproduced shortcut, not confirmatory results. + +### Coexistence economics additions (p. 13) +- [ ] Scenario axes include market structure: private supply, public hardware sales, multiple suppliers, concentration. +- [ ] The USD 340 M and USD 23 M thresholds and the USD 20 to 75 M development range live in a sensitivity workbook with their assumptions, never as served boundaries. + +### Miner and operator experience (p. 14) +- [ ] Desktop-first, a mining console. Easy entry: install, hardware detection, compatibility explanation, safe default tuning. Honest economics: mining, internal proving and external proving income shown separately, net of the operator's entered electricity tariff. Control: power limits, pause and stop, job selection, explicit acceptance of software updates. Failure visibility: rejected work, failed proofs, queue delays, memory pressure, missed payments visible and actionable. Accessible payouts: non-custodial, practical for small operators. Safe execution: proving isolated from wallet secrets and signing authority; security assumptions published. +- [ ] Hardware profiling lives in the client, never as consensus privilege. + +### Proving correctness (p. 16) +- [ ] The negative test set every validator passes: correct statement with an invalid proof (rejected, no reward); wrong program or verifier identity; wrong chain, epoch or statement binding (replay); changed payout identity; duplicate proof reward; incorrect rewards or consensus inputs (derivation authenticated, not only execution). Each mapped to a test in the enforced-proving set with its version. +- [ ] Boundary served: a proof of execution is not a proof of authenticated consensus inputs, canonical history or data availability. + +### Consensus and failure behaviour (p. 19) +- [ ] D5 scenario rows: prolonged partition (no conflicting final histories inside the fault assumptions; liveness loss explicit); authority-set transition (verifiable continuity from the last certified history; a timeout alone is not evidence missing voters are gone); signing stops while mining continues (defined checkpoint, weight and recovery; no contradictory certificates); old voting keys compromised (its own analysis, distinct from new hashrate); finality unavailable at a seed boundary (a seed and mining path that does not depend on an unavailable certificate); partitions reconnect (deterministic recovery, no quiet reversal of an irreversible label). +- [ ] The real integration tested together: ordering, finality, proof queues, voter tables, seed transitions. +- [ ] User-facing rule everywhere: included, executed, proven and finalised are four states; a safe pause is shown as a pause. + +### User verification (p. 20) +- [ ] Light wallet: starting point, voter weights and authority changes authenticated. Execution proof: the permitted proof verified and its inputs authenticated, never an aggregator statement in its place. Payment receipt: proves the transfer with asset, recipient and amount, or is labelled "transaction-inclusion receipt". Oracle: deployer-installed trust anchors removed or disclosed, unchecked signatures named. Data availability: how state is obtained and reconstructed, explained. + +### Operational independence (p. 21) +- [ ] One machine-readable release manifest: network identity, source commits, mining class, dataset parameters, finality rule, program and verifier identities, activation state, fee schedule. Status pages generate from it; historical records are labelled. +- [ ] Software release: reproducible builds, pinned source and binaries, explicit operator acceptance, a signing-key incident procedure. A fleet that auto-accepts a release key is operationally centralised. +- [ ] Public infrastructure, mining, proving and aggregation continue without founder services and without unpublished files or hidden configuration. + +### Programme order, mainnet prerequisites, funding (p. 24, 26) +- [ ] Spend order: proof enforcement and finality boundaries first while closing the v6 evidence packet; hardware research and one narrow paid pilot in parallel; broad ecosystem expansion waits until the core path is secure, reproducible and useful. +- [ ] Mainnet needs: complete proof enforcement, a resolved finality and recovery model, operator-control tests, the compatible-application test suite, a funded maintenance plan (engineering, audits, infrastructure, incident response), committed funding distinguished from adoption-dependent income; fair launch is a principle, not a funding strategy. +- [ ] Acceptance scorecard served as a checklist with its "do not substitute" column (plan p. 25), never as a completion dashboard. +- [ ] Brand kit stands: Unbounded, IBM Plex Sans, IBM Plex Mono; obsidian, ember, graphite, bone, molten.