Polkassembly Logo

Head 1
Head 3
Head 4
Create Pencil IconCreate
TRACKS
ORIGINS
Report an issueNeed help with something?
Foot 1
Foot 2
Foot 3
Foot 4
OpenGov
View All Discussion

Treasury Proposal by Centrifuge: Support Axelar General Message Passing in the Polkadot ecosystem (via BridgeHub)

mustermeiszer
2 years ago

Proponent: 12wWLUd5qMzLFGqBsMnHLVFeTuYJwuo5ygMAxuSywrBX1XSF

Date: 2023.03.23

Requested DOT: 45,306 DOT (277,000 USD)

Contact: jeroen@k-f.co & frederik@k-f.co


Currently, the only bridges available to users of the Polkadot ecosystem have some limitations, including:

  1. Being EVM-specific and not Substrate native, e.g. several bridges (including Axelar) have been deployed on Moonbeam EVM. While this is great for bootstrapping liquidity in those EVM networks, it complicates integrations with other parachains through XCM and adds significant overhead.

  2. Centralized bridges which are reliant on multisigs, which is incompatible with the Web3 vision of the Polkadot ecosystem.

  3. Bridges that only go to Ethereum mainnet, and don’t support message passing.

We believe Axelar is an ideal option for solving those problems, as it’s a decentralized protocol based on delegated proof-of-stake, with support for general message passing across all its target domains. It’s currently connected to 32 blockchains, including Ethereum, Avalanche, Celo, Arbitrum, Cosmos, and Polygon.

Axelar’s any-to-any connectivity is crucial to the success of any ecosystem. Within Cosmos, where Axelar is the most widely used interoperability platform, historically only a minority of users onboard from Ethereum mainnet, with Polygon being the most popular option. By enabling people to onboard from any ecosystem, we expand the user base of Polkadot, Centrifuge and the ecoystem. Axelar network supports General Message Passing across chains and delivers any-to-any connectivity. Most people are familiar with cross-chain activity via bridges, which can only transport wrapped representations of assets. General Message Passing goes beyond: Axelar can transport any payload. This enables more sophisticated cross-chain operations, like buying an NFT representing a RWA on Centrifuge, with an asset held on Arbitrum. Axelar is working with Circle to compose this functionality with CCTP, so that users can perform those operations with 0-slippage.

Centrifuge and Axelar have been discussing the need for this with the ecosystem and the following parachains have also expressed an interest in using a Substrate-native Axelar integration:

  • Astar
  • Acala
  • Oak Network
  • Parallel
  • Gear
  • Manta
  • Clover
  • Composable
  • Equilibrium
  • Interlay
  • Peaq network
  • Unique
  • Watr
  • OmniBTC

The deliverable for this proposal contains an Axelar-Gateway-Pallet compatible with XCM to be integrated in the BridgeHub common good parachain, an Audit of the given pallet and all work around maintenance. The given Axelar-Gateway-Pallet will also be usable for a "local" deployment so that it will help all Substrate based parachains to connect to Axelar.

The full proposal can be found here.

Comments (6)

2 years ago

I support this proposal. I'm excited for the prospect of Bridge Hub and to have a few different bridge pallets in there would be quite powerful. I also think it makes sense to ensure there is healthy competition between the Bridges.

profile
vgeddes
2 years ago

Snowfork does not object to this proposal in any way. We're also launching our bridge on BridgeHub. We realize that light-client bridges such as ours require a long development time, and have a lot of complexity that results in delays. If an Axelar bridge helps the ecosystem in the interim, we support it. In a sense, it helps take the heat off us.

At launch, both bridges will offer different functionality, so there is no overlap.

  • Snowbridge will initially only support transferring ERC20 tokens to Polkadot. This is the same plan as per our original treasury proposal way back in Nov 2022. Support for XCM::Transact will come later (The base architecture supports pluggable message types)
  • The Axelar bridge will initially only support generalized message passing (aka XCM::Transact).

Now trying to be objective, I do have one concern about Axelar, and that is the tokenomics behind the Axelar token. Axelar validators are incentivised to be honest by having their AXL stake slashed for misbehavior. The problem I see that less than 25% of the total supply of AXL is circulating. So if large amounts of AXL come into circulation, the price could decrease rapidly, reducing the security of the bridge.

In such a scenario, we're left with having to trust in the honesty of Axelar validators, rather than relying on in-chain disincentivizes for fraud. The community will need to decide whether to accept that risk (which is common to all multisigs) At least its a 46/70 multisig (with MPC), an improvement over most other multisigs.

I think some more discussion around "defense in depth" would also be valuable. This could take the form of one or more of the following:

  • Ability to emergency halt the bridge by governance
  • Circuit breakers that automatically halt the bridge when anomalous events are detected
  • A timelock that delays routing of inbound XCM::Transact calls for a certain period of time. This would allow intervention by governance when fraud is detected. Given all the bridge hacks of 2022, the desire for instant finality is perhaps something the community may need to compromise on.
Load more comments
PleaseLogin to comment

Help Center

Report an Issue
Feedback
Terms and Conditions
Github

Our Services

Docs
Terms of Website
Privacy Policy

A House of Commons Initiative.

Polka Labs Private Limited 2025

All rights reserved.

Terms and ConditionsTerms of Website
Privacy Policy