ZavaX is good, simple and original
3 Likes
Hello Community! You’re overdue for an update from us. We are still working on Milestone 3, completion date estimate is soon, July 15. Apart from deliverables, I have spent the bulk of my time recently coalition-building around ZavaX. This is a tricky and time-consuming business, and I hope to have some results to report to you soon.
I’m going to work to do more frequent and shorter updates for the community here. We have a two-week sprint pace, so I will try to keep up with that.
At least two of us who have been working on ZavaX will be attending Z|ECC Summit in San Diego next week. We find these in-person events really helpful as we build. Also, for anyone in the New York City area or Northeast US who would like to meet, please reach out!
Re branding, two notes. One is that Avalanche has rebranded subnet as Avalanche L1. Personally, I like it better overall.
Re ZavaX thanks for your comments above. Based on them, we are sticking with ZavaX for the Zcash-Avalanche bridge. The Avalanche L1 on which it resides will be called red·bridge. This is based on feedback from the Avalanche community. (The red·bridge L1 may contain other bridges in the future.)
We can’t wait to complete Milestone 3 and move onto Milestone 4 in which we begin to put it all together!
17 Likes
Hello,
Today we are providing Deliverable 3.1, “A written analysis posted to the forum of whether or not FROST should replace BLS for threshold signature signing, and if so, a redesign of UML diagrams to reflect this change.” Analysis follows. This will also be our update for this sprint.
In our initial design, we had assumed that we would be using BLS threshold signatures in the ZavaX bridge on red·bridge design because BLS was already being used by Avalanchego, the Avalanche node software, and is also used by Ethereum. FROST was also being considered, as it was first brought to my attention as a viable solution by @nathan-at-least at Zcon4.
Since then, after analysis, we have decided to use FROST threshold signatures instead. We have decided to do so for three reasons:
-
We had been under the impression that because Avalanche used BLS signatures, it also used threshold BLS signatures. We assumed that audited libraries for threshold BLS signing, and signing group creation and maintenance, would already be available to us in Avalanchego. However, after showing the design to people deeply familiar with the Avalanchego codebase, I was informed that this assumption was incorrect. Avalanchego does support BLS, but it does not support threshold BLS. While it would be possible to implement threshold BLS from another codebase, it may not have been audited, and it would introduce another possible attack vector and complexity. Tight integration with Avalanchego was a major selling point for using threshold BLS, and with this not actually possible, other threshold signing options such as FROST looked more appealing.
-
The Zcash Foundation has created and supports audited FROST libraries specifically for use with Zcash transactions. In our consideration of FROST, we have found the Zcash-FROST development team from ZF extremely accessible and helpful to us. We are a small team, so having support around us as we build is crucial for the bridge’s success. Also, Zcash-FROST was written to integrate with bridges such as ZavaX. It has everything we need for decentralized signature generation and threshold signing. Also, like BLS, it is scalable for our needs, supporting one thousand signature groups easily.
-
We are funded by the Zcash community through @ZcashGrants, and as such, it makes sense for us to help strengthen Zcash software. The ZavaX bridge will be one of the first implementations of Zcash-FROST and as such can serve as a reference implementation for other projects. We hope this will help to expand the Zcash-FROST user base.
With the decision made to switch to FROST, we revised the ZavaX Bridge architectural documents, and you can find them here. Much thanks to @pacu (also funded by ZCG) for his invaluable help with these revisions. Also thanks to @conradoplg and @nsheep (on Discord) from ZF!
25 Likes
3 Likes
Exciting news, we have finished rebuilding the ZavaX Oracle platform so that it is much more robust and resilient. It now runs on eight hosts of three different types. Reconfigured, it’s much harder to attack. We are testing it now, and as soon as we are done, we will release the results here and on GitHub. We will also release the new architecture, a threat model, and some revisions to the codebase.
All this lays the groundwork needed to build a robust red·bridge as we will use all the lessons learned while building and improving this PoC platform. Can’t wait to get started on the coding!
(We are still making changes and bringing nodes up and down for testing, so you may experience some of this as you try the site.)
Kit
18 Likes
Today we could not be more excited to be shipping Deliverable 3.2 to the community and @ZcashGrants. With this delivery, we complete Milestone 3 for the project.
“Implementation of security best practices to protect ZavaX Oracle subnet, and a report posted to the forum describing our penetration tester’s attempt to stop the ZavaX Oracle subnet from operating.”
This was a cumbersome but necessary deliverable in preparation for deploying a bridge that is both secure and robust. We split the three node ZavaX Oracle network across eight different servers, each with its own role and its own layers of protection. We then performed penetration testing on all servers and adjusted their configuration accordingly until all tests passed. Please see these notes which describe the new platform configuration in detail, and please see this report for the results of our penetration testing.
In other news, we are transitioning away from the name ZavaX to red·bridge. We had wanted to retain ZavaX in addition to red·bridge, but this has proved to be confusing to just about everyone we’ve talked to about the project outside of the Zcash community. Launching a new product is challenging enough without added confusion. We are also changing the staking token ticker from ZAX to RBR. Amazingly, no project has ever used those three letters before!
So the last time you will see “ZavaX” used is with this ZavaX Oracle testnet. Thank you for your service, ZavaX! 
As Josh says, onwards!
Kit
19 Likes
Will this work similarly to how BTC.b does on Avalanche?
Yes. The big difference is that BTC.b is bridged by the authority given to to a small number of Bitcoin-Avalanche bridge wardens, while with red·bridge, up to 1,000 guardians reach consensus on bridging ZEC.z, and anyone with enough of the RBR staking token can become a red·bridge guardian.
1 Like
This is very interesting. 
i am starting to study Avalanche more… didn’t realize it was capable of all these things…
1 Like
red·bridge ! x.com
Please comment!
5 Likes
Posted in Global Discord + Telegram
Excited to use this some day, I hope progress is going well.
Could the foundations behind this project also support a wrapped AVAX ZSA on the Zcash blockchain once ZSAs are live, or would that require completely different code/validators?
3 Likes
The zavax-bridge implementation looks great, but what about migrating funds from old bridge address to new? You’d need old wardens to help since they have the shared key and some kind of enforcement so they don’t drop out.
Looking at zavax-bridge/Architecture/UML/Sequence/Maintain Wardens Sequence.png at main · red-dev-inc/zavax-bridge · GitHub this part is omitted.
2 Likes
In the next month we at red·dev will have a series of announcements.
The first one, which we are very excited to announce today, is that we have deployed a red·bridge Demo website so that everyone can try out the UX and let us know what you think and any changes you would like to see. The demo site is also a great way to introduce non-technical people to the project.
The code is published here on GitHub. We have written it with the absolute minimum of library dependencies for increased security and simplicity: HTML + JavaScript + CSS.
The bridge is designed with decentralization in mind, so as you are trying the demo, you will see a place to choose your Agent on the second page. The job of the agent is to escort your transaction across the bridge, and normally it won’t matter which one you choose, but it does protect bridge users from a possible point of centralization.
Also in the demo, you will note that the fee is a flat 0.01 ZEC per use. In the production version, this fee will actually be determined by and collected for the bridge guardians.
Please give it a try! And if you would be interested in helping us test the bridge and/or taking an active role in bridging operations, please get in touch with us. You can message me here.
cc: @ZCG
19 Likes
just a note on the color and accessibility?
isnt it just bit too much red? could the centre box maybe be white instead for better text readability?
2 Likes
Our branding is red, but we actually have in the works a
light mode - red mode - dark mode
switch so that users can pick for the experience they’d like.
7 Likes
Basic demo seems to work, running locally
127.0.0.1 - - [21/Feb/2025 18:01:17] “GET /transaction-status.html?send=10.0000%20ZEC&receive=9.9900%20ZEC.rbr HTTP/1.1” 304 -
4 Likes
5 Likes
Here’s an update about what we’ve been doing recently building red·bridge. We’ve updated our milestones based on the new support from Avalanche Foundation’s InfraBUIDL() program. They are:
- Demo Bridge with Functional UX
- Threat Model for ZavaX Oracle Revisions after Review
- ACP-77 Architecture Revisions
- ZCG Milestone 4 “Support for bridging ZEC to ZEC.rbr in both directions on testnets, with a one-validator Subnet, to C-Chain (assuming supported) or Subnet, and UX and UI design for GUI completed.”
- ZCG Milestone 5 “Fully functional deployment to Zcash and Avalanche testnets, with a 3-validator Subnet, with CLI support.”
- Threat Model for Bridge Reviewed
- ZCG Milestone 6 “GUI: bridge integration into Metamask, and publishing of the source code to a public Github repo.”
- First Audit (Least Authority)
- First Audit Fixes
- Second Audit (Halborn or other well-regarded auditor)
- Second Audit Fixes
- Incentivized Testnet (with RBR rewards)
We completed Demo Bridge with Functional UX a month back and even have some enhancements which we will announce soon. Next up are these three, which we are working on concurrently:
- Threat Model for ZavaX Oracle Revisions after Review
- ACP-77 Architecture Revisions
- ZCG Milestone 4 “Support for bridging ZEC to ZEC.rbr in both directions on testnets, with a one-validator Subnet, to C-Chain (assuming supported) or Subnet, and UX and UI design for GUI completed.”
For (1), we are in the middle of an audit of a threat model we have written up for our proof-of-concept ZavaX Oracle, a permissioned blockchain that runs on the Avalanche Fuji testnet. We have received initial feedback from Least Authority and are making a round of revisions to the threat model before asking them for more feedback.
For (2), we are working on these revisions. The biggest challenge is that Avalanche ACP-77 is so new that the documentation for it is not as thorough as one might wish. Also, the group of people who know the answers to our questions is small and stretched thin, so getting answers at times is slow and difficult. Once we get the answers we need, the actual changes should not be substantial, but it’s important that we do them exactly right.
For (3), we are working on building a PoC for using Avalanche’s ICM (inter-chain messaging protocol). Again, because we are working on brand new tech, we are facing similar challenges as with (2). For instance, Avalanche has created documentation on ICM, but it focuses on L1-to-L1 messaging where both L1s are running a fork of the EVM (Ethereum Virtual Machine). However, we are building an L1 with a custom VM, and the only documentation on messaging with custom VMs is very old and vague.
Our team has experience writing documentation for undocumented systems. Indeed, we won awards from Avalanche for helping to document an early version of L1s, called subnets. We will propose to AF to write some documentation as an additional milestone if no one else is going to do it. While this could push our schedule back a month, it is necessary to gather this information to proceed.
(3) is by far the most challenging milestone because our success is dependent on even more new tech. We have not even dug deep into FROST integration, for instance. It should work (and we’ve had excellent support from the FROST team) but FROST is brand new as well, and the devil is in the details.
Thanks for reading!
12 Likes
Four views from red·bridge: red, Dark, Light, and Zebra
Live now! https://redbridge-demo.red.dev/
Code: https://github.com/red-dev-inc/redbridge-demo
Please like and retweet on X: https://x.com/reddevinc/status/1912523430018039870
Please let us know how you like these too. We want red·bridge to feel like your bridge. We’ll be using this UX code in the final product, not just the demo.
9 Likes