How does cross-chain infrastructure work? In-depth analysis of the Gravity interoperability protocol and native oracle architecture.

The fragmented landscape of the blockchain industry is a repeatedly stated fact. Dozens of public chains and L2s, such as Ethereum, Solana, Cosmos, and Arbitrum, coexist, each with its own account system, state storage, and consensus rules. Cross-chain asset bridges and cross-chain messaging protocols have emerged in abundance over the past few years, but a fundamental structural issue has always remained unresolved: who certifies cross-chain data?

Most L1 chains "outsource" the verification responsibility of oracles or cross-chain bridges to off-chain independent networks—an external oracle network signs data, or an independent multi-sig committee proves deposit events. The chain itself stays "clean," but a new trust assumption is attached to the flank. Once the side channel is compromised, the chain continues to run, but the on-chain data is already wrong.

Gravity offers a distinctly different architectural answer. Developed by the Galxe team, Gravity is a high-performance, fully EVM-compatible Layer 1 blockchain. Its core differentiator lies in the Native Oracle—the same set of validators generates blocks under AptosBFT consensus while simultaneously observing external data, voting, and writing to L1. No external oracle network, no independent multi-sig committee. The cross-chain bridge is not an independent service but a contract that receives data already submitted by the validator set.

This is precisely what "native" means: the validator proving pipeline is part of the chain's state machine, not a service running alongside. Any data landed through the Native Oracle has security equivalent to the chain itself—the same validators, the same BFT threshold, the same finality window.

In June 2026, the Gravity L1 mainnet officially launched, marking the transition of this architecture from theory to production. This article will systematically deconstruct Gravity's interoperability protocol mechanism from four dimensions: cross-chain message passing, liquidity routing, verification and security model, and the full asset cross-chain process.

Cross-Chain Message Passing Mechanism: A Paradigm Shift from "Pull" to "Push"

Cross-chain message passing is the foundational layer of all interoperability protocols. Its core question can be simplified to: How does Chain A prove to Chain B that "something has happened?"

In traditional cross-chain bridge designs, users deposit assets into a contract on the source chain, and a set of external relayers monitor the event and then mint corresponding assets on the target chain. This model relies on the honesty and availability of the relayers and often requires users to wait for multiple block confirmations to reduce the risk of reorganization.

Gravity's message passing mechanism is built on its Native Oracle, fundamentally changing this process. The Native Oracle is a single contract deployed at a fixed system address on Gravity L1: NativeOracle → 0x0000000000000000000000000001625F4000. This contract exposes a core operation, record, which can only be called by SYSTEM_CALLER—a privileged consensus-time identity, not a regular account.

The record function accepts the following parameters: source type (sourceType, e.g., blockchain), source ID (sourceId, e.g., chain ID), nonce, source chain block number, payload (opaque binary blob), and callback gas limit. There is also a recordBatch variant for delivering multiple events from the same source in a single transaction.

Three key design choices are worth elaborating:

First, centralized replay protection. The Native Oracle enforces a strict sequential requirement for each (sourceType, sourceId) pair: nonce == currentNonce + 1—strictly sequential, no skipping. Old messages can never be replayed because the contract has passed their nonce. Application-layer handlers do not need to maintain their own processed-nonce mappings. This means the deduplication logic for cross-chain messages is elevated to the protocol layer, rather than left for each application contract to implement—significantly reducing the security burden on application developers.

Second, callback routing instead of polling. Each (sourceType, sourceId) pair can register a callback contract. When data is recorded, the Native Oracle calls the registered handler's onOracleEvent function with the gas limit specified by the caller. Resolution is two-tiered: a default handler per source type, which can be overridden by a specialized handler for a specific sourceId. Governance manages the registry. This "push" mode allows application contracts to be notified and execute corresponding logic as soon as cross-chain data arrives, without needing to continuously poll state.

Third, callback fault tolerance. The handler returns shouldStore: bool—a handler that fully consumes the payload (applying it to its own state) can return false to skip storage and save gas. If the handler reverts or runs out of gas, the Native Oracle catches the exception, emits a CallbackFailed(reason) event, and still stores the payload. The record operation succeeds regardless.

This design achieves a clear separation of concerns: the Native Oracle is responsible for truth (consensus proof, replay protection), while application contracts are responsible for meaning (decoding and execution). The authenticity of cross-chain messages is guaranteed by the Gravity validator set with BFT finality, not by an external relay network.

Verification and Security Model: Same Lock, Same Key

The difference in security models is a core dimension distinguishing the quality of cross-chain protocols. Gravity's security architecture can be summarized in one sentence: The security of the Native Oracle is equivalent to the security of the chain itself.

Specifically, Gravity uses a Proof-of-Stake verification mechanism, where validators stake G tokens to participate in consensus and Native Oracle attestations. The consensus engine is AptosBFT, providing fast finality. The validator set secures the chain with a two-thirds threshold—the same threshold also guarantees the authenticity of Native Oracle data.

What does this mean?

On most chains, failures of oracles or cross-chain bridges are often "invisible"—anomalies in the external verification network may go unnoticed for long periods before causing massive losses. On Gravity, the security of the oracle is identical to the chain's own security. If an attacker wants to submit false cross-chain data, they need to control more than one-third of the validators—which simultaneously means they could attack the chain itself. There is no "weaker side channel" for attackers to breach at lower cost.

From an asset cross-chain perspective, this model eliminates the "external signer" risk of traditional cross-chain bridges. The traditional Ethereum → Cosmos Gravity bridge consists of two parts: a Solidity smart contract deployed on Ethereum and a Cosmos SDK blockchain module. Users deposit assets on one side, and corresponding tokens are minted on the other. However, under Gravity L1's Native Oracle architecture, the Ethereum → Gravity L1 asset bridge is the first production-grade application of the Native Oracle. No external oracle network, no independent signer set stacked on top of consensus.

It is worth noting that Gravity is also undergoing an important upgrade in security architecture. In June 2026, Gravity announced that during its L1 blockchain launch, it would upgrade from LayerZero to Chainlink CCIP as its canonical cross-chain infrastructure. The Gravity native token G will become a cross-chain native asset (CCT), providing developers with self-serve deployment, zero-slippage transfers, and higher programmability. CCIP, leveraging its decentralized oracle network, will greatly enhance the ability of developers on the Gravity network to build secure cross-chain applications. This upgrade shows that while maintaining the core advantages of the Native Oracle, Gravity is also actively integrating the industry's most mature cross-chain standards.

Complete Asset Cross-Chain Process: An Eight-Step Deduction from Deposit to Receipt

Based on the above mechanisms, a complete asset cross-chain (taking Ethereum → Gravity L1 as an example) can be broken down into the following steps:

Step 1: User locks assets. The user deposits ETH or ERC-20 tokens into Gravity's Ethereum bridge contract on Ethereum. This contract records the deposit event, including the user's address, asset type, amount, and target chain information.

Step 2: Ethereum block finalization. Gravity validator nodes continuously monitor the Ethereum chain. Validators do not rely on external relayers to push data; they observe Ethereum state themselves.

Step 3: Validator consensus vote. In each block of Gravity L1, validators sign and broadcast the external data they observe (including Ethereum deposit events) as part of the Native Oracle payload. Validators use the exact same keys and threshold for signing such external data as they do for signing Gravity chain's own transactions.

Step 4: Data submission to the Native Oracle. Once the validator set reaches consensus on a specific external event (reaching two-thirds threshold), the data is written to Gravity L1's Native Oracle contract via a record or recordBatch call.

Step 5: Nonce check and replay protection. The Native Oracle contract verifies that the nonce of the event is strictly increasing. If the nonce does not match (duplicate submission or skip), the record is rejected.

Step 6: Callback triggering. The asset bridge contract, as a registered callback handler, receives the onOracleEvent call. The contract decodes the payload, verifies the asset type and amount, and confirms the target receiving address.

Step 7: Minting or releasing assets. The asset bridge contract mints the corresponding amount of G token-wrapped assets (or directly releases G in the case of a native asset bridge) on Gravity L1 and transfers them to the user's address on the Gravity chain.

Step 8: Finality confirmation. The entire process achieves sub-second finality under Gravity's AptosBFT consensus. Users can receive cross-chain assets within a 200-millisecond block time.

The key feature of this entire process: No step relies on external relayers or independent signers. From data observation to voting to writing to execution, everything is done by the same set of validators under the same security assumptions.

Performance Foundation: 12,000+ TPS and Sub-Second Finality

The value of the mechanism design needs a performance base to carry it. Gravity's performance parameters provide practical feasibility for its cross-chain interoperability:

Gravity Mainnet uses the Grevm parallel EVM execution engine (forked from revm). Under real-time workloads, Gravity can sustain 12,000+ TPS in ERC-20 transfer throughput, with a block time of 200 milliseconds. In actual measurements on a 3-validator node cluster (8 vCPU / 16 GB nodes), throughput remained around 9,500–11,000 TPS.

Even more noteworthy is its fee structure. A base fee of 50 Gwei makes block space on Gravity functionally a public good rather than a competitive asset. The cost of each ERC-20 transfer is approximately $0.0026. This breaks the standard L1 economic model, which relies on fee pressure as the main source of token value accrual. Value capture shifts to the services provided by validators (oracle attestations, cross-chain data, bridging) and the application layer.

For cross-chain scenarios, low fees make high-frequency cross-chain transactions economically viable; sub-second finality brings cross-chain user experience close to intra-chain transactions.

Looking at historical data, since its launch in August 2024 as an Arbitrum Nitro-based L2, the Gravity Alpha Mainnet processed over 611 million transactions across 28.5 million wallets, with an average block time of 1.3 seconds over 22 months. This serves as a production-grade validation for the L1 mainnet launch.

Market Data and Token Economics

As of June 29, 2026, according to Gate market data, Gravity (G) is priced at $0.003641, with a 24-hour increase of +13.78%, a 7-day increase of +36.62%, and a 30-day increase of +3.72%. The market cap is approximately $26.33M, ranking 658th. The 24-hour trading volume is $29.2M, with a total supply of 12.0 billion. Market sentiment is neutral. Over the past year, the price change is -69.22%, with an all-time high of $0.015440.

G is the native token of Gravity L1, with a maximum supply of 12 billion, migrated from the original GAL token. At mainnet launch, 7 launch validators received an initial staking allocation of 7 million G. The corresponding 7 million G has been locked in the canonical bridge's GBridgeSender contract on Ethereum Mainnet, permanently locked to support native G on L1.

G serves as the gas token driving transactions, secures the network through staking, and drives governance decisions, incentivizes growth, and facilitates payments. G holders govern protocol decisions through the G DAO.

Conclusion: The Endgame of Interoperability is Unified Trust

The evolution of cross-chain interoperability can be divided into three phases.

The first phase is asset bridges, where users transfer assets from Chain A to Chain B, relying on external validators or light client proofs.

The second phase is general message passing protocols (such as LayerZero, Axelar), supporting cross-chain smart contract calls, but the verification logic still depends on a combination of external oracles and relayers.

The third phase is protocol-level interoperability—the validator set is simultaneously responsible for the chain's state transitions and cross-chain data attestations, compressing external trust assumptions to the same security boundary as the chain itself.

Gravity's Native Oracle architecture represents an engineering implementation of the third phase. It is not an incremental optimization of existing cross-chain bridge models but a fundamental reconstruction of the answer to "who certifies cross-chain data." When the security of cross-chain data and the security of L1 itself are guaranteed by the same set of validators and the same BFT threshold, the trust gap between "cross-chain" and "intra-chain" is significantly reduced.

This is not to say that Gravity eliminates all risks. The degree of decentralization of the validator set, the long-tail stability of the staking economic model, the code risk of cross-chain contracts, and the engineering challenges during the migration from LayerZero to Chainlink CCIP are all dimensions that require continuous observation. Additionally, in May 2026, the Gravity Bridge suffered an attack, resulting in a loss of approximately $5.4 million, which also reminds the market that even the best-designed cross-chain architecture still needs sufficient real-world testing.

But the direction is clear: the endgame of interoperability is not more bridges, but fewer trust assumptions. Whether Gravity can become a representative infrastructure for this endgame depends on the validator decentralization process after mainnet launch, the migration speed of ecosystem applications, and the resilience of the Native Oracle under real attacks. For researchers and developers focused on the cross-chain track, Gravity's architectural choice provides a sample worthy of continuous tracking.

FAQ

Q1: What are the core differences between Gravity and cross-chain protocols like LayerZero or Axelar?

LayerZero is based on Ultra Light Node (ULN) architecture, using Oracle and Relayer to jointly verify cross-chain messages; Axelar adopts an independent PoS verification network with General Message Passing (GMP). Gravity embeds cross-chain data verification directly into the L1 consensus layer, with the same set of validators guaranteeing both chain state and cross-chain data authenticity under the same BFT threshold.

Q2: How does Gravity's Native Oracle ensure cross-chain data security?

The Native Oracle has no external network or multi-sig committee. Validators observe external data, vote, and write to L1 under AptosBFT consensus. Data authenticity is guaranteed by a two-thirds threshold of the validator set—completely identical to the chain's own security. The cost to attack false cross-chain data is equivalent to attacking the chain itself.

Q3: What are Gravity's current performance parameters?

Gravity L1 can sustain 12,000+ TPS in ERC-20 transfer throughput under real-time workloads, with a block time of 200 milliseconds and sub-second finality. The cost per ERC-20 transfer is approximately $0.0026. The Alpha Mainnet processed over 611 million transactions in 22 months.

Q4: What does Gravity's upgrade from LayerZero to Chainlink CCIP signify?

In June 2026, Gravity announced Chainlink CCIP as its canonical cross-chain infrastructure. G will become a cross-chain native asset (CCT), providing developers with self-serve deployment, zero-slippage transfers, and higher programmability. This enhances the security standards and development convenience of Gravity's cross-chain applications.

Q5: What are the main functions of the G token?

G is the native gas and staking token of Gravity L1. Validators stake G to participate in consensus and Native Oracle attestations. G holders govern protocol decisions through the G DAO, and G also serves as a payment and incentive token in the Galxe ecosystem.