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
10 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.
14 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.
15 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
17 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.
7 Likes
Yes, that’s right. best to have a heterogeneous system of connections to and from Zcash for robustness. More advantages too!
7 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.
16 Likes
What advantages will this have over the current Zcash implemention over on Solana? How is this different other than it’s on Avalanche?
Will it be possible to have privacy while operating on Avalanche or will it work in the same way as Zcash on Solana?… So it’ll be public, but give us access to AVAX DeFi?
2 Likes
Hi @Blazin8888 good questions. On Avalanche, there is a technology called eERC20–encrypted ERC20–that we are exploring bridging directly into, so that would mean that you could bridge direct from the Orchard shielded pool on Zcash to an encrypted token on Avalanche. There are still some challenges with this, however. One is that the tooling (wallet support, etc.) is not built out yet for eERC20, so there’s not yet too much you can do with those tokens on the Avalanche side. The other is that by default, eERC20 uses a different SNARK zero-knowledge proof system called Groth16. Groth16 requires a trusted setup, so it would be better to use Halo2, same as Orchard does. This change can be made, and we believe it should be made to provide the best privacy for Zcash and red·bridge users.
By the way, red·bridge is called an “Avalanche bridge” because it uses an Avalanche L1 to perform the bridging in a decentralized permissionless and open source manner–all good things! However, the ZEC.rbr token can be used across DeFi. More details on this soon!
6 Likes
So users would deposit their zcash into a shielded pool for eerc20 ZEC on Avalanche? This would work similarly to Railgun?
…very interesting and I agree would be ideal if it used Halo and was trustless.
1 Like
Very nice to see red·bridge featured in a write up from the Avalanche Foundation today! red·bridge, truly a joint community project of two important ecosystems!
cc: @ZCG
5 Likes
This has been a busy month for red·bridge!
On the Avalanche side, we have powered through adding full ICM (interchain messaging) to our custom L1, which now includes full support for Teleporter protocol which operates on top of ICM and creates a simple UX for developers to use. Until this point, Teleporter had only been supported for EVMs, not a custom VM such as our own. This means that the growing ecosystem of other Avalanche L1s will be able to easily communicate with ours without their developers having to learn anything more. We are meeting with Ava Labs (the software company that builds Avalanche) to do a code review on Tuesday.
Tamil and our social media host Benny created an explainer video showcasing Tamil’s recent work which we will release on Monday. We plan to make more videos like this one, at least one per month, to keep the community informed of our progress. I will post links to them here, and I will appear in some of them!
Next, Tamil took on another PoC project, sending instructions from our L1 to the Avalanche C-Chain to mint and burn tokens–a critical bridging activity. He finished this extremely quickly with the first draft done in under a day and polishing taking a few more days. 
We will make another explainer video about this accomplishment, and now he is moving onto transitioning a brand new Avalanche L1 from proof-of-authority (PoA) to proof-of-stake (PoS), secured with a test token. We will then take what we learn and apply it to ZavaX Oracle, the first L1 we ever created that is still going strong. These steps are necessary because red·bridge is to be a decentralized permissionless blockchain with its own staking token, RBR, and this is the path we will take.
Aratrika was also about to create an explainer video with Benny regarding her PoC for FROST, but ran into some problems due to the NU6.1 upgrade. We posted to Discord and got quick responses from ECC about the resolution that is in the works, and now we are just looking for a work-around so that we can do the demo and also keep building FROST-related PoCs. We will still create the video and just explain how the last step–actually signing a transaction–will work (and had been working) even if we can’t find a work-around.
Aratrika and Asmita also updated the red·bridge demo webapp to illustrate bridging to Ethereum as well as to Avalanche. With recent discussions (and after attending DevConnect in Argentina), we realized it was important to show clearly that red·bridge will be able to bridge ZEC.rbr to all of defi.
Next, Aratrika will look into how we are going to support FROST’s many-to-many communication requirements in a more efficient and robust way, possibly leveraging some Avalanchego code.
Our operations team and I have also been working on finishing the paperwork for our Swiss lawyers to form a legal entity that will be responsible for releasing the RBR staking token to the world. We are doing this in Switzerland because of its clear settled law regarding utility tokens for blockchains. More on this soon.
The unsung hero in all this is our project manager Mari who has been gradually taking over PM duties from me for red·bridge.
I’ve been busy working on fund-raising–honing our pitch deck with advisors, traveling to New York, taking part in online meetings, etc.–as it’s very necessary to grow as a company in order to compete in this much more economically exciting environment that we find ourselves in. For quite some time, we have been moving slowly due in part to cash constraints. Now, with the price of ZEC and attention on Zcash, it’s time to accelerate! This is a high quality problem indeed.
Onward!
cc: @ZCG
11 Likes
Here’s our first explainer video. Our software dev Tamil explains to noobie Benny (our social media host) his recent work. In it, Tamil gives Benny a demo of how messages can now be sent back and forth between the red·bridge custom Avalanche L1 and the Avalanche C-Chain. We plan do to more videos like this to keep the community informed. (Feel free to turn on subtitles if you’re not used to listening to the southern Indian accent by pressing the cc button.)
5 Likes
Hello! Here’s our January update for red·bridge. We continue to work on PoCs both on the FROST (Zcash) side and Avalanche side. In addition, we continue to ramp up our comms by posting more on social media, participating with ZSA debates on this forum, and creating explainer videos under the red·dev brand Benny Learns Blockchain.
Aratrika worked on a FROST PoC which she explains in this video. She uses FROST to create a minimum 2-of-3 signing scheme and then creates and submits a Zcash transaction on mainnet. Next, she is modularizing the PoC more so that we can test with larger signing sets.
Meanwhile, Tamil worked on converting an Avalanche L1 from proof-of-authority blockchain to proof-of-stake. He has made the conversion, so now the blockchain is secured with a token, and now he is figuring out how to remove the old proof-of-authority nodes cleanly and deploy on Avalanche mainnet (which requires hardware wallet signing).
I continue to work on fund-raising which, in my experience, always takes longer than you think it is going to! We have delayed forming the Swiss association for the time being, as there is no need for it to exist just yet, and there are ongoing administrative costs involved. That said, everything with that is ready to go!
5 Likes