Treasury Proposal by Centrifuge: Support Axelar General Message Passing in the Polkadot ecosystem (via BridgeHub)
Proponent: 12wWLUd5qMzLFGqBsMnHLVFeTuYJwuo5ygMAxuSywrBX1XSF
Date: 2023.03.23
Requested DOT: 45,306 DOT (277,000 USD)
Contact: [email protected] & [email protected]
Currently, the only bridges available to users of the Polkadot ecosystem have some limitations, including:
-
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.
-
Centralized bridges which are reliant on multisigs, which is incompatible with the Web3 vision of the Polkadot ecosystem.
-
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)
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.
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.
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: