Proposal Summary Blockchain@Columbia, in conjunction with the Fantom and Axelar Team, are proposing to deploy Uniswap V3 on Fantom Chain. Given the BSL expiry, it is crucial for Uniswap to establish market share in other ecosystems. Deployment on Fantom would be beneficial to both Uniswap and Fantom.
Overview of Fantom Fantom Chain is a highly scalable and secure smart-contract platform designed to enable rapid deployment of dApps. Powered by its unique Directed Acyclic Graph framework and an advanced consensus mechanism, Fantom offers fast, secure, and low-cost transactions. Its innovative architecture has attracted numerous projects and developers.
Motivation As an industry leader, Uniswap has established a strong presence in the DeFi space. In order to maintain its competitive edge, Uniswap must continue to adapt and expand its reach to other blockchain networks. This strategic move will capitalize on current market opportunities and strengthen Uniswap's position in the DeFi landscape. Axelar is chosen for a number of reasons:
Outlook While Fantom’s time in the spotlight has somewhat passed since “DeFi Summer”, the ecosystem still boasts a significant amount of TVL, hovering around $450 million for the majority of the past year with steady growth (DeFiLlama). There is a clear demand for decentralized exchanges on Fantom as four of the top ten protocols are decentralized exchanges, so there’s no doubt that Uniswap will be the leading DEX while also facilitating swaps for currently unavailable pairs. Additionally, the Fantom Foundation has consistently worked to reduce the staking requirements for validators from 3.175m FTM in 2021 to 500,000 FTM. As the requirements needed to validate the network decreases, more users will be able to participate in the validation process. Fantom Chain's dedication to the Ethereum ecosystem is evident in its interoperability efforts, developer resources, and focus on driving the growth of decentralized finance. The Fantom team is also committed to fostering collaboration with Ethereum through Axelar Network to enable smooth asset transfers within the two ecosystems. We are convinced that deploying Uniswap on Fantom Chain offers numerous advantages to both Uniswap Labs and its users. We estimate that 30% of the current DEX volume on Fantom would be routed to Uniswap should deployment occur. DEX volume on Fantom is available on DeFiLlama. Uniswap would receive an estimated $30-40 million in volume per week based on the data above as well as deployment on an highly-compatible, low cost chain to test new products and attract users.
Engagement Terms The deployment and its costs will be borne by the Fantom Foundation and Axelar. As such, no grants or subsidies will be offered to Uniswap. Axelar and Fantom will handle the backend deployment of the smart contracts; however, Uniswap will need to handle the frontend.
Bridge Security
Does the bridge support arbitrary message passing? -Yes, arbitrary message passing was described in the Axelar white paper in January 2021, and Axelar released its General Message Passing (GMP) capability to mainnet in April 2022. For example, GMP enables developers building on one chain to call any function on any other connected chain. (We use the word “function” to encompass both smart contracts at the application layer and functions built at the protocol layer, as in Cosmos, for example.) That means complete composability across Web3. -Like all Axelar functions, General Message Passing relies on a permissionless validator set (delegated proof-of-stake) for security and a decentralized protocol that handles routing and translation.
Is the bridge secured by a trusted entity, by a multi sig, or a protocol/set of incentivized nodes? Robust security comes from (a) the right design, (b) engineering practices, and (c) application-level security add-ons:
(A) The Design: A decentralized permissionless network with a many-to-many communication model. The decentralized and permissionless model has the best practical security guarantees as it encourages diverse validator deployments, incentivizes validators to guard their keys, promotes good behavior, and punishes bad behavior. -Axelar is the full-stack decentralized transport layer. At the core, it is powered by delegated proof-of-stake consensus to validate cross-chain messages. Applications can instantiate additional validation logic across connected paths 3 that may be governed by the application token, permissioned set, light-client, zk proofs, or other available technologies. Our approach is to: (a) Offer the best-in-class security via decentralization as the default that solves most use cases for developers. (b) Allow developers to customize security as needed. -The Axelar network itself comprises a validator set responsible for maintaining the network and executing transactions, running the Cross-Chain Gateway Protocol, a multi-party cryptography overlay that sits on top of a Layer-1 blockchain. -Axelar Gateways are effectively smart contracts that connect the Axelar network to its interconnected external chains. Validators monitor Gateways for incoming transactions, which the validators READ. They then reach a consensus on the validity of that transaction and, once agreed, WRITE to the destination chain’s Gateway to execute the cross-chain transaction. -The validators and Gateways compose the core infrastructure layer. It’s important to note that relaying across Axelar and its interconnected networks is completely permissionless. This guarantees that no one can censor user transactions and delivers 100% liveness guarantees (assuming the interconnected networks and the Axelar network are running). If relayers are down, the user or anyone else can post transactions, themselves. If one of the interconnected networks is halted or undergoing an upgrade, the packets are just queued up at the network layer and can subsequently be posted (or re-posted) when the networks are back up. -Proof-of-stake decentralized design at the core - Axelar is built using battle-tested delegated proof-of-stake consensus with a diverse and dynamic validator set that is open to all. -To further decentralize the network, cross-chain messages are approved if they’re authorized via the quadratic voting rule. That is, the voting power of each validator is equivalent to the square root of their stake. A threshold of validators (currently 60%), weighted by the square root of the stakes, must collectively co-authorize every cross-chain request. With quadratic voting, as validators accumulate stake, it gets harder for them to accumulate voting power. -Amplify stake security - With Interchain Security available in the Cosmos ecosystem in the coming months, one network can “borrow” the security of other networks. This would allow it to increase the stake used for validation on the network, making any economic attack much more difficult. We also have plans to allow ETH holders to contribute to Axelar’s security, via the restaking model that Eigenlayer introduced recently.
(B) Engineering and Operational Practices -Key rotations on the network - Validators of the Axelar network maintain keys that allow them to co-authorize cross-chain requests, similarly to how they co-authorize every block on the blockchain. -Continuous unit tests & end-to-end tests through the stack - Continuous unit tests and end-to-end tests help discover vulnerabilities and bugs early in the pipeline. -Audits and bug bounties (see above).
(C) Application-Level Security Add-Ons -Customize security - Additional paths can be secured by deploying additional validator sets, light-clients, and/or zero-knowledge proofs when available. We think this will be the best instantiation for the Uniswap community: leverage the robust Axelar network for all default traffic. If there is a highly valuable/sensitive transaction, utilize the additional UNI elected validator set for co-signing. See the Appendix for more details on how we propose customizing security for Uniswap. -Rate limits - The Gateways and the Axelar network have a rate-limiting function, which limits how much of each asset can be transferred in a given time interval.
Sitting atop the validators and Gateways are Axelar services and APIs that enable developers to access the tools and infrastructure enabled by those validators and Gateways. These services and APIs do not add any security assumptions.
Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms? A majority of Axelar validators attest to messages that pass from Ethereum to a destination chain. The voting threshold is 60%, based on the validator’s quadratic stake (current stake distribution: Validators | Axelarscan). An adversary who can corrupt 60% of voting power can pass fraudulent messages. The adversary could try to corrupt enough servers to do this, but mechanisms such as key rotations & rate limits minimize the potential of these attacks.
What are the ramifications of fraud to the malicious actor? -Axelar validators get slashed on the Cosmos SDK level, the same way that validators of any other Cosmos chains get slashed for misbehavior. -There is a penalty for validators who don’t maintain sufficient uptime. When a validator doesn’t vote on enough cross-chain events, they’re penalized with a loss of stake and rewards. -Validators who misbehave significantly (double signing blocks, not participating for a long period of time) get jailed.
Within the TM consensus rewards, rewards slashing rules are set as follows: -Validators will lose the TM Consensus rewards if they lose liveness and get jailed if they don’t participate for a longer duration. -Validators need to sign 50% of the blocks in every 35,000-block window. -Given a block time of five seconds, this corresponds to maintaining total liveness for at least one day in every two-day window. -They lose 0.01% of rewards per block for downtime and 2% for double signing blocks.
If the validators lose liveness for more than 50% of the window, then they are locked (“jailed” in Cosmos terminology, forbidden from rejoining the validator set) for two hours (about 1,440 blocks), after which they would need to unlock themselves. Axelar network implements an unbonding period of seven days.
Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied? -Yes, the Axelar network code has been audited over 30 times and continues to go through continuous and rigorous audits. -There is also a $2.25 million bug bounty program on Immunefi. -Axelar network and contracts are all open-source to encourage white-hat revisions
Future Alterations Once a cross-chain deployment method is finalized in the future, we wholeheartedly support changing current deployment mechanisms to fit the new process. However, given the urgency of this proposal, we believe that the currently proposed deployment with Axelar is needed.
Timeline After the completion of the on-chain vote, Axelar will handle Uniswap V3 smart contract deployments on Fantom while Uniswap Labs handles the front-end integration. This is estimated to take ~4-6 weeks with audits.
Proposal Summary Blockchain@Columbia, in conjunction with the Fantom and Axelar Team, are proposing to deploy Uniswap V3 on Fantom Chain. Given the BSL expiry, it is crucial for Uniswap to establish market share in other ecosystems. Deployment on Fantom would be beneficial to both Uniswap and Fantom.
Overview of Fantom Fantom Chain is a highly scalable and secure smart-contract platform designed to enable rapid deployment of dApps. Powered by its unique Directed Acyclic Graph framework and an advanced consensus mechanism, Fantom offers fast, secure, and low-cost transactions. Its innovative architecture has attracted numerous projects and developers.
Motivation As an industry leader, Uniswap has established a strong presence in the DeFi space. In order to maintain its competitive edge, Uniswap must continue to adapt and expand its reach to other blockchain networks. This strategic move will capitalize on current market opportunities and strengthen Uniswap's position in the DeFi landscape. Axelar is chosen for a number of reasons:
Outlook While Fantom’s time in the spotlight has somewhat passed since “DeFi Summer”, the ecosystem still boasts a significant amount of TVL, hovering around $450 million for the majority of the past year with steady growth (DeFiLlama). There is a clear demand for decentralized exchanges on Fantom as four of the top ten protocols are decentralized exchanges, so there’s no doubt that Uniswap will be the leading DEX while also facilitating swaps for currently unavailable pairs. Additionally, the Fantom Foundation has consistently worked to reduce the staking requirements for validators from 3.175m FTM in 2021 to 500,000 FTM. As the requirements needed to validate the network decreases, more users will be able to participate in the validation process. Fantom Chain's dedication to the Ethereum ecosystem is evident in its interoperability efforts, developer resources, and focus on driving the growth of decentralized finance. The Fantom team is also committed to fostering collaboration with Ethereum through Axelar Network to enable smooth asset transfers within the two ecosystems. We are convinced that deploying Uniswap on Fantom Chain offers numerous advantages to both Uniswap Labs and its users. We estimate that 30% of the current DEX volume on Fantom would be routed to Uniswap should deployment occur. DEX volume on Fantom is available on DeFiLlama. Uniswap would receive an estimated $30-40 million in volume per week based on the data above as well as deployment on an highly-compatible, low cost chain to test new products and attract users.
Engagement Terms The deployment and its costs will be borne by the Fantom Foundation and Axelar. As such, no grants or subsidies will be offered to Uniswap. Axelar and Fantom will handle the backend deployment of the smart contracts; however, Uniswap will need to handle the frontend.
Bridge Security
Does the bridge support arbitrary message passing? -Yes, arbitrary message passing was described in the Axelar white paper in January 2021, and Axelar released its General Message Passing (GMP) capability to mainnet in April 2022. For example, GMP enables developers building on one chain to call any function on any other connected chain. (We use the word “function” to encompass both smart contracts at the application layer and functions built at the protocol layer, as in Cosmos, for example.) That means complete composability across Web3. -Like all Axelar functions, General Message Passing relies on a permissionless validator set (delegated proof-of-stake) for security and a decentralized protocol that handles routing and translation.
Is the bridge secured by a trusted entity, by a multi sig, or a protocol/set of incentivized nodes? Robust security comes from (a) the right design, (b) engineering practices, and (c) application-level security add-ons:
(A) The Design: A decentralized permissionless network with a many-to-many communication model. The decentralized and permissionless model has the best practical security guarantees as it encourages diverse validator deployments, incentivizes validators to guard their keys, promotes good behavior, and punishes bad behavior. -Axelar is the full-stack decentralized transport layer. At the core, it is powered by delegated proof-of-stake consensus to validate cross-chain messages. Applications can instantiate additional validation logic across connected paths 3 that may be governed by the application token, permissioned set, light-client, zk proofs, or other available technologies. Our approach is to: (a) Offer the best-in-class security via decentralization as the default that solves most use cases for developers. (b) Allow developers to customize security as needed. -The Axelar network itself comprises a validator set responsible for maintaining the network and executing transactions, running the Cross-Chain Gateway Protocol, a multi-party cryptography overlay that sits on top of a Layer-1 blockchain. -Axelar Gateways are effectively smart contracts that connect the Axelar network to its interconnected external chains. Validators monitor Gateways for incoming transactions, which the validators READ. They then reach a consensus on the validity of that transaction and, once agreed, WRITE to the destination chain’s Gateway to execute the cross-chain transaction. -The validators and Gateways compose the core infrastructure layer. It’s important to note that relaying across Axelar and its interconnected networks is completely permissionless. This guarantees that no one can censor user transactions and delivers 100% liveness guarantees (assuming the interconnected networks and the Axelar network are running). If relayers are down, the user or anyone else can post transactions, themselves. If one of the interconnected networks is halted or undergoing an upgrade, the packets are just queued up at the network layer and can subsequently be posted (or re-posted) when the networks are back up. -Proof-of-stake decentralized design at the core - Axelar is built using battle-tested delegated proof-of-stake consensus with a diverse and dynamic validator set that is open to all. -To further decentralize the network, cross-chain messages are approved if they’re authorized via the quadratic voting rule. That is, the voting power of each validator is equivalent to the square root of their stake. A threshold of validators (currently 60%), weighted by the square root of the stakes, must collectively co-authorize every cross-chain request. With quadratic voting, as validators accumulate stake, it gets harder for them to accumulate voting power. -Amplify stake security - With Interchain Security available in the Cosmos ecosystem in the coming months, one network can “borrow” the security of other networks. This would allow it to increase the stake used for validation on the network, making any economic attack much more difficult. We also have plans to allow ETH holders to contribute to Axelar’s security, via the restaking model that Eigenlayer introduced recently.
(B) Engineering and Operational Practices -Key rotations on the network - Validators of the Axelar network maintain keys that allow them to co-authorize cross-chain requests, similarly to how they co-authorize every block on the blockchain. -Continuous unit tests & end-to-end tests through the stack - Continuous unit tests and end-to-end tests help discover vulnerabilities and bugs early in the pipeline. -Audits and bug bounties (see above).
(C) Application-Level Security Add-Ons -Customize security - Additional paths can be secured by deploying additional validator sets, light-clients, and/or zero-knowledge proofs when available. We think this will be the best instantiation for the Uniswap community: leverage the robust Axelar network for all default traffic. If there is a highly valuable/sensitive transaction, utilize the additional UNI elected validator set for co-signing. See the Appendix for more details on how we propose customizing security for Uniswap. -Rate limits - The Gateways and the Axelar network have a rate-limiting function, which limits how much of each asset can be transferred in a given time interval.
Sitting atop the validators and Gateways are Axelar services and APIs that enable developers to access the tools and infrastructure enabled by those validators and Gateways. These services and APIs do not add any security assumptions.
Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms? A majority of Axelar validators attest to messages that pass from Ethereum to a destination chain. The voting threshold is 60%, based on the validator’s quadratic stake (current stake distribution: Validators | Axelarscan). An adversary who can corrupt 60% of voting power can pass fraudulent messages. The adversary could try to corrupt enough servers to do this, but mechanisms such as key rotations & rate limits minimize the potential of these attacks.
What are the ramifications of fraud to the malicious actor? -Axelar validators get slashed on the Cosmos SDK level, the same way that validators of any other Cosmos chains get slashed for misbehavior. -There is a penalty for validators who don’t maintain sufficient uptime. When a validator doesn’t vote on enough cross-chain events, they’re penalized with a loss of stake and rewards. -Validators who misbehave significantly (double signing blocks, not participating for a long period of time) get jailed.
Within the TM consensus rewards, rewards slashing rules are set as follows: -Validators will lose the TM Consensus rewards if they lose liveness and get jailed if they don’t participate for a longer duration. -Validators need to sign 50% of the blocks in every 35,000-block window. -Given a block time of five seconds, this corresponds to maintaining total liveness for at least one day in every two-day window. -They lose 0.01% of rewards per block for downtime and 2% for double signing blocks.
If the validators lose liveness for more than 50% of the window, then they are locked (“jailed” in Cosmos terminology, forbidden from rejoining the validator set) for two hours (about 1,440 blocks), after which they would need to unlock themselves. Axelar network implements an unbonding period of seven days.
Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied? -Yes, the Axelar network code has been audited over 30 times and continues to go through continuous and rigorous audits. -There is also a $2.25 million bug bounty program on Immunefi. -Axelar network and contracts are all open-source to encourage white-hat revisions
Future Alterations Once a cross-chain deployment method is finalized in the future, we wholeheartedly support changing current deployment mechanisms to fit the new process. However, given the urgency of this proposal, we believe that the currently proposed deployment with Axelar is needed.
Timeline After the completion of the on-chain vote, Axelar will handle Uniswap V3 smart contract deployments on Fantom while Uniswap Labs handles the front-end integration. This is estimated to take ~4-6 weeks with audits.
great, i support the process
Thanks for the proposal @blockchaincolumbia. This proposal is a good start, but there are a few things I'd like to ask:
Axelar's features and security are mentioned, but what is the real reason for nominating Axelar?
Uniswap and Fantom originate from the EVM Ecosystem, whereas Axelar originates from the Cosmos ecosystem. What's the reason for not picking an interoperability infrastructure provider that originates from the EVM ecosystem?
I recall there are 8 interop infra providers that were mentioned in Uniswap's cross-chain bridge assessment process.
Thanks for the proposal @blockchaincolumbia. This proposal is a good start, but there are a few things I'd like to ask:
Axelar's features and security are mentioned, but what is the real reason for nominating Axelar?
Uniswap and Fantom originate from the EVM Ecosystem, whereas Axelar originates from the Cosmos ecosystem. What's the reason for not picking an interoperability infrastructure provider that originates from the EVM ecosystem?
I recall there are 8 interop infra providers that were mentioned in Uniswap's cross-chain bridge assessment process.
what would be an alternative?
What are your thoughts on an interoperability infrastructure provider that does what Axelar does, but has some improvements such as middleware layer with customizable bridging logic, modular architecture and bridge contracts that are generated accordingly to the validated message/payload entering the middleware chain? What do you think?
What are your thoughts on axL-USDC used as liquidity? (from a security perspective)
great, i support the process
Thanks for the proposal @blockchaincolumbia. This proposal is a good start, but there are a few things I'd like to ask:
Axelar's features and security are mentioned, but what is the real reason for nominating Axelar?
Uniswap and Fantom originate from the EVM Ecosystem, whereas Axelar originates from the Cosmos ecosystem. What's the reason for not picking an interoperability infrastructure provider that originates from the EVM ecosystem?
I recall there are 8 interop infra providers that were mentioned in Uniswap's cross-chain bridge assessment process.
Thanks for the proposal @blockchaincolumbia. This proposal is a good start, but there are a few things I'd like to ask:
Axelar's features and security are mentioned, but what is the real reason for nominating Axelar?
Uniswap and Fantom originate from the EVM Ecosystem, whereas Axelar originates from the Cosmos ecosystem. What's the reason for not picking an interoperability infrastructure provider that originates from the EVM ecosystem?
I recall there are 8 interop infra providers that were mentioned in Uniswap's cross-chain bridge assessment process.
what would be an alternative?
What are your thoughts on an interoperability infrastructure provider that does what Axelar does, but has some improvements such as middleware layer with customizable bridging logic, modular architecture and bridge contracts that are generated accordingly to the validated message/payload entering the middleware chain? What do you think?
What are your thoughts on axL-USDC used as liquidity? (from a security perspective)
Questions as part of the Deployment Accountability Committee*
Thank you for the proposal @blockchaincolumbia with Fantom and Axelar team, I would like to ask few questions to provide more information for the Uniswap community.
Questions as part of the Deployment Accountability Committee*
Thank you for the proposal @blockchaincolumbia with Fantom and Axelar team, I would like to ask few questions to provide more information for the Uniswap community.
The deployment and its costs will be borne by the Fantom Foundation and Axelar. As such, no grants or subsidies will be offered to Uniswap. Axelar and Fantom will handle the backend deployment of the smart contracts; however, Uniswap will need to handle the frontend.
When the proposal mentions "Uniswap will need to handle the frontend", does that mean the Uniswap team will need to dedicate its own resources to create a such interface ?
Considering some of popular DEX like Sushiswap and Curve are on Fantom, can the project clarify whether they received grants or liquidity incentive for such onboarding? If they did, what makes Uniswap's case different?
We estimate that 30% of the current DEX volume on Fantom would be routed to Uniswap should deployment occur.
Thank you.
We're in support of this deployment and we look forward towards a multi-chain Uniswap V3 ecosystem!
Prior to a defined cross-chain deployment process being finalized, we think it’s beneficial to use different providers for different deployments for now to gauge each provider’s efficiency and efficacy. Axelar is a leading interoperability spanning across 39 chains and the Fantom ecosystem, where its cross-chain swaps have been integrated by leading DEXes like Spookyswap. Fantom users use Axelar to bridge and onboard from other EVM and Cosmos chains.
Axelar network is a neutral and ecosystem agnostic - decentralized cross-chain messaging layer. Its technology is built on Cosmos SDK and it’s often associated with Cosmos given it powers most of its on/off liquidity between EVM chains and Cosmos chains. Axelar’s general message passing and asset transfers support 39 chains, EVM chains, and Cosmos chains. Axelar’s usage in EVM ecosystems is growing rapidly as seen by the number of messages here.
There are few alternatives, however, we believe Axelar is best suited for the Fantom deployment given its proven technology, track record, and distribution to all other chains. As mentioned in the post, we wouldn’t be opposed to a change in the cross-chain process in the future if the community deems it so.
Axelar already has customizable messaging logic, modular building blocks like developer SDKs and example contracts. Axelar recently introduced a virtual machine layer for customizing connections, security, and speed where developers can build connections using light-clients, zero-knowledge or other technologies that are available. (More here)
This Uniswap deployment does not use axlUSDC. axlUSDC is a wrapped representation of USDC, enabling users to transact the stablecoin across various blockchain networks. Users can access axlUSDC through DEX liquidity pools, cross-chain liquidity routers such as Squid, or via Satellite, a cross-chain bridge built by Axelar. The platform enables composable USDC using its General Message Passing (GMP) capability in collaboration with Circle's Cross-Chain Transfer Protocol (CCTP). Axelar's technical security risk appears to be well-managed, with comprehensive measures to ensure user funds' safety. You can read more about axlUSDC risk assessment here.
Questions as part of the Deployment Accountability Committee*
Thank you for the proposal @blockchaincolumbia with Fantom and Axelar team, I would like to ask few questions to provide more information for the Uniswap community.
Questions as part of the Deployment Accountability Committee*
Thank you for the proposal @blockchaincolumbia with Fantom and Axelar team, I would like to ask few questions to provide more information for the Uniswap community.
The deployment and its costs will be borne by the Fantom Foundation and Axelar. As such, no grants or subsidies will be offered to Uniswap. Axelar and Fantom will handle the backend deployment of the smart contracts; however, Uniswap will need to handle the frontend.
When the proposal mentions "Uniswap will need to handle the frontend", does that mean the Uniswap team will need to dedicate its own resources to create a such interface ?
Considering some of popular DEX like Sushiswap and Curve are on Fantom, can the project clarify whether they received grants or liquidity incentive for such onboarding? If they did, what makes Uniswap's case different?
We estimate that 30% of the current DEX volume on Fantom would be routed to Uniswap should deployment occur.
Thank you.
We're in support of this deployment and we look forward towards a multi-chain Uniswap V3 ecosystem!
Prior to a defined cross-chain deployment process being finalized, we think it’s beneficial to use different providers for different deployments for now to gauge each provider’s efficiency and efficacy. Axelar is a leading interoperability spanning across 39 chains and the Fantom ecosystem, where its cross-chain swaps have been integrated by leading DEXes like Spookyswap. Fantom users use Axelar to bridge and onboard from other EVM and Cosmos chains.
Axelar network is a neutral and ecosystem agnostic - decentralized cross-chain messaging layer. Its technology is built on Cosmos SDK and it’s often associated with Cosmos given it powers most of its on/off liquidity between EVM chains and Cosmos chains. Axelar’s general message passing and asset transfers support 39 chains, EVM chains, and Cosmos chains. Axelar’s usage in EVM ecosystems is growing rapidly as seen by the number of messages here.
There are few alternatives, however, we believe Axelar is best suited for the Fantom deployment given its proven technology, track record, and distribution to all other chains. As mentioned in the post, we wouldn’t be opposed to a change in the cross-chain process in the future if the community deems it so.
Axelar already has customizable messaging logic, modular building blocks like developer SDKs and example contracts. Axelar recently introduced a virtual machine layer for customizing connections, security, and speed where developers can build connections using light-clients, zero-knowledge or other technologies that are available. (More here)
This Uniswap deployment does not use axlUSDC. axlUSDC is a wrapped representation of USDC, enabling users to transact the stablecoin across various blockchain networks. Users can access axlUSDC through DEX liquidity pools, cross-chain liquidity routers such as Squid, or via Satellite, a cross-chain bridge built by Axelar. The platform enables composable USDC using its General Message Passing (GMP) capability in collaboration with Circle's Cross-Chain Transfer Protocol (CCTP). Axelar's technical security risk appears to be well-managed, with comprehensive measures to ensure user funds' safety. You can read more about axlUSDC risk assessment here.
Following the positive bridge assessment of Axelar and the resolvement of Multichain's hiatus, this has been moved to a temperature check here.
Thanks for the proposal @blockchaincolumbia,
We would like to support this proposal, however, we do have some concerns with the recent news/rumours regarding the arrest of Multichain’s developers and the disruption of bridging services.
Multichain is the largest provider of bridged assets to Fantom including almost all popular ERC20 tokens.
Thanks for the proposal @blockchaincolumbia,
We would like to support this proposal, however, we do have some concerns with the recent news/rumours regarding the arrest of Multichain’s developers and the disruption of bridging services.
Multichain is the largest provider of bridged assets to Fantom including almost all popular ERC20 tokens.
Our concern currently, is that there is a possibility that the native underlying tokens sitting within the Multichain bridge will be seized. Therefore, assets bridged on FTM lose their value and Uniswap liquidity providers are hurt as a result.
We understand that this is a risk for most non-native EVM bridge assets across various chains, however, given the size of Fantom's asset exposure to Multichain, waiting for more clarity around the situation could help protect users who want to use an official Uniswap deployment.
Following the positive bridge assessment of Axelar and the resolvement of Multichain's hiatus, this has been moved to a temperature check here.
Thanks for the proposal @blockchaincolumbia,
We would like to support this proposal, however, we do have some concerns with the recent news/rumours regarding the arrest of Multichain’s developers and the disruption of bridging services.
Multichain is the largest provider of bridged assets to Fantom including almost all popular ERC20 tokens.
Thanks for the proposal @blockchaincolumbia,
We would like to support this proposal, however, we do have some concerns with the recent news/rumours regarding the arrest of Multichain’s developers and the disruption of bridging services.
Multichain is the largest provider of bridged assets to Fantom including almost all popular ERC20 tokens.
Our concern currently, is that there is a possibility that the native underlying tokens sitting within the Multichain bridge will be seized. Therefore, assets bridged on FTM lose their value and Uniswap liquidity providers are hurt as a result.
We understand that this is a risk for most non-native EVM bridge assets across various chains, however, given the size of Fantom's asset exposure to Multichain, waiting for more clarity around the situation could help protect users who want to use an official Uniswap deployment.
