The Encryption Norm. ECC Update

Hi Zeeps,

I posted the following on X this week:

This isn’t fiction or hopium. The use of encryption is inevitable if cryptocurrency is going to be used for financial transactions. Reports are that the use of stables is rising and 94 billion was moved over the last couple of years. Bitcoin is also growing but well behind at just over a billion in 2024. Sounds like a lot, but crypto volume vs total global payments volume is less than .1%. As crypto is used more pervasively, the world will wake up to the fact that the emperor has no clothes - quite literally.

A little over five years ago, Balaji, Zooko, and I co-authored a piece that posited that Zcash is the HTTPS of blockchains. When people realized the power of the internet for intermediated digital payments, encryption became the norm. Financial activity without encryption is not only intrusive but unsafe.

Some of us have been shouting this for some time, railing against the notion that Bitcoin’s transparency is a feature and not a bug. Maybe some are starting to catch on. Even Bitcoin flag bearer Michale Saylor is unnerved about people knowing how much Bitcoin he holds.

Um. Oops!

Encryption will be the norm for centralized money services businesses as they are forced to evolve, not from some high-minded ideology, but of the necessity of user protection and, perhaps even, of the need to be compliant with new encryption-supporting regulatory mandates.

We know that AI is going to make things worse as models are increasingly allowing for the aggregation of digital and real world information.

But let’s look beyond the very near term reality of the intersection of AI and cryptocurrencies. The internet as we know it is changing.

The old paradigm is search-driven and ad-based. The new paradigm is AI-based. As with crypto payments volume as compared with traditional payments, AI search is still only a fraction of the aggregate searches on the web, but this is shifting, and it will continue to shift. ChatGPT is replacing search.

But beyond search will be the use of AI agents to take care of the papercuts of life and automate our payments. I welcome the day that I can task my agent to procure me the cheapest Freak Show cabernet it can find when my stock runs low. Or maybe even pay my bills and optimize my portfolio. The AI agent representing the company that mows my lawn will send my AI agent which will review the invoice, cross-check it against the contract, pay the bill at the exact moment it becomes due and readjust my liquid balances as needed for other bills coming due soon.

Cryptocurrencies will be the currency for AI agents operating on our behalf. They will understand threat models and how to ensure funds are kept SAFU. Do you really believe that AI agents are going to default to exposing their master’s financial data to other AI agents? They will use encryption.

Every day, more projects are waking up and frantically attempting to bolt privacy onto their transparent chains. But it’s not a feature that can be bolted on. Containers with bolts thrust through them tend to be leaky. And mixing isn’t the answer. Let’s let a computer play Where’s Waldo with your financial data and see how that works out.

In the end, people just want to be and feel safe. They don’t want to think about how to buy new flip-flops for their beach vacation without putting their lives at risk. The answer is pure, easy-to-use, scalable, proven private digital money. Encrypted digital money will be the norm.

The (not so) normal things ECC did this week:

Zashi Product

What we did:

  • Reviewed and finalized base designs for the flow for swaps on NEAR.
  • Made significant progress in building the swap UI.
  • Shipped several UI iterations for testing on iOS.
  • WIP: NEAR 1ClickSwap API integration + business logic for the initial testing prototype.

What’s up next:

  • Review and test implementation of transaction submission over Tor and release it next week (Zashi 2.1 release scheduled for June 3rd/4th).
  • NEAR 1ClickSwap API integration + business logic for the initial testing prototype.
  • Evaluate all available options for the Maya integration and plan the next steps.

iOS Analytics

  • Unique Installs: 8.11k
  • ​​​Total Downloads: 9.74k
  • ​​​​​​​​​AppStore Rating: 4.9*

Android Analytics

  • Unique Installs: 3.8k
  • ​​​Total Downloads: 19k
  • ​​​​​​​​​AppStore Rating: 4.421*

Zashi Product Marketing

What we did:

  • Zashi Risk Model draft (interview with core TBD).
  • Zashi website redesign work.
  • Initiated process changes for evaluating user feedback.

What’s up next:

  • On/off-ramp research (ongoing) including Baxa, Spritz and Ramp
  • Zashi 2.1 comms
  • Add this info to Zashi video
  • Zashi user research and adoption plan.
  • Paper on T-Address use
  • Record interview with Aaluxx from Maya

Zcash Core

What we did:

  • The core team spent the week in person with Sean Bowe to work through the design and plans for Project Tachyon. I’ve seen photos of the whiteboards and heard from a reliable source that it was "EXTREMELY productive.”
  • Hired a new core team member! More information on that to come. He’ll join us in Prague for the Z|ECC Summit
  • The team also spent time on NU 6.1. The changes needed are expected to be released in a couple weeks and we will be able to move forward with testnet after the changes are incorporated into zebrad.

What’s up next:

  • Work in support of NU 6.1 and Zallet for NU7.

Other

The next Z|ECC Summit will be held in Prague the week of July 7th. We are now over capacity, and registrations are closed! It’s shaping up to be an amazing week. I drafted an agenda that I’ll review with the team and proposed workshop leaders this week. I’ll share it once we have it locked in.

We held the quarterly Bootstrap Board of Directors meeting. There is way too much going on to cover it all in the two hours we had together.

We are actively reviewing the pending Market Structure legislation in the US. Paul is also working with Project Glitch on planning for this year’s DC Privacy Summit.

We are developing a grant submission package for coinholder vote once the distribution mechanism and submission process are in place.

That’s all for this week.

Normalizing encryption,

Onward.

12 Likes

It is troubling to see a long close seemingly focused on the importance of privacy with project updates that literally promote the opposite (the required use of Zcash t-addresses in the integrations with NEAR and Maya).

Please stop claiming to care about Zcash privacy while simultaneously creating more barriers to the depreciation of its greatest privacy leak (t-address existence and integrations that require its usage).

1 Like

DEXs are critical on ramps for people that don’t have access to or want to use centralized exchanges for ZEC.

They also allow for bridging out - can pay someone in their preferred currency while keeping yourself shielded.

2 Likes

What prevents you from shielding the coins in your wallet immediately after receiving them? It’s basically the same thing.

You are so dissatisfied with the obvious progress that it gives rise to certain thoughts.

1 Like

Excellent message, Josh!

You are perfectly aware that “basically the same thing” is not an ideal Zcash is trying to represent.

The wonderful mathematicians that helped invent zk-SNARKs and/or helped Zcash implement them in the real world would not be pleased. We know this because of them started a thread about focusing more on privacy (Resetting Zcash) in this forum.

We can do better

Of course. We can and we do. But we need to start with transparent addresses because it’s guaranteed to work right away. Shielded addresses are unlike anything else in the blockchain world, so it takes time to implement. This is what we see from developer feedback. Devs states every time that it’s much more complicated than what they’ve had to work with before. So I’m grateful right now for those opportunities, but I’m also looking forward to more. And I think these things need our kind support.

1 Like

We are in complete agreement on the complicated part.

What you refer to as opportunities (t-address integrations) I consider moving backwards (creating more barriers to t-address depreciation).

Kind support is already happening in the form of generous paychecks. I wouldn’t appreciate this work even it was done for free (because I think it is harmful to the Zcash community goal of advancing privacy).

Many people agree with me. Some clearly agree with you as well.

When shielded voting arrives (and voices of privacy minded users are no longer shackled) we shall see where majority opinions stand.

I’m looking forward to the dollar stablecoin on the zcash platform. I believe it will be a great evolution, having a shielded dollar.

1 Like

I had already peeked Zashi’s repo recently and loved this! Congrats @joshs and team. And also Say hello to the new Core Dev for me :blush:

I use NEAR quite a lot make payments.

Volatility is a high price to pay when you are earning your living through crypto payments, so everyone asks you for payment in Stablecoins. Since gas are the breadcrumbs chainalysts use to link ETH accounts together, you can use NEAR to send the stablecoin ERC20 to that person just by withdrawing to the payee’s address** without having to fund a new ERC20 wallet with a Gas token. Cool huh?

Also, Both NEAR and Maya give you better ZEC price quotes than most exchanges, so you also make a few ZEC by not using CEXs.

** Note: This is risky, but I live in a tough region of the planet and I’d rather lose a few bucks than leaking my info.

2 Likes

Is it risky, or expensive? Or both? Why, if risky?

It’s risky in terms of that I don’t know (and I haven’t researched) what’s any troubleshooting workflow if this “withdrawal” that I actually send to the real recipient of the trade would be stall for some reason.

Example:

let’s say myself and your Tether fan alter-ego… let’s call that person… Incoming.doze :smile: requests 80 USDT.

incoming.doze: ok, those guitar lessons would be 80 USDTs
pacu: oh… that’s nearly .1 ZEC! (let’s dream a bit).
incoming.doze: nah, last time I used ZEC it tanked!
pacu: oh, those days are over but… ok… it’s your money. what’s your address?
incoming.doze: incoming.doze.eth
pacu: trades .1 ZEC into 80 USDT in NEAR, withdraws to incoming.doze.eth
incoming.doze: hey! I’m not seeing my USDT and it’s been a while.
pacu: oh…sorry, there’s a problem with my payment rail… sorry (uses another and pays 80 USDTs)

… an hour layer

incoming.doze: hey, I got 80 USDT more!
pacu: if you trade it for ZEC you can send me 0.09 ZEC :slight_smile: Welcome back to Zcash!
incoming.doze: ok, got me! my brother will love this, he’s a Hardcore Zebra

Thanks for clarifying.

Is Maya a trust based or trustless DEX?

If trust based, we should get going with a conversation regarding how we get a trustless DEX to support Zcash, because trust based is just a great stop gap between CEXs and trustless DEXs but it definitely should not end there.

afaik Maya is trustless DEX. anyone can confirm?

The opinion of Claude 4 Opus:

Based on the available information, Maya Protocol appears to operate with a distributed trust model rather than being fully trustless in the strictest blockchain sense.

Key Trust Considerations

Maya Protocol is described as a “decentralized, permissionless cross-chain swap system that relies on multiple key participants to function smoothly” . This architecture suggests:

  • Distributed trust: The protocol distributes trust across multiple participants rather than centralizing it
  • No single point of failure: As a decentralized system, it doesn’t rely on any single entity
  • Permissionless nature: Anyone can participate without requiring approval, which typically reduces trust requirements

Comparison with True Trustless Systems

Unlike explicitly “trustless” bridges (such as those in the Polkadot ecosystem like Hyperbridge and Snowbridge), Maya Protocol’s documentation doesn’t use the term “trustless.” Instead, it emphasizes:

  • Being “decentralized” and “secure”
  • Operating as an “entire blockchain protocol” where different DEXs can be built on top
  • Freeing users from “constraints of centralized exchanges”

Technical Architecture

The protocol’s reliance on “multiple key participants” suggests it likely uses:

  • A validator or node system that requires some degree of trust in the collective
  • Consensus mechanisms among these participants
  • Potentially a threshold security model where trust is distributed

While Maya Protocol significantly reduces trust requirements compared to centralized exchanges, it appears to operate more as a trust-minimized system rather than a fully trustless one. The need for “multiple key participants to function smoothly” indicates that users must trust in the collective behavior and security of these participants, even if no single participant can compromise the system.

2 Likes

Maybe you should have been more thoughtful when you picked your nym.

We can do better

… presumes our continued existence.

If your agenda of eliminating taddresses had succeeded, we would not have DEX support now.

I think it’s important for anyone who values DEX support to understand that.

It’s plausible this will kill zcash.

1 Like

What is dead may never die.

:wink:

Please try to be intellectually honest and stop trying to mislead people

Of course DEX support can be built for shielded only Zcash. Its just more difficult of an engineering job.

By paying devs to do the easy job instead (t-address support) we are harming Zcash by discouraging real progreal (shielded DEX support and usage).

The same concept applies to hardware wallets, etc. We would have had shielded hardware wallet support much sooner but for the self sabotage of paying for flawed (and not properly maintained) t-address hardware support.