Harmony RPC: Sharding, Finality, and What Changed After 2022

By John Sullivan · January 1, 1970 · 5 min read

Harmony was one of the first major chains to bet on sharding as the path to scale. With 4 shards running in parallel, 2-second block times, and theoretical throughput of thousands of transactions per second, it was positioned as a high-performance alternative to Ethereum. Then the $100M bridge exploit in June 2022 changed everything. The chain is still running, the RPC still works, and for developers building on Harmony, the fundamentals haven't changed. Here's what you need to know.

What Harmony actually is

Harmony is a sharded Layer 1 blockchain using Proof of Stake consensus. Unlike most chains that process all transactions in a single sequence, Harmony splits its state across 4 shards, each processing transactions in parallel. This gives it higher theoretical throughput than single-chain architectures.

Key specs:

  • Chain ID: 1666600000 (0x63564C40)
  • Shard 0 block time: ~2 seconds
  • Gas token: ONE
  • Consensus: Proof of Stake with BFT finality
  • Shards: 4 (shard 0 is the beacon chain)
  • EVM compatibility: Full (on shard 0)

The architecture is distinct from both Ethereum L2s and other L1s. Each shard has its own set of validators and processes its own transactions. Cross-shard transactions are handled by the beacon chain (shard 0), which coordinates state between shards.

For most developers, you'll interact with shard 0 — it's where the EVM compatibility lives and where most dApps are deployed. The other shards exist but have limited adoption.

The RPC: Standard Ethereum JSON-RPC (with caveats)

Harmony exposes the standard Ethereum JSON-RPC interface on shard 0. If you've built against Ethereum, the core methods work as expected.

# Chain ID
curl -s -X POST https://rpc.swiftnodes.io/rpc/harmony?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x63564c40"}

# Latest block
curl -s -X POST https://rpc.swiftnodes.io/rpc/harmony?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x592a771"}  # ~93M

The core methods work as expected:

Method What it gives you
eth_chainId Chain ID (1666600000 / 0x63564C40)
eth_blockNumber Latest block height (shard 0)
eth_getBlockByNumber Block by number (with or without full txs)
eth_getBalance ONE balance for an address
eth_call Execute a call without creating a transaction
eth_sendRawTransaction Submit a signed transaction
eth_getLogs Query event logs

Important: All queries default to shard 0. If you need to query other shards, you'll need to use shard-specific endpoints (not widely supported by third-party providers).

Gas fees and block structure

Harmony's gas fees are consistently low, typically under 1 gwei. The 2-second block times mean transactions confirm quickly, though you should wait for a few blocks for finality.

# Block with transactions
curl -s -X POST https://rpc.swiftnodes.io/rpc/harmony?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":{"number":"0x592a771","timestamp":"0x6a9bafb3","transactions":[...]}}

Blocks on shard 0 contain a moderate number of transactions. While Harmony's theoretical throughput is high (thousands of TPS across all shards), actual usage is concentrated on shard 0.

What happened in 2022 (and why it matters)

In June 2022, Harmony's Rainbow Bridge was exploited for approximately $100M in wrapped assets. The exploit compromised validator keys, allowing the attacker to forge cross-shard transactions.

What changed:

  • The bridge was paused and later relaunched with additional security measures
  • Validator set was restructured
  • Development pace slowed significantly
  • TVL and user activity dropped sharply

What didn't change:

  • The chain itself continued operating
  • Block production never stopped
  • RPC endpoints remained functional
  • Existing dApps on shard 0 continued working

For developers querying the chain via RPC, the exploit doesn't affect your ability to read state, submit transactions, or interact with contracts on shard 0. The chain's consensus and execution layer remained intact.

If you're building new applications on Harmony, you should be aware of the reduced ecosystem activity and smaller developer community compared to 2021-2022.

eth_getLogs and range caps

Like most chains, Harmony imposes range caps on eth_getLogs to prevent abuse. If you're querying logs for a contract that emits a lot of events, you'll need to chunk your queries into smaller block ranges.

A safe default is 10,000 blocks per query. If you need to scan a wider range, loop through it in chunks:

const FROM_BLOCK = 90000000;
const TO_BLOCK = 93000000;
const CHUNK_SIZE = 10000;

for (let i = FROM_BLOCK; i < TO_BLOCK; i += CHUNK_SIZE) {
  const logs = await provider.getLogs({
    address: "0x...",
    fromBlock: i,
    toBlock: Math.min(i + CHUNK_SIZE - 1, TO_BLOCK),
  });
  // Process logs
}

Trace methods and archive access

Harmony's standard RPC does not support trace_block, trace_transaction, or debug_traceCall. These methods require an archive node with tracing enabled, which is a different (and more expensive) infrastructure setup.

If you need internal transactions, contract creation traces, or state diffs at a specific block, you'll need to use a dedicated archive provider or query the chain's block explorer API.

For most dApp use cases — reading balances, submitting transactions, querying logs — the standard RPC is sufficient.

Finality and cross-shard considerations

Harmony uses BFT consensus with single-block finality on each shard. Once a block is committed by the shard's validator set, it's final. No reorgs, no probabilistic confirmation waits.

However, cross-shard transactions add complexity. If your application needs to interact with state on multiple shards, you're relying on the beacon chain's cross-shard messaging, which has different timing characteristics.

For most developers staying on shard 0, this isn't a concern. Your transactions have the same finality guarantees as any other BFT chain.

The short version

Harmony is a sharded L1 with 4 parallel chains. Chain ID 1666600000, ~2 second blocks on shard 0, gas fees under 1 gwei. Standard Ethereum JSON-RPC — if you've built on Ethereum, you already know how to query it. Uses ONE for gas.

The 2022 bridge exploit reduced ecosystem activity but didn't break the chain. Block production continued, RPC endpoints stayed live, and shard 0 remains fully functional.

For reliable Harmony RPC access across load-balanced nodes, grab a free API key and point your app at:

https://rpc.swiftnodes.io/rpc/harmony?key=YOUR_API_KEY
J
John Sullivan
Infrastructure Writer, SwiftNodes

John Sullivan covers RPC infrastructure, node operations, and multi-chain development at SwiftNodes — what it actually takes to keep endpoints fast, fresh, and reliable across EVM and non-EVM networks.

Try SwiftNodes free — multi-chain RPC across 75+ networks, flat-rate pricing, pay by card or crypto, no KYC. Get an API key in 30 seconds →