Love it! My favorites are dark and zebra modes 
5 Likes
For the production version of red·bridge, we will be using Zebra. In preparation and for testing purposes, over the past week we have upgraded two out of the three nodes running ZavaX Oracle, our proof-of-concept blockchain for red·bridge. ZavaX Oracle is a small permissioned Avalanche subnet running on Avalanche’s Fuji testnet.
The upgrades went smoothly (well, pretty smoothly!), and we learned a few things along the way. Now we are ready to upgrade the third node, and that will require some downtime because of limited disk space on that server. ZavaX Oracle will be in maintenance mode until this upgrade is complete. We estimate 1-5 days depending on the amount of time it takes to completely sync Zebra. I’ll post again when it’s up and running again, this time with new Zebra installations on all nodes!
8 Likes
Great news, the upgrade of the third node went smoothly and was completed over the weekend, and now ZavaX Oracle is using ZEBRA!
Next up, we will be upgrading the ZavaX Oracle Subnet from an Avalanche Subnet to an Avalanche L1.
9 Likes
Ten days ago, I was on a panel at the Avalanche Summit in London, and I got a chance to talk about red·bridge. Here’s a sneak peak. The subject of the panel is about how to get funding, but I did get a chance to introduce red·bridge to about a hundred people in the Avalanche community. Afterwards, I was talking with a VC, and he said, “Oh! So you’re building something real!” I think we’re a bit of a breath of fresh air among all the meme coin pump-and-dumps!
Project update coming soon!
16 Likes
Today we are submitting milestone ACP-77 Architecture Revisions to the Avalanche Foundation. This might sound a bit dry 
, but it’s actually very very cool 
, and let me explain why.
The friendlier name for ACP-77 is Avalanche9000, and it is a huge upgrade for Avalanche that dramatically lowers the cost of anyone running a red·bridge guardian. Before Avalanche9000, you would have had to stake at least 2000 AVAX (about $44,000 today) to even run a validator. That’s because you used to have to validate the primary Avalanche network in order to validate another one like red·bridge. No more! To run a red·bridge node with Avalanche9000, it costs about 1 AVAX ($22 today) per month, plus you will need to obtain and stake RBR tokens. (And fear not, for anyone reading this post, we will have opportunities ahead for the Zcash community to obtain some RBR.) This puts bridge guardianship within the reach of a far wider group than would have been possible prior to Avalanche9000.
We have also wrapped into this milestone a solidification of our strategy using ZF’s FROST implementation. Huge thanks to @conradoplg for help as we made sure we understood everything just right. The bridge wallet will be a FROST wallet, and each Guardian will have a signing share, giving distributed control.
If you’re interested in digging into the UML documents and seeing the changes we’ve made, check out our repo. We have made changes throughout, but the bulk of the changes were made to the Maintain Guardians use case.
Thanks also to @ZCG and Avalanche Foundation for your ongoing support or the red·bridge project, to @pacu for your support, and to the entire red·dev team for your support with this milestone! So interesting and exciting for us to combine Avalanche and Zcash technologies together! Next up: establishing a good threat model for ZavaX Oracle, our early proof-of-concept, and building the bridge itself. Onward!
13 Likes
This past sprint we have made further revisions to the architecture documents:
- Additional refactoring for naming consistency.
- An adjustment to the ZEC.rbr → ZEC bridging use case regarding the burning and minting of ZEC.rbr.
- Enhancements to the documentation with two additional README files.
- Guardian payments for exiting guardian/validators after a one epoch (24 hour) cooling off period.
We continue to work on the threat model for ZavaX Oracle, and we are beginning to build proofs-of-concept projects for all critical technologies that are to be integrated together into red·bridge.
I am also excited to be joining the ECC team in Prague for the Z|ECC Summit in less than two weeks!
Onward!
cc: @ZCG
9 Likes
We have been busy this month building red·bridge.
I attended the Z|ECC Summit in Prague, strengthening relationships with this branch of the Zcash community, learning about how red·bridge might integrate best with Zashi, NEAR Intents, Zallet, and in the future, Tachyon. While in Europe, I also met up in person with our project manager Mari to refine and solidify our rocks, milestones, and overall timeline. Currently, I am finally circling back to the audit of the ZavaX Oracle threat model with Least Authority.
Since red·bridge is combining technologies, some very new, that have never been used together before, we think it prudent to take each tech and develop a small proof of concept project around each. We have a list of about ten of these.
The first one Tamil is working on concerns Inter-Chain Messaging (ICM, previously called “warp messaging”) delivery between Avalanche L1s. Ava Labs has already built some of the necessary infrastructure, but it is focused on their EVM virtual machine, SubnetEVM. However, we are building our own RedBridgeVM custom virtual machine, so we must extend their work, and that is what Tamil is doing now.
Meanwhile, Aratrika is working on doing a proof of concept around FROST. Since our software is written in Go, and Zcash FROST is written in Rust, she is implementing UniFFI to connect the two.
Also, Asmita is making some enhancements to the red·bridge UI, and Mari is taking over more of the project management from me. It’s exciting to see the pieces of the puzzle slowly fall into place. We will be publishing a new timeline here soon.
13 Likes
Hi, here’s a progress report on red·bridge. Both Tamil and Aratrika have made progress on their projects. Aratrika was able to fully reproduce the FROST demo and in the process reported one bug which was promptly fixed. She has successfully used golang with UniFFI to perform a DKG ceremony with three FROST nodes. She is now working on composing sending an Orchard-to-Orchard transaction.
Meanwhile, Tamil has set up two Avalanche L1s using Avalanche’s XSVM to exchange warp (ICM) messages with each other. It’s working well manually, and he has done a deep dive into how the code works, and now he is automating the process by adding a relay agent. XSVM will serve as a template for the redbridgeVM. In the end, it will communicate with the Avalanche C-chain, so this is Tamil’s next task.
I met last week with two auditors Least Authority to discuss the ZavaX Oracle threat model, and they gave us some recommendations for improvements which we are implementing over the next few weeks. Our goal is to have this deliverable complete this month. This threat model will then serve as a basis for a larger threat model for red·bridge itself.
I also have made a draft of a revised project timeline which I will share with the community here next week.
14 Likes
Hello, I would like to share our revised timeline for red·bridge. There’s some exciting alpha in here, foremost that we will be doing RBR token airdrops to the Zcash and Avalanche communities throughout Q1 and Q2 of 2026. We will also host an incentivized testnet where you will have a chance to earn RBR while helping to test out the bridge. Details will be shared at a later date but with plenty of notice, in time for the communities to participate.
The details of the timeline are shared here in a google sheet. There are a couple points worth noting. One is that ZCG M4 is a heavy lift, as it is actually the building of the bridge, and there are many pieces of the software that we have to fit together for it to work. Our strategy is to create proofs-of-concept for each piece of tech. On the PoCs for MS4 tab, you will see 19 of them listed, and we will keep this updated as we complete them. Milestones M5 and M6 are by contrast much lighter.
Another point is that we will activate the red·bridge L1 live on the Avalanche mainnet in December 2025. Initially, it will serve as an oracle for the Zcash blockchain and then, soon after, for Bitcoin as well. Each request will cost 0.001 AVAX. This will allow any L1 or smart contract on Avalanche to inexpensively query data from Zcash and Bitcoin in a decentralized manner. As a fully in-production blockchain, it will help to build community confidence in the stability and robustness of the L1 before it begins to perform the higher-stakes use case of bridging. We will then add bridging once it is ready, in Q2 2026.
As all this progresses, red·dev, based in Wyoming, USA, will serve as lead software provider for the decentralized red·bridge network. However, the RBR tokens will be issued out of a new Swiss entity, a verein (or association), that is being formed now. More on this later as well!
This has not been an easy project, but we are fully in builder mode and are actually really enjoying the technical challenges. It’s super exciting and an honor to be adding to the robustness of the Zcash ecosystem along with a growing number of other projects.
cc: @ZCG
16 Likes
I have been waiting for this for so long. Excited.
Basically it means Zcash is not just dependent on NEAR intents for easy swaps too.
6 Likes
Yes, that’s right. best to have a heterogeneous system of connections to and from Zcash for robustness. More advantages too!
6 Likes
I have some great news to share. We’ve completed two critical deliverables for red·bridge, two proofs-of-concept, necessary building blocks for the bridge.
First, Aratrika has successfully completed a FROST DKG (distributed key generation) demo using a two-of-three signing scheme and has then successfully generated a signature for a Zcash note and sent funds on mainnet. We will build on these same principals to enable bridge guardians to jointly generate keys, once per epoch, and disburse funds from the bridge escrow wallet, once per Avalanche → Zcash bridging transaction. This is especially exciting as I believe we are the first team to implement ZF’s FROST libraries.
Second, Tamil, working on the Avalanche side, has enabled ICM (inter-chain messaging) between a custom VM (virtual machine) and Avalanche’s C Chain, its main chain. This was especially challenging because no one had yet written a relay agent that would work with a custom VM.
Tamil, Aratrika and I have won hackathons together, so it was no surprise to me that our team was able to get through these tasks, but at the same time, both were difficult, working with the “bleeding edge” of software in both the Zcash and Avalanche ecosystems.
Shout-out as usual to @pacu for his weekly guidance along the way.
Up next, both Tamil and Aratrika will iterate on these PoCs, in both cases increasing the use-case complexity, and then they will move onto the next set of PoCs.
As for me, I wear both the CTO and CEO hat for red·bridge, and due to the recent increased interest in Zcash and privacy in general, I have put on my CEO hat and have focused almost exclusively on fund-raising, making hay while the sun shines. This has delayed my CTO deliverable for a threat model audit. I do have a CTO in mind to hire once we are funded who will be just extraordinary, and I just can’t wait to bring them onboard and wear just one hat.
I’m at Ethereum’s Devconnect in Buenos Aires now. There’s a nice group of Zcashers here, and I am about to go track down the Avalanche booth as well. Perhaps I’ll make some introductions! Thanks as always to @ZCG for your continued support of this important project that will offer Zcashers a robust, open source, and decentralized way to move ZEC and ZSAs across the crypto world.
13 Likes