<p>The key words "MUST", "MUST NOT", and "SHOULD" in this document are to be interpreted as described in RFC 2119. <aid="id1"class="footnote_reference"href="#rfc2119">1</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Recipient</dt>
<dd>A wallet or other software that can receive transfers of assets (such as ZEC) or in the future potentially other transaction-based state changes.</dd>
<dd>A wallet or other software that can send transfers of assets, or other consensus state side-effects defined in future. Senders are a subset of Consumers.</dd>
<dd>The necessary information to transfer an asset to a Recipient that generated that Receiver using a specific Transfer Protocol. Each Receiver is associated unambiguously with a specific Receiver Type, identified by an integer Typecode.</dd>
<dd>The necessary information to view information about payments to an Address, or (in the case of a Full Viewing Key) from an Address. An Incoming Viewing Key can be derived from a Full Viewing Key, and an Address can be derived from an Incoming Viewing Key.</dd>
<dt>Viewing Key Encoding</dt>
<dd>An encoding of a Viewing Key as a byte sequence.</dd>
<dd>Either a Legacy Address or a Unified Address.</dd>
<dt>Transfer Protocol</dt>
<dd>A specification of how a Sender can transfer assets to a Recipient. For example, the Transfer Protocol for a Sapling Receiver is the subset of the Zcash protocol required to successfully transfer ZEC using Sapling Spend/Output Transfers as specified in the Zcash Protocol Specification. (A single Zcash transaction can contain transfers of multiple Transfer Protocols. For example a t→z transaction that shields to the Sapling pool requires both Transparent and Sapling Transfer Protocols.)</dd>
<dt>Address Encoding</dt>
<dd>The externally visible encoding of an Address (e.g. as a string of characters or a QR code).</dd>
<p>Notation for sequences, conversions, and arithmetic operations follows the Zcash protocol specification <aid="id2"class="footnote_reference"href="#protocol-notation">3</a>.</p>
<p>This proposal defines Unified Addresses, which bundle together Zcash Addresses of different types in a way that can be presented as a single Address Encoding. It also defines Unified Viewing Keys, which perform a similar function for Zcash viewing keys.</p>
<p>Each of these has its own Address Encodings, as a string and as a QR code. (Since the QR code is derivable from the string encoding, for many purposes it suffices to consider the string encoding.)</p>
<p>The difficulty with defining new Address Encodings for each Address type, is that end-users are forced to be aware of the various types, and in particular which types are supported by a given Consumer or Recipient. In order to make sure that transfers are completed successfully, users may be forced to explicitly generate Addresses of different types and re-distribute encodings of them, which adds significant friction and cognitive overhead to understanding and using Zcash.</p>
<li>Provide a “bridging mechanism” to allow shielded wallets to successfully interact with conformant Transparent-Only wallets.</li>
<li>Allow older conformant wallets to interact seamlessly with newer wallets.</li>
<li>Enable users of newer wallets to upgrade to newer transaction technologies and/or pools while maintaining seamless interactions with counterparties using older wallets.</li>
<li>Facilitate wallets to assume more sophisticated responsibilities for shielding and/or migrating user funds.</li>
<li>Allow wallets to potentially develop new transfer mechanisms without underlying protocol changes.</li>
<li>Provide forward compatibility that is standard for all wallets across a range of potential future features. Some examples might include Layer 2 features, cross-chain interoperability and bridging, and decentralized exchange.</li>
<li>The standard should work well for Zcash today and upcoming potential upgrades, and also anticipate even broader use cases down the road such as cross-chain functionality.</li>
<p>Unified Addresses specify multiple methods for payment to a Recipient's Wallet. The Sender's Wallet can then non-interactively select the method of payment.</p>
<p>Importantly, any wallet can support Unified Addresses, even when that wallet only supports a subset of payment methods for receiving and/or sending.</p>
<p>Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs <aid="id4"class="footnote_reference"href="#zip-0321">11</a> and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new Address type.</p>
<li>A Consumer wallet or user <em>imports</em> the Address Encoding through any of a variety of mechanisms (QR Code scanning, Payment URIs, cut-and-paste, or “in-band” protocols like <code>Reply-To</code> memos).</li>
<li>A Consumer wallet <em>decodes</em> the Address Encoding and performs validity checks.</li>
<li>(Perhaps later in time) if the Consumer wallet is a Sender, it can execute a transfer of ZEC (or other assets or protocol state changes) to the Address.</li>
<p>Encodings of the same Address may be distributed zero or more times through different means. Zero or more Consumers may import Addresses. Zero or more of those (that are Senders) may execute a Transfer. A single Sender may execute multiple Transfers over time from a single import.</p>
<p>When new Transport Protocols are introduced to the Zcash protocol after Unified Addresses are standardized, those should introduce new Receiver Types but <em>not</em> different Address types outside of the UA standard. There needs to be a compelling reason to deviate from the standard, since the benefits of UA come precisely from their applicability across all new protocol upgrades.</p>
<p>Every Wallet must properly <em>parse</em> a Unified Address containing unrecognized Receiver Types; and similarly for Unified Viewing Keys containing unrecognized Viewing Key Types.</p>
<p>A Wallet may process unrecognized Receiver Types or Viewing Key Types by indicating to the user their presence or similar information for usability or diagnostic purposes.</p>
<p>The string encoding is “opaque” to human readers: it does <em>not</em> allow visual identification of which Receivers or Receiver Types are present.</p>
<p>The string encoding is resilient against typos, transcription errors, cut-and-paste errors, unanticipated truncation, or other anticipated UX hazards.</p>
<p>There is a well-defined encoding of a Unified Address (or UFVK or UIVK) as a QR Code, which produces QR codes that are reasonably compact and robust.</p>
<p>The string encoding fits into ZIP-321 Payment URIs <aid="id5"class="footnote_reference"href="#zip-0321">11</a> and general URIs without introducing parse ambiguities.</p>
<p>Given a valid UA, Selection must treat any unrecognized Receiver as though it were absent.</p>
<ul>
<li>This property is crucial for forward compatibility to ensure users who upgrade to newer protocols / UAs don't lose the ability to smoothly interact with older wallets.</li>
<li>This property is crucial for allowing Transparent-Only UA-Conformant wallets to interact with newer shielded wallets, removing a disincentive for adopting newer shielded wallets.</li>
<li>This property also allows Transparent-Only wallets to upgrade to shielded support without re-acquiring counterparty UAs. If they are re-acquired, the user flow and usability will be minimally disrupted.</li>
<p>Unified Addresses and Unified Viewing Keys must be able to include Receivers and Viewing Keys of experimental types, possibly alongside non-experimental ones. These experimental Receivers or Viewing Keys must be used only by wallets whose users have explicitly opted into the corresponding experiment.</p>
<p>A Unified Full Viewing Key (resp. Unified Incoming Viewing Key) can be used in a similar way to a Full Viewing Key (resp. Incoming Viewing Key) as described in the Zcash Protocol Specification <aid="id6"class="footnote_reference"href="#protocol-nu5">2</a>.</p>
<p>For a Transparent P2PKH Address that is derived according to BIP 32 <aid="id7"class="footnote_reference"href="#bip-0032">12</a> and BIP 44 <aid="id8"class="footnote_reference"href="#bip-0044">15</a>, the nearest equivalent to a Full Viewing Key or Incoming Viewing Key for a given BIP 44 account is an extended public key, as defined in the section “Extended keys” of BIP 32. Therefore, UFVKs and UIVKs should be able to include such extended public keys.</p>
<p>A wallet should support deriving a UIVK from a UFVK, and a Unified Address from a UIVK.</p>
<sectionid="open-issues-and-known-concerns"><h3><spanclass="section-heading">Open Issues and Known Concerns</span><spanclass="section-anchor"><arel="bookmark"href="#open-issues-and-known-concerns"><imgwidth="24"height="24"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<sectionid="encoding-of-unified-addresses"><h3><spanclass="section-heading">Encoding of Unified Addresses</span><spanclass="section-anchor"><arel="bookmark"href="#encoding-of-unified-addresses"><imgwidth="24"height="24"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>Rather than defining a Bech32 string encoding of Orchard Shielded Payment Addresses, we instead define a Unified Address format that is able to encode a set of Receivers of different types. This enables the Consumer of a Unified Address to choose the Receiver of the best type it supports, providing a better user experience as new Receiver Types are added in the future.</p>
<p>Assume that we are given a set of one or more Receiver Encodings for distinct types. That is, the set may optionally contain one Receiver of each of the Receiver Types in the following fixed Priority List:</p>
<p>We say that a Receiver Type is “preferred” over another when it appears earlier in this Priority List.</p>
<p>The Sender of a payment to a Unified Address MUST use the Receiver of the most preferred Receiver Type that it supports from the set.</p>
<p>For example, consider a wallet that supports sending funds to Orchard Receivers, and does not support sending to any Receiver Type that is preferred over Orchard. If that wallet is given a UA that includes an Orchard Receiver and possibly other Receivers, it MUST send to the Orchard Receiver.</p>
<p>Let <code>padding</code> be the Human-Readable Part of the Unified Address in US-ASCII, padded to 16 bytes with zero bytes. We append <code>padding</code> to the concatenated encodings, and then apply the
algorithm as described in <ahref="#jumbling">Jumbling</a>. The output is then encoded with Bech32m <aid="id13"class="footnote_reference"href="#bip-0350">17</a>, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.</p>
<li>Let <code>padding</code> be the Human-Readable Part, padded to 16 bytes as for encoding. If the result ends in <code>padding</code>, remove these 16 bytes; otherwise reject.</li>
<p>For Unified Addresses on Mainnet, the Human-Readable Part (as defined in <aid="id14"class="footnote_reference"href="#bip-0350">17</a>) is “<code>u</code>”. For Unified Addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
<p>A wallet MAY allow its user(s) to configure which Receiver Types it can send to. It MUST NOT allow the user(s) to change the order of the Priority List used to choose the Receiver Type.</p>
</section>
<sectionid="encoding-of-unified-full-incoming-viewing-keys"><h3><spanclass="section-heading">Encoding of Unified Full/Incoming Viewing Keys</span><spanclass="section-anchor"><arel="bookmark"href="#encoding-of-unified-full-incoming-viewing-keys"><imgwidth="24"height="24"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>Unified Full or Incoming Viewing Keys are encoded and decoded analogously to Unified Addresses. A Consumer MUST use the decoding procedure from the previous section. For Viewing Keys, a Consumer will normally take the union of information provided by all contained Receivers, and therefore the Priority List defined in the previous section is not used.</p>
<p>For each UFVK Type or UIVK Type currently defined in this specification, the same Typecode is used as for the corresponding Receiver Type in a Unified Address. Additional UFVK Types and UIVK Types MAY be defined in future, and these will not necessarily use the same Typecode as the corresponding Unified Address.</p>
<p>The following UFVK or UIVK Encodings are used in place of the
<li>There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be diversified in an unlinkable way). The Typecode
<spanclass="math">\(\mathtt{0x01}\)</span>
MUST NOT be included in a UFVK or UIVK by Producers, and MUST be treated as unrecognized by Consumers.</li>
<li>For Transparent P2PKH Addresses that are derived according to BIP 32 <aid="id16"class="footnote_reference"href="#bip-0032">12</a> and BIP 44 <aid="id17"class="footnote_reference"href="#bip-0044">15</a>, the UFVK and UIVK Encodings have Typecode
<spanclass="math">\(\mathtt{0x00}.\)</span>
These encodings are identical and are the serialization of an extended public key, defined in the section “Serialization format” of BIP 32 <aid="id18"class="footnote_reference"href="#bip-0032-serialization-format">13</a>.</li>
</ul>
<p>The Human-Readable Parts (as defined in <aid="id19"class="footnote_reference"href="#bip-0350">17</a>) of Unified Viewing Keys are defined as follows:</p>
<sectionid="requirements-for-both-unified-addresses-and-unified-viewing-keys"><h3><spanclass="section-heading">Requirements for both Unified Addresses and Unified Viewing Keys</span><spanclass="section-anchor"><arel="bookmark"href="#requirements-for-both-unified-addresses-and-unified-viewing-keys"><imgwidth="24"height="24"src="assets/images/section-anchor.png"alt=""></a></span></h3>
). The rationale is that the existing P2SH and P2PKH transparent-only address formats, and the existing P2PKH extended public key format, suffice for this purpose and are already supported by the existing ecosystem.</li>
<aid="id20"class="footnote_reference"href="#bitcoin-compactsize">20</a> (Although existing Receiver Encodings and Viewing Key Encodings are all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.)</li>
<li>Each Receiver, UFVK, or UIVK SHOULD represent an Address or Viewing Key at the ZIP 32 or BIP 44 Account level.</li>
<li>There is intentionally no Typecode defined for a Sprout Shielded Payment Address or Sprout Incoming Viewing Key. Since it is no longer possible (since activation of ZIP 211 in the Canopy network upgrade <aid="id21"class="footnote_reference"href="#zip-0211">9</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
<li>Consumers MUST ignore constituent Addresses/Viewing Keys with Typecodes they do not recognize.</li>
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which the same Typecode appears more than once, or that include both P2SH and P2PKH Transparent Addresses, or that contain only a Transparent Address.</li>
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which <em>any</em> constituent address does not meet the validation requirements of its Receiver Encoding, as specified in the Zcash Protocol Specification <aid="id22"class="footnote_reference"href="#protocol-nu5">2</a>.</li>
<li>Producers SHOULD order the constituent Addresses/Viewing Keys in the same order as in the Priority List above. However, Consumers MUST NOT assume this ordering, and it does not affect which Address should be used by a Sender.</li>
<sectionid="adding-new-types"><h3><spanclass="section-heading">Adding new types</span><spanclass="section-anchor"><arel="bookmark"href="#adding-new-types"><imgwidth="24"height="24"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>It is intended that new Receiver Types and Viewing Key Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <aid="id23"class="footnote_reference"href="#zip-0000">6</a>.</p>
<p>For experimentation prior to proposing a ZIP, experimental types MAY be added using the reserved Typecodes
<spanclass="math">\(\mathtt{0xFFFA}\)</span>
to
<spanclass="math">\(\mathtt{0xFFFF}\)</span>
inclusive. This provides for six simultaneous experiments, which can be referred to as experiments A to F. This should be sufficient because experiments are expected to be reasonably short-term, and should otherwise be either standardized in a ZIP (and allocated a Typecode outside this reserved range) or discontinued.</p>
</section>
<sectionid="deriving-a-uivk-from-a-ufvk"><h3><spanclass="section-heading">Deriving a UIVK from a UFVK</span><spanclass="section-anchor"><arel="bookmark"href="#deriving-a-uivk-from-a-ufvk"><imgwidth="24"height="24"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>Each UIVK Encoding can straightforwardly be derived from the corresponding UFVK Encoding, without changing the Typecode. In the case of a Transparent P2PKH UFVK Encoding, the UIVK Encoding is the same.</p>
</section>
<sectionid="deriving-a-unified-address-from-a-uivk"><h3><spanclass="section-heading">Deriving a Unified Address from a UIVK</span><spanclass="section-anchor"><arel="bookmark"href="#deriving-a-unified-address-from-a-uivk"><imgwidth="24"height="24"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>To derive a Unified Address from a UIVK we need to choose a diversifier index, which MUST be valid for all of the Viewing Key Types in the UIVK. That is,</p>
<ul>
<li>A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” <aid="id24"class="footnote_reference"href="#zip-0032-sapling-diversifier-derivation">8</a>.</li>
<li>A Transparent diversifier index MUST be in the range
<spanclass="math">\(0\)</span>
to
<spanclass="math">\(2^{31}\)</span>
inclusive.</li>
</ul>
<p>There are no additional constraints on an Orchard diversifier index.</p>
<p>In the case of deriving a Transparent P2PKH Receiver from a Transparent P2PKH UIVK, the diversifier index is used as a BIP 44 child key index at the Index level to derive the address. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation <aid="id25"class="footnote_reference"href="#bip-0032-public-to-public">14</a> MUST be used, with the Change element of the path being 0, and the Index element of the path being the diversifier index <aid="id26"class="footnote_reference"href="#bip-0044-path-index">16</a>. That is, the BIP 44 path of the Transparent P2PKH Receiver MUST be:</p>
<li>is controlled by the adversary (for concreteness, the adversary knows <em>at least one</em> of the private keys of the constituent Addresses).</li>
<li>In this variant, part b) above is replaced by the meaning of the new Address being “usefully” different than the Address it is based on, even though the adversary does not know any of the private keys. For example, if it were possible to delete a shielded constituent Address from a UA leaving only a Transparent Address, that would be a significant malleability attack.</li>
<p>There is a generic brute force attack against near second preimage resistance. The adversary generates UAs at random with known keys, until one has an encoding that partially collides with one of the
<p>There is also a generic brute force attack against nonmalleability. The adversary modifies the target Address slightly and computes the corresponding decoding, then repeats until the decoding is valid and also useful to the adversary (e.g. it would lead to the Sender using a Transparent Address). With
<sectionid="usage-for-unified-addresses-ufvks-and-uivks"><h4><spanclass="section-heading">Usage for Unified Addresses, UFVKs, and UIVKs</span><spanclass="section-anchor"><arel="bookmark"href="#usage-for-unified-addresses-ufvks-and-uivks"><imgwidth="24"height="24"src="assets/images/section-anchor.png"alt=""></a></span></h4>
<p>In order to prevent the generic attack against nonmalleability, there needs to be some redundancy in the encoding. Therefore, the Producer of a Unified Address, UFVK, or UIVK appends the HRP, padded to 16 bytes with zero bytes, to the raw encoding, then applies
<p>It would be possible to make an attack more expensive by making the work done by a Producer more expensive. (This wouldn't necessarily have to increase the work done by the Consumer.) However, given that Unified Addresses may need to be produced on constrained computing platforms, this was not considered to be beneficial overall.</p>
<p>The padding contains the HRP so that the HRP has the same protection against malleation as the rest of the address. This may help against cross-network attacks, or attacks that confuse addresses with viewing keys.</p>
bytes. The restriction to a single Address with a given Typecode (and at most one Transparent Address) means that this is also the maximum length as of NU5 activation.</p>
bytes plus the size of a BLAKE2b hash state. However, it is possible to reduce this by streaming the
<spanclass="math">\(d\)</span>
part of the jumbled encoding three times from a less memory-constrained device. It is essential that the streamed value of
<spanclass="math">\(d\)</span>
is the same on each pass, which can be verified using a Message Authentication Code (with key held only by the Consumer) or collision-resistant hash function. After the first pass of
<spanclass="math">\(d\)</span>
, the implementation is able to compute
<spanclass="math">\(y;\)</span>
after the second pass it is able to compute
<spanclass="math">\(a;\)</span>
and the third allows it to compute and incrementally parse
<spanclass="math">\(b.\)</span>
The maximum memory usage during this process would be 128 bytes plus two BLAKE2b hash states.</p>
is quite complicated, we do not require all Consumers to support streaming. If a Consumer implementation cannot support UAs / UVKs up to the maximum length, it MUST nevertheless support UAs / UVKs with
bytes. Note that this effectively defines two conformance levels to this specification. A full implementation will support UAs / UVKs up to the maximum length.</p>
<p>The authors would like to thank Benjamin Winston, Zooko Wilcox, Francisco Gindre, Marshall Gaucher, Joseph Van Geffen, Brad Miller, Deirdre Connolly, Teor, and Eran Tromer for discussions on the subject of Unified Addresses.</p>
