Payment IDs in Monero: Why They Were Deprecated and What Replaced Them

The Rise and Fall of Payment IDs

Payment IDs were once a ubiquitous feature in the Monero ecosystem. If you used Monero before 2019, you almost certainly encountered them when depositing to exchanges or paying merchants. These extra identifiers were appended to transactions to help recipients distinguish between multiple incoming payments. Despite their usefulness, payment IDs introduced significant privacy and usability problems that ultimately led to their deprecation.

Understanding this history is important for anyone using Monero today, especially when interacting with older services that may still reference payment IDs. Whether you swap through MoneroSwapper or manage your own wallet, knowing what replaced payment IDs and why helps you transact more safely.

What Were Payment IDs?

A payment ID was a 64-character hexadecimal string (32 bytes) that could be attached to a Monero transaction. Think of it as a reference number or invoice ID embedded directly in the blockchain transaction. There were two types:

Long Payment IDs (Unencrypted)

The original payment ID format was a 32-byte string transmitted in plaintext as part of the transaction's extra field. When you sent a transaction with a long payment ID, anyone viewing the blockchain could see the payment ID value. This was the earliest method and was widely used by exchanges and payment processors.

The problem was immediately apparent from a privacy perspective: if an exchange published its deposit address and assigned unique payment IDs to each user, an observer could identify all deposits to that exchange and potentially link payment IDs to specific users through timing or amount analysis.

Encrypted Payment IDs (Short Payment IDs)

To address the plaintext problem, Monero introduced encrypted payment IDs in 2017. These were 8-byte values encrypted with a shared secret derived from the transaction's one-time keys. Only the recipient could decrypt the payment ID using their private view key. On the blockchain, the encrypted payment ID appeared as random data to everyone else.

Encrypted payment IDs were bundled with integrated addresses, which combined a standard Monero address with an 8-byte payment ID into a single address string. This made them easier to use because the sender did not need to manually copy and paste a separate payment ID field.

Why Exchanges and Services Used Payment IDs

The practical reason for payment IDs was simple: exchanges and merchants needed to attribute incoming payments to specific users or orders. Because Monero uses stealth addresses that make every transaction output unique, a service receiving thousands of deposits daily needed a mechanism to determine which deposit belonged to which customer.

The typical workflow was:

• Exchange gives all users the same deposit address but assigns each user a unique payment ID
• User sends XMR to the exchange address with the assigned payment ID
• Exchange scans incoming transactions for the payment ID to credit the correct account

This system worked but was fragile. Users frequently forgot to include the payment ID, resulting in lost deposits that required manual recovery by exchange support teams. This was one of the most common support issues for Monero-accepting exchanges and a major source of user frustration.

The Privacy Problems with Payment IDs

Even encrypted payment IDs introduced several privacy vulnerabilities that undermined Monero's core privacy guarantees:

Linkability Through Metadata

When all users of an exchange sent to the same address, the stealth address mechanism was undermined. An observer could identify that a transaction was destined for a specific exchange simply by recognizing the public address. The payment ID, even when encrypted, added distinguishing metadata to the transaction. Transactions with payment IDs looked different from transactions without them, creating two classes of transactions that reduced the anonymity set.

The Two-Pool Problem

Transactions with payment IDs and transactions without payment IDs formed two visually distinct pools on the blockchain. This distinction provided information to chain analysts. If a transaction contained an encrypted payment ID, it was very likely going to an exchange or merchant, narrowing down the possible recipients significantly.

Timing and Pattern Analysis

Exchanges typically processed deposits in batches or with predictable timing. Combined with the single deposit address model, this created patterns that sophisticated analysts could exploit. The combination of a known address, timing patterns, and the presence of payment IDs made correlation attacks more feasible than they should have been.

User Error as a Privacy Leak

When users forgot the payment ID, they often had to contact support and prove the transaction was theirs. This typically involved sharing the transaction private key or view key information, creating additional privacy leakage and a paper trail linking their identity to the transaction.

The Deprecation Timeline

The Monero community recognized these problems and took action through several protocol upgrades:

• 2018 (v0.13, Beryllium Bullet) — Long (unencrypted) payment IDs were deprecated, and wallet software began showing warnings when users attempted to use them
• 2019 (v0.15, Carbon Chamaeleon) — Long payment IDs were banned at the protocol level. Transactions with unencrypted payment IDs were rejected by the network
• Wallet software updates — GUI and CLI wallets progressively removed payment ID fields and encouraged subaddress usage
• Exchange migration — Major exchanges migrated from payment IDs to subaddresses over 2019 and 2020, with some stragglers taking longer

Encrypted (short) payment IDs via integrated addresses technically still work at the protocol level, but they are strongly discouraged. Modern wallet software either hides the option entirely or shows clear warnings. The community consensus is that subaddresses are the correct replacement.

Subaddresses: The Superior Replacement

Subaddresses were introduced as the recommended replacement for payment IDs. A subaddress is a unique address derived from your main wallet address using a mathematical relationship that only your wallet can compute. Each subaddress is cryptographically linked to your main address, but the link is invisible to outside observers.

How Subaddresses Work

Your Monero wallet can generate an essentially unlimited number of subaddresses from your primary address. Each subaddress looks like a completely independent Monero address to anyone viewing the blockchain. When someone sends XMR to your subaddress, the transaction output uses the subaddress's public keys to generate the stealth address, ensuring that only your wallet can identify the payment.

Key advantages of subaddresses over payment IDs include:

• No shared address — Each customer or payment gets a unique address, eliminating the single-address problem entirely
• No metadata leakage — Transactions to subaddresses look identical to transactions to main addresses on the blockchain
• No user error — Users simply send to the provided address without needing to remember an extra payment ID field
• Unlinkable — An observer cannot determine that two subaddresses belong to the same wallet
• No two-pool problem — All transactions look the same regardless of whether they use main addresses or subaddresses

Subaddresses for Exchanges

For exchanges that previously used payment IDs, the migration to subaddresses improved both security and user experience. Instead of giving every user the same address with different payment IDs, exchanges now generate a unique subaddress for each user. The exchange's wallet automatically identifies which subaddress received the deposit and credits the correct account.

This approach eliminated the most common support issue (forgotten payment IDs) while simultaneously improving the privacy of all users. It was a rare case where the more private solution was also the more user-friendly one.

Migration Guide for Services Still Using Payment IDs

If you operate a service that still uses payment IDs, migrating to subaddresses is straightforward:

• Generate subaddresses — Use the wallet RPC method create_address to generate a unique subaddress for each user account
• Store the mapping — Maintain a database mapping between user accounts and their assigned subaddresses
• Update deposit instructions — Remove payment ID fields from your deposit interface and display only the subaddress
• Monitor incoming transactions — Use the get_transfers RPC method, which automatically reports the subaddress index for each incoming transaction
• Maintain backward compatibility — For a transition period, continue scanning for old payment ID transactions so that users who cached old deposit instructions are not affected

What to Do If You Encounter a Service Requesting Payment IDs

Despite the deprecation being years old, some smaller exchanges and services still request payment IDs. If you encounter this situation, here is what you should know:

Proceed with caution. A service still using payment IDs in 2026 may not be keeping up with Monero protocol changes, which could indicate broader maintenance and security concerns. Consider whether the service is trustworthy.

Use integrated addresses if offered. If the service provides an integrated address (which embeds the payment ID), your wallet will handle the payment ID automatically. This is preferable to manually entering a long payment ID.

Double-check the payment ID. If you must enter a payment ID manually, copy and paste it carefully. Verify every character. A wrong payment ID means lost funds that may be difficult to recover.

Consider alternatives. If a service demands a long (unencrypted) payment ID, modern Monero software will likely reject the transaction. You may need to use a different service or request that they update to subaddresses. Services like MoneroSwapper use modern infrastructure that does not require payment IDs.

The Broader Lesson

The deprecation of payment IDs illustrates a key principle of Monero's development philosophy: privacy is not just about cryptographic primitives but also about protocol design and real-world usage patterns. Even with strong encryption, the metadata and behavioral patterns created by payment IDs were sufficient to weaken privacy guarantees.

By replacing payment IDs with subaddresses, Monero eliminated an entire class of privacy leaks while improving usability. This kind of iterative improvement, where the protocol evolves based on real-world privacy analysis, is what distinguishes Monero from projects that treat privacy as a feature rather than a fundamental requirement. The removal of payment IDs made every Monero transaction more private by eliminating distinguishing metadata and creating a more uniform transaction pool.

For users today, the practical message is simple: use subaddresses for everything, avoid services that still require payment IDs when possible, and appreciate that this seemingly small protocol change represents years of research and community effort to make Monero's privacy stronger for everyone.