Starknet RPC Guide: How to Connect and Build on Starknet (2026)

Starknet is a STARK-based ZK rollup settling to Ethereum. It is not an EVM chain. That single fact has more practical consequences for developers than almost any other decision you will make when choosing a network. Starknet uses Cairo, not Solidity. It uses starknet_* methods, not eth_* methods. Native account abstraction means every account is a smart contract.

This guide covers what a Starknet RPC endpoint is, how to connect to it with starknet.js and direct JSON-RPC calls, which methods you need to know, what changes if you are coming from Ethereum, how to choose a provider. For endpoint URLs, chain specs, and WebSocket details, see the Starknet chain page.

---

What is a Starknet RPC Endpoint

A Starknet RPC endpoint is an HTTP or WebSocket URL that exposes the Starknet JSON-RPC API. You send a JSON payload specifying a starknet_* method and its parameters, and the node returns structured data about the chain state.

The interface looks similar to Ethereum’s JSON-RPC surface, but the methods, data types, transaction model are entirely different. There is no eth_call, no eth_getBalance, no eth_getLogs. Attempting to call those methods against a Starknet node will return a method-not-found error.

---

Starknet vs EVM: Key Differences

Developers migrating from Ethereum need to recalibrate several assumptions before their first Starknet integration works correctly.

Cairo, not Solidity. Starknet smart contracts are written in Cairo, a language designed from the ground up to produce computations that are efficiently verifiable by STARK proofs. There is no Solidity-to-Cairo transpiler. Moving an existing Solidity contract to Starknet means a full rewrite, not a port.

starknet_ methods, not eth_ methods. The entire RPC method namespace is different. Reading a contract, submitting a transaction, fetching events: all of these use starknet_* prefixed methods. ethers.js, viem, web3.js do not speak this protocol.

Native account abstraction. Starknet has no externally owned accounts (EOAs) in the Ethereum sense. Every account is a smart contract. Transaction signing is handled by the account contract’s own verification logic rather than a fixed secp256k1 ECDSA scheme. This enables multi-sig wallets, social recovery, session keys, other patterns without add-on infrastructure.

STARK proofs. Each batch of Starknet transactions is proven with a STARK proof before being settled to Ethereum. Finality on Starknet means the proof has been verified on Ethereum L1.

Dual fee token. Gas can be paid in ETH (bridged from Ethereum) or in STRK, Starknet’s native token.

---

Example Starknet RPC Methods

Reading Chain State

starknet_blockNumber returns the latest accepted block number. This is the equivalent of eth_blockNumber and the correct first call to verify your connection.

starknet_getBlockWithTxs returns a full block including all transaction objects. Pass "latest" or a specific block number.

starknet_call executes a read-only call against a Cairo smart contract without submitting a transaction. This is the Starknet equivalent of eth_call. Use it to read token balances, query contract state, or simulate a view function.

starknet_getEvents returns events matching a filter. It accepts a from_block, to_block, address, list of keys (event selectors). This is the Starknet equivalent of eth_getLogs. Note: Starknet event keys are field elements (Felt252 values), not ABI-encoded topic hashes.

Reading Transactions

starknet_getTransactionByHash retrieves a transaction by its hash. Returns the full transaction object including calldata, sender address, max fee.

starknet_getTransactionReceipt returns the receipt for a completed transaction. Check the execution_status field (SUCCEEDED or REVERTED) and finality_status field (ACCEPTED_ON_L2 or ACCEPTED_ON_L1). Waiting for ACCEPTED_ON_L1 means the STARK proof has been submitted to Ethereum.

Submitting Transactions

starknet_addInvokeTransaction submits a signed invoke transaction to the network. Invoke is the standard transaction type for calling functions on an existing Cairo contract.

starknet_addDeclareTransaction declares a new contract class on the network. In Starknet’s deployment model, you first declare a class (the compiled Sierra bytecode), then deploy instances of it.

starknet_estimateFee estimates the fee for a transaction before submitting it. Essential for any application that displays fee estimates to users.

---

Connecting Step by Step

starknet.js (TypeScript / JavaScript)

npm install starknet

import { RpcProvider } from "starknet";

const provider = new RpcProvider({
  nodeUrl: "https://eu.endpoints.matrixed.link/rpc/starknet?auth=YOUR_KEY",
});

// Verify connection
const blockNumber = await provider.getBlockNumber();
console.log("Latest block:", blockNumber);

// Read contract state with starknet_call
const result = await provider.callContract({
  contractAddress: "0xYourContractAddress",
  entrypoint: "balanceOf",
  calldata: ["0xYourAccountAddress"],
});
console.log("Balance result:", result);

starknet-rs (Rust)

# Cargo.toml
[dependencies]
starknet = "0.12"
tokio = { version = "1", features = ["full"] }

use starknet::providers::{JsonRpcClient, Url, jsonrpc::HttpTransport};

#[tokio::main]
async fn main() {
    let provider = JsonRpcClient::new(HttpTransport::new(
        Url::parse("https://eu.endpoints.matrixed.link/rpc/starknet?auth=YOUR_KEY").unwrap(),
    ));

    let block_number = provider.block_number().await.unwrap();
    println!("Latest block: {}", block_number);
}

Direct JSON-RPC with curl

# starknet_blockNumber
curl https://eu.endpoints.matrixed.link/rpc/starknet?auth=YOUR_KEY \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"starknet_blockNumber","params":[],"id":1}'

# starknet_getTransactionByHash
curl https://eu.endpoints.matrixed.link/rpc/starknet?auth=YOUR_KEY \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "method": "starknet_getTransactionByHash",
    "params": ["0xYourTxHash"],
    "id": 1
  }'

---

Starknet-Specific Considerations

Sierra and CASM compilation. Cairo contracts compile first to Sierra (Safe Intermediate Representation), then to CASM (Cairo Assembly) for execution on the CairoVM. When you declare a contract, you submit the Sierra bytecode. The sequencer compiles it to CASM. This two-stage pipeline means compilation errors can surface at declaration time, not just at deploy time.

Native account abstraction mechanics. Because every account is a smart contract, deploying a new account requires a two-step process: declare the account class (if not already on-chain), then deploy an instance and fund it. Argent and Braavos wallets handle this automatically. Custom integrations must implement the __validate__ and __execute__ entrypoints or use a pre-audited account contract.

Fee token selection. When building transactions, you must specify whether you are paying fees in ETH or STRK. Most existing tooling defaults to ETH. If your users hold only STRK, you need to handle fee token selection explicitly.

Field element (Felt252) data type. Starknet’s native data type is a 252-bit field element. Contract addresses, transaction hashes, storage keys, event selectors are all Felt252 values. They are represented as hex strings in the RPC, typically zero-padded to 64 characters. starknet.js and starknet-rs handle conversions, but raw curl calls require correctly formatted Felt252 values.

---

Common Issues for Ethereum Developers

Using ethers.js or viem. These libraries do not work with Starknet. The RPC methods and data formats are incompatible. Use starknet.js for JavaScript/TypeScript or starknet-rs for Rust.

Expecting eth_getLogs for events. Events on Starknet are fetched with starknet_getEvents. The filter structure uses keys (Felt252 event selectors) rather than Keccak256 topic hashes.

Misreading finality. ACCEPTED_ON_L2 means the Starknet sequencer accepted the transaction. ACCEPTED_ON_L1 means the STARK proof has been verified on Ethereum. For applications where L1-level finality matters (cross-chain bridges, high-value withdrawals), wait for ACCEPTED_ON_L1.

Single-step deployment expectations. Ethereum contract deployment is one transaction. Starknet uses declare then deploy. If you skip the declare step (the class may already be declared by someone else), you can go straight to deploy. Failing to check whether a class is already declared wastes fees.

---

Choosing a Provider

Public Starknet RPC endpoints have rate limits and are suitable for development. Production applications need a dedicated provider.

Key criteria for Starknet specifically:

• Full starknet_* method coverage including starknet_getEvents, starknet_estimateFee, starknet_addDeclareTransaction.
• WebSocket support for event subscriptions.
• Infrastructure that handles the heavier node workload from STARK proof processing alongside standard RPC traffic.
• Flat-rate pricing matters on Starknet because starknet_call and starknet_estimateFee are called frequently during normal contract interaction.

BoltRPC provides dedicated Starknet infrastructure with HTTP and WebSocket access, full method coverage, flat-rate pricing. Built on ISO/IEC 27001:2022 certified infrastructure by Matrixed.Link.

For endpoint details, chain specs, and WebSocket URLs, visit the Starknet RPC endpoint page.

Start your free 2-week trial: trial.boltrpc.io

---

FAQ

What is a Starknet RPC endpoint and how is it different from an Ethereum RPC endpoint?

A Starknet RPC endpoint is an HTTP or WebSocket URL exposing the Starknet JSON-RPC API. It uses starknet_* methods rather than eth_* methods. The data types, transaction model, account model, fee structure are all different from Ethereum. You need starknet.js or starknet-rs to interact with it correctly.

Can I use ethers.js or viem to connect to Starknet?

No. ethers.js and viem are built for EVM-compatible chains and do not understand Starknet’s JSON-RPC methods or Cairo data types. Use starknet.js for JavaScript and TypeScript projects or starknet-rs for Rust.

What is the difference between ACCEPTED_ON_L2 and ACCEPTED_ON_L1 on Starknet?

ACCEPTED_ON_L2 means the Starknet sequencer has included the transaction in a block. ACCEPTED_ON_L1 means the STARK proof covering that transaction has been verified on Ethereum. For most application reads, L2 acceptance is sufficient. For bridge withdrawals or high-value finality requirements, wait for L1 acceptance.

What is starknet_call used for?

starknet_call executes a read-only function call against a Cairo contract without submitting a transaction or spending gas. It is the Starknet equivalent of eth_call. Use it to read token balances, query contract view functions, or simulate contract interactions before submitting an invoke transaction.

---