Igneum 2.0: the founder's reference (docs/plans/igneum-2.0-reference.txt) and the plan with the pins (docs/plans/igneum-2.0.md), decided 8 October 2026; landed from the Mac checkout, byte-identical

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/plans/igneum-2.0-reference.txt

@@ -0,0 +1,132 @@
+INGEUM 2.0 


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
+Area
+My assessment of the proposed end-state
+Keeping ordinary GPUs competitive
+A potential leadership position, provided independent hardware analysis confirms the result against programmable, multi-epoch competitors.
+Quality of the resistance evidence
+A major strength if you publish reproducible measurements, realistic adversarial designs and economics that do not assume chips automatically expire.
+Miner experience
+Potentially top-tier: straightforward installation, effective tuning, transparent earnings, reliable payouts and retained control.
+Usefulness of the hardware
+A compelling proposition if the same accessible hardware can earn from genuinely purchased proving work as well as securing the chain.
+Security and decentralisation
+A credible contender after independent review and failure testing—not something a feature list establishes.
+Miner profitability and market leadership
+Still dependent on demand, competition, liquidity and operating costs. 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.
+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.
+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.
+


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
+Decision
+My recommendation for Igneum
+Why
+What developers build against
+EVM-compatible execution
+Let builders use familiar contracts, languages and tools rather than requiring them to learn a new application platform.
+How execution is proved
+An established general-purpose zkVM, initially your SP1-based implementation
+Prove the EVM implementation without developing an entirely new proof system yourselves. Preserve a carefully versioned replacement path.
+Where the network obtains consensus and finality
+Your sovereign GPU-mined L1, subject to the security gates we discussed
+This preserves your actual objective: an independent network secured by accessible hardware, rather than a proving 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.  
+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.
+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.
+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.

docs/plans/igneum-2.0.md

@@ -0,0 +1,146 @@
+# Igneum 2.0
+
+Decided 8 October 2026, 17:45 BST. The testnet is held (go cut acaf08b0 never ran; the three seeds idle for D5). Devnet 3 is the network. The miner line restarts at v2.0.0. Everything below is a pin: a box, an owner, a pass condition. A pin closes only with a landed document and the pass condition met, never with a plan.
+
+## The objective
+
+Durable GPU competitiveness, not chip destruction. Four properties, all holding without assuming a future emergency algorithm change:
+
+1. A specialised miner cannot remove much cost without losing substantial performance.
+2. Ordinary operators can obtain competitive hardware, software and access to rewards.
+3. Mining and proving stay economically sustainable as the network grows and issuance falls.
+4. The above hold with no rescue upgrade assumed.
+
+A manufacturer with a profitable product is not the failure. An exclusive, durable advantage large enough to displace the accessible GPU fleet is. The target is contestable mining.
+
+Positioning line (served text, every page): "A GPU-secured network for Ethereum-compatible applications and verifiable computation." Never "another zkEVM". Three boundaries stated wherever the proof architecture is explained: proven execution is not finality; EVM compatibility is not Ethereum security; ZK is not privacy.
+
+## Standing rules carried in (do not re-decide)
+
+- [ ] More layers is not more resistance. A smaller generator whose every accepted program is strong beats a larger one with occasional weak programs.
+- [ ] Rejected knobs (long programs, select trees, W=8/W=32, SM count, memory clock) stay out and stay as regression controls. Never resurrected under new names.
+- [ ] The adversary is re-optimised after every change. Synthesis k is never a lower bound; placed rows score.
+- [ ] GPU-cost budget is set before results (10 percent at the lock). No ratio is bought with honest GPU energy.
+- [ ] "Every chip dies within a family epoch" is out of the baseline economic model. Chip-arrival percentages are not published.
+- [ ] No ASIC detection in consensus. No hardware whitelists, attestation, per-address quotas or self-reported GPU bonuses.
+- [ ] Rotation is optional to the security argument. Seed delay is evaluated only as seed-selection protection.
+- [ ] Energy advantage, economic advantage and response capability are reported separately. Cohort = the discrete-GPU population, used cards included.
+- [ ] Mining resistance, proving competitiveness and system stability are three questions with three answers.
+
+## D1. A frozen, reproducible baseline
+
+Owner: coordinator (Counter ASIC 3.0) with the hash lane and the node lane.
+
+- [ ] One exact generator, verifier, dataset policy, compiler configuration and measurement harness, pinned by digest and served.
+- [ ] Pending measurements closed: placed 64-register rows, PC 1 lock row, 5.5 GiB coexistence rows.
+- [x] Mixed FP32 branch: KILL 8 Oct 16:3x. Deterministic FP32 costs the cards 15 to 26 percent energy per hash against a 10 percent budget (four fifths of it the integer masking that keeps the FP unit deterministic) and the chip's edge grows to 3.0x to 3.2x because that masking is ARX work it pays at the floor. Document: docs/analysis/class-v6/mixed-fp32.md. Regression control, never resurrected.
+- [ ] Mining and proving measured together on the final configuration, not combined on paper.
+- [ ] Wall power alongside device telemetry; accepted work, rejected work, compile time, memory use, sustained thermals.
+- [ ] Reference GPU population published: several vendors, memory sizes, generations, used cards (5090, 5080, 4090, 3090, 9070 XT, RX 7600 8 GB, Arc, Apple).
+- [ ] Two tests per class: existing owner (power, wear, fees, alternative use) and new entrant (purchase, operating, resale).
+- [ ] Central measure served: cost per accepted unit of work = (annualised hardware + power + hosting, failures, fees) / annual accepted work.
+- Pass: an independent operator reproduces the baseline within declared tolerances from the served kit alone.
+
+## D2. Two architectural experiments, not twenty knobs
+
+Owner: class v6 invention lane (a) and the multi-family adversary lane (b).
+
+- [x] (a) Reorganise existing work for unavoidable live state and resource coupling, counts held constant. RESULT 8 Oct 17:25: KILL as a class. Only the window width reaches the chip (+1.2 pJ per lane-op at N5); rearranging the dependency graph of the same ops moves neither side. Document: docs/analysis/class-v6/connected-state.md. The generator variant and liveness tool stay behind a flag.
+- [ ] (b) Attack memory sharing, recomputation and data-local execution against v6 (ProgPoW review threat: dataset split across processors, compute moved to the data). Price the cheapest combination of moving state, moving data, recomputing and local resources, not the expected architecture.
+- [ ] Cumulative memory complexity and bandwidth hardness mapped onto the actual evaluation across many hashes (shared datasets, partial caches, recomputation, multiple engines amortising setup). Which trade-offs are bounded, which rest on physical-design experiments.
+- [ ] Selective participation: distribution of the specialist's advantage across programs and epochs, not the mean; downtime, difficulty adjustment, re-entry included.
+- [ ] Cryptographic review of the template, nonce, expensive work and result binding: no expensive intermediate reused across cheap winning attempts.
+- Pass: the candidate improves against re-optimised adversaries across the declared population within the preset cost and verification limits. Otherwise v6 stands and the experiment is published as a failure.
+
+## D3. A programmable adversary allowed to survive
+
+Owner: multi-family adversary lane with the k lane (shadow k from RTL).
+
+- [ ] Whole-system cost minimised across every published family, free to change lane count, register implementation, instruction storage, memory technology, scheduling and support hardware.
+- [ ] Physical implementation (placed), not logic synthesis. Uncertainty published with every row.
+- [ ] Three-year stress life for the programmable chip; survival across the family bank assumed.
+- [ ] Next-generation opponents in the matrix: programmable compute without graphics (Vortex class), chiplets and 3D packaging (UCIe), denser external memory (24 Gb GDDR7 boards), data-local hybrids, proof accelerators (PipeZK class), an operator combining mining and proving devices.
+- [ ] Dataset schedule (5.5 / 8.5 / 11.5 GiB) scored per step: adversary burden against commodity burden (cards excluded, mine-and-prove lost, replacement cost). A step that hurts ordinary operators more than an adaptable adversary is rejected. Default: epoch-defined bounded dataset with a conservative published support horizon.
+- [ ] State coupling of the dataset justified or dropped after sync, recovery, storage and adversarial state-growth costs.
+- Pass: the best supported cost and energy advantage sits inside the chosen competitiveness envelope, with uncertainty published. 1.5x energy is a research goal, not the pass criterion.
+
+## D4. A five-year coexistence model
+
+Owner: research lane (economics), with the k lane's rows as input.
+
+- [ ] Replaces the capex wall. Mandatory stress case: development already paid for; the opponent covers manufacturing, deployment and operation only.
+- [ ] Growing and shrinking networks, reduced issuance, cheap and dear electricity, GPU replacement and resale on both sides, changing proving demand, private mining and hardware sales, several productive lifetimes, cheaper derivative chips.
+- [ ] Miners react: no fixed market shares.
+- [ ] Outputs: cost advantage, replacement economics, accessible supply, break-even electricity price per class, supplier and operator dependence.
+- [ ] Tariff advantage shown separately from hardware advantage (the 6.25x illustration).
+- [ ] Economics page: the tip-share discrepancy resolved; explicit user-funded proving payment with congestion pricing, burn treated separately; hard cap and no development tax kept.
+- [ ] Profit-maximising operator simulation: mine, internal prove, external prove, off; under a proving demand spike, a token price fall, a major prover leaving, a specialised entrant in either market. Pass if pricing and capacity rules restore service without an administrator.
+- Pass: the model names credible conditions for sustained commodity participation and names where it fails. A result needing a small network, token appreciation or scheduled ASIC death has not passed.
+
+## D5. A no-rescue network exercise
+
+Owner: node lane with the build-server lane (the three ex-testnet seeds are the start).
+
+- [ ] Prerequisite: proof verification enforced in consensus (verifier_in_consensus, proof_rule_active_from) live on the exercise network.
+- [ ] No founder-operated mining, proving, aggregation or mandatory distribution infrastructure.
+- [ ] Cross epoch boundaries, interrupt signing, partition the network, remove major operators, hostile proof submissions, independently written clients.
+- [ ] A withholding concentrated prover: replacement operators, usable inputs, reassignment, explicit behaviour during proof delays.
+- Pass: specified behaviour with no emergency algorithm change and no privileged intervention.
+
+## Pools, software and participation (launch requirements)
+
+Owner: pool lane.
+
+- [ ] Vote keys stay with the miner at protocol level: the member's retained voting key committed into its work, payment aggregation separate, verifiable, pool identity substitution resisted.
+- [ ] Non-custodial payouts, practical minimum payouts, local work verification, low-bandwidth participation (P2Pool as precedent, not code).
+- [ ] Accepted-work penalty measured for home internet against datacentre connections.
+- [ ] Optimisation work, compiler settings and safe tuning logic published; Ember reaches good operating points without third-party software.
+
+## Architecture and product (review 2)
+
+Owner: node lane (protocol), reference-apps lane (compatibility), second-prover lane (backend policy), site lane (positioning).
+
+- [ ] EVM-compatible execution for developers (revm); SP1 as the one well-tested proving backend behind the versioned interface; sovereign GPU-mined consensus. Not an Ethereum L2.
+- [ ] Program identities, verifier versions and security parameters pinned in the protocol. One backend first; a second only where justified, never interchangeable immature backends.
+- [ ] Compatibility as a product deliverable: representative contracts, wallet fee estimation, indexing, failed transactions, receipts, application assumptions; the documented set of differences (block context, randomness, two-dimensional fees).
+- [ ] Hardware language kept honest: NVIDIA proving against AMD and Apple mining; the full pipeline judged (inputs, proving, aggregation, verification, payment, memory, mining income forgone).
+- [ ] Proving business ladder: own execution; one external customer's exact workload with repeat paid jobs; further workloads only where the fleet has a demonstrated edge. The external market stays out of revenue assumptions until built.
+- [ ] Every served page carries the positioning line and the three boundaries; "zkEVM" appears only under the architecture explanation.
+
+## Versioning
+
+- [ ] Miner v2.0.0 cut from the 0.3.26 line with the audit's window rebuild, the 2.0 served text and the baseline kit digest. Three-part versions, canary gate, one-box rollout, commit-string read-back, as before.
+- [ ] Node 2.0.0 follows once D5's prerequisite (enforced proving) is on Devnet 3.
+
+## Leadership tests (review 3)
+
+Owner: main. These are the tests the site may claim progress against, never completion without the evidence.
+
+- [ ] Benchmarks published against operating systems, not whitepapers: Ravencoin KAWPOW (same stated objective), Ergo (GPU memory-hard, live pooling and emission changes), Firo's reference miner (NVIDIA and AMD, no developer fee, within about 1 percent of closed miners: the bar Ember meets or beats).
+- [ ] Miners stay through hard conditions (compatibility, operating cost, payouts, control), measured, not launched.
+- [ ] Customers repeatedly pay for proofs at prices that carry reliable service and operator margin. Pilots and announcements do not count.
+- [ ] The network runs without the founding team: independent clients, rule enforcement, failures survived, no emergency intervention (D5).
+- [ ] Served ranking language: "serious contention for the top of the GPU-mining space on engineering and operator proposition" is the ceiling; no "number one" claim before comparative results and adoption exist.
+
+## Site reset
+
+Owner: site lane.
+
+- [ ] The served site starts at Igneum 2.0: no 0.x release history, no changelog before 2.0, no Counter ASIC 2.0 / 3.0 / 4.0 names, no testnet pages or links, no old-version evidence rows, no status-log history.
+- [ ] The pre-reset site is tagged site-pre-2.0 on the box mirror; the repo keeps everything, the site serves none of it.
+- [ ] Devnet 3, the explorer, the faucet and the reference apps stay: they are the network, not history.
+- [ ] Every page carries the positioning line; the miner page serves v2.0.0 when it is cut and nothing older.
+- [ ] The facts page is wiped: it restarts with only 2.0 facts, each traceable to a landed document.
+- [ ] The FUD ledger is written fresh against this brief: every entry names the pin it answers; the old ledger and its decisions stay in the repo as history and are not served or linked.
+- [ ] Copy sweep beyond the site: the litepaper and the apps (miner, wallet, Windows host, HiveOS card) are edited to the 2.0 reference where the text differs from it (positioning line, three boundaries, EVM + SP1 + sovereign consensus stated as three decisions, NVIDIA proving against AMD and Apple mining stated plainly, no rotation-as-defence claims, no chip percentages, no 0.x history, no testnet). Dataset state-coupling in the litepaper is marked "under evaluation (D3)" until justified or dropped.
+
+## The four deliverables the site may frame itself around
+
+| What we deliver | Why it matters |
+|---|---|
+| GPUs remain economically competitive against realistic specialised hardware | Miners invest without depending on emergency algorithm changes |
+| A straightforward, efficient miner with reliable payouts and retained operator control | Ordinary owners participate successfully, not only mining businesses |
+| Useful proofs that outside customers repeatedly purchase | Demand for a service, not enthusiasm for the coin |
+| 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.