Monero Stealth Addresses, Subaddresses and View Tags Explained

Ring signatures hide who sent a Monero transaction. Hiding who received it is the job of stealth addresses, a scheme that turns your one public address into an unlimited supply of unlinkable one-time addresses. This guide covers how stealth addresses work, how subaddresses build on them, and how view tags made scanning for your payments much faster.

The problem with public addresses

On Bitcoin, the address you hand out is the address that shows up on the blockchain. Post a donation address and anyone can add up every payment you received, see when you spent it, and follow the coins onward. Reusing an address is a well-known privacy risk, and generating a new one for every payer is awkward.

Monero takes a different route: the address you share never appears on-chain at all.

Your Monero keys in 60 seconds

A standard Monero wallet has two key pairs:

Your 95-character standard address (starting with 4) is just the two public keys, A (view) and B (spend), encoded together with a checksum.

This split is useful. You can give someone your private view key so they can see incoming payments, for an audit or a point-of-sale terminal, without giving them any power to spend. The Moneropedia calls this design “private by default and optionally semi-transparent”. Details on handling these keys safely are in our Wallets section.

How a stealth address is created

When someone pays you, their wallet does the following, simplified:

1. Generates a random one-time secret r for the transaction and publishes the matching public value R = r·G in the transaction. This is the transaction public key.
2. Computes a shared secret with you using your public view key: roughly r·A. Only you can compute the same value from the other side, as a·R, using your private view key a.
3. Derives a one-time output key: P = Hs(r·A, i)·G + B, where i is the output’s index in the transaction and B is your public spend key.
4. Writes only P to the blockchain as the destination of that output.

P looks like a random public key. Nothing in it reveals A or B, and two payments to the same address produce two completely unrelated P values.

How your wallet finds the payment

Your wallet scans every new transaction. For each one it takes R, computes a·R with your private view key, and checks whether Hs(a·R, i)·G + B equals any output key P in the transaction. If it matches, the output is yours.

To spend that output, you need its one-time private key, x = Hs(a·R, i) + b, which requires your private spend key b. That is why the view key alone can find payments but never move them.

Key point: Stealth addresses mean a blockchain observer cannot tell that two outputs went to the same person, even if both were paid to the exact same published address.

Subaddresses: one wallet, unlimited addresses

Stealth addresses protect you on-chain. Off-chain there is a different problem: if you give the same address to your employer, your landlord and an online shop, those three parties can compare notes and know they paid the same person.

Subaddresses, which have been in the reference wallet since 2017, fix this. From one seed your wallet can generate a practically unlimited number of addresses, organised into accounts and indexes. They:

• Start with 8 on mainnet (standard addresses start with 4).
• Cannot be linked to each other or to your main address by anyone who lacks your private view key.
• All arrive in the same wallet, so one seed backs them all up.

Mathematically, subaddress number i has its own spend public key D = B + Hs(a, i)·G and view public key C = a·D. Senders pay a subaddress using a slightly different transaction-key method, and your wallet keeps a lookup table of the subaddress spend keys it has generated so it can recognise payments to any of them.

Practical ways to use subaddresses

1. One per payer or service. Give your exchange, your employer and each customer their own subaddress.
2. One per purpose. Keep donations, sales and personal receipts apart so you can tell incoming funds apart at a glance.
3. One per invoice. Merchants can generate a fresh subaddress for every order to match payments to orders without payment IDs.

Tip: Wallets usually scan only a certain number of subaddresses ahead (the “lookahead”). If you restore a wallet that used many hundreds of subaddresses, you may need to raise the lookahead in settings before old payments appear.

Subaddresses vs integrated addresses vs standard addresses

Integrated addresses bundle your main address with an encrypted 8-byte payment ID so the receiver can tell which customer paid. They still work, but because they all contain the same underlying main address, anyone holding two of them can see they belong to the same wallet. Subaddresses give the same “who paid?” ability without that leak.

Warning: Unencrypted (“long”) payment IDs were deprecated years ago and are no longer supported by the official wallets. If a service still asks you to attach a 64-character payment ID, its integration is out of date.

View tags: faster scanning, same privacy

Scanning is the slow part of running a Monero wallet. For every output on the chain, your wallet has to work out whether it belongs to you, which involves elliptic-curve operations.

The August 2022 network upgrade added view tags. When a sender creates an output, they also compute one byte derived from the shared secret, view_tag = first byte of H("view_tag", r·A, i), and store it alongside the output.

Your wallet still computes the shared secret a·R once per transaction. Before doing the more expensive per-output work (Hs(...)·G + B), it checks the one-byte tag:

• If the tag does not match, the output is certainly not yours and is skipped. About 255 out of 256 non-owned outputs are discarded this way.
• If the tag does match, the wallet runs the full check. Roughly 1 in 256 foreign outputs pass the tag by chance and are then rejected by the full check.

The Monero Project estimated view tags would cut wallet sync time by 30-40%. The leak is negligible: one byte cannot be traced back to an address without the view key, and an observer learns nothing useful from it.

What view tags do not fix

View tags make scanning faster but do not make it unnecessary. Your wallet still has to download and process every transaction since its restore height. That is why setting an accurate restore height, and syncing from a fast node you trust, still makes a big difference. See Wallets for sync tips.

Limits of the current scheme

The 2014-era CryptoNote addressing still has some rough edges:

• View-only wallets cannot see spends. Finding outgoing transfers needs key images, and computing those needs the spend key, so a view-only wallet’s balance becomes wrong once you spend.
• Janus attack. A malicious sender can craft an output that, if you acknowledge receiving it, reveals that two of your subaddresses belong to the same wallet. Wallets have partial defences, but the protocol does not rule it out.
• Burning bug. A sender can create two outputs with the same one-time key, of which only one can ever be spent. Wallets now include checks against it.
• Quantum exposure. An attacker able to solve discrete logarithms could, in principle, link outputs to addresses.

What changes with Carrot

Monero’s planned FCMP++ upgrade comes with a new addressing protocol called Carrot (“Cryptonote Address on Rerandomizable-RingCT-Output Transactions”). According to its specification:

• Existing addresses keep working. Standard addresses, subaddresses and integrated addresses remain valid, and no key migration is required.
• Janus and burning-bug protection apply to all wallets.
• View tags grow to 3 bytes, filtering out far more non-owned outputs before the expensive step.
• New wallets get a richer key hierarchy, with tiers such as generate-address, view-received and view-all, the last of which allows a true view-only wallet that sees outgoing payments too.
• Forward secrecy improves: a future attacker who can solve discrete logarithms learns nothing about the receiver or amount without already knowing the receiver’s address.

Carrot was chosen instead of Jamtis, an earlier, more ambitious scheme designed for the Seraphis protocol. Jamtis would have introduced brand-new 196-character addresses starting with xmra, forcing everyone to switch. Carrot keeps the address format and borrows much of Jamtis’s maths, and its outputs are designed to look the same on-chain as Jamtis-style outputs. The FCMP++ guide in this category covers the timeline.

Summary

Stealth addresses mean your public Monero address never touches the blockchain: each payment lands on a fresh one-time key that only your view key can recognise. Subaddresses extend that privacy to the off-chain world by giving each payer a different, unlinkable address. View tags make finding your payments 30-40% faster without weakening privacy. Carrot will keep all of this working while closing older gaps.

For wallet-specific instructions, head to Wallets. For the other two pillars of on-chain privacy, see our ring signatures and RingCT guides in Technology.