# Zingo 2.0, Sync With Max Zing

**URL:** <https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652>\
**Category:** Zcash Apps\
**Created:** [July 14, 2025, 7:11pm UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652 "2025-07-14T19:11:59Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**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:** [July 14, 2025, 7:11pm UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/1 "2025-07-14T19:11:59Z")

</div>

Well folks.. it’s here! Zingo 2.0 available in Apple and Google app stores. Check it out, and keep an eye on this thread to hear all about this **comprehensive** upgrade!

---

<div class="post-metadata">

**Author:** ![markoosh](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/markoosh/32/39955_2.png) [@markoosh](https://forum.zcashcommunity.com/u/markoosh)\
**Post date:** [July 15, 2025, 3:05am UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/2 "2025-07-15T03:05:05Z")

</div>

I like the “Danger zone” and the new transparent address option!

---

<div class="post-metadata">

**Author:** ![Batuhan](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/batuhan/32/32784_2.png) [@Batuhan](https://forum.zcashcommunity.com/u/Batuhan)\
**Post date:** [July 15, 2025, 8:02pm UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/3 "2025-07-15T20:02:10Z")

</div>

The Turkish translation looks great. More people in Turkey will use Zingo, and in their own language too!  
Thanks for the collaboration.

---

<div class="post-metadata">

**Author:** ![karentaponte](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/karentaponte/32/43080_2.png) [@karentaponte](https://forum.zcashcommunity.com/u/karentaponte)\
**Post date:** [July 15, 2025, 8:06pm UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/4 "2025-07-15T20:06:47Z")

</div>

🔐 Zingo! Wallet 2.0.0 is here! This version gives you more control over your funds, greater privacy with Tor, and new ways to organize your shielded addresses.  
Now with Pepper Sync 2.0, you can spend even before sync completes—without sacrificing clarity or security.  
It also includes minimal confirmations, visual enhancements, and Turkish language support.

Here’s everything that’s new 👉 [Update 2.0.0](https://free2z.cash/zingolabs/zpage/pepper-sync-20-check-balance-with-tor-diversified-addresses-and-much-more)

 ![](https://global.discourse-cdn.com/zcash/original/3X/6/c/6c83df2601001225e975d5b5ac259aeadf6626c1.jpeg)

---

<div class="post-metadata">

**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:** [July 17, 2025, 12:20am UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/6 "2025-07-17T00:20:12Z")

</div>

Thanks @markoosh!

Here is some of the thinking we put into this feature.

## What’s Safety?

In the Rust programming language source code is “Safe” by default which means that the compiler guarantees that certain problems (with resource allocation) cannot occur.

If you can convince a Rust compiler to compile your source code, then you know that it doesn’t have certain kinds of bugs! It so happens that the kinds of bugs that you _can’t_ have are some of the most important sources of security vulnerabilities in other languages.

Now.. _sometimes_ you might want to write a program that does something that is _risky_. You understand what needs to happen, and you can write the code in a “safe” way, but the guaranteed safety that comes from the Rust compiler has to be switched off in a specific location, so that you can execute the _risky_ but necessary operations you need for your Use case. To do what you need to do, you have to mark the risky code specifically as “ **Unsafe** ”.

## How Zingo 2.0 Approaches Safe Taddresses

This is the philosophy that the Zingo 2.0 interface used to approach taddresses.

Zingo 2.0 is private by default it does not allow a user to offer a taddress to a sender. This is because (as in Rust) taddresses allow dangerous information leakage, and are a potential important source of security vulnerabilities.

But (as in Rust) you might know that you _do_ need to offer a taddress for your use case. To do so in Zingo 2.0, you must turn off the “private by default” behavior of the application-in-service, and enter “ **The Danger Zone** ”, analogous to entering an “unsafe” block of Rust code. In that context you can access your taddress, or generate a new (single use?!) one.

We think this the correct pattern for dealing with dangerous, but important, functionality. The application-in-service (Zingo 2.0) has only enough authority to enforce private-by-default behavior if that’s what the User requires.

## Recommendation For Safe Operation

To minimize the danger from leaky taddress use, Zingo2.0 offers a convenient taddress generation feature, so that each use of a taddress can produce a unique taddress that’s uncorrelated to any other revelations.

This is a feature that was specifically requested by @frankbraun in this [blog post](https://frankbraun.org/t-addr/) in which he correctly (in my opinion) highlights the integration role of taddresses.

If you must expose a dangerous taddress, please generate a single use taddress uses the “New Address” button offered by Zingo 2.0.

---

<div class="post-metadata">

**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:** [July 17, 2025, 12:36am UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/7 "2025-07-17T00:36:27Z")

</div>

## Reasoning About Agentic Applications

It’s increasingly the case that applications are “[agentic](https://en.wikipedia.org/wiki/Agentic_AI)”, able to pursue goals without human intervention. We think about this when we’re attempting to design tools to enhance autonomy and dignity.

To contextualize our thinking and inform our design decisions, we turn to the principles expounded at [erights.org](http://erights.org). For this release of Zingo 2.0 we paid particular attention to The Principle Of Least Authority.

We chose to allow the application sufficient authority to generate new addresses, but we did not delegate the capability of **choosing** to do so to the app, rather we reserved that capability for the User. We think that allowing the app to automatically generate addresses provides it with more than the Least Authority it requires.

Our design requires User Consent, for operations we believe that the User has sufficient capability to make.

As we have reasoned about this internally, we developed a term of art, The Application in Service (AIS), to clarify how we think the Application should relate to the User.

---

<div class="post-metadata">

**Author:** ![frankbraun](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/frankbraun/32/45665_2.png) [@frankbraun](https://forum.zcashcommunity.com/u/frankbraun)\
**Post date:** [July 17, 2025, 10:33pm UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/8 "2025-07-17T22:33:20Z")

</div>

> [@zancas](#):
>
> To minimize the danger from leaky taddress use, Zingo2.0 offers a convenient taddress generation feature, so that each use of a taddress can produce a unique taddress that’s uncorrelated to any other revelations.

Interesting design choice, I like it.

I just tested it and if you don’t mind, here are some additional suggestions, based on my understanding that you want to give the most authority to the user and let him make explicit decisions, rather than having things done automatically for him:

- If a t-address has already been used I would show a warning on the screen where it is shown and advise the user to generate a new one, to prevent linking two transparent transactions together by reusing the t-address.
- If a user has received funds on two (or more) _different_ t-addresses shielding them will link them together. If you want to give the user explicit choice you could warn him about the the linking and offer him a choice to just shield one of them (to prevent linking).
- It might also be a good idea to show the amount of time that has elapsed since the last shielding operation (to make timing attacks harder).
- Maybe you can even show the number of transactions that happened _on chain_ since the last shielding transaction, if you have an easy way to query that from the backend. To give the user a better estimation if enough time has elapsed since the last shielding transaction to make timing attacks harder.
- Funds received in multiple transactions on the same t-address can and should always be shielded together. They are linked anyway, so nothing can be gained anymore by shielding them separately.

In this post I describe a similar possible mechanism for Zashi, but with a UX where most decisions are made automatically for the user:

> [@Why does Zashi only allow 1 Transparent address?](https://forum.zcashcommunity.com/t/why-does-zashi-only-allow-1-transparent-address/51538/7):
>
> I ordered one just so I can use it to store shielded Zcash on a hardware wallet. Having the ability to securely store shielded Zcash “at rest” is crucial for privacy in my opinion and you don’t want to store larger amounts on Zashi itself (because of the inherent security issues of mobile phones, not the software itself). And privacy is the biggest differentiator of Zcash, so that’s a very important feature to have. Would it be great to have support for shielded addresses in more widely used h…

---

<div class="post-metadata">

**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:** [July 17, 2025, 10:56pm UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/9 "2025-07-17T22:56:48Z")

</div>

This is fantastic feedback! Thanks very much.

Perhaps we could have our cake and eat it too, so to speak, by letting the user opt in to these behaviors as a policy, so that don’t have to manually specify each behavior every time.

---

<div class="post-metadata">

**Author:** ![frankbraun](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/frankbraun/32/45665_2.png) [@frankbraun](https://forum.zcashcommunity.com/u/frankbraun)\
**Post date:** [July 17, 2025, 11:15pm UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/10 "2025-07-17T23:15:14Z")

</div>

You’re welcome. Advancing to the next unused t-address is pretty standard in Bitcoin wallets, so I would definitely consider that, I don’t think you gain anything by having the user do that manually. The user can still manually retrieve old addresses, if he wishes to do so, and in that case I would warn him about linkability.

I’ll think a bit more about “shielding policies”.

---

<div class="post-metadata">

**Author:** ![dismad](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/dismad/32/18432_2.png) [@dismad](https://forum.zcashcommunity.com/u/dismad)\
**Post date:** [July 19, 2025, 5:22pm UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/11 "2025-07-19T17:22:16Z")

</div>

> [@zancas](#):
>
> Zingo 2.0 is private by default it does not allow a user to offer a taddress to a sender. This is because (as in Rust) taddresses allow dangerous information leakage, and are a potential important source of security vulnerabilities.
> 
> But (as in Rust) you might know that you _do_ need to offer a taddress for your use case. To do so in Zingo 2.0, you must turn off the “private by default” behavior of the application-in-service, and enter “ **The Danger Zone** ”, analogous to entering an “unsafe” block of Rust code. In that context you can access your taddress, or generate a new (single use?!) one.

I like this approach as it gives user the choice, ty!

 ![image0](https://global.discourse-cdn.com/zcash/original/3X/9/9/995a24cd226700a384b91c7022440c0d6ee4d8dd.jpeg)

#### Feedback:

It wasn’t immediately clear to me the “Exposed transparent address” was a button, I thought of it as a label and proceeded to click the green “GET NEW ADDRESS” thinking it was adding a transparent reciever in the UA.

---

<div class="post-metadata">

**Author:** ![rebsijo](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/rebsijo/32/41163_2.png) [@rebsijo](https://forum.zcashcommunity.com/u/rebsijo)\
**Post date:** [November 23, 2025, 10:23pm UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/12 "2025-11-23T22:23:18Z")

</div>

Hello can i get assistance I have an issue

---

<div class="post-metadata">

**Author:** ![Shawn](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/shawn/32/187_2.png) [@Shawn](https://forum.zcashcommunity.com/u/Shawn)\
**Post date:** [November 23, 2025, 10:25pm UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/13 "2025-11-23T22:25:31Z")

</div>

> [@rebsijo](#):
>
> I have an issue

Post your question and someone may be able to assist.

There is no official support channel or help system, ignore anyone trying to DM you.

---

<div class="post-metadata">

**Author:** ![rebsijo](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/rebsijo/32/41163_2.png) [@rebsijo](https://forum.zcashcommunity.com/u/rebsijo)\
**Post date:** [November 23, 2025, 10:50pm UTC](https://forum.zcashcommunity.com/t/zingo-2-0-sync-with-max-zing/51652/14 "2025-11-23T22:50:35Z")

</div>

I sent zcash using zashi app to my exodus wallet and the balance appears but I cannot spend it in any way I even try using zingo to reshield it but it still won’t work
