Z|ECC Summit Cancún 2025 - Day 2 - until the candles burn out

You are reading day two, the third entry of this series of chronicles on Z|ECC summit. You can catch up on the previous entry here.

All of the quotes are unattributed due to the nature of the Chattham House rules that were agreed upon by all the attendees to the summit. #PrivacyIsNormal

Rise and shine

My day starts early in the morning. It’s still night and the sun has not risen yet. Although air conditioning feels like a lifeline, it’s winter in this part of the planet. I head out to the gym again. My dear young colleagues, this profession is very tough on your physical and mental health. Be mindful of your wellness, you don’t want to be blowing a gasket. In my head I’m going over my presentation and I figure I have things to improve here and there. So at breakfast I pull out my tablet and start moving things around.

The resort didn’t have many places for breakfast and people were not arriving, it seemed that Zcashers stayed up “hasta que las velas no ardan”. Some pale faces started to mingle around the buffet. I somewhat felt like the old neighbor sweeping the front yard early while watched the youth going to bed at sunrise and saying “calavera no chilla” which is the Spanish way to mock someone who’s had a great night and a terrible morning LOL.

Str4d was the facilitator of this talk where the ECC core team would announce a correction of the NU7 schedule (in their PoV).

According to them there are quite two sets of things to include in NU7: key capabilities and timely convenient items for future features. It is also the first time we have this many organizations pushing for features to be included into the protocol: ECC, ZF, QEDIT and Shielded Labs.

New transaction format

The V6 transaction format is the critical item (ZIP-230) which is being owned by ECC and ZF but all four entities are proposing changes that affect the current transaction format (V5). Changing the way a transaction is formatted is one of the most traumatic changes for a blockchain ecosystem. It affects every single application and clients, regardless of them being a full-node or a small mobile app. If the application does not recognize the new format, it will break. That’s why a huge ecosystem outreach has to be carried out every single time there is a change in the format regardless of how small it is.

That’s why it’s preferable to do all changes at once even though they might not be needed right away. Application might choose to ignore some fields of a transaction, but they can’t ignore what they can comprehend.

Zcash Shielded Assets

Q-EDIT is pushing for ZSAs to be included in NU7 with great support from the community. Shielded assets (ZIPs 226 and 227) enable the issuance, transfer and burn of custom assets on the Orchard pool. If you want to know more about ZSAs you can watch this demo from QEDIT. Unfortunately no one from QEDIT was present at the summit to argue on their behalf.

Memo Bundles

Another feature that is a candidate to go into NU7 is Memo Bundles. ECC is proposing that memos can be bundled up to 16Kib. This allows users to create larger memos with more information. One weakness of the current memo approach is that users can’t authenticate. Meaning that they can’t add information that will enable the recipient to verify that the memo is coming from a trusted source. To make memos useful, it is necessary to make applications react to their content. But you don’t want your application to react to any memo sent to an address watched by a viewing key just because. You need to know that the sender of the memo is legit. We need to be able to sign a memo or provide proof that we can verify. For this, the size of memos needs to grow. Another proposal of memo bundles is that many recipients can decrypt the same memo bundle, saving chain space and also to allow clients to prune memo chunks from transactions so that clients can disregard the additional data if they don’t need it.

Network Sustainability Mechanism

Shielded Labs has been in charge of Research and Development of a Network Sustainability Mechanism (ZIPs, 233, 234 and 235). In a nutshell what they propose is that there can be an “anti-issuance” mechanism that can remove ZEC from circulation. This was originally called “burning” but ZIP editors requested Shielded Labs to come up with a different terminology since burning is commonly used as a way of removing assets from circulation forever and they intended to do something that is temporary. NSM entails a couple of alterations to the current state of the protocol that are not trivial. Beside the removal of ZEC from circulation, they propose that such ZEC can be reinstated lated, which modifies the issuance curve that historically mimics the one designed by Satoshi. They require that part of the fees are moved to the NSM by removing them from circulation and also they mean to provide a mechanism for voluntarily removing ZEC from circulation into the NSM fund. This items of the NU7 proposal were the most debated.

“These ZIPs shouldn’t be included now” a big consensus around the room. Unfortunately no members of Shielded Labs had attended the summit this time. But there were more benevolent views as well proposing that ZIP-234 that smooths the issuance curve can be safely implemented because it only kicks in two years from now and its effects can be evaluated more carefully as time goes on.

It is important to note that “The fact that a feature has been developed does not mean that it needs to be included in the protocol”. And ZIP editors apply this criterion regardless of who's proposing and/or developing the feature.

Explicit Fees (ZIP-2002)

This ZIP is being pushed forward by ECC/ZF which basically consists of adding the notion that transaction creation implies that all the fees are explicitly specified in a fee field. Originally Bitcoin fees were determined by the remainder of inputs and outputs. This is somehow what was modelled by the Zcash protocol. The problem that this brings is that to know the fee of a transaction you have to download it fully. The Zcash compact block protocol that powers mobile apps that have skyrocketed the sapling and orchard pools to their ATHs do need to have clear fees displayed to their users but certainly would benefit from not downloading all their TXs. Compact Transactions as detailed in ZIP-307 are 90% “lighter” than their full-node versions. ZIP-2002 helps keep light clients (like mobile wallets) that way by not needing to download all that data just to know a decimal number.

Disable V4 transactions (ZIP-2003)

This has brought controversy given that this would also disable the ability of transacting Sprout funds out of that pool. It’s not that the funds will be lost. The funds would be “locked as in lockbox”. In general the room was in accordance with the technical approach given that Sprout has been carefully signal as a deprecated pool. Also, unlike Sapling, Sprout was only available in full-nodes using a CLI wallet over the terminal. Someone put it in a blatantly honest way: there are no confused grannies holding Sprout funds.

“I’m in favor of 2003 but I don’t know if we can make it in time with governance by NU7”

It is important to note that on Keystone Launch day 100,000 ZEC moved to the Orchard pool from transparent. Also, since possible Sprout lock was announced a thousand ZEC moved out from the Sprout pool.

“We’ve always said that it was not possible to maintain all pools and the complexity of the protocol it entails.”

Technically speaking, Sprout is a burden. It is also an attack surface since the pool is the one that has the flaw that inspired Sapling. So it is certainly positive to continue all the logical steps needed to deprecate Sprout. It will have to be admitted that many funds within the Sprout pool are probably lost as well. It won’t be the case that the Sprout pool value count will be Zero.

WHEN NU7?

If you’ve been following Zcashd Deprecation Updates you are probably familiar with these timelines.

“Keystone has delayed (ECC’s) NU7 changes for two months but we believe it was the right decision”

What needs to be done?

There is still a list of things that need to happen before NU7 can be activated and it’s not short

• Deprecate/Disable Zcashd RPCs
• MVP of full-node CLI (Zallet)
• Get Zallet talking to Zaino
• A test version of the Zcash stack that can be shipped to different partners for integration testing purposes and detailed hands-on feedback

“We are going to need a Zcash stack infrastructure that includes Zebra, Zaino and Zallet. We need Yasser and Emersonian to work on this”
A positive note is that many things that Zallet needs are already implemented for Zashi.

And then what? Possibilities for NU8

It was speculated that NU8 would be rather simple just being comprised of ZSA Extension for Asset swaps and some of the proposals that ended up omitted from NU7 and any fixes that are needed.

The funding question

The lockbox mechanism will end in November 2025. This means that with NU7 slipping by two months there won’t be enough time to deploy a subsequent NU for at least 3 months after the seventh upgrade lands. This is from experience of past upgrades, it take at least 90-days to carry out a successful ecosystem outreach which is the foundation for a successful upgrade.

Some alternatives are being explored such as:

• Doing nothing, let the lockbox + ZCG funding expire and give 100% of coinbase to miners
• Propose a 6.5 upgrade that extends the current funding stream or a full 20% lockbox before NU7

Josh and Daira-Emma from ECC posted in the forums that ECC is working on the zBloc ZIP.

But let’s go back and talk about the current proposals that have been presented.

Loan Directed Retroactive Grants

Proposed by Kris Nuttycombe from ECC, the LDRG is a mechanism that can be performed mostly off-chain where a group proposes a grant and this group must “raise capital” within the Zec holders that funds the work proposal. When the proposal is delivered, the group gets retroactive funding from a disbursement mechanism to pay back its investors.

“The LDRG can be developed with a LDRG as compilers are built” (note: the C compiler is built with C)

“People with deep pockets can influence the protocol” (this can be positive or negative depending on who the listener is but it was expressed as a negative aspect)

Zbloc

The Z funding bloc or Zbloc proposal has been posted long ago by Josh Swihart. It expressed as a mechanism for a group of people to determine what Zcash is (as opposed to the trademark agreement that Zooko and Dodger signed as leaders of ECC and ZF). This group of k of n people that approve governance decisions and funding can change in time where removal of members requires a supermajority. Initially ZCG, Zechub, coin holders and core engineers are some of the actors proposed for the Zblock k-of-n governance but additional orgs could be voted in. The goal of Zbloc is to give the community a voice and avoid a plutocracy.

Finding our normies

Blake from zec.rocks presented some ideas to find out dear normies and bring them into Zcash.
He confronted the room with a hard fact: there is no Zcash success story. We are not making money. And that is pretty important for an internet cash project.

Bitcoin had Silk Road, cash app, exchanges; Ethereum has MakerDAO, Uniswap, standwithcrypto; but what about Zcash? What is our success story? Not sure.

Blake proposed an idea to Build with profits, not with grants. Which is quite powerful and necessary. From his point of view It’s too hard to buy things with ZEC. Zcash needs to focus on first time users and be generous with them.

Details of his proposal have been omitted but you should be paying attention to Blake! Trust me, it’s awesome.

Zashi design workshop

The product team unveiled an all-new Zashi design that prepares the field for what swaps and payments will look like within the app. The user interface we saw included a redesigned home screen and asset swap mock-ups. Andrea presented the room with two different workflows for us to play with and provide feedback through a Figma prototype.

Although it was not all bed and roses. There was a coin list menu in one of the swap flows which infuriated part of the room, since some of these coins had vicious communities towards ZEC itself or communities that are part of it. But then a brutal fact was dropped “More stores accept Doge -a meme coin- than ZEC”. Silence. Followed by thoughtful advice: “ECC should use Swapkit and not waste time implementing their own solution. They should be making sure that Swapkit is implementing ZEC right”.

“Meme coins are powerful”
“The first ZSA should be a memecoin”
“What if we find alignment with the Pepe community?”

I was somewhat pleased to see that the ECC team was not reinventing the wheel and using known patterns from the DeFi ecosystem instead and that the workshop focused on Zashi integrating such workflow. I’m eagerly waiting for these features to land.

ZSA workshop

Daira-Emma and Str4d lead this workshop on Zcash Shielded Assets. A ZSA is an ASSET_ID which is a unique identifier on the entire Zcash Orchard pool. This asset identifier is tied to an issuance key (ik) and an asset description. The actor holding an issuance key, is identified as the issuer of a certain asset.

The problem: A description does not need to be unique. So, the asset_id “abed1” can be described as “zBTC”, but so does the asset_ID “beef2”. Which one is the “real” zBTC?. Moreover, anyone can be an issuer.

How opinionated can we be about an issuer? Ultimately it’s people who will have to trust the proof that the issuer is presenting on the liquidity of the “unwrapped” version of a certain asset. This is somehow an existing problem in all swap ecosystems. Maya can play an interesting role here with their LPs.

But there’s an additional problem. Issuance key (Treasury) holding. This is not a trivial issue. Very promising projects like Ren Protocol took huge reputational hits due to flawed treasury key holding designs. So, there has to be some sort of “reputational score” system for ZSA issuers. But that comes with its own daemons as well. “Credit Scores” are one of the instruments of TradFi to achieve financial segregation.

Innovation brings new solutions, but also new problems. How can we have a healthy ZSA ecosystem and at the same time avoid summoning the demons we originally wanted to fight”?

On ZSAs, Shielded Memes and NFTs

There’s one thing that the community must be aware of. As they are designed and implemented at the moment, ZSAs are not meant to support NFTs they may know them. Collections, rarities, attributes, etc. don’t have a place in the current design. Even though the asset description field can hold a kilobyte data (that’s 1024 characters, or two ZIP-302 memos) that wouldn’t be enough to describe a set of NFTs. ZSAs are designed to be fungible, so in order to create a non-fungible asset, a new asset_id would have to be created with a total supply of a single unit. NFTs will take additional work. Some of those features could be worked around at the application level and operating over “convention”. Otherwise additional specifications will have to be created, implemented and deployed into the protocol in order to have NFTs as you know them.

Memecoins on the other hand, are fully supported by ZSAs. Transacting an asset will be no different than transacting ZEC. Ultimately, wallets like Zashi will be similar to solflare, phantom or Trust wallet (on ETH, SOL or TRC). A single Orchard address will be able to receive and send many asset types.

Innovation but to some extent

The wallet team was pretty motivated by the talk but there was some “woa woa woa… hold on” moments where the community folks were just saying “just copy the wallet patterns that are present in the rest of the DeFi chains and don’t think about it twice”. In fact, we have two great multi-coin wallets that are Zcash allies: Edge and Unstoppable. We should learn from them and think about how ZSA would fit into their UX. Moreover not only in terms of usability, but code as well. I did the first PoC of Zcash in Unstoppable wallet in a matter of a day of work. That was not my merit, it was Unstoppable’s. They are the ones that created a project with a structure that allowed someone -with quite some expertise- to actually contribute something meaningful in a matter of hours. I think we should learn from them and that’s something I talked about in my presentation.

Don’t make NU5 mistakes in NU7

There is no debate on whether Zcashers want ZSAs or not. It’s a tautology that they do. The real question is whether it is easy to use ZSAs or not. Taylor Hornby proposed something to measure ZSA usability and as usual he was spot on. I may add that it would be a complete missed opportunity if NU7 is not activated with full support in most wallets and at least two or three assets that can be issued within the next 24 to 72 hours from launch. We need to get this right from every possible angle. Development, Marketing, Usability, narrative, you name it. Otherwise, Zcash will continue to be the “Thanks for building all of this we are profiting from elsewhere” coin and we will wave the Zk bullmarket train as it passes by.

State of Developer community

I did a 15 minute pitch about this which will have its own article! Stay Tuned.

RedBridge: Bridging Zcash to the DeFi world and back

Kit from RedDev has been a long time supporter of Zcash and Avalanche. Two blockchain projects that are very different but somewhat similar. They are very keen on innovating. Zcash is heading towards a multi-asset privacy decentralized financial system with ZSAs. Avalanche has recently launched their 9000 ecosystem which turns Avalanche into a Blockchain of Blockchains which could potentially for example run a native Orchard L1.

The RedBridge, formerly known as ZavaX bridge, will connect Zcash to Avalanche allowing bridging ZEC into ZEC.z and vice versa. Connecting ZEC to Avalanche’s DeFI ecosystem and AVAX to Zcash’s anonymity set, privacy and selective disclosure.

With the advent of ZSAs the possibilities expand even more. Because ZSAs will be able to have their Avalanche equivalent. Additionally zAVAX could become a ZSA the same way the RedBridge will mint ZEC.z on the Avalanche side.

We will revisit Kit’s presentation in a follow-up article. In the meantime, follow Kit on X for more news on Avalanche and Zcash integration.

A case for ZSA Summit.

There were a handful of important crypto events that were located near me over the last year. Some of them I could attend, others unfortunately I didn’t have time for. What I could appreciate about the Avalanche Summit, ZkLATAM and the Crecimiento Pop-Up city is that there’s no workaround for in-person rapport. We must face it. We must crawl out from our (eco) chambers. Look for investors, sponsors and associates to shake this numb feeling out of our ecosystem. If we aren’t capable of organizing a Shielded Assets Summit to show the world how awesome ZSAs are, then how do we think we would be able to get investors to provide liquidity for ZSAs to exist?

This is a call to action to all the community, ECC, FPF, Shielded Labs, QEDIT, ZCG and ZF to work together to organize a ZSA launch we can all be proud of.

Onwards.