Run a Gravity Testnet Public Full Node
Run a Gravity Longevity Testnet (L1) Public Full Node. Covers binaries, testnet genesis artifacts, the public-network seed, deployment, database warm start, and sync verification for a PFN/RPC endpoin
This guide walks you through running a Public Full Node (PFN) on Gravity Longevity Testnet (L1, Chain ID 7771625). A PFN syncs from an upstream public or VFN seed and can serve EVM JSON-RPC for your applications, indexers, or internal services.
A PFN does not participate in consensus, does not hold validator stake, and does not require an invite. If you only need occasional reads or writes, you can use the public endpoint at https://testnet-rpc.gravity.xyz instead.
Required version. Longevity Testnet nodes must run v1.10.0-pre (or newer) to follow the live tip after Gamma. See Gravity Longevity Testnet Hardforks.
Placeholders. Commands below use
<YOUR_...>placeholders. Replace each value before running. Never commit private keys, generated identities, or node databases to version control.
Network Role
Gravity L1 separates node traffic into validator, VFN, and public networks. A PFN uses the public network and syncs outward from upstream infrastructure:
validators --VFN net--> VFN --public net--> PFN / RPC --> app or indexerUse a PFN when you want:
a private or high-throughput JSON-RPC endpoint on testnet;
a node close to your backend or indexer;
independent chain data for analytics or monitoring;
no validator-set or governance operations.
Prerequisites
A Linux x86-64 host. Production-like nodes are built and run on Ubuntu 24.04 LTS. Build on the same OS family that you deploy to.
gravity_nodeandgravity_cli. Build from source:git clone https://github.com/Galxe/gravity-sdk.git cd gravity-sdk git checkout v1.10.0-pre RUSTFLAGS="--cfg tokio_unstable" \ cargo build --profile quick-release -p gravity_node -p gravity_cliThe binaries land in
target/quick-release/. You can also download the v1.10.0-pre release assets (gravity_node,gravity_cli). Forgravity_clicommand usage, see the Gravity CLI Skill.Testnet
genesis.jsonandwaypoint.txt. These artifacts pin the exact chain you are joining. Download the canonical files fromgravity-sdk/genesis/testnet; do not regenerate genesis locally for the public testnet.An upstream public-network seed. For the seed you need its
peer_id, host, public port, andnetwork_public_key. The current public testnet PFN seed is listed below.SSD/NVMe storage. Chain data grows with uptime. Budget well above the current chain size.
1. Prepare Genesis Artifacts
Place the canonical testnet artifacts where your cluster config references them:
If the artifacts live elsewhere, you can point to absolute paths in genesis_source:
The genesis.json and waypoint.txt must match each other. A wrong pair can start a node on a different chain identity and prevent it from syncing testnet.
Confirm the downloaded genesis includes the live hardfork fields (pragueTime, alphaTime, betaTime, osakaTime, gammaTime). See Longevity Testnet Hardforks.
2. Gather Seed Information
Current Testnet PFN Connectivity
testnet-rpc-p2p-1
testnet-rpc-p2p-1.gravity.xyz
https://testnet-rpc.gravity.xyz
6195
e7ddaced105af1c4381ca670cea01b0a8e3006c7e360a4f4e40e79fe06c29433
86d3bd6c81fb6994bdbe8df40da28acf44433138cb09ad491c4d98637abd817a
For normal JSON-RPC traffic, prefer the aggregate endpoint:
Before using the PFN host as an upstream seed, verify from your node host that the public-network port is reachable:
Use the current public testnet PFN seed directly in local-pfn.toml.
For an explicit PFN seed, fill these values from the upstream node's public identity:
<YOUR_UPSTREAM_PEER_ID>
Upstream sidecar account_address.
<YOUR_UPSTREAM_HOST>
DNS name or IP address of the upstream public listener.
<YOUR_UPSTREAM_PUBLIC_PORT>
Public-network port exposed by the upstream node.
<YOUR_UPSTREAM_NETWORK_PUBLIC_KEY>
Upstream sidecar network_public_key.
Prefer explicit seed entries over seeds = [{ from = "<id>" }] for a standalone PFN config. The { from = ... } form only works when the seed node is also defined in the same TOML file.
3. Write local-pfn.toml
Create a config such as:
Port choices can be changed if you run multiple nodes on one host. Keep the RPC port private unless you intentionally expose it behind your own gateway, authentication, rate limiting, and monitoring.
prune_transactionlookup_distance = 10064 starts reth with --full --prune.transactionlookup.distance 10064. This keeps recent transaction-hash lookup data while allowing older transaction lookup indexes to be pruned. Use a value greater than or equal to 10064 for production-like PFN/RPC nodes.
Use transaction-lookup pruning when you want lower execution database growth and do not need arbitrary old eth_getTransactionByHash lookups from this node.
If you omit prune_transactionlookup_distance, the generated PFN reth config uses archive-style storage for transaction lookups and keeps historical lookup indexes instead of pruning them. That is simpler for indexers or debugging flows that need old transaction hashes, but it uses more disk over time.
Do not set prune_transactionlookup_distance = 0 to disable pruning. A distance of 0 is still a pruning mode and can prune transaction lookup data aggressively. To run without transaction-lookup pruning, leave the field out.
The example above generates and stores identity files locally. In production-like environments, you can also load the node identity from a secret manager. For example:
Pin a fixed secret version instead of latest when you want reproducible deployments and safer rollbacks.
4. Generate Identity and Deploy
From the SDK cluster directory:
Expected layout:
If the package is generated on a build host, copy it to the runtime host while preserving the node directory layout.
5. Optional: Warm Start From a Snapshot or Existing Node
A new PFN can sync from genesis, but that may take a long time on an established testnet.
Option A: Download the Public Testnet Data Snapshot
Gravity publishes daily Longevity Testnet PFN data snapshots in the public bucket. List available dates:
Pick the latest date and download it. For example, use 2026-09-01 for gravity-testnet-data/2026-09-01.tar:
Before the first start, replace the generated empty data directory with the snapshot data:
After extraction, the data directory should contain the snapshot databases while preserving the node directory layout:
Option B: Copy From an Existing Node You Control
If you already run a trusted RPC/PFN, you can copy only the chain databases from that node:
Do not copy rand_db or secure_storage.json from another node. Those files carry node-specific randomness or safety state and should not be reused.
6. Start the Node
Check the logs under the node directory:
7. Verify Sync
Confirm that your local node is on the testnet chain:
The expected result is 0x7695e9, which is decimal 7771625.
Query your local node:
Compare it with the public chain head:
When the two heights are close and your local height keeps advancing, the node is caught up. Gravity has BFT-final blocks: once a block is returned by your node, there is no EVM-style reorg to wait for.
Troubleshooting
seeds: from=<id>: missing host or public_port in cluster.toml
Use an explicit peer_id / address seed, or define the seed node in the same TOML.
Node stays at a low height
Re-check seed peer_id, host, port, network public key, genesis.json, and waypoint.txt.
eth_chainId is not 0x7695e9
The node is not using the canonical testnet genesis or RPC target. Re-check genesis_source and the public RPC URL.
net_peerCount returns 0
Usually expected. Gravity syncs through AptosBFT/VFN/public networks, not EVM devp2p gossip. Watch block height instead.
RPC unavailable
Confirm rpc_port is free, the process is running, and logs exist under the deploy directory.
Database paths look nested incorrectly
data_dir should be the deploy directory. Storage is rendered to $data_dir/data.
See Also
Last updated
Was this helpful?

