igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

Token Value decisions ratified 9 October: the litepaper and economics page read the cap fixed with no tail emission and no vote that expands it under the pre-launch security-funding gate (D01), the schedule's pacing under comparison and not final (D02), every fee and burn route explicit with the 80/20 coinbase an emission allocation only and external-job charges not yet set (D04); the explorer pages' recovery lock never shown as final (D05); the leadership line cites D06; a ratified decision is a rule, not a promise of value

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-09 08:16:25 +00:00
parent 66f6749d45
commit 57dfdbac48
13 changed files with 22 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/fud-ledger-2.0.md
View file

@ -298,7 +298,7 @@ Pin: Leadership tests, first box (Ergo).
Status: Conceded (8 October 2026): no "number one" claim before comparative results and adoption exist.
Answer: No present-tense rank is served. Published claims name the evaluated release, evidence and boundary conditions. Designed to compete for leadership among GPU-first networks. That is the scoped wording until a ranking is measured (the Token Value volume’s rule VR-30, scoped claims only, 9 October 2026): an independently substantiated pass of the acceptance standard would not award a numerical rank, nor guarantee adoption, perpetual GPU profitability or the defeat of every future chip. The tests that would earn it are miners staying through hard conditions, customers repeatedly paying for proofs, and the network running without the founding team (D5); none is met yet.
Answer: No present-tense rank is served. Published claims name the evaluated release, evidence and boundary conditions. Designed to compete for leadership among GPU-first networks. That is the scoped wording until a ranking is measured (the Token Value volume’s rule VR-30 and decision D06, scoped claims only, ratified 9 October 2026): an independently substantiated pass of the acceptance standard would not award a numerical rank, nor guarantee adoption, perpetual GPU profitability or the defeat of every future chip. The tests that would earn it are miners staying through hard conditions, customers repeatedly paying for proofs, and the network running without the founding team (D5); none is met yet.
Evidence: `docs/plans/igneum-2.0.md` (Leadership tests, second to fifth boxes).

2
site/address.html
View file

@ -291,7 +291,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
<div class="tbl"><table><thead><tr><th>Block</th><th class="n">Number</th><th class="n">DAA</th><th class="n">Blue score</th><th>Colour</th><th class="n">Subsidy</th><th class="n">Txs</th><th>Time</th></tr></thead><tbody id="blocks"></tbody></table></div>
</div>
</div>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as finalised. On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as final (the Token Value volume’s D05). On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
</main>
<!-- footer:start -->
<footer class="site-footer">

2
site/block.html
View file

@ -284,7 +284,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
<div class="card"><div class="viz-head"><h2>Shard plan and proofs</h2><div class="eyebrow" id="proof-eyebrow"></div></div><div id="proofs"></div></div>
<div class="card"><div class="viz-head"><h2>Finality</h2><div class="eyebrow" id="fin-eyebrow"></div></div><div id="finality"></div><div id="recheck"></div></div>
</div>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as finalised. On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as final (the Token Value volume’s D05). On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
</main>
<!-- footer:start -->
<footer class="site-footer">

2
site/claims.html
View file

@ -263,7 +263,7 @@
<li><strong>Proof verification in consensus.</strong> On the Igneum 2.0 devnet, yes, from block zero (verifier_in_consensus set, the node's own start line; running since its first block at 17:14 UK on 8 October 2026). It is the prerequisite of the no-rescue network exercise (Deliverable 5), which is still owed; an earlier devnet ran with the rule off.</li>
<li><strong>Proving on every card.</strong> No. NVIDIA proves; AMD and Apple mine. The proving stack is judged on the full pipeline: inputs, proving, aggregation, verification, payment, memory and the mining income forgone.</li>
<li><strong>What proofs do not give.</strong> Proven execution is not automatically finality. EVM compatibility is not Ethereum security. ZK technology does not automatically make transactions private.</li>
<li><strong>A ranking.</strong> No. Igneum makes no leading or number-one claim. Published claims name the evaluated release, evidence and boundary conditions. Designed to compete for leadership among GPU-first networks. That is the scoped wording until a ranking is measured (the Token Value volume’s rule VR-30, scoped claims only): an independently substantiated pass of the acceptance standard would not award a numerical rank, nor guarantee adoption, perpetual GPU profitability or the defeat of every future chip. Benchmarks against Ravencoin’s KAWPOW, Ergo and Firo’s reference miner are owed work; no result exists yet.</li>
<li><strong>A ranking.</strong> No. Igneum makes no leading or number-one claim. Published claims name the evaluated release, evidence and boundary conditions. Designed to compete for leadership among GPU-first networks. That is the scoped wording until a ranking is measured (the Token Value volume’s rule VR-30 and decision D06, scoped claims only): an independently substantiated pass of the acceptance standard would not award a numerical rank, nor guarantee adoption, perpetual GPU profitability or the defeat of every future chip. Benchmarks against Ravencoin’s KAWPOW, Ergo and Firo’s reference miner are owed work; no result exists yet.</li>
<li><strong>A finished protocol.</strong> The sustained-mining finality rule is the newest piece and the one that external review will try hardest to break. The specification, the review and the benchmarks are published as they happen.</li>
</ul>
<p>Everything in this document is subject to the gates on the roadmap. Nothing in it is an offer to sell anything. Found an error, or a criticism this document does not answer? Email <a href="mailto:hello@igneum.network">hello@igneum.network</a>, or open an issue on the public specification repository: <a href="https://git.igneum.network/igneum-network/spec/issues" rel="noopener">git.igneum.network/igneum-network/spec/issues</a>. Post reaches Igneum Labs LTD, Unit IH-00-01-01-OF-01, Level 01, Innovation One, Dubai International Financial Centre.</p></div>

6
site/economics.html
View file

@ -226,7 +226,7 @@
<tr><td>Launch rate</td><td class="num"><span data-rm="fees.emission.launch_rate_base_units_per_daa_second">31,688,087,810,000,000,000</span> base units a DAA second at 18 decimals (the literal 3,168,808,781 of <code>emission.rs</code> 104, 10<sup>9</sup> IGN x 10<sup>8</sup> / 31,557,600 floored, widened by <code>rescaled(DEVNET_DECIMALS, EVM_DECIMALS)</code> at <code>emission.rs</code> 129 in the devnet4 parameters: one billion IGN in year one, the same rate as mainnet)</td><td><code>emission.rs</code> 85 to 123; <code>igneum.rs</code> 34</td></tr>
<tr><td>Ramp</td><td class="num">2,592,000 s (30 days) from 10 percent</td><td><code>igneum.rs</code> 76 <code>launch_ramp</code></td></tr>
<tr><td>Step</td><td class="num">63,115,200 s (two years), the rate halved each step (decay 2<sup>31</sup> of 2<sup>32</sup>)</td><td><code>emission.rs</code> 85 to 123</td></tr>
<tr><td>Tail</td><td class="num">none in the code: the curve runs to zero and the sum is the hard cap, 4,000,000,000 IGN; the tail and the cap are pending decisions of the Token Value volume (D01 to D06)</td><td><code>emission.rs</code> 69 to 71</td></tr>
<tr><td>Tail</td><td class="num">none in the code: the curve runs to zero and the sum is the hard cap, 4,000,000,000 IGN; the cap is fixed with no tail emission and no vote that expands it (the Token Value volume’s D01, subject to the pre-launch security-funding gate)</td><td><code>emission.rs</code> 69 to 71</td></tr>
<tr><td>Where each runs</td><td>The Igneum 2.0 devnet (18 decimals, the rescaled schedule); mainnet (18)</td><td><code>params.rs</code> 2158, 1764</td></tr>
</tbody>
</table></div>
@ -250,13 +250,13 @@
<tr><td>Base fee, execution gas</td><td>burned in full: gas used times the execution base fee, debited and credited to no one</td><td>in the code on the devnet</td><td><code>igneum/exec/src/executor.rs</code> 320 to 371 (327 and 357, 328 and 360)</td></tr>
<tr><td>Priority fee (the tip)</td><td><span data-rm="fees.priority_fee.miner_percent">80</span> percent to the block’s miner; <span data-rm="fees.priority_fee.developer_percent">20</span> percent to the developer registrations of the contracts whose code ran, pro rata by each frame’s gas; an unregistered frame’s part is credited to nobody, which is a burn</td><td>in the code on the devnet</td><td><code>executor.rs</code> 335 to 339; <code>igneum/exec/src/pgas.rs</code> 290; <code>igneum/exec/src/config.rs</code> 76 (<code>DEVELOPER_SHARE_PERCENT = 20</code>)</td></tr>
<tr><td>The proving payment</td><td>pgas used times the proving base fee, the congestion price of proving capacity: 90 percent to the block’s proving pool, paid per shard to its provers by consensus proving cost; 10 percent burned</td><td>designed, in the code behind the constant (<code>Params::proving_payment_activation_daa</code>, never on every object, on the fork branch proving-payment); the shard guest’s mirror of the split is owed before any height; on the 2.0 devnet the proving charge burns in full</td><td>spec 05 sections 5.1 and 5.3; <code>docs/design/proving-payment.md</code> (8 October 2026)</td></tr>
<tr><td>External proving jobs</td><td>90 percent to the provers who delivered, 10 percent burned, once jobs settle in IGN</td><td>designed, not in the code: no constant exists; at launch a job is paid on the customer’s own chain</td><td>spec 05 section 5.4; the litepaper’s Proving section</td></tr>
<tr><td>External proving jobs</td><td>90 percent to the provers who delivered, 10 percent burned, once jobs settle in IGN</td><td>designed, not in the code: no constant exists; at launch a job is paid on the customer’s own chain and the charge is not yet set (D04)</td><td>spec 05 section 5.4; the litepaper’s Proving section</td></tr>
<tr><td>The provers’ part of the tip</td><td>none: no part of the tip reaches the provers; the tip stays whole to the block (spec O-5.7 closed at zero, 8 October 2026)</td><td>in the code</td><td><code>docs/design/proving-payment.md</code>; <code>executor.rs</code> 335 to 339</td></tr>
</tbody>
</table></div>
<h2>The proving-fee market</h2>
<p>A card’s second income is the proving pool: 20 percent of every block, paid per shard against a valid proof record, plus 90 percent of every block’s proving payment, which users pay at the congestion price of proving capacity (designed; on the devnet that payment is still burned in full). Nothing from the priority fee, which stays whole to the block. The reason the design routes the proving charge to the provers: the operator simulation reads a fixed internal pool as a subsidy, not a price, and only the congestion-priced user-funded fee restores service after a lasting proving spike (35 periods against never; modelled). The price a prover must charge an outside customer is the subsidy it forgoes while it proves, which falls as one over the network’s hash rate; the market itself is designed and not built. The hard cap and the absence of any development fund are unchanged in the code; both sit among the pending monetary decisions of the Token Value volume (D01 to D06).</p>
<p>A card’s second income is the proving pool: 20 percent of every block, paid per shard against a valid proof record, plus 90 percent of every block’s proving payment, which users pay at the congestion price of proving capacity (designed; on the devnet that payment is still burned in full). Nothing from the priority fee, which stays whole to the block. The reason the design routes the proving charge to the provers: the operator simulation reads a fixed internal pool as a subsidy, not a price, and only the congestion-priced user-funded fee restores service after a lasting proving spike (35 periods against never; modelled). The price a prover must charge an outside customer is the subsidy it forgoes while it proves, which falls as one over the network’s hash rate; the market itself is designed and not built. The hard cap and the absence of any development fund are unchanged: the cap is fixed (D01); every fee and burn route on this page is explicit, the 80/20 coinbase is an emission allocation only, and external-job charges are not yet set (D04).</p>
<h2>The client fee and the fund it fills</h2>
<div class="tbl"><table>

2
site/explorer.html
View file

@ -326,7 +326,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
<p class="note">Every answer names the network (the Igneum 2.0 devnet) and the chain id the node reports (4465). The RPC itself is at rpc.devnet.igneum.network (read methods and eth_sendRawTransaction, 20 requests per second per address).</p>
</div>
</div>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as finalised. On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as final (the Token Value volume’s D05). On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
</main>
<!-- footer:start -->
<footer class="site-footer">

2
site/ledger.html
View file

@ -446,7 +446,7 @@ blockquote{margin:10px 0;padding:10px 14px;border-left:3px solid var(--line-2);c
<blockquote>You claim to be the best GPU network before anyone outside has checked anything.</blockquote>
<div class="status"><span class="badge b-conceded">Conceded</span> <span class="did">8 October 2026): no &quot;number one&quot; claim before comparative results and adoption exist.</span></div>
<div class="pin"><b>Pin</b> Leadership tests, fifth box (served ranking language); second to fourth boxes.</div>
<details><summary>The answer as first written</summary><p>No present-tense rank is served. Published claims name the evaluated release, evidence and boundary conditions. Designed to compete for leadership among GPU-first networks. That is the scoped wording until a ranking is measured (the Token Value volume’s rule VR-30, scoped claims only, 9 October 2026): an independently substantiated pass of the acceptance standard would not award a numerical rank, nor guarantee adoption, perpetual GPU profitability or the defeat of every future chip. The tests that would earn it are miners staying through hard conditions, customers repeatedly paying for proofs, and the network running without the founding team (D5); none is met yet.</p></details>
<details><summary>The answer as first written</summary><p>No present-tense rank is served. Published claims name the evaluated release, evidence and boundary conditions. Designed to compete for leadership among GPU-first networks. That is the scoped wording until a ranking is measured (the Token Value volume’s rule VR-30 and decision D06, scoped claims only, ratified 9 October 2026): an independently substantiated pass of the acceptance standard would not award a numerical rank, nor guarantee adoption, perpetual GPU profitability or the defeat of every future chip. The tests that would earn it are miners staying through hard conditions, customers repeatedly paying for proofs, and the network running without the founding team (D5); none is met yet.</p></details>
</article>
<p class="intro" style="margin-top:var(--sec)">Source: the project's Igneum 2.0 criticism ledger, a file in the repository, rendered to this page at build time. A criticism that is not here, or that shows an entry is wrong, is added with credit if wanted: <a href="mailto:hello@igneum.network">hello@igneum.network</a> or <a href="https://git.igneum.network/igneum-network/spec/issues" rel="noopener">an issue on the specification repository</a>.</p>

16
site/litepaper.html
View file

@ -303,7 +303,7 @@ body.all .pager{display:none}
</div>
<div class="meta">
<span>Published <b>3 October 2026</b> · updated <b>8 October 2026</b></span>
<span>Coin <b>IGN</b> · cap <b>4,000,000,000</b> (a decision pending)</span>
<span>Coin <b>IGN</b> · cap <b>4,000,000,000</b> (fixed, D01)</span>
<span>Status <b>The Igneum 2.0 devnet is live</b></span>
<span>Method <b>one founder with AI systems</b> · external review before gate 3</span>
<span>This is not an offer to sell anything</span>
@ -361,7 +361,7 @@ body.all .pager{display:none}
<tr><td>The mining card does paid, useful, verifiable work</td><td>Primecoin's prime chains in 2013 were not useful. Aleo ran proving as consensus and the fastest prover won (both approximate)</td><td>Proving kept apart from the lottery; shards assigned by sortition, not by speed</td><td>Implemented: proving v0 and v1 on the devnet from block zero, on NVIDIA cards. The job market for other chains is Designed</td></tr>
<tr><td>A proof-of-work chain where every block is proven</td><td>Proven-execution EVM chains run as rollups on proof-of-stake Ethereum. Conflux has run GPU-mined EVM apps on a DAG since 2020, without proofs (approximate)</td><td>Proven state on a proof-of-work base layer, produced by the miners themselves</td><td>Implemented: shards proven and paid on the devnet; proof verification enforced in consensus from block zero on the Igneum 2.0 devnet (running since 17:14 UK on 8 October 2026)</td></tr>
<tr><td>Finality held by miners and not moved by hour-long rentals</td><td>Decred votes with stake. Horizen penalises hidden chains. Kaspa limits merge depth (approximate)</td><td>Vote weight is 30 days of blocks per key. Hashrate that appeared today has no vote</td><td>Implemented: rule v3 live on the devnet from block zero. External review is owed at gate 3</td></tr>
<tr><td>100% of emission to the people running the hardware</td><td>Kaspa's fair launch. Zcash and Decred fund developers from emission (approximate)</td><td>No fee to any team, foundation or fund in the protocol. The miner software's optional 1% dev fee is the one payment to the project, off with one flag</td><td>Implemented in consensus: the 80/20 coinbase on the devnet</td></tr>
<tr><td>100% of emission to the people running the hardware</td><td>Kaspa's fair launch. Zcash and Decred fund developers from emission (approximate)</td><td>No fee to any team, foundation or fund in the protocol. The miner software's optional 1% dev fee is the one payment to the project, off with one flag</td><td>Implemented in consensus: the 80/20 coinbase on the devnet (an emission allocation only, D04)</td></tr>
<tr><td>A chain your browser verifies by itself</td><td>Light clients trust a committee, as Ethereum's trust a sync committee (approximate)</td><td>At launch, one execution proof plus a certificate the client is given. The consensus proof that makes the checkpoint self-verifying is phase two</td><td>Designed. The home page's card verifies a devnet certificate in the browser today, with the voter list taken from a node</td></tr>
</tbody>
</table></div>
@ -533,7 +533,7 @@ body.all .pager{display:none}
<h3>The proving budget</h3>
<p>Gas prices execution. Proving cost is a different number, so Igneum meters it separately: every transaction pays in both dimensions, and each block has a proving-cost budget set in consensus from measured prover throughput. A transaction that is cheap to run and expensive to prove pays for what it costs the provers. Measured on 5 October 2026 (an RTX 5090 under SP1 6.8.1's GPU prover, the shard size the chain adopts from its fee switch, 30,000 proving gas, about 4.7 million prover cycles): one full shard proves in 4.3 seconds and needs 20.4 GB of GPU memory with the card to itself, so a 24 GB card proves full shards and a 12 GB or 16 GB card does not on this prover build, whose floor is 13.9 GB for even an empty shard; mining and proving on one card needs 32 GB today (the prototype-size shard beside the miner peaked at 30.1 GB) and 24 GB once the adopted shard size is live (22.2 GB beside the miner, 13.2 seconds a shard, measured on the 32 GB card; a 24 GB card has not run it yet). The old 12 GB gate on the roadmap was withdrawn on 5 October until a prover build with a smaller floor was measured; on 6 October a patched server proved the same shard at 7.4 to 8.0 GB alone on eleven rented cards from the RTX 3060 to the RTX 5090 (the real-card table), so the gate returns as measured and the patched server is not yet in the shipped app. The first proofs exist: on 4 October 2026 an RTX 5090 proved a small two-transaction block in 1.4 seconds (2.7 seconds compressed), verified in 0.22 and 0.038 seconds, and a laptop CPU proved a three-shard block end to end in 19 minutes. Later that day the same card proved a full shard at the provisional size, 6.75 million prover gas, which executed in 60.8 million cycles: core proof 8.3 seconds, compressed proof 10.9 seconds, verified in 0.040 seconds; a four-shard block took 44.5 seconds of GPU stages end to end. Shards are assigned and proven on the devnet from block zero. The gate asks for a mid-range card, and an RTX 5090 is not one, so the gate stands open. Once the gate is measured, the budget rises by schedule as hardware improves. The proof system is hash-based, which is what runs on consumer cards, and sits behind a versioned interface. SP1 is the one backend. A replacement is adopted only where justified, by a miner-signalled release, never as an interchangeable second backend, and the chain runs for ever on the current one if none is adopted.</p>
<h3>Proving for everyone else</h3>
<p>The job market for other chains is Designed, not built, and stays out of every revenue assumption until it is. The order: Igneum's own execution first; then one external customer's exact workload with repeat paid jobs; further workloads only where the fleet has a demonstrated edge. As designed, a customer posts a job, a miner wins it, proves it, and is paid, and the market is permissionless. At launch a job is paid on the customer's own chain, in the customer's currency, to a payout contract keyed by miner address, because Igneum cannot yet see Ethereum. Settlement in IGN, with 10% of each fee burned, follows when the proof bridge lets Igneum see the payment, in phase two. The Igneum miner client can also bid on other proving networks and take the best price, where a miner chooses to hold their collateral: Boundless provers post ZKC and Succinct provers stake PROVE (approximate, from their documentation). The proving market is small today. Igneum does not depend on it. We know of no proof-of-work chain that sells proofs to other chains.</p>
<p>The job market for other chains is Designed, not built, and stays out of every revenue assumption until it is. The order: Igneum's own execution first; then one external customer's exact workload with repeat paid jobs; further workloads only where the fleet has a demonstrated edge. As designed, a customer posts a job, a miner wins it, proves it, and is paid, and the market is permissionless. At launch a job is paid on the customer's own chain, in the customer's currency, to a payout contract keyed by miner address, because Igneum cannot yet see Ethereum. The charge itself is not yet set (D04). Settlement in IGN, with 10% of each fee burned, follows when the proof bridge lets Igneum see the payment, in phase two. The Igneum miner client can also bid on other proving networks and take the best price, where a miner chooses to hold their collateral: Boundless provers post ZKC and Succinct provers stake PROVE (approximate, from their documentation). The proving market is small today. Igneum does not depend on it. We know of no proof-of-work chain that sells proofs to other chains.</p>
</section>
<section id="finality">
@ -575,7 +575,7 @@ body.all .pager{display:none}
<h2>Economics</h2>
<p>The coin is IGN. It is gas and the proving currency, and part of every payment on Igneum is burned. Outside customers pay in their own currency on their own chain at launch; settlement in IGN with a 10% burn follows when the proof bridge lets Igneum see the payment, in phase two.</p>
<h3>Supply</h3>
<p>Fair launch. No premine, no pre-sale, no allocation to anyone. The supply schedule, the cap, the tail and the fee routes are the six monetary decisions D01 to D06 of the Token Value volume, pending; what follows is the devnet’s code today, not a promise. Hard cap of 4 billion IGN, approached and never reached, because emission starts at 1 billion a year and halves every two years for ever. Nearly a quarter of all supply is mined in the first year and half in the first two. Emission ramps from 10% to 100% over the first 30 days so that nobody takes the first month before the rest of the world hears about it.</p>
<p>Fair launch. No premine, no pre-sale, no allocation to anyone. The cap, the schedule, the fee routes and the finality display are the Token Value volume’s decisions, ratified on 9 October 2026 (D01 to D06): the cap is fixed with no tail emission and no vote that expands it, subject to the pre-launch security-funding gate (D01); the schedule’s pacing is under comparison and not final (D02); every fee and burn route is published explicitly, the 80/20 figure is an emission allocation only, and external-job charges are not yet set (D04); a recovery certificate is never shown as final (D05). A ratified decision is a rule, not a promise of value. Hard cap of 4 billion IGN, approached and never reached, because emission starts at 1 billion a year and halves every two years for ever; the pacing is under comparison and not final (D02). Nearly a quarter of all supply is mined in the first year and half in the first two. Emission ramps from 10% to 100% over the first 30 days so that nobody takes the first month before the rest of the world hears about it.</p>
<div class="figure">
<svg viewBox="0 0 760 300" role="img" aria-label="Half of the 4 billion cap is mined in the first two years" font-family="IBM Plex Mono, monospace" font-size="12">
<text x="40" y="26" font-family="IBM Plex Sans, system-ui, sans-serif" font-size="15" font-weight="600" fill="var(--ink)">Half of the 4 billion cap is mined in the first two years</text>
@ -611,13 +611,13 @@ body.all .pager{display:none}
</tbody>
</table></div>
<h3>Where fees go</h3>
<p>The base fee of every transaction is burned in full, Ethereum's rule, so a miner cannot fill blocks with its own transactions for free. The priority fee splits two ways: 80% to the miner and provers of that block, 20% to the apps whose code ran, by gas consumed inside each. External proving fees, once they settle on Igneum, pay 90% to the provers who delivered and burn 10%. The hard cap in the devnet’s code fixes supply today (a decision pending). Emission is untouched by any of this: every coin minted still goes to miners and provers.</p>
<p>The base fee of every transaction is burned in full, Ethereum's rule, so a miner cannot fill blocks with its own transactions for free. The priority fee splits two ways: 80% to the miner and provers of that block, 20% to the apps whose code ran, by gas consumed inside each. External proving fees, once they settle on Igneum, pay 90% to the provers who delivered and burn 10%. The hard cap fixes supply (D01). Emission is untouched by any of this: every coin minted still goes to miners and provers.</p>
<h3>Every payment route</h3>
<p>One row per route, so operator income and protocol income never blur. The protocol pays no address of its own, and a burn pays nobody. Rows 1 to 5 are the protocol. Row 6 is the project's software, outside the protocol, and is never added to the other five.</p>
<div class="tbl"><table>
<thead><tr><th>Route</th><th>Currency</th><th>Recipient</th><th>Fee</th><th>Burn</th></tr></thead>
<tbody>
<tr><td>1. Emission, per block</td><td>IGN, new coins on the schedule above</td><td>80% the block's miner, 20% the proving pool for the provers of that block</td><td>None</td><td>None. Implemented in consensus: the 80/20 coinbase on the devnet</td></tr>
<tr><td>1. Emission, per block</td><td>IGN, new coins on the schedule above</td><td>80% the block's miner, 20% the proving pool for the provers of that block</td><td>None</td><td>None. Implemented in consensus: the 80/20 coinbase on the devnet (an emission allocation only, D04)</td></tr>
<tr><td>2. Base fee, both gas dimensions</td><td>IGN</td><td>Nobody</td><td>The base fee the chain sets per block</td><td>All of it. Implemented on the devnet</td></tr>
<tr><td>3. Priority fee</td><td>IGN</td><td>80% the block's miner and provers; 20% the apps whose code ran, per call frame</td><td>The tip the sender sets</td><td>The share of any frame in an unregistered contract. Implemented on the devnet</td></tr>
<tr><td>4. External job, at launch</td><td>The customer's currency, on the customer's chain</td><td>The miner who delivered, through a payout contract keyed by miner address</td><td>Priced in the customer's money per proof, at or above the subsidy the prover forgoes (a formula in network hash, under Building on Igneum, never a fixed number); the customer chain's own bond and slashing apply</td><td>None; Igneum cannot see the payment. Designed</td></tr>
@ -627,7 +627,7 @@ body.all .pager{display:none}
</table></div>
<p class="src"><b>Sources:</b> specification sections 2.5 and 5.1 to 5.4; the measurement record in the repository (docs/bench-log.md) for the earlier devnet's receipts and the dev-fee count.</p>
<h3>Security after the subsidy</h3>
<p>The cap stays at 4 billion in the code today, and no tail emission is coded; the year-five tail vote below is written beside that, an unresolved tension and a pending decision (D01 to D06), not a promise. The schedule is a bet, not a measurement: a halving halves emission income overnight if price and fees do nothing. Kaspa's steeper monthly reduction kept its hashrate while its price rose (approximate). Long term, security has to be paid by fees and, if it is built and bought, the proving market. The external market is Designed, not built, and is out of the numbers below. As designed, outside customers buy proofs as dollars-priced work settled in IGN, and 90% of every job goes to the provers who delivered it. The table shows the first year in which the block subsidy on its own pays miners less than the power of about 3,000 consumer cards, at three flat prices. The prices are inputs chosen to span two orders of magnitude. The model (modelled, 3 October 2026) runs a 300 W card at 124 MH/s on electricity at USD 0.12 per kWh. One rule sits beside the cap. If external proving revenue is under one fifth of the block subsidy over any 90-day window after year 5, the question of a tail reward goes to the miners' signalling vote. The protocol never changes emission by itself.</p>
<p>The cap is fixed at 4 billion, with no tail emission and no vote that expands it (D01, subject to the pre-launch security-funding gate). The schedule is a bet, not a measurement: a halving halves emission income overnight if price and fees do nothing. Kaspa's steeper monthly reduction kept its hashrate while its price rose (approximate). Long term, security has to be paid by fees and, if it is built and bought, the proving market. The external market is Designed, not built, and is out of the numbers below. As designed, outside customers buy proofs as dollars-priced work settled in IGN, and 90% of every job goes to the provers who delivered it. The table shows the first year in which the block subsidy on its own pays miners less than the power of about 3,000 consumer cards, at three flat prices. The prices are inputs chosen to span two orders of magnitude. The model (modelled, 3 October 2026) runs a 300 W card at 124 MH/s on electricity at USD 0.12 per kWh. One rule sits beside the cap. If external proving revenue is under one fifth of the block subsidy over any 90-day window after year 5, the answer is the security-funding plan under D01, never a tail emission or a vote that expands the cap. The protocol never changes emission by itself.</p>
<div class="tbl"><table>
<thead><tr><th>Price per IGN</th><th>First year the subsidy alone pays under the power of 3,000 cards</th><th>Subsidy to miners that year</th></tr></thead>
<tbody>
@ -868,7 +868,7 @@ body.all .pager{display:none}
<li><strong>Proof verification in consensus.</strong> On the Igneum 2.0 devnet, yes, from block zero (verifier_in_consensus set, the node's own start line; running since its first block at 17:14 UK on 8 October 2026). It is the prerequisite of the no-rescue network exercise (Deliverable 5), which is still owed; an earlier devnet ran with the rule off.</li>
<li><strong>Proving on every card.</strong> No. NVIDIA proves; AMD and Apple mine. The proving stack is judged on the full pipeline: inputs, proving, aggregation, verification, payment, memory and the mining income forgone.</li>
<li><strong>What proofs do not give.</strong> Proven execution is not automatically finality. EVM compatibility is not Ethereum security. ZK technology does not automatically make transactions private.</li>
<li><strong>A ranking.</strong> No. Igneum makes no leading or number-one claim. Published claims name the evaluated release, evidence and boundary conditions. Designed to compete for leadership among GPU-first networks. That is the scoped wording until a ranking is measured (the Token Value volume’s rule VR-30, scoped claims only): an independently substantiated pass of the acceptance standard would not award a numerical rank, nor guarantee adoption, perpetual GPU profitability or the defeat of every future chip. Benchmarks against Ravencoin’s KAWPOW, Ergo and Firo’s reference miner are owed work; no result exists yet.</li>
<li><strong>A ranking.</strong> No. Igneum makes no leading or number-one claim. Published claims name the evaluated release, evidence and boundary conditions. Designed to compete for leadership among GPU-first networks. That is the scoped wording until a ranking is measured (the Token Value volume’s rule VR-30 and decision D06, scoped claims only): an independently substantiated pass of the acceptance standard would not award a numerical rank, nor guarantee adoption, perpetual GPU profitability or the defeat of every future chip. Benchmarks against Ravencoin’s KAWPOW, Ergo and Firo’s reference miner are owed work; no result exists yet.</li>
<li><strong>A finished protocol.</strong> The sustained-mining finality rule is the newest piece and the one that external review will try hardest to break. The specification, the review and the benchmarks are published as they happen.</li>
</ul>
<p>Everything in this document is subject to the gates on the roadmap. Nothing in it is an offer to sell anything. Found an error, or a criticism this document does not answer? Email <a href="mailto:hello@igneum.network">hello@igneum.network</a>, or open an issue on the public specification repository: <a href="https://git.igneum.network/igneum-network/spec/issues" rel="noopener">git.igneum.network/igneum-network/spec/issues</a>. Post reaches Igneum Labs LTD, Unit IH-00-01-01-OF-01, Level 01, Innovation One, Dubai International Financial Centre.</p>

2
site/live.html
View file

@ -513,7 +513,7 @@ details.tablebar summary{display:flex;align-items:center}
</details>
<div class="obs-foot"><span>Igneum / observatory</span><span>One node read every 2 s. Nothing here is a replay.</span></div>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as finalised. On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as final (the Token Value volume’s D05). On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
</main>
<!-- footer:start -->

2
site/proving.html
View file

@ -303,7 +303,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
<dl id="totals"></dl>
</div>
</div>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as finalised. On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as final (the Token Value volume’s D05). On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
</main>
<!-- footer:start -->
<footer class="site-footer">

2
site/scenes.html
View file

@ -265,7 +265,7 @@
<p class="note">One node is read every 2 s; the window is the last 120 s. Under reduced motion each scene draws a still frame on every reply. Add <code>?only=a</code>, <code>b</code> or <code>c</code> to the address for one scene full width.</p>
</div>
</section>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as finalised. On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as final (the Token Value volume’s D05). On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
</main>
<!-- footer:start -->
<footer class="site-footer">

2
site/scorecard.html
View file

@ -230,7 +230,7 @@
<tr><td><b>Independent operation</b><div class="kv">D5</div></td><td>No-founder exercise on the real implementation.</td><td>A centrally supported demo.</td><td>PENDING: the no-rescue network exercise is owed; the devnet is the project’s own machines, its rented fleet and a few outside laptops.</td></tr>
<tr><td><b>Commercial demand</b><div class="kv">Architecture and product</div></td><td>Repeat paid external jobs and workable operator margins.</td><td>Devnet payouts or subsidised volume.</td><td>EXCLUDED from every revenue figure today: the external proving market is designed, not built; no external job has been paid.</td></tr>
<tr><td><b>Long-term funding</b><div class="kv">D4</div></td><td>Internal proving and security payments and maintenance runway.</td><td>Burn accounting or assumed appreciation.</td><td>MODELLED: the proving model on the economics page walks the halvings at today’s shard and key counts; the proving payment’s routing is designed behind its constant, burned in full today.</td></tr>
<tr><td><b>Leadership</b><div class="kv">Leadership tests</div></td><td>Comparative results, adoption, retention and reliability over time.</td><td>A roadmap or unsupported rank.</td><td>EXCLUDED: no rank is claimed; the served wording until a ranking is measured is “Designed to compete for leadership among GPU-first networks.” (VR-30); the comparison set (Ravencoin KAWPOW, Ergo, Firo’s reference miner) is owed work, not a result.</td></tr>
<tr><td><b>Leadership</b><div class="kv">Leadership tests</div></td><td>Comparative results, adoption, retention and reliability over time.</td><td>A roadmap or unsupported rank.</td><td>EXCLUDED: no rank is claimed; the served wording until a ranking is measured is “Designed to compete for leadership among GPU-first networks.” (VR-30, D06); the comparison set (Ravencoin KAWPOW, Ergo, Firo’s reference miner) is owed work, not a result.</td></tr>
</tbody>
</table></div>
<p class="src"><b>Source:</b> <code>docs/plans/igneum-2.0-plan.txt</code>, section 23 (the acceptance scorecard) and the pins in <code>docs/plans/igneum-2.0.md</code>; the Today column is the facts page’s label for the rows each gate cites, and moves only with those rows. The five labels: TEAM-REPORTED, MODELLED, PROPOSED, PENDING, EXCLUDED. The public mirror follows master; a link that answers 404 is a file not yet synced.</p>

2
site/tx.html
View file

@ -279,7 +279,7 @@ main{padding-bottom:100px}.card{background:var(--row);border:1px solid var(--lin
<div class="card"><div class="viz-head"><h2>Block and proof</h2><div class="eyebrow" id="blk-eyebrow"></div></div><dl id="blk"></dl></div>
<div class="card"><div class="viz-head"><h2>Logs</h2><div class="eyebrow" id="log-n"></div></div><div class="tbl" id="logs"></div></div>
</div>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as finalised. On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
<p class="note" data-four-words><b>Four words, used exactly.</b> <b>Included</b>: the block carries the transaction. <b>Executed</b>: the EVM ran it and the result is on the record. <b>Proven</b>: a valid proof record for its block was carried and paid. <b>Finalised</b>: the block sits under a certified checkpoint, two thirds of active and of total weight. A pause in finality is shown as a pause, never as a block losing its lock. <b>Recovery lock</b>: after a full weight window with no lock, a checkpoint signed by more than half of the anchored weight; shown as a recovery lock, never as final (the Token Value volume’s D05). On the devnet’s current node line the lock kind is reported by the forming node only: a node that received the certificate records an ordinary lock, so a recovery lock can read as final on a receiving node until the 2.0.3 node line lands. The definitions are the finality specification’s: <a href="https://git.igneum.network/igneum-network/igneum/src/branch/master/docs/spec/finality-guarantees.md">section 9, the guarantees</a>.</p>
</main>
<!-- footer:start -->
<footer class="site-footer">