01The money
The money
Igneum's purpose is private digital money: a currency, IGN, that an ordinary person can hold privately, protect from the loss of an everyday key, recover under rules they chose, and verify with a small computer, secured by a proof-of-work network of the graphics cards people already own, on three lanes that no special chip can take over. In the holder's words:
- Your money stays private. Who paid whom, and how much, is not on the ledger.
- Your everyday key cannot empty your savings. Savings sit behind a delay and a second key that can stop a withdrawal but cannot redirect it.
- Recovery follows rules you choose. You name who can replace your keys, how long it takes, and what they can never do; the everyday key cannot change those rules.
- Ownership rests only on hash-based and lattice-based keys, never on an elliptic curve, as a requirement of the design: the keys a new class of computer is expected to break are kept off the spend and recovery path. It is said as a property only when the whole path, every key that can spend or recover, has passed review.
Nothing on the chain is sold to anyone outside it. The chain's own proof machinery exists only because privacy needs it, and because anyone should be able to verify the rules on a phone.
02Spend and VaultOne currency, IGN, and two experiences.
Spend and Vault
One currency, IGN, and two experiences.
Spend. A payment is a private transfer: the ledger records no sender, no recipient and no amount. Receiving needs no action by the recipient; the wallet finds its own notes by scanning the chain with its own keys, on the person's own machine or node. For one payment, the payer or the payee can produce a receipt that reveals exactly that payment's amount, recipient and memo, and nothing about any other payment, balance or address; the receipt names what it reveals, in words, before it is produced.
Vault. Protected savings, on paper until the payment construction is settled. A withdrawal is announced, waits a delay the owner chose, then completes; during the delay it is visibly pending in the wallet. A second key, held apart from the everyday key, can cancel a pending withdrawal; it cannot redirect, spend or change the rules. The owner names a recovery authority (their own cold key, a set of people, a hardware device, or none) that can replace the vault's keys through an explicit process with its own, longer delay, announced on the ledger and cancellable during it. The everyday key can never shorten a delay, raise a limit or replace the recovery authority, and repeated small withdrawals cannot bypass the limit. The wallet shows what is available, what is protected, what is leaving and when, and what is being recovered and by whom.
03What must holdFive requirements, each with what would fail it.
What must hold
Five requirements, each with what would fail it.
| Requirement | What it means | What would fail it |
|---|---|---|
| Payment privacy | The ledger, the miners and a wallet server learn neither sender, recipient nor amount of a private transfer, and cannot link a spend to the note it spends. | A linkable nullifier; an amount readable from the ledger; a network or wallet-server leak that ties an address to a machine; a small anonymity set presented as a large one. |
| Supply integrity | No private transfer creates coins. The pool never holds more than verifiably entered it, and anyone can check that number from public data. | A proof-system soundness bug; a hash collision in the commitment or nullifier scheme; a missing turnstile, so a counterfeit inside the pool could leave it unnoticed. |
| Ownership off the elliptic curve, a requirement of the design | Every authorisation that can move funds or replace keys, the everyday spend, the cancellation, the recovery and the policy change, rests only on hash-based or lattice-based assumptions. | Any curve-based signature or proof anywhere on the spend or recovery path; a public-side key that can act on vault funds; a claim made before the whole path is reviewed. |
| Theft containment | The loss of the everyday key loses at most the everyday balance plus one period's limit; the loss of the cancellation key alone loses nothing; the loss of the recovery authority alone loses nothing within its delay. | A path by which one key both spends and changes policy; a delay the everyday key can shorten; a withdrawal split that evades the limit; a recovery that completes without a visible, cancellable delay. |
| Independent verification on the minimum node | A node on the minimum supported machine validates every block, private transfers included, inside the whole-block time budget, and its disk and bandwidth hold at the stated transaction rate. | A proof the minimum node cannot verify in time; chain growth that fills the disk inside a year at the stated rate; a sync that needs a trusted checkpoint or a server's word. |
The address a transaction is sent from, the address a wallet syncs from, and the pattern of a wallet's queries to a server can each link a person to a payment the ledger itself hides; no privacy claim is made that the network layer has not been measured against.
04What is not claimed
What is not claimed
- Not more private than the established privacy coins today. As designed, a private transfer here is larger than theirs, slower to prove, and a new pool's anonymity set is a fraction of theirs. A person who wants only private payments is better served today by one of them, and this page says so.
- The transfer sizes as designed are large and must come down: an estimated 85 to 145 KB a transfer, where the established designs carry a few kilobytes. Every size and time is an estimate until it is measured.
- Two matching features elsewhere do not make a combination better until it is measured. Private payments, a public vault with chosen recovery and accounts on hash-based and lattice-based keys each exist elsewhere; what this design adds is the three together in one pool, and a combination is not better until it is measured.
- Nothing here is live. No private transfer, no vault and no hash-based or lattice-based key runs on any Igneum network today, and no served page states the design as running.
05The stagesOn the research chain, in this order, each stage ending in reproducible evidence: a record page with the chain, the block range, the node build, the commands and the figures, re-runnable by anyone with the repository.
The stages
On the research chain, in this order, each stage ending in reproducible evidence: a record page with the chain, the block range, the node build, the commands and the figures, re-runnable by anyone with the repository.
The vault stays on paper until the four before it pass. No date is written here.
- Keys, private receive and spend: the keys from one seed, with test vectors; the proof generated on a PC and a phone; a private transfer accepted by a node of record; the proof's size, the proving time and memory, and the node's verification time against the thresholds.
- Double-spend rejection and supply conservation: a duplicate spend refused in the pool and in a block; an unbalanced transfer refused; the pool's total read exact against every deposit and withdrawal.
- Wallet scanning, backup and restore: a wallet scanning a day's outputs on a phone; a restore from the 24 words; the balance exact, spent notes included.
- Scoped disclosure: a receipt for one payment verified by a third party with no other knowledge, revealing nothing about any other payment.
- Vault withdrawals and cancellation, on paper before code: the vault's rules (the everyday key, the cancellation key, the recovery authority, the delay, the limit), a withdrawal with its delay, the cancellation path; code only after the design review.
- Recovery and policy changes, on paper before code: the recovery process, its longer delay, its cancellation, the key replacement, the policy change under the stronger authority.
- Mining pay and the existing wallet: a key's share paid directly into the private pool, reconciled by the public ledger to the wei; the wallet's private account beside its public one with every boundary labelled; Ember offering the private payout address, never setting it by itself.
06How it is judgedNo claim of being better is made until four wins are measured and published, each against the same scenarios run on the comparable systems:
How it is judged
No claim of being better is made until four wins are measured and published, each against the same scenarios run on the comparable systems:
- Security: the same compromise scenarios (the everyday key, the cancellation key, the recovery authority, an old backup) run against this design and against each comparable wallet, with the most that can be lost in each published as a share of the holding.
- Privacy: ledger linkability measured on the research chain at stated transfer rates and pool sizes; the payout link before and after stage 7; network metadata; wallet-server leakage in each sync mode; what a receipt reveals beyond its one payment. A small network cannot manufacture an anonymity set, and the figure says how small it was.
- Usability with people, not agents: whether holders can say, unprompted, what is protected, what is pending, who can recover, and what a receipt reveals.
- Operating cost: sizes, fees in gas, scanning time and bandwidth, verification time and memory on the minimum node, and storage on each supported device, measured beside the same figures for the comparable systems where they are published.
The comparison is published row by row, each cell with its basis, and with no aggregate score. The stop condition, in one sentence: if the design needs an unsubstantiated construction or exceeds the minimum node's budget, the programme stays research, with what would have to change said plainly, and no claim is weakened to fit.
Source: every sentence on this page is from the design record of 18 October 2026, which names its sources; the comparison's figures are cited there to the pages they came from.