Remove the development fund from the protocol
Decision of 3 October 2026: no fee to any team, foundation or fund. Priority fee now splits 80% to the miners and provers of the block and 20% to the application called, attributed per call frame as before. No burn of the tip; the base fee is still burned in full on both gas dimensions. External proving jobs pay 90% to the provers who delivered and burn 10%. The 60% signalling mechanism stays as a general tool for parameters that genesis rules leave to miners; upgrades stay at 90%. Ledger E4 closed by removal; E3, E5, G4, G5, G8, L1 and overclaims 45, 46 and 53 rewritten to the new rule. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
parent
5b79eb130f
commit
0965d3dc19
8 changed files with 59 additions and 59 deletions
|
|
@ -6,7 +6,7 @@ Owner: execution engineer. Reviewers: consensus engineer (sections 1 and 3), cry
|
|||
|
||||
This document takes decisions. Each section states the decision, the reason, and the rejected alternative in one line. Numbers follow the labels of `docs/spec/00-overview.md` section 0.2: Measured, Implemented, Designed, Target, or approximate. Line numbers into `vendor/rusty-kaspa` are from commit `01b532e8` (v2.1.0, 22 Sep 2026), the base in `docs/fork-map.md`. Claims about other chains cite a source or say approximate.
|
||||
|
||||
What this document rests on, fixed by the design document and CLAUDE.md and not reopened here: blocks carry transactions only and make no claim about state; every node executes natively; every block is proven by miners in shards and aggregated 20 to 60 s behind the tip at launch; base fee burned in full on both gas dimensions; priority fee split 65/15/15/5 with the developer share per call frame; proving pool paid per block as a fixed amount divided by consensus proving cost; SP1 behind a swappable interface; no stake, no other chain in consensus; transactions public.
|
||||
What this document rests on, fixed by the design document and CLAUDE.md and not reopened here: blocks carry transactions only and make no claim about state; every node executes natively; every block is proven by miners in shards and aggregated 20 to 60 s behind the tip at launch; base fee burned in full on both gas dimensions; priority fee split 80/20 (producer and provers / developer, per call frame), no burn of the tip and no development fund; proving pool paid per block as a fixed amount divided by consensus proving cost; SP1 behind a swappable interface; no stake, no other chain in consensus; transactions public.
|
||||
|
||||
## Decisions in one table
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ What this document rests on, fixed by the design document and CLAUDE.md and not
|
|||
| D7 | The header drops `utxo_commitment` and `accepted_id_merkle_root`. It keeps `hash_merkle_root` over the body and adds `proofs_root` over the proof records the body carries | 2.2 |
|
||||
| D8 | block.number = selected-chain height of C (contiguous). block.timestamp = max(parent segment timestamp, C.timestamp div 1000), non-decreasing. blockhash(n) = hash of chain block n within 256. PREVRANDAO = keccak(epoch seed, number). coinbase = miner address of the block that first included the executing copy. Cancun opcodes, no blob transactions | 3 |
|
||||
| D9 | Gas has two dimensions: execution gas on Ethereum's schedule, unchanged; proving gas (pgas) on a per-opcode and per-precompile table calibrated in reference prover kilocycles. One transaction gas limit; the wei budget `gas_limit x max_fee_per_gas` caps both dimensions. Base fee per dimension, EIP-1559 adjusted, burned | 4 |
|
||||
| D10 | Developer attribution per call frame by execution gas, to the registration of the account whose code runs; registration by the deployer at deployment through a system registry; created contracts inherit the creator's registration unless re-registered in the same transaction; unregistered frames' 15% is burned | 4.5 |
|
||||
| D10 | Developer attribution per call frame by execution gas, to the registration of the account whose code runs; registration by the deployer at deployment through a system registry; created contracts inherit the creator's registration unless re-registered in the same transaction; unregistered frames' 20% is burned | 4.5 |
|
||||
| D11 | Shards are cut from the native execution trace by pgas, never splitting a transaction; continuations for one transaction above the shard budget. Sortition assigns each shard to 8 eligible provers for a 10 s exclusive window, then open. No claim bond in-chain; the bond is for the external job market only | 5 |
|
||||
| D12 | A full node rejects a block whose proof record disagrees with its own native execution (the native-execution veto). Proof system versioned in consensus, three-month overlap, 90% signalling, latest proof wrapped once at the switch | 5.5 |
|
||||
| D13 | Native proving precompile at a fixed system address: request now, result delivered by a later proof record that runs a callback; paid by the requester with the external-job split | 6 |
|
||||
|
|
@ -140,7 +140,7 @@ The environment revm sees is built from the chain block C whose segment is execu
|
|||
| `block.timestamp` (TIMESTAMP) | `ts(C) = max(ts(parent chain block), C.timestamp_ms div 1000)` | Header timestamp, strictly increasing | Non-decreasing, equal values happen at one block a second. Kaspa only requires a header timestamp above the past median time of a 27-sample window and below now plus 132 s (`constants.rs:23 to 30`; `post_pow_validation.rs:20 to 24`; `pre_ghostdag_validation.rs:38 to 42`), so without the max rule time could step backwards |
|
||||
| `blockhash(n)` (BLOCKHASH) | Hash of chain block n for `number - 256 <= n < number`, else 0 | Same | Hashes of merged non-chain blocks are not reachable from the EVM; `IgneumInfo` exposes the mergeset of a chain block |
|
||||
| `block.prevrandao` (PREVRANDAO, and DIFFICULTY) | `keccak256(epoch_seed ‖ number)`, where `epoch_seed` is the 10-minute class-group VDF output for the epoch that contains C (spec section 4) | RANDAO mix | Unbiasable by the producer but predictable for the whole epoch (about 1 h) by anyone who has computed the VDF. Fine for a game's shuffle revealed later, wrong for a per-block lottery. Use the proving precompile with a committed input for anything adversarial |
|
||||
| `block.coinbase` (COINBASE) | `miner` address of the block that first included the executing copy | Fee recipient | Also the address that receives the 65% share, so the correspondence Ethereum contracts assume holds. For a transaction in a red block it is still the red block's miner, who is paid the share (section 4.4) |
|
||||
| `block.coinbase` (COINBASE) | `miner` address of the block that first included the executing copy | Fee recipient | Also the address that receives the 80% share, so the correspondence Ethereum contracts assume holds. For a transaction in a red block it is still the red block's miner, who is paid the share (section 4.4) |
|
||||
| `block.gaslimit` (GASLIMIT) | Per-block execution gas limit, a consensus constant | Header gas limit | A segment can hold up to the mergeset limit of blocks (180 at 1 BPS, `bps.rs:75 to 86`), so a segment's total can exceed `gaslimit` |
|
||||
| `block.basefee` (BASEFEE) | Execution base fee at this segment (section 4.3) | Same | The proving base fee is readable from `IgneumInfo` |
|
||||
| `block.chainid` (CHAINID) | 4461 | 1 | |
|
||||
|
|
@ -207,22 +207,20 @@ Backlog rule. If the oldest unproven segment is more than 600 chain blocks behin
|
|||
|---|---|---|---|
|
||||
| Execution base fee `f_e x gas_used` | 100% | Burned | At execution |
|
||||
| Proving base fee `f_p x pgas_used` | 100% | Burned | At execution |
|
||||
| Tip `tip x gas_used` | 65% | The `miner` of the block that first included the executing copy, red or blue | At execution |
|
||||
| Tip | 15% | Developer registrations, per call frame (section 4.5); unregistered frames' share burned | At execution |
|
||||
| Tip | 15% | Burned | At execution |
|
||||
| Tip | 5% | Development fund contract | At execution |
|
||||
| Tip `tip x gas_used` | 80% | The `miner` of the block that first included the executing copy, red or blue | At execution |
|
||||
| Tip | 20% | Developer registrations, per call frame (section 4.5); unregistered frames' share burned | At execution |
|
||||
| Subsidy | 80% of emission | Blue blocks' `miner` addresses, red blocks unpaid (Kaspa's rule) | In the segment that merges the block |
|
||||
| Proving pool | 20% of emission for the proven segment, divided among its shards by consensus pgas, with 10% of the pool to the aggregator (Designed, parameter open) | Provers named in the proof record | In the segment that includes the proof record |
|
||||
|
||||
The red-block miner keeps the 65% tip share because the sequence executed its transaction; red-ness is a GHOSTDAG verdict on the block's position, not on its contents. Alternative: tip share to the merging chain block's miner. Rejected: it rewards chain blocks for merging red blocks, which they do not choose.
|
||||
The red-block miner keeps the 80% tip share because the sequence executed its transaction; red-ness is a GHOSTDAG verdict on the block's position, not on its contents. Alternative: tip share to the merging chain block's miner. Rejected: it rewards chain blocks for merging red blocks, which they do not choose.
|
||||
|
||||
### 4.5 Developer attribution
|
||||
|
||||
Decision. During execution the executor keeps a per-frame counter of execution gas consumed by the frame's own opcodes (not its sub-calls). At the end of the transaction the 15% developer share is divided among frames in proportion to that gas, and each frame's part goes to the registration of the account whose code ran in that frame: for CALL and STATICCALL the callee, for DELEGATECALL and CALLCODE the code address (the implementation behind a proxy). Precompile frames and EOA transfers have no registration; their share is burned.
|
||||
Decision. During execution the executor keeps a per-frame counter of execution gas consumed by the frame's own opcodes (not its sub-calls). At the end of the transaction the 20% developer share is divided among frames in proportion to that gas, and each frame's part goes to the registration of the account whose code ran in that frame: for CALL and STATICCALL the callee, for DELEGATECALL and CALLCODE the code address (the implementation behind a proxy). Precompile frames and EOA transfers have no registration; their share is burned.
|
||||
|
||||
Registration lives in a system contract `DeveloperRegistry` at a fixed address, populated by rule on CREATE and CREATE2: the new contract's registration is copied from its creator's registration if the creator has one (a factory passes its payee to everything it deploys), and the creating transaction may overwrite it by calling `DeveloperRegistry.register(newContract, payee)` before it ends. A deployer EOA sets its own default payee once with `register(self, payee)`; a contract can change its own registration by calling `register(address(this), payee)` from its own code. Nobody else can.
|
||||
|
||||
Self-dealing (ledger E3). The base fees are burned, so a developer who spams its own contract loses 100% of two base fees and 85% of the tip to recover 15%. A developer who also mines the including block recovers 80% of the tip and still loses 20% of the tip plus both base fees. No positive-expectation loop exists. The share does inflate "gas earned by app" on a leaderboard at that cost, so the explorer must not rank apps on raw developer share; section 8.4 asks Blockscout's ranking to exclude transactions whose sender, coinbase and payee coincide.
|
||||
Self-dealing (ledger E3). The base fees are burned, so a developer who spams its own contract loses 100% of two base fees and 80% of the tip to recover 20%. A developer who also mines the including block recovers the whole tip and still loses both base fees. No positive-expectation loop exists. The share does inflate "gas earned by app" on a leaderboard at that cost, so the explorer must not rank apps on raw developer share; section 8.4 asks Blockscout's ranking to exclude transactions whose sender, coinbase and payee coincide.
|
||||
|
||||
Alternative. Attribute by the proxy address rather than the code address. Rejected: it lets a proxy claim a library author's work; the code address is what actually ran.
|
||||
|
||||
|
|
@ -322,7 +320,7 @@ interface IProverCallback {
|
|||
}
|
||||
```
|
||||
|
||||
Who pays. The requester's `msg.value` is escrowed as the job fee and must be at least `maxPgas x f_p x 1.5` (the 1.5 is the premium that makes a job worth a miner's switch from hashing, Designed, parameter open); the request itself is a normal transaction paying both gas dimensions. On delivery the fee splits by the external-job rule: 10% burned, 5% to the development fund, the rest to the prover; unused fee above the actual pgas is refunded to the requester. A job nobody proves within 3,600 chain blocks expires and refunds in full.
|
||||
Who pays. The requester's `msg.value` is escrowed as the job fee and must be at least `maxPgas x f_p x 1.5` (the 1.5 is the premium that makes a job worth a miner's switch from hashing, Designed, parameter open); the request itself is a normal transaction paying both gas dimensions. On delivery the fee splits by the external-job rule: 90% to the provers who delivered, 10% burned; unused fee above the actual pgas is refunded to the requester. A job nobody proves within 3,600 chain blocks expires and refunds in full.
|
||||
|
||||
How results return. A prover runs the program, and its job proof is gossiped like a shard proof. A block producer includes it as a `JobRecord {jobId, output, proof}` in the body's `proofs` section. When the segment carrying the record executes, the executor verifies the job proof with the current `ProofSystem` (full nodes cannot re-run arbitrary programs natively, so for jobs the proof is the only check, unlike segments), stores `(status, output)` in `Prover`, and calls `callback.onProof` with a gas stipend of 200,000 execution gas paid from the escrow (Designed). The segment's own proof recursively verifies the job proof, so a light client needs nothing extra. Jobs are assigned by the same sortition as shards.
|
||||
|
||||
|
|
|
|||
|
|
@ -379,32 +379,32 @@ Answer: The schedule (1 billion a year halving every two years, 30-day ramp from
|
|||
|
||||
Evidence: litepaper "Supply" and "Fair launch, announced".
|
||||
|
||||
### E3. The 15% developer share enables wash gas
|
||||
"Deploy a contract, spam it with your own transactions, collect 15% of your own priority fee back. If you also mine the block you collect 80%."
|
||||
### E3. The 20% developer share enables wash gas
|
||||
"Deploy a contract, spam it with your own transactions, collect 20% of your own priority fee back. If you also mine the block you collect all of it."
|
||||
|
||||
Status: Answered by design, with a metrics caveat.
|
||||
|
||||
Answer: The base fee is burned in full, so every wash transaction loses its whole base fee. Of the priority fee a developer alone gets back 15% and loses 85%. A developer who also mines the block including its own transaction gets 65% plus 15% and loses 20% of the priority fee plus the full base fee. Wash gas is a guaranteed loss. What it can do is inflate an app's "gas earned" figure on a leaderboard at a cost of 20% of the priority fee, so no explorer ranking should be built on raw developer share without a self-dealing filter. Attribution is per call frame by gas consumed, with factory-deployed contracts inheriting the factory's registration.
|
||||
Answer: The base fee is burned in full, so every wash transaction loses its whole base fee. Of the priority fee a developer alone gets back 20% and loses 80%. A developer who also mines the block including its own transaction gets 80% plus 20%, the whole priority fee, and still loses the full base fee in both gas dimensions. Wash gas is a guaranteed loss. What it can do is inflate an app's "gas earned" figure on a leaderboard at a cost of 20% of the priority fee, so no explorer ranking should be built on raw developer share without a self-dealing filter. Attribution is per call frame by gas consumed, with factory-deployed contracts inheriting the factory's registration.
|
||||
|
||||
Evidence: design doc Finality v2 "Fees"; litepaper "What a builder gets for being early".
|
||||
|
||||
### E4. 5% of gas to the dev fund is a tax
|
||||
"You say 100% of emission to miners, then take 5% of gas. Users are taxed instead."
|
||||
|
||||
Status: Answered by design, wording fix needed.
|
||||
Status: Closed by removal, 3 October 2026.
|
||||
|
||||
Answer: The fund takes 5% of the priority fee (the base fee is burned in full), and 5% of external job fees, and no emission. Spending needs 60% of hashrate signalling over two weeks. The litepaper says "5% of gas" and should say "5% of the priority fee". Whether a fee-funded, miner-controlled fund is a "tax" is a word choice; the number is 5% of tips.
|
||||
Answer: There is no development fund. The 5% of the priority fee and 5% of external job fees that earlier drafts routed to a fund contract under 60% miner signalling were removed on 3 October 2026. A switch that routes money to an address somebody controls is the first thing a critic points at, however it is gated, so the protocol carries no fee to any team, foundation or fund. The priority fee now splits 80% to the miner and provers of the block and 20% to the apps whose code ran; external jobs pay 90% to the provers who delivered and burn 10%. The team earns in the open by running provers in the job market and by the app share on the contracts it deploys. A grant mechanism can be added by miner signalling later if the community wants one.
|
||||
|
||||
Evidence: design doc Finality v2 "Fees". Fix: overclaims list, item 56.
|
||||
Evidence: spec section 5.5; design doc "No development fund, so nothing to fight over". Fix: none outstanding; overclaims item 53 closed.
|
||||
|
||||
### E5. "Not one coin to a founder" is false
|
||||
"The official miner carries a 1% dev fee to the founder's company. That is 1% of all hashrate paid to one company for as long as miners run it, which is a founder allocation with better PR."
|
||||
|
||||
Status: Conceded, partly stated, homepage overclaims.
|
||||
|
||||
Answer: Correct in substance. The litepaper discloses the 1% dev fee and says any other client is welcome. The homepage says "Not one coin to a founder, a fund or a stake", which is true of emission and false of the dev fee. The design doc also says the founder's company carries development from that fee, its pool and its proving business until usage funds the development fund. All of that must be in one place in the litepaper under a heading a critic can quote.
|
||||
Answer: Correct in substance. The litepaper discloses the 1% dev fee and says any other client is welcome. The homepage says "Not one coin to a founder, a fund or a stake", which is true of emission and false of the dev fee. There is no development fund (removed 3 October 2026) and no protocol fee to the team; the team earns from the client dev fee, its pool, its provers in the job market and the app share on contracts it deploys, all in the open. All of that must be in one place in the litepaper under a heading a critic can quote.
|
||||
|
||||
Evidence: design doc "Funding development for ever without taxing miners". Fix: overclaims list, item 63.
|
||||
Evidence: design doc "No development fund, so nothing to fight over". Fix: overclaims list, item 63.
|
||||
|
||||
### E6. Two-year halvings bleed hashrate
|
||||
"Every GPU coin that halved fast lost its miners at the second halving. You halve every two years for ever."
|
||||
|
|
@ -469,7 +469,7 @@ Evidence: design doc, decisions table row "Who are you?". Journey: `site/journey
|
|||
|
||||
Status: Conceded, wording fix needed.
|
||||
|
||||
Answer: Correct. Consensus has no admin keys. The genesis apps are contracts and each will have an upgrade policy; the bridge's is the one that matters, and if it starts as a committee bridge (E7) it has keys by definition. The litepaper's sentence must be scoped to consensus and each genesis contract must publish its key policy before launch.
|
||||
Answer: Correct. Consensus has no admin keys. The genesis apps are contracts and each will have an upgrade policy; the bridge's is the one that matters, and if it starts as a committee bridge (E7) it has keys by definition. The development fund contract named in the quote no longer exists: the fund was removed on 3 October 2026. The litepaper's sentence must be scoped to consensus and each genesis contract must publish its key policy before launch.
|
||||
|
||||
Evidence: litepaper "Governance". Fix: overclaims list, item 46.
|
||||
|
||||
|
|
@ -478,7 +478,7 @@ Evidence: litepaper "Governance". Fix: overclaims list, item 46.
|
|||
|
||||
Status: Conceded, stated in the litepaper.
|
||||
|
||||
Answer: True at launch. The litepaper says a second independent client is the development fund's first priority. The finality module is separable and the chain runs on plain GHOSTDAG without it, which contains one class of bug. A second client before mainnet is not in the 13-month plan and the litepaper should not imply it is.
|
||||
Answer: True at launch. The litepaper names a second independent client as the first priority after launch; there is no development fund to pay for it (removed 3 October 2026), so whoever builds it pays for it. The finality module is separable and the chain runs on plain GHOSTDAG without it, which contains one class of bug. A second client before mainnet is not in the 13-month plan and the litepaper should not imply it is.
|
||||
|
||||
Evidence: litepaper "Governance", last bullet.
|
||||
|
||||
|
|
@ -505,7 +505,7 @@ Evidence: not yet.
|
|||
|
||||
Status: Conceded, stated in the design doc.
|
||||
|
||||
Answer: True in the same way it is true on Bitcoin, where miner signalling activated SegWit and Taproot. The thresholds are high so that nothing passes without near-consensus. The litepaper should name pool concentration as the governance risk rather than imply every miner votes.
|
||||
Answer: True in the same way it is true on Bitcoin, where miner signalling activated SegWit and Taproot. The thresholds are high so that nothing passes without near-consensus. Since 3 October 2026 there is no fund to spend: the 60% threshold applies only to parameters that the genesis rules leave to miners, and 90% to upgrades. The litepaper should name pool concentration as the governance risk rather than imply every miner votes.
|
||||
|
||||
Evidence: design doc Finality v2, Residual risks bullet 3.
|
||||
|
||||
|
|
@ -630,7 +630,7 @@ Evidence: CLAUDE.md rules (privacy rejected). Fix: overclaims list, item 68.
|
|||
|
||||
Status: Open, counsel not yet engaged.
|
||||
|
||||
Answer: There is no sale, no premine, no allocation and no promise of return, and nothing in consensus is controlled by the team, which is the structure that regulators have treated most favourably (approximate: compare the SEC's own framework on sufficiently decentralised networks and MiCA's exemption for tokens created automatically as a reward for maintaining a distributed ledger, approximate quotation). The weak points a lawyer will circle are the ones quoted: founder-run pool and proving business, founder-seeded DEX, launch grants, and the phrase "exchange listings after". None is in consensus; all are promotional. The litepaper must drop the listing sentence and counsel must review the founder-business paragraph before v0.2. The legal entity is "offshore, parked" in the design doc, which is not an answer.
|
||||
Answer: There is no sale, no premine, no allocation and no promise of return, and nothing in consensus is controlled by the team and no protocol fee reaches it (the development fund was removed on 3 October 2026), which is the structure that regulators have treated most favourably (approximate: compare the SEC's own framework on sufficiently decentralised networks and MiCA's exemption for tokens created automatically as a reward for maintaining a distributed ledger, approximate quotation). The weak points a lawyer will circle are the ones quoted: founder-run pool and proving business, founder-seeded DEX, launch grants, and the phrase "exchange listings after". None is in consensus; all are promotional. The litepaper must drop the listing sentence and counsel must review the founder-business paragraph before v0.2. The legal entity is "offshore, parked" in the design doc, which is not an answer.
|
||||
|
||||
Evidence: design doc "Legal" paragraph. Fix: overclaims list, items 75 and 76.
|
||||
|
||||
|
|
@ -926,10 +926,10 @@ Replace with: "Igneum is governed by the hashrate that powers it. Pools carry th
|
|||
Replace with: "Pools can be bypassed on transaction choice. Igneum ships Stratum v2 job declaration from day one, so a miner chooses its own transactions when its pool supports it. Vote keys stay with the pool."
|
||||
|
||||
45. LP governance: "There are no admin keys. Nothing in consensus can be paused, upgraded or reversed by any key."
|
||||
Replace with: "There are no admin keys in consensus. Nothing in consensus can be paused, upgraded or reversed by any key. The genesis apps and the development fund contract publish their own key policies before launch; the bridge's is the one to read."
|
||||
Replace with: "There are no admin keys in consensus. Nothing in consensus can be paused, upgraded or reversed by any key. The genesis apps publish their own key policies before launch; the bridge's is the one to read."
|
||||
|
||||
46. LP governance: "Upgrades need a second independent node client, funded from the development fund as its first priority."
|
||||
Replace with: "At launch there is one node client. A second independent client is the development fund's first priority and is not in the 13-month plan."
|
||||
Replace with: "At launch there is one node client. A second independent client is the first priority after launch, anyone can build it, and it is not in the 13-month plan."
|
||||
|
||||
47. LP miners ask: "Kaspa said ASIC resistant too, and IceRiver shipped a chip in eighteen months."
|
||||
Replace with: "Every GPU coin got a chip in the end. Kaspa got one in about eighteen months."
|
||||
|
|
@ -951,7 +951,7 @@ Replace with: "That is a different limit from Bitcoin's, where a majority can re
|
|||
Replace with: "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."
|
||||
|
||||
53. LP economics and governance: "5% of gas and 5% of external job fees go to a development fund"
|
||||
Replace with: "5% of the priority fee and 5% of external job fees go to a development fund"
|
||||
Closed by removal, 3 October 2026: there is no development fund. The paragraph now reads "No fund, no foundation, no fee to the team" and the governance bullet names 60% signalling as the tool for parameters that genesis leaves to miners.
|
||||
|
||||
54. LP economics: "Nearly a quarter of all supply is mined in the first year and half in the first two, so the people who show up early get the most."
|
||||
Replace with: "Nearly a quarter of all supply is mined in the first year and half in the first two. Emission halves every two years for ever."
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ This specification defines the Igneum layer 1 so that a stranger can reimplement
|
|||
| 2 | `02-consensus.md` | The ordering layer as a delta on rusty-kaspa: block rate, GHOSTDAG parameters, difficulty, emission, header changes, duplicate inclusion |
|
||||
| 3 | `03-finality.md` | Sustained-mining finality, version 2, with the quorum floor |
|
||||
| 4 | `04-seeds-and-vdf.md` | The epoch and era seed pipeline through the class-group VDF |
|
||||
| 5 | `05-fees-and-economics.md` | Fees, splits, burns, the development fund, signalling thresholds |
|
||||
| 5 | `05-fees-and-economics.md` | Fees, splits, burns, signalling thresholds, no development fund |
|
||||
| 6 | `06-open-items.md` | Every parameter or rule that is unmeasured, unreviewed or marked open, with the experiment that closes it |
|
||||
|
||||
Out of scope for version 0.1: the zkEVM execution layer, the chunked proving protocol, the proof format carried in headers, the external job market, the P2P wire format, the RPC surface, the miner client and pool protocol. Where a later section depends on one of these, the dependency is named as a forward reference and the behaviour the dependency must provide is stated.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# Igneum protocol specification, section 5: fees, splits, burns, the development fund, signalling
|
||||
# Igneum protocol specification, section 5: fees, splits, burns, signalling
|
||||
|
||||
Spec version 0.1, 3 October 2026. Status of this section: Designed (design document, "The token", "Finality rule, version 2: Fees", decisions table "What do I get for being early?"). Nothing here is implemented or measured. Emission itself is section 2.5.
|
||||
|
||||
Two rules frame everything: there is no stake anywhere in consensus, and not one unit of emission goes to a treasury, a fund, a founder or a stake. Development is funded from fees, under miner signalling.
|
||||
Two rules frame everything: there is no stake anywhere in consensus, and the protocol carries no fee to any team, foundation or fund. Not one unit of emission or of fees goes to a treasury, a fund, a founder or a stake. The development fund that earlier drafts carried (5% of tips and 5% of job fees under 60% signalling) was removed on 3 October 2026 (section 5.5).
|
||||
|
||||
## 5.1 Base fee
|
||||
|
||||
|
|
@ -21,20 +21,20 @@ Designed. The priority fee (tip) of every executed transaction splits:
|
|||
|
||||
| Share | Recipient | Rule |
|
||||
|---|---|---|
|
||||
| 65% | Block producer and provers | The producer of the block in which the first copy executed (section 2.6) and the provers of that block, in the proportion the proving protocol defines (forward reference) |
|
||||
| 15% | Developer | Attributed per call frame by gas consumed, to the developer address registered for the called contract at deployment. A frame in an unregistered contract sends its share to the burn |
|
||||
| 15% | Burn | |
|
||||
| 5% | Development fund | Section 5.5 |
|
||||
| 80% | Block producer and provers | The producer of the block in which the first copy executed (section 2.6) and the provers of that block, in the proportion the proving protocol defines (forward reference) |
|
||||
| 20% | Developer | Attributed per call frame by gas consumed, to the developer address registered for the called contract at deployment. A frame in an unregistered contract sends its share to the burn |
|
||||
|
||||
Per-call-frame attribution: a transaction that calls contract A, which calls B, which calls C, pays 15% of the tip in proportion to the gas each frame consumed, to A's, B's and C's registrations respectively. A frame's own gas excludes the gas of frames it called.
|
||||
No part of the tip is burned by rule; the burn is the base fee (5.1) and the unregistered developer share.
|
||||
|
||||
Per-call-frame attribution: a transaction that calls contract A, which calls B, which calls C, pays 20% of the tip in proportion to the gas each frame consumed, to A's, B's and C's registrations respectively. A frame's own gas excludes the gas of frames it called.
|
||||
|
||||
Factory rule: a contract deployed by another contract (CREATE or CREATE2 from a contract) inherits the deploying contract's registration unless it re-registers in the same transaction. A contract deployed from an externally owned account registers the address the deployment names, or none.
|
||||
|
||||
Self-dealing: a developer who also mines the including block collects 65% plus 15% and loses 20% of the tip plus the whole base fee, so wash gas is a guaranteed loss; it can still inflate a "gas earned" figure on a leaderboard, so no explorer ranking should use raw developer share without a self-dealing filter (ledger E3; not a consensus rule).
|
||||
Self-dealing: a developer who also mines the including block collects 80% plus 20%, the whole tip, and still loses the whole base fee in both dimensions, so wash gas is a guaranteed loss; it can still inflate a "gas earned" figure on a leaderboard, so no explorer ranking should use raw developer share without a self-dealing filter (ledger E3; not a consensus rule).
|
||||
|
||||
## 5.3 Proving pool
|
||||
|
||||
Designed. The 20% emission share (section 2.5) and the provers' part of the 65% tip share are paid per block as a fixed amount for that block, divided among the block's shards by consensus proving cost, so a stuffed block earns no more than an honest one. Shards are claimed with a small bond, slashed on a bad or late proof, and a withheld shard reopens with a rising fee until someone proves it (design document, security model table). First-come claiming favours the lowest-latency datacentre (ledger P8, C9); sortition of shards by a VRF keyed to the block, weighted by past proving, with open claiming after a timeout, is the scheduled replacement and is Open (O-5.1). Bond size and timeout are Open (O-5.6). An unproven block delays only its proof; execution and the 30-s lock do not wait for it (ledger P9).
|
||||
Designed. The 20% emission share (section 2.5) and the provers' part of the 80% tip share are paid per block as a fixed amount for that block, divided among the block's shards by consensus proving cost, so a stuffed block earns no more than an honest one. Shards are claimed with a small bond, slashed on a bad or late proof, and a withheld shard reopens with a rising fee until someone proves it (design document, security model table). First-come claiming favours the lowest-latency datacentre (ledger P8, C9); sortition of shards by a VRF keyed to the block, weighted by past proving, with open claiming after a timeout, is the scheduled replacement and is Open (O-5.1). Bond size and timeout are Open (O-5.6). An unproven block delays only its proof; execution and the 30-s lock do not wait for it (ledger P9).
|
||||
|
||||
## 5.4 External job market
|
||||
|
||||
|
|
@ -42,21 +42,22 @@ Designed. At launch external proving jobs are paid on the customer's chain, in t
|
|||
|
||||
| Share | Recipient |
|
||||
|---|---|
|
||||
| 85% | The prover that won the job |
|
||||
| 90% | The provers who delivered the job |
|
||||
| 10% | Burn |
|
||||
| 5% | Development fund |
|
||||
|
||||
The burn applies only to IGN-settled jobs (ledger P10). The timing of the switch and the bridge's trust model are Open (O-5.2).
|
||||
|
||||
## 5.5 Development fund
|
||||
## 5.5 No development fund
|
||||
|
||||
Designed. A contract, not an account. It receives 5% of every priority fee (5.2) and 5% of every IGN-settled external job fee (5.4), and never a unit of emission. Spending needs miner signalling: a proposal names a recipient and an amount; blocks signal for it; it passes when at least **60% of blue blocks** over a signalling window of **1,209,600 DAA s (two weeks)** carry the signal (the BIP 9 model). Miners hold the purse without filling it; users and rollups fill it. Before there is usage the founder's company carries development from the official client's 1% dev fee, its pool and its proving business (ledger E5: the homepage's "not one coin to a founder" is true of emission and false of the dev fee, and must say so). The fund contract's upgrade and key policy is published before launch (ledger G4, O-5.4).
|
||||
Designed, decided 3 October 2026. There is no development fund and no protocol fee to any team, foundation or fund. Earlier drafts routed 5% of the priority fee and 5% of IGN-settled job fees to a fund contract that spent only on 60% miner signalling. Removed, because a switch that routes money to an address somebody controls is the first thing a critic points at, however it is gated. The team earns in the open, like anyone else: it runs provers in the job market (5.3, 5.4) and collects the developer share (5.2) on the contracts it deploys.
|
||||
|
||||
The 60% signalling mechanism stays as a general governance tool (5.8): a parameter that the genesis rules leave to miners is set by a proposal that passes at **60% of blue blocks** over a window of **1,209,600 DAA s (two weeks)**, the BIP 9 model. A grant mechanism can be added the same way later if the community wants one; none is specified. Ledger E4 is closed by removal; O-5.4 no longer covers a fund contract.
|
||||
|
||||
## 5.6 No stake, no treasury
|
||||
|
||||
- No consensus rule reads a balance. No bond, deposit or stake affects block validity, vote weight, fork choice or finality. The prover shard bond of 5.3 is an execution-layer escrow, not a consensus weight.
|
||||
- No unit of emission goes anywhere but the block producer (80%) and the proving pool (20%).
|
||||
- The team holds no consensus key and no purse (hostile review table, "A team that controls a treasury").
|
||||
- The team holds no consensus key, no purse and no protocol fee (hostile review table, "A team that controls a treasury").
|
||||
|
||||
## 5.7 Upgrade signalling
|
||||
|
||||
|
|
@ -66,19 +67,20 @@ Emergency path: a soundness bug in the proof system cannot wait for a signalling
|
|||
|
||||
## 5.8 Signalling encoding
|
||||
|
||||
Designed, Open (O-5.3). Each block carries a bitfield; bit b set means "this block signals for proposal b". Proposals are registered by a transaction naming the bit, the kind (fund spend or upgrade), the threshold (60% or 90%) and the window start in DAA score. The count is over blue blocks with DAA score in the window. A proposal that fails may be re-registered.
|
||||
Designed, Open (O-5.3). Each block carries a bitfield; bit b set means "this block signals for proposal b". Proposals are registered by a transaction naming the bit, the kind (parameter or upgrade), the threshold (60% for a parameter the genesis rules leave to miners, 90% for an upgrade) and the window start in DAA score. The count is over blue blocks with DAA score in the window. A proposal that fails may be re-registered.
|
||||
|
||||
## 5.9 Parameters in this section
|
||||
|
||||
| Parameter | Value | Label |
|
||||
|---|---|---|
|
||||
| Base fee burn | 100%, both dimensions | Designed |
|
||||
| Priority fee split | 65 / 15 / 15 / 5 | Designed |
|
||||
| External job split (IGN-settled) | 85 / 10 / 5 | Designed |
|
||||
| Fund signalling threshold | 60% of blue blocks | Designed |
|
||||
| Fund signalling window | 1,209,600 DAA s | Designed (design document: "over two weeks") |
|
||||
| Priority fee split | 80 / 20 (producer and provers / developer) | Designed |
|
||||
| External job split (IGN-settled) | 90 / 10 (provers / burn) | Designed |
|
||||
| Parameter signalling threshold | 60% of blue blocks | Designed |
|
||||
| Parameter signalling window | 1,209,600 DAA s | Designed (design document: "over two weeks") |
|
||||
| Upgrade signalling threshold | 90% of blue blocks | Designed |
|
||||
| Upgrade window, activation delay | not set | Open (O-5.3) |
|
||||
| Shard bond, claim timeout | not set | Open (O-5.6) |
|
||||
| Proving-cost budget per block | from the phase 2 measurement | Target |
|
||||
| Emission to any treasury | 0 | Designed |
|
||||
| Protocol fee to any team, foundation or fund | 0 | Designed (3 October 2026) |
|
||||
|
|
|
|||
|
|
@ -85,10 +85,10 @@ An item closes when its measurement is in `docs/bench-log.md` or its decision is
|
|||
| O-5.1 | First-come shard claiming lets the lowest-latency datacentre take every shard (ledger P8, C9) | Specify sortition of shards (VRF keyed to the block, weighted by past proving, open claiming after a timeout); measure on the phase 4 devnet | decision, cryptographer; measure in 4 |
|
||||
| O-5.2 | External job settlement: on the customer's chain at launch, in IGN with a 10% burn once the proof bridge exists; the bridge's trust model at launch (committee-attested or proof-verified) is undecided (ledger P10, E7) | Decision before phase 4; the litepaper stops presenting the proof bridge as a genesis feature until then | decision, execution engineer |
|
||||
| O-5.3 | Signalling encoding: version bits or a separate field, window length and activation delay for upgrades, proposal registration format (section 5.7, 5.8) | Specify with the consensus engineer; BIP 9 is the model | 2 |
|
||||
| O-5.4 | The development fund contract's upgrade and key policy; every genesis contract's key policy (ledger G4) | Publish before launch | 4 |
|
||||
| O-5.4 | Every genesis contract's upgrade and key policy (ledger G4); the development fund contract is gone (fund removed 3 October 2026) | Publish before launch | 4 |
|
||||
| O-5.5 | The proving-cost gas dimension: the metering table per opcode and precompile, and the per-block budget from the phase 2 measurement | Phase 2 benchmark; execution-layer specification | phase 2 |
|
||||
| O-5.6 | Shard bond size and claim timeout (ledger P9) | Set on the phase 4 devnet | 4 |
|
||||
| O-5.7 | The provers' proportion of the 65% tip share (section 5.2) | Defined by the chunked proving protocol | phase 2 |
|
||||
| O-5.7 | The provers' proportion of the 80% tip share (section 5.2) | Defined by the chunked proving protocol | phase 2 |
|
||||
| O-5.8 | Developer registration format at deployment and the re-registration transaction (section 5.2) | Execution-layer specification | decision, execution engineer |
|
||||
|
||||
## 6.6 Count
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
| 2 | `02-consensus.md` | Designed | The ordering layer as a delta on rusty-kaspa: 1 BPS and the steps, k, merge depth, DAA, header fields, emission, duplicate inclusion |
|
||||
| 3 | `03-finality.md` | Designed (simulated without a DAG, not implemented, not reviewed) | Weight W1 to W5, checkpoints C1 to C5, quorum Q1 to Q4 with the 56.7% floor and the simulation that justifies it, sortition, fork choice, equivocation, residual risks, the first month, exchange guidance |
|
||||
| 4 | `04-seeds-and-vdf.md` | Measured (primitive, one machine); Designed (pipeline); Open (fallback) | Class-group Wesolowski VDF, T from a genesis reference rate, 20-minute and 2-hour leads, proof format, who evaluates, fallback options |
|
||||
| 5 | `05-fees-and-economics.md` | Designed | Base fee burned, 65/15/15/5 with per-frame attribution and the factory rule, proving pool, job market, development fund at 60%, upgrades at 90%, no stake, no treasury |
|
||||
| 5 | `05-fees-and-economics.md` | Designed | Base fee burned, priority fee 80/20 with per-frame attribution and the factory rule, proving pool, job market 90/10, no development fund, parameter signalling at 60%, upgrades at 90%, no stake, no treasury |
|
||||
| 6 | `06-open-items.md` | Open | 60 items, each with the experiment or decision that closes it and its gate |
|
||||
|
||||
Prototype values (carried by the implementation today, part of the test vectors, confirmed or replaced at gate 1): seed derivation; 64 instructions x 8 iterations; 8 registers; the op weights including the 25% load weight; the output fold rotations; the 256 MiB cache, 64 lines per segment and ChaCha12; 8 item rounds and the mixer shape; the 1 GiB pack dataset against the 2 GiB genesis size; the 3,600 DAA s epoch; the era length, draw bounds and reserve list; the header binding of the init words. The full table with what fixes each is section 1.16.
|
||||
|
|
|
|||
|
|
@ -327,7 +327,7 @@ footer .wrap{padding-block:48px 32px}
|
|||
<div class="job reveal">
|
||||
<svg viewBox="0 0 24 24" width="32" height="32" fill="none" stroke="#F2541B" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true"><path d="M8 7l-5 5 5 5M16 7l5 5-5 5M14 4l-4 16"></path></svg>
|
||||
<h3>Build</h3>
|
||||
<p>Ethereum bytecode, wallets and tools, unchanged. One-second inclusion, finality in about two minutes, a prover network any contract can call, and 15% of the priority fees your code earns paid back to you every block.</p>
|
||||
<p>Ethereum bytecode, wallets and tools, unchanged. One-second inclusion, finality in about two minutes, a prover network any contract can call, and 20% of the priority fees your code earns paid back to you every block.</p>
|
||||
<a href="/litepaper#builders-ask" class="more">Deploy on Igneum</a>
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -373,7 +373,7 @@ footer .wrap{padding-block:48px 32px}
|
|||
<div class="wrap" style="display:grid;gap:48px;grid-template-columns:repeat(auto-fit,minmax(min(100%,380px),1fr));align-items:center">
|
||||
<div class="reveal" style="display:flex;flex-direction:column;gap:20px">
|
||||
<h2>Every coin, mined</h2>
|
||||
<p style="color:var(--ink-2)">Hard cap of 4 billion IGN. Emission halves every two years for ever. Not one coin to a founder, a fund or a stake. Development is paid from fees by the people who use the chain, and spent only when miners signal yes.</p>
|
||||
<p style="color:var(--ink-2)">Hard cap of 4 billion IGN. Emission halves every two years for ever. Not one coin to a founder, a fund or a stake. No fee to any team, foundation or fund either. The team mines, proves and builds on the same terms as everyone else.</p>
|
||||
<div style="display:flex;flex-direction:column;gap:10px">
|
||||
<div class="bar" id="bar"><div style="width:0;background:var(--ember)" data-w="80%"></div><div style="width:0;background:var(--molten)" data-w="20%"></div></div>
|
||||
<div class="legend mono" style="margin-top:4px;font-size:13px">
|
||||
|
|
|
|||
|
|
@ -177,7 +177,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's proving-as-consensus centralised</td><td>Proving is useful, verifiable in milliseconds, and kept apart from the lottery</td></tr>
|
||||
<tr><td>A proof-of-work chain where every block is proven</td><td>zkEVMs exist only as rollups on proof-of-stake Ethereum. Conflux has run GPU-mined EVM apps on a DAG since 2020, without proofs</td><td>Proven state on a proof-of-work base layer, produced by the miners themselves</td></tr>
|
||||
<tr><td>Finality held by miners and immune to hour-long rentals</td><td>Decred votes with stake. Horizen penalises hidden chains. Kaspa limits depth</td><td>Sustained-mining weight: hashrate that appeared today has no vote</td></tr>
|
||||
<tr><td>100% of emission to the people running the hardware</td><td>Kaspa's fair launch, with no utility. Zcash and Decred fund developers from emission</td><td>Fair launch, utility, and a development fund paid by outsiders and spent by miners</td></tr>
|
||||
<tr><td>100% of emission to the people running the hardware</td><td>Kaspa's fair launch, with no utility. Zcash and Decred fund developers from emission</td><td>Fair launch, utility, and no fee to any team, foundation or fund</td></tr>
|
||||
<tr><td>A chain your browser verifies by itself</td><td>Light clients trust a committee</td><td>At launch, one execution proof plus the votes on the latest locked checkpoint. The single-proof client that also proves canonicity is phase two and the roadmap says so</td></tr>
|
||||
</tbody>
|
||||
</table></div>
|
||||
|
|
@ -320,7 +320,7 @@ body.all .pager{display:none}
|
|||
<p>The first apps, a DEX, a lending market and an Ethereum bridge, ship at genesis so there is somewhere to use the coin from day one.</p>
|
||||
<h3>What a builder gets for being early</h3>
|
||||
<ul>
|
||||
<li><strong>Apps earn the gas they generate.</strong> 15% of every transaction's priority fee goes to the contracts whose code ran, by gas consumed inside each, paid every block to the developer address registered at deployment. Canto and Blast proved builders come for this. On Igneum it comes out of fees, never out of miner emission.</li>
|
||||
<li><strong>Apps earn the gas they generate.</strong> 20% of every transaction's priority fee goes to the contracts whose code ran, by gas consumed inside each, paid every block to the developer address registered at deployment. Canto and Blast proved builders come for this. On Igneum it comes out of fees, never out of miner emission.</li>
|
||||
<li><strong>Stablecoins at genesis.</strong> USDC and USDT bridged through the proof bridge, canonical versions on Igneum, the way Arbitrum and Base launched. Native USDC is requested from Circle during public testnet. Igneum issues no stablecoin of its own.</li>
|
||||
<li><strong>Liquidity from the people who are there.</strong> The DEX is seeded by the founders' own mined coins and by miners, and every miner is a funded wallet from day one.</li>
|
||||
<li><strong>Launch grants.</strong> Paid from the founders' own mined coins, never from emission, to the first apps that bring users.</li>
|
||||
|
|
@ -368,9 +368,9 @@ body.all .pager{display:none}
|
|||
</tbody>
|
||||
</table></div>
|
||||
<h3>Where the price comes from</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 four ways: 65% to the miner and provers of that block, 15% to the apps whose code ran, by gas consumed inside each, 15% burned, 5% to the development fund. External proving fees burn 10%. The hard cap fixes supply. Demand comes from use of the chain and from outsiders buying proofs, and both reduce supply as they happen. Emission is untouched by any of this: every coin minted still goes to miners and provers.</p>
|
||||
<h3>Development, paid by outsiders and controlled by miners</h3>
|
||||
<p>5% of gas and 5% of external job fees go to a development fund held in a contract. Not one coin of emission goes to it, so miners are never taxed. Spending from it needs 60% of hashrate signalling yes over two weeks. Miners hold the purse. The users and rollups who want Igneum to keep improving fill it.</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 pay 90% to the provers who delivered and burn 10%. The hard cap fixes supply. Demand comes from use of the chain and from outsiders buying proofs, and both reduce supply as they happen. Emission is untouched by any of this: every coin minted still goes to miners and provers.</p>
|
||||
<h3>No fund, no foundation, no fee to the team</h3>
|
||||
<p>There is no development fund. A switch that routes money to an address somebody controls is the first thing a critic points at, so Igneum has none. The protocol carries no fee to any team, foundation or fund. The team earns in the open: it runs provers in the job market and collects the app share on the contracts it deploys, like anyone else. If the community ever wants a grant mechanism, miners can add one by signalling.</p>
|
||||
</section>
|
||||
|
||||
<section id="miners">
|
||||
|
|
@ -401,10 +401,10 @@ body.all .pager{display:none}
|
|||
<p>Igneum is governed by the people who power it, and by nobody else.</p>
|
||||
<ul>
|
||||
<li><strong>Nothing needs a scheduled upgrade.</strong> The mining program, the dataset and the finality rules run themselves for ever. If the community ever ships an improvement, a better proof system or a block-rate step, it is published with test vectors at least three months ahead and activates only when 90% of blocks signal readiness. Developers can write code. Only miners can turn it on.</li>
|
||||
<li><strong>The development fund is spent by miners.</strong> Every proposal passes or fails on 60% of hashrate signalling over two weeks, and the fund is filled by fees, never by emission.</li>
|
||||
<li><strong>Miners set what genesis leaves open.</strong> A parameter that the genesis rules leave to miners is set by signalling: a proposal passes or fails on 60% of hashrate over two weeks. There is no fund to vote on and no fee to any team, foundation or fund.</li>
|
||||
<li><strong>Pools cannot censor.</strong> Igneum uses Stratum v2 from day one, so each miner chooses its own transactions even inside a pool.</li>
|
||||
<li><strong>There are no admin keys.</strong> Nothing in consensus can be paused, upgraded or reversed by any key. There is no foundation allocation to vote with and no stake to buy.</li>
|
||||
<li><strong>The chain runs without its founders.</strong> Blocks, proofs and finality need no one. Upgrades need a second independent node client, funded from the development fund as its first priority.</li>
|
||||
<li><strong>The chain runs without its founders.</strong> Blocks, proofs and finality need no one. A second independent node client is the first priority after launch, and anyone can build it.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
|
|
@ -448,7 +448,7 @@ body.all .pager{display:none}
|
|||
<h3>Which stablecoin, and is there liquidity?</h3>
|
||||
<p>USDC and USDT, bridged through the proof bridge at genesis as the canonical versions on Igneum. Native USDC is requested from Circle during testnet. The DEX is seeded at launch by the founders' own mined coins and by miners, and every miner is a funded wallet.</p>
|
||||
<h3>What do I get for being early?</h3>
|
||||
<p>15% of the priority fee on every transaction that runs your code, paid to you every block. Launch grants from the founders' mined coins. A place in the wallet's Apps tab and the explorer from day one. And the only user base a new chain has ever had that did not have to be paid to arrive.</p>
|
||||
<p>20% of the priority fee on every transaction that runs your code, paid to you every block. Launch grants from the founders' mined coins. A place in the wallet's Apps tab and the explorer from day one. And the only user base a new chain has ever had that did not have to be paid to arrive.</p>
|
||||
<h3>How do I deploy?</h3>
|
||||
<p>Point Hardhat or Foundry at an Igneum node with the chain id and deploy the same bytecode. Verify the source in the explorer. Register a developer address for the gas share. The afternoon is the hard part.</p>
|
||||
</section>
|
||||
|
|
|
|||
Loading…
Reference in a new issue