# Announcing Halo ARC
**URL:** https://forum.zcashcommunity.com/t/announcing-halo-arc/39053
**Category:** General
**Created:** [April 12, 2021, 3:50pm UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053 "2021-04-12T15:50:52Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Shawn](https://forum.zcashcommunity.com/u/Shawn)
#### Post date: [April 12, 2021, 3:50pm UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/1 "2021-04-12T15:50:53Z")
> Electric Coin Co. (ECC) today announced **Halo Arc for Zcash,** a product suite to launch the next generation of Zcash. It includes updates to Zcashd, the ECC Reference Wallet apps and the ECC wallet SDKs.
> Halo Arc leverages two upcoming Zcash improvements: Network Upgrade 5 (NU5) and unified addresses. NU5 will move Zcash to the Halo proving system, representing the continual evolution of our zk-SNARK technology stack. Halo removes the need for the trusted setup and upgrades the protocol’s underlying cryptography.
> Unified addresses, a complementary feature, introduce a future-proof address format that prioritizes shielded adoption. Later this week, we’ll release a blog post with a deeper explanation of unified addresses, how they work and what it means for supporting Zcash users to shield by default.
> The planned release of Halo Arc is Oct. 1, 2021\*, to coincide with the activation of [Network Upgrade 5](https://electriccoin.co/blog/nu5-proposed-features/) (NU5)\*\*. NU5 will be the first mainnet activation of the Halo proving system, marking a significant achievement in the evolution of zero knowledge proof cryptography.
> The Halo Arc product suite includes:
> - **ZCASHD, NU5-COMPATIBLE CONSENSUS NODE:** Zcashd is the consensus node for Zcash. Zcashd will support the upcoming network upgrade, which includes the Orchard Shielded Protocol ([ZIP 224](https://zips.z.cash/zip-0224)), non-malleable transaction IDs ([ZIP 244](https://zips.z.cash/zip-0244)), a new transaction version format ([ZIP 225](https://zips.z.cash/zip-0225)), and unified addresses ([ZIP 316](https://github.com/zcash/zips/issues/470)).
> - **ECC REFERENCE WALLET (iOS and Android):** ECC Reference Wallet is a beta reference implementation of a Zcash wallet for Android and iOS, available as open source.
> - **NU5-COMPATIBLE WALLET SDKS:** ECC maintains wallet SDKs for Android and iOS. These SDKs will support the upcoming network upgrade, including a new transaction format, the Orchard shielded pool and unified addresses.
> - **AUTO-SHIELDING FEATURE:** Auto-shielding lets users (more specifically their wallets) automatically move funds from a transparent address to the latest shielded ZEC pool. Auto-shielding, along with unified addresses, will facilitate increased user privacy and a better overall user experience. Through auto-shielding, wallets can offer their users funds that are shielded by default, regardless of the originating address.
> - **AUTO-MIGRATION FEATURE:** Auto-migration is a mechanism for wallets to seamlessly move funds to the most modern shielded pool supported by the wallet. This feature will also make it easier to deprecate older pools.
> - **IMPROVED NOTE MANAGEMENT:** Improved note management reduces the time users need to wait between sending transactions. This means that lightclients will be able to send one transaction immediately after another.
> Halo Arc represents a new ECC strategy, which bundles upgrades, products and features into regular releases. These bundles could include any or all of the products that ECC develops, such as Zcashd, [Lightwalletd](https://zcash.readthedocs.io/en/latest/rtd_pages/lightclient_support.html), wallet SDKs, and wallet source code.
> As Zcash development decentralizes, the broader Zcash community will benefit from a greater diversity of products, such as the Zebrad consensus node from the Zcash Foundation and lightclient infrastructure funded by ZOMG. By emphasizing products as well as the underlying protocol, ECC can package and promote compatible software across the Zcash technology stack, from protocol to wallets.
> **[Halo Arc for Zcash proposed for release later this year](https://electriccoin.co/blog/halo-arc-for-zcash-proposed-for-release-later-this-year/)**
>
> NU5 will move Zcash to the Halo proving system, representing the continual evolution of our zk-SNARK technology stack. Unified addresses introduce a future-proof address format that prioritizes…
[https://www.coindesk.com/zcash-halo-arc-timeline-protocol-privacy-update](https://www.coindesk.com/zcash-halo-arc-timeline-protocol-privacy-update)
---
### Author:  [@covfefe](https://forum.zcashcommunity.com/u/covfefe)
#### Post date: [April 12, 2021, 6:29pm UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/2 "2021-04-12T18:29:38Z")
Excellent, looks like a lot of important improvements are on the way
---
### Author:  [@hanh](https://forum.zcashcommunity.com/u/hanh)
#### Post date: [April 13, 2021, 6:35am UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/3 "2021-04-13T06:35:20Z")
What user facing improvement do you see? That part is not clear to me.
---
### Author:  [@den](https://forum.zcashcommunity.com/u/den)
#### Post date: [April 13, 2021, 6:38am UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/4 "2021-04-13T06:38:37Z")
The UAs seem to be a nice user experience improvement. **If** I understand correctly, they will send shielded and receive shielded by default.
No need for the user to select which address to use in his wallet since it will be handled automatically.
---
### Author:  [@hanh](https://forum.zcashcommunity.com/u/hanh)
#### Post date: [April 13, 2021, 6:50am UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/5 "2021-04-13T06:50:12Z")
Well, if there was no upgrade, you wouldn’t need this since the current zs address do that. The problem it solves is due to the various value pools (sprout, sapling, orchard,…) that current use different addressing schemes. Sure it is nice to have a solution but the users expect it.
---
### Author:  [@den](https://forum.zcashcommunity.com/u/den)
#### Post date: [April 13, 2021, 7:01am UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/6 "2021-04-13T07:01:38Z")
Sure, but that implies you already chose the zs address as a user instead of a t address. It is an easy and straightforward choice for many, but might not be for new users. (Again, that’s how I understood it, not 100% sure yet).
---
### Author:  [@hanh](https://forum.zcashcommunity.com/u/hanh)
#### Post date: [April 13, 2021, 7:07am UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/7 "2021-04-13T07:07:57Z")
Same for UA, they are shielded. You chose them over t addr too.
---
### Author:  [@Shawn](https://forum.zcashcommunity.com/u/Shawn)
#### Post date: [April 13, 2021, 4:04pm UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/8 "2021-04-13T16:04:03Z")
Interesting, so UAs are shielded? I thought it was combining T&Z somehow…
I’m still a bit unclear as to how these UAs work,
Now we have:
1. T address
2. Z address Sprout
3. Z address Sapling
After Halo we will have:
1. T address
2. Z address Sprout
3. Z address Sapling
4. Unified Address
Or is it:
1. T address
2. Unified Address
Or:
1. Unified Address
:thinking::thinking:
---
### Author:  [@hanh](https://forum.zcashcommunity.com/u/hanh)
#### Post date: [April 13, 2021, 5:02pm UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/9 "2021-04-13T17:02:07Z")
I’m not clear either. I understood they were shielded from the article:
“With Halo Arc, we’re making it easy for wallets to support shielded Zcash by default,” said Swihart. “Users of supporting wallets will be able to give counterparties a single address and know that funds will be sent to their shielded address, regardless of whether the sender supports shielded addresses.”
It seems it means
1. T addr
2. UA
???
---
### Author:  [@Autotunafish](https://forum.zcashcommunity.com/u/Autotunafish)
#### Post date: [April 13, 2021, 5:12pm UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/10 "2021-04-13T17:12:57Z")
We can still count sprout but I’d just substitute orchard addys in that list and also potentially UDA addys
---
### Author:  [@adityapk00](https://forum.zcashcommunity.com/u/adityapk00)
#### Post date: [April 13, 2021, 5:18pm UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/11 "2021-04-13T17:18:33Z")
A lot of the details of the Unified Addresses need to be figured out, especially by wallet developers like myself, but here’s some intuition to help the thinking around it.
Imagine that we define a Unified Address as simply a zcash URI. The URI is of the format:
`zcash:?alternate.sprout=&alternate.sapling=&alternate.orchard=`
So, when a reciever’s wallet wants to display a Unified address, it constructs this URI, filling in all the address formats that it is capable of recieving. JAXX wallet might fill in just the ``, while Zecwallet Desktop might fill in all taddr, sapling and orchard addresses and maybe Zecwallet Mobile will fill in only taddr and orchard address.
Then, when the sender’s wallet reads the Unified Address (which is just the zcash URI string), it can then figure out
1. OK, the receiver can receive `` and `` types of transactions.
2. I can send ``, `` and `` types of transactions.
3. I have funds in `` and ``
And then decide what type of transaction to construct and send.
This is not quite how it works, but it’s a helpful abstraction to think about how the Unified Addresses will work and how wallets will make use of them.
---
### Author:  [@Autotunafish](https://forum.zcashcommunity.com/u/Autotunafish)
#### Post date: [April 13, 2021, 5:22pm UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/12 "2021-04-13T17:22:48Z")
Does a zs to zo (orchard) bypass the turnstile or does it execute another or multiple aggregated txs like how auto shielding does now?
---
### Author:  [@den](https://forum.zcashcommunity.com/u/den)
#### Post date: [April 13, 2021, 6:38pm UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/13 "2021-04-13T18:38:46Z")
some extra info here:
>
>
> \### Unified Address Overview
>
> Unified Addresses specify multiple methods for p…ayment to a Recipient's Wallet. The Sender's Wallet can then non-interactively select the method of payment.
>
> Importantly, any wallet can support Unified Addresses, even when that wallet only supports a subset of payment methods.
>
> Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new address type.
>
> \### Status
>
> This ticket is a proposed set of requirements, which I'd like to refine with Zcash development community to see if we can agree on a standard along these lines. If there's enough support (especially from wallet vendors), the next step would be to draft a ZIP specification that meets these requirements.
>
> At Electric Coin Co, we have a desire to see if the ecosystem can safely standardize on this approach \_prior\_ to activating Orchard. The rationale for introducing Unified Addresses as a dependency is that it would avoid introducing the what these requirements call a "Legacy Address" for Orchard, because every Legacy Address introduces fragmentation costs to the ecosystem in usability (such as "address negotiation") and development/infrastructure support. We're sharing these requirements now to get feedback from Zcash core & wallet devs and the rest of the community on the requirements themselves, but also the timeline, the notion of combining this with Orchard, and other strategic factors.
>
> (Note: these are a paraphrase of messy internal documents around requirements, so I don't guarantee these represent the full agreement/commitment of all ECC folks, and we can/should just continue to refine them with the broader community.)
>
> \### Goals
>
> The goals for a Unified Address Standard are as follows:
>
> \- Simplify coordination between receivers and senders of Zcash wallets by removing complexity from negotiating address types.
> \- Provide a “bridging mechanism” to allow shielded wallets to successfully interact with (conformant) Transparent Only wallets.
> \- Allow older conformant wallets to interact seamlessly with newer wallets.
> \- Enable users of newer wallets to upgrade to newer transaction technologies and/or pools while maintaining seamless interactions with counterparties with older wallets.
> \- Allow wallets to shoulder more sophisticated responsibilities for shielding and/or migrating user funds.
> \- Allow wallets to potentially develop new transfer mechanisms without underlying protocol changes.
> \- Provide forwards compatibility that's 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.
> \- The standard works well for Zcash today and upcoming potential upgrades, yet it also anticipates even broader use cases down the road such as cross-chain functionality.
>
> \### Concepts and Terminology
>
> \- A \_Recipient\_ is a wallet or other software that can receive ZEC transfers (or in the future potentially other assets or transaction-based state changes).
> \- A \_Sender\_ is a wallet or other software that can send ZEC transfers (or other assets, or other future consensus state side-effects).
> \- Wallets follow a model \_Interaction Flow\_ as follows:
> - First, a Recipient \_generates\_ an Address.
> - Second, the Recipient wallet or human user \_distributes\_ this Address through any number mechanisms which may be "out-of-band" (example: they spray paint a QR Code on a sign) or they may be more or less "in-band" (example: they include a \`Reply-To\` address in an encrypted memo following a common standard).
> - Third, a Sender wallet or user \_imports\_ the Address through a variety of mechanisms (QR Code scanning, cut'n'paste, "in-band" protocols like Payment URIs or \`Reply-To\` memos).
> - Fourth, the Sender wallet executes a \_Transfer\_ of ZEC (or other assets or future protocol state changes) to the Address.
> - These steps are a funnel: the same Address may be distributed 0 or more times through different means. Zero or more Senders may import addresses. Zero or more of those may execute a Transfer. A single Sender may execute multiple Transfers over time from a single import.
> \- An \_Address\_ is either a \_Legacy Address\_ or a \_Unified Address\_.
> \- A \_Unified Address\_ (henceforth \_UA\_) combines multiple \_Receivers\_.
> \- A \_Legacy Address\_ (or \_LA\_) is a Transparent, Sprout, or Sapling Address.
> \- A \_Receiver\_ is the necessary information to transfer ZEC \[1\] to the \_Recipient\_ which generated that \_Receiver\_ using a specific \_Transfer Protocol\_.
> - Each Receiver is associated unambiguously with a specific \_Receiver Type\_.
> - Each \_Receiver Type\_ by definition designates unambiguously a \_Transfer Protocol\_.
> \- A \_Transfer Protocol\_ fully specifies how a \_Sender\_ can transfer ZEC (or issue other kinds of relevant transaction actions) to the \_Recipient\_. For example, the \_Transfer Protocol\_ for a \_Sapling Receiver\_ is the subset of the Zcash protocol required to successfully transfer ZEC using either \`Sapling Spend/Output Transfers\` as specified in the current Zcash Protocol Spec.
> - Clarification: 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.
> - Clarification: All of the consensus rules around Transaction and Block validity as well as Proof-of-Work consensus and so on are dependencies of the current set of existing \_Transfer Protocols\_. This standard anticipates the possibility of future \_Transfer Protocols\_ which \_do not\_ rely on Zcash base layer consensus.
> \- A \_Transport Encoding\_ is the externally visible encoding of an Address. It is common both in this document (where we believe it's unambiguous) and in casual usage for people to conflate an \_Address\_ with it's \_Transport Encoding\_.
>
> Examples:
>
> \- \*\*Example 1:\*\* A Transparent \`P2PKH\` Receiver may be encoded with the existing well known \`t1-\` prefixed base58 Legacy Address encoding for Transparent Addresses.
> \- \*\*Example 2:\*\* A Transparent \`P2PKH\` Receiver may be encoded as the sole Receiver within a Unified Address using the (single, standard) Unified Address encoding.
>
> \### Requirements
>
> \#### Addresses
>
> \- A Unified Address (or UA for short) combines one or more Receivers.
> \- When new \_Transport Protocols\_ are introduced to the Zcash protocol after Unified Addresses are standardized those SHOULD introduce new \_Receiver Types\_ but \_not\_ 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.
>
> \#### Receivers
>
> \- Every Wallet MUST anticipate and properly parse a UA with any unknown arbitrary Receiver Type.
> \- When \_Transferring\_ a Sender MUST behave as if any unknown Receiver Type is simply not present for the purposes of the transfer.
> \- A Wallet MAY process unknown Receiver Types by indicating to the user their presence or similar information for usability or diagnostic purposes.
>
> \#### Transport Encoding
>
> \- The encoding is "opaque" to human readers: it does NOT allow visual identification of which Receivers or Receiver Types are present.
> - Rationale: The general thinking behind UAs is to allow wallets to streamline user experience. If human users can parse a UA and alter their behavior based on that, then different users will end up using the same wallet very differently. Note that this does not preclude a wallet from providing user-friendly displays or indications about Receiver support, and the wallet's UX design can decide when and how to do this and build a behavioral flow around that.
> \- The encoding is resilient against typos, transcription errors, cut'n'paste errors, unanticipated truncation, or other anticipated UX hazards. (FIXME: How resilient? I generally think "as good as base58 or bech32 is good enough" but I haven't studied this area well.)
> \- The encoding works well in QR Codes.
> \- The encoding fits into ZIP-321 Payment URIs and general URIs without introducing parse ambiguities.
> \- The encoding MUST support an arbitrary number of unknown Recipient Types without requiring centralized coordination around the encoding for those new Types.
> - However, the encoding may provide for optimizations for a well known set of standardized Receiver Types where those optimizations require centralized coordination. For example there may be a distinction between a more optimized "reserved space" that's allocated through centralized coordination as long as there's also a possibility for permissionless experimentation (similar thinking to HTTP \`X-\` headers or "small values are reserved, but large random values are open to all).
> - The encoding MUST allow all wallets to safely and correctly parse out unknown Receiver Types well enough to ignore them.
>
> \#### Transfer
>
> \- When executing a \_Transfer\_ the Sender selects a transfer method via a \_Selection\_ process.
> \- \_Selection\_ MUST treat any unrecognized Receiver as if it were absent.
> - By implication: \_Selection\_ must behave identically between any two UAs where one is a subset of the other containing all of the same \_known\_ Receivers and no \_unknown\_ Receivers.
> - This property is crucial for forwards compatibility to ensure users who upgrade to newer protocols / UAs don't lose the ability to smoothly interact with older wallets.
> - 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.
> - This property also allows Transparent-Only wallets to upgrade to shielded support without re-acquiring counterparty UAs, or even when they are re-acquired the user flow and usability will be minimally disrupted.
>
> \### Open Issues and Known Concerns
>
> FIXME: We have a few of these I will add in future edits. This is especially true of privacy impacts of transparent or cross-pool transactions and the associated UX issues.
I know now I’ll need the extra article to get a better idea of what it consists of 🙂
---
### Author:  [@joshs](https://forum.zcashcommunity.com/u/joshs)
#### Post date: [April 13, 2021, 9:40pm UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/14 "2021-04-13T21:40:20Z")
That’s the intent. Taddrs are still necessary. But the UA should encapsulate all address types (including novel address types for interop and L2) and supplant shielded address. For Orchard and future pools, no native address will be available. It must go through a UA. We’re planning to post an explainer blog tomorrow morning.
---
### Author:  [@hanh](https://forum.zcashcommunity.com/u/hanh)
#### Post date: [April 14, 2021, 1:16am UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/15 "2021-04-14T01:16:05Z")
@den Thanks for the link. It is very helpful.
@joshs From what I understand, future network upgrades will require a new UA for the user?
For example, let’s say there is a Sequoia upgrade. In order to have my current UA (sprout + sapling) include it as a recipient I will have to generate a new UA that has sprout + sapling + sequoia ?
Thanks
---
### Author:  [@joshs](https://forum.zcashcommunity.com/u/joshs)
#### Post date: [April 14, 2021, 1:37am UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/16 "2021-04-14T01:37:58Z")
Not necessarily. For example, Overwinter and Canopy did not require new address types. Orchard changes the underlying cryptography and requires a new pool, as did Sapling.
If a new pool is created, the wallet should be able to supply a UA that includes support of the new pool without a change to the address format, abstracting that complexity away from the user.
---
### Author:  [@hanh](https://forum.zcashcommunity.com/u/hanh)
#### Post date: [April 14, 2021, 1:48am UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/17 "2021-04-14T01:48:36Z")
But even if the address type is the same, wouldn’t you still need to indicate support in the UA if it is a different value pool?
And if the address type is different, you need to have a new UA, right?
---
### Author:  [@Autotunafish](https://forum.zcashcommunity.com/u/Autotunafish)
#### Post date: [April 14, 2021, 2:46am UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/18 "2021-04-14T02:46:35Z")
Pool deprecation would necessitate it (blob of raw data under the UA header) needing modified as well and I think it was an automatic modification if the wallet indicates support but the ‘UA’ is/can be a permanent address (I believe).
---
### Author:  [@hanh](https://forum.zcashcommunity.com/u/hanh)
#### Post date: [April 14, 2021, 3:09am UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/19 "2021-04-14T03:09:22Z")
> [@Autotunafish](#):
>
> ‘UA’ is/can be a permanent address (I believe).
I think it’s more like an “address pack”. The UA combines several legacy addresses together. But if there is a new type of address, it will not be covered. IMO, the term “universal” is a bit inaccurate as it implies future proof.
If you don’t upgrade your UA, you will not benefit from potential improvements in the crypto used by zcash.
---
### Author:  [@Autotunafish](https://forum.zcashcommunity.com/u/Autotunafish)
#### Post date: [April 14, 2021, 3:25am UTC](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053/20 "2021-04-14T03:25:57Z")
I’m not super hip to automated control like that either but I think its the metadata that the address ‘string’ points to that changes (to my understanding). (“don’t upgrade your UA” I think is why Nathan expanded on explicit error handling because it wouldn’t be fullproof anyways (fixin Zookos triangle is hard!))
[Next page](https://forum.zcashcommunity.com/t/announcing-halo-arc/39053.md?page=2)