Glacis – A Router and Firewall for Cross-Chain Messages

I’ve been thinking about Cross-Chain development tools and scenarios for several years now, since the start of the Moonbeam project back in 2020.  Moonbeam itself is specialized in supporting cross-chain developers, and in the last 4 years I’ve learned a lot based on conversations with bridge providers and developers building cross-chain protocols. For development of a Web3 protocol today, cross-chain  is both a requirement and also full of risks. Glacis, a new project coming out of Moonsong Labs is our answer for today’s developers that find themselves between this rock and hard place. It’s an attempt to empower developers to meet critical cross-chain requirements, while at the same time providing tools that help them manage cross-chain risks in a better way.

Glacis, at its core, is a router and firewall for cross-chain messages.  It uses an adapter system to integrate with leading bridges and general message passing (GMP) solutions such as Axelar, Wormhole, Layerzero, CCIP, and Hyperlane. Glacis gives developers abstraction over existing bridging protocols, and the ability to specify access control, redundancy, retry management, and routing behavior for cross-chain messages they are sending between smart contracts on different chains.  Integrating a single bridge, which is the status quo for most developers today, means your protocol will live or die with the underlying bridge provider. That bridge provider’s security risks become your risks. But with Glacis, those underlying bridge risks can be greatly reduced through the ability to shift and manage traffic between providers using the features above. This empowers developers and protocols to be in control of and manage cross-chain risks. The rest of this blog will delve deeper into the current state of the market, further introduce Glacis and the challenges it addresses, the solutions it provides to those problems, and explore what future opportunities exist.

Cross-Chain Developer Motivations, Mindset, and Experience

Back when we started Moonbeam, many developers were still developing with a single chain deployment in mind. You would pick a chain (e.g. Ethereum mainnet) and develop against and deploy to that chain.  Today, the landscape has changed. Single chain deployments are the exception rather than the rule. Cross-chain is the new normal. According to the latest Electric Capital Web3 developer report:

• 80% of developers work on 2+ chains
• There has been 10x growth in multi-chain developers since 2015
• 30% of developers work on 5+ chains

Why is this the case? What is the reason for working on multiple chains?

From my perspective, this path towards multichain deployments is inevitable. There has been and will continue to be a proliferation of chains. As there are more and more chains, users and assets get split across those chains. Adopting a development strategy that restricts deployment to a single blockchain significantly narrows the total addressable market (TAM) for that application or protocol. We can see that even Ethereum mainnet stalwarts like Uniswap, Aave, and Compound have all gone multichain. This need to reach users and assets on different chains will continue to drive multichain chain deployments and cross-chain requirements.

Current Cross-Chain Dev Approach and its Limitations

The typical approach taken by developers today is to opt for the straightforward strategy of choosing a single bridge provider to meet their cross-chain needs. This is an appealing choice for its simplicity: you have 1 SDK and API you need to learn and integrate. Another benefit of this strategy is by using a single bridge, developers can avoid liquidity fragmentation, as bridges usually produce different token representations on different chains. Despite the benefits, this single bridge approach still comes with significant risks.

From experiences on Moonbeam and Moonriver, I am acutely aware of the risks that the failure of a single bridge can have. Nomad and Multichain were both heavily used within these  ecosystems and both had catastrophic failures, leaving enormous amounts of damage in their wake.  When you integrate, embed, or rely on a single bridge, the risk for your application or protocol extends out to include all of the risks of the underlying bridge you are integrating – and these security risks for any one bridge are substantial.

The risks extend beyond catastrophic failures. Numerous other issues, while not as severe as hacks or complete breakdowns, can still significantly affect your protocol’s users. For example, bridges can have unplanned downtime, performance issues, or even just be down for planned maintenance and upgrades. Depending on your protocol, downtime could result in anything from poor user experience all the way to end user loss of funds in the case of e.g. a lending and borrowing protocol where user positions can be liquidated with changing asset prices.

Relying on a single bridge for integration is a little like an “integrate and pray” strategy, where your success or failure is inextricably linked to the performance and reliability of the chosen bridge provider.

Multiple bridges as a solution to single bridge risks

Integrating multiple bridges and being able to control the flow of traffic and tokens across them greatly mitigates single bridge risks.  If a given bridge is having an issue, you can failover or re-route to another bridge that is working normally, but this is easier said than done. Each bridge provider has a different architecture, different SDKs and APIs, and different capabilities. Developers are already being asked to be infrastructure experts in order to integrate one bridge, and  adding more bridges multiplies the work required to learn and integrate different SDKs and APIs. And the challenges don’t stop there; once integrated, cross-chain routing, redundancy, and other logic needs to be implemented and maintained across them. Implementing a multi-bridge approach in-house is complex, carries implementation risks, splits token liquidity, and leads to much higher cost and delayed time to market.  For this reason, almost all teams default to the single bridge option.

Compounding this issue is that today’s developer tools are designed with either single chains or single bridge providers in mind. Moving to a multi bridge configuration generally means that existing tools won’t work as well, and that a combination of existing tools needs to be used to get a clear picture of what is happening. And beyond visibility, any management controls for changing which bridges are used needs to be developed as custom logic.

What is Glacis?

The core of Glacis is a management control plane that integrates leading bridges and allows developers to control the routing of messages across multiple bridges. Glacis is a router and firewall for cross-chain messages. It provides an adapter architecture for supporting multiple bridges and general message passing providers. Upon initial release it supports Axelar, Wormhole, LayerZero, CCIP, and Hyperlane, and it can be easily extended to support additional bridge providers by creating additional adapters.

The implementation of the core is a set of solidity smart contracts that interface with the bridge provider gateway contracts on supported chains. It abstracts the SDKs and APIs of the individual bridge providers. Developers call the Glacis API which in turn calls the bridge provider contracts. This greatly simplifies the development of a multi-bridge architecture as you just need to use the Glacis API, and Glacis can route your messages to destinations across any of the supported bridges.

As a set of smart contracts, there are limited trust assumptions for Glacis when compared to other solutions which rely on off-chain routing logic. Developers can configure Glacis with exactly the routing and security configuration they want.  As part of the first release of Glacis, the core contracts are being open sourced and can be found here.

Cross-chain applications are being built on top of the Glacis core.   The first application is Glacis Cross Chain Tokens (GXTs). GXTs are mint and burn cross-chain tokens that behave like LayerZero OFTs, Axelar Interchain Tokens, and Wormhole xTokens. The key difference is that they are built on top of Glacis, so they are not tied to any particular bridge provider. With GXTs you can switch bridge providers or use Glacis redundancy to mitigate single provider bridge risk in your cross-chain token. GXTs are also XERC20 compatible so you can always move off Glacis if it no longer serves your needs well.

Additional Glacis cross-chain development tools are under development by the Glacis team and will be made available in a follow-on release. This includes a Glacis explorer which will show any message or token transfer which flows through Glacis regardless of which chains or bridges are being used. This will help with application development, troubleshooting, and ongoing management for developers.

How does Glacis Work?

A smart contract sends a message on Chain 1, which is screened by a firewall for security verification of your policies. This message is then routed through Glacis, acting as a GMP matching engine, to ensure it is directed to the correct chain with the right parameters. The message may pass through various GMP providers. Upon receipt at Chain 2, the message undergoes another security check before being received by the intended application, where the message is then processed accordingly.

How does Glacis Address Cross-Chain Challenges?

The first thing that Glacis does to help address cross-chain challenges is to mitigate the risks with having a single bridge for your protocol or application. Glacis creates an abstraction layer on top of supported bridges and general message passing providers. This means that developers just integrate once with Glacis, but that gives them a multi-bridge implementation. Glacis dramatically simplifies multi-bridge implementations, putting them in reach for every Web3 team.

Once Glacis is in place securing your cross-chain interactions, its features can be brought to bear to mitigate different kinds of bridge risks. For example:

• Abstraction allows developers to quickly and easily implement multi-bridge configurations that avoid single bridge risks.
• Access Control can be used to secure cross-chain interactions, limiting the cross-chain attack surface to the smallest possible.
• Redundancy can be used to create high availability configurations such as a 2 of 3 quorum across 3 different bridges. This means that any one bridge can be totally compromised, but your Glacis app will continue working normally.
• Retry Management can be used to gracefully handle messages which are not relayed properly or other reliability issues, an all too familiar occurrence.
• Intelligent Routing can be used to failover, re-route, or migrate traffic from one bridge that is having issues to another.
• GXTs can be used to create native cross-chain tokens which aren’t wrapped, and which aren’t dependent on any specific bridge provider.

Developers have the flexibility to decide exactly how they want to set up their cross-chain configurations, which bridges to use, determining what level of redundancy they require, and can optimize based on cost, speed, and other parameters.

Comparison with the Development of Networking

I spent many years working in the networking and systems domain before joining Web3. It strikes me that there are a lot of parallels between the history and evolution of networking in the IT domain and cross-chain in the Web3 domain. In the networking domain you started with proprietary, vendor specific protocols which over time evolved into open standards which were managed by an increasingly rich stack of management tools. Network carriers like ATT, Verizon, and Telefonica are similar to the bridge and GMP providers in Web3, connecting disparate blockchains with each other.

In the 1980s you had vendors like Cisco start to develop routers that could interface with different proprietary networking technologies and providers. Customers could specify routing, failover, redundancy, and security logic using these devices. The feature set of Glacis was directly inspired by network routers and firewalls, but with the features applied to bridges and general message passing providers. Just like Cisco, I believe these cross-cutting features are best provided by a provider that isn’t a bridge operator themselves. Bridge providers aren’t well positioned to deliver features which cut across multiple providers, which include their competitors.

I believe we are at the beginning of a new cross-chain Web3 infrastructure category with a huge market and a Cisco-like opportunity in front of it. Many apps can be built on top of Glacis Core, inspired by the networking domain. Let’s take a quick look at what these could be and what they mean in the context of cross-chain:

• Deep Packet Inspection – this could be standardized templates where the router or firewall can act on message content (not just message metadata like source and destination). It could keep track of total value transferred in the last 24 hour period and not forward messages that increase this value beyond a certain threshold.
• IDS/IPS – this could be an off-chain database that is consulted with fingerprints of known bad messages. If a match is found, an alert would be raised and the message would be quarantined.
• Policy based and software defined networking  – this could be cross-chain message and token routing based on destination chain conditions, oracle feeds, or other predefined policies.

How does Glacis help Moonbeam?

Moonbeam has always tried to be the best place for developers to build cross-chain applications. This includes having the best cross-chain tools, infrastructure, docs, and knowledgeable DevRel engineers. Glacis directly supports this mission and provides an important capability to cross-chain Moonbeam developers. Glacis will leverage the existing bridges on Moonbeam including Wormhole, Axelar, and LayerZero, allowing developers to configure more complex and redundant multi-bridge configurations.

The initial development of Glacis has used Moonbeam throughout, ensuring its compatibility as a supported network from the start. Moonbeam developer relations can support any team interested in exploring development with Glacis. My hope is that developers use Glacis on Moonbeam to create safer cross-chain applications that can be managed, controlled, and optimized in a way that is much better than what is currently possible.

Learn More about Glacis

To learn more about Glacis have a look at the Github and developer docs below. And follow Glacis on Twitter for updates.

• Website
• Docs
• Github
• Contact 
• Twitter