Document
Wiki / Deep Reference
Primitive
Feework · Argon2d
Expiry
24 blocks · 2 minutes
Client
v3.3.4.0
Wiki · Feeless · Spam-Resistant · Throughput

Work, not fees.

A cryptographic coupon — one second of CPU time — replaces the per-transaction fee. The economics of micropayments become viable. Feeless is not free — feework is the shape of anti-spam when there is no fee market.

Feeless Argon2d 24-block expiry Memory-hard Multisig-capable ~150k TPS
Feework lifecycle. Mine · bind · broadcast · (include or expire). 2-minute window.
Block time
5s
QP_TARGET_SPACING · Junaeth
Feework
Argon2d
Memory-hard · 16-byte nonce
Expiry
24 blk
2-minute window · then invalid
Verify advantage
~9,362×
One hash to verify · many to produce
Multi-core TPS
~150k
16-core · parallel verification
01 · THESIS

Feeless is not free.

Work replaces money · Coupon not tip

On a fee-based chain, the fee is the ledger's tax on motion. Every call, every stream frame, every sensor reading pays again. At machine frequency and micropayment size, the tax exceeds the payload and the model collapses.

Stealth takes the fee off the critical path entirely on stealthCORE. The sender does the work. The network charges nothing. Spam is still priced — just in seconds of compute, not dollars of block space.

02 · FEEWORK

The coupon, the nonce, the binding.

Argon2d · 16-byte nonce · ceiling 0x0006ffffffffffff

A feework output is a digital coupon attached to a feeless transaction. Each coupon carries a 16-byte proof-of-work nonce, found by hashing the transaction data with Argon2d until the output falls below a fixed ceiling. The coupon is highly specific to both the transaction and the precise moment it was created. Verification is one hash. Production is many.

FEEWORK · ARGON2D

Illustrative trace
algorithm: argon2d — memory-hard
nonce: 16 bytes
ceiling: 0x0006ffffffffffff
binding: tx-hash · block-height · difficulty
produce: ~1s on desktop CPU
verify: one hash
advantage: ~9,362× validator over spammer

# if hash(tx · nonce · height) < ceiling → coupon valid
# otherwise: increment nonce, hash again, repeat
Memory-hardness matters. Argon2d deliberately requires RAM during the hash — more as difficulty rises. An empty block needs 262 KB; a 20%-full block, 819 KB. A GPU's advantage over a CPU shrinks when the bottleneck is memory bandwidth rather than arithmetic throughput. To our knowledge, Stealth is the only cryptocurrency to use a memory-hard hash (Argon2d) as its per-transaction anti-spam primitive in place of a fee.

Structure · Coupon → Difficulty → Binding

  1. The feework coupon

    Attached to every feeless transaction. Proves the sender's computer did at least one second of computational work. The production cost equals renting a CPU core for one second. Work substitutes for money.
  2. Committed difficulty

    The coupon specifies the difficulty of the calculation upfront. A spammer must commit to a difficulty level before calculating feework — and must exceed the difficulty legitimate users are willing to tolerate. Legitimate users can outbid spammers by raising their own difficulty, or by paying a tiny fee instead.
  3. Block-specific binding

    Feework binds to a specific recent block height — committing to both a moment in time and a specific fork. Failed transaction feework cannot be reused. An attacker must continuously produce fresh work, creating a relentless and expensive burden.
03 · EXPIRY

Unconfirmed transactions expire in 24 blocks.

Stealth-pioneered · 2-minute window

A feeless transaction that doesn't make it into a block within 24 blocks · 120 seconds is invalidated. The spammer's work expires — and must be redone from scratch.

Transaction expiration is a Stealth-pioneered innovation. Unconfirmed feeless transactions are valid only inside a rolling 24-block window — about two minutes — tied to the block height the feework committed to.

Expiration does two jobs at once. For users, a held-up transaction doesn't wait indefinitely — it invalidates cleanly, and the sender retries with higher feework difficulty rather than staring at a stuck pending state. For spammers, it neutralises mempool flooding at the root.

Without expiry, a spammer at just 100 extra TPS could fill a 1 GB mempool in roughly 11 hours. With 24-block expiry, sustaining that same flood indefinitely requires over 4,000,000 TPS of fresh feework — every two minutes, forever.

no expiry: 100 TPS  →  1 GB mempool flooded in ~11h
24-blk expiry: sustained flood needs >4,000,000 TPS
Δ: four orders of magnitude harder

Every two minutes, stale feework vanishes from memory. The mempool has a drain. Spam that arrived at the top of the hour is gone by the five-past.

Analogy

A thought experiment — two identical rooms.

Picture the mempool — the waiting area where unconfirmed transactions sit before they're bundled into a block — as a small room, roughly three metres on a side. Now imagine two of those rooms, side by side. They're identical. Same volume. Same door. Same owner outside.

A vandal walks up and starts throwing books through the door of both rooms — one book per second, every second. Each book is a spam transaction; the rate is a cheap, sustained flood. The only thing that differs between the two rooms is a single rule written on the wall — do books expire, or do they stay forever? — and that rule is the entire difference between a chain that can be DoS'd to a halt and one that cannot.

  • Room= the mempool (unconfirmed-tx buffer in memory)
  • Book= one broadcast transaction with feework attached
  • Rule= do books expire on their own, or must a block producer carry them out?
Room A · Nano

The rule: once a book is in the room, it stays there until a block producer physically carries it out. Books never expire on their own.

Fills up forever.

After 2 minutes — 120 books. After 10 minutes — 600. After an hour — 3,600. The books never leave. Eventually the room is full and nothing new fits — legitimate users get turned away at the door.

This isn't hypothetical. In early 2021 Nano was hit with a months-long spam attack that peaked at nearly 5 million transactions per day. Because Nano transactions never expire, a determined attacker can also pre-prepare tens of millions of transactions over months and unleash them all at once.

Mempool · books over time

t = 0 → accumulates indefinitely
Room B · Stealth XST

The rule: every book's feework is stamped with a block-height expiry. Exactly 2 minutes after it lands, the book vanishes on its own — no block producer required.

Never exceeds 120 books.

After 2 minutes — 120 books. But then something happens: feework expires after exactly 2 minutes. For every new book thrown in, the oldest one disappears. The count stays flat at 120, forever.

The room is self-cleaning. The vandal is running on a treadmill — going nowhere. To actually overwhelm the room, he'd need to throw books faster than 4,000,000 per second — and the work to produce each book is Argon2d, memory-hard, bounded by his RAM budget rather than his CPU.

Mempool · books over time

t = 0 → capped at 120

TL;DR. Stealth's 2-minute feework expiry is like a self-cleaning room. Nano's room has no drain.

04 · MULTISIG

The world's first feeless multisig.

P2SH · n-of-m · spam-resistant round trip

Stealth completed the world's first feeless (spam-resistant) multi-signature round trip — both sending to and spending from a multisig account without a monetary fee. Nano, the only other cryptocurrency with true feeless transactions, has no multisig support and no plans to introduce it. Multisig lives on the BTC-style ledger; Stealth is the only BTC descendant where multisig is also feeless.

Security · 01

Unauthorised spending requires conspiracy.

When a company holds a large balance in a single-signature account, one compromised key drains the treasury. Multisig forces a conspiracy across multiple individuals. Game theory makes such conspiracies unstable — any defector can turn the others in and have something to gain.

Security · 02

Compromised keys become useless alone.

If a signatory's key is stolen, the thief can't send anything. They need to convince a valid subset of the other legitimate signatories to co-sign — which, in practice, is not going to happen. A stolen key in an n-of-m multisig is a key that does nothing.

Security · 03

Lost keys don't freeze the funds.

If a signatory dies and their key is lost, the remaining signatories can still spend — as long as the account is structured n-of-m with n < m. This is the standard configuration. Single-signature wallets have no equivalent; key loss is terminal.

Adoption

Custodians run on multisig.

Most users can't be expected to secure private keys themselves — especially in times of urgency. They rely on exchanges and custodians, who in turn depend on multisig for their own security standards. Feeless multisig is therefore essential for mainstream adoption, not a niche feature.

Technical reference · how to send

The commands below are used by programs serving as interfaces to the underlying functionality — not by end users manually. Custodial parties build their own workflows from these primitives. Sending feelessly to a multisig address is the same sendtoaddress command; the multisig nature is carried by the P2SH address prefix.

sendtoaddress 2MxfkUWojAic6gPuFjW9fADTiLtJpnSZghd 20
  • Sending to multisig ↗
  • Transaction listing ↗
  • Spending from multisig ↗
  • Spend tx listing ↗
05 · SPAM

Nano is the benchmark. It isn't close.

Feeless-peer comparison · two vulnerabilities

Nano is widely considered the leader among feeless cryptocurrencies and is the most logical competitor to compare against. In early 2021, Nano suffered a months-long spam attack peaking at nearly 5M transactions per day. Their response was architectural: sort unconfirmed transactions into 129 buckets by account balance, prioritise less-recently-used accounts, and form a ~50,000-transaction Active Election Container.

Vulnerability · 01

Small-balance buckets are cheap to flood.

Of Nano's 129 balance buckets, 87 serve accounts under 0.0001 XNO. Populating those buckets with 87,000 attacker-controlled accounts costs approximately $0.40. The bucket structure was meant to price legitimate users fairly; it also prices attackers at basement rates.

Vulnerability · 02

Transactions never expire.

Nano has no analogue to Stealth's 24-block expiry. Spam accumulates in memory indefinitely. A patient attacker can pre-prepare tens of millions of transactions over months — then release them all at once as a single coordinated burst. There is no architectural counter.

There is also a utility cost: Nano accounts can only submit one unconfirmed transaction at a time. Each payee must be paid sequentially. Stealth's UTXO model — inherited from Bitcoin — supports full parallel spend across independent note outputs.

Attack scenario XST · Result Nano · Result
Mempool flooding Requires >4M TPS (24-block expiry) Transactions never expire
Pre-prepared spam burst Feework expires in 2 min Accumulates indefinitely in memory
GPU DoS at 20% block fill ~$14,000 of GPUs needed Bucket structure exploitable for ~$0.40
UX during attack Pay tiny fee · unaffected Sequential tx confirmation
Parallel processing Full UTXO parallelism Single unconfirmed tx per account
"Stealth's feeless protocol was designed to thwart any conceivable exploit that may arise when offering feeless transactions."
— Stealth R&D LLC
06 · COST

The attack budget is a nation-state line item.

Memory · Compute · GPU economics

At maximum feework difficulty, the cost to keep Stealth's mempool saturated runs into millions of dollars per month. The numbers below are not aspirational — they fall directly out of the Argon2d work function, the 2-minute expiry window, and the block-binding requirement working together.

Memory requirement

2.88M transactions every 2 minutes.

To saturate a 1 GB mempool at maximum feework difficulty

A typical node with 4 GB of RAM allocates roughly 1 GB to the mempool. Keeping it filled requires the attacker to generate nearly 2,880,000 transactions every two minutes — each requiring ~13 seconds of computation on a high-end Intel Xeon core.

Compute requirement

320,000 CPU cores · $6,700 per hour.

Continuous — 720 hours a month

At max difficulty, each core produces 9 transactions per 2-minute window — so covering all 2,880,000 requires 320,000 cores running non-stop. An 8-core machine runs ~$120/month; scaling to 320,000 cores runs approximately $4.8M/month, or $6,700/hour. Only nation-states could sustain this.

GPUs don't help. A Tesla V100 ($7,000) manages only ~88 feeless TPS under Argon2d. Filling blocks to just 20% capacity takes more than two such GPUs working continuously — and legitimate users can always outbid spammers by specifying higher hardness or paying a tiny fee. Memory-hard hashing flattens the attacker's structural advantage.

"A denial of service spam attack on Stealth's feeless transaction system is prohibitively difficult — and will always remain so by design."
— Stealth R&D LLC · July 1, 2021
07

Throughput.

5-second blocks. 917 TPS on a single core. ~150,000 on sixteen.

Junaeth targets a 5-second block interval (QP_TARGET_SPACING = 5 in QPConstants.hpp) — 12 blocks per minute, 720 per hour, 17,280 per day. Throughput scales along three orthogonal axes: block-size, core-count, and the micropayment multiplier that only a feeless chain can access.

STAGE · 01

917 TPS

1 MB block · single core · feework-verify

Baseline. Every node in the network meets this ceiling today with conservative parameters. Already 130× Bitcoin's observed throughput.

STAGE · 02

9,362+ TPS

~10 MB block · single core · feework-verify

Larger blocks lift raw throughput ~10×. The verifier's cost advantage over an attacker is a separate quantity, set by Argon2d's mining-vs-validation asymmetry.

STAGE · 03

~150,000 TPS

10 MB block · 16-core parallel verify (9,362 × 16)

Verifier-side parallelism. Signature checks, feework validation, and UTXO updates are embarrassingly parallel at the block level.

Where this puts Stealth.

Chain Block time Block size Observed TPS Feeless
Stealth XST 5 s 1 – 10 MB 917 – 150,000 Yes
Bitcoin ~600 s 1 – 4 MB ~7 No
Monero ~120 s Dynamic ~30 – 50 No
Litecoin ~150 s 1 MB ~56 No
Ethereum ~12 s ~1.8 MB (gas) ~15 – 30 No

The micropayment multiplier.

A fee chain's effective throughput for sub-dollar payments is zero. A feeless chain's effective throughput is its observed throughput.

FEE CHAIN

$0.001 × 10,000 per min

= $10.00 of value moved
= $100.00 of fees paid (at $0.01/tx)

Economic collapse. Nobody sends $0.001 when the fee is 10×.

FEELESS CHAIN

$0.001 × 10,000 per min

= $10.00 of value moved
= $0.00 of fees paid (Argon2d work only)

Micropayment market is reachable. So are IoT, machine-to-machine, and streaming.

JUNAETH · 5-SECOND BLOCK QUEUE
t+00BLK · N
t+05BLK · N+1
t+10BLK · N+2
t+15BLK · N+3
t+20BLK · N+4

Every 5 seconds, the next validator in Junaeth's pre-scheduled rotation publishes the next block. No mining race. No fork. No wait.

08 · STEALTHPRIVATE

The shielded sidechain.

Confidential value · zk-STARK

Every transparent chain leaks. Amounts, addresses, and the graph that connects them are permanent and public. stealthPRIVATE removes the graph entirely. Value crosses from Core into a shielded pool where a transfer reveals nothing — no sender, no receiver, no amount.

This is not a mixer or an overlay. It is the ledger: balances exist only as commitments, and every spend is proven correct in zero knowledge before the network accepts it.

What a shielded note is. A note is a cryptographic commitment stored on-chain — cm = H(amount ‖ owner ‖ salt). It binds an amount and an owner, yet reveals neither. Sender, receiver, and amount are not obfuscated; they are mathematically absent from the public record. The chain stores only commitments and a growing set of spent-markers.
Nullifier · 01

Spent once, provably.

To spend a note, its owner publishes a nullifier — a one-way derivative that marks the note consumed without revealing which note it was. The network rejects any repeat, so double-spends are impossible while the link between spend and note stays hidden.

Proof · 02

Correct without disclosure.

A spend bundle — input, output, optional change — ships with a zk-STARK proof that the transfer is balanced and authorised. Roughly 40 KB per transfer, verified in ~0.8 ms. The verifier learns only one thing: that the rules held.

09 · BRIDGE

Crossing the peg.

Lock · mint · burn · release

Shield · XST → shielded note

  1. Lock on Core

    The sender locks XST into the bridge custody address on stealthCORE. The lock is a transparent, verifiable transaction on the public chain.
  2. Record without identity

    The bridge records the deposit — Core transaction, amount, custody address — but stores no sender and no recipient shielded address. The link between the two chains is never written down.
  3. Mint on Private

    An equivalent shielded note is minted on stealthPRIVATE to the recipient. From this point the value moves privately, unlinked from the public deposit that funded it.

Unshield · shielded note → XST

  1. Burn on Private

    The owner burns a shielded note on stealthPRIVATE and names any XST destination address they choose.
  2. A free destination

    That destination is a free parameter — there is zero enforced linkage between where value entered the pool and where it leaves. The anonymity set is every historical depositor.
  3. Release on Core

    The federation releases the XST from custody on Core to that address, and the pool shrinks by exactly the burned amount.
pool solvency: netSupply = nTotalMinted − nTotalBurned
meaning: shielded value on Private always equals the XST locked on Core
How custody works. Every locked deposit is backed 1:1 and held by a bonded n-of-m federation of StealthNodes, selected per-deposit by sortition so no single group holds the pool. Releasing custodied XST requires a threshold of that committee to sign. The peg is federated, not trustless: its safety rests on an honest supermajority of custodians — an economic guarantee backed by bonded stake, not a cryptographic one. Shielded privacy is cryptographic; peg custody is bonded trust. The two are separate layers, and the wiki names each for what it is.
10 · DISCLOSURE

Selective transparency, on the sender's terms.

Outgoing viewing key · voluntary

A shielded payment is invisible by default. But the sender holds an Outgoing Viewing Key — a capability strictly weaker than the power to spend — that can reopen a single one of their own payments on demand. The choice is the sender's, one payment at a time.

The result is a portable proof: this recipient, this amount, this memo — verifiable by anyone, offline, revealing no other part of the sender's history.

Seal → Recover → Verify

  1. Seal, at send time

    When the payment is made, the wallet seals a record of the output note under the sender's viewing key. Nothing extra is published on-chain; only the sender can later reopen it.
  2. Recover, to prove it

    When the sender chooses to disclose, the wallet reopens that one note into a portable proof — recipient, amount, memo — containing no key material and no other payment.
  3. Verify, by anyone

    A third party recomputes the note's commitment hash — which has exactly one valid opening — and checks its Merkle inclusion against a real on-chain anchor. It matches the chain, or it doesn't.
Reveals · 01

Exactly one payment.

The recipient, the amount, and the memo of the single disclosed payment — plus proof that it exists on-chain at a specific position under a specific anchor. Enough for a receipt, a refund, or an audit of that one transfer.

Never · 02

Nothing else.

No other payment, no balance, no history, and none of the inputs that funded it. The viewing key itself never leaves the wallet — not in a backup, not in an export, not in the proof. Disclosure is sender-cooperative by design: a tool for proving a payment, not for compelling its reveal.

11 · QUANTUM

Private after the quantum computer.

zk-STARK · no trusted setup

Most privacy coins prove their transfers with zk-SNARKs over elliptic curves — the exact structure a quantum computer running Shor's algorithm dismantles. stealthPRIVATE uses pure zk-STARKs instead.

Their soundness reduces to the security of a hash function, with no trusted setup and no SNARK wrapper. The randomness that seeds each proof is public. Nothing to ceremony away, nothing for Shor to unwind.

Privacy layer · 01

Post-quantum by construction.

Shielded proofs on stealthPRIVATE are zk-STARKs — hash-based, curve-free. Their confidentiality does not degrade when large quantum computers arrive.

Base layer · 02

Classical today — and we say so.

Transparent XST signatures on stealthCORE remain classical elliptic-curve signatures, like Bitcoin's. That half is not post-quantum yet, and the claim is scoped to the privacy layer rather than overstated across the whole protocol.

Pure STARKs, no wrapper. The proof system is hash-based end to end — Winterfell over the Goldilocks field with a Rescue-Prime hash — so the post-quantum and no-trusted-setup properties hold all the way through, not just at an outer layer wrapping a curve-based core.
12

Specifications.

The feeless protocol and the shielded layer, in hard numbers.
Block time5 secondsQP_TARGET_SPACING = 5
Blocks per day17,28012 / min · 720 / hr
ConsensusJunaethMainnet · May 2021
StealthNodes~100Bonded validator set · reverse-auction
Feework algorithmArgon2dMemory-hard PoW coupon
Nonce size16 bytesPer-transaction
Difficulty ceiling0x0006ffffffffffffMax feework hardness
Tx expiry24 blocks (~2 min)Unconfirmed feework drops
Validator advantage~9,362×Verify / mine asymmetry
Base TPS9171 MB · single core
Scaled TPS9,362+~10 MB · single core
Parallel TPS~150,00016-core verify
Transaction modelUTXOBTC-descended
MultisigFeeless · world's firstP2SH · any M-of-N
Fee for feeless tx$0Argon2d work, not currency
Shielded chainstealthPRIVATEzk-STARK private sidechain
Shielded proof systemzk-STARKWinterfell · Goldilocks · Rescue-Prime
Trusted setupNoneHash-based · public randomness
Shielded proof size~40 KBVerifies in ~0.8 ms
Bridge custodyn-of-m federationBonded StealthNodes · per-lock sortition
Peg backing1:1 XSTnetSupply = minted − burned
Payment disclosureOutgoing viewing keyVoluntary · per-payment