Summary
An Abstract RPC provider gives your dApp a JSON-RPC endpoint to the Abstract Layer 2 network, which is a zero-knowledge rollup built on the ZK Stack. Providers handle node operation, load balancing, and API access so you can focus on building. This article explains what to look for in an Abstract RPC provider, how to compare options, and how to connect your app.
Quick recommendation: what to check before picking an Abstract RPC provider
If you are evaluating an Abstract RPC provider, the first thing to decide is whether you need a shared public endpoint or a dedicated node. Public endpoints are fine for prototyping and light usage, but production apps usually need a provider that offers:
- Reliable uptime with load balancing across multiple nodes.
- Support for Ethereum JSON-RPC plus zkSync-specific methods like
eth_sendRawTransactionwith paymaster params. - WebSocket support for real-time subscriptions.
- Archive data if you need historical state or want to run indexers.
- Clear rate limits and pricing that match your traffic.
Start by testing the provider's endpoint with your actual workload. Use the network page at Abstract network to get an endpoint and run a few calls. Then compare providers on the criteria below.
What is Abstract and why does it need a special RPC provider?
Abstract is a zero-knowledge rollup Layer 2 built on zkSync's ZK Stack, designed for consumer crypto applications. It inherits Ethereum's security while offering lower fees and faster transactions. It also features native account abstraction through the Abstract Global Wallet (AGW), letting users interact with apps using email or social logins.
Because Abstract is an EVM-compatible rollup, it exposes the standard Ethereum JSON-RPC interface, but it also adds zkSync-specific methods for things like paymasters and transaction batching. A good Abstract RPC provider must support both sets of methods.
How to evaluate an Abstract RPC provider
When comparing providers, focus on the following criteria:
| Criterion | What to check | Why it matters |
|---|---|---|
| Network coverage | Mainnet and testnet (Sepolia) support | You need both for development and production |
| API compatibility | Full Ethereum JSON-RPC + zkSync methods | Missing methods break your dApp |
| Performance | Latency, throughput, and rate limits | Slow or throttled endpoints degrade user experience |
| Reliability | Uptime history, redundancy, failover | Downtime means lost transactions and users |
| Data availability | Archive data, trace support | Needed for indexers, analytics, and debugging |
| WebSocket support | WSS endpoints for subscriptions | Essential for real-time features |
| Pricing model | Pay-as-you-go vs. subscription | Must match your budget and traffic |
| Support | Documentation, community, SLAs | Helps you resolve issues quickly |
Abstract network details at a glance
Here are the key network parameters you'll need to configure your wallet or dApp:
| Parameter | Mainnet | Testnet |
|---|---|---|
| Network name | Abstract Mainnet | Abstract Testnet |
| Chain ID | 2741 | 11124 |
| Currency symbol | ETH | ETH |
| Block explorer | Abscan | Testnet explorer |
How to connect to Abstract RPC
You can connect to Abstract using any Ethereum-compatible library. Here's an example using ethers.js:
import { ethers } from "ethers";
const provider = new ethers.JsonRpcProvider("https://rpc.example.com/abstract");
async function getBlockNumber() {
const blockNumber = await provider.getBlockNumber();
console.log("Current block:", blockNumber);
}
getBlockNumber();
For a WebSocket subscription, use:
const wsProvider = new ethers.WebSocketProvider("wss://rpc.example.com/abstract");
wsProvider.on("block", (blockNumber) => {
console.log("New block:", blockNumber);
});
What methods does an Abstract RPC provider need to support?
Beyond standard Ethereum methods, you should verify support for zkSync-specific methods:
eth_sendRawTransactionwith paymaster parameterszks_getConfirmedTokenszks_getBridgeContractszks_estimateFee
Check the provider's documentation to confirm they support these.
Common pitfalls when using an Abstract RPC provider
- Using the wrong chain ID – Double-check that you're using 2741 for mainnet and 11124 for testnet.
- Ignoring rate limits – Public endpoints often have strict limits; use a provider with higher limits for production.
- Not handling WebSocket reconnections – Implement reconnection logic to avoid missed events.
- Assuming archive data is included – Archive access is often a paid add-on.
How to test an Abstract RPC provider
Before committing, run a simple load test to see how the provider handles concurrent requests. You can use a tool like hey or a custom script. Here's a basic curl example:
curl https://rpc.example.com/abstract \
-X POST \
-H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
Monitor response times and error rates. Also test WebSocket connections for stability.
When to consider a dedicated Abstract node
If your application has high traffic, requires low latency, or needs custom configuration, a dedicated node might be better. Dedicated nodes offer:
- Isolated resources – No noisy neighbors.
- Custom settings – You can tune the node for your use case.
- Higher rate limits – No shared throttling.
OnFinality offers dedicated node options for teams that need this level of control.
How to choose between free and paid Abstract RPC providers
Free endpoints are great for development, but they often have rate limits and no uptime guarantees. For production, consider a paid provider that offers:
- Service level agreements – reliability expectations (but verify the terms).
- Priority support – Faster resolution of issues.
- Scalable pricing – Pay for what you use.
Check RPC pricing to see how OnFinality structures its plans.
Key Takeaways
- Abstract is an EVM-compatible ZK rollup, so your RPC provider must support both Ethereum and zkSync methods.
- Evaluate providers on network coverage, API compatibility, performance, reliability, data availability, and pricing.
- Use the correct chain IDs: 2741 for mainnet, 11124 for testnet.
- Test your provider with real workloads before going to production.
- Consider a dedicated node if you need higher throughput or custom configuration.
Frequently Asked Questions
What is an Abstract RPC provider?
An Abstract RPC provider is a service that offers JSON-RPC endpoints to interact with the Abstract blockchain. It handles node infrastructure, so you don't have to run your own node.
How do I get an Abstract RPC endpoint?
You can get a free endpoint from public providers or sign up for a paid service. OnFinality provides endpoints for Abstract on its network page.
What is the Abstract chain ID?
The Abstract mainnet chain ID is 2741, and the testnet chain ID is 11124.
Does Abstract support WebSocket?
Yes, most providers offer WSS endpoints for real-time subscriptions.
Can I use Ethereum libraries with Abstract?
Yes, because Abstract is EVM-compatible, you can use ethers.js, viem, web3.js, and other Ethereum tools.
What are zkSync-specific RPC methods?
Methods like zks_estimateFee and zks_getBridgeContracts that are unique to zkSync-based rollups.
How do I choose between a shared and dedicated Abstract RPC?
Shared endpoints are cost-effective for low to medium traffic. Dedicated nodes are better for high traffic, low latency, or custom needs.
Does OnFinality support Abstract?
Yes, OnFinality provides Abstract RPC endpoints. Check the supported networks page for details.