Given the track record of cross-chain bridges being prime targets for high-value attacks, it would be helpful to understand the security model in more detail. For instance, what validation mechanisms, auditing processes, or trusted execution approaches are you considering, and do you have experience working with secure enclave technologies or similar environments?
Great questions, and you’re absolutely right, bridges are prime targets @operational-anxiety4.
You can find a detailed exploration of the red·bridge archictecture here. The tl;dr is that it operates as an L1 and thus uses the same security model as a proof-of-stake blockchain. Validators called Guardians stake the RBR token and then vote to approve or deny bridge transactions. Unlike most other L1s, the threshold for approval is higher, set at 80%. We initially explored using SGX secure enclaves, as are used by the Avalanche-Bitcoin bridge, but we decided against this early-on given SGX side-channel attacks and because a functioning blockchain provides inherent security. Another concern we have is about early token-price volatility degrading bridge security, and to counter this, we plan on putting enough tokens in the hands of Zcash-aligned parties and community members so that together they have the power to halt the bridge in an emergency.
The bridge virtual machine software will undergo at least two audits by reputable audit firms, and we will also produce a threat model for red·bridge under the guidance of Least Authority. (See above for a link to our previous threat model work on ZavaX Oracle, a proof-of-concept for red·bridge.)
I hope this answers your questions, and thanks for asking about this issue that should keep every bridge designer up at night!
We have some updates to share, including a new episode of Benny Learns Blockchain in which Benny interviews red·dev’s Aratrika Mukherjee about her accomplishments creating a more complex testing environment for FROST threshold signing.
This video is actually a few weeks old, and more recently @aratrika_am has moved on to working with ChainSafe devs (tagging @Wollum-ChainSafe) on using their Metamask Zcash snap to help users authorize red·bridge transactions. Based on her findings, we have had to make a small design change to red·bridge, and Aratrika is now updating our UML diagrams. Without getting too technical, even though the Zcash snap can sign transactions using the same private key as Metamask, it actually does so connected to a different derived address than Metamask provides to the user for Ethereum and Avalanche transactions, so red·bridge has to hop the bridged funds over one more hop in order for the bridge user to gain easy access to their bridged funds. We’ve figured out how this can mostly be hidden from the user so that they still get a nice clean UX experience.
Meanwhile, @tamil-reddev has continued to work closely with Ava Labs dev rel engineers to convert a PoA L1 to PoS with a staking token. I feel we’re in the home stretch now. Ava Labs has had to change a few things on their end to get it to work with our custom L1, and also we’ve had our own learning curve.
Last week, @pacu and I met with two auditors from Least Authority (in a meeting funded by @ZCG) to review our latest draft of the ZavaX Oracle Threat Model. It was such a helpful meeting, and I can’t recommend Least Authority highly enough as a top-notch auditing firm. Their two auditor/engineers had excellent recommendations for us.
This is our second meeting with these two auditors, and after the first meeting, they provided us with a number of suggested changes to improve our threat model. Then I, integrating the helpful advice of Pacu, Tamil, and Aratrika, made these revisions, expanding the document’s length by at least 33%. The LA auditors liked how we had implemented their previous recommendations, and they also had more recommendations for us about the new content that we have added. We will be able to share their report soon.
Most likely, we will implement a few of their “low-haning fruit” recommendations for this threat model, but our actual end-goal here is to create a top-notch threat model for red·bridge itself, so instead of continuing with the ZavaX Oracle threat model, we will probably shift gears and use what we have learned to write a threat model for the actual bridge and then again review it with LA.
I’ve also been working hard on tokenomics and token distribution (as you can see in my reply above), especially in how these matters relate to bridge security. More on this soon. Also we have been corresponding with accountants and lawyers in Switzerland for the formation of the RBR Association which will launch the RBR token. I’ve also been thinking about how NEAR Intents and red·bridge compliment each other in some surprising ways that together make the Zcash ecosystem stronger. I will be posting about this soon.
Oh, I also had the most interesting conversation with the CEO of Landslide Network yesterday. They have built an IBC bridge, and we were discussing how we might join forces to integrate Landslide and red·bridge. I share this not because anything is imminant, but just to give you a taste of the excitement we have about the possibilities ahead, one of many.
Hello @ZCG. We would like to request a milestone adjustment to our grant. We would like to adjust Milestone 4.1 so that it matches up with the Avalanche Foundation InfraBUIDL() milestone that was just completed. Our grant to AF describing this milestone reads:
We have created a threat model document for our prototype L1, ZavaX Oracle, using Invariant-Centric Threat Modeling principles. We will ask ZCG to authorize and pay for a review of this document by Least Authority, a well-regarded code auditing firm (that has audited AvalancheGo). After receiving their feedback, we will implement their recommendations which would satisfy this milestone.
(The “feedback” mentioned is the LA report from December 30, 2024, and we implemented their recommendations in the months prior to our most recent meeting on March 25. See zavax-oracle/security/Least Authority - ZavaX Oracle Threat Model Review Notes.pdf at main · red-dev-inc/zavax-oracle · GitHub and https://github.com/red-dev-inc/zavax-oracle/blob/main/security/threat-model.md.)
If you agree to this change, this would mean that what’s now Milestone 4.1 would not exist anymore, but we think that would be OK because there is only a tiny difference between our delivering 5.1 and 4.1 (running the test platform with three validators instead of just one validator), and we already completed 4.2 on April 15, 2025, “UX and UI design for GUI completed.” See https://redbridge-demo.red.dev and GitHub - red-dev-inc/redbridge-demo · GitHub which is the exact GUI design and code that the bridge will use.
Thank you for your consideration.
This adjustment has been approved by ZCG. Thanks @mrkit2u!
Thank you for requesting your milestone 4 payout.
We just sent you 86.28 ZEC at $328.5 USD/ZEC for a total of $28,343 USD.
TXID: f8816dec35844dc9817c50baf9b3e1b57057c4f1aa3a7c990c2cb94f16a6eb84
Hello! This past month has been a big one for red·bridge, with an announcement coming early next week. On the development side, Tamil has created a proof-of-stake testnet using a custom oracle VM. In the process, we ran into a few more rough edges in the L1 creation process which we resolved with Ava Labs dev rel.
Aratrika meanwhile dove into the Zcash Metamask snap and webz.js project codebase, as it is critical for our bridge. In the process, we found two problems that we will fix and one additional feature that we will add. More on this next month! Aratrika also updated our UML diagrams to reflect our findings regarding how the snap works.
Oswaldo has been setting up dev ops systems to monitor node health and has been taking the Avalanche Academy online course.
I have been working on numerous legal challenges involved with launching this special-purpose blockchain as well as on business development.
Onwards!
Hello! As most of you already know from this thread, we are about to launch red·bridge! We’re very excited to have the participation of Shielded Labs, ZecHub, Zcash Brasil, and more as Zcash-aligned organizations who will be running a red·bridge guardian-validator node. In addition, numerous individuals have contacted us through the Zcash Global Discord server about running a node, and we will have a program set up for you soon. Stay tuned!
Our initial funding from ZCG was for building the bridging software, and we are nearing its completion. Now it’s time to launch, so new funding is required. We have about seven months of deliverables to complete in order to get the bridge to full functionality with revenue-generating ability. In addition, as you may know, we have launched a Swiss Verein called RBR Association in order to issue the RBR staking token and oversee the bridge, and still ahead on our financial ledger are related legal and compliance expenses. Finally, we are not approaching red·bridge as a “build it and they will cross” bridge. Like every other product, we have a go-to-market strategy to execute.
We have combined these elements into a new red·bridge launch grant request from ZCG. I believe we’re being about as frugal as possible with our request, having carefully budgeted what is necessary for the launch of a new special-purpose blockchain. As a bonus, we are offering to take on maintenance of a fork of the Webzjs and MetaMask Snap codebase. This software enables easy website integration with a Zcash wallet, and it is mission-critical for red·bridge operations, so it’s a good fit for us to maintain it. We have already addressed some important issues and will continue to do so as Zcash moves forward through NU 6.3, NU 7, and beyond.
Questions and comments are welcome. Onwards!
Oh good, no problem. It’s a good point about bridge security being dependent on the value of the token (now called RBR), which creates a bootstrapping problem when the token price is low or volitile. That’s one reason why we have recruited Zcash-aligned orgs as the first bridge node operators, as they will have a self-interest in the integrity of the bridge above-and-beyond the price of RBR. Then, as the price stabilizes, RBR will gradually become more dispersed and the bridge increasingly decentralized.
We made a list of well-known organizations to begin and asked them. A couple other orgs have messaged me initially but have not followed up yet. Individuals can run nodes as well, and we will be providing information on this soon. If you’re interested, please send me a DM and also join the Zcash Global Discord Server as that is where we will be doing support.
@mrkit2u ZCG has voted async to approve this proposal. Congratulations!
To keep the community informed, ZCG requests that you provide monthly updates via the forum in this thread.
Please check your forum inbox for a direct message from FPF with important next steps, including a link to the Milestone Payment Request Form and your unique validation code for submitting payment requests.
This is amazing! Thank you so much!!! @ZCG
@ZCG we are indeed honored. We are in an online co-working meeting right now as this good new arrived, and we did the famous Latin American toast together: “arriba, abajo, al centro, pa dentro!” with our various non-alcoholic morning beverages. ![]()
Thank you.
We will do our very best to continue to be good stewards of the Zcash community’s hard-earned money.
Onwards!
