Astar RPC: One Chain, Two VMs, Polkadot Security

Most chains give you one virtual machine. Astar gives you two: a full EVM environment and WebAssembly (Wasm) contracts, on the same Polkadot parachain. If you're building with Solidity, you use the EVM side — chain ID 592, ordinary eth_*, viem/ethers/foundry unchanged — and you may never touch the Wasm layer. But it's worth knowing what's underneath, because Astar is a Substrate-based Polkadot parachain, and that gives it a security and finality model different from a standalone L1 or a rollup. Here's the map.

The essentials

Astar's EVM is chain ID 592, with:

• ASTR as the gas token (18 decimals) — also used for staking and dApp Staking.
• ~12-second blocks with deterministic finality via Polkadot's GRANDPA finality gadget.
• Polkadot parachain — inherits shared security from the Polkadot relay chain via nominated proof-of-stake.
• Dual VM — EVM (Solidity) and Wasm (ink!) contracts coexist on the network.

For Solidity work, connecting is completely standard:

import { createPublicClient, http } from "viem";
import { astar } from "viem/chains";   // chain ID 592

const client = createPublicClient({
  chain: astar,
  transport: http("https://rpc.swiftnodes.io/rpc/astar?key=YOUR_API_KEY"),
});
await client.getBlockNumber();   // just works

One clarification up front: chain 592 is the Polkadot-based Astar EVM. Astar has separately operated a zkEVM deployment on different infrastructure — that's a distinct network. When you point tooling at chain 592, you're on the parachain EVM.

The dual-VM model: EVM and Wasm

Astar's defining trait is that it runs two smart-contract environments side by side:

• EVM — standard Solidity, deployed and called exactly as on Ethereum. This is what chain 592's RPC serves.
• Wasm (ink!) — Rust-based WebAssembly contracts, native to the Substrate/Polkadot world.

For an RPC consumer, the practical takeaway is simple: the EVM side is a normal eth_* endpoint, so your Solidity contracts, ABIs, and tooling work with zero changes. The Wasm side lives in the Substrate layer and is reached through Polkadot's own RPC (Substrate JSON-RPC / Polkadot.js), not eth_*. If you're doing pure Solidity, you stay entirely in the EVM RPC and the Wasm layer is just... there, an option for teams that want it. The two can interoperate, but that's an advanced path — most EVM developers use chain 592 like any other EVM chain.

The parachain model: what changes underneath

Astar isn't a standalone L1 and isn't a rollup — it's a parachain, which shapes two things worth understanding:

• Shared security from Polkadot. Rather than bootstrapping its own validator economy, Astar inherits security from the Polkadot relay chain's validator set (nominated PoS). Its safety rides on Polkadot's.
• Deterministic finality via GRANDPA. Polkadot's finality gadget provides deterministic finality — once a block is finalized, it's irreversible. That means no reorgs to defend against once finality is reached. The whole class of reorg-handling patterns — waiting many confirmations, tolerating tip rollbacks — reduces to tracking the finalized head. It's the same "confirm once" comfort you get on other deterministic-finality EVM chains like Kaia and Flare, just delivered by Polkadot's consensus rather than a chain-specific one.

There's also a conceptual parallel worth drawing: like the Cosmos chains where an EVM sits atop a non-EVM native layer, Astar's EVM (via the Frontier compatibility layer) sits atop Substrate. You mostly won't see it from the eth_* RPC, but it's why the underlying architecture differs from a from-scratch EVM chain. (If you've read the Cosmos RPC explainer, it's a similar "EVM cockpit over a different engine" idea — and different again from a non-EVM chain like Sui with its own object model.)

dApp Staking: an ecosystem quirk worth knowing

Astar has a distinctive dApp Staking program: ASTR stakers can direct rewards to the projects building on the network, so dApps earn ongoing support based on the stake backing them. It doesn't change your RPC integration, but it's part of why teams choose to build here — worth a mention if you're evaluating the chain, not just querying it.

What carries over unchanged

On the EVM side (chain 592), treat Astar as a standard EVM chain:

• eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, eth_subscribe all behave normally.
• Solidity contracts, ABIs, and the viem/ethers/hardhat/foundry toolchain deploy and run as-is.
• ASTR is the gas token with 18 decimals; WebSocket subscriptions (newHeads, logs) work; if you're pulling lots of reads, batch them.

The short version

Astar (EVM chain ID 592) is a Polkadot parachain that runs both EVM and Wasm contracts. For Solidity, it's a standard eth_* endpoint — viem/ethers/foundry unchanged — while the Wasm (ink!) side lives in the Substrate layer reached via Polkadot's RPC. The parachain model gives it shared security from Polkadot and deterministic GRANDPA finality (no reorgs once finalized, so index the finalized head and confirm once). Build the EVM side like any EVM chain; know that the Wasm option and Substrate underpinnings are there.

Deploying Solidity on Astar, or building across its EVM and Wasm environments? A flat-rate Astar RPC endpoint gives you chain 592 over HTTP and WebSocket alongside 75+ other chains under one key. Grab a free key and point your stack at:

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