Monero's long unencrypted payment IDs, once a standard mechanism for exchanges and merchants to attribute inbound transactions to specific users, were officially deprecated to address a fundamental privacy leak. These 64-character hexadecimal strings were appended to transaction extra fields in cleartext, creating a permanent, on-chain linkage identifier visible to any observer. This practice undermined the privacy of both the sender and the receiver by adding a static, non-cryptographic tracking vector to an otherwise privacy-preserving protocol. The network upgrade at block height 1,546,000 in April 2018 formally restricted the use of long payment IDs, requiring integrators to adopt privacy-preserving alternatives.
Protocols
Payment ID Migration and Encoding
A practical implementation guide for deprecating unencrypted payment IDs and migrating to encrypted, subaddress-based payment identification in Monero. Covers integrated address encoding for legacy compatibility and the privacy risks of long unencrypted payment IDs.
introduction
PRIVACY AND OPERATIONAL MIGRATION
The End of Unencrypted Payment IDs
The mandatory deprecation of unencrypted payment IDs in Monero and the migration to subaddresses and encrypted integrated addresses for exchange and payment gateway integrations.
The operational migration path bifurcates into two primary mechanisms: subaddresses and encrypted payment IDs embedded within integrated addresses. Subaddresses, generated deterministically from a wallet's private view and spend keys, allow an exchange to produce a unique, unlinkable address for each customer deposit without the need for a shared identifier. For legacy systems that cannot easily map millions of subaddresses to user accounts, the short, encrypted payment ID offers a compatibility bridge. This 8-byte identifier is encrypted with the recipient's public view key and packed into an integrated address, ensuring that only the recipient can decrypt it while the identifier remains cryptographically opaque on the blockchain. Using a plain-text short payment ID in the tx_extra field is technically possible but is strongly discouraged as it replicates the original privacy flaw.
The primary risk for operators maintaining legacy systems is the inadvertent use of unencrypted payment IDs, which modern wallet software and monero-wallet-rpc will reject by default. An exchange attempting to send a transaction with a long payment ID to a network-enforced minimum ring-size will see the transaction fail. The correct integration pattern requires a systematic shift: generating a unique subaddress per deposit request, or constructing an integrated address containing an encrypted short payment ID for the transfer or transfer_split RPC calls. Chainscore Labs can assess an exchange's current Monero integration architecture to identify any remaining dependencies on deprecated payment ID schemes and design a migration path that preserves both operational attribution and user privacy.
MIGRATION AND ENCODING REFERENCE
Payment ID Standards at a Glance
Operational impact and migration requirements for the deprecation of unencrypted payment IDs and the adoption of subaddress-based identification in Monero.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Long Unencrypted Payment IDs | Deprecated and rejected by most major services due to privacy leakage and transaction bloat. | Exchanges, payment gateways, and wallets with legacy systems. | Verify if any legacy system still generates or requires long payment IDs. Plan immediate migration. |
Short Payment IDs | Deprecated for new integrations but still encodable into integrated addresses for legacy compatibility. | Payment processors and services interacting with legacy wallets. | Audit use of short payment IDs. Migrate to subaddresses for new integrations to prevent future breakage. |
Integrated Addresses | Format that encodes a short payment ID and a public spend key. No longer the recommended standard. | Wallet developers and exchange deposit systems. | Stop generating new integrated addresses. Use subaddresses for all new deposit flows. |
Subaddresses | Standard method for generating unlinkable, unique per-transaction addresses without a payment ID. | All Monero integrators: exchanges, merchants, and wallet developers. | Implement subaddress generation (CryptoNight-based derivation) for all receiving flows. Map subaddresses to internal customer IDs. |
Encrypted Payment IDs | Optional 8-byte value encrypted for the receiver. Not visible on-chain. | Integrators needing to attach a memo to a transaction. | Use only when a subaddress is insufficient. Ensure the receiving wallet can decrypt and process the value. |
Exchange Deposit Workflows | Shift from a single deposit address with a payment ID to a unique subaddress per customer. | Exchange infrastructure and compliance teams. | Redesign deposit monitoring to index incoming transactions by subaddress. Update user-facing deposit instructions. |
Privacy Model | Unencrypted IDs expose a shared identifier across transactions. Subaddresses break this link. | Compliance officers and privacy auditors. | Assess current transaction flows for unencrypted payment ID leakage. Acknowledge that subaddresses prevent casual chain analysis. |
Transaction Construction | Wallets must select the correct output for a subaddress and construct the transaction without a separate payment ID field. | Wallet and custody provider engineers. | Review transaction building logic to ensure it handles subaddress-based output selection and omits deprecated payment ID fields. |
technical-context
PAYMENT ID MIGRATION AND ENCODING
Encoding and Privacy Mechanics
How Monero encodes payment identification data into addresses and the privacy implications of legacy unencrypted payment IDs.
Monero's payment identification system has undergone a critical migration from unencrypted, plaintext payment IDs attached to transactions to privacy-preserving alternatives. The legacy system allowed a 32-byte (long) or 8-byte (short) payment ID to be included in the tx_extra field of a transaction, which was visible to any observer on the blockchain. This created a permanent, on-chain linkage between a payer and a payee, fundamentally undermining Monero's privacy guarantees for any transaction that used them. The primary motivation for deprecation was to eliminate this metadata vector that could be used to cluster transactions and deanonymize users, pushing the ecosystem toward subaddresses and encrypted payment IDs embedded directly into addresses.
The migration path bifurcates into two standards. The first is the integrated address, which encodes a short, 8-byte payment ID directly into the address format. This is not encrypted but is structurally part of the address, preventing the ID from being arbitrarily attached to any transaction. The second, and preferred method, is the use of subaddresses. A subaddress is a cryptographically unlinkable derivative of a wallet's main address, allowing a merchant or exchange to generate a unique, one-time address for each customer or deposit. This eliminates the need for a payment ID entirely, as the unique address itself serves as the payment identifier. The long, unencrypted 32-byte payment ID is fully deprecated and should not be used by any modern integration.
For operators maintaining legacy systems, the risk is acute. Exchanges that still generate a single, static address and require a long payment ID for customer deposits are operating a privacy-degrading and increasingly unsupported workflow. The operational impact includes potential rejection of transactions by modern wallet software and a permanent, auditable record of exchange-customer linkages on the blockchain. The correct migration path is to generate a unique subaddress per user or per deposit, mapping the subaddress to the internal user ID off-chain. Chainscore can assess the privacy leakage of existing exchange address management systems and design a migration architecture that replaces payment IDs with subaddress-based reconciliation, ensuring compliance without sacrificing user privacy.
IMPACT ANALYSIS
Who Is Affected by the Migration
Exchange & Custody Impact
Exchanges face the highest operational risk from payment ID migration. Legacy systems that rely on long, unencrypted payment IDs for deposit routing expose customer transaction graphs and violate current privacy norms.
Required actions:
- Audit all hot-wallet infrastructure for long payment ID usage.
- Migrate deposit routing to unique per-customer subaddresses.
- For legacy compatibility, encode short payment IDs into integrated addresses only.
- Update internal ledgers to map subaddresses to accounts instead of parsing memos.
Risk: Continued use of unencrypted payment IDs creates a permanent, public link between exchange deposits and withdrawals, undermining user privacy and potentially attracting regulatory scrutiny. Chainscore can audit your exchange's Monero integration to identify and remediate payment ID dependencies.
implementation-impact
PAYMENT ID DEPRECATION
Migration Paths and Integration Changes
Actionable migration paths for exchanges, wallets, and payment processors moving from unencrypted payment IDs to subaddresses or encrypted payment IDs. Covers legacy compatibility, privacy risks, and integration cutover strategies.
01
Subaddress Adoption as Primary Replacement
The canonical replacement for unencrypted payment IDs is the per-transaction subaddress. Exchanges must generate a unique subaddress for each deposit, eliminating the need for a separate memo field. This requires wallet infrastructure to support programmatic create_address calls and maintain a mapping of subaddress indices to user accounts. Chainscore can review subaddress generation pipelines to ensure cryptographic correctness and prevent privacy leakage from index reuse.
02
Encrypted Payment ID for Legacy Compatibility
For integrations that cannot immediately adopt subaddresses, short encrypted payment IDs encoded into integrated addresses provide a backward-compatible path. Unlike long unencrypted payment IDs, these are embedded in the address itself and protected by the transaction's stealth addressing. Teams must ensure they are generating integrated addresses correctly and not falling back to the deprecated payment_id field in the transaction extra. Chainscore can audit legacy compatibility layers for accidental plaintext ID exposure.
03
Long Unencrypted Payment ID Sunset
Long unencrypted payment IDs are a critical privacy hazard. They are stored in plaintext in the transaction extra field, permanently visible on-chain, and linkable by any observer. Most major wallets and pools have already dropped support. Any remaining integration using this method must prioritize immediate removal. Continuing to accept or generate these IDs exposes users to chain analysis and violates the privacy expectations of the Monero protocol. Chainscore can perform a rapid assessment of transaction construction logic to identify and eliminate this vector.
04
Exchange Deposit Workflow Migration
The standard exchange deposit workflow must shift from 'generate one static address and parse the payment ID from the memo' to 'generate a unique subaddress per deposit request.' This impacts the hot wallet's RPC interface, the database schema for tracking pending deposits, and the sweep logic that consolidates funds. The 10-block unlock maturity still applies. Chainscore can review the full deposit-to-sweep lifecycle to ensure the new subaddress-based workflow is complete and resistant to race conditions.
05
User-Facing Communication and Cutover
Exchanges and payment gateways must manage a cutover period where legacy integrated addresses are deprecated and subaddresses become the only supported method. This requires clear user communication, updated API documentation, and a grace period for pending deposits to old-style addresses. A hard cutover without a monitoring period can result in lost funds if users send to deprecated address formats. Chainscore can help design a phased migration plan with operational monitoring to ensure zero fund loss during the transition.
06
Privacy Risk Audit for Hybrid Systems
A common failure mode is a hybrid system that uses subaddresses for deposits but still logs or exposes the subaddress-to-user mapping in an internal database accessible to multiple services. This creates a centralized deanonymization point that undermines the privacy gains of the migration. A proper audit must verify that the mapping is cryptographically protected, access-controlled, and not leaked to logs, error messages, or analytics systems. Chainscore can conduct a privacy-focused architecture review of the entire subaddress management lifecycle.
PAYMENT ID MIGRATION AND ENCODING
Privacy and Operational Risk Matrix
Evaluates the privacy, compliance, and operational risks associated with different payment identification methods during and after the migration away from unencrypted payment IDs.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Unencrypted Long Payment IDs | Deprecated and blocked by default on most public nodes. Transactions using them are non-standard and will not be relayed, causing permanent fund loss if forced. | Exchanges, payment gateways, and wallet developers with legacy integration code. | Immediately audit all transaction construction logic to ensure no long, unencrypted payment IDs are generated. Verify relay policy against connected daemon. |
Short Payment IDs in Integrated Addresses | Encoded directly into a non-standard address format. This is a legacy compatibility shim that is still relayed but leaks the payment ID to all network observers. | Merchants and services that have not yet migrated to subaddresses for payment differentiation. | Treat as a temporary measure. Plan a full migration to per-transaction subaddresses. Chainscore can review the migration path for completeness. |
Subaddress-based Identification | Replaces payment IDs entirely. A unique, cryptographically unlinkable address is generated for each payment, embedding the payer's identity off-chain in the wallet's internal mapping. | All wallet developers, exchanges, and payment processors. | Adopt as the standard method. Ensure the wallet database mapping subaddresses to customer accounts is robust and backed up. Verify subaddress generation follows M/44'/128'/0' derivation. |
Encrypted Payment IDs (Payment ID 8) | A short, encrypted payment ID embedded in the | Wallets and services requiring sender-identified payments without on-chain leakage. | Use only when a subaddress is not sufficient, such as for self-send identification. Verify the recipient wallet supports decryption. Chainscore can audit the encryption implementation. |
Exchange Deposit Monitoring | Shift from scanning for a single static address with a payment ID to monitoring millions of unique subaddresses for incoming funds. | Exchange infrastructure and compliance teams. | Implement a scalable subaddress generation and monitoring pipeline. Ensure the wallet RPC can handle the index range. Review for race conditions during block reorgs. |
Compliance and Travel Rule | Unencrypted payment IDs were sometimes used to attach customer information to a transaction, creating a permanent on-chain record and a severe privacy violation. | Compliance officers and regulated exchanges. | Never use unencrypted payment IDs for customer data. Implement off-chain memos or use encrypted payment IDs if a transaction reference is required. Review current practices against jurisdictional data privacy laws. |
Transaction Fee and Size Impact | Including any data in | High-volume payment processors and exchanges. | Favor subaddresses for cost efficiency. If using encrypted payment IDs, factor the additional ~100 bytes into dynamic fee calculations to avoid stuck transactions. |
Wallet Recovery and Audit | Recovering a wallet from seed without the original subaddress-to-account mapping file results in a loss of the ability to associate incoming payments with specific customers. | Exchange key-management and disaster recovery teams. | Ensure the wallet cache and account mapping database are included in critical backup and recovery procedures. Test the restoration process to verify subaddress labels are not lost. |
PAYMENT ID DEPRECATION READINESS
Exchange and Payment Gateway Migration Checklist
A practical checklist for exchanges, payment gateways, and custody providers migrating away from unencrypted payment IDs to subaddress-based or encrypted payment identification. Each item identifies a critical operational risk, the verification signal, and the specific integration points that must be updated to avoid deposit loss or privacy degradation.
Identify every code path, configuration file, and database schema that generates or stores 64-character hexadecimal payment IDs for incoming customer deposits. Long unencrypted payment IDs are the primary target of the deprecation because they permanently link transactions on-chain and bloat transaction size.
Why it matters: Continuing to generate long payment IDs after ecosystem support drops will result in failed or rejected transactions, leading to customer deposit delays and support incidents.
Verification signal: A grep across wallet RPC call sites for payment_id parameters with 64-character hex strings. Confirm that no customer-facing deposit flow produces a long payment ID.
Chainscore can: Audit your address generation pipeline for deprecated payment ID patterns and map every integration point that requires migration.
resource-links
MONERO IMPLEMENTATION REFERENCES
Canonical Resources and Specifications
Use these Monero resources to verify payment ID formats, integrated-address handling, wallet RPC behavior, and release-specific compatibility before changing production deposit workflows.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
PAYMENT ID MIGRATION FAQ
Frequently Asked Questions
Common operational and integration questions about migrating from legacy payment IDs to subaddresses and encrypted payment IDs in Monero.
Long, unencrypted payment IDs attached to the tx_extra field of a transaction were a significant privacy leak. They created a permanent, on-chain identifier that could link transactions, undermining Monero's privacy guarantees. The deprecation was a community-driven effort to eliminate this metadata and push the ecosystem toward subaddresses, which provide unlinkable, per-transaction addresses without bloating the chain or exposing a shared identifier. Exchanges and services that continue to use them risk deanonymizing their users and their own internal fund flows.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.