# Implement Orchard **URL:** \ **Category:** Applications\ **Created:** [August 4, 2022, 9:11pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706 "2022-08-04T21:11:03Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![zancas](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zancas/32/42011_2.png) [@zancas](https://forum.zcashcommunity.com/u/zancas)\ **Post date:** [August 4, 2022, 9:11pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/1 "2022-08-04T21:11:03Z")
ZingoLabs is implementing Orchard in its mobile app! > **[Home - Zcash Foundation](https://zfnd.org/)** > > Advancing Digital Privacy The Zcash Foundation is a 501(c)(3) public charity building financial privacy infrastructure for the public good, primarily serving users of the Zcash protocol and blockchain. Donate Our Mission To help sustain and improve... The astute might recall this: > [@Announcing Zingo!](https://forum.zcashcommunity.com/t/announcing-zingo/42371): > > Hello Zcashers! (Context Note) I am writing this post to announce “zingo” a next generation zcash application that is being built on top of orchard. Terminology: “Developer-User”, (abbreviation DevUser, also UserDev): “A hacker, software or otherwise, that uses the thing that they are building.” What is zingo? It’s a Developer-Used wallet created by it’s Users. Store your funds in it, like all of its DevUsers do, and you will get the same privacy, security, and viability benefits that… Conspicuously not appearing in this application: - `Privacy Enhancement Fee` - `Direct Feature Bids` - `Multi-Signature Spends` - `Sync Upgrades` Does ZingoLabs still aim for a self-sustaining application that aligns ZEC user and developer incentives?! Yes! That’s the plan.. where we’re heading… Is it within the scope of this grant? No! Since we began work on our vision for a sustainable, reliable, intuitive user-facing zcash app… it has become clear to us that the environment is more dynamic than anticipated! Which is exciting! But, is also a strong signal that we should focus on components that will certainly be relevant now, and push them to a state of completion before scheduling the next set of tasks. We have a great deal of uncertainty about the transaction volume (in any pool) going forward. We’re aware of rapid development on `zcashd`, and `zebrad`, and `warp-sync`. It’s not clear how those variables (`transaction-volume` and `transaction-state`) will change moving forward. Therefore we’re staying focused on our Orchard implementation. How do we fit into the wider economy? - our Orchard/Wallet implementation aims for portability, so we will be efficient at porting our solution to wallets - we’re refactoring our code to ease building against WASM for web-based applications `free2z/ZUUL` - we’re opening PRs against `librustzcash` and `orchard` - we’re providing test tools to facilitate `lightwalletd-proxy` testing ---
**Author:** ![dannasessha](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/dannasessha/32/20576_2.png) [@dannasessha](https://forum.zcashcommunity.com/u/dannasessha)\ **Post date:** [August 5, 2022, 5:31am UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/2 "2022-08-05T05:31:48Z")
![image](https://global.discourse-cdn.com/zcash/original/3X/f/6/f61db36ae59a3ab4695db828c323b0230a4cd4a2.jpeg) This is just a basic prototype logo, but I thought people might be interested in seeing a larger version of the image. 🙂 ---
**Author:** ![zancas](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zancas/32/42011_2.png) [@zancas](https://forum.zcashcommunity.com/u/zancas)\ **Post date:** [August 18, 2022, 8:24pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/3 "2022-08-18T20:24:48Z")
Hello [@dontpanicburns @wobbzz @aiyadt @BrunchTime @aquietinvestor] we’re chugging away on our implementation! Activity is visible here: > **[GitHub - zingolabs/zingolib: An API and test-app that exposes zcash...](https://github.com/zingolabs/zingolib)** > > An API and test-app that exposes zcash functionality for app consumption - GitHub - zingolabs/zingolib: An API and test-app that exposes zcash functionality for app consumption We’re confident that we’ll hit our first milestone. ---
**Author:** ![zancas](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zancas/32/42011_2.png) [@zancas](https://forum.zcashcommunity.com/u/zancas)\ **Post date:** [September 3, 2022, 12:17am UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/4 "2022-09-03T00:17:04Z")
Update, we did indeed complete our Milestone 1 on schedule. After some internal discussion, we intend to pull the current grant and reapply with specific amendments to address the concerns raised by the ZCG in their last meeting. > [@Zcash Community Grants Meeting Minutes 8/22/22](https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-8-22-22/42891): > > Below please find the latest [@ZcashGrants](https://forum.zcashcommunity.com/groups/zcashgrants) meeting minutes and Public Dashboard link. Attendance: Aditya Brian Burns Jason Michael Alex Bornstein (ZF resource) Daniel Wolande (ZF resource) Jack Gavigan (ZF resource) Danika Delano acting as notetaker Key Takeaways: ZCG members stated that Zcon3 was a success and they are invigorated and inspired. ZCG rejected the [Accelerating Zcash on FPGA Clusters](https://forum.zcashcommunity.com/t/accelerating-zcash-on-fpga-clusters/42395) grant and encouraged the applicant to solicit feedback on an arborist call. ZCG decided to l… ---
**Author:** ![zancas](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zancas/32/42011_2.png) [@zancas](https://forum.zcashcommunity.com/u/zancas)\ **Post date:** [September 5, 2022, 8:05pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/5 "2022-09-05T20:05:32Z")
[@ZcashGrants](https://forum.zcashcommunity.com/groups/zcashgrants) In response to questions raised [here](https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-8-22-22/42891), ZingoLabs is ammending its grant proposal in the following ways: 1. _smaller ask_: **$128\_520.00**. This substantially smaller asks reflects three changes: 2. _niche specification_: 3. _Target Userbase_ people who want a _reliable_ - _responsive_ mobile app: Finally, we’ll note that we’ve hit our first milestone, and are much more familiar with the codebase. ---
**Author:** ![AloeareV](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/aloearev/32/20303_2.png) [@AloeareV](https://forum.zcashcommunity.com/u/AloeareV)\ **Post date:** [September 5, 2022, 8:11pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/6 "2022-09-05T20:11:20Z")
Edit: Selected better images Some screenshots of the testflight app, (graphics are subject to change): ![zingo03](https://global.discourse-cdn.com/zcash/original/3X/a/6/a6a8be166c9f4b3ee408f36972a3907bc5038a84.png) ![zingo04](https://global.discourse-cdn.com/zcash/original/3X/0/2/02153a1a975ba12aef02346d74c65964a820e614.png) ---
**Author:** ![tokidoki](https://avatars.discourse-cdn.com/v4/letter/t/dc4da7/32.png) [@tokidoki](https://forum.zcashcommunity.com/u/tokidoki)\ **Post date:** [September 6, 2022, 1:00am UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/7 "2022-09-06T01:00:21Z")
Should the last address option instead be “U-Unified”? If in the future, when Zingo decides to be an Orchard-focused wallet, then users can easily migrate their keys while keeping access to their balance. Anyway, I want to express my support for this grant to be approved. Cheers! ---
**Author:** ![AloeareV](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/aloearev/32/20303_2.png) [@AloeareV](https://forum.zcashcommunity.com/u/AloeareV)\ **Post date:** [September 6, 2022, 3:13pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/8 "2022-09-06T15:13:05Z")
Yes, it should be Unified. The unified addresses are currently orchard-only, we intend to rework that after we finish getting spending from the orchard pool working, so the names and interface there are a bit of a placeholder at the moment as they will need to be restructured anyway if we want to support the full set of possible UA combinations. ---
**Author:** ![nuttycom](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/nuttycom/32/9621_2.png) [@nuttycom](https://forum.zcashcommunity.com/u/nuttycom)\ **Post date:** [September 6, 2022, 3:15pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/9 "2022-09-06T15:15:47Z")
Ideally unified addresses will be the _only_ kind of address that’s readily available. You could then provide a second-level UI to obtain the transparent or Sapling components of the UA for use with legacy UI that don’t yet recognize UAs, but for the top level address, I don’t think you should have tabs at all. ---
**Author:** ![pacu](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/pacu/32/15383_2.png) [@pacu](https://forum.zcashcommunity.com/u/pacu)\ **Post date:** [September 6, 2022, 4:27pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/10 "2022-09-06T16:27:02Z")
This wallet seems to be a fork of ZecWallet Mobile. So it replicates the implementation of Orchard and misuse of Unified Addresses. Please note that Unified Addresses should be the only address users should share with the option of decomposing the receivers for recipients that can’t receive UAs (until they do). Using a UA-Encoded Orchard address should be considered an “[anti-pattern](https://en.wikipedia.org/wiki/Anti-pattern)” of Unified Addresses. UAs should be favored before any other kind of string encoded Addresses because they are a “Multi-Pool Wallet Management” Pattern that allows the users to delegate knowledge of pools and addresses to wallets and so that users only handle one type of address like all the other cryptocurrencies do (except XMR that has Master and common addresses and Zcash forks that have T and Z). This makes the protocol more flexible at the user end and provides not only the possibility for Protocol Developers to add new pools with their respective addresses, but to retire them as well. Zingo and ZecWallet should show the UA with Transparent, Sapling and Orchard receivers and then have a second screen that de-aggregates Transparent and Sapling for compatibility reasons EDIT: please don’t think of this as an “error” on your behalf. We should have had better documentations so developers didn’t have to figure it out by themselves. ---
**Author:** ![AloeareV](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/aloearev/32/20303_2.png) [@AloeareV](https://forum.zcashcommunity.com/u/AloeareV)\ **Post date:** [September 6, 2022, 4:40pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/11 "2022-09-06T16:40:22Z")
We’ve been deferring thinking too hard about the interface changes we’ll need to make until spending from the orchard pool is implemented, but this does sound like the ideal interface. The third milestone already includes reworking our UA interface so that we support all valid receiver combinations, this would be a simpler way of doing that than keeping all the legacy address code in there adjacent to the UAs anyway. Edit: After discussion with @zancas, we would be happy to change milestone 3 to expicitly include a switch to this interface. ---
**Author:** ![pkr](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/pkr/32/29938_2.png) [@pkr](https://forum.zcashcommunity.com/u/pkr)\ **Post date:** [September 6, 2022, 4:57pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/12 "2022-09-06T16:57:11Z")
Lol. Please hire a designer. ---
**Author:** ![zancas](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zancas/32/42011_2.png) [@zancas](https://forum.zcashcommunity.com/u/zancas)\ **Post date:** [September 6, 2022, 5:06pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/13 "2022-09-06T17:06:39Z")
I am favor of this UI… or something like it. Users shouldn’t face unnecessary options. ---
**Author:** ![hanh](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/hanh/32/27853_2.png) [@hanh](https://forum.zcashcommunity.com/u/hanh)\ **Post date:** [September 6, 2022, 6:03pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/14 "2022-09-06T18:03:21Z")
While I understand the desire to build a UI that supports future protocols, I feel that it hardly makes any difference today. ZWL shows: - T - Z - O as UA I think that you suggest: - T+Z+O as UA - T - Z Besides the order, the second UA has T & Z receivers. However, any wallet that understands how to decode a UA would use the O receiver until the next pool, wouldn’t it? If so, when would the T & Z receivers be used? ---
**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\ **Post date:** [September 6, 2022, 9:34pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/15 "2022-09-06T21:34:21Z")
> [@hanh](#): > > However, any wallet that understands how to decode a UA would use the O receiver until the next pool, wouldn’t it? > If so, when would the T & Z receivers be used? Not necessarily: - It is entirely possible (and an easier lift) for wallets to implement Unified Address decoding before implementing send-to-Orchard support. UAs that only contain Orchard receivers cannot interact with these wallets. - Example: exchanges that currently only allow withdrawals to transparent addresses, can and should allow withdrawals to UAs containing transparent receivers. This has the added benefit of being able to measure how many of their users _would_ withdraw to shielded if they could, which is a metric they can use as part of deciding whether to add shielded withdrawals to their engineering roadmap. - If the sender’s wallet has sufficient funds in the Sapling pool to create a transaction, then if the receiver’s UA contains both Sapling and Orchard receivers (i.e. the receiver is indicating their preference to receive funds into either of these pools), the sender’s wallet can create a fully-shielded Sapling-to-Sapling transaction instead of an amount-visible Sapling-to-Orchard transaction. ---
**Author:** ![hanh](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/hanh/32/27853_2.png) [@hanh](https://forum.zcashcommunity.com/u/hanh)\ **Post date:** [September 7, 2022, 12:43am UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/16 "2022-09-07T00:43:24Z")
> [@str4d](#): > > - Example: exchanges that currently only allow withdrawals to transparent addresses, can and should allow withdrawals to UAs containing transparent receivers. This has the added benefit of being able to measure how many of their users _would_ withdraw to shielded if they could, which is a metric they can use as part of deciding whether to add shielded withdrawals to their engineering roadmap. It seems to me that implementing t2z is of the same complexity as t2t because the builder takes care of everything. Therefore, IMO, if an exchange has decided to not withdraw to shielded, I don’t think it is because of engineering reasons. Likewise for transparent wallets, I think they chose to stick with a simple model and to let the recipient deal with shielded addresses themselves. In other words, I am not sure a transparent-only wallet will update to support UA because of the confusion it will cause to their users. > [@str4d](#): > > If the sender’s wallet has sufficient funds in the Sapling pool to create a transaction, then if the receiver’s UA contains both Sapling and Orchard receivers (i.e. the receiver is indicating their preference to receive funds into either of these pools), the sender’s wallet can create a fully-shielded Sapling-to-Sapling transaction instead of an amount-visible Sapling-to-Orchard transaction. Thanks. Is there a design/specification document describing the expected behavior? I could only find mentions of “shielded by default”, which can mean many different things. ---
**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\ **Post date:** [September 7, 2022, 1:00am UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/17 "2022-09-07T01:00:39Z")
> [@hanh](#): > > It seems to me that implementing t2z is of the same complexity as t2t because the builder takes care of everything. This is (sadly) false - or rather, it assumes the use of the Rust transaction builder (which I’d love everyone to be using, but alas). t2t can and is done in a variety of languages and platforms (because it is generally built on top of whatever language / platform was already being used for Bitcoin), while t2z currently requires Rust (because that’s the language in which the proving system and circuit are implemented in). Now, the Rust components can in theory be used anywhere that supports C FFI. However, integrating Rust components into an exchange’s (likely custom in-house) transaction builder implementation can be a significant engineering lift for teams that don’t have Rust experience. Guess how I know 🙂 > [@hanh](#): > > Is there a design/specification document describing the expected behavior? - [ZIP 316](https://zips.z.cash/zip-0316) describes how Unified Addresses must be interpreted by consumers of them. - The protocol specification and relevant ZIPs describe how transactions must be constructed. Beyond that, there is no specification document for how to send funds because there’s nothing else normative to specify: wallets get to decide what behaviour they implement that best serves their users’ interests. However, “ZIP 315: Best Practices for Wallet Implementations” ([in-progress draft](https://github.com/zcash/zips/pull/607)) is where we intend to provide general guidance on how wallets should construct transactions. ---
**Author:** ![steven-ecc](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/steven-ecc/32/26556_2.png) [@steven-ecc](https://forum.zcashcommunity.com/u/steven-ecc)\ **Post date:** [September 7, 2022, 2:22am UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/18 "2022-09-07T02:22:04Z")
@hanh note str4d’s comment about ZIP 315 being in progress. Given our focus on UX, we’ll want to review this in terms of general UX best practices before publishing so it’s subject to revision. ---
**Author:** ![hanh](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/hanh/32/27853_2.png) [@hanh](https://forum.zcashcommunity.com/u/hanh)\ **Post date:** [September 7, 2022, 2:42am UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/19 "2022-09-07T02:42:08Z")
Thanks @str4d @steven-ecc. ZIP 315 looks like a big chunk of work for any wallet implementer. ---
**Author:** ![decentralistdan](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/decentralistdan/32/28747_2.png) [@decentralistdan](https://forum.zcashcommunity.com/u/decentralistdan)\ **Post date:** [September 8, 2022, 10:19pm UTC](https://forum.zcashcommunity.com/t/implement-orchard/42706/20 "2022-09-08T22:19:04Z")
@zancas + Zingo Team, I am happy to announce that this grant proposal was approved at the most recent [@ZcashGrants](https://forum.zcashcommunity.com/groups/zcashgrants) Committee meeting! [Next page](https://forum.zcashcommunity.com/t/implement-orchard/42706.md?page=2)