Monero Subaddresses: What They Are and How to Use Them

The three kinds of Monero addresses

Every Monero wallet has one primary address, which starts with the digit 4. From that wallet you can also generate subaddresses, which start with the digit 8, and integrated addresses, which combine your primary address with a payment ID.

All of these point back to the same wallet and the same funds. The difference is in how you organize and reveal them. Subaddresses are the modern, recommended way to receive multiple payments, and they have largely replaced the older integrated-address-plus-payment-ID approach for most uses.

The formats are easy to tell apart once you know them. A primary address is 95 characters and begins with 4. A subaddress is also 95 characters and begins with 8. An integrated address is 106 characters and begins with 4, because it carries an eight byte encrypted payment ID inside the encoding. If you can read the first character and count the length, you know what you are looking at.

One thing is true of all three. None of them ever appears on the blockchain. Monero delivers every payment to a one-time stealth address computed from the recipient's keys and randomness supplied by the sender, so two payments to the same subaddress produce two outputs that look entirely unrelated to an observer. An address is something you hand to a person, not something the network writes down.

Why address reuse is still a problem on a private chain

On a transparent chain, reusing an address is a privacy disaster because anyone can look it up and read its entire history. Monero removes that completely. Nobody can look up an address, nobody can see a balance, and nobody can count how many payments it has received. So the obvious question is why subaddresses matter at all.

The answer is that the leak moves off the chain and into the social layer. An address is a string you give to other people, and those people can store it, compare it, publish it, index it, or be compelled to hand it over. If the same string appears in an invoice to a client, in a public donation post, and in a message to a friend, then anyone who sees two of those three now knows those two contexts belong to the same person.

This is not theoretical. Public donation addresses get scraped and cached. Support tickets get archived. Screenshots get shared and reposted. A reused address becomes a persistent identifier, and persistent identifiers are the raw material of deanonymisation. A fresh subaddress per counterparty means there is no shared string left to correlate.

There is a quieter second benefit. Because subaddresses are indistinguishable from the addresses of unrelated wallets, someone who knows one of your addresses learns nothing when they later see another. They cannot tell whether they are looking at the same wallet or a different person entirely.

How subaddresses actually work

Your wallet is built from a seed, which produces a master spend key and view key. A subaddress is derived from those master keys using an index, organized into accounts and addresses within each account. You can generate a practically unlimited number of them, all controlled by your single seed.

The derivation combines your private view key with the account index and the subaddress index to produce a per-address offset, which is applied to your master spend key to give that subaddress its own keys. The mechanics matter less than the two consequences. Every subaddress is reproducible from the seed alone, and your wallet can recognise a payment to any of them while it scans.

When someone sends to a subaddress, your wallet recognizes the incoming output as yours during scanning, because it checks each output against your keys and the derived subaddress range. You never have to import or register a subaddress anywhere. Generate it, share it, and the wallet handles the rest.

Because subaddresses are derived rather than stored, a restored wallet regenerates them automatically and there is nothing extra to back up. Wallets scan a lookahead window of indices beyond the ones you have explicitly created, which is why a wallet restored from seed still finds payments to subaddresses you generated on the old device. If you had produced an unusually large number of them, generate a comparable number again after restoring so the window covers everything.

Why subaddresses improve your privacy

Monero already hides amounts, senders, and receivers on the blockchain, so an outside observer cannot tie addresses together by watching the chain. The privacy benefit of subaddresses is about the people you interact with directly.

If you reuse one address across many people, each of them sees the same string. They could compare notes and learn that the same address received from several of them. By giving each payer a unique subaddress, no one you deal with sees an address you have shared with anyone else. It compartmentalizes who knows what, off-chain.

Organizing payments with accounts

Subaddresses sit inside accounts. Account 0 is your default, and you can create additional accounts for separate purposes, such as one for personal use and another for a side project. Each account has its own running balance and its own set of subaddresses.

This gives you a lightweight bookkeeping system inside one wallet. You can label each subaddress in the GUI so you remember who or what it was for. The labels are local to your wallet and never leave your device, so they do not affect privacy on the network.

The distinction that matters in practice is how money moves. When you spend from a wallet with multiple accounts, the wallet selects inputs only from the account you are spending from, and change returns to that same account. An account with no balance cannot be topped up implicitly by another one. Moving value between your own accounts is a real Monero transaction with a real fee, not an internal bookkeeping entry.

So accounts are the right tool when you want genuinely separate pools of money without juggling seeds, and subaddresses are the right tool for everything smaller. Subaddresses within an account are free and effectively unlimited. The only cost of creating a lot of them is a marginally longer scan.

When to use a subaddress versus an integrated address

For almost everyone, the answer is just use subaddresses. Generate a new one per payer or per invoice and you get clean separation with no extra steps. They are supported across the official GUI, CLI, and the major third-party wallets.

Integrated addresses bundle a payment ID into the address and were historically used by services to match incoming payments to orders. They still work, but subaddresses solved the same problem more cleanly, so the ecosystem has shifted toward them. If you are not running a payment processor that specifically asks for an integrated address, you can ignore them.

Two practical differences are worth knowing. An integrated address can only be built from your primary address, not from a subaddress, so the two features do not combine. And the older style of separate unencrypted payment IDs has been phased out in favour of the short encrypted ID carried inside an integrated address, which is why modern wallets discourage or refuse the old form.

If you are on the receiving end of a service that still asks for a standalone payment ID, treat that field as mandatory rather than optional. Deposits sent without it land in a shared wallet with nothing to identify them, and sorting that out means a support ticket.

How to generate and use one

In the Monero GUI, open the Receive tab. You will see your current address and a button to create a new subaddress, often with a field to add a label. Click it, copy the new 8-prefixed address, and share that for the payment you are expecting.

In the CLI, the address command lists your subaddresses and lets you create new ones with an optional label. Mobile wallets expose the same feature under their receive screens. There is no downside to spinning up a new one for each incoming payment, and it costs nothing.

When you receive into Monero from a swap, you can paste a fresh subaddress as your destination so that the payout lands on an address you have not shared elsewhere. Because the swap is non-custodial and needs no account, the only thing it ever sees is that one receiving address.

Which wallets support them

Subaddresses are part of Monero itself rather than a feature of any one app, so support is effectively universal in current software. The official GUI and CLI, Feather, Cake Wallet, Monero.com, Monerujo, and Stack Wallet all create and recognise them, and a subaddress generated in one wallet works identically when the same seed is restored into another.

In the GUI, the Receive tab lists your addresses with a control to create another and a field for a local label. In the CLI, the address command creates and lists them. Mobile wallets put the same feature behind a new address or fresh address control on the receive screen, and some go further by rotating the displayed address automatically once one has been used.

Labels are worth the small effort. They live in your local wallet cache and are never transmitted anywhere, so naming a subaddress after the payer costs you nothing in privacy and turns your receive list into a usable record of who paid what.

Practical patterns worth copying

One subaddress per counterparty is the sensible default. Anyone who is going to pay you more than once gets their own, and you never hand the same string to two people.

One subaddress per invoice is the stricter version, used when you need to match incoming payments to specific orders without asking the payer to attach anything extra. This is exactly the problem integrated addresses were invented to solve, and subaddresses handle it without a payment ID.

Keep anything public entirely separate. If you publish a donation address, assume it will be scraped and cached forever. Give the public a dedicated subaddress, or better a dedicated account, so nothing you publish is ever a string you also gave to an individual.

Use a fresh subaddress for every exchange withdrawal or swap payout. The service then learns one address that has never appeared anywhere else and leads nowhere, which is the whole point.

A few practical cautions

Subaddresses are not a substitute for good operational habits. They protect you from the people you share addresses with, not from someone who already knows your identity and is watching your behavior off-chain.

One thing that is often assumed to be dangerous is fine here. On Bitcoin, spending coins received at two different addresses in a single transaction publicly links those addresses. On Monero it does not, because the inputs are hidden inside ring signatures and the outputs were stealth addresses to begin with. You can safely combine funds received at several subaddresses in one spend.

What subaddresses cannot fix is behaviour. If you post a subaddress under a pseudonym you use elsewhere, the pseudonym is the link and the address is irrelevant. If you always receive from the same exchange account, that exchange knows what it knows regardless of which address you give it. And if someone is watching your network traffic, a fresh address does nothing about that. Subaddresses solve one specific problem completely, which is the reuse of a shared string, and they solve nothing else.

Also remember that all subaddresses share one seed. Backing up that single seed backs up every subaddress and account you will ever create, so there is nothing extra to save. Lose the seed and you lose all of them at once, which is the same rule that applies to any Monero wallet.