Hi Moonwell Community,
I just created a snapshot proposal to kickstart the discussion about the community’s preferred bridging strategy for Moonwell Artemis. Three bridges are evaluated on the basis of security, financial coverage, and user experience.
Hi Moonwell community,
Thanks @nikodem for proposing this; especially vital for us to discuss as a community the best path forward for Moonbeam’s bridging infrastructure.
Quick intro: We’re the team at StellaSwap, the leading DEX on Moonbeam. Made up of DeFi natives who previously co-founded one of the first regulated cryptocurrency exchange in the Middle East. Fast forward to now, we’ve been working with numerous projects across the space to spearhead the growth of Moonbeam ecosystem.
StellaSwap (and Moonwell) was at ground zero for Nomad’s exploit, which meant that we were at the forefront of managing our community, discussing with the relevant stakeholders (internally and externally) as well as spearheading efforts for the finalization of a resolution plan from Nomad. Beyond what transpired, the most important takeaway throughout this entire journey was the conceptualization of a robust + comprehensive bridging framework to ensure that we can substantially mitigate against risk vectors associated with bridging. In order to actualize that, StellaSwap team had to perform deep due diligence qne work with various stakeholders (including the amazing Moonwell team) to solicit feedback + discuss variables that would be vital to look out for.
That has enabled us to create a framework for evaluating bridges on Moonbeam, which can be seen here: Rebuilding Strategy: A Framework for Evaluating Bridges on Moonbeam | by StellaSwap | Sep, 2022 | Medium . We implore everyone to have a read on the parameters that should be considered when deciding a bridge. We appreciate your feedback, support and participation in arriving at a consensus for rebuilding the ecosystem.
Thank you for this excellent proposal. I’m looking forward to a lively discussion about the merits of each bridge. I think they are all very strong:
I think all 3 are excellent choices, so I’m eager to hear what the community thinks as well.
Hi Niko,
really appreciate you putting up this proposal and considering Wormhole as a bridge choice.
It’s great to see the priorities you and StellaSwap outlined for your bridge choice align with the priorities of the Wormhole contributors and there really isn’t much I could add to your side-by-side comparison.
One important thing to note on the Connectivity side is that the Portal token bridge on Wormhole supports any standard compliant fungible token on any of the connected ecosystems and not just 113 assets. Portal automatically adds support for new tokens when they are transferred via the UI for the first time.
We understand that this is a super important decision for the community so if there are any questions on Wormhole by either you or the community we’ll make sure to answer them here or on the Wormhole Discord.
Hendrik
- Wormhole Contributor
Hey all, Alexei from Interlay here.
This vote here is a quite important one - it will determine the main bridge being used by the majority of AMMs on Moonbeam. Sharing my 2 cents, having spent quite some years working on and researching bridge designs (was my PhD topic).
Note: this post is not a “dunk” on any of the bridges. The teams have done great work to deliver. Rather, this post is neutral summary, explaining how they work
First and foremost: we all want a fully decentralized Ethereum bridge. However, this currently does exists. Snowbridge (snowbridge snowfork com) is being actively developed, but there are some dependencies on Beefy light client improvements before it can go to production. Last I heard - we’re looking at 2023.
Now, looking at the candidates: all 3 bridges are reputable. Wormhole and Multichain are well known in the space, showing large volumes of bridged assets. Both have already been hacked but have survived and are still operational. Axelar is fairly new and cannot (yet) boast with TVL, but also has not been hacked (though could be due to it being “young”).
All bridges have risks - we all know that. I think it is important to keep in mind: none of the 3 candidates
are as “decentralized & trustless” as a light-client to light-client bridge like Snowbridge would be (alas, the latter is very hard to build). This does not mean they will be exploited, however: code bugs can happen even in the most decentralized systems.
All 3 are similar at the core - even if their implementations differ.
For those who want to read more: a decent summary was provided by Jump - despite being a big backer of Wormhole, the report is fairly neutral: Jump Crypto - Security Stack-Up: How Bridges Compare | Jump Crypto
If you want to go really “deep”, you can check out our scientific work on bridge security and designs: https://eprint.iacr.org/2019/1128.pd (albeit, it does not explicitly mention the 3 bridges as it was published a while ago).
So, which one would I vote for?
Honestly, I do not know. They are all interesting and good candidates and we (Interlay) look forward to working with all of them. And as we have seen, hacks can happen to anyone.
Ultimately, the decision here is: “Which team do we trust most not to have a bug in their code?”. This is where the security devs among us should speak up - or anyone who has perhaps looked at the code and can share insights (for, I have not and hence cannot comment on this part).
I would even go so far as to suggest: even if initially the focus will be on 1 bridge to avoid liquidity fragmentation, I would suggest working with all 3 teams and building up stableswap pools for assets bridged over (e.g. on Curve) - diversifying the risk if 1 goes down. Perhaps LP tokens for these 3 pools (or similar) would be the most reliable source for bridged assets in the long run.
As always: DYOR (this time really!) and please share thoughts here. This vote is too important to go unnoticed.
Hey everyone! Mustard from Multichain here!
As I have always said, both Axelar and Wormhole have a great team behind them and have proven they are very capable of developing high quality bridging infrastructure.
I would like to add some extra info that was not on the article.
Multichain has been a supporter of Moonbeam right from the start. We have around 25 million in TVL in Moonbeam already, mostly bridged from Ethereum. So we already have a head start 
Multichain has more than 62 chain integrated, including non-evm chains and over 1500 different projects! So we can help grow the Moonbeam ecosystem by connecting the Moonbeam projects with all of these projects and assets.
It has been running its bridges for over 2 years, and has focused on security ever since the beginning, our bridge has been open sourced since the beginning as we believe in decentralization.
1.Firstly,Multichain uses MPC off-chain network that leverage threshold ECDSA to sign signatures.
2.Secondly, We make our onchain contracts as simple as possible, and believe in the immutability of smart-contracts.
3.Ultimately, We use separated Ethereum Smart Contract for each Network and unique subset of MPC validators for each bridge, Moonbeam Bridge is uniquely and separated from all other bridges.
We have been audited several rounds by TOB and other best auditing firms in the space and have a Immunifi bounty and a security fund, for more security details check our article Multichain Security Model & Mechanism | by Multichain (Previously Anyswap) | Multichain | Medium
You can check our docs, statistics and github at multichain.org .
If you have any questions please join our TG and we will be more than happy to answer them for you!
Unfortunately I cant post our TG link here because of a 2 links by post limit.
Mustard
VP, Ecosystem at Multichain
hi Luke. it’s rather unfortunate that your users have been subject to an exploit already, and regardless of the circumstances there are two important design considerations for any bridge: Engineering and consensus. Consensus is generally bulletproof, but when it comes to hacks most projects of course fail on the engineering side, as evidenced by the Nomad hack. a canary network and 3 day optimistic fraud challenge period for example would offer a more robust second/third layer of protection (managed by council and technical committees) that would mitigate these kinds of careless oversights and other failures, do you agree?
Although it’s assumed your new focus should be on bridge security, and it’s listed as a top priority, it’s still evident to me by your 3 choices that you are prioritizing UX, asset choice, and speed of deployment over more secure options. i think you should reconsider your approach and research projects that trend towards the ‘trustless’ side of the spectrum vs. these 3 more ‘trusted’ systems for the benefit of your users, with bonus points awarded for supporting Polkadot ecosystem projects with native features and governance.
My recommendation would be to go with a light client-based bridgehub / message network that’s more closely aligned with Parity’s vision, combined with a liquidity network such as Darwinia + Celer. These solutions may take a greater amount of time to implement and some features may still be under development, but it’s all about your priorities. do you value speed and UX, or security?
The biggest factors is utilizing security. We are in a transitional space were the education of bridging is becoming alarming and how it plays in this blockchain trilemma .
Most projects tend to lean towards scalability but sacrificing security with this choice. With previous exploits such as nomad, hacks such as solana wormhole, ronin hack and even harmony hack. Wouldn’t security be the most important factor when highly liquid bridges tend to be targets. Projects such as Interlay, Celer and Darwinia tend to utilize Light Client technology that aligns with Polkadot’s ethos. I would hope projects such as yours could forsee that deploying trusted bridges will become another case of hack.
I dont like to see this with any project and particularly in the Polkadot Ecosystem.
I would hope moving forward we can see better education on which bridges are trusted and trustless giving the consumer the choice on which bridges best fit their needs.
Please consider Darwinia.network. light client bridge protocol. Secure AF.
Hi Megan, I just wanted to point out that this proposal was submitted by a community member in Poland, and not by any of the contributing teams to Moonwell (I work for one of them).
I appreciate this recommendation, and would encourage your team to put up a similar proposal for a bridge solution that you believe aligns with the goals of the Moonwell community and the broader Dotsama and Moonbeam ecosystems. My team is intentionally not voting on this proposal because we don’t want to influence the outcome, but ultimately this is a signaling vote and is a good way for the Moonwell community to express their preference for what they believe are the 3 strongest current options available to the Moonbeam ecosystem.
If there are other options they missed, please feel free to:
This is all within your power as a community member, so I’d encourage you to engage. Thanks!
Dustin, I think everyone here in the community would like to learn more about the benefits of light client technologies, and what they can bring to Moonwell and the Moonbeam ecosystem. I think it should be noted that Nomad was also a “light client technology,” yet what caused their downfall was poor smart contract security, an attack vector that was completely unrelated to the way they transfer data from one network to another. So it isn’t fair to say “light client technology is superior” when we know that security requires a defense-in-depth approach at multiple layers, including good operational practices, which have been the unfortunate downfall to many bridges.
I’d encourage you and your team to participate in here and educate our community on why your solution is superior to the 3 that @nikodem proposed. It might also help to share a roadmap and plans/timeline for when bridged assets might be available, to help the community plan. Thanks!
Afaik Nomad did not yet have light client support. Smart contract bugs can happen on any system, so the Nomad hack does not serve as argument “against” light client bridges.
Rather, the issue is that there currently aren’t any live light client solutions to bridge between Polkadot and Ethereum and we still don’t have a clear timeline for these (were expected already last year but these things need efficient light clients which are simply not that easy to build).
So, I don’t think there is a way around more centralized designs right now. Waiting is not an option: our ecosystem is stalling without being able to access liquidity - until we mature and build up value and demand internally.
It is a risk, but in this case a calculated one imho.
When a light client bridge launches and is stable, I think the switch will happen naturally. (I’d even bet that within 3 years all major chains will have light client bridges between them. After all, this is largely “only” an implementational problem by now.)
Hello, yes as you mentioned above that we can open up discussion to further the education about light clients as for Nomad I did mention Nomad as an exploit not an hack in comparison to other bridges being compromised. Of course there’s quite a bit of complexities with security from messaging to smart contracts , teams as I mention have been working on them for several years and are still not fully stable. So moving forward hope I can help educate others in bridging and how important security is surround these bridges.
Apologies, you are correct that Nomad uses optimistic interoperability and watchers, not light clients - just found it here: Optimistic Verification - Nomad Docs. And I agree the Nomad hack doesn’t serve as an argument against light client bridges.
I do think Nomad and other bridge hacks caution us that no technology is bulletproof if the contracts have poor security. So regardless of your choice of light client, MPC, optimistic, or other technology, you still have to “trust” that the creator of the bridge has good security practices and didn’t make mistakes that enable hackers to steal funds from the bridge contracts.
I haven’t seen anything that I would truly call a “trustless” system - there is always trust somewhere. Even with light clients - who are you trusting to create and maintain the light client? Perhaps immutability is a nice quality to have here, but at some point you have to trust something that was created by humans and has bugs.
i agree that technically there can’t be trustless systems because there will always be the assumption of potential code flaws, and that’s true for any project, but there are some (especially Substrate-based) bridge projects that have prioritized design choices around decentralization and being as close to the trustless side of the spectrum as possible. the shared security of the relay chains and robust governance systems add on additional levels of protection for bridges created for the dotsama ecosystem, where DAOs act like bulkheads to contain and limit potential damage whether that be from potentially damaging code changes, or disaster.
the whole hype around light clients is due to them performing native verification vs. layering on and having to trust a set of external validators. use of light clients may result in some time delays to achieve finality from chain to chain, but that’s where liquidity networks performing local verification come in to provide fast entries and exits. this combination of message network + liquidity network creates a solution that (outside code) inherits the security of only the source and destination chains.
not to dispute the quality or diss on other bridges especially the ones represented here; they offer practical solutions and choices for those with various design considerations. and although i’d like to recommend Darwinia Polkadot<>Kusama bridgehub as an immediate solution, we are still in the process of connecting up Moonriver to our various supported chains, and are a few months out from launching the direct route to Ethereum and SDK. Routes from Moonbeam<>ETH will follow afterward.
You should also consider REN, their Moonbeam support should be ready soon: Introducing Ren 2.0. Today we are excited to introduce the… | by Ren Community | Ren Project | Aug, 2022 | Medium.
They have the best reputation and track record so far and they will be fully trustless and decentralized.
I don’t have much to add as I agree with the criteria used to evaluate the bridges (great job btw).
For me, given the nascent state of bridges, and the history of bridge hacks, Lindy effect + (perceived at least) operational security are really important. As folks have said, nothing is forcing Jump or Multichain to backstop in the case of hacks in the future even though they have in the past, so betting on repayment doesn’t seem too important.
A platform having been hacked and lost either user funds (whether they’re repayed or not) should always trigger a huge increase in security practices for those teams. I am not aware of Axelar’s or Multichain’s or Wormhole’s full security measures, but I do know that in every organization myself or a friend or colleague has worked in that security is treated extremely seriously after hacks of these kinds. (Aside: it’s unfortunate that it’s typically not treated as seriously before these events, but hopefully the crypto space will push this change for software companies)
Unfortunately, this means the underlying mechanism doesn’t matter too much to me, so even though the nerd inside of me gets excited by each of the mechanisms, I think it’s rational to trust first Wormhole (since it was hacked for the most money and survived) and then next Multichain (since it was hacked a bit) and finally Axelar in that order makes the most sense.
This is great, I didn’t realize Ren was coming to Moonbeam, but they’ve definitely been around for a long time (I used their BTC bridge in 2020) and they have a solid solution for BTC.
Ren isn’t decentralized.
To the best of my knowledge and according to this report it’s a multisig (decrypt.co/40110/massive-honeypot-ren-holds-100m-bitcoin-centralized-wallet%3Famp=1).
They might be one day if they launch FROST signing - but they would still need a collateralized model if you want it to be trustless (otherwise it would be a bigger/better multisig than now but still more or less trusted).
Proposing having Celer cBridge for the Moonbeam Ecosystem
Hey all this is Ilnaw from Celer Network. As addressed in @alexei’s post, there are a number of risks we absolutely must address when considering different bridging options. The most imperative one being the security of a particular bridge. At the end of the day, the result of the bridging process is similar, it’s just the process itself that needs to be examined.
Unfortunately, as @alexei mentioned, both Multichain and Wormhole have been exploited in smart contract hacks in the past and we are happy to see them recovering well, but it doesn’t change the fact that it has happened. Smart contracts are extremely difficult to manage as if they don’t change, the hacker has a massive amount of time to look for potential vulnerabilities or exploits. There was also a bit of a lack of security monitoring in general. Part of the reason these vulnerabilities exist is that some models are inherently flawed.
In comparison, we at Celer use a two-fold approach to security that makes it incredibly difficult for any exploits to be executed by malicious actors and has been proven through an extensive cross-chain transaction history of $10 billion. As proven by our analytics, we have seen our fair share of market conditions and users; we have built trust from the market in our protocol. Some points we’d like to highlight are that cBridge was launched in July 2021 and has seen huge traction and growth with:
Celer cBridge supports 37 chains and 135 tokens in cross-chain bridging, including the bridging of USDC, USDT, and ETH on Moonbeam. For the full list of chains and assets that cBridge supports, you can look here.
Security Models
Celer cBridge comes with two security models that apply to cross-chain transfers on a per-tx basis.
By default, inter-chain dApps rely on the security of the State Guardian Network (a Cosmos Chain) by processing messages routed from another chain without delay. The SGN offers L1-blockchain level security just like Cosmos or Polygon with it being a Proof-of-Stake (PoS) blockchain built on Tendermint with CELR as the staking asset. If a guardian acts maliciously, its staked CELR will be slashed by the consensus protocol. This level of economic security is something that grows with the staked CELR’s value and is simply not available in simple Multi-signature or MPC/PoA-based solutions. As of early September 2022, SGN has 21 validators, with renowned entities such as Infstone, Ankr, Cosmostation, Binance and Everstake running validators.
Even under the extreme case of 100% of the guardians behaving maliciously, inter-chain dApps can maintain full security with an optimistic-style delay buffer. Instead of instantly processing a message routed by the SGN, cBridge can inject a mandatory delay buffer and anyone can run an independent watchtower service to double-validate the message on the source chain. If the watchtower service detects any inconsistency, it can prevent the message from being processed before the delay expires.
In the cBridge production, optimistic-rollup-style delay-buffer execution is used for certain large-sized transactions along with an independent sentinel system. For any large transaction larger than a certain amount, two-txs are needed to actually make the bridge happen: a “commit” transaction that will trigger the time buffer and then after the time buffer, a “confirm” tx. If the sentinel system observes that the “commit” tx does not have a matching source in a different chain, it can immediately pause the token bridging process. The sentinel system also continuously monitors the bridge for small transactions as well to detect and prevent any unexpected smart contract bugs. There is also rate-limiting for token bridging as the last resort to the worst-case scenario.
Celer cBridge is also using security measures on all levels of operations:
Smart contract-level rate-limiting to risk control and monitor sudden volume surges;
Transaction-level sentinel for on-chain bridge in/out balance monitoring;
Front-end and website integrity monitoring for codes and contract addresses;
CertiK, PeckShield and SlowMist have audited Celer cBridge. Furthermore, cBridge has one of the more extensive bounty programs in the space via a $2 million offer on Immunefi.
There’s more to interoperability, as Celer has been spearheading cross-chain message passing with its Celer Inter-chain Messaging framework implemented in different dApps to enable various one-click and one-tx cross-chain user experience. Examples include one-click cross-chain token exchanges with Rango Exchange, cross-chain perpetual swaps with SynFutures, and cross-chain governance with Futureswap. We are excited to support Moonbeam dApps to enable similar features with IM down the road.