Abstract
SIWORLD is a post-quantum private payment network. On SIWORLD, nobody reading the chain can tell who paid whom, how much was paid or in which asset, or when the money arrived and how long it sat. All three are hidden at once, in every transaction, and protected by proofs built from hash functions alone, so a quantum computer cannot unlock them later.
Each transaction carries one native STARK proof generated by the payer's wallet, and a node accepts the transaction after verifying that single proof. The proof system needs no trusted setup and makes no elliptic-curve assumption. SIP and every issued asset share one privacy pool and one transaction shape; fees stay confidential and are settled by a proof in each block. A block arrives every five minutes and carries 64 to 576 identical-format transaction slots.
The design targets at least 80 bits of security against a quantum adversary, accounted against the actual proof instances, while keeping a conjectured classical margin near 185 bits. Proofs are kept for three days after finality; the public ledger is kept forever.
Security target. The engineering target is at least 80 bits of quantum security. SIP is the network's unit of account and its only fee asset; this paper describes a protocol and is not an offer of any financial product.
Three layers of privacy: who, how much, when
Bitcoin writes three facts onto its ledger forever: who paid whom, how much, and when. SIWORLD takes all three off the chain.
| Who | How much | When |
|---|---|---|
| Payer and payee | Amounts, assets and fees | Arrival and holding time |
| Commitments, no addresses | Amounts as commitments | Arrival time never shown |
| Nullifiers can't be linked | Asset type hidden too | Every past note is cover |
| ML-KEM-768 outputs | Fees are commitments | Fixed slots plus padding |
| Dandelion++ hides origin | Settlement proof per block | Ordered by hash, not time |
Hash proofs + ML-KEM + ML-DSA: on by default, built for the quantum era.
Who: the payment graph cannot be drawn
A note's owner exists only inside its encrypted contents; the chain holds a commitment. The nullifier revealed at spend time is derived inside the proof from the owner's secret, and it is fully disconnected on chain from the note it consumes. Outputs are encrypted with ML-KEM-768, so only the recipient can recognise its notes. Transactions travel a random Dandelion++ path before they are broadcast, so the first node to announce one is not its creator. The result: nobody can draw SIWORLD's payment graph.
How much: amounts, assets and fees stay private
Amounts and asset types reach the chain only as commitments, and the proof confirms that every asset balances without revealing a single value. Fees are committed too, so standard and priority transactions look identical, and one settlement proof per block shows the fee total is correct. SIP and every issued asset share one pool and one transaction shape: sending ten thousand tokens and sending one SIP look exactly the same on chain.
When: timing clues are flattened
A spend proves only that its inputs sit under one of the newest 4,096 commitment-tree roots. It reveals neither which note it spends nor when that note arrived. Money received yesterday and money received three years ago look exactly the same when spent; the whole history of notes is the anonymity set. Every block's slots share one format and padding fills the empty ones, so the chain does not display how many real payments it carries, and slots are ordered by a BLAKE3 identifier rather than by arrival time.
On by default, built for the quantum era
These three layers are not optional features; they are the default state of every transaction. They rest on hash-based proofs, ML-KEM and ML-DSA rather than on elliptic curves that quantum computers will break. Every byte written to SIWORLD is protected to the standard of the quantum era.
1. Motivation
Bitcoin and Ethereum showed that money can run without a trusted party. They also showed that a public ledger remembers everything, and that the cryptography protecting it has an expiry date. SIWORLD is designed around both lessons.
Transparent ledgers have lost their anonymity
Bitcoin was described as pseudonymous: addresses are not names. In practice the graph of payments gives names back. In 2013, Meiklejohn and colleagues clustered Bitcoin addresses by shared ownership and tied a substantial, active part of the economy to real-world entities (A Fistful of Bitcoins). Ethereum's account model is weaker still, because it relies on address reuse: Béres and colleagues profiled users by time-of-day activity, fee habits and graph structure, and linked mixer deposits to withdrawals (Blockchain is Watching You).
The consequence is that both chains are, for practical purposes, transparent. One exchange withdrawal or one known payment connects a person to an entire history of balances, counterparties and habits, permanently and for anyone to read. Pseudonymity no longer delivers the anonymity it was meant to provide, and a later privacy layer cannot erase what was already published.
The quantum clock is accelerating cryptography
The expected arrival of large quantum computers has already changed cryptography faster than any attack. NIST finalized its first post-quantum standards, ML-KEM (FIPS 203) and ML-DSA (FIPS 204), on 13 August 2024 and urged administrators to start integrating them immediately (NIST). The UK's National Cyber Security Centre has set migration milestones for 2028, 2031 and 2035, and warns that "harvest now, decrypt later" collection is already happening (Infosecurity Magazine).
The estimated cost of an attack keeps falling. In May 2025 Craig Gidney estimated that RSA-2048 could be factored in under a week with fewer than one million noisy qubits, down from 20 million in his 2019 estimate (arXiv:2505.15917). In 2026 a paper from Google Quantum AI, the Ethereum Foundation and Stanford put the 256-bit elliptic-curve discrete logarithm used by Bitcoin and Ethereum at roughly 1,200 to 1,450 logical qubits and fewer than 500,000 physical qubits, about twenty times below the previous estimate (Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities).
No such machine exists today, but the exposure is already on chain. A June 2026 analysis estimates that about 6.0 million BTC, roughly 30% of supply, and about 55 to 60% of ETH sit behind public keys that have already been revealed (Quantum Horizon). For a transparent chain, a quantum computer threatens funds. For a privacy chain whose note encryption depends on elliptic curves, it threatens something worse: every recorded ciphertext becomes readable, and the privacy of the whole history is lost at once.
Three design choices
SIWORLD follows three rules that come directly from these two problems:
- Publish as little as possible. The chain stores commitments, nullifiers and ciphertexts, not amounts, assets or addresses. What is never written cannot be analysed or decrypted later.
- Prove with hashes. Validity is shown with STARK proofs whose soundness rests on hash functions and low-degree testing, with no pairing, discrete-log or trusted-setup assumption.
- Encrypt and sign with post-quantum primitives. Outputs are encrypted to recipients with ML-KEM-768; node identities and fund records are signed with ML-DSA-65; peer connections combine X25519 with ML-KEM-768.
2. Notes, assets and state
Value lives in notes. A note is a private record of an owner, an amount, a 32-byte asset identifier, an unlock height and fresh randomness. The chain sees only its commitment, a Poseidon2 hash of those fields, appended to a global commitment tree.
Spending a note reveals its nullifier, a value derived inside the proof from the note and the owner's secret. Nodes keep the set of spent nullifiers and reject any repeat. Nothing on chain links a nullifier to the commitment it consumes.
One pool, many assets. SIP uses the reserved all-zero identifier. Anyone can issue a fixed-supply asset: the issuer signs a public declaration with an ML-DSA-65 key, and the asset identifier is a BLAKE3 hash of the network, that key and a sequence number. Issuance is public, so an asset's existence and total supply are known. After issuance its notes join the same pool as SIP, and later transfers reveal neither the asset nor its links to earlier transfers. Issuance pays a fixed fee in SIP, which does not go to the miner.
Recent roots. A transaction proves that its inputs exist under some recent commitment-tree root. Those roots are themselves kept in a depth-12 tree, and membership is checked inside the proof, so a transaction reveals only which snapshot it used, not which note. Nodes accept anchors from the newest 4,096 snapshots, about 14 days.
Encryption. Each output is encrypted so its recipient can find and spend it. The recipient output uses ML-KEM-768 with ChaCha20-Poly1305; the two change outputs use ChaCha20-Poly1305 keys derived with domain-separated BLAKE3. Every output plaintext is 208 bytes, and padding performs real encryption under throwaway keys, so ciphertexts have one size and one shape.
3. Transactions
Every transaction has the same shape: two inputs, three outputs, one confidential SIP fee, and one native STARK proof generated by the sender's wallet. The three outputs are a payment, an asset change and a SIP change; a pure SIP transfer uses the same fields, with unused positions set to zero value.
The proof shows, without revealing any of the values, that:
- each nonzero input exists under an accepted recent root and is owned by the spender;
- the nullifiers are correctly derived and distinct;
- every asset balances separately, so one asset can never pay for another;
- the fee is paid in SIP alone and matches its public commitment;
- no input is spent before its unlock height;
- the output commitments are well formed, and every ciphertext byte is bound to the statement.
The proof does not show that ciphertexts decrypt correctly. Wallets check their own encryption before broadcast, and recipients verify each tag and recomputed commitment on receipt. A malformed ciphertext can lose that one payment; it cannot create an invalid state.
Proof system and parameters
Proofs use Plonky3 over the KoalaBear field with a degree-8 extension (D8), Poseidon2 with width 24 (W24) and 12-element digests.
| Parameter | Value |
|---|---|
| Transaction AIR | 256 rows, 1,392 main and 247 preprocessed columns, 101 public values |
| Constraints | 2,898, maximum degree 3 |
| FRI | log blowup 7, 41 queries, binary folding |
| Grinding | 20 bits on queries and batching |
| Proof size limit | 655,360 bytes |
Security accounting
Parameters are set against the actual transaction instance. The quantum-halved Johnson-bound Fiat–Shamir terms reach about 81.7 bits, conjectured classical security about 185 bits, and commitment collision resistance 123.3 bits under the BHT quantum model. The settlement and issuance relations meet the same floors with their own parameters. Each transaction slot occupies 2,115 bytes of permanent on-chain data.
4. Blocks and confidential fees
A block holds between 64 and 576 transaction slots, in steps of 16, and every slot looks the same on chain. The miner chooses the capacity, fills it with real transactions from the mempool, and fills the rest with padding transactions it generates itself. Padding has the same byte length, the same proof envelope and real encryption under throwaway keys.
Slots are ordered by a domain-separated BLAKE3 statement identifier, strictly ascending, which removes the miner's freedom to arrange transactions by arrival time or by sender. Duplicate identifiers are rejected. Blocks propagate in compact form: peers already hold the verified transactions, so a block carries references and the per-block data, not 576 proofs again.
At full capacity a block settles 576 transactions every 300 seconds, about 1.9 transactions per second, or about 165,900 per day. Throughput scales with the chosen capacity, not with miner proving power.
Confidential fees
A published fee would reveal which slots are padding and which are priority payments. SIWORLD therefore never publishes individual fees.
- Each transaction carries a randomized commitment to its fee: zero for padding, the base fee b for a standard transaction, or 4b for a priority one. The base fee is fixed by the snapshot the transaction anchors to.
- The opening of that commitment travels privately, in a sidecar beside the transaction, to the nodes that relay it and the miner that includes it.
- The miner adds one native settlement proof per block. It shows that the committed fees of all included slots sum to the amount paid into the miner's reward notes, and that those notes carry the correct subsidy, mode and unlock heights.
The settlement proof sums fee commitments only. A miner can start without holding SIP: its first block pays it subsidy plus fees, and padding costs only proving time.
5. Consensus
SIWORLD uses Nakamoto consensus: the valid chain with the most accumulated work wins, and a block is final after 24 confirmations, about two hours.
Proof of work. The work function is a chain of sequential BLAKE3 hashes over a fixed header seed and nonce. It has no elliptic-curve component; a quantum computer gains at most Grover's quadratic search speedup, which shifts difficulty but does not break the rule.
Difficulty. An ASERT controller retargets every block toward a 300-second interval with a 4-hour half-life, so hash-rate swings correct within hours rather than weeks. Timestamps must exceed the median of the previous 11 blocks and may run at most 15 minutes ahead of local time.
Validity before work. A node accepts a block only after it has verified every transaction proof and the settlement proof, checked every nullifier against the spent set, and applied one deterministic, integer-only state transition. The same transition is used for building, validating and replaying blocks.
Reorganization bound. Nodes reorganize at most 24 blocks automatically. A deeper fork stops the node and requires an explicit recovery procedure, rather than silently rewriting settled history.
Checkpoints. Because proofs are pruned after three days (Section 7), a new node cannot re-verify every historical proof from genesis. Checkpoints are signed under a 2-of-3 authority fixed in the genesis block. Proof of work alone does not prove the validity of deleted history; the checkpoint is an explicit, disclosed trust assumption for bootstrapping.
6. Monetary policy
SIP is issued only through block subsidies. The subsidy starts at about 33.95 SIP per block, falls by about 15% a year, and settles at a permanent tail of 1 SIP per block after about 21.6 years. Issuance begins at block 1. One SIP is 100,000,000 atoms, and all monetary arithmetic is integer.
Issuance schedule
The schedule moves in epochs of 4,032 blocks, about 14 days. With e = floor((h − 1) / 4032):
r0 = 3,394,524,515 atomsre+1 = max(108, ⌊re · 4,268,204,354 / 232⌋)
The first year issues about 3.3 million SIP. The decaying phase issues about 21.32 million SIP in total; the tail then adds about 105,000 SIP a year, enough to keep paying miners for security after the decay ends.
| Year | Subsidy per block at start of year | Cumulative SIP issued (gross) |
|---|---|---|
| 1 | 33.95 SIP | 3.31 million |
| 4 | 20.85 SIP | 10.53 million |
| 10 | 7.86 SIP | 17.66 million |
| 20 | 1.54 SIP | 21.12 million |
| 22 | 1.11 SIP | 21.36 million |
| 30 | 1.00 SIP (tail) | 22.20 million |
Computed from the consensus formula above, 105,192 blocks per year, before burns.
Burns from Voyager blocks reduce circulating supply below this gross curve; how much depends on miners' choices.
Where each subsidy goes
Every block subsidy S is split by consensus, in integer atoms, before anyone touches it. Transaction fees are not split; they go entirely to the miner.
| Share | Recipient | Rule |
|---|---|---|
| 87% | Miner | Paid according to the miner's chosen mode, below |
| 10% | Development fund | floor(S/10), released half at maturity and half over four years |
| 3% | Holder pool | floor(3S/100), a public consensus balance with no private key |
Miner modes: Voyager and Holder
Each block template states one mode explicitly; there is no default, and the mode is public in the block. The modes apply only to the miner's 87%.
| Voyager | Holder | |
|---|---|---|
| Spendable after 24 blocks | 75% | 60%, plus 1/4,032 of the Holder pool |
| Locked | None | 40%, as four notes of 10% each |
| Unlock heights | n/a | 52,560 / 105,120 / 157,680 / 210,240 blocks later (about 6, 12, 18 and 24 months) |
| Released by the miner | 5% burned permanently, 20% to the Holder pool | None |
A Voyager miner takes less, sooner, and gives up a quarter of its share: one fifth of that is destroyed, the rest goes to the pool. A Holder miner accepts that 40% of its share stays locked for up to two years, and in exchange draws a fixed fraction of the pool with each block it finds. Locks are enforced inside the transaction proof: a note cannot be spent in any transaction anchored below its unlock height.
Holder pool order. Within each block the pool is credited first and drawn second. With P the pool balance before the block and C = floor(3S/100), a Holder block takes floor((P + C) / 4032) and the remainder stays in the pool; a Voyager block adds C plus its released 20% and takes nothing. Every amount is an integer number of atoms, and the pool has no private key: only the consensus rule moves it.
The mechanism is meant to smooth early supply and remove a share of it permanently. It is not a promise of any price or profit, and the pool's size depends entirely on how other miners choose.
Development fund
The development fund receives 10% of every subsidy, computed by consensus in the same integer transition as the miner's share. Half of each credit becomes spendable after the 24-block maturity; the other half vests linearly over 1,461 days, about four years, counted by block height. Spending requires an ML-DSA-65 signature and can never exceed the vested balance minus what has already been spent. Fund records are public and permanent, so anyone can audit what has vested and what has been spent.
Conservation
At every height, total issuance equals the sum of reward notes, the Holder pool balance, the cumulative burn and the development fund entitlements. Nodes check this identity and roll the pool, burn and fund state back atomically with any reorganization. Public tools will report issuance, burn, locked totals, pool balance and fund spending.
7. Storage and synchronization
SIWORLD keeps the public ledger forever and the proofs for three days. A proof's job is done once the block that carries it is final and every honest node has checked it; keeping hundreds of gigabytes of proofs per month would buy no extra safety for current users.
| Data | Kept for |
|---|---|
| Headers and proof of work | Permanently |
| Commitments, tree state, ciphertexts, nullifiers, fee commitments | Permanently |
| Settlement declarations (without proofs), reward notes, fund records, issuance records, recent-root snapshots | Permanently |
| Transaction, settlement and issuance proofs; fee sidecars | Until three days after finality |
At full load, every slot adds 2,115 permanent bytes, about 128 GB a year. The rolling proof window covers 888 blocks (24 unfinalized plus three days) and is capped at about 336 GB. A validating node therefore needs roughly 680 GB in its first year at sustained maximum load; a 1 TB SSD is recommended, and actual use grows with real traffic rather than with the cap.
A new node starts from a checkpoint signed by the genesis-fixed 2-of-3 authority, downloads the permanent public data, verifies that it matches the checkpoint, and then verifies every proof from that point on. Ciphertexts are kept forever, so a wallet restored from its seed can always scan the chain and recover its notes, including locked ones.
Hardware baseline
| Role | Memory | Storage | Network |
|---|---|---|---|
| Validating node | 16 GiB | SSD, 500 GB minimum, 1 TB recommended | 43 Mbps minimum, 100 Mbps recommended |
| Miner | 32 GiB | SSD, 1 TB recommended | 100 Mbps recommended |
All roles require an x86-64-v3 processor (AVX2). An ARM baseline is planned. These profiles are sized for sustained maximum load.
8. Network
Peer connections are encrypted with a hybrid key exchange, so traffic recorded today cannot be decrypted later by breaking only one of its parts.
- Hybrid handshake. Every session combines ephemeral X25519 and ML-KEM-768; both must contribute. There is no fallback to a classical-only channel: a peer that cannot negotiate the hybrid handshake is disconnected.
- Dual identity. Each node holds an Ed25519 key and an ML-DSA-65 key and signs the handshake with both. An attacker must forge both to impersonate a known peer, and unexpected key changes fail closed.
- Source privacy. New transactions are relayed with Dandelion++: they travel along a short random path before being broadcast, which makes the first node to announce a transaction a poor guide to who created it. Both phases run only over hybrid-authenticated peers.
- Resource limits. Nodes verify each proof before relaying it, reserve memory before accepting proof bytes, and enforce global and per-peer limits. Proofs travel once, with the transaction; blocks then propagate in compact form.
Relaying a full block's proofs to several peers requires an uplink of at least 43 Mbps. Encryption protects the contents of connections; it does not hide which machines are talking to each other.
9. What each observer can see
SIWORLD defines precisely what each kind of observer can see, so every user knows exactly where their privacy boundary lies.
| Observer | Can see |
|---|---|
| Anyone reading the chain | Headers and work, slot positions, nullifiers, commitments, ciphertexts, the block's reward mode, public issuance and fund records |
| A node relaying a transaction | The transaction, its arrival time and its fee opening |
| The miner of a block | The transactions it selected, their fee openings, and which slots are its own padding |
| A recipient | The notes paid to it, and when its own payments were included |
| A network peer | Its own connection endpoints and traffic pattern |
| Malware on a user's machine | Whatever that machine's account can read, possibly including keys in use |
Amounts, asset types, senders, recipients and arrival times never reach the chain. To get the most from that privacy, users and operators should keep the following in mind:
- Uniform slot size and committed fees remove specific on-chain signals. They do not guarantee that real and padding transactions are computationally indistinguishable.
- Low traffic, known payments, active probing and off-chain information can all narrow an anonymity set.
- Fee openings are visible to relaying nodes and miners, so a zero opening identifies padding to them.
- Asset issuance is public. Later transfers hide the asset, but its existence and total supply are known.
- Public monitoring must never label slots as real or padding, or publish individual fee openings, endpoints or nullifier timings.
10. Future work
The protocol keeps its validity rules minimal and leaves room for extensions that do not change what makes a transaction valid:
- Recursive compression. Optional aggregation of historical proofs, so that a node could check deleted history without trusting a checkpoint. It is an addition, never a condition of validity.
- Consensus multisignature. Shared spending authority for user payments, up to 2-of-3.
- Mining pools. Pooled block templates that respect the explicit Voyager or Holder mode of each block.
- ARM hardware baseline. A second qualified processor family beside x86-64-v3.
References
- Source code and specifications: github.com/siworld-labs/siworld
- Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008
- Meiklejohn et al., A Fistful of Bitcoins: Characterizing Payments Among Men with No Names, USENIX ;login:, 2013
- Béres, Seres, Benczúr and Quintyne-Collins, Blockchain is Watching You: Profiling and Deanonymizing Ethereum Users, 2020
- NIST, first three finalized post-quantum encryption standards, 13 August 2024
- Infosecurity Magazine, NCSC sets 2035 deadline for post-quantum migration, 20 March 2025
- Craig Gidney, How to factor 2048 bit RSA integers with less than a million noisy qubits, 2025
- Babbush, Gidney, Neven, Drake and Boneh, Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations, 2026
- Gershteyn and Alber, Quantum Horizon: An evaluation of quantum computing as a threat to Bitcoin and Ethereum, 2026
- Plonky3
- Fanti et al., Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees, 2018
SIWORLD is published on 31 October 2026, the eighteenth anniversary of the Bitcoin whitepaper. It builds on the same premise, a payment system that needs no trusted party, and adds the two things the next eighteen years will demand: privacy by default and cryptography that does not depend on elliptic curves.