Gravity: Layer-1 Mainnet is Live

Key Insights

• Gravity is a fully EVM-equivalent Layer-1 (L1) built by the Galxe team, the Web3 growth and distribution platform behind Quest, Earndrop, Passport, and Score. The chain sustains 12,000+ TPS for ERC-20 transfers at 200-millisecond block times, with substantial modifications to Reth, including a more pipelined architecture and optimizations to Reth’s merklization and storage.
• Gravity mainnet is live in a permissioned phase, with a small validator set operating the network at launch. The Galxe ecosystem migrates to Gravity L1 as the first production application, with the validator set expanding and additional applications onboarding once the chain proves it can sustain Galxe’s transaction volume.
• A native oracle is Gravity’s primary architectural differentiator. The first application built on the primitive is an Ethereum to Gravity L1 asset bridge live at launch, with no external oracle network or separate signer set layered on top of consensus.
• G is the native gas and staking token on Gravity L1, with a 12 billion maximum supply migrated from the legacy GAL token. Validators stake G to underwrite consensus and native oracle attestations, while G holders govern protocol decisions through the G DAO and use G as the payment token across the product suite.
• High throughput and a 50 Gwei base fee make blockspace on Gravity functionally a public good rather than a contested asset, breaking the standard L1 economic model that relies on fee pressure as the primary token value sink. Value capture moves toward validator-provided services (oracle attestations, crosschain data, bridges) and the application layer rather than fees on a constrained substrate.

Primer

Gravity is a high-performance Layer-1 (L1) blockchain built by the Galxe team. The network combines Proof-of-Stake (PoS) validation, a pipelined AptosBFT consensus engine, and Grevm (Gravity EVM), a parallel EVM forked from revm, to deliver sub-second finality and sustained 12,000+ TPS on real workloads. Gravity Alpha Mainnet launched in August 2024 as an Arbitrum Nitro-based L2 to bring the Galxe ecosystem onchain. Over the 22 months since, the chain has processed more than 611 million transactions across 28.5 million wallets at a 1.3-second average block time, serving as the proving ground for the L1 mainnet now live.

Three engineering threads converged into that launch. Grevm 2.0 shipped in March 2025, replacing optimistic parallelism with a directed acyclic graph (DAG)-based scheduler that benchmarked 500-millisecond blocks at 7,000+ TPS on the contemporaneous devnet. The Gravity SDK was open-sourced in the same window, packaging an AptosBFT consensus engine, a Quorum Store mempool, and a 5-stage execution pipeline into the first production-ready toolkit for pipelined EVM L1s. In parallel, the team worked with Paradigm, the crypto venture firm that maintains Reth, to merge several Gravity Reth optimizations upstream, and the two teams are now collaborating on RocksDB integration and a parallel storage schema for chains with billions of accounts.

Galxe is a Web3 growth and distribution platform that builds infrastructure for user acquisition, engagement, and token distribution. Its product suite includes Quest for onchain campaigns and tasks, Earndrop for airdrops and large-scale token distributions, Starboard for contributor and social analytics, Passport for identity management, and Score for reputation. At mainnet launch, the Galxe ecosystem becomes the first production workload on Gravity L1, with Quest, Compass, Passport, Score, Alva, and Identity Protocol migrating across.

Gravity Chain is Live

Gravity Chain is now live, transitioning the Gravity Alpha Mainnet from an Arbitrum Nitro-based Layer-2 (L2) to its own L1 network. Gravity launches with a small set of invited validators operating the chain through its initial production phase. As mainnet proves it can carry production load at scale, the team will broaden the validator set and progress toward a permissionless network.

Performance metrics

Mainnet sustains 12,000+ transactions per second (TPS) on ERC-20 traffic at roughly 200-millisecond block times. The Gravity Reth execution layer benchmarks a 1.5-1.9 gigagas per second under isolated testing (1 gigagas = 1 billion gas units, the unit of computational cost on EVM chains), comfortably above the 1 gigagas per second sustained target from the litepaper. For reference, the contemporaneous Longevity Testnet ran at 500-millisecond blocks and roughly 7,000 TPS in a three-validator cluster on 8 vCPU / 16 GB RAM nodes. Mainnet roughly doubles the testnet’s ERC-20 throughput while halving block times on the same modest hardware profile.

All benchmark code is open source and independently reproducible.

The 5-Stage Pipeline

Gravity’s throughput comes from end-to-end pipelining. Where most blockchains process blocks sequentially (a block reaches consensus, executes, and commits state before the next is proposed), Gravity runs five consecutive blocks through five stages concurrently, coordinated by a pipeline controller that dynamically adjusts pace via backpressure signals from each stage. The chain advances at the speed of its fastest stage rather than its slowest, with five blocks in flight at any given moment.

Stage 1 - Transaction Dissemination: Quorum Store, a mempool architecture inherited from Aptos, decouples transaction propagation from consensus. Validators stream and certify transaction batches in parallel rather than serializing through the block leader, removing the leader as a bandwidth bottleneck.

Stage 2 - Block Ordering: Consensus runs on AptosBFT with Order Votes (AIP-89), reducing finality to three hops, the theoretical lower bound for any BFT protocol. The leader proposes, validators vote, and the order is locked in within a single network round trip.

Stage 3 - Parallel Execution: Gravity Reth, a performance fork of Paradigm’s Reth, executes the block using Grevm. Grevm 2.0’s DAG-based scheduler builds a dependency graph from a simulation pass, then executes independent transactions in parallel while preserving sequential semantics for dependent ones.

Stage 4 - State Commitment: A parallel merklization framework computes the new state root asynchronously, batched across multiple blocks. Commitment work no longer blocks the next block’s execution.

Stage 5 - State Persistence: Gravity Store, a multi-version key-value store with asynchronous I/O, writes finalized state to disk. The team is collaborating with Paradigm on a RocksDB integration to extend this layer to chains with billions of accounts.

The architectural payoff is that no stage waits on another. The chain’s effective block time is set by the fastest stage, and any stage can absorb localized slowdowns without stalling the pipeline.

Native Oracle: The Differentiator

Most L1s offload crosschain data to third-party oracle networks, bridge committees, or relayers whose validators are not the same set securing the chain. The chain itself stays clean, but a separate trust assumption is bolted on the side. When that side channel breaks (a misconfigured verifier network, a compromised signer set, a stale price feed), the chain keeps running, but the data on which applications acted is wrong.

Gravity solves this issue by having the same validators that produce blocks, observe external data, vote on its inclusion, and write it to the L1. In doing so, Gravity’s Native Oracle allows external-world state to be observed onto Gravity without adding an extra trust assumption. The project has built its own native oracle, embedded within the network layer, where each validator runs an oracle observer alongside its consensus duties, polls source chains for finalized events, and submits its observations into the same BFT machinery that orders normal transactions. A piece of external data is finalized on Gravity when more than two-thirds of validators have attested to it, under the same thresholds that secure block production. The trust assumption for offchain data is the trust assumption for the chain itself, nothing more.

Gravity’s Ethereum to L1 asset bridge is the first example of this primitive. The same architecture can support many other types of external state, such as stock prices, weather data, sports results, major political events, and other real-world signals. New applications will be registered via governance rather than spun up alongside the chain as a separate oracle network.

Network Details

Gravity runs on chain ID 127001 with G (18 decimals) as the native gas and staking token. The mainnet RPC endpoint is live at mainnet-rpc.gravity.xyz, and a Blockscout-based block explorer is available. Users can add Gravity to their wallets through Chainlist, and QuickNode provides third-party RPC support from day one.

Engineered for Agents

AI agents are becoming a meaningful user class onchain. The 2026 wave of agentic applications, in which models execute multi-step actions on behalf of users rather than just generating responses, depends on infrastructure capable of sustaining agent-paced activity at production scale. Wallets and accounts are not enough; agents need a backend that reads and writes state in real time, settles value within the loop of a decision, and stays synchronized with the external world. Most existing chains weren't built for that workload.

Agents work in tight decision loops where seconds of latency are unacceptable, which rules out chains with multi-second finality. Those same loops create high-frequency transaction volume at small denominations, breaking the L1 fee economies built around scarce blockspace. Decisions in those loops depend on external signals (market prices, offchain events, the outputs of other agents) that force reliance on oracle infrastructure most networks outsource rather than secure natively. The final requirement sits on the developer side: the chain itself must be addressable without humans writing SDK wrappers as glue, a problem most networks have not solved.

Gravity is designed to accommodate the proliferation of onchain agents. Sub-second finality at 200-millisecond block times keeps decision loops short. A 50 Gwei base fee puts a standard ERC-20 transfer at roughly 0.0026 G, low enough that agent-scale transaction volumes don’t compound into prohibitive cost. The native oracle provides a trustworthy offchain state without an additional trust hop. Gravity also ships with an installable Skill that lets any compatible coding agent operate or build on the chain directly.

Gravity Skills

The Gravity Skill is an official Agent Skill that loads Gravity's chain knowledge into an AI coding agent on demand — network parameters, the system-contract address map, the native oracle ABI, the cross-chain G token bridge, on-chain randomness, and the canonical EVM preinstalls. Written in the standard SKILL.md format, it works with Claude Code, Cursor, Codex, and 50+ other agents:

Once installed, the agent handles both developer and operator tasks directly: deploying contracts, reading state, sending transactions, and checking chain status.

Beyond Blockspace Economics

The standard L1 economic model treats blockspace as a scarce good: throughput is constrained, demand competes for inclusion, and the resulting fee pressure becomes the dominant sink of token value. Gravity’s launch parameters dissolve that assumption.

Fees on Gravity remain nonzero by design to prevent Sybil floods by giving every transaction a small, deterministic cost. That cost is high enough to make spam economically irrational and low enough to keep agent-scale workloads viable.

Value capture moves accordingly toward two new categories. The first is validator-provided services. Validators on Gravity not only order transactions, they attest external state through the native oracle, which makes their consensus signature the security layer underneath every bridge, price feed, and offchain attestation on the chain. Service-side revenue scales with the volume of attested data routed through that primitive, growing as more applications deploy to the network.

The second is the application layer. High-performance, low-cost blockspace lowers the floor for application unit economics, particularly for agent applications, high-frequency markets, and consumer-grade onchain activity. These are the use cases that have historically struggled on fee-scarce chains, where transaction cost forces application designs around batching, offchain settlement, or L2 abstractions. On Gravity, value accrual flows through the applications themselves rather than through fees on a constrained substrate.

The implications carry differently for each part of the network. Tokenholders depend on validator service revenue and application-layer adoption rather than fee burn or fee revenue. Validators earn from block production and from running consensus-attested services that extend the chain’s reach into oracle, bridging, and crosschain data territory. Application developers operate under different unit economics than they would on a fee-scarce chain, with cost no longer a primary constraint on the kinds of products they can build.

G Token Utility

G is the native gas and staking token on Gravity L1, with a maximum supply of 12 billion. The token originated from a 1:60 migration of the legacy GAL token and trades natively on Gravity L1 with ERC-20 representations on Ethereum, BNB Chain, and Base.

G has four core utilities:

• Gas - Every transaction on Gravity is paid in G. Standard ERC-20 transfers cost about 0.0026 G under benchmark parameters.
• Staking - Validators stake G to secure the network. The same staked weight underwrites consensus, native oracle attestations, and all derivative validator-provided services on the chain. Stakers earn rewards from block production and may be eligible for additional airdrops and rewards from applications across the Galxe ecosystem.
• Governance - G holders vote in the G DAO on protocol-level decisions, including native oracle callback registrations, validator-set changes, and economic parameter updates.
• Payment - G functions as the payment token across the Galxe product suite, including Galxe Quest, Passport, Score, and the broader application stack migrating to Gravity L1.

Looking Ahead

Gravity’s near-term priorities follow from its launch posture: a permissioned chain proving itself under Galxe’s production load, with the validator set, application surface, and oracle reach all expanding from there.

• Path to permissionless - The validator set will broaden on a controlled cadence as mainnet demonstrates it can carry production workloads without security incidents. The eventual goal is a fully permissionless network with no gating on validator entry, sequenced through staged onboarding rather than a single switchover.
• Crosschain oracle expansion - The native oracle currently supports a single end-to-end path (Ethereum to Gravity L1). The validator-attestation pipeline is built to extend to additional L1s and L2s, with each new source chain plugging into the same primitive through governance registration rather than a separate oracle network. Next directions include adding more EVM chains to the bridge, then expanding to non-asset data types such as price feeds and offchain attestations.
• Application onboarding and developer programs - Beyond the Galxe ecosystem migration, the team is preparing hackathons, builder grants, and ecosystem partnerships to bring third-party applications onto the network. These programs are gated on the foundation of proving itself under Galxe load first.
• Continued Reth and Paradigm Contributions - Several Gravity Reth optimizations have already been merged upstream into Paradigm’s Reth. The active collaboration covers RocksDB integration and a parallel storage schema designed for chains with billions of accounts, with additional contributions to follow as the work matures.
• Agent-app ecosystem build-out - The team is pursuing partnerships, grants, and integrations targeting AI-native applications built on Gravity, with the Skills tooling and native oracle infrastructure now serving as the substrate.

Closing Summary

Gravity launches as a high-performance EVM L1 anchored by three architectural choices that separate it from peer chains: parallel execution through Grevm and pipelined consensus through AptosBFT, native crosschain trust through validator-attested external state, and native agent tooling through installable Skills. The migration of Galxe’s existing application stack, along with the transaction volume it entails, gives the network a production-load proof point from day one rather than a cold start.

Gravity’s structural risks fall into three categories. The permissioned validator set keeps centralization on the table through the initial production phase, and the path to permissionless cadence is not yet publicly defined. Galxe’s dominance of early load means a single ecosystem dependency for stress-testing the network at scale, with the implications of that concentration not yet visible. The native oracle, while structurally sound at the consensus layer, inherits a new attack surface from each source chain whose state it ingests, expanding as the oracle’s coverage grows.

Gravity ships with parallel execution, a native oracle, and agent-native tooling, plus a production load with Galxe from day one. The chain’s success from here depends on validator expansion past the permissioned phase, native oracle coverage of additional source chains, and third-party application adoption beyond the Galxe ecosystem.