DEV Community: SwiftNodes

Tron RPC: USDT-TRC20, TVM, and the Stablecoin Rail

SwiftNodes — Wed, 09 Sep 2026 05:31:02 +0000

Tron isn't just another blockchain — it's the world's largest stablecoin rail. With over $50 billion in USDT supply, more than any single chain, Tron has become the default infrastructure for cross-border value transfer, especially in Asia and Latin America. If you're building anything related to stablecoins or emerging markets, you need to understand Tron's RPC.

What Tron actually is

Tron is a high-throughput blockchain launched in June 2018, focused on decentralized content and entertainment. It uses Delegated Proof-of-Stake (DPoS) with 27 active Super Representatives producing blocks every 3 seconds.

Key specs:

Network: Mainnet (non-EVM, uses its own identifier)
Block time: ~3 seconds
Consensus: Delegated Proof-of-Stake (27 Super Representatives)
Native token: TRX (6 decimals)
Virtual Machine: TVM (TRON Virtual Machine) — largely Solidity-compatible
Primary use case: Stablecoin transfers (USDT-TRC20)

The TVM (TRON Virtual Machine) is largely Solidity-compatible, allowing Ethereum contracts to be ported with minor changes. However, Tron is non-EVM — it doesn't use Ethereum's JSON-RPC interface. Instead, Tron exposes its own HTTP API and gRPC endpoints.

The RPC: HTTP API and gRPC, not JSON-RPC

Here's where most Ethereum developers get tripped up. Tron doesn't use eth_blockNumber, eth_getBalance, or any of the standard Ethereum JSON-RPC methods. Instead, Tron has its own HTTP API with different endpoints and response formats.

# Get current block (Tron HTTP API)
curl -X POST https://rpc.swiftnodes.io/rpc/tron -H 'Content-Type: application/json' -d '{
  "jsonrpc": "2.0",
  "method": "wallet/getnowblock",
  "params": {},
  "id": 1
}'

# Get account balance
curl -X POST https://rpc.swiftnodes.io/rpc/tron -H 'Content-Type: application/json' -d '{
  "jsonrpc": "2.0",
  "method": "wallet/getaccount",
  "params": {
    "address": "TYourAddressHere"
  },
  "id": 1
}'

# Get TRC20 token balance (USDT)
curl -X POST https://rpc.swiftnodes.io/rpc/tron -H 'Content-Type: application/json' -d '{
  "jsonrpc": "2.0",
  "method": "wallet/triggersmartcontract",
  "params": {
    "owner_address": "TYourAddressHere",
    "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
    "function_selector": "balanceOf(address)",
    "parameter": "000000000000000000000000TYourAddressHere"
  },
  "id": 1
}'

The core methods you'll use:

Method	What it gives you
`wallet/getnowblock`	Current block info
`wallet/getblock`	Block by number or ID
`wallet/getaccount`	Account info and TRX balance
`wallet/getcontract`	Smart contract info
`wallet/triggersmartcontract`	Call smart contract (read-only)
`wallet/broadcasttransaction`	Broadcast signed transaction

TVM: Solidity-compatible, but not identical

Tron's TVM (TRON Virtual Machine) is largely compatible with Solidity, which means you can port most Ethereum contracts to Tron with minor adjustments. However, there are important differences:

Address format: Tron uses base58 addresses starting with T (like TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t for USDT), not Ethereum's hex addresses.
Energy and bandwidth: Tron uses a dual-resource model. Transactions consume bandwidth (for basic transfers) and energy (for smart contract execution). You can stake TRX to get these resources, or pay fees in TRX.
Precompiles: Some Ethereum precompiles behave differently or don't exist on Tron. Test thoroughly if porting contracts.
Gas mechanics: While TVM uses "energy" similar to gas, the calculation and limits differ from Ethereum.

Here's what a simple TRC20 transfer looks like in Solidity for Tron:

pragma solidity ^0.8.0;

import "./TRC20.sol";

contract MyToken is TRC20 {
    constructor() TRC20("MyToken", "MTK") {
        _mint(msg.sender, 1000000 * 10 ** decimals());
    }
}

The code looks identical to Ethereum, but the deployment and interaction use Tron's HTTP API, not eth_sendRawTransaction.

USDT-TRC20: The dominant stablecoin

Tron's killer feature is USDT-TRC20. Tether on Tron has over $50 billion in supply, more than any single chain. This makes Tron the most-used chain globally for cross-border value transfer.

Why? Sub-cent fees and 3-second finality. Sending $10,000 USDT on Tron costs less than $1 and settles in seconds. Compare that to Ethereum's variable gas fees and 12-second blocks, and you can see why emerging markets have adopted Tron for remittances.

To query USDT balances or transfers, you'll interact with the USDT contract at TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t:

# Get USDT balance for an address
curl -X POST https://rpc.swiftnodes.io/rpc/tron -H 'Content-Type: application/json' -d '{
  "jsonrpc": "2.0",
  "method": "wallet/triggersmartcontract",
  "params": {
    "owner_address": "TYourAddressHere",
    "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
    "function_selector": "balanceOf(address)",
    "parameter": "000000000000000000000000TYourAddressHere"
  },
  "id": 1
}'

The response includes the balance in the constant_result field, which you'll need to decode from hex.

How this compares to other chains

Tron is often compared to other high-throughput chains, but its focus on stablecoins makes it unique:

Ethereum has higher decentralization and a larger developer ecosystem, but higher fees and slower blocks. Ethereum is better for DeFi and NFTs; Tron is better for stablecoin transfers.
BSC is EVM-compatible with lower fees than Ethereum, but Tron has even lower fees and is more focused on stablecoins.
Solana offers similar throughput and low fees, but uses a different programming model (Rust vs Solidity). Tron's Solidity compatibility makes it easier for Ethereum developers to port contracts.

From an RPC perspective, Tron is fundamentally different. You can't use ethers.js or viem directly — you need Tron-specific libraries like TronWeb or the HTTP API.

Transaction submission

Submitting transactions on Tron is also different. The flow is:

Create transaction: Use wallet/createtransaction (for TRX transfers) or wallet/triggersmartcontract (for contract calls)
Sign transaction: Sign locally with the private key (Tron uses ECDSA like Ethereum, but with different address derivation)
Broadcast transaction: Use wallet/broadcasttransaction to submit

TronWeb (the JavaScript SDK) handles most of this for you, but it's still a different workflow than Ethereum's eth_sendRawTransaction.

The short version

Tron is a high-throughput blockchain focused on stablecoin transfers. 3-second blocks, DPoS consensus with 27 Super Representatives, and the TVM (largely Solidity-compatible). Uses HTTP API and gRPC — not Ethereum JSON-RPC. Native token is TRX (6 decimals).

For stablecoin applications — especially USDT transfers and emerging market remittances — Tron is where the volume is. USDT-TRC20 has over $50B in supply, making it the largest stablecoin deployment on any chain.

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

https://rpc.swiftnodes.io/rpc/tron?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Aptos RPC: Move Language, Parallel Execution, and REST API

SwiftNodes — Tue, 08 Sep 2026 06:29:17 +0000

Aptos is a Layer 1 blockchain built by former Meta (Diem) engineers, and it's fundamentally different from the EVM chains most developers are used to. No JSON-RPC, no Solidity, no EVM. Instead, Aptos uses a REST API, the Move programming language, and a parallel execution engine called Block-STM. If you're coming from Ethereum, everything is different — and that's the point.

What Aptos actually is

Aptos is a high-throughput Layer 1 designed for sub-second finality and massive parallel transaction processing. It launched mainnet in October 2022 after years of development stemming from Meta's Diem project.

Key specs:

Chain ID: 1 (in Aptos terms, not EVM)
Block time: ~1 second
Finality: Sub-second (deterministic via AptosBFT)
Gas token: APT (8 decimals)
Consensus: AptosBFT (Jolteon-based proof-of-stake)
Execution: Block-STM (parallel execution engine)
Smart contracts: Move language (not Solidity)

The architecture is built around three core innovations:

Move language: A resource-oriented programming language designed for safe digital asset management. Unlike Solidity's account model, Move treats assets as resources that can't be copied or accidentally discarded.
Block-STM: A parallel execution engine that runs transactions optimistically in parallel and re-executes only those that conflict. This extracts parallelism without requiring developers to declare dependencies upfront.
AptosBFT: A consensus mechanism based on Jolteon, providing deterministic finality in sub-second time. Once a block is committed, it's final — no reorgs, no probabilistic confirmation waits.

The API: REST, not JSON-RPC

Here's where most Ethereum developers get tripped up. Aptos doesn't use JSON-RPC. It uses a REST API (the Aptos fullnode API). If you're trying to use ethers.js or viem, you're in the wrong place.

# Get ledger info (chain state)
curl -s https://rpc.swiftnodes.io/rpc/aptos | jq .

# Get account info
curl -s https://rpc.swiftnodes.io/rpc/aptos/accounts/0x1 | jq .

# Get account resource (e.g., coin balance)
curl -s https://rpc.swiftnodes.io/rpc/aptos/accounts/0x1/resource/0x1::coin::CoinStore<0x1::aptos_coin::AptosCoin> | jq .

The core endpoints you'll use:

Endpoint	What it gives you
`/`	Ledger info (chain ID, epoch, block height, timestamp)
`/accounts/{address}`	Account info (sequence number, authentication key)
`/accounts/{address}/resource/{resource_type}`	Account resource (balances, module state)
`/accounts/{address}/modules`	Deployed Move modules
`/transactions`	Submit or query transactions
`/blocks/by_height/{height}`	Block by height

Move language: Resources, not accounts

Move is the heart of Aptos, and it's unlike any smart contract language you've used. The key concept: resources.

In Solidity, balances are just numbers in a mapping. In Move, coins are resources that:

Can't be copied (no accidental inflation)
Can't be discarded (no accidental loss)
Must be explicitly moved or destroyed

Here's what a simple coin transfer looks like in Move:

public entry fun transfer<CoinType>(
    from: &signer,
    to: address,
    amount: u64
) acquires CoinStore {
    // Withdraw from sender
    let coins = Coin::withdraw<CoinType>(from, amount);
    // Deposit to recipient
    Coin::deposit<CoinType>(to, coins);
}

The type system ensures that coins can't be copied or dropped — it must be deposited somewhere. This eliminates entire classes of bugs that plague Solidity contracts.

Block-STM: Parallel execution without the hassle

Most blockchains execute transactions sequentially. If you have 100 transactions in a block, they run one after another. Aptos does something different.

Block-STM runs all transactions in a block optimistically in parallel. If two transactions conflict (they touch the same state), Block-STM detects the conflict and re-executes only the conflicting transactions. The result: you get parallel execution benefits without having to manually declare dependencies or worry about ordering.

For developers, this means:

Write contracts as if execution is sequential
The runtime handles parallelization automatically
High throughput without the complexity

How this compares to other chains

Aptos is often compared to Sui, which also uses Move. The difference: Aptos uses an account-based model (like Ethereum), while Sui uses an object-based model. Aptos is closer to what Ethereum developers expect, but with Move's safety guarantees.

Compared to Solana, Aptos offers similar throughput but with deterministic finality (Solana has probabilistic finality with reorg risk). Aptos also uses Move instead of Rust, which is more specialized for blockchain but has a steeper learning curve.

Compared to Cosmos chains, Aptos is a single monolithic chain (not an appchain framework). You're trading customization for simplicity and performance.

Querying account state

In Ethereum, you query balances with eth_getBalance. In Aptos, you query resources. Every piece of state is a resource stored under an account.

# Get APT balance for an account
curl -s "https://rpc.swiftnodes.io/rpc/aptos/accounts/0x1/resource/0x1::coin::CoinStore<0x1::aptos_coin::AptosCoin>" | jq .

# Response includes:
# {
#   "data": {
#     "coin": { "value": "1000000000" },  // 10 APT (8 decimals)
#     "frozen": false,
#     "deposit_events": { ... },
#     "withdraw_events": { ... }
#   }
# }

The resource type is a fully qualified Move module path: 0x1::coin::CoinStore<0x1::aptos_coin::AptosCoin>. This is verbose but explicit — you know exactly what you're querying.

Transaction submission

Submitting transactions is also different. You don't just sign and send raw transactions. You:

Build a transaction payload (specifying the Move function to call)
Simulate the transaction (optional but recommended)
Sign with your account's private key
Submit via the /transactions endpoint

The Aptos TypeScript SDK handles most of this for you, but it's still a different workflow than Ethereum's eth_sendRawTransaction.

The short version

Aptos is a high-performance L1 using Move language and Block-STM parallel execution. Chain ID 1, ~1 second blocks, sub-second finality. REST API (not JSON-RPC), APT token (8 decimals). Smart contracts in Move (not Solidity).

For developers building high-throughput applications — DeFi, gaming, consumer apps — Aptos offers Ethereum-like account model with Move's safety guarantees and parallel execution performance.

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

https://rpc.swiftnodes.io/rpc/aptos?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

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

SwiftNodes — Mon, 07 Sep 2026 05:25:36 +0000

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

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Polygon RPC: The Gateway L2 for High-Throughput dApps

SwiftNodes — Sun, 06 Sep 2026 11:38:14 +0000

Polygon PoS is the scaling solution that proved Ethereum could scale without waiting for rollups to mature. With 1.5-second block times, gas fees that rarely exceed 1 gwei, and over 93 million blocks processed, Polygon has become the default home for dApps that need throughput today, not someday.

What Polygon actually is

Polygon PoS is a sidechain to Ethereum, not a rollup. It runs its own consensus mechanism (Proof of Stake with a validator set) and periodically anchors state to Ethereum for security. This is fundamentally different from Optimism, Arbitrum, or Base, which are optimistic rollups that inherit Ethereum's security directly.

The tradeoff: Polygon offers faster finality (2 seconds vs 2 minutes for rollups) and lower fees, but you're trusting the Polygon validator set rather than Ethereum validators directly. For most applications, this is an acceptable tradeoff — Polygon has been running since 2020 with over 300 validators and has never had a consensus failure.

Key specs:

Chain ID: 137 (0x89)
Block time: ~1.5 seconds
Gas token: POL (formerly MATIC)
Consensus: Proof of Stake with checkpointing to Ethereum
EVM compatibility: Full (same opcodes, same tooling)

Polygon also operates Polygon zkEVM, a separate Type 1 zkEVM chain that uses zero-knowledge proofs for Ethereum-equivalent execution. That's a different chain (chain ID 1101) with different tradeoffs. This post focuses on Polygon PoS, the high-throughput sidechain.

The RPC: Standard Ethereum JSON-RPC

Polygon exposes the standard Ethereum JSON-RPC interface. If you've built against Ethereum mainnet, you already know how to query Polygon.

# Chain ID
curl -s -X POST https://rpc.swiftnodes.io/rpc/polygon?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":"0x89"}

# Latest block
curl -s -X POST https://rpc.swiftnodes.io/rpc/polygon?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":"0x590a5ae"}  # ~93M

The core methods work as expected:

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

Gas fees and block structure

Polygon's gas fees are consistently low. While Ethereum mainnet can spike to 50-200 gwei during congestion, Polygon typically stays under 1 gwei. A typical swap on Uniswap V3 (deployed on Polygon) costs fractions of a cent.

Blocks arrive every ~1.5 seconds and contain hundreds of transactions. Polygon processes more daily transactions than most L2s combined, making it one of the most active chains in the ecosystem.

# Gas price
curl -s -X POST https://rpc.swiftnodes.io/rpc/polygon?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x6fc23ac00"}  # ~30 gwei in wei

# Block with transactions
curl -s -X POST https://rpc.swiftnodes.io/rpc/polygon?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":"0x590a5ae","timestamp":"0x6a9bafb3","transactions":[...]}}

What's different from rollups

Polygon PoS is often grouped with L2s, but it's architecturally distinct:

Optimism/Arbitrum/Base are optimistic rollups. They post transaction data to Ethereum and rely on fraud proofs for security. Finality takes ~7 days for withdrawals (or ~1 hour with fast-bridge services).
Polygon PoS is a sidechain. It runs its own consensus and periodically checkpoints to Ethereum. Finality is ~2 minutes for deposits, ~30 minutes for withdrawals via the official bridge.
Polygon zkEVM is a Type 1 zkEVM rollup. It uses zero-knowledge proofs for validity, offering stronger security guarantees than PoS but with higher gas fees and slower block times.

From an RPC perspective, they're all EVM-compatible. You can use the same tooling — ethers.js, viem, Hardhat, Foundry — against any of them. The chain ID is the only thing that changes.

eth_getLogs and range caps

Like most high-throughput chains, Polygon 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.

The exact cap varies by provider, but 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

Polygon'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.

Bridging and finality

Assets move between Polygon and Ethereum via the official Polygon bridge (https://portal.polygon.technology/bridge) or third-party bridges like Across, Hop, and Stargate.

Deposits (Ethereum → Polygon): ~20-30 minutes via the official bridge
Withdrawals (Polygon → Ethereum): ~30 minutes via the official bridge (faster than rollups' 7-day challenge window)

Polygon's checkpoint mechanism anchors state to Ethereum every ~30 minutes. Once a checkpoint is confirmed on Ethereum, the corresponding Polygon blocks are considered finalized. This is faster than optimistic rollups but slower than chains with instant finality like Solana or Avalanche.

The short version

Polygon PoS is a high-throughput sidechain for Ethereum. Chain ID 137, ~1.5 second blocks, gas fees typically under 1 gwei. Standard Ethereum JSON-RPC — if you've built on Ethereum, you already know how to query it. Uses POL (formerly MATIC) for gas.

For dApps that need throughput today — DeFi, NFTs, gaming, social — Polygon is where the users are. Uniswap V3, Aave, OpenSea, and thousands of other dApps have made it one of the most active chains by daily transactions.

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

https://rpc.swiftnodes.io/rpc/polygon?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Base RPC: Coinbase's OP Stack L2 for Consumer dApps

SwiftNodes — Sat, 05 Sep 2026 06:13:41 +0000

Base has quietly become one of the most active Layer 2s on Ethereum. Built by Coinbase on the OP Stack, it offers the same EVM compatibility developers expect from Ethereum mainnet, but with ~2 second block times and gas fees that hover around 0.01 gwei. If you're building consumer-facing dApps — trading, payments, social — Base is where the users are.

What Base actually is

Base is an optimistic rollup built on the OP Stack, the same framework that powers Optimism. It launched in August 2023 and has grown to consistently rank in the top 3 L2s by daily transactions.

The architecture:

Execution layer: OP Stack (Geth-based), fully EVM-compatible
Security: Inherits from Ethereum via fault proofs
Sequencer: Currently operated by Coinbase (with stated intent to decentralize)
Gas token: ETH
Chain ID: 8453

Base is part of the Optimism Superchain — a network of OP Stack chains that share sequencer infrastructure, governance frameworks, and bridging primitives. Other Superchain members include Optimism itself, Mode, Zora, and opBNB.

The chain has become a hub for consumer-grade dApps: Aerodrome (the dominant DEX), Uniswap V3, Aave V3, Friend.tech (which drove a massive spike in 2023), Farcaster (decentralized social), and a wave of memecoins. Coinbase's wallet integration gives Base a direct on-ramp for millions of users.

The RPC: Standard Ethereum JSON-RPC

Base exposes the standard Ethereum JSON-RPC interface. If you've built against Ethereum mainnet, you already know how to query Base.

# Chain ID
curl -s -X POST https://rpc.swiftnodes.io/rpc/base?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":"0x2105"}

# Latest block
curl -s -X POST https://rpc.swiftnodes.io/rpc/base?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":"0x308a968"}  # ~50.8M

The core methods work as expected:

Method	What it gives you
`eth_chainId`	Chain ID (8453 / 0x2105)
`eth_blockNumber`	Latest block height
`eth_getBlockByNumber`	Block by number (with or without full txs)
`eth_getBalance`	ETH balance for an address
`eth_call`	Execute a call without creating a transaction
`eth_sendRawTransaction`	Submit a signed transaction
`eth_getLogs`	Query event logs (with range caps — see below)

Gas fees and block structure

Base's gas fees are among the lowest in the L2 ecosystem. At the time of writing, gas prices hover around 0.01 gwei — roughly 100x cheaper than Ethereum mainnet. A typical swap on Aerodrome costs fractions of a cent.

Blocks arrive every ~2 seconds and contain around 150-200 transactions. That's a healthy throughput for a consumer-focused chain.

# Gas price
curl -s -X POST https://rpc.swiftnodes.io/rpc/base?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x2540be400"}  # ~10 gwei in wei

# Block with transactions
curl -s -X POST https://rpc.swiftnodes.io/rpc/base?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":"0x308a968","timestamp":"0x6a9bafb3","transactions":[...]}}

What's different from other L2s

Base shares the OP Stack with Optimism, so the RPC surface is identical. The differences are in the ecosystem and sequencing:

Optimism is the "original" OP Stack chain, with a focus on protocol development and the Superchain vision. OP token governs the protocol.
Base is Coinbase's deployment, optimized for consumer dApps and wallet integration. No native token — gas is paid in ETH.
Arbitrum uses a different stack (Nitro, derived from Geth but not OP Stack). It has a different fee model and a different governance token (ARB).

From an RPC perspective, they're all EVM-compatible. You can use the same tooling — ethers.js, viem, Hardhat, Foundry — against any of them. The chain ID is the only thing that changes.

eth_getLogs and range caps

Like most L2s, Base 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.

The exact cap varies by provider, but 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 = 50000000;
const TO_BLOCK = 50800000;
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

Base'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.

Bridging and finality

Assets move between Base and Ethereum via the official Base bridge (https://bridge.base.org) or third-party bridges like Across, Hop, and Squid.

Deposits (Ethereum → Base): ~10-15 minutes via the official bridge
Withdrawals (Base → Ethereum): 7 days via the official bridge (the challenge window for optimistic rollups), or instant via third-party bridges

Base inherits Ethereum's security through fault proofs. If a sequencer proposes an invalid state root, there's a 7-day window for challengers to dispute it. This is the tradeoff for optimistic rollups: fast deposits, but withdrawals take time unless you use a fast-bridge service.

The short version

Base is Coinbase's OP Stack L2 on Ethereum. Chain ID 8453, ~2 second blocks, gas fees around 0.01 gwei. Standard Ethereum JSON-RPC — if you've built on Ethereum, you already know how to query it. Part of the Optimism Superchain alongside Optimism, Mode, and Zora. Gas paid in ETH. No native token.

For consumer dApps — trading, payments, social — Base is where the users are. Aerodrome, Uniswap V3, Aave, Farcaster, and a wave of memecoins have made it one of the most active L2s by daily transactions.

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

https://rpc.swiftnodes.io/rpc/base?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

dYdX RPC: Querying a Decentralized Perpetuals Exchange

SwiftNodes — Fri, 04 Sep 2026 05:54:06 +0000

dYdX Chain is one of the more architecturally distinctive chains in the Cosmos ecosystem, because the entire chain exists to serve a single application: a decentralized perpetual-futures exchange. The orderbook is off-chain, settlement is on-chain, and the validators themselves run the matching engine. Developers who connect an RPC endpoint to dYdX often expect a standard Cosmos pattern and miss the parts that make it different. Here's the map.

What dYdX actually does

dYdX is a decentralized perpetual-futures exchange built on the Cosmos SDK with CometBFT consensus. The pitch: trade perpetual contracts with the speed of a centralized exchange, but keep your funds in self-custody. The chain handles order matching, trade settlement, liquidations, and funding rate calculations — all on-chain, all with sub-second block times.

The numbers as of September 2026: $1.6 trillion in lifetime trading volume, 99+ listed markets, and open interest in the tens of millions. The chain migrated from an Ethereum L2 (dYdX v3, StarkEx-powered) to a sovereign Cosmos SDK appchain (dYdX v4) on October 27, 2023. The migration was driven by the need for lower latency, higher throughput, and full control over the execution environment — things that are hard to achieve when your settlement layer is someone else's chain.

The architecture has three layers:

Off-chain orderbook: Each validator runs an in-memory orderbook. Orders are gossiped peer-to-peer and matched locally. This is what gives dYdX its speed — matching happens in memory, not through consensus.
On-chain settlement: When orders match, the resulting trades are proposed as transactions and committed through CometBFT consensus. This is where the chain comes in — recording trades, updating positions, handling liquidations.
Indexer API: A separate indexer aggregates on-chain state into a queryable API for the frontend. Most users and dashboards read from the indexer, not directly from the chain.

Perpetuals are margined in Noble USDC bridged onto the chain via IBC. The native DYDX token (18 decimals, base denom adydx) is used for staking and governance — not as trading collateral.

The RPC: CometBFT JSON-RPC, same as other Cosmos chains

dYdX Chain runs on dydx-mainnet-1, uses CometBFT v0.38.x, has sub-second blocks (~0.7s in practice), and exposes the standard CometBFT JSON-RPC surface. No eth_*, no EVM. The chain ID is the string dydx-mainnet-1, not a numeric EVM ID.

SwiftNodes serves the CometBFT JSON-RPC endpoint:

# Node status
curl -s -X POST https://rpc.swiftnodes.io/rpc/dydx?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"status","params":[],"id":1}'
# -> {"result":{"node_info":{"network":"dydx-mainnet-1",...},"sync_info":{"latest_block_height":"104059712",...}}}

The core methods you'll use:

Method	What it gives you
`status`	Node info, latest block height, sync state, network ID
`block`	A block by height — header, transactions, last commit
`block_results`	Transaction results and events for a block
`broadcast_tx_sync` / `_commit`	Submit a signed transaction
`tx`	Look up a transaction by hash

These are the consensus-layer queries — reading blocks, monitoring chain activity, broadcasting transactions. They work the same way across every Cosmos chain.

Where the special part lives: dYdX modules

Here's where dYdX diverges from a plain Cosmos chain. The trading state — perpetual markets, positions, orders, fills — lives in dYdX-specific protobuf modules. You query these through abci_query with the module's gRPC query path, or (more commonly) through the dYdX Indexer API that wraps these queries.

Module	What it manages
`dydxprotocol.perpetuals`	Perpetual market definitions, funding rates, premium votes
`dydxprotocol.subaccounts`	User positions, margin requirements, PnL
`dydxprotocol.clob`	The orderbook — order placement, matching, fills
`dydxprotocol.prices`	Oracle price feeds for each market
`dydxprotocol.bridge`	USDC bridging from Noble via IBC

The practical split:

Consensus RPC (CometBFT) — reading blocks, monitoring the chain, broadcasting standard transactions. This is what a flat-rate RPC endpoint gives you.
Module queries (abci_query) — reading trading state (positions, markets, orderbook state). Requires protobuf-encoded request data.
Indexer API — the high-level query layer that most frontends and dashboards use. Wraps the module queries with a friendlier REST interface.

If you're building a trading bot, a position tracker, or a liquidation monitor, you'll typically use the Indexer API for market data and positions, and the CometBFT RPC for broadcasting transactions and monitoring block-level events. The Indexer API is maintained by the dYdX team and reads from the chain — it's not a separate service you need to run yourself.

How this compares to other Cosmos chains

dYdX shares the CometBFT RPC surface with every other Cosmos chain, but the application layer is where it diverges. Injective also puts an orderbook in modules — but Injective's orderbook is fully on-chain (orders are transactions). dYdX's orderbook is off-chain (orders are gossiped, matched in memory, then settled on-chain). The difference matters for latency: dYdX can match orders in microseconds because matching doesn't wait for consensus; Injective's matching waits for the next block.

Osmosis puts a spot DEX in modules. Celestia is a data availability layer. dYdX is a perpetuals exchange. The pattern is the same — Cosmos SDK modules extend the base chain with application-specific state — but the domain is different each time.

Finality and block structure

dYdX has single-block deterministic finality via CometBFT BFT consensus — once a block is committed by the validator set, it's final. No reorgs, no probabilistic confirmation waits. With sub-second block times, trades settle in under a second from order placement to on-chain confirmation.

For an indexer, this means you can trust a committed block immediately. Read blocks via block, transaction results via block_results. The same reorg-handling patterns you'd build for probabilistic chains like Ethereum don't apply here — once it's committed, it's done.

The fast block times also mean higher block volume. At ~0.7s per block, dYdX produces roughly 125,000 blocks per day — more than Ethereum's ~7,200. If you're indexing every block, plan for the throughput.

The short version

dYdX Chain is a decentralized perpetual-futures exchange built on the Cosmos SDK. Its RPC is CometBFT JSON-RPC — the same surface as every other Cosmos chain. Use status, block, block_results, and tx to read chain state. Use abci_query with dYdX-specific module paths (dydxprotocol.clob, dydxprotocol.perpetuals, dydxprotocol.subaccounts) to read trading state, or use the dYdX Indexer API for a higher-level interface. The orderbook is off-chain (gossiped and matched in memory by validators); settlement is on-chain. It has single-block BFT finality, sub-second blocks, Noble USDC for margin, and the DYDX token (18 decimals) for staking and governance.

For monitoring dYdX chain activity, tracking trading state, or broadcasting transactions, you need a reliable CometBFT endpoint. A flat-rate dYdX RPC endpoint gives you that across load-balanced nodes, alongside 74 other chains under one key. Grab a free key and point your app at:

https://rpc.swiftnodes.io/rpc/dydx?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Akash Network RPC: Querying a Decentralized Compute Marketplace

SwiftNodes — Thu, 03 Sep 2026 06:51:27 +0000

Akash Network is one of the more interesting chains to connect an RPC endpoint to, because the chain itself isn't the product — the chain is the settlement layer for a decentralized compute marketplace. Developers who first query Akash often expect a familiar Cosmos pattern and miss the parts that make it different. The compute marketplace (deployments, bids, leases) lives in Akash-specific modules, not in the standard bank/staking queries. And the workloads themselves — containers running on provider GPUs — don't live on-chain at all. Here's the map.

What Akash actually does

Akash is a decentralized cloud compute marketplace built on the Cosmos SDK with CometBFT consensus. The pitch: instead of renting GPUs from AWS at $3.93/hr for an H100, you describe your workload, providers bid against each other in a reverse auction, and you pay market price (currently around $1.33/hr for the same H100). The chain records the leases and handles settlement; the actual compute runs in provider-operated Kubernetes clusters off-chain.

The numbers as of September 2026: ~59 active providers, ~15,000 vCPUs, ~433 GPUs (H100, A100, H200, RTX 5090), ~89 TB memory, ~785 TB storage. The AI inference wave has been the main demand driver — Akash ships pre-configured templates for Llama 3, DeepSeek, and Stable Diffusion, plus Ray cluster support for multi-node training.

The deployment flow has three steps:

Deploy: you describe your workload in an SDL (Stack Definition Language) file — CPU, memory, GPU, storage, exposed ports, max price. This creates a deployment on-chain.
Bid: independent providers submit competing bids. This is the reverse auction — providers undercut each other, and the market sets the price.
Lease: you accept a bid. A lease is recorded on-chain, and the provider initializes your container in their Kubernetes cluster.

The chain handles the marketplace, the lease accounting, and the payment settlement. The compute itself is off-chain — you won't find container logs or execution results by querying the chain.

The RPC: CometBFT JSON-RPC, same as other Cosmos chains

Akash runs on akashnet-2, uses CometBFT v0.38.x, has ~6-second blocks, and the AKT token has 6 decimals. The RPC is the standard CometBFT JSON-RPC — the same surface you'd use for Osmosis, Injective, or Celestia. No eth_*, no EVM. The chain ID is the string akashnet-2, not a numeric EVM ID.

SwiftNodes serves the CometBFT JSON-RPC endpoint:

# Node status
curl -s -X POST https://rpc.swiftnodes.io/rpc/akash?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"status","params":[],"id":1}'
# -> {"result":{"node_info":{"network":"akashnet-2",...},"sync_info":{"latest_block_height":"28455984",...}}}

The core methods you'll use:

Method	What it gives you
`status`	Node info, latest block height, sync state, network ID
`block`	A block by height — header, transactions, last commit
`block_results`	Transaction results and events for a block
`commit`	Signed header with validator signatures (84 signers on recent blocks)
`broadcast_tx_sync` / `_commit`	Submit a signed transaction
`tx`	Look up a transaction by hash

These are the consensus-layer queries — reading blocks, monitoring chain activity, broadcasting transactions. They work the same way across every Cosmos chain.

Where the special part lives: Akash modules

Here's where Akash diverges from a plain Cosmos chain. The marketplace state — deployments, bids, leases, providers — lives in Akash-specific protobuf modules. You query these through abci_query with the module's gRPC query path:

Query path	What it reads
`/akash.deployment.v1beta3.Query/Deployments`	Active deployments by owner
`/akash.market.v1beta4.Query/Orders`	Orders (resource requests) for a deployment
`/akash.market.v1beta4.Query/Bids`	Provider bids for an order
`/akash.market.v1beta4.Query/Leases`	Active leases (accepted bids)
`/akash.provider.v1beta3.Query/Providers`	Registered compute providers

The abci_query method takes four parameters: the query path, hex-encoded protobuf request data, a block height (0 = latest), and a prove flag. The protobuf encoding is the tricky part — you typically generate the request bytes from a Cosmos SDK client library rather than hand-crafting them. If you're using akash-cli or a Cosmos SDK integration, the module queries are wrapped for you.

The practical split:

Consensus RPC (CometBFT) — reading blocks, monitoring the chain, broadcasting standard transactions. This is what a flat-rate RPC endpoint gives you.
Module queries (abci_query) — reading marketplace state (deployments, bids, leases, providers). Requires protobuf-encoded request data.
Workload management — actually deploying containers, accepting bids, managing leases. This happens through the Akash Console or CLI, which wraps the module transactions.

If you're building a dashboard that tracks active deployments, monitors provider capacity, or indexes lease pricing data, you need the CometBFT RPC for chain state plus abci_query for the marketplace modules. If you're deploying workloads, you'll use the Akash CLI or Console on top.

Finality and block structure

Akash has single-block deterministic finality via CometBFT BFT consensus — once a block is committed by the validator set, it's final. No reorgs, no probabilistic confirmation waits. Recent blocks carry ~84 validator signatures in the commit, and blocks contain a handful of transactions (9 txs in a typical recent block at height 28,455,980).

For an indexer, this means you can trust a committed block immediately. Read blocks via block, transaction results via block_results, and the validator commit via commit. The same reorg-handling patterns you'd build for probabilistic chains like Ethereum don't apply here — once it's committed, it's done.

How this compares to other Cosmos chains

Akash shares the CometBFT RPC surface with every other Cosmos chain, but the application layer is where it diverges. Injective puts an orderbook in a module. Osmosis puts a DEX in modules. Akash puts a compute marketplace in modules. The pattern is the same — Cosmos SDK modules extend the base chain with application-specific state — but the domain is different each time.

The difference from Celestia is architectural: Celestia is a data availability layer (its special part is blob posting, which happens through a separate node API, not the core RPC). Akash's marketplace state is fully queryable through the standard CometBFT RPC via abci_query — there's no separate "Akash node API" you need to run.

The short version

Akash is a decentralized compute marketplace built on the Cosmos SDK. Its RPC is CometBFT JSON-RPC — the same surface as every other Cosmos chain. Use status, block, block_results, and commit to read chain state. Use abci_query with Akash-specific module paths (akash.deployment, akash.market, akash.provider) to read marketplace state: deployments, bids, leases, and provider registrations. The workloads themselves run off-chain in Kubernetes. It has single-block BFT finality, ~6-second blocks, and the AKT token (6 decimals).

For monitoring Akash chain activity, tracking marketplace state, or broadcasting transactions, you need a reliable CometBFT endpoint. A flat-rate Akash RPC endpoint gives you that across load-balanced nodes, alongside 74 other chains under one key. Grab a free key and point your app at:

https://rpc.swiftnodes.io/rpc/akash?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Axelar RPC: Connecting to the Cross-Chain Messaging Layer

SwiftNodes — Wed, 02 Sep 2026 06:19:51 +0000

Axelar is one of the major cross-chain interoperability networks, and it's easy to misunderstand if you arrive expecting an EVM chain — because it isn't one. Axelar is a Cosmos SDK proof-of-stake network whose whole job is connecting other blockchains: moving tokens and arbitrary messages between them. Once you understand that, its RPC makes sense. Here's the map.

What Axelar actually does

Most blockchains are islands. Axelar's purpose is to be the communication layer between them, built around two primitives:

Cross-chain token bridging: move a token from one connected chain to another. Axelar locks or burns on the source, mints or releases on the destination, coordinated by its validator set.
General Message Passing (GMP): a contract on one chain calls a function on a contract on another chain, passing arbitrary data along with it. This is what makes cross-chain applications possible, not just token transfers.

The mechanics: Axelar's validators run light clients of the connected chains and watch for events. When something happens on a source chain, the validators collectively attest to it using threshold signatures, and that attestation authorizes the corresponding action on the destination chain. Axelar launched mainnet in February 2022, is built with the Cosmos SDK + CometBFT (Tendermint) consensus, uses the AXL token (6 decimals) for staking, fees, and governance, and produces ~6-second blocks with single-block deterministic finality.

The RPC reality: it's a Cosmos chain, not an EVM one

Because Axelar is a Cosmos SDK chain, you don't talk to it with eth_* — those methods don't exist here. You use the CometBFT (Tendermint) RPC, the same consensus-layer RPC every Cosmos chain exposes. SwiftNodes serves this endpoint:

# Node + sync status (CometBFT RPC)
curl -s -X POST https://rpc.swiftnodes.io/rpc/axelar?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"status","params":[],"id":1}'
# -> {"result":{"node_info":{...},"sync_info":{"latest_block_height":"...",...}}}

The CometBFT RPC methods you'll actually use:

Method	What it gives you
`status`	Node info + latest block height + sync state
`block`	A block by height (params: `["height"]`)
`block_results`	Tx results + events for a block
`abci_query`	Query application state
`broadcast_tx_sync` / `_commit`	Submit a signed transaction
`tx`	Look up a transaction by hash

If you're new to the Cosmos RPC stack — how Tendermint RPC relates to the REST (LCD) and gRPC interfaces — we cover the whole thing in our Cosmos RPC explainer. The same surface applies across Celestia, Osmosis, and the rest of the Cosmos family.

Where the special part lives: GMP and cross-chain messages

The thing that makes Axelar Axelar — the actual cross-chain messaging — doesn't happen over a special RPC method. It's driven by smart contracts on the connected chains calling into Axelar's gateway contracts, with Axelar's validators relaying and attesting the messages between them. From your RPC's point of view, cross-chain activity shows up as ordinary Axelar transactions and events you read with block_results / abci_query — the cross-chain magic is coordinated by the validator set, not exposed as a bespoke endpoint.

The practical split for a developer:

To read or index Axelar itself — track GMP message status, watch validator attestations, monitor bridging activity — use the CometBFT RPC. That's what a flat-rate endpoint like SwiftNodes gives you.
To initiate a cross-chain call — you interact with Axelar's gateway contract on your source chain (e.g. an EVM chain), using its SDKs. Axelar's own RPC is where you observe and verify the result.

Finality and reading the chain

Axelar has single-block deterministic finality via CometBFT — once a block is committed by the validator set, it's final, no reorgs. One nuance for cross-chain builders: delivery on the destination chain also depends on that chain's own finality, so an end-to-end GMP call is only as final as both ends. For indexing Axelar itself, though, you can trust a committed block immediately — no probabilistic confirmation waits, minimal reorg handling. Read blocks and results via block / block_results, and query state via abci_query.

The short version

Axelar is a cross-chain interoperability network, not an EVM chain — so its RPC is Cosmos CometBFT (Tendermint) RPC, not eth_*. Use status, block, block_results, abci_query, and broadcast_tx_* to read state and broadcast transactions. The cross-chain part — token bridging and General Message Passing — is coordinated by Axelar's validator set via threshold-signed attestations; you initiate cross-chain calls from your source chain's gateway contract and observe them on Axelar. Single-block BFT finality means reads are deterministic.

For reading Axelar, tracking GMP activity, and broadcasting transactions, you need a reliable CometBFT endpoint. A flat-rate Axelar RPC endpoint gives you that across load-balanced nodes, alongside dozens of other chains under one key. Grab a free key and point your app at:

https://rpc.swiftnodes.io/rpc/axelar?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Boba Network RPC: Chain ID 288 and the Hybrid-Compute Rollup

SwiftNodes — Tue, 01 Sep 2026 05:18:23 +0000

Most rollups optimize one thing: cost. Boba Network tried to optimize the programming model too. Launched in 2021 as an EVM-compatible optimistic rollup on Ethereum, Boba (chain ID 288) is best known for Hybrid Compute — smart contracts that can trigger off-chain computation and external API calls during execution. This guide covers what you need to build on it: the chain ID, a working mainnet RPC endpoint, live fee behavior, and the usual fork-over habits.

The essentials

Boba's Ethereum L2 is chain ID 288, with:

ETH as the gas token (the BOBA token exists as the network's governance and utility asset — not the gas currency).
Blocks that follow transaction flow — sampled live while writing this: roughly one block every ~2 seconds, with the head past 38.5M.
Optimistic-rollup security: fast L2 confirmations, with withdrawals to Ethereum following the ~7-day challenge window.
A standard EVM surface — Solidity, viem, ethers, Foundry, and the usual eth_* methods.

A working config with our endpoint:

import { createPublicClient, http, defineChain } from "viem";

const boba = defineChain({
  id: 288,
  name: "Boba Network",
  nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/boba?key=YOUR_API_KEY"] } },
});

const client = createPublicClient({ chain: boba, transport: http() });
await client.getBlockNumber();   // just works

Hybrid Compute, from the RPC seat

The headline feature: Boba contracts can invoke off-chain compute and external APIs within a transaction — the network's Hybrid Compute framework routes those calls (including AI and Web2 data sources) and folds the results back into execution. It's a chain-level capability rather than an RPC extension, so from where you sit the interface stays boring in the best way:

Standard eth_call / eth_estimateGas / eth_sendRawTransaction semantics apply.
Hybrid-Compute transactions arrive through the same mempool and block flow as everything else — receipts and logs read identically.
Indexers and dashboards need no special decoding just to follow the chain; the exotic part is what contracts choose to do with the capability.

Historically Boba shipped alongside the OMG Foundation era (BOBA was airdropped to bridged OMG holders at launch), and the network also runs deployments on other base chains such as BNB Smart Chain — chain 288 is specifically the Ethereum L2, and the one SwiftNodes serves.

Fees: milligwei country

Boba's fee numbers look like a formatting bug until you accept them. Sampled live through our endpoint while writing this:

eth_gasPrice: ~0.001 gwei. The base fee sat several orders of magnitude below that (sub-microgwei).
A 21,000-gas transfer therefore costs on the order of 0.00002 ETH — deep sub-cent territory.
The sampled block was nearly empty (one transaction, ~44k gas used), which is normal for a rollup whose block production tracks demand.

Estimation flows work unchanged — eth_estimateGas and the EIP-1559 fields behave like any EVM chain (gas estimation basics apply as-is). Budget for dust, buffer as usual.

What carries over — and what to verify

Standard reads and writes — eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt (receipt semantics unchanged), eth_sendRawTransaction, eth_subscribe — all behave as on any EVM chain.
Archive access works: our block-1 state probe was answered normally, so historical queries route fine — on SwiftNodes that's &archive=1 on paid plans.
Extension methods, verify per-method: traces and debug vary by upstream everywhere, Boba included — our weekly auto-probed matrix covers it, with the error-code reference for the responses you'll meet.
WebSocket subscriptions fit well at this cadence (reconnection habits transfer directly).

The short version

Boba Network is chain ID 288: an EVM optimistic rollup on Ethereum with ETH gas, demand-driven blocks around 2-second pace, and fees in milligwei territory. Its signature feature — Hybrid Compute, letting contracts call off-chain compute and APIs mid-execution — leaves the RPC surface standard, so Ethereum tooling carries over as-is. Verify extension-method support per-method rather than assuming, and treat the 7-day withdrawal window as the trust horizon back to Ethereum.

Building on Boba? A flat-rate Boba Network RPC endpoint serves chain 288 over HTTP and WebSocket, load-balanced across upstreams, alongside 75+ other chains under the same key. Grab a free key and point your stack at:

https://rpc.swiftnodes.io/rpc/boba?key=YOUR_API_KEY
wss://rpc.swiftnodes.io/ws/boba?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

PulseChain RPC: Chain ID 369 and the Full-State Ethereum Fork

SwiftNodes — Mon, 31 Aug 2026 07:18:59 +0000

Most chains start from an empty genesis. PulseChain started from a copy of Ethereum. Launched May 13, 2023, PulseChain (chain ID 369) is an EVM-compatible Layer 1 built as a full-state fork of Ethereum — accounts, token balances, contracts, and NFTs snapshotted onto a new network with its own gas token and faster blocks. That origin story is also where most developer confusion lives, so this guide covers the essentials: the chain ID, a working mainnet RPC endpoint, and exactly what the fork means for your tooling.

The essentials

PulseChain mainnet is chain ID 369, with:

PLS as the gas token — not ETH. Budgeting, fee math, and balance displays need the native currency set correctly.
~10-second blocks (we sampled live while writing this: a block every few seconds, head past 27.4M).
Proof-of-stake validation with epoch-based finality.
A standard EVM surface — Solidity, viem, ethers, Foundry, and the usual eth_* methods all apply.

A working config with our endpoint:

import { createPublicClient, http, defineChain } from "viem";

const pulsechain = defineChain({
  id: 369,
  name: "PulseChain",
  nativeCurrency: { name: "Pulse", symbol: "PLS", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/pulsechain?key=YOUR_API_KEY"] } },
});

const client = createPublicClient({ chain: pulsechain, transport: http() });
await client.getBlockNumber();   // just works

For MetaMask, the same facts: network name PulseChain, RPC URL as above, chain ID 369, currency symbol PLS.

A fork of the state, not just the code

This is the part that trips people up. PulseChain didn't just copy Ethereum's software — it copied Ethereum's state at the May 2023 snapshot. Consequences worth knowing:

Contracts live at the same addresses as on Ethereum at snapshot time. A token contract you knew on Ethereum mainnet exists at the identical address on PulseChain — but it is a separate asset on a separate chain. The copies are referred to as PRC-20 tokens (the ERC-20 equivalent). Same address, different chain, different supply dynamics.
Chain ID 369 is the replay boundary. Transactions are signed with the chain ID, so nothing replays between Ethereum (1) and PulseChain (369) — but wallet and indexer code that hardcodes chain 1 or derives addresses assuming ETH balances needs updating.
The snapshot is frozen in time. PulseChain's copied state reflects Ethereum as of May 2023. Anything that happened on Ethereum since — new deployments, balance changes, upgrades — is not mirrored. Treat the two as fully independent chains that happen to share historical addresses.

The ecosystem itself is anchored by PulseX, the network's primary DEX, alongside HEX and other community projects that came across at the snapshot.

Fees: big gwei numbers, tiny bills

PulseChain runs EIP-1559-style fees, and the numbers look startling until you remember the unit is PLS. Sampled live through our endpoint while writing this:

Base fee: ~892,000 gwei — which is ~0.0009 PLS per gas.
A simple 21,000-gas transfer therefore costs roughly 19 PLS — a fraction of a cent.
The sampled block carried 25 transactions, and eth_gasPrice returned the combined price as usual.

All the standard estimation flows work unchanged: eth_estimateGas, eth_gasPrice, and the EIP-1559 fields behave like any EVM chain (gas estimation basics apply as-is). If your dashboard shows "huge" fees on PulseChain, check the display currency before alarming anyone.

What carries over — and what to verify

Standard reads and writes — eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt (receipt semantics unchanged), eth_sendRawTransaction, eth_subscribe — all behave as on any EVM chain.
Archive access works: our probe against block 1 returned state normally, so historical queries route fine — on SwiftNodes that's &archive=1 on paid plans.
Method support beyond the basics, verify per-method: extension methods (traces, debug) vary by upstream everywhere, PulseChain included — our weekly auto-probed matrix covers it, with error-code reference for the responses you'll see.
WebSocket subscriptions are the right pattern at this block cadence (reconnection habits transfer directly).

The short version

PulseChain is chain ID 369: an EVM-compatible, full-state fork of Ethereum with PLS gas, ~10-second blocks, and EIP-1559 fees that look large in gwei but cost fractions of a cent. The fork means Ethereum contract addresses exist at the same locations (as separate PRC-20 assets), the snapshot state is frozen at May 2023, and chain ID 369 is your replay boundary. Everything else is standard EVM — with method support worth checking per-method rather than assuming.

Building on chain 369? A flat-rate PulseChain RPC endpoint serves the network over HTTP and WebSocket, load-balanced across upstreams, alongside 75+ other chains under the same key. Grab a free key and point your stack at:

https://rpc.swiftnodes.io/rpc/pulsechain?key=YOUR_API_KEY
wss://rpc.swiftnodes.io/ws/pulsechain?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Optimism RPC: The Chain That Became a Template

SwiftNodes — Sun, 30 Aug 2026 05:35:50 +0000

Most layer-2s are chains. Optimism is a chain and a template. OP Mainnet (chain ID 10, public mainnet since December 2021) is one of the oldest and most battle-tested optimistic rollups — and its codebase, the OP Stack, is what Base, Zora, opBNB, Unichain, and Soneium are built on. The practical consequence for developers: what you learn building against Optimism's RPC transfers across the whole family. Here's the map.

The essentials

Optimism mainnet is chain ID 10, an optimistic rollup on Ethereum with:

ETH as the gas token — no new native asset to hold for fees.
2-second blocks (verified live while writing this), with transactions ordered by a sequencer that gives you instant soft confirmations; hard finality follows Ethereum's. The sequencer is operated by OP Labs today, with decentralization an explicit roadmap item.
Fault proofs live since June 2024 — the optimistic-rollup dispute mechanism that lets anyone challenge an invalid state claim on Ethereum, rather than trusting an upgrade delay alone.
A standard EVM execution environment — Solidity, viem, ethers, Foundry, and the usual eth_* surface apply directly.

Connecting is boilerplate:

import { createPublicClient, http, defineChain } from "viem";

const optimism = defineChain({
  id: 10,
  name: "OP Mainnet",
  nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/optimism?key=YOUR_API_KEY"] } },
});

const client = createPublicClient({ chain: optimism, transport: http() });
await client.getBlockNumber();   // just works

Fees are two layers — and estimation already knows

This is the one place Optimism differs from Ethereum in a way you'll notice. Every transaction pays two components:

An execution fee — ordinary EIP-1559 gas for running your transaction on the rollup. This part is minuscule: the base fee we sampled this morning was ~0.000001 gwei.
An L1 data fee — the cost of posting your transaction's data to Ethereum (as blobs, since the 2024 upgrades). For calldata-heavy transactions, this component dominates.

The good news: you don't compute either by hand. eth_estimateGas returns an all-in figure — if the number looks larger than a naive 21,000-plus-calldata guess, that's the L1 data fee folded in at current prices, by design. eth_gasPrice likewise returns a combined price. Normal estimation flows with your usual buffer work unchanged (gas estimation basics apply as-is).

The OP Stack: skills that carry

Because the same codebase runs the family, an integration built for OP Mainnet is mostly configuration when it moves sideways:

Same RPC surface — 2-second blocks, the same two-layer fee shape, optimistic-rollup semantics with each chain's own sequencer and proof setup.
Same tooling story — viem/ethers chain definitions differ per network, but your indexer logic, subscription patterns, and receipt handling don't.
Same operational habits — WebSocket subscriptions over polling at 2-second cadence (reorg and reconnection habits transfer), log range discipline unchanged.

SwiftNodes serves the family under one key — Optimism, Base, Zora, opBNB, Unichain, and Soneium — so a multi-chain product can treat the OP Stack family as one integration target with per-chain endpoints.

The one rough edge: traces are uneven

If there's a caveat on Optimism, it's the Parity trace namespace. The OP Stack's standard surface doesn't include trace_* methods, and where traces do appear they're often gated upstream — probing OP Mainnet through our routing this morning, archive-flavored queries returned provider gate messages rather than data. The honest pattern: check per-method, per-chain, and re-check — support genuinely varies by upstream mix. Our weekly auto-probed matrix does exactly that, with per-method detail pages like trace_filter and trace_transaction (and the longer treatment in our trace field guide).

Everything else is the standard EVM you expect: receipts, logs, subscriptions, and the usual error-code taxonomy when something rejects. Historical state (balances and receipts at old blocks) needs archive routing — on SwiftNodes that's &archive=1 on paid plans.

What carries over unchanged

eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, eth_subscribe — all standard behavior.
EIP-1559 fields and estimation flows (all-in numbers, buffer as usual).
Solidity bytecode deploys as-is; the toolchain is untouched.
WebSocket subscriptions are the right default at 2-second blocks.
Cross-check method support in the live matrix rather than a feature table — especially for traces and debug methods.

The short version

Optimism (chain ID 10) is a mature optimistic rollup — ETH gas, 2-second blocks, fault proofs live since 2024 — and the origin of the OP Stack that powers Base, Zora, opBNB, Unichain, and Soneium. Fees come in two layers (a tiny execution base fee plus the L1 data fee), but eth_estimateGas returns an all-in figure so normal estimation flows work unchanged. The one thing to verify rather than assume is trace/debug method support, which varies by upstream. Everything else is standard EVM — and every skill transfers sideways across the Superchain family.

Shipping on OP Mainnet or its siblings? A flat-rate Optimism RPC endpoint gives you chain 10 over HTTP and WebSocket, load-balanced across upstreams, with the rest of the OP Stack family — and 75+ chains total — under the same key. Grab a free key and point your stack at:

https://rpc.swiftnodes.io/rpc/optimism?key=YOUR_API_KEY
wss://rpc.swiftnodes.io/ws/optimism?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

trace_filter and trace_transaction: Reading What Receipts Can't Show

SwiftNodes — Sat, 29 Aug 2026 06:51:27 +0000

A successful receipt tells you almost nothing about what a transaction actually did. The token moved, but through which contracts? The call succeeded, but which internal transfer carried the value? Logs record what contracts chose to emit; everything between calls is invisible to eth_getTransactionReceipt. The Parity trace namespace was built for exactly that gap, and two of its methods do most of the work: trace_transaction for a single transaction's full internal-call tree, and trace_filter for scanning ranges of blocks. We operate RPC across 75+ chains and probe trace support weekly (it's part of our method-support matrix), so this comes with current availability data, not folklore.

trace_transaction: one transaction, fully unpacked

Here's a real response for a fresh Sonic transaction, captured through our endpoint while writing this:

// trace_transaction("0xe3bb52bf…") on Sonic →
[
  {
    "action": {
      "callType": "call",
      "from": "0x1fc056…",
      "to": "0xf87af5…",
      "value": "0x0",
      "gas": "0x10e78",
      "input": "0xe17e76e3…"
    },
    "blockNumber": 78366386,
    "result": { "gasUsed": "0x1201d", "output": "0x…0001" },
    "subtraces": 0,
    "traceAddress": [],
    "transactionHash": "0xe3bb52bf…",
    "transactionPosition": 0,
    "type": "call"
  }
]

Each entry is one step of execution. The fields that matter:

action — who called whom (from/to), with what value, callType (call, delegatecall, staticcall), or for other types: create (contract deployment) and suicide.
traceAddress — this step's position in the call tree. [] is the top-level call; [2] is the third sub-call of the top level; [2,0] is its first child. That array is how you reconstruct the whole tree.
subtraces — how many children this step spawned.
result — gas used and return data at this level, separately from the transaction-level receipt.

A DEX swap through a router, two pools, and a recipient ends up as a dozen or more of these entries — the exact path the value traveled. That reconstruction is what accounting tools, forensic dashboards, and internal-transfer indexers are actually built on. For the cost side of tracing (and why you should never loop these calls casually), see our earlier piece on debug_traceTransaction.

trace_filter: the indexer's range scan

trace_transaction answers "what did this hash do?" trace_filter answers "what happened across these blocks?" — scans a block range and returns every trace matching your filter:

// trace_filter over three recent Ethereum blocks →
// 7,276 traces returned
[
  {
    "action": {
      "from": "0x835033…",
      "callType": "call",
      "to": "0x933339…",
      "value": "0x214e8348c4f0000",   // 0.15 ETH
      "input": "0x",
      "gas": "0x13498"
    },
    "blockNumber": 25859102,
    "subtraces": 0,
    "traceAddress": [],
    "transactionHash": "0x49bcbd…",
    "type": "call"
  }
]

The filter object accepts fromBlock, toBlock, plus optional address and topics constraints. Indexers use it the way Safe's Transaction Service does for non-L2 deployments — their infrastructure docs list the trace methods among the indexer's RPC requirements, with trace_filter doing the discovery work. Note the volume in that sample: roughly 2,400 internal actions per Ethereum block. That number explains everything in the next section.

The param gotcha we hit today

Some implementations reject block tags in the filter and demand numeric blocks. The same query, "fromBlock": "latest" versus "0x18a9c1d":

{"code":-32602,"message":"Invalid params","data":"invalid value: string \"latest\", expected a 8 byte hex string at line 1 column 21"}

Fetch eth_blockNumber and pass hex numbers — it works everywhere the method works at all. -32602 here is good news, by the way: the method exists and parsed your request. That ambiguity between "fix your params" and "method missing" is the same taxonomy we covered in yesterday's error-code field guide.

Where traces actually work in 2026

The trace namespace comes from the Parity client lineage. Geth never implemented it, which means most L2s and geth-fork chains simply don't have it — and among chains whose software could serve traces, providers frequently gate them because they're expensive. This week's probe across the 54 EVM chains we serve:

Capability	Chains serving it
`trace_filter`	11 of 54
`trace_transaction`	11 of 54
Both (full indexer suite)	8 of 54 — Ethereum, Gnosis, Sonic, Berachain, Fraxtal, Plasma, PulseChain, Soneium

OP Stack chains and most zk chains return clean rejections — the namespace is gone there by design. And even where a chain supports tracing, the upstream provider can gate it. A real response from a Base request, via a popular public endpoint:

{"code":-32602,"message":"Archive requests require a personal token. Get one at: https://www.allnodes.com/publicnode"}

That's policy, not capability — which is why per-chain claims need probing rather than reading someone's feature page. The live, re-probed breakdown is on our trace_filter and trace_transaction pages, column-by-column for every chain.

Working with traces in practice

Reconstructing internal transfers: filter by to or from address over a block range, keep entries with type: "call" and non-zero value — that's the ETH that moved between contracts, invisible to receipt-based accounting.
Post-mortem debugging: when a transaction "succeeded" but balances don't add up, trace_transaction shows every internal hop. Pair with state proofs when you need to verify, not just inspect.
Historical tracing requires archive access: traces are state-dependent, so scanning old ranges routes through archive nodes — on SwiftNodes that's &archive=1, included on paid plans.
Respect the volume: thousands of traces per block means wide filters are heavy. Narrow your block range, filter by address where you can, and cache aggressively. Same discipline as getLogs range caps.

Check any endpoint yourself

npx rpc-doctor <url> probes method support — including the trace pair — and reports what an endpoint actually serves, for any endpoint, yours or anyone's. It's open source.

And if you want traces where they exist and honest answers where they don't: our routing spreads load across upstreams that genuinely serve the namespace, and the method-support matrix is re-probed weekly through the same path your requests take — free tier included.

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.