Bridging & Messaging Partner for GMX

[coinflipcanada]

1. Who We Are
GMX is a decentralized perpetual exchange offering low-cost, high-speed infastructure. As we expand to new chains and introduce advanced features, we need a secure, scalable bridging and messaging partner to ensure a seamless cross-chain experience for traders and liquidity providers.

2. Why Cross-Chain Matters for GMX

1. Unified Liquidity Across Multiple Chains

• We concentrate core liquidity (network availability) on Arbitrum, enabling users from Base, Sonic, or other chains to transact against this larger pool.
• This boostsl efficiency while limiting risk for Arbitrum-based LPs.

2. Seamless User Experience

• Fast bridging for smaller amounts, straightforward messaging, and minimal manual steps—giving traders a “native-like” feel.
• Reduced friction is key to scaling up usage and adoption.

3. Risk Containment & Scalable Growth

• Local liquidity providers remain protected from cross-chain issues.
• Future expansions to new EVM or non-EVM chains (e.g., Solana, TON) require minimal redeployments or reconfigurations.

3. GMX Safety Reserve & Partner Contribution

1. Security Backstop

• GMX’s Safety Reserve, overseen by the GMX Security Committee, serves as a reserve for major exploits or black swan events.
• Minimum Contribution: Qualifying proposals must include a commitment of no less than $6 million vested over up to 3 years to support the Safety Reserve.
• Please note: This is not an auction. We’re providing clear guidance on our contribution expectations but will still evaluate proposals holistically, including all technical requirements and the terms and nature of the contribution.

2. Dispute Resolution & Transparency

• Any large-scale usage of Safety Reserve funds (e.g., severe exploit compensation) must undergo a governance vote, ensuring open community oversight.
• Regular updates to the community will detail Safety Reserve balances, partner contributions, and any disbursements.

4. Technical Requirements

1. Cross-Chain Bridging for $GMX & Key Assets

• Secure bridging between Arbitrum, Avalanche, upcoming EVM chains covering $GMX, USDC, leading supported stablecoins, wrapped BTCs, ETH and bitcoin LSTs, and GMX’s own GM / GLV tokens.
• Have Solana support and visibility on timelines for TON, to support bridging of $GMX
• A user must be able to bridge funds together with a message in a single transaction to the destination chain, and without requiring the deployment of contracts on the source chain
• A user should also be able to bridge multiple tokens in a single bridge transaction
• Bridging tokens and a message should be supported without requiring a custom contract to be deployed by GMX on the source chains. With an obvious exception for any token contract owned by the GMX DAO to support inter-chain transfers of $GMX other than $GMX.

2. Fast & Flexible Deposits/Withdrawals

• Near-instant bridging for smaller amounts, with more rigorous security checks for large deposits/withdrawals.
• Proposals should include estimates of median cost and time required to bridge $1k, $10k, $100k, $1m for the assets listed in 4.1.a above from reference chains (ETH, BNB, Base to Arbitrum)

3. Messaging & Order Execution

• Address ERC2771 (gasless transactions) and chain reorg scenarios for a reliable user experience.

4. Security & Reliability

• Audited protocols with a proven record against exploits.
• Mechanisms to handle reorgs, message tampering, and complex bridging requirements at scale.
• Ability to use n of m bridges to verify messages to improve security

5. Commercial Collaboration

1. Minimizing Bridging Costs

• Our shared objective is to lower user fees, making cross-chain usage as frictionless as possible over the term of this agreement

2. Safety Reserve Support

• Proposals must include a minimum $6 million vesting contribution over up to 3 years to the GMX Safety Reserve.
• Treasury Swaps (Optional): If relevant, detail any proposed swap (~$1M notional) with at least two-year lockups, noting if either party seeks governance power with these tokens.

6. Proposal Requirements

1. Company Overview: Your background, relevant bridging experience, key achievements or case studies.
2. Technical Outline:

• How you’ll handle bridging + messaging in a single transaction.
• Approach to fallback logic, chain reorgs, partial reverts, etc.

3. Commercial & Safety Reserve Approach:

• Strategies to reduce bridging fees.
• Mandatory: A clear plan to provide at least $6 million in vested support for the GMX Safety Reserve (over up to 3 years).
• Optional treasury swap details (size, lockup, and governance).

4. Timeline & Costs: Projected setup time, ongoing fees, and approach to integrating new chains.
5. Innovation & Unique Features: Special bridging protocols, custom fallback solutions, keeper/relayer integration, etc.
6. Support for bridging multiple tokens in a single bridge transaction (yes / no): For deposits, users would need to send two tokens e.g. WETH, USDC. It would be preferred if these two tokens could be sent using a single bridge transaction
7. Support for bridging tokens and a message in a single bridge transaction without requiring deployment of a contract on the source chain (yes / no): To allow new chains to be quickly supported, it would be preferred that bridging tokens and a message can be done without requiring the deployment of a contract by GMX on the chain which the user is sending funds from
8. Support for using “n of m” bridges for verification (yes / no): This refers to for example, a 2 of 3 bridge, which would involve 3 separate bridges being used to send a message, and at least 2 must independently transmit the message for it to be confirmed
9. Bridging Cost & Speed: Proposals should include estimates of median cost and time required to bridge $1k, $10k, $100k, $1m for the assets listed in 4.1.a above from reference chains (ETH, BNB, Base to Arbitrum)

7. Process & Timeline

1. Proposal Submission (Governance Forum)

• All proposals must be posted on the GMX governance forum by February 21, 2025
• Include all elements in Section 6.

2. Technical & Commercial Review

• GMX core contributors check if proposals meet technical requirements and commit to the $6 million Safety Reserve contribution (plus other commercial criteria).
• Proposals that pass move to community voting.

3. AMA / Q&A Session

• Eligible partners present and discuss their proposals in open AMA sessions, letting the GMX community ask questions or request clarifications.

4. Governance Vote

• Proposals that pass the initial review and AMA process go to a Snapshot vote by GMX governance.
• The community selects the winning partner, with an emphasis on technical merit, security, and overall alignment.

5. Exclusive Negotiation Window

• The chosen partner enters an exclusive window to finalize contractual details and confirm Safety Reserve contributions.
• If negotiations fail, GMX may revisit other eligible proposals.

8. Key Dates

• Tender Release: February 8, 2025
• Proposal Deadline (Forum Submission): February 21, 2025
• Technical Review Complete: February 28, 2025
• AMA/Q&A Sessions: Week of March 3rd
• Governance Vote: March 10 - 17
• Documentation Window Begins: after governance vote
  (Dates are flexible, based on the final schedule.)

9. How We’ll Choose

• Technical Fit & Security: Does your solution integrate effectively with GMX’s architecture and security needs?
• Scalability & Performance: Capacity to handle high volumes, expansions, and fail-safe bridging.
• Commercial & Safety Reserve Alignment: Fee minimization strategy, no less than $6 million Safety Reserve pledge, and other partner commitments.
• Community Governance: While Labs has called for this tender, it does so on behalf of the GMX DAO. Ultimately, the GMX community vote on Snasphot decides which proposal offers the best overall fit.
• Right to modify or cancel: This tender is informal in nature and may result in modification of tender terms, eliminate tender participants, with no commitment to selection or possible selection of no partner. Participants in this tender will receive no compensation, and hold no assurance or commitment provided by the GMX DAO, Labs, Contributors or those involved in the selection process other than this document and any further updates provided.

10. Questions?
    For further clarifications, reach us at:

• Telegram: @coinflipcanada
• Each protocol will have a Tender-specific chat created to support the coordination of information from GMX Contributors. Communication will be routed through these channels and the public GMX governance forum.

Thank you for reviewing this tender. We look forward to receiving your proposal, including your commitment to the GMX Safety Reserve, and building a secure, scalable, and truly frictionless cross-chain experience for the GMX community!

This any submissions are deemed as confidential. They may not be shared without the express permission of an authorised party. Work is subject to full terms and engagement contracts. Nothing in this document is financial or legal advice.

[Alik1975]

Great proposal.Thak you coinflipcanada

[Jonezee]

Look forwarding to seeing various candidates with market-leading interchain solutions present themselves.

[cmrn]

It’d be awesome, in the spirit of decentralization, if the potential partners posted their proposals in public. I understand you’ve already mentioned for them to message you direct, which is fine. Run the tender how you prefer. Just noting for the future, that kind of material, non-public information is super helpful for community members to have.

[insomniac79ac]

The response below is posted on behalf of Castle Capital

We are looking forward to seeing which service providers put their names in the hat. Has GMX reached out to any potential providers about the tender?

Here are also a couple of examples Castle has come across that offer a unified trading experience across multiple chains. They rely on chain abstraction protocols, letting users trade with balances spread across the supported networks:

• VOOI (Built on OneBalance)
  https://app.vooi.io/r/V3GG0OV

• UniversalX (Built on Particle Network)
  UniversalX丨Trade any token, on any chain

We hope the information is useful.

[coinflipcanda]

Clarifications

Submission Date of Friday February 21st has been extended to EOD February 24th

While initial submissions are being made directly to Labs, Labs will coordinate and prior to the commencement of the voting period for evaluation and community questions.

Compliant proposals will be posted in part to the forum, select portions maybe redacted for commercial and trade sensitivity. Reasonable effort will be made to ensure compliance and deviation from the benchmarks of the tender are still confirmable while voting for the preferred vendor for negotiation.

[coinflipcanda]

Process Update

We have been reviewing and discussing the submitted proposals with both the proposers and various market participants. These conversations have led us to refine certain aspects of the original submissions. The informal nature of this tender was intentional, allowing us to incorporate feedback from potential partners and aim for an optimal outcome.

Tender Evaluation (Messaging vs. Asset Bridging)

• Primary Focus on Messaging Bridges
  We will prioritize the award of a partnerships for the messaging bridge that will secure the cross-chain movement of GMX assets ($GMX, GMs, GLV), support expansion to additional chains, and enable cross-chain messaging.
• Combining Messaging and Fast Bridging
  We initially encouraged combining messaging with low-latency bridging for underlying assets (USDC, USDT, ETH, BTC, etc.), prompting multiple protocols to collaborate on proposals due to the distinct skill sets involved. Given the rapidly evolving fast-bridging market (including direct discussions with intent protocols), we believe it is best not to lock into a single asset-bridging partner at this time and instead continue evaluating the best long term solution.
• Future Negotiations
  GMX may still negotiate with a primary bridging partner to offer near-zero cost, low-latency bridging from our target chains. Although such an integration could ultimately involve the messaging partners and that is our preferred outcome, it is not a strict requirement.

Tender Process (Commercials)

• Financial Support & GSR Contributions
  All submitting protocols are committed to providing financial support, minimizing bridging costs, and offering conditional contributions to the GMX Strategic Reserve (GSR), though each with its own terms and conditions.
• Private Commercial Negotiations
  Each protocol has requested that commercial negotiations remain private to better align their proposals with our desired structure. Therefore, protocols will publicly share their technical proposals and ecosystem details, while GMX contributors will provide limited commentary on whether these proposals meet or deviate from our baseline commercial requirements. Contributors will also address community questions about the technical aspects of each proposal.
• Ensuring Commitments to the DAO
  The shortlisted partner will be required to enter into agreements reflecting the commitments and representations made both publicly and privately. Should material deviations occur, we will seek updated approval from the DAO or re-evaluate the process.

Next Steps

• Public AMA
  We plan to hold a public AMA later this week (tentatively Friday) with the protocols that have submitted proposals.
• Snapshot Vote
  We will initiate a Snapshot vote during the week of March 31, 2025, to shortlist a messaging partner.

We appreciate everyone’s continued involvement and feedback throughout this process.

[Raoul]

Hey Everyone, Raoul from Chainlink Labs here to share our technical and ecosystem proposal for a bridging and messaging partnership with GMX. Over the past 18 months the collaboration between the GMX and Chainlink communities has driven massive shared success, and we’re excited to pitch the opportunity to grow this success even wider!

Proposal: GMX <> Chainlink <> Across cross-chain partnership

This proposal aims to establish the Chainlink Cross-Chain Interoperability Protocol (CCIP) as the cross-chain bridging and messaging solution for GMX, in collaboration with Across as the intents-based protocol for fast and low-cost token transfers.

As a key long-time partner, Chainlink has supported the growth of GMX’s trading protocol by providing high-quality, decentralized, and sub-second market data through Chainlink Data Streams—a pull-based oracle network solution. Chainlink currently helps enable highly reliable markets for GMX by securing more than $450M in TVL and $135M in open interest. Integrating CCIP would deepen the alignment between the GMX and Chainlink ecosystems, with GMX benefitting from the fact that adopting CCIP would introduce little-to-no additional trust assumptions or vendor risk given GMX’s ongoing usage of Chainlink Data Streams. There is also a strong alignment between Chainlink and GMX to drive GMX adoption, given our existing relationship, and this proposal to enable GMX to expand to multiple chains is part of a wider collaboration to grow DeFi adoption and usage with GMX.

As part of this proposal, we are collaborating with Across Protocol to combine their experience with intents-based bridging and Chainlink’s battle-tested history of deterministic messaging to create a custom intents-based protocol specifically for GMX, to be built on top of CCIP and leverage its existing benefits. We believe that this solution offers the most robust and performant cross-chain bridging and messaging infrastructure for meeting GMX’s stated requirements.

Chainlink CCIP features the highest level of cross-chain security thanks to its time-tested oracle infrastructure, multiple layers of decentralization, independent Risk Management Network, Token Developer Attestation feature, high-quality node operators, highly audited codebase, and additional security features such as rate limiting and timelocked upgrades. By incorporating a custom, intents-based protocol on top of CCIP, GMX would benefit from CCIP’s best-in-class security and reliability, as well as the enhanced speed and cost-efficiency of intents-based bridging. This unmatched combination of security and speed helps ensure the continued success of GMX as a core pillar of DeFi.

With the CCIP-based intents solution, GMX users will be able to:

• Quickly transfer user funds cross-chain to the GMX Multichain Vault using an intent engine and solvers.
• Securely bridge GMX, GM, and GLV tokens across chains using CCIP, unlocking DeFi and other markets for native GMX assets.

The remainder of this proposal describes how the CCIP-based intents solution meets the current and potential future needs of GMX according to the proposal’s selection criteria.

1. Company Overview

Chainlink is the standard for onchain finance, verifiable data, and cross-chain interoperability. Chainlink launched on mainnet more than a half-decade ago, starting with decentralized data feeds. Since then, Chainlink has become the most widely adopted oracle solution and expanded to a decentralized computing platform featuring a variety of different data, compute, and interoperability services built upon the same battle-tested technological foundation. The Chainlink platform has successfully secured over $75 billion in DeFi TVL at its peak and enabled more than $20 trillion in transactional value since the start of 2022 across 47 blockchain networks.

Supported by Chainlink’s unparalleled levels of security, reliability, and decentralization, CCIP is the interoperability standard for transferring tokens and/or data between any public or private blockchain network. CCIP currently supports 40+ blockchain networks in production, regularly adding additional chains. Notably, CCIP has been adopted as the canonical cross-chain infrastructure for more than 20 blockchain ecosystems, including Sony’s Soneium, Ronin, Botanix, Celo, B² Network, BOB, and many others.

In all, more than 120 DeFi and other protocols have adopted CCIP for cross-chain token and/or data transfers. Chainlink’s deep roots in DeFi are reflected in protocols adopting both its data solutions and CCIP, minimizing trust assumptions by using battle-tested Chainlink DONs. These protocols include:

• Aave, the leading DeFi lending market with $18B TVL, uses Chainlink Price Feeds and integrated CCIP to support its multi-chain expansion by enabling cross-chain governance and native cross-chain transfers of their GHO stablecoin.
• Lido, with $19B TVL, launched Direct Staking, a CCIP-powered cross-chain staking solution that enables users to stake their ETH and receive wstETH directly on L2 networks.
• Solv, with $2B TVL, integrated CCIP, Proof of Reserve (PoR), and Price Feeds for its SolvBTC ecosystem, enabling cross-chain transfers of their LSTs such as SOLVBTC, SOLVBTC.BNN, SOLVBTC.ENA, and others.
• Lombard, with $1.7B+ TVL, adopted CCIP, PoR, and Price Feeds for its LBTC token.
• Usual, with $800M TVL, adopted CCIP, PoR, and Price Feeds for its Usual ecosystem tokens.
• Magpie uses CCIP to secure its $700M ecosystem, including its Eigenpie, Babpie, Cakepie and Radpie ecosystems.
• Liquid Collective, with $210M+ TVL, adopted CCIP for bridging its LsETH liquid staking token to Base.

CCIP is also central to Chainlink’s work with the world’s largest banking and capital markets institutions to enable interoperability between private and public blockchains, as well as allowing tokenized assets to be interacted with through existing legacy infrastructure. Some highlights include:

• Swift, the interbank messaging network used by 11,500+ banks globally, collaborated with Chainlink and 12+ of the world’s largest financial institutions and market infrastructures to successfully demonstrate how Swift member banks can use Chainlink CCIP to transfer tokenized assets across any public/private blockchain. Participants included the DTCC, Euroclear, Clearstream, ANZ Bank, Citi, BNY Mellon, BNP Paribas, Lloyds Banking Group, and SIX Digital Exchange (SDX).
• DTCC, the world’s largest securities settlement system that processes $3+ quadrillion annually, collaborated with Chainlink and 10 of the world’s largest financial institutions to successfully demonstrate how Chainlink CCIP can make mutual fund NAV data available across any public/private blockchain. Participants included Euroclear, Swift, UBS, Franklin Templeton, Wellington Management, CACEIS, Vontobel, and Sygnum Bank.
• ANZ Bank, one the world’s largest banks with $1+ trillion in total assets under management, collaborated with Chainlink to successfully demonstrate how Chainlink CCIP can power the cross-border, cross-chain, and cross-currency settlement of tokenized assets.
• UBS Asset Management, the asset management arm of one of the world’s largest banks with $5+ trillion in total assets under management, and SBI Digital Markets, a subsidiary of Japan’s largest online financial services group SBI Holdings, collaborated with Chainlink to streamline tokenized fund operations by automating fund subscriptions and redemptions with blockchains and smart contracts.

CCIP launched on mainnet in early access in July 2023 and entered general availability in April 2024—following years of rigorous research and development. Since then, CCIP has enabled over $2B in cross-chain token transfers and actively powers $33.6B in Cross-Chain Tokens (CCTs). Unlike other solutions, CCIP usage has grown organically without any artificially-inflated incentivized usage metrics, and more chains, tokens, and dApps are increasingly adopting the protocol.

Across is a leading crosschain Intent-based bridging protocol. Intents enable a fast and cost-effective way for users to transfer value across chains and empower developers to build native seamless crosschain experiences into their dApps. Since going live in 2021, Across has processed over $19B. Its deep liquidity, rapid transfer speeds, and decentralized relayer network helps ensure reliability and efficiency, making it attractive for crosschain transfers. Across’s industry-leading speed is unmatched.

Across has also forged key partnerships:

• Uniswap: Across is integrated directly into Uniswap’s dApp and wallet, allowing users to execute crosschain swaps in a single click. This integration has resulted in over 600M in total volume, giving users a frictionless experience, with zero support tickets recorded since going live in October 2024.
• Optimism: Across is Optimism’s official L2 → L2 bridge and is featured as the default interoperability solution in both the Optimism and Base portals. This partnership ensures seamless and low-cost crosschain transfers across the OP Superchain.
• Arbitrum: Across supports Fast Withdrawals on Arbitrum Orbit chains, leveraging withdrawal times from 7 days to approximately 15 minutes for adopting chains. Integrating Across with Arbitrum Fast Withdrawals creates a symbiotic relationship that enhances capital efficiency and responsiveness in the Orbit ecosystem. Recently, Arbitrum unveiled its ambitious interop roadmap focused on intent-based solutions, in which Across and ERC-7683 are poised to become key enablers.

Beyond bridging, Across plays a key role in shaping the future of crosschain interoperability through its contributions to ERC-7683—an emerging standard for crosschain Intents. Co-created by Across and Uniswap, ERC-7683 offers flexibility in Intent creation and settlement, ensuring projects can adopt the standard while tailoring execution to their needs. While Across is the first crosschain Intents protocol in production today, ERC-7683 is now supported by more than 50 major projects including Arbitrum, Base, Optimism, Offchain Labs, Polygon and ZKsync, among others, additionally the standard has been endorsed by Vitalik.

Since its inception, Across has expanded to support a broad range of blockchain networks, providing seamless connectivity and accessibility for users and developers. Currently, Across supports 19 blockchain networks. With its robust infrastructure, Across is able to rapidly onboard new chains, including stack chains like OP, Orbit, and ZK Stack. Additionally, Across has completed a significant migration to support non-EVM chains.

Across’s decentralized design helps ensure long-term security and reliability. Across’s architecture is built on competitive relayers, creating a naturally decentralized network that provides optimal transaction speed and cost. This helps ensure that Across maintains its fee efficiency across all routes, providing users with a consistent, seamless experience. It is due to this intents-based design that Across can deliver its users a fast bridging experience.

Across’s crosschain intent solution makes the multichain landscape feel like one unified network. By abstracting away the complexities, Across enables users to have seamless crosschain experiences.

2. Technical outline

GMX Use Cases

The intents-based solution described in this proposal will be purpose-built for the use cases most relevant to GMX, with the overarching objective to enable a “native-like” feel for GMX users, but is also flexible enough to evolve with GMX’s needs over time.

The solution is designed to support both the protocol and users across two key use cases:

Use Case 1: Fast Deposits and Withdrawal

The solution is designed to enable users to make deposits from and withdrawals to remote chains with minimal friction via intents to support trading on Arbitrum. In alignment with GMX’s requirements, our solution will support cross-chain transfers of multiple tokens at once.

Use Case 2: Bridging for GMX Native Assets

The solution is also designed to enable cross-chain transfers of GMX, GLV tokens, and other GMX native assets via the Cross-Chain Token (CCT) standard, which will support new use cases for these native assets in the multi-chain DeFi ecosystem.

To enable each of the aforementioned use cases, the proposed solution starts with the deployment of a Router contract, designed with modularity in mind to facilitate support for future upgradability and the avoidance of vendor lock-in. The Router provides a single address/interface for cross-chain requests, including fee estimation. A routing table defines which method (contract) to use for bridging.

At first the routes will include:

1. Across intents for major assets and blockchains supported by Across.
2. Native cross-chain token transfers for GMX issued assets via CCIP and the Cross-Chain Token (CCT) standard.
3. A simple, custom Chainlink-built intent engine to allow for intent filling for assets and blockchains not yet supported by Across.

The below routing diagram is a high-level diagram to explain the modularity-focused approach that informs the rest of the design.

Cross-Chain Intent Architecture

To meet the unique requirements set forth by the GMX community, Chainlink and Across will work together to extend the ERC-7683 framework so it can be used to support a wider set of assets, and executed securely via CCIP. Across will support CCIP as one of its ERC-7683 compatible settlement systems. All GMX transactions will be secured using CCIP in order to maintain the same security and trust assumptions already inherent in the rest of the GMX system.

Additional development is required to enable full integration of solvers affiliated with CCIP token developers. In order to facilitate the best user experience and optionality, the solution will include a Router which enables usage of a proprietary intent system to cover a wider array of assets, including stablecoins, BTC and ETH LSTs/LRTs, and others.

This solution will solve the key challenges of intents-based bridging: maintaining the highest level of security and redundancy while providing users the best possible experience of fast, low-cost bridging across a wide range of assets. This is achieved by leveraging Across’ intent framework, while maintaining the use of Chainlink infrastructure for securing cross-chain messaging.

The solution is custom-designed to enable GMX users on remote chains to interact with the GMX Protocol deployed on Arbitrum with minimal friction and the highest level security, achieving this by incorporating solvers to execute user intents. Deposits will flow through a Router that can select between intent systems based on asset availability. Orders will then be forwarded either to Across intent system or to a custom Intent Engine being built for GMX to handle assets currently not supported by Across.

With this intents-based solution, users will submit their transactions on a source chain, which will transfer funds to an intent engine. Solvers then execute the user’s transaction on the destination chain, triggering the Engine on the destination chain to use CCIP to send a message that will release funds to the solver back on the source chain. This results in the solver being repaid in the tokens they used to execute the user’s transaction. The entire flow is designed to minimize both the transaction time and gas fees for users in the context of Chainlink’s security-first standards.

The solution will have a range of features designed to meet GMX’s requirements, including defense-in-depth security, bundled token transfers and bridging, and ease of deployment. It is planned to also enable incorporation of multiple intent systems in order to quickly be able to adapt to new asset or chain requirements.

As part of the solution, a user will deposit funds on the remote chain and, depending on the asset, the best route will be chosen. Chainlink is collaborating with Across and enabling fulfilment via Across framework as well as the custom built intent solver system in order to support a wide range of assets. This solution is designed to interact with GMX’s planned multi-chain vault by enabling permit flows on the user’s desired remote chain that are ERC-2771 compliant.

The general user flow would work as follows:

1. The user deposits funds on a remote chain.
2. The funds arrive in the GMX vault on Arbitrum within seconds.
3. The user trades via GMX with their vault balance.
4. The user triggers withdrawal from the remote chain via GMX using ERC-2771.
5. The funds leave the vault on Arbitrum and transfer to the user’s wallet on the remote chain.

Deposit Flow:

1. User initiates a deposit sending funds on a remote chain (e.g., Base). User does not need gas on Arbitrum.
2. Router determines intent network based on chain and token.
3. Solver deposits assets for the user into the GMX MultichainVault
4. Solver uses CCIP to issue a message on the remote chain to verify that the intended action took place on Arbitrum, which causes the release of assets from the UserChainIntentEngine on the remote chain to the solver.

Withdrawal Flow

1. GMX initiates withdrawal requests for user specifying destination address and chain.
2. Router determines intent network based on chain and token.
3. Solver repays the user on the destination.
4. Solver uses CCIP to trigger a smart contract to receive repayment on Arbitrum. CCIP issues a message on Arbitrum to verify that the intended action took place on the remote chain, which causes the vault to release the assets to the solver.

Exception Flow (for custom intent engine route):

On either side, the user will be able to trigger an abort by interacting directly with the intent engine on the source chain. CCIP is used to maintain deterministic state transitions between the 2 contracts. This allows the user to signal the desire to abort a bridge transaction, and the cross-chain system to determine if it is safe to pay them back, or if the request has already been filled.

Exception Flow (for Across route):

There are two fallbacks: an expiration or a slow fill. A slow fill means that the Across system fills the user without requiring a relayer to provide the capital. It’s called a slow fill because it requires Across to optimistically verify this fill before executing it, which means the fill happens a few hours after initiation (much longer than a typical fill).

A slow fill happens when the following conditions are met:

• The input token and output token are the same asset.
• requestV3SlowFill is called on the destination chain before the expiration time for the intent.
• The slow fill is executed before any relayer fills it or the intent expires.

In cases where a slow fill can’t or does not happen and a relayer does not fill the intent, the intent expires. Like a slow fill, this expiry must be optimistically verified, which takes a few hours. Once this verification is done, the user is then refunded their money on the origin chains.

The Across fill process is designed so that funds are returned to the user on one chain or another in a couple of hours (less than 8 hours). No user intervention is required.

Cross-Chain Settlement of GMX Assets Via CCIP

Enabling the cross-chain transfer of GMX assets (GMX, GLV, etc) requires a secure messaging protocol to enable the burning and minting (or locking and minting) of assets between chains. Intents alone cannot be used, as Intents-based bridging relies upon tokens already being integrated with a messaging protocol to enable the final settlement of assets. Given the security-sensitive nature of expanding tokens to additional blockchains, only a highly secure messaging protocol can be used.

Given GMX’s existing usage of Chainlink Data Streams and this proposals’ intents-based CCIP-powered solution, enabling the native transfer of a GMX asset cross-chain would be best suited by Chainlink CCIP. The CCIP v1.5 upgrade recently introduced the Cross-Chain Token (CCT) standard, which enables token developers to integrate new and existing tokens with CCIP in a self-serve manner in minutes. CCTs are cross-chain native tokens secured by CCIP, supporting self-serve deployments, full control and ownership for developers, enhanced programmability, and zero-slippage transfers.

CCTs are token logic agnostic, meaning token developers can deploy pre-audited token pool contracts to turn any ERC20-compatible token into a CCT or deploy their own custom token pool contracts for bespoke token use cases. CCTs do not require token developers to inherit any CCIP-specific code within their token’s smart contract.

With the CCIP Token Manager, developers can manage ownership of their token contracts, CCIP token pools, lane expansion, and customized implementation logic, including rate limits across chains. The autonomy of CCTs eliminates the need for vendor lock-in, hard-coded logic, or external dependencies, allowing developers to customize functionality without compromising security.

CCIP supports multiple methods of transferring tokens cross-chain in a capital efficient manner including the following which can support GMX, GLV tokens and other GMX native assets:

• Burn and mint—Tokens are burned on a source chain, and an equivalent amount are minted on a destination chain. This enables the creation of cross-chain native tokens with a dynamic, unified supply across chains.
• Lock and mint—Tokens are locked on the chain they were natively minted on, and an equivalent amount of tokens are minted on a destination chain. These minted tokens can be transferred across other non-native destination chains via burn-and-mint or be burned to unlock tokens back on the original minting source chain.

We are happy to support the GMX community in pursuing whichever path it chooses in terms of a front end for its users to initiate cross-chain transfers. CCIP already powers a growing number of bridging front ends, including Interport Finance, OpenOcean, Transporter, and XSwap. CCIP v1.5 also introduced the CCIP SDK, which makes it even easier for protocols and application developers to build custom front-ends powered by CCIP, which can be housed directly on the GMX front end.

3. Bridging Cost & Speed

Intents-Based Bridging

In the vast majority of situations, a user’s funds will arrive in the GMX vault on the destination chain after one block confirmation on the source/remote chain. The speed of a user’s transfer will be case-by-case based on the source chain. For example, during high congestion on the Ethereum L1, the solvers may wait for 3 blocks instead of the standard one block confirmation to avoid block reorg risks. This is the same for all of the value categories mentioned in the tender.

For example:

• Base > Arbitrum

• • Current blocktime: 2 seconds (Expected upgrade in Q2 2025 to reduce blocktime to 0.2 seconds)
• • Estimated e2e latency: 3 seconds

• Sonic > Arbitrum

• • Current blocktime: 0.5-1 seconds
• • Estimated e2e latency: 2 seconds

• Ethereum > Arbitrum

• • Current blocktime: 12 seconds
• • Estimated e2e latency: 13 seconds

• BNB Chain > Arbitrum

• • Current blocktime: 3 seconds
• • Estimated e2e latency: 4 seconds

The proposed solution supports the following assets, enabling a wide range of collateral for GMX users:

Issuer	Token	Category
Circle	USDC	Stablecoin
Tether	USDT	Stablecoin
Aave	GHO	Stablecoin
Usual	USD0	Yield-bearing stablecoin
Usual	USD0++	Yield-bearing stablecoin
BitGo	wBTC	Wrapped BTC
Solv	SolvBTC	Wrapped BTC
Solv	SolvBTC.BBN	Yield-bearing BTC
Lombard	LBTC	Yield-bearing BTC
Ethereum	wETH	Wrapped ETH
Lido	wstETH	Liquid Staking ETH

The cost for the transfer of each of these assets via Intents are as follows:

Deposits

• USDT/wBTC: (i) 2-3bps charged by the solvers, including Across; (ii) gas cost on source chain
• All other assets: (i) 1-2bps charged by the solvers, including Across; (ii) gas cost on source chain
• $0.05 flat fee on all transactions, as requested by the solvers to be financially viable when solving small transactions (below $100).

Withdrawals

• USDT/wBTC: (i) 2-3 bps charged by the solvers, including Across; (ii) gas cost on source chain
• All other assets: (i) 1-2bps charged by the solvers, including Across; (ii) gas cost on source chain
• Note: For withdrawals to Ethereum, there will be a separate destination gas fee of ~$0.60 (under a 1 gwei gas environment). This is subject to changes in the gas environment.

These fees will be paid for by the user in the same token being transferred. More details are provided in the “5. Commercial Approach” section below to lower the cost for the end users.

CCT Transfers

When transferring CCTs cross-chain, users pay a single fee on the source chain that covers the estimated gas costs of executing transactions via CCIP on the destination chain along with an additional flat fee. The flat fee rate varies based on the token pool mechanism used and the chain lanes used, ranging between $0.225 - $0.25 for non-Ethereum lanes. Fees can be paid in blockchain gas tokens, or in LINK for a discount. The flat fee is the same rate regardless of the amount transferred. There are no set-up fees or ongoing fees when integrating CCT.

More information on CCIP billing and fee payments can be found in the CCIP Billing Documentation.

4. Innovation & Unique Features

The solution will introduce a unique design that combines faster-than-finality solver-driven transactions with the industry-leading security of CCIP. In addition to incorporating a highly secure cross-chain protocol (CCIP) as a fallback to the IntentEngine, it will also benefit from the ongoing investments in research and development around CCIP that have led to a growing list of innovations including the Risk Management Network, Programmable Transfers, configurable rate limits, token developer attestations, and now intents-based bridging.

5. Commercial Approach

To further reduce the cost for the end users, we will be committed to the following initiatives:

Waiver of development cost

Development cost of the custom solution will be covered by Chainlink Labs, as part of the growing alignment in driving GMX adoption under the ongoing fee sharing agreement related to the use of Chainlink Data Streams.

Agreements with partners to lower cost or provide subsidy

There are expected to be agreements established with selected asset issuers to provide liquidity of their assets to solvers, helping ensure a cost-competitive solution for GMX users.

Active monitoring of solver network’s cost competitiveness

There will also be periodic reviews on the cost competitiveness of the solver network. Given a proven history of substantial volume and efficient markets, the solver network will naturally grow and it should be possible to reduce the user cost over time to fast fill GMX bridge requests.

6. Timeline

The proposed solution is designed to support all requested chains while enabling seamless expansion to new chains with minimal integration work. While each chain expansion will have its own requirements, the core technical needs remain consistent:

• Deployment of Router & Intent Engine – A Router and Intent Engine to support a wider range of assets will be deployed on both the source and destination chains to coordinate solvers.
• Solver Compatibility – Solvers are required to operate on new chains. If additional solvers are required, we will collaborate with GMX to expand solver availability.
• CCIP Availability – CCIP is now live on 40 chains, with ongoing expansions. CCIP’s Solana integration is in development and expected in the coming months. For additional chains such as TON, we will work with GMX to prioritize as needed.

To ensure a smooth transition, we recommend the following phased approach as the implementation plan:

Phase 1: Initial Deployment (2-3 Months)

• Deliver a custom CCIP-based intents solution to GMX.
• Finalize integration with the solver network to facilitate cross-chain execution.
• Route selected assets via the Across Framework once secured by CCIP.

Phase 2: Expansion & Optimization

• Continuous Chain Expansion – Work with GMX to prioritize and integrate additional chains as needed.

• Infrastructure Enhancements – Expand solver network capabilities, supporting both permissioned and permissionless solvers for assets which are not supported by Across.

• Further Decentralization & Flexibility – Implement mechanisms to enhance solution decentralization.

We look forward to collaborating with GMX on these phases and will share additional details as development progresses.

7. CCIP Architectural Design

Chainlink CCIP serves as the foundation of the solution proposed to be used by GMX. CCIP is underpinned by Chainlink’s proven Decentralized Oracle Network (DON) architecture where multiple oracle nodes come to distributed consensus. DONs in the Chainlink ecosystem are operated by a geographically distributed collection of Sybil-resistant, security-reviewed node operators with significant experience running mission-critical infrastructure across Web2 and Web3.

Rather than operating as a single monolithic network, which can lead to speed and reliability issues due to constrained throughput, CCIP is composed of multiple DONs per chain lane—with each lane consisting of a unique path between a source chain and destination chain. This approach allows CCIP to scale horizontally, as additional DONs are added to CCIP for each additional blockchain network supported as opposed to funneling all cross-chain traffic through a single network.

Each CCIP chain lane consists of three unique oracle networks—the Committing DON, the Executing DON, and the Risk Management Network. The Committing DON is a decentralized network of oracle nodes that monitor events on a given source chain, wait for source chain finality, bundle transactions to create a Merkle root, come to consensus on that Merkle root, and commit that Merkle root to the destination chain. The Executing DON is a decentralized network of oracle nodes that submit Merkle proofs on a destination chain, which are then verified onchain by ensuring that the transactions were included in a previously committed Merkle root, which was also validated (aka “blessed”) by the Risk Management Network.

The Committing DONs and Executing DONs in CCIP are composed of 16 high-quality independent node operators, while the Risk Management Network is composed of 7 distinct node operators (resulting in a total of 23 node operators). More information about the architecture and security model of CCIP can be found in the Chainlink documentation. Our real-time, public-facing dashboard for CCIP can be accessed at CCIP Explorer | Chainlink.

Risk Management Network

The Risk Management Network is a separate, independent network that continuously monitors and validates the behavior of CCIP, providing an additional layer of security by independently verifying cross-chain operations for anomalous activity. The Risk Management Network utilizes a separate, minimal implementation of the Chainlink node software, creating a form of client diversity for increased robustness while also minimizing external dependencies to prevent supply chain attacks.

The Risk Management Network was written in a different programming language than the primary CCIP system, developed by a different internal team, and uses a distinct non-overlapping set of node operators compared to the CCIP DONs. The Risk Management Network is a wholly unique concept in cross-chain interoperability that builds upon established engineering principles (N-version programming).

To increase the security and robustness of CCIP, the Risk Management Network engages in two types of activities:

• Secondary Approval: The Risk Management Network independently recreates Merkle roots based on transactions from the source chain, which are then published on the destination chain and compared against the Merkle roots published by the Committing DON. Cross-chain transactions can only be executed if the Merkle roots from the two networks match.

• Anomaly Detection: The Risk Management Network monitors for abnormal behavior from the CCIP network (e.g., committed transactions with no source chain equivalent) as well as the behavior of chains (e.g., deep block reorgs). If anomalous activity is detected, the Risk Management Network can trigger an emergency halt to pause all CCIP lanes and limit any losses.

Security Audits and Source Code

Security is the number one priority for the Chainlink ecosystem, a value we do not and will not compromise on. Chainlink Labs has put an immense amount of resources into developing the security model of CCIP, and as such, is the most audited Chainlink solution to date.

The onchain and offchain code for CCIP and the Risk Management Network underwent a total of 28 independent audits by five leading security firms—Cure53, Dedaub, NCC Cryptography Services, Sigma Prime, and Trail of Bits—in preparation for the initial mainnet launch and subsequent deployments. Copies of all completed independent audit reports can be provided separately for review.

Additionally, four crowdsourced audits of CCIP and the Risk Management Network have been conducted on the Code4rena and CodeHawks platforms:

• CCIP and Risk Management Network

• CCIP Administration Contracts

• CCIP v1.5

• CCIP v1.6

All valid findings were remediated and fixes confirmed with the respective auditors. In some cases, findings represented expected behaviors and were reviewed with auditors upon receipt of audit reports.

The onchain source code for CCIP is publicly viewable on GitHub:

• Cross-Chain Interoperability Protocol
• Risk Management Network
• CCIP Owner Contracts

Finally, CCIP is covered by the Chainlink bug bounty program on Immunefi, with a $3 million maximum bounty for critical smart contract vulnerabilities.

Security and Reliability

In keeping with Chainlink’s defense-in-depth approach to security, the solution incorporates multiple mechanisms beyond those already built into CCIP in order to protect protocols and users.

As in intents-based protocol, solvers are responsible for managing and underwriting costs related to finality risks (i.e., block reorgs) on behalf of users. In exchange for taking on this risk, solvers are compensated in the form of a small percentage based fee derived from the amount of value transferred cross-chain.

At the architectural level, the solution incorporates CCIP as a fallback in the event solvers are unable to fill a user’s transaction on the destination chain. Should this happen, the intents-based solution will switch to failover mode, passing the user’s instruction to abort the transaction from the source to the destination chain via CCIP, along with an acknowledgement back to the source chain. Afterwards, the funds will be released back to the user on the source chain. CCIP is designed with a security-first approach emphasizing determinism above speed or cost. Settlement doesn’t need to be fast and transactions can be batched to reduce message counts. CCIP messages are used to enable secure settlement of fast fulfilled transactions, which combines industry leading security with lightning-fast UX.

Native m-of-n Bridge Support

CCIP’s defense-in-depth architecture provides its own version of m-of-n bridging through the use of multiple independent decentralized oracle networks (DONs), as described previously.

The intents-based solution will also be built to provide all the necessary functions with little-to-no additional trust assumptions. It is built to combine the fast finality from leading solvers with the battle-tested security of CCIP. Multi-bridge aggregation models that combine different bridge providers for settlement, by contrast, increase rather than reduce the attack surface for a protocol by introducing heterogeneous risks that dilute the security of the overall system, effectively reducing its security to that of the weakest component. Incorporating multiple bridge providers also significantly increases monitoring and maintenance costs as well as user fees, while also reducing both the composability of assets and the ease of programmatic transfers.

Combining Messaging and Bridging

Chainlink CCIP was built from the outset to enable the simultaneous transfer of both tokens and messaging. This capability, called Programmable Token Transfers, enables smart contracts to transfer tokens cross-chain along with instructions on what the receiving smart contract should do with those tokens once they arrive on the destination chain. Users can send tokens, arbitrary data, or tokens and arbitrary data via CCIP with the same interface. This capability is built into every chain integration with CCIP.

The intents-based solution for GMX is similarly designed to bundle both tokens and data, though the mechanisms specific to high-speed transactions are slightly different. Solvers within the intent infrastructure execute fulfillment in all directions. The user’s CrossChain request will emit an event including the Router address and calldata to be executed. The solver will fund and execute the transaction on the other side.

8. Conclusion

This proposal presents a CCIP-based intents solution for the GMX ecosystem, enabling the secure, fast, and low-cost transfer of tokens/data cross-chain to expand the use of GMX on remote chains. By combining CCIP’s battle-tested security with Across’ intents-based bridging, the GMX community will be able to benefit from GMX’s deep liquidity on Arbitrum while transacting on remote chains.

The use of CCIP would build upon GMX’s existing use of Chainlink Data Steams for low-latency market data, introducing little-to-no additional trust assumptions for users as it operates on the same battle-hardened Chainlink platform that already secures tens of billions in DeFi TVL and has enabled trillions in transaction value. GMX would also benefit from the solution’s support for high configurability and ability to adapt to new intent systems and solvers over time to prevent fragmentation.

We look forward to expanding our collaboration with the GMX community and driving toward the creation of a truly open, low-friction, and interoperable DeFi economy.

Disclaimer

Chainlink Labs’ work is offered “as is” without representations, guarantees, or warranties of any kind, on a commercially feasible basis and subject to GMX’s acceptance of the Chainlink Labs terms of service and the Chainlink Foundation terms of service. The benefits are solely being made available to GMX and not to any other party.

[Jonezee]

Thank you for sharing that very elaborate proposal for how a GMX <> Chainlink <> Across partnership could help solve GMX’s Multichain ambitions, Raoul

[LayerZeroLabs]

GMX x LayerZero Partnership Proposal

1 | Company Overview

Founded in 2021, LayerZero is the leading interoperability solution, securing over $100 billion in assets across a vast network of blockchain ecosystems. LayerZero is leveraged by a diverse range of industry leaders, from DeFi protocols expanding their total value locked (TVL) across multiple chains to institutions utilizing its technology for tokenization and seamless cross-chain interoperability. As the most widely connected interoperability protocol, LayerZero enables value transfer across more than 120 chains, including Solana, TON, Aptos, and all major EVM-compatible networks.

LayerZero is trusted by leading institutions and DeFi protocols to facilitate secure and scalable cross-chain liquidity movement and messaging. Notable implementations include:

• USTD0: LayerZero powers USDT0’s cross-chain interoperability using the OFT standard, enabling seamless transfers across ecosystems. This also connects to legacy USDT via the Legacy Mesh, bridging liquidity between Ethereum, Tron, TON, and Arbitrum. Using Arbitrum as a hub, USDT holders can seamlessly access the USDT0 network and emerging ecosystems like Ink and Berachain, reducing fragmentation and enhancing capital efficiency.
• PayPal: PayPal integrated LayerZero’s OFT standard to facilitate cross-chain functionality for PYUSD, ensuring secure and standardized transfers between Ethereum and Solana. To meet NYDFS compliance requirements, LayerZero extended its Decentralized Verifier Network (DVN) model to incorporate custom blacklist functionality, rate limiting, and other security controls, allowing PayPal to maintain full regulatory oversight of its asset.
• BitGo: BitGo implemented LayerZero’s OFT Standard to upgrade wBTC – addressing wBTC’s primary challenge: fragmented liquidity caused by different versions of wBTC existing across multiple chains. Within six months, wBTC has expanded to Base, Avalanche, BNB, Berachain, Unichain, Sei and many more. The OFT implementation unified liquidity across all supported networks, eliminating the need for wrapped assets, enhancing security and scalability for wBTC holders.
• Ondo: As the issuer of USDY, one of the largest RWA-backed stablecoins, Ondo selected LayerZero to enable cross-chain transfers across Ethereum, Arbitrum, and Mantle, with further chain expansions planned for 2025. Security and operational control were critical factors in Ondo’s decision, as LayerZero’s OFT framework provides rate limiting, pausing mechanisms, and a dedicated DVN structure to verify all USDY transactions.
• Ethena: Ethena adopted LayerZero’s OFT standard to expand USDe, sUSDe, and ENA across 10 ecosystems, achieving over $2 billion in cross-chain transaction volume. USDe’s rapid growth highlights LayerZero’s ability to facilitate scalable, compliant, and efficient cross-chain movement, with built-in security features such as blacklisting and controlled access mechanisms ensuring seamless asset management.
• Boyco: Royco, Berachain and LayerZero recently coordinated to run a predeposit OFT vault campaign for Bera, collaborating to create Boyco Markets. These vaults attracted over $2.2B in pre-deposit funds from partners such as Ethena, Etherfi and Solv. Berachain combined these vaults with an OFT-powered bridge; in total, the two were responsible for over $3.2B in day-one OFT deposits, all of which went through 100% seamlessly.
• And hundreds more: Usual Money, Resolv, Swell, MIM, Anzen Finance, Maple Finance, Avalon Finance, Schuman Financial, Kelp DAO rsETH, Mantle cmETH, Frax Finance, PancakeSwap, Radiant, CORE, Pendle, Angle Protocol, Clearpool, StakeStone, BTC.b, Superform, ApeCoin, Dinero, etc.

2 | Technical Outline

LayerZero is a network of smart contracts, not a blockchain, designed to provide immutable, censorship-resistant, and permissionless interoperability across chains. The protocol is highly secure, extensively audited, and battle-tested, with the second-largest bug bounty in the space. Unlike traditional cross-chain solutions, LayerZero’s core protocol is immutable, meaning that once deployed, it cannot be altered or upgraded, eliminating the primary attack vector for the majority of cross-chain exploits.

For GMX, this means operating on an interoperability layer that is entirely controlled by GMX, with a bespoke configuration for verification and execution, similar to how PayPal and Ondo Finance have structured their deployments. GMX retains full autonomy over how cross-chain transactions are validated and executed, ensuring security, reliability, and control over its assets and messaging.

Security & Mitigating Chain Reorgs

Given LayerZero’s architecture, GMX has full configurability over its cross-chain interactions and can leverage multiple features to mitigate against block reorgs and other concerns. The protocol is highly configurable, allowing GMX to:

• Define source chain finality by setting the exact number of block confirmations required before a message is accepted on the destination chain.
• Choose the verification model, selecting a specific set of Decentralized Verifier Networks (DVNs) to approve messages.
• Implement rate limits to prevent unusual transaction activity from impacting liquidity or order execution.
• Customize execution logic to define how transactions behave under different conditions, ensuring deterministic and predictable cross-chain operations.

Additionally, GMX can enforce either unordered or ordered message delivery, giving developers the flexibility to optimize sequencing and execution based on their application needs.

It is also worth highlighting that LayerZero’s protocol design ensures that no messages can be lost, and no value can be tampered with in cross-chain transactions. Since the protocol is stateless, even in cases of network congestion or reorgs, messages may be delayed but are always successfully processed once conditions are met.

Solutions for GMX Built on LayerZero

LayerZero’s protocol enables seamless bridging, messaging, and execution of GMX-specific use cases. Below are the solutions tailored to GMX’s requirements:

1. $GMX as an Omnichain Fungible Token (OFT)

LayerZero does not enforce a specific token standard for cross-chain transfers, but the Omnichain Fungible Token (OFT) Standard is recommended—an extension of ERC20 and non-EVM equivalent—designed to meet GMX’s stated requirements. This common interface across all chains ensures ease of use while allowing for bespoke customizations, making it a seamless yet powerful standard for cross-chain asset transfers.

The OFT standard is the best-in-class model for bridging native assets across chains while maintaining full security, interoperability, and control. GMX has multiple options for implementing $GMX as an OFT:

• Native GMX Deployments on New Chains
  • Direct mint-and-burn functionality on new chains like Solana and TON, ensuring seamless movement of $GMX while keeping supply integrity.
  • GMX controls contract ownership and supply logic across all deployed networks.
• Mint-and-Burn Adapter Contracts for Existing Chains
  • On Arbitrum and Avalanche, where GMX is already live, adapter contracts can be deployed on LayerZero to interface with existing GMX contracts.
  • These contracts call burn and mint functions on the native GMX token contracts, ensuring native-level bridging without reliance on third-party wrappers or liquidity pools.

By utilizing the OFT standard, $GMX will benefit from the following:

• Universal Composability: Seamless interaction with smart contracts across all LayerZero supported chains.
• Unified Liquidity: A globally connected supply that eliminates liquidity fragmentation across chains.
• Security and Trust: Cross-chain communication with customizable validation through DVNs.
• Streamlined Inventory Management: Efficiently handle supply rebalancing without the need for traditional offchain third parties, inventory across multiple chains can be rebalanced permissionless via the LayerZero protocol for the price of gas vs. OTC or other permissioned methods.
• Customizable Fee Structures: Tailored fee models to optimize transfers and incentivize usage/flows.

2. Interoperability for GM Tokens & Issuers on GMX

If GMX intends to support issuers creating GM tokens that are natively interoperable, multiple LayerZero-powered solutions can be implemented:

• General Message Passing: Allows GMX to provide fully custom logic for messaging between chains, useful for governance or execution instructions.
• OFT for GM Tokens: Similar to $GMX, GM tokens issued on GMX’s platform can follow the OFT standard, which will benefit from the features mentioned above.
• Intents Model on LayerZero: If GMX seeks to enhance order execution and cross-chain interactions, an intents-based system can be built on LayerZero to execute trades, settle orders, or handle protocol transactions seamlessly across multiple chains.
• Liquidity Based Bridges: Stargate is an omnichain liquidity protocol built on LayerZero that facilitates the transfer of value across blockchains. Stargate allows users to transfer assets in a fully composable manner with unified liquidity. By leveraging LayerZero’s technology, Stargate ensures deep liquidity, minimal slippage, and seamless interoperability for DeFi applications, making it a possible solution for GM tokens and Issuers. Stargate has expressed interest in partnering with LayerZero here to best serve GMX.

3. lzRead and Governance

lzRead extends the existing omnichain messaging protocol to enable developers to not only send cross-chain messages, but also request and retrieve on-chain state from other supported blockchains.

This is particularly relevant to GMX holders in regard to cross-chain governance. LzRead is capable of retrieving voting power across any number of chains, allowing token holders to vote once on any chain, significantly simplifying cross chain governance. Agora has built a multichain governance module using lzRead, which could be made custom to fit GMX’s selected use case. This would be a joint collaboration between GMX, LayerZero and Agora.

Alternatively, custom governance solutions can also be designed and implemented utilizing lzRead, such as round-robin voting or other.

Each of these solutions provide exciting avenues for GMX, and will help in not only expanding the protocol to new ecosystems, but in functionality also. LayerZero is fully committed to scoping each of the solutions out with the GMX team directly to identify and implement the ideal solution for GMX.

3 | Bridging Fees and Costs

Reducing bridging fees

In regard to transferring $GMX as an OFT, the user will only ever be charged the gas fees, with no BPS attached. The gas cost for transferring GMX can of course be optimised to be as cheap as possible without introducing the risk of insufficient gas and inflight transaction failures.

Additionally, GMX can elect to run its own DVN for all GMX transfers, adding a level of protocol-owned security and control over cross-chain verification costs. Operating a DVN in-house is one way to decrease or eliminate any fees paid to outside parties.

DVNs also receive retroactive rewards in $ZRO tokens, distributed quarterly based on their performance metrics. Since all GM assets including GMX could use this DVN, it introduces a direct and transparent mechanism for redistributing the fees to users.

Costs

Development and deployment: $0

Co-marketing: $0

DVN pathway costs: Completely configurable depending on the DVN setup GMX selects. To send a message using LayerZero, users only pay gas from the source chain because of the unique gas abstraction service the executor runs. Below is a chart demonstrating the sample cost of passing a message using LayerZero v2 between a few widely-used pathways, featuring a 2-DVN setup of LayerZero Labs and Google:

• This is what it costs to send any message through these specific pathways, completely separate from dollar amount (fees don’t scale with volume bridged)
• The cost of any transaction equates to the cost of signing for a single message on each respective chain
• Projects that use LayerZero can customize their fee/security structure by choosing between 43 different DVNs, 42 of which are run by independent third parties such as Google, Polyhedra, Blockdaemon, and more
• GMX could choose to implement a bridging fee in the OFT contract logic if they so desired

4 | Timeline

Working Timeline

Milestone	Target Date	Status	Notes
Submission Deadline	2/21	In progress	GMX proposal window closes
Technical Review Complete	2/28	Not started	GMX concludes technical review
Governance Vote	3/31	Not started	GMX holds governance vote to determine interop provider
Working Plans & OFT Design	4/7	Not started	Outline scope of work, design and finalize OFT contract architecture
Co-marketing Planning	4/14	Not started	Discuss social media support thru X and Discord
Partnership Announcement	4/21	Not started	Announce the omnichain partnership between GMX and LayerZero
Phase 1 Deployments	4/24	Not started	Deploy OFT Contracts for Arbitrum, Avalanche, and other desired day-1 chains, with immediate bridging enabled
Phase 2 Planning	TBD	Not started	Discuss future OFT deployments to further chains, including non-EVM networks like TON and Solana
Phase 2 Deployments	TBD	Not started	Deploy OFT Contracts for additional chains, with co-marketing support

5 | Innovation and Special Features

LayerZero Messaging Features

Native Gas Drop

LayerZero’s native gas drop feature allows developers to include a specified amount of the destination chain’s native token in cross-chain messages. This creates a much improved developer experience by ensuring that the recipient contract or address on the destination chain receives the necessary funds to cover transaction fees or other operations, even if they don’t already hold the native token of that chain.

Message Design Patterns

LayerZero enables developers to configure any type of message design pattern, going beyond the standard source-to-destination (AB) pattern.

• ABA: a nested send call from Chain A to Chain B that sends back again to the source chain (A → B → A)
• Batch Send: a single send that calls multiple destination chains.
• Composed: a message that transfers from a source to destination chain and calls an external contract (A → B1 → B2)
• Composed ABA: transfers data from a source to destination, calls an external contract, and then calls back to the source (A → B1 → B2 → A)
• Message Ordering: enforce the ordered delivery of messages on execution post verification.
• Rate Limit rate limits the number of send calls for a given amount of messages or tokens transferred.

lzRead

lzRead is a request-response (i.e. query) data primitive built on LayerZero that enables seamless access to any on-chain data from any supported network with a single function call. It allows applications to retrieve, map, reduce, (i.e. compute) and securely deliver on-chain data while leveraging LayerZero’s existing immutable Endpoint and modular DVN infrastructure.

lzRead is already live on production mainnets, powering use cases such as:

• Wintermute & Chaos Labs – Wintermute’s prediction market for the U.S. presidential election used Chaos Labs’ oracle and lzRead to query results across multiple chains.
• Bored Ape Yacht Club (BAYC) – NFT collections use lzRead to read Ethereum ownership data from ApeChain.
• Azuki – Enables verification of Azuki NFT ownership on Ethereum L1 for claims on Anime Chain.
• LayerZero ZRO Referendum – Aggregates ZRO voting power across all chains, allowing users to vote once from any chain.

SyncPools

LayerZero’s Sync Pool architecture simplifies cross-chain liquidity management by securely synchronizing assets across different networks. It achieves this by using LayerZero messaging to keep the circulating supply on L2s in sync with the collateral pool on Ethereum, allowing assets to be issued on L2 quickly. At the same time, it batches user deposits on L2 to reduce transaction costs and leverages native L2 bridges for secure asset transfers. This solution is live and powers EtherFi’s weETH native L2 restaking.

Research

QMDB

Quick Merkle Database (QMDB) is a high-performance, verifiable database optimized for blockchains, offering significant advancements in scalability and performance. Highlights include:

• 2.28M state updates per second, 1M TPS (benchmarked transfers per second).
• Benchmarked with workloads up to 15B (10x Ethereum’s 2024 state) and proven capacity to scale to 280B entries on a single server.
• Single read per state access, O(1) I/O for updates, and in-memory Merkleization on a footprint as small as 2.3 bytes per entry.
• Efficiently scales across both consumer grade and enterprise hardware.
• Unlocks many novel use cases like historical proofs and real time ZK proof generation.

Delta Algorithm

The Delta Algorithm efficiently manages cross-chain liquidity by maintaining a unified pool on each blockchain, virtually divided into segments allocated to other connected chains. This dynamic allocation ensures that liquidity is available where needed, enabling seamless native asset transfers with instant guaranteed finality. The algorithm continuously monitors and adjusts these virtual partitions, redistributing funds to address any deficits and maintain balance across the network. This approach enhances capital efficiency and simplifies cross-chain transactions without relying on wrapped tokens. The Delta Algorithm is used by Stargate, one of the largest bridges in the industry.

Color Algorithms

LayerZero Labs solved the colored coins problem with the invention of a family of Color algorithms. Each algorithm solves the colored coins problem but with different variations. These coloring solutions are a way of tagging or marking a token’s metadata to identify from whom the tokens originate – precisely tracking a token’s lifecycle and associated on-chain activity. This unlocks accurately tracking fungible token ownership history: where, when, and by whom they were created and owned. Additionally, it enables pro-rata attributions, i.e., yield distributions, to holders of certain marked tokens, and creates a publicly transparent system where participants are fairly rewarded across blockchain ecosystems.

6 | Support for Bridging Multiple Tokens in a Single Bridge Txn (yes/no)

Yes, multiple tokens, such as WETH and USDC, can be bridged in a single bridge transaction using LayerZero as the messaging layer. Here is an example that bridges MOR and WETH from Arbitrum to Optimism in a single LayerZero message.

Liquidity bridging protocols built on top of LayerZero, such as Stargate have started to support GMX assets and bridging multiple in a single bridging transaction.

7 | Support for Bridging Tokens and a Message in a Single Bridge Txn without deployment of a contract on the source chain (yes/no)

It is possible to bridge message data and tokens in a single bridge transaction using LayerZero via a Composed Message; however, to handle a Composed Message on the destination chain using LayerZero’s protocol, there needs to be an additional Composer Receiver contract on the destination chain. The Composer Receiver contract is the contract interface to handle receiving the Composed Message and the custom business logic via the lzCompose. We strongly believe that all applications should own their specific Composer Receiver contracts or revoke ownership / burn the keys. We will work closely with GMX to gather requirements and fully scope out the most optimal solution and any related processes on behalf of the DAO’s implementation preference.

8 | Support for using “N of M” Bridges for Verification (yes/no)

Yes. LayerZero pioneered the concept of Decentralized Verifier Networks (DVNs) - entities that check the payload hash of an emitted message, ensuring the security of every cross chain transaction. LayerZero runs one of the 40+ DVNs, joining other third parties like Google, Blockdaemon, Nethermind, Polyhedra (ZK proof), Axelar (entire validator set), and many others. This modular security architecture allows for applications to run their own DVNs as well if desired to own the security infrastructure.

For GMX, this means the option of configuring their stack to utilize the CCIP, Axelar, and LayerZero DVNs if desired.

Note: The example OApp in the figure above has set their configuration threshold to have a total of 3 DVNs with 1 required DVN and 1-of-2 optional DVNs, needing 2-of-3 DVNs to verify their messages. The configured DVN threshold can be expanded out to any number of DVNs in a X-of-X and/or X-of-Y model.

9 | Bridging Cost & Speed

Cost

Because LayerZero works by passing data between a source and destination chain, only one chart is necessary to show the cost of bridging any OFT in any amount, whether a user is sending $10 or $10m of value between chains using USDT0, sUSDe, WBTC, or any other OFT. This can vary depending on the selection & number of DVNs used in an OFT’s specific security configuration, but here’s an example of what these pathway-specific costs would look like using a 2-DVN setup of LayerZero Labs and Horizon or Nethermind depending on the pathway:

Speed

This total median time until finality would vary depending on the specific DVN setup GMX chose to use for message verification, but across all of our pathways, the median time to pass a message between GMX’s specified chains is as follows:

10 | Final Thoughts

Due to a multitude of factors, we believe LayerZero to be the single best option for interoperability for GMX. The permissionless, immutable, and censorship-resistant nature of LayerZero makes it the most secure, decentralized, and modular message-passing protocol in defi, and with over 120 supported chains and over $100B in token value currently secured, our ecosystem continues to expand every day. LayerZero is extremely excited at the prospect of joining GMX in its quest to take both its token and platform omnichain.

[Jonezee]

Thanks for sharing your proposal.

[axelar-wormhole]

Proposal: GMX Token Bridge & Stablecoin Bridge Powered by Axelar + Wormhole

Introduction

In response to the GMX community’s call for a secure and transparent expansion of GMX across multiple chains like Arbitrum, BASE, BNB, and Ethereum, the Axelar, Wormhole, Mayan and Squid teams are pleased to present a unified proposal that combines our expertise in cross-chain messaging and bridging infrastructure to support GMX’s expansion across multiple chains. Our solution addresses GMX’s requirements for unified liquidity and seamless user experience.

We’d like to express our thanks to the GMX Governance for their feedback as we’ve put together this design. Should it receive positive community feedback and DAO approval, Axelar Inc., Squid, and the Wormhole Network will jointly support GMX’s multichain expansion.

Problem Background

GMX requires a robust cross-chain infrastructure that enables:

• Unified liquidity pooling on Arbitrum while serving users across multiple chains
• Fast and cost-effective bridging for various transaction sizes
• Secure message passing for cross-chain order execution
• Support for multiple tokens and messages in single transactions
• Scalability for future chain expansions

Technical Solution

Executive Summary

We propose multiple products for the different requirements presented by GMX.

• Native Token Transfers (NTT) for bridging $GMX quickly, securely and without fragmented liquidity across chains.
• Wormhole and Axelar as cross-chain messaging solutions.
• Wormhole Bridge for cost-efficient asset transfers.
• Wormhole Settlement, Squid and Mayan as intent-based bridging protocols, for fast bridging, built on top of Axelar and Wormhole.

Native Token Transfers

Our solution implements a multi-bridge approach that combines the security and efficiency of multiple leading bridge providers, utilizing the NTT standard. This is the identical implementation that was used in the Lido wstETH proposal for BNB

We propose a multi-bridge approach that combines Wormhole and Axelar network messaging in a standardized way, and provides the GMX flexibility to add more messaging providers in the future.

1. Unified Message Verification
   • Implementation of a message aggregator contract that manages message verification across multiple providers
   • Support for 2-of-2 or higher threshold verification
   • Built-in fallback mechanisms for chain reorganizations
2. Single-Transaction Single Token Bridging with Message
   • Squid: Messages and tokens can be bridged simultaneously without source chain contract deployment
3. Flexible Token Support
   • Native support for all GMX-required assets: $GMX, USDC, stablecoins, wrapped BTCs, ETH, bitcoin LSTs, GM/GLV tokens
   • Expandable token registry for future asset additions
   • Optimized gas costs for multi-token transactions.
   • For native-to-native USDC chain transactions, we can provide entirely gasless transactions for users - the user does not have to pay gas on the source or destination chain.

NTT - Message Architecture Overview

The main components are:

• NttManager - responsible for locking and minting GMX, governance, and sending/receiving multi-bridge messages via the Transceiver components
• Transceiver - responsible for sending and receiving cross-chain messages from a single provider .
• GMX on BASE, Avalanche, Solana, etc as newly deployed mintable/burnable tokens representing GMX on Arbitrum.

When a user transfers GMX from Arbitrum to a destination chain like BASE, the following steps occur:

1. The user interacts with the NttManager contract. This contract locks the user’s GMX and sends messages to mint GMX on BASE via each Transceiver contract. In this design, Axelar and Wormhole each implement a Transceiver contract and the GMX can choose to modify or add additional messaging providers.
2. Each messaging provider will perform its own verification of the message from Arbitrum and relay attestations to the corresponding Transceiver contract on BASE. At a high level:
   • Wormhole’s validators (Guardians) identify messages emitted from Arbitrum, wait for finality, and produce a signed attestation once a super-majority comes to consensus. A Wormhole relayer then delivers this message to the Wormhole Transceiver on BASE.
   • Axelar network is a decentralized Proof-of-Stake based network that leverages a distributed consensus to verify and route messages across chains. Once the message is posted on the source chain, the validators verify it, route it, and a relayer transmits a transaction to the destination chain approving the cross-chain message.
3. Transceiver contracts on BASE Chain receive and verify their respective messages and then the NttManager aggregates these messages and verifies that the appropriate 2-of-2 threshold is met. If all checks pass, the NttManager mints GMX and delivers it to the intended recipient.

When a user transfers GMX from BASE to Arbitrum, similar steps occur with the following exceptions:

• The NttManager on BASE will burn the user’s GMX, instead of locking. This is because BASE GMX will be a newly deployed ERC20Burnable (or similar) that can be burned.
• The NttManager on Arbitrum will unlock and send GMX to the recipient, instead of minting.

This design is flexible and the GMX can choose to add more Transceiver providers or update the multi-bridge threshold, e.g. from 2-of-2 to 2-of-3 or 3-of-3.

It is also important to note that transfers between non-source chains do not require going through a “main” chain as generally happens with native bridges. Tokens are burned on one chain and minted at the destination, simplifying the user experience and reducing costs.

NTT - Transfer Costs and Times

The following table shows estimated costs of transferring tokens to Arbitrum. With NTT and the bridge, the cost is independent of the amount of tokens being transferred.

Chain	Gas Paid	USD	Token	Note
ETH	0.0003595 ETH	$0.66	W	NTT
ETH	0.0001861 ETH	$0.50	ETHFI	NTT
ETH	0.0003724 ETH	$0.97	SWISE	NTT
BNB Chain	0.0003281 BNB	$0.19	L3	NTT
BNB Chain	0.0001813 BNB	$0.12	L3	NTT
BASE	0.0000059 ETH	$0.01	W	NTT
BASE	0.0000008 ETH	$0.00	L3	NTT
AVAX	0.000349 AVAX	$0.01	WETH	Bridge. Transfer
AVAX	0.0007163 AVAX	$0.01	WETH	Bridge. Transfer with payload
AVAX	0.0001674 AVAX	$0.00	SOL	Bridge

Times on NTT generally depend on the network block finality (unless configured otherwise by the protocol). As an example, and if we considered ‘finalized’ as desired for transfers, in average:

• Ethereum: 15 minutes
• BNB Chain: 5 seconds
• Base: 18 minutes
• Avalanche: < 1 second

Message + Bridge Architecture Overview

Wormhole supports more than 40 blockchains and Axelar supports more than 70 blockchains with the overlapping chains including Ethereum, BASE, Arbitrum, Polygon, and Avalanche. Both parties have aggressive plans to provide Day-1 support for many of the highly anticipated EVM chain launches.

• Solana has been supported by Wormhole since August 2021.
• Wormhole’s TON support is expected to begin with intents in ~1 months, with full general messaging support expected to come over the following ~6 months.
• Both Wormhole Settlement and Wormhole + Axelar multi-bridged messaging support passing payloads to the destination chain, and in the future,
• Wormhole will be able to support users who seek to bridge multiple assets at a time, as well as include a payload with them.

Intent-Based Bridging

Using suite of intents products, we are able to provide a near instant bridge for arbitrary native-to-native transfers (e.g. $ETH on Arb to $Avax on Avax) and NTT tokens (e.g. potentially $GMX or GM and GLV tokens). While built on Wormhole + Axelar multi-bridged messaging, each protocol uses a novel architecture with unique price discovery, scalability, and latency tradeoffs.

• Wormhole Settlement offers routes that can facilitate near instant intents bridging for a small premium or slower transfers at nearly zero cost.
• For native-to-native USDC chain transactions, we are able to provide entirely gasless transactions for users - the user does not have to pay gas on the source nor destination chain.
• Working with GMX, we can whitelist other assets for this service (e.g. $GMX, $GM, etc..).
• Chain reorgs risks are placed on solvers and do not impact the user, if they occur.

Settlement - Price and Cost

Wormhole Settlement provides a series of estimates for some chains and assets requested by GMX.

• Base to ARB: $1m USDC cost of <$0.04 and 21 minutes via Mayan MCTP (a Wormhole Settlement protocol - see Jumper screenshot below). For faster transfers, integrators can leverage Mayan Swift, where execution times occur in seconds.
• Base to ARB: $1,000 USDC → ~$998.84 at <7 seconds
• Base to ARB: $10,000 USDC → ~$9,996.55 at <7 seconds

Mayan Bridge

• Mayan is a cross-chain swap auction protocol designed to deliver optimal swap rates and rapid asset transfers using three complementary methods – WH Swap, MCTP, and Swift.
• MCTP leverages Circle’s CCTP to convert input tokens to USDC and dispatch messages directly to smart contracts on destination chains, ensuring secure and efficient value delivery.
• Swift method allows users to lock funds on the source chain and trigger an auction on Solana, where a designated driver fulfills the order on the destination chain in near-instant speeds.
• Mayan major chains such as Ethereum, Arbitrum, BASE, BNB, Polygon, and Avalanche, Mayan facilitates cross-chain swaps for over 1,000 assets. It offers seamless integration while maintaining low fees and deep liquidity.

Squid Router

• Squid’s Multicall is designed specifically for payload generation on the client, so a developer can use javascript only to build withdrawal and deposit transactions before and after a bridge or swap.
• The Squid Multicall allows for transaction bundling, such as approve → deposit → transfer receipt, reducing load on the destination chain smart contract. On the source chain, a user can exchange their receipt token for e.g. USDC in a pre-hook, then swap it across chains and deposit in a post hook, all in one transaction.
• Squid’s pre and post hooks allow developers to build arbitrarily long transaction bundles before and after the bridge and swap using e.g. typescript. This reduces load on smart contract development, improving security.

Squid – Performance Metrics

• TL;DR
  • Price: Squid’s RFQ (Intent Centric) called Coral charge only 1 bp for any amount of major stablecoins like USDC & USDT which is cheaper than the industrial level
    • As of now, Squid CORAL can support up to $100K deal and will continue to increase per bridge size.
  • Speed (Medium calculated by hundred of thousands of txs):
    • Bridging across L2s takes 5 seconds (saving 50%~70% of the processing time compared to other players)
    • Bridging from/to Ethereum takes 25 seconds
• Cross-Chain Swap:
  • Squid has integrated major DEXs (110 liquidity sources) across chains, which allows users/protocols have more choices to migrate liquidity to desire tokens on chains you have been providing services to. What’s more, Squid’s CORAL also supports cross-chain swap for major tokens including USDC, USDT, BTC, ETH, etc, with the fixed rates without swapping through DEXs, which means there is no slippage. Notably, Squid is willing to support bitcoin LSTs, GMX’s own GM & GLV tokens if the proposal is approved by the GMX DAO.
• Cheapest: Squid has a unique structure to provide cross-chain bridging via AMM model and RFQ (Intent Centric) called Coral, which makes the price most competitive in the market.
• Fastest: Squid has RFQ (Intent Centric) called Coral, which makes the processing time taking 5 secs only on average. Citing the attached picture, Coral completes each bridge transaction within 3-10 secs, which is much faster than players like Stargate (40secs~5mins) & Across (10-15 secs)

Coral Real-Time Transactions

Squid – Estimated Bridging Times and Costs (Bridge Stablecoins Across Arbitrum and BASE)

Amount	Time (median)	Cost (USD)
$1K	5 seconds	$0.1
$10K	5 seconds	$1
$100K	5 seconds	$10

General Security and Operational Considerations

Security is paramount, and this proposal joins the security measures of Wormhole and Axelar network together to protect GMX users. Axelar network implements multi-layered security starting with the decentralized protocol, followed by robust engineering, and application-level addons. The Wormhole network incorporates defence-in-depth measures like the Global Accountant and Governor, has gone through extensive audits and maintains multimillion-dollar public bug bounties to maintain high security and operational standards.

The Wormhole Protocol’s security program has been managed by Asymmetric Research since 2023. The team brings extensive security expertise through its leadership - Felix Wilhelm, formerly of Google Project Zero, and Jonathan Claudius, previously head of security at Mozilla and Jump Crypto. Leveraging their deep experience in blockchain security, Asymmetric Research oversees all aspects of Wormhole’s security operations, including incident response and vulnerability management.

Both protocols have undergone extensive audits and maintain large public bug bounties to maintain high security and operational standards.

For near instant bridging, Wormhole Settlement solvers (RockawayX, Flow Traders, Tokka Labs, and others) handle all source chain reorg risk.

Wormhole protocol messages use stable IDs (digests) that are resilient against chain reorgs. Each message includes destination chain, destination wallet address, output token address, minimum output amount, gas drop amount, deadline, and 32 bytes of random hex to prevent collisions - a keccak-256 hash is then calculated to identify the order. Wormhole does not include any timestamp, block number, or other inputs into the orderID that may be impacted by a reorg to ensure stable orderID construction.

Axelar is designed with a security first approach. The Axelar network is itself a proof-of-stake blockchain, secured by a set of 75 validators. This validator set is permissionless, meaning that anyone can join and participate in the security of the network. When sending a cross-chain transaction that message is sent from the source chain to the destination via the Axelar network. While the message is routed through the Axelar network, the Axelar validator set must come to consensus on the message that was sent. The authenticity of the message from the source chain is therefore confirmed by the decentralized validator set. To ensure the network decentralization Axelar also employs quadratic voting, this sets the number of votes each validator gets to a square root of their stake. The major benefit being that it restricts the ability of the top few validators to have too much influence over the network when it comes to governance proposals. Validators are also required to periodically rotate their keys amongst other best practices to protect the network from attackers trying to accumulate keys maliciously.

As an added layer of security, Axelar has fallback solutions to protect the network from any incidents. Axelar employs rate limits for high priority routing assets such as USDX or ETH. Axelar services such as its Interchain Token Service also allow token integrators to set rate limits at the contract layer for their assets.

On the Axelar side, to address the possibility of a reorg the protocol has a unique Command Id. Generating a command id involves combining specific attributes of the message, such as the source chain, message id (transaction hash + event index), and other relevant data, and then hashing this combination to produce a unique identifier. This process ensures that each command id is unique for the message it represents.

While a multi-bridge approach is subject to the combined uptime of all providers, Wormhole and the Axelar network are both designed with resilience in mind and have encountered no significant downtime in the past year.

Axelar Network:

• Audits: GitHub - axelarnetwork/audits: Axelar network audits

• Bug bounty: Axelar Network Bug Bounties | Immunefi

• Security overview: https://axelar.network/blog/security-at-axelar-core

Squid:

• Audits: https://github.com/0xsquid/audits

• Security overview: Squid’s 9 Audits, primary reliance on Axelar, and stateless contracts provide very good security. Squid has never had a security incident.

Wormhole:

• Audits: wormhole/SECURITY.md at main · wormhole-foundation/wormhole · GitHub

• Bug bounty: Wormhole Bug Bounties | Immunefi

• Security overview: Cross-chain security | Wormhole

Conclusion

Our joint proposal offers GMX a comprehensive solution that meets all technical requirements. We are committed to fostering GMX’s growth across multiple chains while maintaining the highest standards of security and performance.

About Axelar

Axelar network is the leading interoperability layer for Web3. The network enables blockchain as a new kind of development platform, integrating diverse networks into a seamless “Internet of blockchains.” Axelar is programmable and decentralized, secured by a proof-of-stake token, AXL. Application users access any digital asset or application, with one click. Developers work with a simple API and access an ecosystem of tools and service providers.

Axelar is funded by top-tier investors, including Binance, Coinbase, Dragonfly Capital, Galaxy and Polychain Capital. Major partnerships and integrations include Microsoft, Mastercard, JPM, dYdX and Uniswap. Axelar’s team includes experts in distributed systems/cryptography and MIT/Google/Consensys alumni; the co-founders, Sergey Gorbunov and Georgios Vlachos, were founding team members at Algorand.

About Squid

Squid creates unlimited access for anything in crypto. Squid can be used to seamlessly swap and bridge across 80+ chains all from one place, and Squid NFT Checkout can be used to buy any NFT using any token. Squid’s API, SDK, and Widgets offer ease of integration for projects building on any chain to enable cross-chain functionality in just 1 click.

About Wormhole

Wormhole is the longest-running generic cross-chain messaging protocol, with the first production message sent in August 2021. Hundreds of projects have leveraged Wormhole to transfer over 57 billion USD of value and over 1 billion messages across more than 40 chains. These messages enable sending price oracle data, transferring tokens between chains, building cross-chain DeFi protocols, cross-chain governance, and many other use cases.

Wormhole supports over 40 blockchains, including Ethereum, Solana, Arbitrum, Polygon. It supports Avalanche, leading stablecoins like USDC.e (Fantom) using Native Token Transfers or USDC using CCTP. There is also the possibility of using wrapped assets via Bridge.

Additionally, Wormhole was named the only unconditionally approved protocol by the Uniswap Foundation’s Bridge Assessment Committee - Bridge Assessment Report.

[Jonezee]

Thank you for sharing!

[Jonezee]

Announcement: GMX Community Call

Q&A Session and Presentation of the Proposals by the potential Bridging & Messaging Partners for GMX Multichain

All community members are invited to listen in to this Community Call on Google Meet, ask questions, and hear from the involved parties.

———

Date: Monday, 31 March

Start Time: 1:30 PM UTC | 9:30 AM ET | 5:30 PM UAE | 9:30 PM SGT
Expected End Time: 3 PM UTC | 11:00 AM ET | 7 PM UAE | 11 PM SGT

Venue: Google Meet: https://meet.google.com/pzu-wdec-emb