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?
1 Like
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!
2 Likes
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.
10 Likes
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!
1 Like
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