DEV Community: OnFinality

What Is Crust Network? Decentralized Storage Explained

OnFinality — Wed, 26 Aug 2026 05:01:40 +0000

Crust Network is a purpose-built layer 1 blockchain that provides decentralized cloud storage by adding an incentive and service layer to IPFS. It is designed for developers and builders who need verifiable, persistent, and cost-effective storage for dApps, NFTs, websites, and other Web3 content.

If you are evaluating Crust for your project, the key decision is whether you need a decentralized storage layer at all, and if so, how to integrate it with your existing stack. This article explains what Crust is, how it works, and how to connect to it via RPC endpoints.

Quick Recommendation: When to Use Crust Network

Crust is a strong fit when you need:

Permanent or flexible storage for NFT metadata, dApp content, or website hosting.
IPFS compatibility with an incentive layer that ensures data availability and redundancy.
Cross-chain interoperability to store data from multiple blockchains (EVM, Substrate, etc.).

If your use case is simple pinning of a few files, you might start with a centralized service. But if you need verifiable, decentralized storage with on-chain guarantees, Crust is worth considering.

For developers, the next step is to set up an RPC connection to interact with the Crust chain. You can use a managed RPC provider like OnFinality to get reliable endpoints without running your own node.

How Crust Network Works

Crust is built on Substrate, the same framework used by Polkadot. It uses a unique consensus mechanism called GPoS (Guaranteed Proof of Stake) that combines staking with storage proofs. Storage nodes prove they are storing data correctly using MPoW (Meaningful Proof of Work) and TEE (Trusted Execution Environment) technology.

The network has three main components:

Validators: Secure the chain and validate transactions.
Storage providers: Offer disk space and prove they store data.
Gateway providers: Provide access to stored data via IPFS gateways.

Crust's storage market is on-chain, meaning users can order storage and pay with the native CRU token. The network also supports cross-chain storage via XCMP (Cross-Chain Message Passing) and EVM compatibility, making it accessible from Ethereum, Polygon, and other chains.

Key Features of Crust Network

IPFS Integration

Crust uses IPFS as its underlying storage protocol. Files are addressed by content ID (CID), and Crust adds an incentive layer to ensure that files are pinned and replicated across multiple nodes. This means you get the benefits of IPFS (content addressing, deduplication) with the guarantee that your data will persist.

On-Chain Storage Market

Users can place storage orders on the Crust blockchain. The network matches orders with storage providers, and the data is stored with redundancy (typically 30+ replicas). This creates a permissionless market where anyone can offer storage and earn CRU.

Cross-Chain Interoperability

Crust supports multiple ways to interact with other chains:

EVM: Crust has an EVM-compatible layer, so you can deploy Solidity smart contracts.
XCMP: As a Polkadot parachain, Crust can communicate with other Substrate-based chains.
X-Chain Contracts: Smart contracts that allow storage functions to be called from other chains.

Tools and SDKs

Crust provides several tools for developers:

Crust Files: A personal cloud storage interface for Web3.
IPFS W3Auth Gateway: A Web3-authenticated IPFS gateway supporting all IPFS write operations.
IPFS W3Auth Pinning Service: A standard IPFS pinning service with Web3 authentication.
Crust GitHub Action: For decentralized CI/CD hosting via IPFS pinning.

Crust Network vs. Other Storage Solutions

Feature	Crust Network	Filecoin	Arweave
Underlying protocol	IPFS	IPFS	Custom
Consensus	GPoS (Substrate)	Proof-of-Spacetime	Proof-of-Access
Storage payment	On-chain market (CRU)	On-chain market (FIL)	Upfront payment
Cross-chain	EVM, XCMP	Bridges	Bridges
Data persistence	Incentivized pinning	Incentivized storage	Permanent

Crust is often compared to Filecoin and Arweave. While Filecoin also uses IPFS, Crust's integration with Substrate and its EVM compatibility make it easier to use from Polkadot and Ethereum ecosystems. Arweave offers permanent storage with a one-time fee, but Crust provides more flexibility with its storage market.

Getting Started with Crust Network RPC

To interact with the Crust blockchain, you need an RPC endpoint. You can run your own node, but for most developers, using a managed RPC provider is more practical. OnFinality offers public and dedicated RPC endpoints for Crust, allowing you to focus on building your application.

Public RPC Endpoint

OnFinality provides a public endpoint for Crust:

https://rpc.crust.network

You can use this endpoint to send JSON-RPC requests to the Crust chain. For example, to get the latest block number:

curl -X POST https://rpc.crust.network \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"chain_getHeader","params":[],"id":1}'

This will return the latest block header, including the block number.

Using the Polkadot.js API

For Substrate-based chains like Crust, you can use the Polkadot.js API to interact with the chain. Here's an example of connecting to Crust and reading the chain name:

const { ApiPromise, WsProvider } = require('@polkadot/api');

async function main() {
  const provider = new WsProvider('wss://rpc.crust.network');
  const api = await ApiPromise.create({ provider });

  const chain = await api.rpc.system.chain();
  console.log('Chain:', chain.toString());

  await api.disconnect();
}

main().catch(console.error);

Wallet Configuration

If you want to use Crust with a wallet like SubWallet, you can add the network manually. The chain ID for Crust is crab (or crust for mainnet). Here's an example configuration:

{
  "network": "crust",
  "displayName": "Crust Network",
  "rpc": "https://rpc.crust.network",
  "ws": "wss://rpc.crust.network",
  "chainId": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "explorer": "https://crust.subscan.io"
}

Note: The chain ID is a placeholder; you should check the official documentation for the correct value.

Common Use Cases for Crust Network

NFT Metadata Storage

NFTs often need metadata that persists forever. Crust can store NFT metadata on IPFS with on-chain guarantees, ensuring that the metadata remains accessible even if the original minter disappears.

Website Hosting

You can host a fully decentralized website on Crust. By pinning your site's files to IPFS via Crust, you ensure that the site is always available, with no single point of failure.

dApp Data Storage

Many dApps need to store user-generated content, such as messages, profiles, or documents. Crust provides a decentralized alternative to traditional cloud storage, with the added benefit of verifiable data integrity.

Data Archiving

For long-term data retention, Crust's storage market allows you to pay for storage over time, with the option to renew. This is useful for compliance or archival purposes.

How to Choose an RPC Provider for Crust

When selecting an RPC provider for Crust, consider the following:

Reliability: Look for providers with a track record of uptime and performance.
Scalability: Ensure the provider can handle your expected request volume.
Support: Check if the provider offers dedicated nodes for high-throughput workloads.
Pricing: Compare pricing models, especially if you have high usage.

OnFinality offers both shared and dedicated RPC nodes for Crust. You can start with the free public endpoint and upgrade to a dedicated node if your project grows. For more details, see our RPC pricing page.

Troubleshooting Common RPC Issues

Connection Timeouts

If you experience timeouts, check your network connection and ensure you are using the correct endpoint. Public endpoints can be rate-limited; consider using a dedicated node for production.

Invalid Chain ID

When connecting to Crust, ensure you use the correct chain ID. For Crust mainnet, the chain ID is crab (or crust). Using the wrong ID will result in connection errors.

WebSocket vs. HTTPS

Some operations require WebSocket (e.g., subscriptions). Use wss:// for WebSocket connections and https:// for HTTPS. Both are available on the public endpoint.

Key Takeaways

Crust Network is a Substrate-based layer 1 blockchain that provides decentralized storage by adding an incentive layer to IPFS.
It offers an on-chain storage market, cross-chain interoperability, and tools for developers.
Crust is suitable for NFT metadata, website hosting, dApp data, and archiving.
To interact with Crust, you need an RPC endpoint. OnFinality provides reliable public and dedicated endpoints.
When choosing an RPC provider, consider reliability, scalability, support, and pricing.

Frequently Asked Questions

What is Crust Network used for?

Crust Network is used for decentralized storage, providing an incentive layer for IPFS. It is commonly used for NFT metadata, website hosting, and dApp data storage.

Is Crust Network a Polkadot parachain?

Yes, Crust is built on Substrate and is a parachain in the Polkadot ecosystem. It also has EVM compatibility, allowing interaction with Ethereum-based chains.

How does Crust Network ensure data availability?

Crust uses a combination of MPoW (Meaningful Proof of Work) and TEE (Trusted Execution Environment) to prove that storage nodes are actually storing the data. The network also replicates data across multiple nodes (typically 30+ replicas).

How do I get a Crust RPC endpoint?

You can use the public endpoint https://rpc.crust.network or get a dedicated endpoint from a provider like OnFinality. For more options, see our supported networks page.

What is the CRU token used for?

CRU is the native token of Crust Network. It is used to pay for storage orders, stake for consensus, and participate in governance.

Can I use Crust with Ethereum?

Yes, Crust has EVM compatibility, so you can interact with it using Ethereum tools and smart contracts. You can also use cross-chain bridges to store data from Ethereum.

Is Crust Network free to use?

There is a cost to store data on Crust, paid in CRU. However, you can use the public RPC endpoint for free to interact with the chain. For high-volume usage, consider a paid RPC plan.

How does Crust compare to Filecoin?

Both Crust and Filecoin use IPFS and provide decentralized storage. Crust is built on Substrate and has EVM compatibility, while Filecoin has its own blockchain. Crust may be easier to integrate with Polkadot and Ethereum ecosystems.

What are the system requirements for running a Crust node?

Running a Crust node requires a machine with sufficient storage and bandwidth. For most developers, using a managed RPC provider is more practical. See our dedicated node page for more information.

How do I monitor my Crust RPC usage?

If you use OnFinality, you can monitor your usage through the dashboard. For custom monitoring, you can use tools like Prometheus to track request metrics.

For more information about Crust Network and RPC services, visit our network page and RPC pricing page.

Related resources

Originally published at OnFinality.

Ethereum Sepolia RPC Endpoint: Chain Settings & Setup

OnFinality — Wed, 26 Aug 2026 05:01:06 +0000

Quick Decision: Which Sepolia RPC Should You Use?

For most development and testing on Ethereum Sepolia, a managed RPC endpoint is the fastest way to start. Public endpoints like https://eth-sepolia.api.onfinality.io/public are free and work for light usage, but they can be rate-limited and less reliable under load. If you're building a production-grade dApp, staging environment, or running automated tests that need consistent throughput, consider a dedicated node or a paid RPC plan. OnFinality offers both shared and dedicated Sepolia endpoints, with WebSocket support and archive data options. Check RPC pricing and supported networks to find the right fit for your workload.

Sepolia at a Glance

Sepolia is Ethereum's primary public testnet for developers. It mimics mainnet's proof-of-stake consensus and is designed for testing smart contracts, wallets, and infrastructure before mainnet deployment. Unlike older testnets like Goerli, Sepolia has a smaller validator set and is more stable, making it the recommended choice for most new projects.

Chain Settings for Sepolia

When adding Sepolia to a wallet or configuring a dApp, you need the following network parameters:

Parameter	Value
Network Name	Ethereum Sepolia
RPC URL	`https://eth-sepolia.api.onfinality.io/public`
Chain ID	11155111 (0xaa36a7)
Currency Symbol	ETH
Block Explorer	https://sepolia.etherscan.io

These settings are consistent across all EVM-compatible wallets and tools. The chain ID is critical: using the wrong one can cause transactions to be broadcast to the wrong network.

Adding Sepolia to MetaMask

To add Sepolia to MetaMask manually:

Open MetaMask and click the network dropdown at the top.
Click "Add network" or "Custom RPC".
Enter the chain settings from the table above.
Click "Save".

Alternatively, you can use a one-click button from services like ChainList, but manual entry ensures you control the RPC endpoint.

Connecting with ethers.js

Here's how to connect to Sepolia using ethers.js in a Node.js environment:

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("https://eth-sepolia.api.onfinality.io/public");

async function getBlockNumber() {
  const blockNumber = await provider.getBlockNumber();
  console.log("Current block number:", blockNumber);
}

getBlockNumber();

For viem:

import { createPublicClient, http } from 'viem';
import { sepolia } from 'viem/chains';

const client = createPublicClient({
  chain: sepolia,
  transport: http('https://eth-sepolia.api.onfinality.io/public')
});

const blockNumber = await client.getBlockNumber();
console.log(blockNumber);

Getting Test ETH on Sepolia

You need test ETH to pay gas fees on Sepolia. Unlike mainnet, this ETH has no real value. Common faucets include:

Alchemy Sepolia Faucet – requires an Alchemy account.
Infura Faucet – requires an Infura account.
Public faucets – like sepoliafaucet.com, but availability varies.

Faucets often have daily limits and may require you to hold a small amount of mainnet ETH or have a GitHub account. If you're running a CI pipeline, consider requesting a larger allocation from a faucet that supports it.

Debugging Common Sepolia RPC Issues

Even with a reliable endpoint, you may encounter issues. Here are common symptoms and fixes:

Symptom	Likely Cause	Fix
`nonce too low`	Transaction nonce mismatch	Reset your account nonce in MetaMask or use `eth_getTransactionCount` with `pending` block parameter
`insufficient funds`	No test ETH	Get test ETH from a faucet
`rate limit exceeded`	Too many requests to public endpoint	Use a paid plan or dedicated node
`connection refused`	Wrong RPC URL	Double-check the endpoint URL and network settings
`block not found`	Querying a block beyond the node's sync	Use a full or archive node for historical data

Using WebSocket for Real-Time Updates

For applications that need real-time data, such as pending transaction monitoring, use a WebSocket endpoint. OnFinality provides WebSocket support for Sepolia. Here's an example using ethers.js:

const { ethers } = require("ethers");

const provider = new ethers.WebSocketProvider("wss://eth-sepolia.api.onfinality.io/public/ws");

provider.on("block", (blockNumber) => {
  console.log("New block:", blockNumber);
});

Note: The exact WebSocket URL may differ; check the Sepolia network page for the current endpoint.

Public vs. Dedicated Sepolia RPC

Public endpoints are free and convenient, but they come with trade-offs:

Rate limits: Public endpoints often limit requests per second, which can break your app under load.
Reliability: They may go down or become slow during peak usage.
Privacy: Requests are shared, so sensitive data could be exposed.

For serious development, consider a dedicated node or a paid RPC plan. OnFinality offers dedicated Sepolia nodes with predictable performance and clear rate limits, ideal for staging environments and load testing. See RPC pricing for options.

Key Takeaways

Sepolia is Ethereum's recommended testnet for development.
Use the chain ID 11155111 and the RPC URL https://eth-sepolia.api.onfinality.io/public to connect.
Public endpoints are fine for light testing, but consider a dedicated node for production-like workloads.
Always verify your nonce and gas settings when debugging transaction issues.
WebSocket endpoints enable real-time updates for dApps.

Frequently Asked Questions

What is the RPC URL for Ethereum Sepolia?

The public RPC URL is https://eth-sepolia.api.onfinality.io/public. You can also find other endpoints on the Sepolia network page.

What is the chain ID for Sepolia?

The chain ID is 11155111 (0xaa36a7).

How do I get Sepolia test ETH?

Use a faucet like Alchemy or Infura. You'll need to sign in and provide your wallet address.

Can I use Sepolia for production?

No, Sepolia is a testnet. Use it only for testing and development. For production, deploy to Ethereum mainnet.

What is the difference between Sepolia and Goerli?

Sepolia is the current recommended testnet, while Goerli is deprecated. Sepolia has a more stable validator set and is better maintained.

How do I add Sepolia to my wallet?

Use the chain settings provided in this article. Most wallets allow you to add a custom network.

What is the block explorer for Sepolia?

The official block explorer is https://sepolia.etherscan.io.

Does OnFinality support WebSocket for Sepolia?

Yes, OnFinality provides WebSocket support for Sepolia. Check the network page for the exact URL.

What are the rate limits for the public Sepolia RPC?

Public endpoints have rate limits to ensure fair usage. For higher limits, consider a paid plan or dedicated node.

How do I troubleshoot "nonce too low" errors?

Reset your account nonce in your wallet or use eth_getTransactionCount with the pending block parameter to get the correct nonce.

Related resources

Originally published at OnFinality.

Polygon Node RPC: Endpoints, Chain Settings & Provider Guide

OnFinality — Wed, 26 Aug 2026 05:00:34 +0000

Quick decision guide: which Polygon RPC setup fits your app?

Before you copy an endpoint into your config, decide what your application actually needs. The right choice depends on request volume, data depth, and whether you can tolerate rate limits.

Prototyping or low traffic: a public RPC endpoint is fine. It costs nothing and is enough for wallet connections, simple reads, and test transactions. Expect rate limits and possible downtime during congestion.
Production app with moderate traffic: a shared or managed RPC service adds reliability, load balancing, and usually WebSocket support. This is the most common choice for dApps, indexers, and backend services.
High throughput, archive data, or custom needs: a dedicated Polygon node gives you exclusive access, no noisy neighbors, and full control over tracing or historical queries. Use this when you need consistent performance under load.

If you are unsure, start with a managed RPC service that offers both shared and dedicated options. That way you can scale without re-architecting your stack. OnFinality provides RPC services for Polygon and many other networks, with pricing that scales from free public endpoints to dedicated nodes.

Polygon chain settings at a glance

Polygon is an EVM-compatible sidechain that settles on Ethereum. The mainnet and the Amoy testnet have distinct chain IDs and endpoints. Use the correct chain ID in your wallet or dApp to avoid sending transactions to the wrong network.

Property	Polygon Mainnet	Polygon Amoy Testnet
Chain ID	137	80002
Native token	POL	POL (test)
Block explorer	polygonscan.com	amoy.polygonscan.com
RPC endpoint	`https://polygon.api.onfinality.io/public`	`https://polygon-amoy.api.onfinality.io/public`
WebSocket support	Yes	Yes

Note: Polygon migrated from MATIC to POL as the native gas token. Always use POL in your transaction configuration.

What is a Polygon node RPC?

A Polygon node RPC is a server that exposes the Polygon blockchain's data and transaction submission capabilities through the JSON-RPC protocol. Applications send HTTP or WebSocket requests to an RPC endpoint to read balances, query contract state, estimate gas, and broadcast transactions.

Running a full Polygon node yourself is possible, but it requires syncing the entire chain, maintaining hardware, and monitoring uptime. Most developers use an RPC provider to avoid this operational overhead. The trade-off is trusting a third party with your requests, so provider reliability and data accuracy matter.

How to connect to Polygon RPC

You can interact with a Polygon RPC endpoint using any Ethereum-compatible library, such as ethers.js or viem. Here is a basic example using ethers.js:

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("https://polygon.api.onfinality.io/public");

async function getBlockNumber() {
  const blockNumber = await provider.getBlockNumber();
  console.log("Current block:", blockNumber);
}

getBlockNumber();

For a raw JSON-RPC call, you can use curl:

curl https://polygon.api.onfinality.io/public \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

If you need real-time updates, use a WebSocket connection:

const { WebSocket } = require("ws");
const ws = new WebSocket("wss://polygon.api.onfinality.io/public");

ws.on("open", () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    method: "eth_subscribe",
    params: ["newHeads"],
    id: 1
  }));
});

ws.on("message", (data) => {
  console.log("New head:", JSON.parse(data));
});

Public vs. shared vs. dedicated Polygon RPC

Understanding the difference between public, shared, and dedicated RPC nodes helps you match infrastructure to your workload.

Public RPC endpoints are free and open to anyone. They are convenient for testing but often have strict rate limits, no SLA, and can become unreliable during network congestion. They are not suitable for production apps.
Shared RPC services (also called managed or API services) pool multiple users on the same infrastructure. Providers add load balancing, caching, and failover to improve reliability. You get a dedicated API key and higher rate limits than public endpoints, but you still share resources with other customers.
Dedicated RPC nodes give you a single-tenant node or cluster. You have exclusive access to the node's compute and bandwidth, which means consistent performance and no "noisy neighbor" issues. This is the best choice for high-throughput applications, archive data needs, or custom RPC methods.

How to choose a Polygon RPC provider

When evaluating RPC providers, focus on the criteria that directly affect your application's performance and reliability. Here is a comparison of common provider types:

Provider Type	Best For	Considerations
OnFinality	Production apps needing scalable shared or dedicated nodes	Multi-chain support, flexible pricing, WebSocket support, dedicated nodes
Public endpoints	Testing, low-traffic tools	Rate limits, no SLA, potential downtime
Large API platforms	Teams wanting a full suite of tools	May require higher pricing tiers for production
Self-hosted nodes	Teams with DevOps capacity	Full control, but high operational cost

Key evaluation criteria:

Uptime and reliability: Look for providers that publish uptime stats or offer SLAs. Avoid making absolute claims; instead, check their status pages and historical performance.
Rate limits and throughput: Understand the request-per-second (RPS) limits for your plan. Public endpoints often cap at a few requests per second, while dedicated nodes can handle much more.
Data availability: Do you need archive data (historical state) or trace methods? Not all providers offer these. Check if the provider supports eth_getLogs with large ranges or debug_traceTransaction.
WebSocket support: For real-time applications, ensure the provider offers a stable WebSocket endpoint.
Pricing model: Compare per-request, per-RPS, or flat monthly pricing. Estimate your monthly request volume to choose the most cost-effective plan.
Geographic distribution: Providers with multiple regions can reduce latency for your users.

Setting up a Polygon node with OnFinality

OnFinality offers both shared and dedicated Polygon RPC nodes. To get started:

Create an account on the OnFinality platform.
Navigate to the Polygon network page and select the network (mainnet or Amoy testnet).
Choose a shared or dedicated node plan. For production, a dedicated node gives you a private endpoint and higher throughput.
Copy your API key and endpoint URL into your application configuration.

For a dedicated node, you can also enable archive mode to access historical state. This is useful for analytics, indexers, and applications that need past balances or events.

Common pitfalls and troubleshooting

Even with a reliable RPC provider, you may encounter issues. Here are common problems and how to fix them:

Incorrect chain ID: Using chain ID 137 for Amoy or 80002 for mainnet will cause transactions to fail. Always verify your network configuration.
Rate limiting: If you see 429 Too Many Requests, you are hitting the rate limit. Reduce request frequency, use batching, or upgrade to a higher-tier plan.
WebSocket disconnects: WebSocket connections can drop due to network issues or server restarts. Implement reconnection logic with exponential backoff.
eth_getLogs timeouts: Querying logs over a large block range can time out. Use smaller ranges and paginate.
Nonce errors: If you send multiple transactions from the same address, ensure you are using the correct nonce. See our nonce guide for details.

Monitoring your Polygon RPC usage

Once your app is live, monitor your RPC usage to avoid surprises. Track metrics like:

Request volume: How many requests per second/minute are you sending?
Error rate: Percentage of failed requests (timeouts, rate limits, etc.).
Latency: Average and p95 response times.
WebSocket connection stability: How often do connections drop?

Most RPC providers offer a dashboard with these metrics. OnFinality's platform includes usage analytics for both shared and dedicated nodes.

Key Takeaways

Polygon mainnet uses chain ID 137, and Amoy testnet uses 80002. Always use the correct chain ID.
Public RPC endpoints are fine for testing but not for production. Use a managed or dedicated service for reliable performance.
Evaluate providers based on uptime, rate limits, data availability, WebSocket support, and pricing.
OnFinality offers shared and dedicated Polygon RPC nodes with flexible pricing and multi-network support.
Monitor your RPC usage to optimize costs and performance.

Frequently Asked Questions

What is the difference between Polygon mainnet and Amoy testnet RPC?

Mainnet RPC connects to the live Polygon network with real POL tokens. Amoy testnet RPC connects to a test network where you can use free test tokens for development. They have different chain IDs and endpoints.

Can I use a public Polygon RPC for production?

It is not recommended. Public endpoints have rate limits and no uptime guarantees, which can cause your app to fail under load. A managed RPC service is a safer choice.

Does OnFinality support Polygon WebSocket?

Yes, OnFinality supports both HTTP and WebSocket connections for Polygon mainnet and Amoy testnet.

How do I get test POL for Amoy?

You can use the official Polygon faucet to request test POL on Amoy. Check the Polygon network page for more details.

What is a dedicated Polygon node?

A dedicated Polygon node is a single-tenant node provisioned exclusively for your use. It provides consistent performance, higher throughput, and optional archive data access.

How much does a Polygon RPC cost?

Pricing varies by provider and plan. OnFinality offers a free public endpoint and paid plans for shared and dedicated nodes. See RPC pricing for current rates.

Related resources

Originally published at OnFinality.

Kaia API: Endpoints, Methods, and How to Connect

OnFinality — Wed, 26 Aug 2026 05:00:01 +0000

Quick recommendation: Which Kaia API access mode fits your project?

Before you write any code, decide how you will reach the Kaia network. The right choice depends on your workload, not on which provider has the most documentation.

Prototyping or a hackathon: use a public endpoint. It is free and fine for low-volume testing, but it is shared and can be rate-limited or unstable under load.
A production dApp or backend service: use a managed RPC provider. You get dedicated throughput, higher reliability, and support for WebSocket and archive data. OnFinality offers a managed Kaia RPC service with public and dedicated options.
Heavy data indexing or analytics: you likely need archive node access and a provider that supports large historical queries. Check whether the provider offers archive data and what the pricing looks like on RPC pricing.

If you are still evaluating providers, the table in the next section gives you the criteria that matter most.

What is the Kaia API?

Kaia is a public, EVM-compatible Layer 1 blockchain created from the merger of Klaytn and Finschia. It is designed for high performance with one-second block times, low transaction fees, and instant finality, making it suitable for large-scale Web3 and stablecoin applications.

The Kaia API is the JSON-RPC interface that lets you interact with the Kaia network. If you have worked with Ethereum's JSON-RPC APIs, the interface will feel familiar. You can use it to read blockchain data, send transactions, and call smart contract methods.

Kaia exposes several API namespaces:

Ethereum-compatible namespaces: eth_, net_, web3_ – standard methods like eth_blockNumber, eth_getBalance, eth_call, and eth_sendRawTransaction.
Kaia-specific namespaces: kaia_ – methods that extend the Ethereum API with Kaia-specific features, such as kaia_getBlockByNumber and kaia_getTransactionReceipt.
Legacy klay_ namespace: maintained for backward compatibility with the old Klaytn API. It supports the same operations as kaia_ but with the klay_ prefix.
Debug namespace: debug_ – development and debugging utilities for deep blockchain analysis and transaction inspection.

For a complete list of supported methods, refer to the official Kaia documentation.

Kaia chain settings at a glance

When you configure a wallet or a dApp to connect to Kaia, you need the correct chain parameters. Here are the essential settings for the Kaia mainnet:

Parameter	Value
Network Name	Kaia Mainnet
Chain ID	8217
Native Currency	KAIA (symbol: KAIA, decimals: 18)
Block Explorer	Kaiascope
Public RPC Endpoint	`https://klaytn.api.onfinality.io/public`

These settings are also available on the Kaia network page.

How to connect to the Kaia API

You can connect to the Kaia API using any Ethereum-compatible library, such as ethers.js, viem, or web3.js. Here is a simple example using ethers.js:

import { JsonRpcProvider } from 'ethers';

const provider = new JsonRpcProvider('https://klaytn.api.onfinality.io/public');

async function getBlockNumber() {
  const blockNumber = await provider.getBlockNumber();
  console.log('Latest block:', blockNumber);
}

getBlockNumber();

You can also make raw JSON-RPC requests with curl:

curl -X POST https://klaytn.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

For WebSocket support, you can use a WebSocket endpoint if your provider offers one. OnFinality's managed Kaia endpoints support both HTTP and WebSocket, which is useful for real-time applications like price feeds or transaction monitoring.

Kaia API methods: what you can do

Kaia's API is broad. Here are the most common method groups you will use:

Chain information: eth_chainId, eth_blockNumber, eth_gasPrice
Account queries: eth_getBalance, eth_getTransactionCount, eth_getCode
Smart contract interaction: eth_call, eth_sendRawTransaction, eth_getTransactionReceipt
Block queries: eth_getBlockByNumber, eth_getBlockByHash
Kaia-specific: kaia_getBlockByNumber, kaia_getTransactionReceipt, kaia_call
Debug: debug_traceTransaction, debug_traceBlockByNumber

For a full reference, see the Kaia JSON-RPC API docs.

How to choose a Kaia RPC provider

When you move beyond a public endpoint, you need to evaluate RPC providers. Here is a comparison table to guide your decision:

Criterion	What to check	Why it matters
Throughput and rate limits	Does the provider offer dedicated throughput or shared limits?	High-traffic dApps need consistent performance without sudden rate limiting.
Reliability and uptime	What is the provider's historical uptime? Do they have a status page?	Downtime directly impacts your users and can cause failed transactions.
Archive data	Does the provider support archive requests?	Indexers and analytics tools often need historical state.
WebSocket support	Is WSS available for real-time subscriptions?	Essential for applications that need live updates.
Geographic distribution	Where are the provider's nodes located?	Global edge networks reduce latency for users worldwide.
Pricing model	Is it pay-as-you-go, subscription, or usage-based?	Predictable costs help you scale without surprises.
Support and SLAs	What level of support is offered?	Production apps need responsive support when issues arise.

OnFinality is a strong option for Kaia RPC. We offer a managed Kaia endpoint with both public and dedicated nodes, and you can see our pricing for details. Our infrastructure is designed for production workloads, with global edge nodes and support for WebSocket and archive data.

Common pitfalls and how to avoid them

Even with a good provider, you can run into issues. Here are some common pitfalls when working with the Kaia API:

Using the wrong chain ID: Make sure you use 8217 for Kaia mainnet and 1001 for the Kairos testnet. Using the wrong chain ID will cause transactions to fail.
Rate limiting on public endpoints: Public endpoints are shared, so they can be rate-limited. If you see 429 errors, consider moving to a managed provider.
Not handling WebSocket reconnections: If you use WebSocket, implement reconnection logic to handle network drops.
Assuming all methods are available: Some providers may not support debug or archive methods. Check your provider's documentation.
Ignoring gas price fluctuations: Kaia has low fees, but gas price can still vary. Use eth_gasPrice or a gas estimator to avoid stuck transactions.

Debugging Kaia API calls

When something goes wrong, here is a quick debugging path:

Check the endpoint: Verify that you are using the correct URL and that it is reachable.
Check the chain ID: Ensure your requests include the correct chain ID.
Test with a simple method: Start with eth_blockNumber to confirm basic connectivity.
Inspect error messages: JSON-RPC errors include a code and message. Common codes are -32601 (method not found) and -32000 (server error).
Use a block explorer: If a transaction fails, look it up on Kaiascope to see the revert reason.

If you are using OnFinality, you can also check our network status page for any ongoing incidents.

Key Takeaways

The Kaia API is an Ethereum-compatible JSON-RPC interface for the Kaia blockchain.
Use the correct chain ID (8217 for mainnet) and endpoint for your network.
Public endpoints are fine for testing, but production apps should use a managed RPC provider like OnFinality.
Evaluate providers based on throughput, reliability, archive data, WebSocket support, and pricing.
Debug systematically: check endpoint, chain ID, and method availability before diving deeper.

Frequently Asked Questions

What is the Kaia API?

The Kaia API is the JSON-RPC interface for the Kaia blockchain, allowing developers to interact with the network using Ethereum-compatible methods.

What is the Kaia chain ID?

The Kaia mainnet chain ID is 8217. The Kairos testnet uses 1001.

Is the Kaia API free?

Public endpoints are free but have rate limits. For production use, you will likely need a paid managed RPC service.

Can I use ethers.js with Kaia?

Yes, Kaia is EVM-compatible, so you can use ethers.js, viem, web3.js, and other Ethereum libraries.

Does OnFinality support Kaia?

Yes, OnFinality provides a managed Kaia RPC endpoint. You can find more details on the Kaia network page.

Related resources

Originally published at OnFinality.

Bitcoin Testnet RPC: Setup, Faucet & Best Practices

OnFinality — Wed, 26 Aug 2026 04:59:28 +0000

Quick Recommendation: When to Use Bitcoin Testnet vs Regtest

If you are building a Bitcoin application, you need a safe environment to test transactions, wallet logic, and block processing. Bitcoin Testnet is a public network that mimics mainnet behavior but uses valueless coins. It is ideal for integration testing, wallet development, and any scenario where you need to interact with a live network of peers.

For most development, however, regtest mode is often the better choice. Regtest gives you a private blockchain where you control block creation, making it faster and more deterministic for unit tests and CI pipelines. Use testnet when you need to test against a public network with realistic transaction propagation and mempool behavior.

If you need a reliable testnet RPC endpoint without running your own node, OnFinality provides managed Bitcoin Testnet RPC services. Check our RPC pricing and supported networks for details.

What Is Bitcoin Testnet?

Bitcoin Testnet is an alternative blockchain designed for testing. It runs the same consensus rules as mainnet but uses testnet coins (tBTC) that have no real-world value. This allows developers to experiment with transactions, smart contracts (via sidechains), and wallet features without financial risk.

Testnet is a public resource maintained by the community. It is not a private sandbox—anyone can join, and the network experiences real transaction traffic. This makes it useful for testing how your application behaves under realistic conditions, such as mempool congestion and block reorgs.

Testnet vs Mainnet vs Regtest: Key Differences

Feature	Mainnet	Testnet	Regtest
Coin value	Real	None	None
Network access	Public	Public	Private
Block creation	~10 min	~10 min	Instant (on demand)
Use case	Production	Integration testing	Unit tests, CI
Faucet needed	No	Yes	No
Transaction restrictions	Standard	Relaxed	None

Testnet relaxes some standard transaction checks, allowing you to test features that might be disabled on mainnet. However, because it is a shared network, you should not abuse it—faucets and nodes are provided by volunteers.

How to Get Testnet Bitcoin (Faucets)

To send transactions on testnet, you need tBTC. You can obtain it from public faucets. These services send a small amount of testnet coins to a testnet address. Common faucets include:

Coinfaucet.eu
Bitcoin testnet faucets listed on community sites

When using a faucet, ensure you provide a valid testnet address. Testnet addresses typically start with m or n (for P2PKH) or tb1 (for SegWit). Do not send mainnet BTC to a testnet address—they are incompatible.

Setting Up a Bitcoin Testnet Node

To interact with testnet, you can run your own node using Bitcoin Core. Here is a basic setup:

Download and install Bitcoin Core.
Configure bitcoin.conf to use testnet:

# bitcoin.conf
testnet=1
server=1
rpcuser=yourusername
rpcpassword=yourpassword

Start bitcoind in testnet mode:

bitcoind -testnet -daemon

Wait for the node to sync. Testnet blockchain is smaller than mainnet but still takes time.
Use bitcoin-cli to interact with the node:

bitcoin-cli -testnet getblockchaininfo

This will show your node's sync status, block height, and network information.

Connecting to a Bitcoin Testnet RPC Endpoint

If you prefer not to run a full node, you can use a managed RPC provider like OnFinality. This gives you a public or private endpoint without the overhead of syncing and maintaining a node.

OnFinality offers Bitcoin Testnet RPC endpoints that you can use directly in your applications. For example, you can make JSON-RPC calls to query blockchain data:

curl -X POST https://bitcoin-testnet.rpc.onfinality.io \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"1.0","id":1,"method":"getblockchaininfo","params":[]}'

Replace the URL with the actual endpoint provided by OnFinality for Bitcoin Testnet. Check the network page for the latest endpoint details.

Using Bitcoin Testnet with JavaScript (bitcoinjs-lib)

For web or Node.js applications, you can use libraries like bitcoinjs-lib to create and broadcast transactions. Here is an example of generating a testnet address:

const bitcoin = require('bitcoinjs-lib');

const network = bitcoin.networks.testnet;
const keyPair = bitcoin.ECPair.makeRandom({ network });
const { address } = bitcoin.payments.p2pkh({ pubkey: keyPair.publicKey, network });

console.log('Testnet address:', address);

To broadcast a transaction, you need to connect to a testnet node or RPC endpoint. You can use bitcoin-cli or a library like bitcoin-rpc to send raw transactions.

Common Pitfalls and Troubleshooting

1. Faucet Not Sending Coins

Faucets may be temporarily out of funds or require a delay between requests. Try a different faucet or wait a few minutes.

2. Transaction Not Confirming

Testnet blocks are mined every ~10 minutes, but sometimes the network is slow. Check the mempool on a testnet explorer like mempool.space/testnet to see if your transaction is pending. You may need to increase the fee.

3. Wrong Network Address

Ensure you are using testnet addresses. Sending to a mainnet address will result in lost funds (even though they are testnet coins).

4. Node Sync Issues

If your node is not syncing, check your internet connection and disk space. You can also use bitcoin-cli -testnet getblockcount to see the current block height and compare it with the explorer.

Monitoring Your Testnet Node

If you run your own node, you should monitor its health. Use bitcoin-cli to check sync status and network connections:

bitcoin-cli -testnet getnetworkinfo
bitcoin-cli -testnet getpeerinfo

For production-grade monitoring, consider using a managed RPC service that handles uptime and scaling. OnFinality provides dedicated nodes with monitoring and failover, as described on our dedicated node page.

Key Takeaways

Bitcoin Testnet is a public test network with valueless coins, ideal for integration testing.
Regtest is better for unit tests and CI due to its deterministic nature.
Use faucets to get tBTC, but be mindful of network abuse.
You can run your own node or use a managed RPC provider like OnFinality.
Always verify you are using testnet addresses and correct RPC endpoints.

Frequently Asked Questions

What is the difference between Bitcoin Testnet and Regtest?

Testnet is a public network with real peers and blocks, while regtest is a private network where you control block creation. Regtest is faster and more predictable for development.

How do I get testnet Bitcoin?

You can get tBTC from public faucets. Search for "Bitcoin testnet faucet" and enter your testnet address to receive free coins.

Can I use Bitcoin Testnet for production?

No, testnet is only for testing. Coins have no value, and the network may be reset or experience issues. Use mainnet for production.

Does OnFinality support Bitcoin Testnet RPC?

Yes, OnFinality provides Bitcoin Testnet RPC endpoints. Check our network page for details and endpoint URLs.

How do I switch from testnet to mainnet?

In your configuration, change testnet=1 to testnet=0 or remove the line. You will need to sync the mainnet blockchain, which is much larger.

Related resources

Originally published at OnFinality.

Kusama Migration: Update Your RPC Endpoints Now

OnFinality — Mon, 24 Aug 2026 04:29:08 +0000

Quick Migration Checkpoints

If you are a developer or infrastructure operator on Kusama, the migration to Asset Hub changes where you send certain RPC calls. Here is a quick checklist to get your endpoints updated:

Identify which chain your dApp depends on. If you were using Relay Chain RPC for balance transfers, staking, or governance, you likely need to switch to Asset Hub Kusama.
Update your network configuration. Change the RPC endpoint and chain ID to Asset Hub Kusama. See the Asset Hub Kusama network page for the official endpoint.
Test with a small transaction. Before going live, send a test transfer to confirm your wallet and backend are using the correct chain.
Monitor for errors. Watch for InvalidTransaction or UnknownConnection errors that indicate you are still pointing to the old chain.

If you are unsure which chain your use case requires, the next section breaks down the migration and its impact.

What the Kusama Migration Actually Changed

The Kusama migration, executed on October 7, 2025, moved core functionality from the Kusama Relay Chain to Asset Hub Kusama. This is part of a broader roadmap to make the network more scalable and accessible. The migration was completed in about 3 hours and 13 minutes, moving all assets, pallets, accounts, and proxies.

For developers, the key change is that Asset Hub Kusama is now the primary chain for asset transfers and management. The Relay Chain still exists but is no longer the place to send KSM transfers or interact with assets. This means your RPC endpoints must be updated to point to Asset Hub Kusama for these operations.

Why This Matters for Your dApp

If your dApp handles KSM transfers, queries balances, or interacts with assets, it must now talk to Asset Hub Kusama. Using the old Relay Chain endpoint will result in errors or stale data. The migration also brought several improvements:

Lower minimum balance: reduced from 0.00003 KSM to 0.000003 KSM.
Lower transaction fees: reduced from 0.00053 KSM to 0.00009 KSM.
More token support: USDT, USDC, DOT, and other ecosystem tokens.
Unified access: KSM, assets, staking, and governance in one place.
Fee payment in any token: pay transaction fees with any supported asset.

These changes are beneficial, but they require you to update your infrastructure to take advantage of them.

Chain Settings at a Glance

Here are the key settings for Asset Hub Kusama. Use these to update your network configuration.

Setting	Value
Network Name	Asset Hub Kusama
Chain ID	1000
RPC Endpoint	See Asset Hub Kusama network page
Explorer	https://assethub-kusama.subscan.io
Token Symbol	KSM
Token Decimals	12

Note: The RPC endpoint is not hardcoded here because it may vary by provider. Use the official OnFinality public endpoint listed on the network page.

Updating Your RPC Endpoint

To update your dApp, you need to change the RPC endpoint in your configuration. Here is an example using a common JavaScript library like polkadot-js:

const { ApiPromise, WsProvider } = require('@polkadot/api');

// Replace with the official Asset Hub Kusama endpoint
const wsProvider = new WsProvider('wss://assethub-kusama-rpc.polkadot.io');

async function main() {
  const api = await ApiPromise.create({ provider: wsProvider });
  console.log(`Connected to chain: ${await api.rpc.system.chain()}`);
}

main().catch(console.error);

If you are using a REST API or a different library, the same principle applies: update the endpoint URL and ensure your chain ID matches.

Common Pitfalls and How to Avoid Them

Here are the most common issues developers face after the migration and how to avoid them:

Pitfall	Symptom	Fix
Using Relay Chain endpoint for transfers	Transaction fails with `InvalidTransaction`	Switch to Asset Hub Kusama endpoint
Wrong chain ID in wallet config	Wallet shows wrong network or fails to connect	Set chain ID to 1000
Not updating backend services	Balance queries return stale data	Update all RPC URLs in your backend
Forgetting to update indexers	Indexer misses new blocks	Reconfigure indexer to use Asset Hub Kusama

Migration Checklist for Production Apps

Before you deploy, run through this checklist to ensure a smooth transition:

[ ] Update all RPC endpoints to Asset Hub Kusama.
[ ] Update chain ID in all configurations.
[ ] Test with a small transfer on the new chain.
[ ] Verify balance queries return correct data.
[ ] Monitor logs for errors after deployment.
[ ] Communicate changes to your users if they use your app for KSM transfers.

Choosing the Right RPC Provider

When updating your endpoints, you may also want to evaluate your RPC provider. The migration is a good time to ensure your provider supports Asset Hub Kusama and offers the reliability you need. Consider the following:

Network coverage: Does the provider support Asset Hub Kusama and other Kusama parachains?
Transport options: Do you need WebSocket, HTTPS, or both?
Rate limits: Are there limits that could affect your traffic?
Support: Is there a dedicated support channel for issues?

OnFinality offers RPC services for Asset Hub Kusama and many other networks. You can check supported RPC networks and RPC pricing to see if it fits your needs. OnFinality also provides dedicated nodes for high-traffic applications.

Key Takeaways

The Kusama migration moved core functionality to Asset Hub Kusama.
Update your RPC endpoints to Asset Hub Kusama for asset transfers and balance queries.
Use the correct chain ID (1000) and test before going live.
Monitor for common errors like InvalidTransaction.
Evaluate your RPC provider to ensure it supports the new chain.

Frequently Asked Questions

Do I need to migrate my KSM tokens?

No. The migration was automatic. Your KSM tokens moved to Asset Hub Kusama without any action on your part.

What happens to my old transaction history?

Old transaction history remains on the Kusama Relay Chain. You can still query it, but new transactions will be on Asset Hub Kusama.

Can I still use the Relay Chain for staking?

Staking functionality has moved to Asset Hub Kusama. You should update your staking dApp or wallet to use the new chain.

How do I find the official RPC endpoint?

Check the Asset Hub Kusama network page for the official OnFinality public endpoint.

What if I use a wallet that doesn't support Asset Hub Kusama?

You may need to switch to a wallet that supports the migration. Many wallets have updated, but some like Trust Wallet had issues. Check your wallet's documentation for migration support.

Related resources

Originally published at OnFinality.

Composable RPC: Endpoints, Dedicated Nodes & Integration

OnFinality — Mon, 24 Aug 2026 04:28:35 +0000

Quick Recommendation: Public Endpoint or Dedicated Node?

Before diving into the technical details, decide which Composable RPC setup fits your stage:

Prototyping or light testing: Use the public Composable Finance RPC endpoint. It is fine for lightweight checks, prototypes, and quick integration tests.
Production dApp or backend: Move to authenticated endpoints or a dedicated node when you need clearer limits, analytics, and operational visibility.
High-throughput or custom needs: A dedicated Composable Finance node gives you isolated resources, custom configuration, and predictable capacity.

If you are unsure, start with the public endpoint, measure your traffic, and then scale to authenticated or dedicated infrastructure as your usage grows. OnFinality offers both paths, so you can migrate without changing your application code.

What Is Composable Finance?

Composable Finance is a cross-chain DeFi infrastructure project focused on improving the accessibility, efficiency, and security of the blockchain industry. Its technology stack enables trustless interoperability across ecosystems such as Ethereum, Polkadot, Kusama, Cosmos, and NEAR, powered by the first cross-ecosystem implementation of IBC (Inter-Blockchain Communication).

For developers, this means Composable is not just a single chain but a network of connected chains. When you interact with Composable, you are typically querying its relay chain or one of its connected parachains. The RPC endpoints you use must reflect the specific chain you are targeting.

Composable RPC Endpoints

OnFinality provides public RPC endpoints for Composable Finance that you can use to connect wallets, dApps, dashboards, bots, and backend services without operating your own node from day one.

Public Endpoint Testing

Start with the public Composable Finance RPC endpoint for lightweight checks, prototypes, and quick integration tests. The public endpoint is rate-limited and shared, so it is not suitable for production workloads.

Authenticated API Access

Move production traffic to authenticated endpoints when you need clearer limits, analytics, and operational visibility. Authenticated endpoints are available through OnFinality's API service and provide a more stable foundation for production apps.

Standard RPC Methods

Composable Finance supports standard JSON-RPC methods for querying blocks, transactions, balances, events, and chain state. You can use HTTP and WebSocket transports, depending on your needs.

Connecting to Composable RPC

Here is a basic example of how to make a JSON-RPC call to a Composable RPC endpoint using curl:

curl -H "Content-Type: application/json" \
  -d '{"id":1, "jsonrpc":"2.0", "method":"system_health", "params":[]}' \
  https://composable.api.onfinality.io/public

Replace the URL with the actual public endpoint from the Composable network page if it differs. For production, use your authenticated endpoint URL.

For WebSocket subscriptions, you can use libraries like wscat or ethers.js to listen to new blocks or events.

When to Use Dedicated Composable Nodes

Production teams need more than an endpoint URL. They need observability, predictable capacity, and a path from shared RPC access to isolated infrastructure.

Request Visibility

Track usage patterns and response activity so your team can understand traffic growth before it becomes an incident. OnFinality provides analytics for authenticated endpoints, and dedicated nodes give you full visibility into your requests.

Dedicated Node Path

Use dedicated Composable Finance nodes when your workload needs isolated resources, custom configuration, and operational control. Dedicated nodes are ideal for high-throughput applications, indexers, and services that require consistent performance.

Archive and Historical Data

If your application needs historical state, consider an archive node. Archive nodes store the full history of the chain, enabling queries like eth_getLogs over long ranges. OnFinality offers archive support for many networks, including Composable.

Composable RPC vs. Other Networks

Composable Finance is unique because it bridges multiple ecosystems. When you work with Composable, you might need to interact with different chains that use different RPC standards. For example, Ethereum-based chains use eth_* methods, while Substrate-based chains use system_* and state_* methods.

Here is a quick comparison of typical RPC methods across the ecosystems Composable touches:

Ecosystem	Common RPC Methods	Transport
Ethereum	`eth_blockNumber`, `eth_getBalance`, `eth_call`	HTTP, WebSocket
Polkadot	`chain_getBlock`, `system_health`, `state_getStorage`	HTTP, WebSocket
Cosmos	`cosmos_tx`, `abci_query`	HTTP, gRPC
NEAR	`near_block`, `query`	HTTP

When integrating with Composable, ensure your client library matches the chain you are querying.

Integration Examples

Using ethers.js with Composable (Ethereum-compatible)

If you are interacting with an Ethereum-compatible chain within the Composable ecosystem, you can use ethers.js:

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("https://composable.api.onfinality.io/public");

async function getBlockNumber() {
  const blockNumber = await provider.getBlockNumber();
  console.log("Current block number:", blockNumber);
}

getBlockNumber();

Using Polkadot.js with Composable (Substrate-based)

For Substrate-based chains, use @polkadot/api:

const { ApiPromise, WsProvider } = require("@polkadot/api");

const wsProvider = new WsProvider("wss://composable.api.onfinality.io/public-ws");

async function main() {
  const api = await ApiPromise.create({ provider: wsProvider });
  const health = await api.rpc.system.health();
  console.log("Health:", health.toHuman());
  await api.disconnect();
}

main();

Note: The WebSocket URL is an example; use the actual endpoint from the Composable network page.

Common Pitfalls and Troubleshooting

1. Wrong RPC Method for the Chain

Using eth_* methods on a Substrate chain will fail. Always check the chain type and use the appropriate JSON-RPC namespace.

2. Rate Limiting on Public Endpoints

Public endpoints are shared and rate-limited. If you see 429 Too Many Requests, switch to an authenticated endpoint or a dedicated node.

3. WebSocket Connection Drops

WebSocket connections can drop due to network issues or server restarts. Implement reconnection logic in your client.

4. Historical Data Gaps

If you need historical data, ensure you are using an archive node. Regular nodes may not have full history.

Choosing the Right Composable RPC Setup

Here is a decision matrix to help you choose:

Workload	Recommended Setup	Why
Prototype / hackathon	Public endpoint	Free, quick to start
Production dApp	Authenticated endpoint	Better limits, analytics
High-throughput / indexing	Dedicated node	Isolated resources, custom config
Historical queries	Archive node	Full chain history

OnFinality offers all these options, so you can start small and scale as needed. For pricing details, see RPC pricing.

Key Takeaways

Composable Finance is a cross-chain DeFi project, and its RPC endpoints vary by the underlying chain.
Start with the public endpoint for testing, but move to authenticated or dedicated nodes for production.
Use the correct JSON-RPC methods for the chain you are querying (Ethereum vs. Substrate).
Dedicated nodes provide isolation, observability, and custom configuration for demanding workloads.
OnFinality supports Composable Finance with public, authenticated, and dedicated node options.

Frequently Asked Questions

What is Composable RPC?

Composable RPC refers to the Remote Procedure Call endpoints used to interact with the Composable Finance network. These endpoints allow developers to query chain data, submit transactions, and subscribe to events.

How do I get a Composable RPC endpoint?

You can use the public endpoint from OnFinality's Composable network page for testing, or sign up for an API key to get authenticated endpoints.

Is the public Composable RPC endpoint free?

Yes, the public endpoint is free to use for testing and light usage. For production, consider authenticated endpoints or dedicated nodes.

What is the difference between public and dedicated nodes?

Public nodes are shared and rate-limited, while dedicated nodes provide isolated resources, custom configuration, and better performance for production workloads.

Does OnFinality support archive nodes for Composable?

OnFinality offers archive node support for many networks. Check the supported networks page for the latest availability.

How do I choose between HTTP and WebSocket?

Use HTTP for simple queries and WebSocket for real-time subscriptions, such as new block notifications or event listening.

Can I use Composable RPC for Ethereum-based chains?

Yes, if the chain is Ethereum-compatible, you can use standard eth_* methods. For Substrate-based chains, use the appropriate Substrate methods.

What should I do if I get rate-limited?

If you hit rate limits on the public endpoint, upgrade to an authenticated endpoint or a dedicated node to get higher limits and better performance.

For more guidance on selecting an RPC provider, see our How to Choose an RPC Provider guide.

Related resources

Originally published at OnFinality.

Sonic Network RPC: Chain Settings, Endpoints & Providers

OnFinality — Mon, 24 Aug 2026 04:28:02 +0000

Quick decision guide: which Sonic RPC should you use?

Before diving into the chain settings, decide which type of Sonic RPC fits your use case. The right choice depends on your workload, not just the lowest latency.

Prototyping or wallet setup: Use the official public endpoint https://rpc.soniclabs.com or the OnFinality public endpoint https://sonic.api.onfinality.io/public. These are fine for testing, adding the network to a wallet, or low-volume requests.
Production dApp or indexer: A managed RPC provider with a dedicated endpoint is safer. Public endpoints can throttle or rate-limit heavy usage, and they rarely offer archive data or WebSocket reliability guarantees.
High-throughput or data-heavy workloads: If you need eth_getLogs over large ranges, trace methods, or consistent WebSocket streams, consider a dedicated Sonic node. Dedicated nodes give you isolated resources and predictable performance.
Compliance or data retention: If you need historical state or trace data, check whether the provider offers archive nodes. Not all Sonic RPC endpoints provide archive data.

For a deeper look at provider evaluation, see our guide on choosing an RPC provider.

Sonic network at a glance

Sonic is an EVM-compatible Layer-1 blockchain designed for high throughput and sub-second finality. It is the successor to Fantom and uses the S token for gas, staking, and governance. For developers, the key takeaway is that Sonic is fully EVM-compatible, so existing Ethereum tooling works with minimal changes.

The official chain settings are:

Setting	Value
Network name	Sonic Mainnet
RPC URL	`https://rpc.soniclabs.com`
Chain ID	146 (0x92)
Currency symbol	S
Block explorer	https://sonicscan.org

These settings are what you need to add Sonic to a wallet or configure a dApp. The OnFinality public endpoint https://sonic.api.onfinality.io/public is also available and can be used as an alternative.

Adding Sonic to MetaMask or other wallets

Most wallets let you add a custom network manually. The process is similar across MetaMask, Rabby, and other EVM wallets.

Open your wallet and go to the network selection dropdown.
Click Add Network or Add a network manually.
Enter the following details:
- Network name: Sonic
- New RPC URL: https://rpc.soniclabs.com or https://sonic.api.onfinality.io/public
- Chain ID: 146
- Currency symbol: S
- Block explorer URL: https://sonicscan.org
Save the network and switch to it.

If you are using a wallet that supports WalletConnect or chainlist, you can also use a one-click add. However, manually entering the details ensures you control which RPC endpoint you use.

Connecting a dApp with ethers or viem

For developers, connecting to Sonic is straightforward. Here is an example using ethers.js:

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider("https://sonic.api.onfinality.io/public");

const network = await provider.getNetwork();
console.log("Chain ID:", network.chainId); // 146

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

With viem:

import { createPublicClient, http } from "viem";

const client = createPublicClient({
  chain: {
    id: 146,
    name: "Sonic",
    nativeCurrency: { name: "Sonic", symbol: "S", decimals: 18 },
    rpcUrls: {
      default: { http: ["https://sonic.api.onfinality.io/public"] },
    },
  },
  transport: http(),
});

const blockNumber = await client.getBlockNumber();
console.log("Latest block:", blockNumber);

Making JSON-RPC calls with curl

If you are debugging or testing, a simple curl request can verify connectivity:

curl https://sonic.api.onfinality.io/public \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

A successful response returns the latest block number in hexadecimal format.

WebSocket support and real-time data

For applications that need real-time updates, such as transaction monitoring or order books, WebSocket endpoints are essential. The official Sonic RPC supports WebSocket, and many providers offer WSS endpoints.

A WebSocket subscription example using viem:

import { createPublicClient, webSocket } from "viem";

const client = createPublicClient({
  chain: {
    id: 146,
    name: "Sonic",
    nativeCurrency: { name: "Sonic", symbol: "S", decimals: 18 },
    rpcUrls: {
      default: { webSocket: ["wss://sonic-rpc.publicnode.com"] },
    },
  },
  transport: webSocket(),
});

const unwatch = client.watchBlockNumber({
  onBlockNumber: (blockNumber) => {
    console.log("New block:", blockNumber);
  },
});

Note that public WebSocket endpoints may have connection limits. For production, a dedicated WebSocket endpoint is recommended.

Sonic RPC provider comparison

When evaluating Sonic RPC providers, consider the following criteria. The table below compares typical offerings, but always verify current details on each provider's site.

Provider	Endpoint type	Archive data	WebSocket	Dedicated nodes
OnFinality	Public, managed, dedicated	Yes (on request)	Yes	Yes
dRPC	Public, premium	Yes (premium)	Yes	No
Dwellir	Public, dedicated	Yes	Yes	Yes
Ankr	Public, premium	Yes (premium)	Yes	No

OnFinality offers both a public endpoint and dedicated Sonic nodes. Dedicated nodes give you isolated resources, which is important for high-throughput applications. You can see the full list of supported networks on our networks page.

When to choose a dedicated Sonic node

A dedicated node is a single-tenant RPC endpoint that is not shared with other users. This is useful when:

Your application generates a high volume of requests and you need consistent performance.
You need archive data or trace methods that are not available on public endpoints.
You want to avoid rate limits and throttling.
You need a private WebSocket endpoint for real-time data.

OnFinality's dedicated node service provides Sonic nodes with isolated resources. You can choose the node size and configuration that matches your workload.

Common pitfalls and troubleshooting

Even with the right endpoint, you may run into issues. Here are common problems and how to fix them:

Wrong chain ID: Ensure your wallet or dApp uses chain ID 146. A mismatch causes transaction signing errors.
Rate limiting: Public endpoints often limit requests per second. If you hit limits, switch to a managed or dedicated endpoint.
Missing archive data: Some RPC methods like eth_getLogs with large ranges require archive nodes. If you get errors, check if your provider offers archive data.
WebSocket disconnects: Public WebSocket endpoints may drop connections. Use a dedicated WebSocket endpoint for production.
Block explorer discrepancies: If the explorer shows a different block height than your RPC, it may be a sync issue. Verify with multiple sources.

Monitoring your Sonic RPC health

To ensure your application stays healthy, monitor your RPC endpoint. A simple health check script can alert you to issues:

#!/bin/bash

RPC_URL="https://sonic.api.onfinality.io/public"

response=$(curl -s -X POST $RPC_URL \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}')

if echo "$response" | grep -q "result"; then
  echo "RPC is healthy"
else
  echo "RPC is down"
fi

For production, consider using a monitoring service that tracks latency, error rates, and block height lag.

Key Takeaways

Sonic is an EVM Layer-1 with chain ID 146 and the S token.
The official RPC is https://rpc.soniclabs.com; OnFinality also provides a public endpoint at https://sonic.api.onfinality.io/public.
For production, evaluate managed or dedicated RPC providers to avoid rate limits and get archive data.
Dedicated Sonic nodes are ideal for high-throughput or data-heavy workloads.
Always monitor your RPC endpoint health to ensure reliability.

Frequently Asked Questions

What is the Sonic network RPC URL?

The official Sonic mainnet RPC URL is https://rpc.soniclabs.com. OnFinality also provides a public endpoint at https://sonic.api.onfinality.io/public.

What is the Sonic chain ID?

The Sonic mainnet chain ID is 146 (0x92).

Does Sonic support WebSocket?

Yes, Sonic supports WebSocket RPC. Public WSS endpoints are available, but for production, a dedicated WebSocket endpoint is recommended.

Can I use Sonic with MetaMask?

Yes, you can add Sonic as a custom network in MetaMask using the chain settings above.

Does OnFinality offer Sonic RPC?

Yes, OnFinality provides a public Sonic endpoint and dedicated Sonic nodes. See our Sonic network page for details.

What is the Sonic block explorer?

The official Sonic block explorer is https://sonicscan.org.

Is Sonic an EVM-compatible chain?

Yes, Sonic is fully EVM-compatible, so you can deploy Ethereum smart contracts without modification.

How do I get Sonic testnet tokens?

Sonic testnet is separate from mainnet. You can get testnet tokens from the Sonic faucet, which is available in the Sonic documentation.

For more information on RPC pricing and supported networks, visit our RPC pricing page and networks page.

Related resources

Originally published at OnFinality.

Polygon MATIC API: RPC, SDKs, and Endpoints

OnFinality — Mon, 24 Aug 2026 04:27:29 +0000

Quick Decision Guide: Which Polygon API Do You Need?

Before diving into endpoints and SDKs, it helps to map the Polygon API landscape. The term "Polygon MATIC API" can mean several different things, and picking the wrong one wastes engineering time.

If you need to...	Use this	Example
Read balances, send transactions, call contracts	JSON-RPC endpoint	`eth_getBalance`, `eth_sendRawTransaction`
Interact with the Polygon bridge (legacy)	Matic.js SDK	`posClient.erc20(...)`
Query historical balances, token holders, or complex analytics	Indexing API (e.g., Bitquery)	GraphQL query for balances
Move stablecoins or build payment flows	Payments API (e.g., Chaingateway)	REST call to send USDC

For most dApp developers, the raw JSON-RPC endpoint is the foundation. It gives you full control and works with any Ethereum tooling (ethers, viem, web3.js). If you need indexed data or payment-specific features, you'll add a specialized API on top.

If you're building a production app, you'll want a reliable RPC provider. OnFinality offers managed Polygon RPC endpoints with HTTP and WebSocket support, and you can compare pricing to see if a dedicated node fits your workload.

What Is the Polygon MATIC API?

Polygon (formerly Matic Network) is an Ethereum-compatible proof-of-stake chain. The "Polygon MATIC API" generally refers to the interfaces for interacting with this chain. The core is the JSON-RPC API, which is identical to Ethereum's, so any Ethereum library works out of the box.

Historically, MATIC was the native token used for gas. After the POL upgrade, POL is now the native token, but many docs and tools still reference MATIC. The API itself is unchanged—you're still sending transactions and querying state.

There are also higher-level APIs:

Matic.js: a legacy SDK for interacting with the Polygon bridge contracts. It's still in the docs but is being phased out.
Indexing APIs: services like Bitquery that provide GraphQL or REST endpoints for historical data, token balances, and analytics.
Payments APIs: services like Chaingateway that abstract away node management and provide webhooks for deposits.

Polygon Chain Settings at a Glance

When configuring your app, you need the correct chain ID and RPC URL. Here are the official settings for Polygon mainnet:

Parameter	Value
Chain ID	137
Native currency	POL (formerly MATIC)
Symbol	POL
Decimals	18
Block explorer	https://polygonscan.com
Public RPC URL	`https://polygon.api.onfinality.io/public`
WebSocket support	Yes (via OnFinality)

For testnet, the Polygon Amoy testnet uses chain ID 80002 and the public RPC URL https://polygon-amoy.api.onfinality.io/public. You can find more details on the Polygon network page.

How to Connect to Polygon with JSON-RPC

You can use any Ethereum-compatible library. Here's an example using ethers.js to read a balance and send a transaction:

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("https://polygon.api.onfinality.io/public");

async function getBalance(address) {
  const balance = await provider.getBalance(address);
  console.log(`Balance: ${ethers.formatEther(balance)} POL`);
}

async function sendTransaction(signer, to, amount) {
  const tx = await signer.sendTransaction({
    to,
    value: ethers.parseEther(amount),
  });
  await tx.wait();
  console.log(`Tx hash: ${tx.hash}`);
}

For raw JSON-RPC calls, you can use curl:

curl -X POST https://polygon.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

This returns the latest block number, confirming your endpoint is live.

Using Matic.js for Bridge Operations

Matic.js is the legacy SDK for interacting with the Polygon bridge. It's still documented, but Polygon Labs recommends newer alternatives for moving money. If you're maintaining existing code, here's a quick example:

const { POSClient, use } = require("@maticnetwork/maticjs");
const { Web3ClientPlugin } = require("@maticnetwork/maticjs-web3");
const HDWalletProvider = require("@truffle/hdwallet-provider");

use(Web3ClientPlugin);

const posClient = new POSClient();
await posClient.init({
  network: "mainnet",
  version: "v1",
  parent: {
    provider: new HDWalletProvider(privateKey, "https://ethereum-rpc.example.com"),
    defaultConfig: { from: userAddress },
  },
  child: {
    provider: new HDWalletProvider(privateKey, "https://polygon.api.onfinality.io/public"),
    defaultConfig: { from: userAddress },
  },
});

const erc20 = posClient.erc20("<token-address>");
const balance = await erc20.getBalance(userAddress);

Note that Matic.js is deprecated for new projects. For modern bridge interactions, consider using the official Polygon bridge UI or a payments API.

Indexing APIs for Balances and History

If you need to query historical balances or token holders, an indexing API like Bitquery can be more efficient than scanning blocks yourself. For example, to get the native POL balance of an address:

query {
  EVM(network: matic, dataset: combined) {
    Balances(
      where: {
        Balance: {
          Address: { is: "0x..." }
        }
      }
    ) {
      Currency { Symbol }
      Balance { Amount }
    }
  }
}

These APIs are useful for analytics dashboards, audit trails, and wallet apps. They typically require an API key and have usage limits.

Choosing Between Public, Managed, and Dedicated RPC

For production apps, the public endpoint is not reliable enough. You have three main options:

Option	Pros	Cons
Public RPC	Free, no signup	Rate limits, unreliable, no SLA
Managed RPC (e.g., OnFinality)	Reliable, scalable, WebSocket support, free tier	Requires API key, usage-based pricing
Dedicated node	Full control, no shared limits, archive data	Higher cost, requires maintenance

OnFinality provides managed Polygon RPC that handles infrastructure concerns like load balancing and failover. For high-throughput or archive needs, a dedicated node might be worth the cost.

Common Pitfalls and Troubleshooting

Chain ID mismatch: Ensure your wallet uses chain ID 137 for mainnet, not 80001 (old Mumbai testnet) or 80002 (Amoy).
Rate limiting: Public endpoints often throttle. If you see 429 errors, switch to a managed provider.
WebSocket disconnects: For real-time updates, use WebSocket but implement reconnection logic.
MATIC vs POL: Some tools still expect MATIC. Check your library's documentation for the correct symbol.

Key Takeaways

The Polygon MATIC API is primarily JSON-RPC, compatible with Ethereum tools.
Choose the right API layer: raw RPC for control, indexing APIs for analytics, payments APIs for stablecoin flows.
Use the correct chain ID (137) and a reliable RPC provider for production.
OnFinality offers managed Polygon RPC with HTTP and WebSocket support.

Frequently Asked Questions

What is the difference between MATIC and POL?

MATIC was the original native token. In 2024, Polygon upgraded to POL, which now serves as the gas token and staking token. The API and chain ID remain the same.

Can I use Ethereum libraries with Polygon?

Yes, Polygon is EVM-compatible, so ethers.js, viem, and web3.js work without modification. Just point them to a Polygon RPC endpoint.

Is the public Polygon RPC endpoint free?

Yes, the public endpoint https://polygon.api.onfinality.io/public is free to use, but it has rate limits. For production, consider a managed RPC plan.

How do I get testnet POL for Amoy?

You can use the Amoy faucet, which is linked from the Polygon network page.

What is Matic.js used for?

Matic.js is a legacy SDK for interacting with the Polygon bridge. It's deprecated for new projects, but existing code may still use it.

Does OnFinality support WebSocket for Polygon?

Yes, OnFinality's Polygon endpoint supports both HTTP and WebSocket. Check the network page for details.

How do I choose between a managed RPC and a dedicated node?

If you need high throughput, archive data, or custom configuration, a dedicated node may be better. For most apps, a managed RPC offers a good balance of cost and reliability. See our RPC provider selection guide for more.

What are the rate limits for the public endpoint?

Public endpoints are subject to rate limits to ensure fair usage. For higher limits, sign up for a free API key on OnFinality.

Can I use Polygon with viem?

Yes, viem supports Polygon out of the box. You can create a client with createPublicClient({ chain: polygon, transport: http("https://polygon.api.onfinality.io/public") }).

Where can I find the full list of supported networks?

Visit the supported networks page to see all chains OnFinality supports.

Related resources

Originally published at OnFinality.

Crust Network Staking: GPoS, Validators, and RPC Monitoring

OnFinality — Mon, 24 Aug 2026 04:26:57 +0000

Quick decision guide: what to check before staking CRU

Before you stake CRU, you need to decide whether you want to run a validator, become a guarantor, or simply delegate to an existing validator. Each role has different requirements and risk profiles. Use this checklist to evaluate your options:

Decision point	What to check	Why it matters
Role	Validator, guarantor, or nominator	Validators need storage resources and a node; guarantors only stake CRU to back a validator
Validator reputation	Historical rewards, commission, era points	Low commission and consistent block production indicate reliability
Staking limits	Minimum stake, upper limit per validator	Crust has a staking upper limit of 1000 CRU per validator; exceeding it may reduce rewards
Lock-up and unbonding	Unbonding period and conditions	You cannot withdraw immediately; plan your liquidity needs
RPC access	Reliable endpoint for monitoring and transactions	A stable RPC provider helps you track rewards and submit extrinsics without downtime

If you are building an application that needs to read staking data or submit staking transactions, you will need a reliable Crust RPC endpoint. OnFinality offers Crust RPC services that can support your staking workflow.

What is Crust Network staking?

Crust Network is a Substrate-based layer-1 blockchain that provides decentralized storage over IPFS. Its consensus mechanism, GPoS (Guaranteed Proof of Stake), is a proof-of-stake algorithm that defines staking power based on storage resources. In GPoS, validators and candidates are elected based on their effective stake, which is a combination of their own staked CRU and the CRU staked by guarantors. This design aligns economic incentives with the network's storage capacity.

Staking on Crust involves locking CRU tokens to support the network's security and, in return, earning rewards. There are two main roles:

Validators: Run nodes that produce blocks and validate transactions. They need to provide storage resources and stake CRU. Validators earn authoring rewards (for block production) and staking rewards.
Guarantors: Stake CRU to back a specific validator. They do not run nodes but share in the validator's staking rewards (minus commission). Guarantors are essential for increasing a validator's effective stake and helping them get elected.

How GPoS works: staking power tied to storage

GPoS is designed to bind staking quotas to storage resources. The network uses two layers:

MPoW (Meaningful Proof of Work): Storage nodes report their storage workload, which is verified using TEE (Trusted Execution Environment). This provides a verifiable measure of how much storage a node contributes.
GPoS: Based on the workload report, each node gets a staking quota. The quota determines how much CRU can be staked to that node and its influence in the consensus process.

In practice, this means that a validator's effective stake is not just the CRU they own but also the CRU that guarantors delegate to them. The more storage a node provides, the higher its staking quota, and the more CRU it can attract. This creates a market where validators compete for guarantors' CRU by offering competitive commissions and reliable performance.

Staking rewards and slashing: what to expect

Validators earn two types of rewards:

Authoring rewards: Earned by validators who produce blocks. The amount depends on the number of blocks produced and the validator's points.
Staking rewards: Earned by validators and candidates based on their effective stake. Guarantors receive a share of these rewards proportional to their stake, minus the validator's commission.

Rewards are distributed each era (approximately 6 hours on Crust mainnet). The total reward pool decreases over time according to the economic whitepaper.

Slashing is a risk in any PoS network. If a validator misbehaves (e.g., goes offline or acts maliciously), a portion of the staked CRU may be slashed. Guarantors should be aware that they share this risk with the validator they back. Always research a validator's track record before staking.

How to stake CRU: step-by-step

Staking on Crust can be done through the official Crust Apps UI or via the Substrate API. Here is a general workflow:

Get CRU tokens: You need CRU to stake. You can obtain it from exchanges or through other means.
Choose a validator: Evaluate validators based on commission, era points, and total stake. You can use the Crust Apps UI to browse validators.
Bond your CRU: Use the staking pallet to bond your CRU. This locks your tokens for staking.
Nominate or guarantee: If you are a guarantor, you need to select a validator to back. This is done by nominating a validator (in Substrate terms) or using the guarantee mechanism.
Monitor your rewards: Check your rewards regularly and adjust your strategy if needed.

For developers who want to automate staking operations, you can use the Substrate RPC API. Here is an example of how to query staking information using a Crust RPC endpoint:

curl -H "Content-Type: application/json" -d '{"id":1,"jsonrpc":"2.0","method":"state_getStorage","params":["0x..."]}' https://crust-rpc.onfinality.io

Replace the storage key with the appropriate key for the staking module. You can find the storage keys in the Crust chain metadata.

Monitoring your stake with RPC

To keep track of your staking rewards and validator performance, you can query the chain via RPC. Common RPC methods include:

state_getStorage to read staking storage items
chain_getBlock to inspect recent blocks
system_health to check node health

For example, to get the current era and staking info, you might use:

curl -H "Content-Type: application/json" -d '{"id":1,"jsonrpc":"2.0","method":"state_getStorage","params":["0x..."]}' https://crust-rpc.onfinality.io

Using a reliable RPC provider like OnFinality ensures that your monitoring scripts have consistent access to the network. OnFinality provides Crust RPC endpoints that you can use for both mainnet and testnet.

Common pitfalls and troubleshooting

Staking upper limit: Each validator has a staking upper limit (1000 CRU). If a validator reaches this limit, additional stake may not earn rewards. Check the validator's current stake before bonding.
Unbonding period: When you unbond your CRU, there is a waiting period before you can withdraw. Plan accordingly.
RPC endpoint reliability: Public RPC endpoints can be rate-limited or unavailable. For production applications, consider using a dedicated RPC service to avoid interruptions.
Validator offline: If your validator goes offline, you may miss rewards. Monitor your validator's era points and consider switching if performance drops.

Key Takeaways

Crust Network uses GPoS, a proof-of-stake mechanism that ties staking power to storage resources.
Staking involves validators and guarantors; guarantors stake CRU to back validators and share rewards.
Before staking, evaluate validator reputation, commission, and staking limits.
Use a reliable RPC provider to monitor your stake and submit transactions.
OnFinality offers Crust RPC services that can support your staking workflow.

Frequently Asked Questions

What is the minimum amount to stake on Crust?

The minimum stake can vary. Check the Crust Wiki or the staking UI for current requirements. Typically, you need enough CRU to cover the existential deposit and any minimum stake thresholds.

Can I stake CRU from an exchange?

Most exchanges do not support Crust staking directly. You will need to withdraw CRU to a wallet that supports staking, such as the Crust Wallet or a Substrate-based wallet.

What is the unbonding period on Crust?

The unbonding period is typically 7 days on Crust mainnet, but it can change. Check the network parameters for the exact duration.

How do I choose a good validator?

Look for validators with low commission, high era points, and a good track record. You can also check their total stake and whether they are close to the staking upper limit.

Can I use OnFinality's RPC for Crust staking?

Yes, OnFinality provides Crust RPC endpoints that you can use to interact with the Crust network, including staking operations. For production use, consider a dedicated node for higher reliability.

For more information about RPC providers and how to choose one, see our guide on choosing an RPC provider. You can also explore all supported networks and RPC pricing.

Related resources

Originally published at OnFinality.

Acala RPC Endpoints: Chain Settings, EVM+ & Dedicated Nodes

OnFinality — Mon, 24 Aug 2026 04:26:24 +0000

Quick Decision Guide: Which Acala RPC Setup Should You Use?

Before diving into endpoint lists, decide what your workload actually needs. The right Acala RPC setup depends on your stage and traffic pattern:

Prototyping or light testing: Use the public Acala RPC endpoint for quick checks, script debugging, and initial integration tests. It is fine for low-volume requests and does not require an API key.
Production dApp or backend service: Move to an authenticated endpoint. You get clearer rate limits, analytics, and operational visibility, which helps you plan capacity and avoid surprise throttling.
High-throughput, archive, or custom node needs: Consider a dedicated Acala node. This gives you isolated resources, the ability to run archive nodes, and control over node configuration—important for collators, indexers, or applications that need consistent performance.

If you are unsure, start with the public endpoint, measure your request volume, and then upgrade to authenticated or dedicated infrastructure as your traffic grows. For a deeper comparison of RPC providers, see our guide on choosing an RPC provider.

Acala at a Glance: Substrate and EVM+ in One Network

Acala is a Polkadot parachain built for DeFi. It provides a full Substrate runtime with pallets for stablecoins, liquid staking, and DEX functionality. On top of that, Acala offers an EVM+ environment, which is compatible with Ethereum tooling while still allowing access to Substrate-specific features.

This dual nature means that when you search for "Acala RPC", you are likely looking for one of two things:

Substrate RPC endpoints for querying chain state, submitting transactions, or interacting with Acala's custom pallets.
EVM RPC endpoints for deploying and interacting with Solidity smart contracts using tools like MetaMask, ethers.js, or viem.

Both are important, and the endpoint you choose depends on the type of application you are building.

Acala Chain Settings at a Glance

If you are connecting a wallet or an EVM-based tool, you need the correct chain configuration. Here are the key settings for Acala Mainnet:

Setting	Value
Network Name	Acala
Chain ID	787 (0x313)
Currency Symbol	ACA
Block Explorer	https://blockscout.acala.network
RPC URL (HTTPS)	https://eth-rpc-acala.aca-api.network
RPC URL (WSS)	wss://eth-rpc-acala.aca-api.network

These settings are commonly listed on chain registries like ChainList. Always verify the chain ID and RPC URL with the official Acala documentation before connecting your wallet.

Acala RPC Endpoint Options

Acala offers several public RPC endpoints, each with different characteristics. Here is a summary of what you will commonly find:

Provider	Endpoint (HTTPS)	Endpoint (WSS)	Notes
Acala Foundation	https://acala-rpc.aca-api.network	wss://acala-rpc.aca-api.network	Official endpoint, may have rate limits
Dwellir	https://acala-rpc.n.dwellir.com	wss://acala-rpc.n.dwellir.com	Independent provider
LuckyFriday	https://rpc-acala.luckyfriday.io	wss://rpc-acala.luckyfriday.io	Community provider
OnFinality	https://acala-polkadot.api.onfinality.io/public	wss://acala-polkadot.api.onfinality.io/public-ws	Public endpoint for testing; authenticated access for production

Note: Public endpoints are shared and can be rate-limited or experience downtime. For production applications, you should use an authenticated endpoint or a dedicated node.

Connecting to Acala EVM+ with MetaMask

If you are building a dApp that uses the EVM+ side of Acala, you can add Acala as a custom network in MetaMask. Here is a sample configuration:

{
  "chainId": "0x313",
  "chainName": "Acala",
  "nativeCurrency": {
    "name": "Acala",
    "symbol": "ACA",
    "decimals": 18
  },
  "rpcUrls": ["https://eth-rpc-acala.aca-api.network"],
  "blockExplorerUrls": ["https://blockscout.acala.network"]
}

You can also use the window.ethereum.request method to programmatically add the network:

await window.ethereum.request({
  method: 'wallet_addEthereumChain',
  params: [{
    chainId: '0x313',
    chainName: 'Acala',
    nativeCurrency: {
      name: 'Acala',
      symbol: 'ACA',
      decimals: 18
    },
    rpcUrls: ['https://eth-rpc-acala.aca-api.network'],
    blockExplorerUrls: ['https://blockscout.acala.network']
  }]
});

Using Acala RPC with ethers.js or viem

For EVM+ development, you can use standard Ethereum libraries. Here is an example using ethers.js:

import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://eth-rpc-acala.aca-api.network');

const blockNumber = await provider.getBlockNumber();
console.log('Acala block number:', blockNumber);

And with viem:

import { createPublicClient, http } from 'viem';

const client = createPublicClient({
  chain: {
    id: 787,
    name: 'Acala',
    network: 'acala',
    nativeCurrency: { name: 'Acala', symbol: 'ACA', decimals: 18 },
    rpcUrls: {
      default: { http: ['https://eth-rpc-acala.aca-api.network'] },
    },
  },
  transport: http(),
});

const blockNumber = await client.getBlockNumber();
console.log('Acala block number:', blockNumber);

Substrate RPC: Querying Chain State

For Substrate-specific operations, you can use the JSON-RPC interface directly. Here is a curl example to get the latest finalized head:

curl -H "Content-Type: application/json" \
  -d '{"id":1,"jsonrpc":"2.0","method":"chain_getFinalizedHead","params":[]}' \
  https://acala-polkadot.api.onfinality.io/public

You can also subscribe to new blocks using WebSocket:

const WebSocket = require('ws');
const ws = new WebSocket('wss://acala-polkadot.api.onfinality.io/public-ws');

ws.on('open', () => {
  ws.send(JSON.stringify({
    id: 1,
    jsonrpc: '2.0',
    method: 'chain_subscribeNewHeads',
    params: []
  }));
});

ws.on('message', (data) => {
  console.log('New head:', data.toString());
});

Acala RPC Methods and Limits

Acala RPC endpoints support standard Substrate and Ethereum JSON-RPC methods. Common methods include:

chain_getBlock
chain_getFinalizedHead
state_getStorage
eth_blockNumber
eth_getBalance
eth_call

Public endpoints often have rate limits to protect the infrastructure. If you need higher throughput or more consistent performance, consider an authenticated endpoint or a dedicated node. OnFinality's RPC pricing page provides details on plans and limits.

Troubleshooting Common Acala RPC Issues

Here are some common issues you might encounter when using Acala RPC:

Connection timeouts: Public endpoints can be slow or overloaded. Try a different endpoint or use a WebSocket connection for real-time data.
Rate limiting: If you receive HTTP 429 responses, you are hitting rate limits. Reduce request frequency or upgrade to an authenticated endpoint.
Wrong chain ID: Ensure your wallet or dApp is configured with chain ID 787. Using the wrong chain ID can cause transaction failures.
EVM vs Substrate confusion: If you are trying to call an EVM method on a Substrate endpoint, it will fail. Use the appropriate endpoint for your use case.

When to Consider a Dedicated Acala Node

A dedicated Acala node gives you full control over the node environment. This is useful for:

High-traffic applications that need consistent performance and clear rate limits.
Archive nodes that need to query historical state.
Collators who need to run a node for block production.
Custom node configurations that require specific flags or patches.

OnFinality offers dedicated Acala nodes with managed operations, monitoring, and isolated resources. You can also explore our supported networks to see other chains we support.

Key Takeaways

Acala is a Polkadot parachain with both Substrate and EVM+ interfaces.
Use the public RPC endpoint for testing, but switch to authenticated or dedicated infrastructure for production.
Configure your wallet with the correct chain ID (787) and RPC URL.
Use standard Ethereum libraries like ethers.js or viem for EVM+ development.
For Substrate-specific queries, use the JSON-RPC interface directly.
Monitor your usage and plan for scaling to avoid rate limits and downtime.

Frequently Asked Questions

What is the Acala RPC endpoint?

Acala provides several public RPC endpoints, including https://acala-rpc.aca-api.network and https://acala-polkadot.api.onfinality.io/public. For production, use an authenticated endpoint or a dedicated node.

What is the Acala chain ID?

The Acala chain ID is 787 (0x313).

Can I use MetaMask with Acala?

Yes, you can add Acala as a custom network in MetaMask using the chain ID 787 and the EVM RPC URL.

What is the difference between Substrate and EVM RPC on Acala?

Substrate RPC is used for chain state and transactions, while EVM RPC is used for smart contract interactions. Use the appropriate endpoint for your use case.

How do I get a dedicated Acala node?

You can get a dedicated Acala node through OnFinality's dedicated node service.

Related resources

Originally published at OnFinality.

SORA Network Blockchain: RPC Setup and Best Practices

OnFinality — Thu, 20 Aug 2026 03:04:05 +0000

Quick Recommendation: How to Decide on SORA Infrastructure

Before you write a line of code, decide how you will access the SORA Network. The choice depends on your workload, not on the network itself.

For prototyping or a hackathon: Use a public endpoint. It is fine for a few requests, but do not build a product on it.
For a production dApp or backend service: Use a managed RPC provider or run your own node. Managed services handle uptime, scaling, and maintenance, so you can focus on your application.
For real-time features like order books or price feeds: You need WebSocket (WSS) support. Confirm your provider offers it.
For historical data or analytics: You may need archive node access. Check that your provider supports archive queries.
For high traffic or strict latency requirements: Consider a dedicated node to avoid noisy neighbors and rate limits.

If you are unsure, start with a managed RPC provider that offers a free tier, test your workload, and upgrade as you grow.

What Is the SORA Network Blockchain?

SORA is a Substrate-based blockchain network designed to create a decentralized autonomous economy (DAE). It uses the XOR token and a token bonding curve to manage an elastic money supply that responds to economic demand. The network powers Polkaswap, a decentralized exchange, and supports democratic governance through the SORA Parliament.

SORA is built on Substrate, the same framework that powers Polkadot, which gives it enterprise-grade security and the flexibility to evolve. It is not an EVM chain, so developers interact with it using Substrate's JSON-RPC interface rather than Ethereum-style JSON-RPC.

Why RPC Endpoints Matter for SORA Developers

To build on SORA, your application needs to read chain state, submit transactions, and listen for events. RPC endpoints provide that interface. The quality of your RPC infrastructure directly affects:

Reliability: A public endpoint can go down or rate-limit you, breaking your app.
Latency: For real-time features, a slow endpoint makes your UI feel sluggish.
Data completeness: Archive nodes are required for historical queries.
Security: A malicious endpoint could return incorrect data or censor your transactions.

How to Connect to SORA: Endpoints and Setup

To connect to SORA, you need an RPC endpoint. OnFinality provides a public endpoint for SORA, which you can find on the SORA network page. For production, consider using a managed RPC provider like OnFinality, which offers dedicated nodes and shared RPC services.

Here is a basic example of connecting to SORA using the Polkadot.js API in JavaScript:

const { ApiPromise, WsProvider } = require('@polkadot/api');

async function main() {
  const wsProvider = new WsProvider('wss://sora.api.onfinality.io/public-ws');
  const api = await ApiPromise.create({ provider: wsProvider });

  // Get the chain name
  const chain = await api.rpc.system.chain();
  console.log('Connected to:', chain.toString());

  // Get the latest block number
  const lastHeader = await api.rpc.chain.getHeader();
  console.log('Latest block:', lastHeader.number.toNumber());

  await api.disconnect();
}

main().catch(console.error);

Note: The endpoint above is a placeholder. Always check the SORA network page for the current public endpoint URL.

Evaluating RPC Providers for SORA

When choosing an RPC provider for SORA, consider the following criteria:

Criterion	What to Check	Why It Matters
Uptime	Historical uptime and SLA	Downtime breaks your app and loses users
Latency	Response time from your region	Slow responses hurt user experience
Rate limits	Requests per second and daily limits	Limits can throttle your app under load
WebSocket support	WSS availability for subscriptions	Needed for real-time features
Archive data	Access to historical state	Required for analytics and some queries
Dedicated nodes	Option for exclusive infrastructure	Avoids noisy neighbors and rate limits
Pricing	Transparent, predictable costs	Helps you budget and scale

OnFinality offers a managed RPC service for SORA with shared and dedicated options. You can compare plans on the RPC pricing page.

Common Pitfalls When Using SORA RPC

Using public endpoints in production: Public endpoints are often rate-limited and can go down. They are fine for testing but not for production.
Ignoring WebSocket support: If your app needs real-time updates, you must use WSS. Not all providers offer it.
Not checking archive support: If you need historical data, ensure your provider has archive nodes.
Assuming EVM compatibility: SORA is Substrate-based, so Ethereum tools like ethers.js won't work directly. Use Polkadot.js or Substrate-compatible libraries.
Overlooking rate limits: Even managed providers have limits. Understand your usage and choose a plan that fits.

Troubleshooting SORA RPC Issues

If you encounter issues, follow this debug path:

Check the endpoint URL: Ensure you are using the correct URL from the SORA network page.
Test with a simple request: Use curl to verify connectivity.

curl -H "Content-Type: application/json" -d '{"id":1,"jsonrpc":"2.0","method":"system_chain","params":[]}' https://sora.api.onfinality.io/public

Check rate limits: If you get 429 responses, you are hitting limits. Consider upgrading your plan.
Verify WebSocket connectivity: Use a tool like wscat to test WSS.
Review your code: Ensure you are using the correct library and method names for Substrate.

Key Takeaways

SORA is a Substrate-based blockchain for a decentralized autonomous economy, using XOR and a token bonding curve.
RPC endpoints are critical for building reliable applications on SORA.
Choose infrastructure based on your workload: public for testing, managed for production, dedicated for high traffic.
Evaluate providers on uptime, latency, rate limits, WebSocket support, archive data, and pricing.
Avoid common pitfalls like using public endpoints in production and ignoring WebSocket support.

Frequently Asked Questions

What is the SORA network?
SORA is a Substrate-based blockchain network designed as a decentralized autonomous economy, using the XOR token and a token bonding curve.

Is SORA an EVM chain?
No, SORA is Substrate-based, so it uses Substrate's JSON-RPC, not Ethereum's.

How do I get a SORA RPC endpoint?
You can use OnFinality's public endpoint or sign up for a managed RPC service. See the SORA network page for details.

Can I use ethers.js with SORA?
No, ethers.js is for EVM chains. Use Polkadot.js or other Substrate-compatible libraries.

What is the XOR token?
XOR is the native token of the SORA network, used for governance, fees, and as a medium of exchange.

Does OnFinality support SORA?
Yes, OnFinality provides RPC services for SORA. Check the supported networks page for more information.

Related resources

Originally published at OnFinality.