Feeless transactions were introduced with Stealth's latest major upgrade. The ability to send without a monetary fee is a practically essential but surprisingly rare feature. Most transactions carry an associated cost — ATM charges, credit card fees, gas costs. Stealth eliminates this entirely.
A feeless transaction is one in which neither the sender nor recipient pay a monetary fee. If a user has 3 XST and sends 1 XST, the user still has exactly 2 XST — and the recipient gets a full 1 XST. No deductions, no rounding, no surprises.
Stealth is the only BTC descendant with true feeless transactions. The BTC heritage matters because it unlocks two critical transaction types unavailable on other architectures: multi-signature transactions — where a subset of signatories can authorise a spend — and data-carrying transactions for layer two applications. The BTC-style ledger also enables cryptographic privacy, including StealthAddresses and zk-SNARKs.
Feeless transaction expiration — pioneered by Stealth — means unconfirmed transactions expire after two minutes if not included in a block. This improves user experience and dramatically hardens the network against denial-of-service attacks. If a legitimate transaction is held up, it expires and the user retries with higher feework difficulty rather than waiting indefinitely.
Expiration also neutralises mempool flooding. An attacker must not only fill blocks with spam — they must continuously fill memory with fresh unconfirmed transactions. Every two minutes, all that work expires and must be reproduced from scratch.
A typical node with 4 GB RAM allocates ~1 GB to the mempool. To keep it filled, an attacker must generate nearly 3 million transactions every 2 minutes — each requiring 13 seconds of computation on a high-end Intel Xeon core.
At max difficulty, each core produces 9 transactions per 2-minute window. Filling the mempool requires 320,000 cores operating non-stop. An 8-core machine costs ~$120/month — scaling to 320,000 cores runs approximately $4.8M/month, or $6,700/hr. Only nation-states could sustain this.
This article discusses feeless multi-signature (multisig) transactions, as an example of the unique versatility available to Stealth's feeless transaction mechanism.
The commands below are typically used by computer programs serving as interfaces to the underlying functionality — not by end users manually. Custodial parties, for example, would build their own workflow from these basic commands.
Sending feelessly to a multisig address:
sendtoaddress 2MxfkUWojAic6gPuFjW9fADTiLtJpnSZghd 20
Stealth's feeless transactions allow users to send without fees by solving a cryptographic puzzle ("feework") instead. This is available in StealthSend Desktop, where a simple toggle lets users choose between feeless and fee-based transactions. Feeless is not the same as "free" — it has robust spam protection built in.
Instead of fees, the sender's computer mines the right to send a single transaction — similar to Bitcoin mining, but requiring negligible energy. A cryptographic proof (a "feework output") is attached to the transaction as a digital coupon, highly specific to both the transaction and the precise moment it was created.
The smallest XST transaction is worth about $0.00025. With a fee, that transaction would cost as much as the amount sent — 100% overhead. Bitcoin is even worse: sending the smallest amount would cost nearly $2 in fees. Feeless makes microtransactions viable for streaming, per-minute billing, and voting systems.
Ethereum users know the hazard of under-estimating gas — sometimes losing thousands of dollars on a single failed transaction. Feeless transactions eliminate the need to check balances before sending, simplify tax accounting (each fee is a taxable event), and remove the unpredictability that makes fee-based systems hard to use at scale.
Nano is considered the leader among feeless cryptocurrencies and 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 solution: sort unconfirmed transactions into 129 buckets by account balance, prioritizing less-recently-used accounts, with ~50,000 transactions forming an "Active Election Container" (AEC).
However, Nano has two key vulnerabilities: (1) a spammer can gain advantage by flooding small-balance buckets — 87 buckets serve balances under 0.0001 XNO, requiring only ~$0.40 to populate with 87,000 accounts; (2) Nano transactions never expire, so spam accumulates indefinitely in memory. A spammer could spend months pre-preparing tens of millions of transactions to unleash all at once.
Additionally, Nano's anti-spam measures sacrifice utility — accounts can only submit one unconfirmed transaction at a time, meaning each payee must be paid sequentially.
Imagine two identical rooms. Each room is 3m × 3m × 3m — exactly the same size. These rooms represent the memory (mempool) of a blockchain network.
Now imagine someone starts throwing books into both rooms at the same rate — one book per second, every second. Each book represents a spam transaction.
After 2 minutes there are 120 books. After 10 minutes, 600 books. After an hour, 3,600 books. The books never leave — they just keep piling up. Eventually the room is completely full and nothing works anymore.
After 2 minutes there are also 120 books. But then something happens — feework expires after exactly 2 minutes. So for every new book thrown in, the oldest book disappears. The room never gets fuller than 120 books. The spammer is running on a treadmill — going nowhere.
The key insight: a spammer throwing books into the Stealth room is wasting their time and money. They would need to throw books at an absolutely impossible rate — over 4 million per second — to cause any real problem. Meanwhile, the Nano room just keeps filling up with no natural limit.
TL;DR — Stealth's 2-minute feework expiry is like a self-cleaning room. Nano's room has no drain.
Junaeth is the consensus protocol powering the Stealth blockchain. Based purely on economic principles, it governs (1) who validates and certifies blocks, (2) how validators are rewarded for performance, and (3) how consensus issues are resolved. This four-part series covers its core innovations in depth.
Validators in Junaeth take the form of tokenized assets called StealthNodes, purchased from the blockchain using XST. The purchase funds are irreversibly eliminated from the XST money supply — permanently destroyed, never recycled.
StealthNode pricing uses a type of reverse auction designed to find fair market price equilibrium. Bids are transparent and binding: each valid bid irreversibly purchases a StealthNode. Instances are offered one at a time, each more expensive than the previous. Buying stops when the price gets too high — the most recent successful purchase price estimates market equilibrium.
Two economic forces shape bids: each purchase reduces the XST money supply, and each new StealthNode dilutes the value of existing ones, since all StealthNodes share a fixed reward pool that does not grow with the number of validators. Effectively, bidders are exchanging a fraction of the XST money supply for a fraction of the future reward pool.
This equilibrium stabilizes the validator set. Unlike fully dynamic validator sets that constantly grow or shrink, Junaeth's set grows by at most one periodically and naturally stabilizes — new StealthNodes simply become too expensive to justify purchasing.
The fixed reward pool is split among all StealthNodes proportional to their individual weight, calculated as the square root of (blocks produced − blocks missed). This incentivizes not just production, but consistent quality performance.
In dPoS, rewards are fixed and equal regardless of performance — with no real incentive for quality unless stakeholders actively value it. In practice, political standing often matters more than performance. Junaeth eliminates this entirely: weight is dynamic and a temporary performance drop affects all future rewards permanently.
Even disabled StealthNodes are incentivized to re-enable: every missed block not only foregoes a reward, it lowers the weight multiplier on every future block earned.
When a StealthNode produces a block, it casts a weighted vote for that chain. The chain with the highest cumulative vote weight wins. Heavier StealthNodes therefore have proportionally more influence on resolving forks.
StealthNodes are kept "honest" by focal point game theory: each node votes for the chain most likely to be voted on by all other nodes. Voting on a minority chain means orphaning oneself — losing weight and block rewards on the winning chain while accumulating missed blocks on the losing one. The economic incentive to stay in consensus is powerful and self-enforcing.
Junaeth targets regular five-second block intervals in a heterogeneous environment where nodes may have unsynchronized clocks or experience latencies of seconds or more. Cash itself is asynchronous — Alice can pay Bob today or next Wednesday. But blockchain needs synchrony to prevent double-spending.
Because each UTXO (spendable transaction output) is electronic, it's trivial to create two different transactions spending the same UTXO. When two blocks (X and Y) each contain transactions spending the same UTXO, nodes must decide which to accept — and that decision requires ordering, which requires time.
Junaeth abandons the requirement of a globally synchronous clock. No node polls any other node to establish consensus on what time it is — such consensus is impossible given that polling itself is subject to unpredictable latencies.
Instead, time is kept by the blocks themselves. Each block carries a timestamp (for user benefit) and a height that must be exactly one greater than its predecessor. Block heights are the ticks of Junaeth's network clock. Validity decisions come from (1) sequential ordering of blocks and (2) the motivation to agree with the majority — driven by focal point game theory.
This approach is robust to forks: a validator on a minority branch will eventually reorganize to the winning chain, not because of timestamps, but because it's economically irrational to keep building on a chain no one else is building on.
StealthNode performance can be assessed with several metrics, all available on stealthmonitor.org. The three key metrics are average block interval, hourly blocks missed, and block interval RMSD.
Calculated by summing all block intervals and dividing by the number of blocks. A target of 5.000 sec is ideal. This metric is forgiving — a 6-second block is offset by a 4-second block, keeping the average stable. As of the time of writing: 5.0116 sec, representing ~0.2% missed blocks over 24 hours.
With 5-second blocks, the Stealth blockchain produces ~17,280 blocks every 24 hours. Common causes of missed blocks include network latency, temporary disconnects, ISP outages, or denial-of-service attacks. As of the time of writing: 32 blocks missed in 24 hours (~0.2%), consistent with the average block interval metric.
RMSD captures how much individual block intervals deviate from the 5-second target on average. A single block at 6 seconds gives an RMSD of 1 second for that block. Lower is better. As of writing: 0.25 seconds — meaning the average block deviates from the target by just a quarter of a second. This barely perceptible deviation is dominated by the occasional missed block.
Weight governs both earnings and consensus influence. The square root function was chosen for its scaling properties: it allows newer nodes to partially catch up with older ones assuming equivalent performance, while ensuring older well-performing nodes are never fully overtaken. Weight is dynamic — even a temporary performance drop affects all future rewards, as weight is constantly growing for all well-performing nodes.
Junaeth's exceptional efficiency and scalability stem partly from a hybrid ledger that separates two types of data: the blockchain itself (which stores all transfers between addresses) and the registry (a stateful data structure tracking validator performance and rewards). This separation dramatically reduces disk usage, memory, and network bandwidth.
Without this separation, every block reward would be stored on-chain — increasing Stealth's blockchain growth by approximately 1.5 GB per year, an easily avoided inefficiency.
The Stealth blockchain is a distributed data structure of ordered blocks, each composed of transactions, each composed of inputs (money spent) and outputs (money received). Everything is implicitly ordered — block by block, transaction by transaction, input and output by input and output.
This ordering means every transaction is a state transition: the ledger has a state before and after each transaction. Ordering is subject to one hard rule: no balance may ever go negative.
The registry exists entirely in memory on nodes running the Stealth client. It has three components: (1) a mapping of all StealthNodes by ID, containing public keys for owner, manager, delegate and controller authorities; (2) the queue — the pseudorandom ordering of StealthNodes for the current block-signing round, tracking time windows, slots, and missed blocks; and (3) the registry ledger — a list of pubkeys and their unclaimed block reward balances.
When a StealthNode produces a block, its manager and delegate pubkeys are credited proportionally. For example, with a 20% delegate split and a 1 XST reward, the delegate gets 0.2 XST and the manager gets 0.8 XST credited in the registry ledger. These can be claimed on-chain in a manner similar to spending XST — but until claimed, they stay off-chain, keeping the blockchain lean.
Both zk-SNARKs and ring signatures were designed to protect transaction privacy on public blockchains — but they achieve this goal through radically different mechanisms and with dramatically different security properties. Understanding the distinction is essential for evaluating any privacy-focused cryptocurrency.
A ring signature is a cryptographic scheme in which a transaction is signed by one member of a predefined group (the "ring"), but observers cannot determine which member actually signed. The signer selects a set of other public keys as decoys, blending their true identity into the group. Monero is the most prominent blockchain to use ring signatures for sender privacy.
The core privacy promise is plausible deniability: if your transaction is one of many in a ring, an outside observer cannot definitively link the transaction to you. However, this deniability is statistical and probabilistic — not mathematical. The larger the ring, the more obfuscation. But "more obfuscation" is not the same as "cryptographic proof of privacy."
A zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) is a form of zero-knowledge proof. It allows one party (the prover) to convince another party (the verifier) that a statement is true — without revealing any information beyond the truth of the statement itself. In a blockchain context, this means a sender can prove that a transaction is valid (no double-spend, correct amount, authorized) without revealing the sender, receiver, or amount.
The privacy guarantee of a zk-SNARK is not probabilistic — it is mathematical and absolute. The verifier learns nothing except that the proof is valid. This is a fundamentally different class of privacy assurance than ring signatures provide.
The signer selects a ring of n public keys. Their real key is one of n candidates. The signature is cryptographically valid for any member of the ring — so the true signer is hidden in the crowd. Privacy scales with ring size, but never reaches zero-information disclosure.
Critically: the set of possible signers is publicly visible on-chain. Every ring member — including decoys — is recorded. Blockchain analysis firms can apply heuristics, cross-reference outputs, and use chain-reaction tracing to narrow down candidates over time.
The prover generates a cryptographic proof that encodes the entire validity of a transaction — inputs, outputs, balances — without revealing any of those values. The verifier checks the proof's validity in milliseconds. No decoys are selected. No candidate set exists. The transaction is provably valid and provably private simultaneously.
There is no statistical model to attack. No chain-reaction tracing. No heuristic that degrades privacy over time. The privacy is encoded in the mathematics of the proof itself — and it does not weaken as chain data accumulates.
Ring signature privacy is not static. Because all ring members are visible on-chain, each member of a ring will eventually appear in another ring as a real spender or additional decoy. This creates a graph of probabilistic relationships that blockchain analysis firms exploit through techniques like "chain-reaction" analysis — where eliminating confirmed decoys from one ring allows real signers in another to be identified.
Several academic studies have demonstrated that a significant portion of early Monero transactions — particularly those using small ring sizes — can be traced with high confidence. The Monero community has responded by mandating larger ring sizes over time, but this is an arms race between obfuscation and analysis, not a mathematical guarantee. Ring signatures also cannot hide transaction amounts without additional schemes (like RingCT), adding further complexity and attack surface.
Each additional decoy in a ring signature adds data to the transaction. A ring-16 transaction is roughly 16× larger than a trivial single-key signature. As blockchains mandate larger rings for stronger privacy, transaction throughput suffers and blockchain storage requirements grow proportionally.
A zk-SNARK proof is typically just a few hundred bytes — regardless of how complex the underlying statement being proved. Hiding sender, receiver, and amount simultaneously produces the same compact proof as hiding only one. This "succinct" property is baked into the name: zk-SNARK.
Verifying a ring signature requires checking the mathematical relationship across all n ring members. A ring-16 transaction takes roughly 16× longer to verify than a trivial signature. On high-throughput chains, this overhead compounds into a meaningful scalability constraint.
Verifying a zk-SNARK is an O(1) operation — it takes the same time regardless of the size or complexity of the underlying proof. This makes zk-SNARKs highly compatible with high-throughput blockchain architectures, where thousands of transactions per second must be validated.
zk-SNARKs require a "trusted setup" ceremony to generate the initial cryptographic parameters. If this ceremony is compromised — if the toxic waste from parameter generation is not destroyed — an attacker could theoretically forge proofs. This is a genuine and important consideration.
However, modern zk-SNARK implementations address this through multi-party computation (MPC) ceremonies, where hundreds or thousands of independent participants each contribute randomness. The toxic waste is only dangerous if every single participant is compromised — an essentially impossible condition in a well-run ceremony with hundreds of participants from across the globe.
Ring signatures, by contrast, require no trusted setup. But this advantage must be weighed against the fundamental statistical weakness of the privacy model: ring signatures cannot provide what zk-SNARKs can — a mathematical proof that nothing has been disclosed.
Stealth's architecture was designed from the ground up with real payment throughput in mind. The combination of 5-second block times, a 1 MB block size ceiling, and a feeless transaction model creates a system capable of handling tens of thousands of transactions per minute — with clear, protocol-level pathways to scale further without changing the core security model.
Stealth targets a block every 5 seconds, defined directly in the protocol source as QP_TARGET_SPACING = 5 in QPConstants.hpp. That yields 12 blocks per minute, 720 per hour, and 17,280 per day.
At the current 1 MB block size, with a single CPU core verifying feeless transactions, Stealth achieves 917 TPS — already comfortably ahead of Visa's widely cited 1,700 TPS average when you factor in multi-core parallelism. The 1 MB block size is not a ceiling: it is a starting parameter. Increasing the block size to approximately 10 MB unlocks 9,362+ TPS on a single core. And because feeless transaction verification is embarrassingly parallel, a validator running a 16-core CPU can process transactions concurrently — reaching approximately ~150,000 TPS.
On fee-based blockchains, throughput is limited not just by block space but by economics. When fees rise under demand, small transactions become uneconomical — a $0.10 fee on a $0.001 micropayment renders the payment nonsensical. Users either wait for cheaper windows or abandon on-chain activity entirely. The result is artificial throughput suppression: users who could transact, don't.
Stealth's feeless model inverts this entirely. Instead of paying a monetary fee, each transaction sender computes a small Argon2 memory-hard proof-of-work. The PoW is calibrated to cost approximately the same as a minimal fee in CPU time — but it costs the network nothing in block-space economics, and it costs the user nothing in money. A sender firing off 10,000 micropayments at $0.001 each faces no per-transaction cost that would make the activity uneconomical. The PoW is the fee — and it scales with the sender's hardware, not with network demand.
When blocks fill up, fee markets emerge. Users bid against each other for block space. Fees spike. Small transactions get priced out first. Miners rationally include only the highest-fee transactions. The chain's nominal TPS capacity is never reached in practice because economic pressure reduces participation before the technical limit is hit.
This is not a hypothetical: Bitcoin's mempool regularly contains hundreds of thousands of pending transactions during demand surges, with fees rising to $50+ per transaction — making sub-$100 payments economically irrational.
Because there is no fee market, there is no economic deterrent to transacting. High demand does not increase per-transaction cost. Block producers do not prioritize transactions by fee size — every valid PoW-stamped transaction is equal. The result is a system where throughput can grow toward its technical ceiling organically, without users being priced out along the way.
The Argon2 PoW requirement does impose a small computational delay on senders — by design. This functions as a natural spam deterrent. Flooding the network with millions of transactions requires genuine CPU work proportional to the flood, making spam attacks costly in hardware terms rather than in money.
The 1 MB block size is the current protocol parameter — not a hard architectural limit. Increasing it to ~10 MB scales single-core throughput from 917 TPS to over 9,362 TPS, a 10× improvement with no changes to the consensus mechanism, the feeless model, or the security model. Unlike Bitcoin, where block size became a years-long ideological conflict, Stealth's architecture allows this parameter to be updated through protocol governance in a coordinated, non-disruptive way.
Beyond block size, Stealth's feeless transaction verification is designed to be parallelised across CPU cores. A validator running a 16-core processor can verify incoming transactions concurrently — the workload distributes cleanly because each feeless Argon2 PoW check is independent. This takes the 9,362+ TPS single-core figure and scales it toward ~150,000 TPS — a number that rivals dedicated payment processors, not just other blockchains.
The existing production configuration. Already faster than Bitcoin, Ethereum, Litecoin, and Monero on raw TPS. Feeless transactions mean every one of those 917 TPS is economically viable for micropayments — not just large-value transfers. This is the baseline, not the ceiling.
A block size increase to ~10 MB requires no consensus mechanism changes and no modifications to the feeless model or cryptographic proofs — only a parameter update and a coordinated node upgrade. Junaeth's validator reputation system makes coordinated upgrades smoother than in leaderless consensus models. This single step surpasses Visa's peak stated capacity on a single CPU core.
Feeless transaction verification (Argon2 PoW checks) is embarrassingly parallel — each check is independent, so validators can distribute the workload across all available CPU cores. A 16-core validator reaches approximately 150,000 TPS. This is not a theoretical extrapolation: it follows directly from the independence of per-transaction PoW verification.
For sustained burst workloads beyond even multi-core capacity, payment channel networks settle millions of off-chain transactions in single on-chain entries. XST's feeless architecture is particularly well-suited here: opening and closing channels incurs no fee, dramatically lowering the barrier compared to fee-based chains where channel economics only work above a minimum payment threshold.
Raw TPS numbers only tell part of the story. A chain that can theoretically handle 9,362 TPS but charges $0.50 per transaction has an effective throughput of zero for sub-$1 payments — because no rational user will pay $0.50 to send $0.10. XST's feeless architecture means that every transaction within the throughput envelope is also economically viable, regardless of payment size.
Consider a micropayment use case at $0.001 per transaction, targeting 10,000 transactions per minute. On a fee-based chain with a $0.01 minimum fee, the fee cost alone would be $100/minute — 10× the value of the payments themselves. On XST, the same 10,000 tx/min costs senders only the small Argon2 PoW computation and consumes a modest fraction of available block space — whether that block space is 1 MB or 10 MB. The throughput ceiling and the economic viability ceiling are always the same number. That is not an accident.