Unified Address Format

A Unified Address Format is designed to be independent of any single blockchain's native addressing scheme. It acts as a wrapper or container that can encapsulate addresses for multiple protocols (e.g., Bitcoin, Ethereum, Litecoin) and asset types (e.g., fungible tokens, NFTs). This allows a single address to receive value across different networks without the user needing to manage separate, protocol-specific addresses.

The address structure contains explicit fields or type bits that specify:

• The asset type to be transferred (e.g., a specific token contract address).
• The transfer protocol or method to use (e.g., simple send, confidential transaction).
• The recipient's address on the target blockchain. This metadata ensures the receiving wallet or node can correctly interpret and process the incoming transaction without external context.

A well-designed format ensures backward compatibility with existing wallet software (often by being ignored or triggering a clear error) while being extensible for future protocols and asset types. This is achieved through version bits and reserved fields within the address structure, allowing new features to be added without breaking existing, valid addresses.

By consolidating multiple destination possibilities into one address, unified formats significantly reduce user error. Key improvements include:

• Single Address Management: Users provide one address for all supported assets.
• Clear Validation: Wallets can immediately detect if an address format is supported.
• Protocol Selection: The burden of choosing the correct network or token standard shifts from the user to the wallet software, which reads the specifier from the address itself.

The Bitcoin Taproot address (bc1p...) is a real-world example of a unified address feature set:

• Encoding: Uses Bech32m.
• Specifier: The bc1p prefix indicates a Taproot (v1 witness) output, specifying the script type.
• Data: Encodes a 32-byte public key for Schnorr signatures.
• Benefit: Unifies pay-to-pubkey and complex smart contract capabilities into a single, efficient address format that is indistinguishable on-chain.

A Unified Address can natively represent multiple asset types, such as Bitcoin (BTC) and Liquid Network (L-BTC), within a single string. This eliminates the need for separate wallet addresses for each asset, streamlining portfolio management and reducing user error. Wallets and services can parse the address to identify and handle the supported assets automatically.

• Example: A single UAF can hold both a transparent Bitcoin balance and a confidential Liquid asset.
• Benefit: Simplifies user experience for multi-asset wallets and exchanges.

The format is fundamentally designed for Pay-to-Taproot (P2TR) outputs, the standard for Bitcoin's Taproot upgrade. It encodes the x-only public key required for Schnorr signatures, enabling advanced scripting and privacy features like Tapscripts and MuSig2 multisignatures. This makes UAF the native address type for the most secure and efficient Bitcoin transactions.

• Core Use: The primary method for sending funds to Taproot-compatible wallets.
• Feature Support: Enables complex spending conditions without revealing them on-chain.

Unified Addresses are the required destination format for Silent Payments, a privacy-enhancing protocol that generates a unique, one-time address for each transaction. This breaks the common-chain analysis heuristic of address reuse. The sender derives a new stealth address from the recipient's public key and the transaction data, which is only payable to the intended recipient.

• Privacy Benefit: Prevents third parties from linking different payments to the same receiver.
• Protocol Requirement: Silent Payment BIPs specify UAF as the output address standard.

Major wallet providers and infrastructure services are adopting UAF to future-proof their systems. Wallets like Sparrow and Blockstream Green support receiving to Unified Addresses. Exchanges and payment processors are integrating UAF parsing to accept deposits, ensuring compatibility with next-generation Bitcoin transactions and assets.

• Adoption Driver: Necessary for supporting Taproot, Liquid, and future Bitcoin upgrades.
• Backward Compatibility: Often paired with a fallback to legacy address formats (P2PKH, P2SH) for broader compatibility.

The sender is responsible for ensuring the unified address is correct and belongs to the intended recipient. Unlike transparent addresses, you cannot validate a shielded address on a block explorer. This makes address proofing and secure communication channels critical to prevent misdirected, irreversible funds.

• Key Risk: Sending to a malformed or incorrect UAF address results in permanent loss.
• Best Practice: Use trusted address books, QR codes, or copy-paste from verified sources.

The security of shielded funds depends on the cryptographic soundness of the zero-knowledge proof system (e.g., Halo 2, zk-SNARKs) and the consensus security of the underlying blockchain. A malicious majority could theoretically censor transactions or, in extreme scenarios, compromise the pool's state.

• Foundation: Trust in the validity of the circuit and the computational integrity of the proving system.
• Network Security: A 51% attack on the chain could disrupt the shielded pool's operation.

Viewing keys allow users to decrypt their transaction history without spending authority. Compromise of a viewing key leaks complete financial privacy.

• Threat Model: Exposure reveals all incoming/outgoing amounts and counterparties for the associated addresses.
• Storage: Must be secured with the same rigor as a spending key, often stored in encrypted wallets.

Wallet software must correctly implement the UAF specification and proof generation. Bugs can lead to loss of funds or privacy leaks.

• Implementation Risks: Incorrect proof generation, RPC call leaks, or UI flaws that expose shielded data.
• Side-Channel Attacks: Timing or memory analysis on the device during proof computation could theoretically leak information.

While enhancing user privacy, the UAF can complicate regulatory compliance for Virtual Asset Service Providers (VASPs). They must use viewing keys or other compliance tools to meet Travel Rule (FATF) requirements.

• Compliance Challenge: Balancing user privacy with the need for audit trails.
• Solutions: Emerging protocols like ZK-proofs of compliance allow proving regulatory adherence without revealing full transaction graphs.

Most current UAF implementations rely on elliptic curve cryptography (e.g., Jubjub) for signatures and note encryption, which are vulnerable to a sufficiently powerful quantum computer.

• Future Threat: A quantum adversary could break the encryption protecting shielded notes.
• Mitigation: Ongoing research into post-quantum cryptography (e.g., lattice-based schemes) for future-proofing shielded pools.

A self-contained descriptor within a Unified Address that defines where and how to receive an asset. A single UA can contain multiple receivers.

• Types: Common receivers include a P2PKH script for simple payments, a P2SH script for smart contracts, and an Orchard shielded note for privacy.
• Function: The sender's wallet selects the most appropriate receiver from the list based on its own capabilities and the user's privacy preferences.

A compact, 16-bit identifier that specifies the type of receiver within a Unified Address. It tells the parsing software how to interpret the subsequent data bytes.

• Example: A typecode might indicate the data is for a P2SH receiver, an Orchard receiver, or a receiver for a completely different blockchain.
• Extensibility: The typecode system allows new receiver types to be added to the format without breaking compatibility with older wallets.

The core design goal of the Unified Address Format: enabling seamless interaction between different blockchain protocols and wallet software.

• Multi-Chain Vision: A UA is designed to potentially contain receivers for assets on Bitcoin, Zcash, or other networks, all under one address string.
• Wallet Agnosticism: Allows wallets with different feature sets (e.g., privacy-supporting vs. basic) to successfully transact by choosing a compatible receiver from the list.

The process by which a wallet or exchange determines which blockchain network an address belongs to. This is a challenge for unified formats.

• Problem: A Unified Address string does not have a network prefix like 1 (Bitcoin) or t1 (Zcash Transparent).
• Solution: Systems must rely on context (which asset a user selected) or attempt to parse and validate the address against known receiver types for each supported network.