This section covers creating shared node endpoints, generating access tokens, and configuring dedicated nodes with customizable settings.

With our tools and services, you can focus on building your dApp without worrying about the technical details of setting up and managing blockchain nodes.

From DeFi apps and NFT platforms to analytics tools, AppChains, and more, GetBlock provides the infrastructure to help you build, test, and scale your blockchain-powered solutions.

Core GetBlock Services

Discover GetBlock

Popular chains

Get started with our most in-demand blockchain networks.

Start here to choose a plan, understand usage limits, and manage billing.

Nonstandard Client Support runs the namespaces, client builds, and configurations that a default node does not enable — extra RPC namespaces, a patched or forked client, or an exotic set of flags. GetBlock operates the setup for you on managed infrastructure, so you get the capability without taking on the operations.

A default node exposes a standard set of RPC namespaces on a standard client build, tuned for the common case. That covers most workloads, but some workloads need what the default deliberately leaves off: the debug, trace, txpool, or admin namespaces; a specific client version or a private fork; or custom flags such as an archive sync mode or a particular tracer configuration.

Enabling these yourself means running the node, and running a nonstandard node means owning its upgrades, its monitoring, and its incidents. This add-on takes that on. You describe what you need; GetBlock deploys and operates it.

For example, a default node does not expose the pending transaction pool and does not run a custom tracer. With this add-on, GetBlock enables the txpool namespace and deploys your tracer, so you can read the pending pool and trace transactions with your own logic — on infrastructure you do not have to manage.

Benefits

• Access to hidden data: Reach namespaces and traces that a default node does not expose.

• Your client build: Run a specific version, a private fork, or a patched client.

• Managed operation: GetBlock runs the exotic setup, so your engineers do not manage the machine.

When to use it

• You run MEV or search workloads that need txpool access and custom tracers.

• Your security or forensics work needs debug_traceTransaction with a custom tracer.

• You need a patched client, a private fork, or a niche chain client that no shared node runs.

Limitations

• This add-on costs more than the others because it is bespoke operations rather than a configuration toggle.

• A nonstandard build needs lead time to prepare and deploy.

Traditionally, when you send a transaction, your node validates it and places it in the mempool. The mempool is a public holding area for transactions that are not yet confirmed. The node then broadcasts the transaction to its peers, so the pending transaction is visible across the network while it waits.

MEV Protection routes your transactions through a private mempool so that MEV bots never see them. This stops front-running and sandwich attacks before they can happen. You enable it at the endpoint level, and your application code does not change.

Block builders — the validators and searchers who assemble the next block — read the mempool and choose which transactions to include and in what order. That power to order, insert, and exclude transactions is where the risk begins.

What MEV is

MEV — Maximal Extractable Value — is the value that a block builder can extract purely by controlling transaction order. Most of this value is not found by the builders themselves. It is found by searchers: third parties who run bots that watch the public mempool and calculate which ordering earns them a profit. The profit usually comes at the expense of an ordinary user whose pending transaction sits in the open.

How the attacks work

1. Front-running: A searcher sees your large trade waiting in the mempool. It submits its own buy with a higher fee, so the builder places it ahead of yours. The searcher buys at the lower price, your trade then pushes the price up, and the searcher profits.

2. Sandwiching: The searcher places one transaction before yours and one after. The first rides the price up ahead of you; the second sells into the price move your trade caused. Your trade is the filling in the sandwich, and you get the worst price.

3. Back-running: The searcher positions its transaction right after yours to capture a price gap your trade opened, for example between two exchanges.

The common thread is visibility. Every one of these attacks depends on the searcher seeing your transaction while it waits in the public mempool.

How MEV Protection works

MEV Protection removes your transaction from that public view. Instead of the public mempool, GetBlock routes it through a private mempool in partnership with Merkle, which acts as a trusted private builder. The transaction travels straight to the builder without being broadcast, so a searcher never sees it and has nothing to attack.

The protection lives at the RPC endpoint layer. You select the MEV-protected endpoint and send transactions exactly as you do today. There is no in-app defense to build and no change to your transaction code.

Benefits

• No in-app defenses to build: The protection sits in the endpoint, which lowers your cost and complexity.

• Protection against front-running and sandwiching: A bot cannot attack a transaction it cannot see.

• The same integration: You keep your existing code and only change the endpoint URL.

• Better outcomes for users: Your users keep the value that a searcher would otherwise take from their trades.

When to use it

Not every transaction needs protection. A plain transfer of ETH, an NFT, or a token exposes no arbitrage, so a bot has no reason to touch it. Protection matters when a transaction moves value in a way a searcher can exploit: a token swap on a DEX, an NFT mint, an auction, or activity in a lending protocol. If your users trade, protect their transactions.

Custom Endpoint URL lets you serve your dedicated node from a domain you own instead of the autogenerated address. Rather than a URL that carries a random access token, you present a clean, branded address such as rpc.yourapp.com, while the node behind it stays exactly the same.

How it works

By default, your endpoint carries a random access token in the path, e.g a typical path from GetBlock shared.eu-central-1.getblock.io/<ACCESS-TOKEN>/. That works, but it ties your public configuration to a provider hash, and it places a secret inside a URL, where it tends to end up in server logs, browser history, and proxy records.

This add-on changes the address in two ways:

1. You input the domain you own at your GetBlock node with a Canonical name (CNAME) record, or choose a readable subdomain in place of the hash.

2. You keep your authentication in a header, such as x-access-token, instead of in the URL, so the secret no longer travels as part of the address.

The node, the performance, and the behavior are unchanged. Only the address your application points at is different.

Benefits

• Your brand on your URLs. A white-label product serves endpoints that carry your name, not a provider hash.

• A private stack. Your public configuration does not reveal which infrastructure provider you use.

• A stable address. The URL survives token rotation, because the token lives in a header rather than in the path.

• A safer secret. Keeping the token out of the URL keeps it out of logs and browser history.

When to use it

• You build a white-label product, and your URLs must carry your brand.

• You prefer that your public configuration not name your provider.

• You want a readable, stable URL that does not change when you rotate keys.

Limitations

• If the endpoint is internal and no user ever sees it, the default URL is already enough.

• Setup requires a domain you own and a DNS change on your side.

A Dedicated Ingress Proxy gives you your own routing layer in front of your node — a proxy fleet that serves only your traffic. It isolates the one part of the path that a standard dedicated node still shares with everyone else: the gateway.

The layer most people forget

A dedicated node isolates the compute that runs the chain, but a request does not reach that compute directly. It first passes through an ingress proxy that terminates TLS, checks authentication, applies rate limits, and routes the request onward. On a standard setup, that proxy layer is shared across many customers. Your node is private, but the front door is not.

Most of the time this is fine. It matters when the shared front door becomes the constraint — when another customer's traffic surge slows the gateway, or when your own throughput and policy needs outgrow a shared default.

What it does

The add-on gives you a proxy fleet that no other customer uses. Because your traffic is the only traffic on it, no other customer's load can compete with yours at the gateway, and the time the proxy adds stays predictable. It also becomes yours to configure: you can apply rate-limit and routing rules that fit your workload rather than a shared default, and your traffic stays isolated from the edge all the way to the node.

Benefits

• No noisy neighbor at the gateway: Another customer's load cannot affect your routing layer.

• Predictable gateway latency: With only your traffic on the proxy, the added latency stays stable.

• Custom policy: Set rate-limit and routing behavior that a shared policy cannot offer.

• End-to-end isolation: Traffic is isolated from the edge to the node, which supports strict compliance requirements.

When to use it

• Your application runs at high request rates, and the shared gateway has become the limit.

• Your compliance rules require an isolated traffic path, not just an isolated node.

• You need custom rate-limit or routing behavior at the gateway.

Limitations

• If your traffic is moderate and the shared gateway keeps up, you do not need a dedicated proxy.

• The add-on isolates the routing layer. It does not change the node's own compute capacity.

The Beacon API opens access to the Ethereum consensus layer — the Proof-of-Stake side of the network. This is a different layer from the one the standard eth_* JSON-RPC serves, and it exposes data that the execution layer simply does not hold.

Since the Merge, an Ethereum node runs as two coupled clients. The execution layer processes transactions and smart-contract state; you read it through the familiar eth_* methods. The consensus layer runs Proof-of-Stake: it manages validators, organizes time into slots and epochs, and decides finality. Each layer answers a different kind of question, and each has its own API.

A standard node gives you the execution layer. The Beacon API add-on gives you the consensus layer alongside it, so a single dedicated node answers both.

What it exposes

The Beacon API returns data that the eth_* API does not:

• Chain timing and finality — slots, epochs, and finalization status.

• Validators — balances, statuses, entry and exit queues, and effectiveness.

• Consensus duties — attestations, sync committees, and block proposals.

• Staking data — the information that validator monitoring and staking dashboards depend on.

For example, when you query a validator by its index, the response returns the validator's status, its balance, and its position in any activation or exit queue. There is no execution-layer method that can answer this, because the execution layer has no concept of a validator.

Benefits

• A complete view of the chain: You read both the execution and consensus layers from one dedicated node.

• Direct staking data: You track finalization, validator effectiveness, and queue position without a separate service in the path.

• Live monitoring: You watch validator status and attestation performance as it changes.

When to use it

• You run a staking provider and monitor validator health.

• You build a validator dashboard or a Proof-of-Stake analytics tool.

• You need finalization status or sync-committee data for your product.

Overlay methods let you replay chain history as if a contract had run different code. You change a contract's bytecode — or its balance, nonce, or storage — and re-run past blocks to see the logs and events it would have produced. Nothing is deployed on-chain, and no real transaction is sent.

A contract only emits the events its code was written to emit. If a contract shipped without an event you now need — a missing Transfer log, an unindexed state change — that data does not exist on-chain, and no normal query can recover it. Re-deploying a fixed contract does not help either, because it cannot rewrite the past.

Overlay methods approach this from the other direction. They take the real historical state and replay it through your version of the contract. The chain's inputs stay real; only the contract logic changes. The result is the data the original contract would have emitted if it had carried your code.

This mirrors how state-override works in eth_call, extended across a range of historical blocks rather than a single call.

What you can do

• Trace a block range (debug/trace block-by-range). Process history in bulk instead of sending one request per block.

• overlay_getLogs. Replay a block range with modified bytecode and pull logs that never existed on the real chain.

• overlay_callConstructor. See how a contract would have initialized under different deployment logic.

Benefits

• Reconstruct missing events: Recover data the original contract never logged.

• Bulk history processing: Block-range tracing removes the per-block request overhead of a normal node.

• Safe experimentation: Test modified logic against real history with no deployment and no risk to on-chain state.

When to use it

• You run on-chain analytics and need events a contract never emitted.

• You reverse-engineer contract behavior.

• You reconstruct historical data for indexing or audit.

Automatic RPC Failover keeps your application online when your dedicated node degrades. If the node falls behind or starts to fail, the system moves your traffic to GetBlock shared RPC and moves it back once the node recovers. The switch is automatic, and your endpoint URL never changes.

A dedicated node gives you isolated, predictable performance, but it is still a single resource. It needs client upgrades, it can fall behind the chain head during a heavy sync, and a traffic spike can push it past its capacity. Without a fallback, any of these moments becomes downtime for your users. Failover removes that single point of failure.

How it works

The system checks the health of your node on a set interval. It treats the node as degraded when any of these conditions appears:

• the node lags the chain head by more than a set number of blocks;

• its error rate crosses a set threshold;

• its response latency crosses a set limit.

When the node is healthy, all your traffic goes to it, and you get the full benefit of dedicated performance. When the node degrades, the system reroutes your requests to the shared pool, so no request is dropped while the node is unavailable. When the node returns to a healthy state, the system routes traffic back to it.

Because the endpoint URL stays the same throughout, your application does not know the switch happened. You do not reconfigure a client or restart a service.

Benefits

• Continuous availability: A degraded node no longer takes your application down with it.

• Safe maintenance: Your node can take client upgrades and maintenance windows without a visible service gap.

• Spike absorption: Traffic beyond your dedicated capacity fails over instead of failing outright.

• No code change: The URL is unchanged, so your integration is unchanged.

When to use it

• You run a production application that cannot drop requests.

• Your node needs regular maintenance or client upgrades.

• Your traffic is bursty and sometimes exceeds your dedicated capacity.

• You hold an uptime commitment to your own users.

Limitations

The shared pool has its own rate limits. Failover is there to keep you online during a problem; it is not a way to get unlimited dedicated capacity on demand. If your steady-state traffic already needs more than your node provides, the answer is more dedicated capacity, not failover. Treat failover as insurance, not as headroom.

A Unified Multichain Endpoint gives you one URL and one credential for every node and chain in your stack. Instead of managing a separate endpoint and key per network, you point at a single base address and name the chain you want in the request.

A multichain application usually collects endpoints as it grows. Each chain brings its own URL, its own access token, and its own security settings, and every new network adds another entry to configure, rotate, and keep in sync. The complexity is not in any single endpoint; it is in the growing set of them.

This add-on collapses that set into one. You keep your dedicated nodes, but you reach them through a single unified endpoint. You select the target chain with a subdomain, a path, or a chain-id parameter, and one credential authenticates across all of them.

Security follows the same principle. You set your rate limits and your IP allowlist once on the unified endpoint, and the policy applies to every chain behind it, rather than being configured network by network.

Benefits

• One URL template. Your client code holds a single pattern, not one URL per network.

• One credential. A single token authenticates across all your chains.

• One security policy. Rate limits and the allowlist are set once and cover every chain.

• Less configuration drift. Adding a chain does not add another endpoint and key to track.

When to use it

• You build a cross-chain application, a wallet, or an aggregator.

• You run an indexer that reads several chains.

• You manage one endpoint and one key per network today, and the overhead slows you down.

Limitations

• If you use a single chain and expect to stay on it, one standard endpoint is enough.

• One shared credential across chains is convenient, but it also concentrates access. Scope it carefully and rotate it on a schedule.

How to Sign Up

1

Go to GetBlock

Visit the homepage and click on the 'Dashboard' button in the upper-right corner, or use this direct link.

2

Choose the sign-up method

• Register with Email

  Enter your name and email address, then verify your email to activate the account.

• Sign in via Google

  Google will share your name, email, language preferences, and profile picture with GetBlock.

• Connect with MetaMask

  Use a MetaMask wallet browser extension to sign up – no email or password required. If you don’t have a wallet extension installed, you’ll be prompted to add one.

• WalletConnect Sign in with MetaMask Mobile, Trust Wallet, Rabby, Ledger Live, or another WalletConnect-compatible wallet.

• Sign up with GitHub

  Use your GitHub credentials to set up an account.

3

Review and accept policies

During registration, you will be asked to accept our Terms of Service and Privacy Policy.

Access the dashboard

Once you've created an account and signed in, you'll be directed to the GetBlock Dashboard.

• You can create endpoints

• Monitor your usage plan

• Access statistics.

Check your User ID

1. Click on your profile icon

1. Click on the Copy Icon to copy your User ID

Every endpoint you create is assigned a unique access token:

https://shared.<region>.getblock.io/<ACCESS_TOKEN>/

The <ACCESS_TOKEN> authenticates requests directly through the endpoint URL.

Making an authenticated request

To make a request, include your full endpoint URL with the access token in the path.

For example, here’s how to fetch the latest Ethereum block number:

curl --location --request POST 'https://shared.eu-central-1.getblock.io/<ACCESS-TOKEN>/

curl --location --request POST 'https://shared.us-east-1.getblock.io/<ACCESS-TOKEN>/

curl --location --request POST 'https://shared.ap-southeast-1.getblock.io/<ACCESS-TOKEN>/

Response:

{
    "jsonrpc":"2.0",
    "id":"getblock.io",
    "result":"0x1449641"
}

Access Token security

Always store your access tokens securely. Avoid exposing them in publicly accessible code repositories or logs.

If a token is compromised, you can quickly roll or delete it without disrupting other endpoints:

1. Go to your GetBlock Dashboard.

2. Locate the endpoint associated with the token.

3. Click the three-dot icon () next to the endpoint.

4. Select the option to either roll (regenerate) or delete the token.

This authentication method ensures that all your interactions with GetBlock’s services remain secure, reliable, and easy to manage.

Import the collection into your Postman workspace: https://documenter.getpostman.com/view/28751185/2s9YRDzqcX.

1. Once the page loads, you'll find a 'Run in Postman' button in the top-right corner. Click this button to open the collection directly in your Postman application.

2. Select the desired network from the drop-down list on the sidebar.

3. Paste the access token copied from your account instead of {YOUR_ACCESS_TOKEN}.

This token will grant you the necessary permissions to explore our node functionalities.

Connection issues

These tools help ensure optimal use of GetBlock’s services and keep you informed of key metrics and events related to your account.

Dashboard

The Dashboard provides a quick snapshot of key metrics:

• Your current plan details

• Remaining CU balance

• Rate limit based on your plan

• Total requests made in the last 24 hours

Detailed statistics

For more detailed analysis, visit the Statistics tab in the dashboard.

Select the time period, protocol name, networks (mainnet/testnet), region, and API interfaces to analyze the data by parameters.

All data is displayed through infographics, including:

• Number of requests and CUs

• Response statuses

• Method call distribution

• Rate limit rejections

Notifications and email communication

GetBlock provides automated email updates for key account and subscription events:

• Account registration

• Successful order payments (Shared, Dedicated services, and Top-Ups)

• Start of grace period

• Subscription expiration

• Dedicated node deployed and activated

• Recurring payment cancelled

Users can also choose whether to receive marketing communications from GetBlock. This preference can be managed in Account Settings → General by enabling or disabling the “I want to receive marketing offers” option.

The GetBlock documentation is available as a Model Context Protocol (MCP) server — a live, machine-readable interface to docs.getblock.io that AI agents can query directly:

https://docs.getblock.io/~gitbook/mcp

Instead of getting non-factual or hallucinated answers, your AI assistant connected to this server searches and reads our documentation from API references, guides, pricing, and setup steps etc, the moment you ask. The server uses streamable HTTP transport and requires no API key or authentication.

What it can do

The server exposes three tools to any connected agent:

Once connected, ask your assistant things like:

• “How do I enable the Yellowstone gRPC add-on on a dedicated Solana node?”

• “What are GetBlock's CU and rate limits per plan?”

• “Show me the Flashblocks API methods for Base.”

Connect your AI agent

Advanced Analytics is a private Grafana workspace for your dedicated node. It records every request the node handles and turns that raw activity into a clear picture of how your node is used, in real time. Without it, a dedicated node is a black box: it serves your traffic, but you cannot see the shape of that traffic or where it strains. It shows request counts, latencies, and errors.

You see the data as time-series charts, which gives you a more readable and understandable in-depth analysis. You can tell which requests consume more compute units(CU).

How it works

The add-on measures every request and stores it as a time series. It then lets you view that data along three dimensions:

1. by RPC method,

2. by access key,

3. and by region

So you can move from a high-level number down to the exact cause behind it.

Three core signals sit at the center of the workspace:

• Request volume: how many calls the node receives over time.

• Latency: shown as percentiles (p50, p95, p99) rather than a single average. An average hides the slow requests; percentiles expose the tail where real problems live.

• Error rate: the share of requests that fail.

The per-method view shows which calls cost you the most; heavy methods such as debug_traceTransaction and eth_getLogs stand out here. The per-key view shows which client or service drives your traffic. The per-region view shows where your users connect from.

The value comes from following one signal to its source. Say your p99 latency jumps at 14:00. You open the per-method view, filter to that window, and find that eth_getLogs latency tripled while everything else held steady. You now know exactly what to optimize, and you never had to guess.

• Cost attribution. Assign traffic to a team, a customer, or a feature by looking at the per-key view.

• Real capacity planning. Size the node from measured traffic rather than an estimate.

• Faster debugging. Trace a latency spike to the method behind it in a single view.

• Abuse detection. Spot a key that starts sending abnormal traffic, with the data to prove it.

• You want to attribute cost to a team, a customer, or a feature.

• You plan capacity and need real numbers.

• You debug latency spikes and need to find their cause quickly.

• You suspect one key is behaving abnormally and want evidence.

Analytics gives you visibility, not control. It shows you what is happening; it does not block or shape traffic. When you need to act on what you see — to restrict access or stop abuse — pair it with the IP Allowlist. And because it works from real traffic, a node with very low, steady volume gains little from it.

An Internet Protocol (IP) allowlist is a network security control that restricts access to your RPC endpoint based on the source IP address of each request. When the allowlist is active, only requests from addresses you have approved can reach your node. Every other request is blocked at the gateway, before it reaches the node and before any processing takes place. In effect, it is a "friend or foe" filter based on where the request comes from.

This adds a layer of defense beyond your access token. A token authenticates who is calling. An allowlist controls where the call comes from. Together they mean that a leaked token is not enough on its own: an attacker would also need to send the request from an approved network.

How Node Allowlisting Works

1. You add one or more entries to the allowlist. An entry is a single IP address, such as 203.0.113.10, or a whole subnet in Classless Inter-Domain Routing (CIDR) notation, such as 203.0.113.0/24. The add-on supports both IPv4 and IPv6.

2. On every incoming request, the gateway compares the source IP against your list. A match lets the request continue to the node. No match returns an access error (403 Forbidden) and the request stops there. Because the check runs at the gateway, a rejected request never consumes your node capacity or your quota.

The allowlist follows a deny-by-default posture. When the list is empty, the node behaves as normal. As soon as you add the first entry, the node accepts only the addresses on the list and rejects the rest.

A few things to plan before you configure the allowlist:

• Account for every trusted network: List each environment that calls your node: production backends, staging, workers, and any third-party service that makes requests on your behalf. An address you forget is an address that gets blocked.

• Do not lock yourself out: If you administer the node from a fixed IP, add that IP before you rely on the list.

• Plan for addresses that change: Some cloud hosts and office connections use addresses that rotate over time. For those, use a CIDR range that covers the expected pool, or route the traffic through a gateway with a static egress IP.

• Protection if your endpoint leaks: Even if your URL or token reaches the wrong hands, an unauthorized server cannot use it, because its requests do not pass the IP filter.

• Protection against quota theft and abuse: No outside party can burn through your request limits from an address you did not approve.

• Defense in depth: The allowlist works on top of token authentication. An attacker would need to steal the token and operate from an allowed IP.

The allowlist fits server-side workloads with stable, known addresses: backends, workers, indexers, other nodes, and corporate networks. For example:

1. You work in a regulated field such as payments, custody, or exchange operations.

2. Your backend runs from static egress IPs.

3. You need to prove that only approved systems reach your node.

The allowlist does not fit clients with dynamic IPs, such as mobile apps and browser-based dApps. In those cases, the request comes straight from the end user's device, and the address changes constantly, so there is no stable list to maintain. For those cases, use token authentication together with referrer or origin restrictions instead.

Zero-Hop Node Access gives you a direct connection to your node, removing the routing layer that normally sits in the path. It is built for the workloads where latency is measured in milliseconds, and every one of them counts.

A normal request does not travel straight to the node. It passes through a gateway and a load balancer first. Those layers do useful work—authentication, rate limiting, health-aware routing—but each one adds a small amount of time and, just as important, a small amount of variance. For an ordinary application, this overhead is invisible. For a trading engine competing on speed, that variance is the problem: not only the average latency, but how much it wobbles from request to request.

Zero-Hop pins your connection to your node and takes those intermediate layers out of the path.

Because you always reach the same node rather than being routed to whichever one the balancer picks, you also get a consistent view of the mempool and chain state — which, for trading, is as valuable as the raw speed. For the largest gain, pair Zero-Hop with a node in the region closest to your own systems, so the short path is also a physically short one.

Benefits

• Lower latency. Removing the gateway and load-balancer hops shortens the path.

• Predictable latency. A fixed, direct route removes the variance those layers introduce.

• A consistent node view. Always hitting the same node keeps your mempool and state view consistent.

When to use it

• You run a high-frequency trading bot or an arbitrage engine.

• You run an MEV searcher, where every millisecond changes the outcome.

• You send transactions where a consistent node view decides success.

Limitations

The direct path is also an unprotected one. By removing the routing layer, you give up the automatic failover and load balancing it provides. That is the right trade for a latency-critical workload and the wrong trade for a normal one — if reliability matters more to you than the last few milliseconds, keep the proxy.

Priority fees incentivize builders to include your transaction faster and position it more favorably within a block. Adding a tip to your private transaction provides three key benefits:

• Higher inclusion probability: Builders prioritize transactions with higher fees

• Better block positioning: Achieve positions 1–2 more reliably

• Faster confirmation: Reduce waiting time for transaction inclusion

They are Two approaches exist for adding priority fees to private transactions:

Choose the appropriate method based on your use case:

Learn how to submit transactions via or method to the private mempool.

The web UI is the fastest way to screen a wallet or transaction — no code required.

Entry point: https://account.getblock.io/products/aml-check→ Run a check.

Screening in three steps

The individual flow is a simple, three-step screen:

The report ("Address risk — Detailed view") surfaces:

• Total risk score — the wallet-wide 0–100 result. It reflects the wallet’s complete screened history across the returned assets, not only its current balance or riskiest token. The interface groups it as Low (0–24), Medium (25–49), High (50–74), or Very high (75–100).

• Recommendation — a plain-language interpretation and suggested review level based on the score. It highlights what to examine but does not automatically tell you to accept or reject the wallet.

Individuals can configure screenings and receive reports inside @GetBlockAMLBot — no separate dashboard needed (Coming soon).

Flashblocks are partial blocks streamed by the sequencer as it builds. The mechanism is powered by Rollup-Boost, a sequencer sidecar built by Flashbots in collaboration with OP Labs. A single OP Stack block is divided into ten Flashblocks streamed at 200ms intervals, each one a delta containing the new transactions and resulting state changes since the previous Flashblock. The preconfirmed state is surfaced through the standard Ethereum JSON-RPC interface using the pending block tag, so existing tooling reads Flashblock state without modification.

How Flashblocks Work

A standard OP Stack block is produced every 2 seconds. Flashblocks subdivide that interval into ten increments:

• The sequencer publishes a new Flashblock every ~200ms (index 0 through 9 within each parent block).

• index 0 carries the base block context; subsequent Flashblocks carry only the diff of new transactions and state changes.

• Reading any supported method against the pending tag returns the accumulated preconfirmed state from the latest Flashblock.

• The same call against latest returns the most recent fully sealed block.

Preconfirmations are strong signals, not guarantees. A streamed Flashblock can be excluded from the final block (a Flashblock reorg). The reorg rate is below 0.1%, but applications handling critical operations should confirm against finalized block data.

There are two access patterns:

• pending tag (request/response): Pass "pending" as the block parameter to any supported read method to get the latest preconfirmed value over HTTP. This is the recommended approach for most applications, as it provides stable behavior with automatic fallback to standard blocks if Flashblocks become unavailable.

• WebSocket streaming (subscriptions): Open a WebSocket connection and subscribe to a Flashblocks topic to receive each Flashblock as it is produced — five times per second. This is intended for latency-sensitive consumers such as trading systems. Applications should avoid a hard dependency on the WebSocket stream and treat it as an optimization layer over the RPC interface.

Flashblocks are documented per network. Endpoints, method tables, and chain-specific methods are covered on the dedicated pages:

Blockbook is an indexer for UTXO chains. It answers questions about an address or a whole wallet — balances, transaction history, and unspent outputs — that a standard Bitcoin node cannot answer on its own.

A Bitcoin node tracks the set of unspent transaction outputs (UTXOs), but it does not organize them by address. Ask a plain node for the balance of an address and it has no direct way to reply, because it was never built to look up history that way. Anyone who needs address-level data has to build a separate index over the chain.

Blockbook, built by Trezor, is that index. It reads the chain and maintains an address-indexed and xpub-indexed view on top of it. You query an address or a wallet, and Blockbook returns the answer from its index.

• Address queries: Ask for the balance, transaction history, or unspent outputs for a single address.

To deploy a private blockchain server, switch over to the ‘Dedicated Nodes’ tab in the Dashboard.

Select a blockchain protocol from the list or click Create new node to begin the setup process from scratch. A dedicated node setup modal will open.

In the setup window:

1. Select the blockchain protocol and the network type (e.g., mainnet, testnet, devnet, etc)

Solana applications often need live, high-throughput access to on-chain events. Solana gRPC plugin solves this core problem of real-time blockchain data access.

Yellowstone gRPC is the name given to the Dragon’s Mouth Geyser plugin’s gRPC interface in Triton One’s “Yellowstone” suite for Solana. It allows opening streams and subscribing to native Solana on-chain events, receiving every new update in real time, with millisecond-level latency.

By plugging directly into validators, it pushes new blocks, transactions, and account updates to your backend the moment they occur.

The Geyser Plugin hooks into validator callbacks for ledger events and publishes those events to its own internal queues. A gRPC server then streams the queued events over the network to subscribed clients.

Geyser gRPC supports streaming the full range of common Solana events:

getblock_unsubscribe cancels a subscription created with . Delivery for that subscription stops and it no longer counts toward your 15-subscription limit. Other subscriptions on the same socket are unaffected.

params is an array containing exactly one object:

Fiat and crypto payments go directly toward a subscription or one-time charge. Credits are a prepaid balance you fund first, then spend across any service on the platform.

Users can pay for subscriptions using traditional fiat currency via Paddle.

How it works:

• Recurring payments enabled by default: Payment is automatically deducted on the billing date.

• Fees: VAT is applied to Paddle payments and varies depending on your region

This add-on adds the account-abstraction methods. Account abstraction lets a smart contract act as a wallet, enabling transactions without native ETH for gas, third-party gas sponsorship, and custom validation logic.

Account abstraction does not change the base protocol. It works through a separate transaction-like object, the UserOperation, and a set of off-chain roles that process it. The geth and reth clients do not know about UserOperations, so they cannot serve the ERC-4337 methods on their own.

To close that gap, GetBlock runs a bundler as a sidecar next to your node. The bundler is the component that understands UserOperations. It exposes the full ERC-4337 RPC to your client and settles the operations on-chain through the EntryPoint contract.

A UserOperation describes an action for a smart-contract wallet. Your client submits it to the bundler rather than to the chain directly. The bundler validates it, holds it in its own mempool, groups several operations together, and submits the bundle to the EntryPoint contract, which executes each one against its target wallet.

An add-on extends your node with a capability that the standard JSON-RPC API does not provide: a second API layer, an address indexer, a bundler, a private mempool, or a real-time stream. Each add-on solves one specific problem that a standard node cannot solve on its own.

The add-ons at a glance

Since the Merge, an Ethereum node runs as two coupled clients: the execution layer, which processes transactions and serves the familiar eth_* methods, and the consensus layer, which runs Proof-of-Stake. A standard node only exposes the execution layer. The Beacon API add-on opens the consensus layer alongside it, so a single dedicated node answers both.

A Bitcoin-type node tracks unspent transaction outputs, but it does not organize them by address — ask a plain node for the balance of an address and it has no direct way to reply. Blockbook, an indexer built by Trezor, maintains an address-indexed and xpub-indexed view on top of the chain and answers those questions from its index.

Account abstraction lets a smart contract act as a wallet — enabling gasless transactions, third-party gas sponsorship, and custom validation logic — but standard clients such as geth and reth do not understand UserOperations, so they cannot serve the ERC-4337 methods. This add-on runs a bundler as a sidecar next to your node: it validates UserOperations, holds them in its own mempool, and settles them on-chain through the EntryPoint contract

If a contract shipped without an event you now need — a missing Transfer log, an unindexed state change — that data does not exist on-chain, and re-deploying a fixed contract cannot rewrite the past. Overlay methods take the real historical state and replay it through your version of the contract: the chain's inputs stay real, only the contract logic changes, and out come the logs the original contract would have emitted.

A pending transaction normally waits in the public mempool, where MEV bots watch for trades they can exploit — front-running your trade, sandwiching it between two of their own, or back-running the price gap it opens. Every one of those attacks depends on the bot seeing your transaction while it waits. MEV Protection routes your transactions through a private mempool, in partnership with Merkle, so a searcher never sees them and has nothing to attack.

Yellowstone gRPC is a high-performance Solana Geyser plugin, built by Triton One, that streams on-chain data directly from validators with millisecond-level latency—often hundreds of milliseconds faster than standard RPC or WebSocket APIs —and can handle millions of events per minute.

In the dedicated node configurator, Step 3 (Select API and Add-ons) lists the add-ons available for your chain — check the ones you need. For a node that is already running, open the node's Add-ons tab in the Dashboard: from there you can add a new add-on, cancel an active one, or create an endpoint for it. Included add-ons come at no extra cost depending on your configuration; advanced add-ons are billed in addition to the base node price.

A block that looked canonical can be replaced by a competing block a few seconds later. Every event the stream delivered from the replaced block (headers, transactions, receipts, logs, transfers, and traces) is then no longer true.

EVM Data Stream reports this on the same subscription that delivered the original event. There is no separate reorg topic and no includeRemoved option: corrections are always on.

The event envelope

Every event, including a correction, carries the same four fields:

A delivered event and its later correction:

1. Store every removed: false event by eventId.

2. When the same eventId arrives with removed: true, undo or delete the stored value.

3. Events from the new canonical branch may arrive before or after the removals. Apply every event by

A minimal client reducer:

• Corrections are always on. A client that does not want them ignores removed: true.

• Corrections pass the same filters as the original event. A filtered subscription never receives a correction for an event it could not have received.

• A correction is sent only for an event this subscription received.

• Events of the new canonical branch may arrive before the old branch is removed.

• Exactly-once delivery.

• A common order across different subscriptions on one socket, or across API replicas.

• Replay of events published while you were disconnected, corrections included. After a reconnect, rebuild state from your own source (for example, an RPC node) before trusting the stream again.

Inclusion in a block is not finality. The stream delivers events as soon as blocks are observed, and a correction may follow. If your application must act only on final data, such as crediting a deposit, wait for your own confirmation depth or for the network's finalized block before acting, and use corrections to reverse anything you showed provisionally.

Crypto Address Audit is GetBlock's AI-powered risk and compliance suite that screens wallets and smart contracts for fraud risk, AML exposure, and rug pull detection in a single API.

The service runs on pure on-chain behavioral analysis with no source code review and no off-chain data, across Ethereum, BNB Smart Chain, and Base.

Choose Your Crypto Audit API:

1. Wallet Audit

A complete behavioral profile of a wallet address. Returns a trust score, AML check across 18+ parameters, behavioral risk profile (Risk Willingness, Experience Level, Risk Capability), protocol interaction history, transaction breakdown by category, and predictive intentions.

Learn more about Wallet Audit, check out it docs, or access its endpoint

1. Wallet Risk

A faster, lighter check focused on a single binary outcome: is this address safe to interact with? Returns a risk score and the flags that drove it. Use this when latency matters and a full audit is more than the use case needs — payment flows, point-of-sale, real-time wallet connect.

Learn more about , check out it , or access its

1. Rug Pull Checker

A predictive check for smart contract and liquidity pool addresses. Analyzes the on-chain behavior of the contract creator and individual liquidity providers — tracing through intermediate contracts to the source wallet — and returns a rug pull risk score (0–100), risk level (LOW / MEDIUM / HIGH), creator trust score, per-LP trust scores, and behavioral flags. The underlying AI model is trained on 336K smart contracts.

Learn more about , check out it , or access its

Two ways to use Crypto Address Audit, depending on the workflow.

1. Via the : This runs a check on the wallet/contract address through the UI. Paste an address, and run the check. No code required. Best for ad-hoc analysis, manual due diligence, and trying the service before integrating it.

2. — one POST request per address, JSON response. Best for production integration into a DeFi protocol, wallet, launchpad, or any product that needs to screen addresses programmatically. .

Crypto Address Audit uses a single subscription that covers all three services with a single API key.

Each user gets 5 free requests per day. After the free quota is used, each request costs $0.20 USD, deducted from the prepaid balance.

1. On your , click on the credit balance as seen below:

1. Click on Top Up

1. Select the amount you want to pay or enter the amount:

1. After that, click on Proceed to checkout

2. You'll be routed to another page to complete your payment

1. Once you've completed your payment, go back to your dashboard to see it reflected.

GetBlock provides direct access to blockchain historical states through both the Dedicated Nodes service and archive-enabled Shared RPC endpoints.

This page covers Archive Mode – a setting that turns on archive-node access within GetBlock’s Shared Nodes subscription.

Common RPC use cases enabled by Archive Mode:

• Read contract/account state at any past block, not just latest , using methods like (address, blockNumber), (contract, slot, blockNumber), (address, blockNumber), etc.

• Call view functions against historical state: e.g. (..., blockNumber).

• Run historical queries and debugging that rely on old state: forensics, audits, explorers, indexing, and retroactive analytics.

• Support tracing and higher-fidelity debugging that may require historical state.

This feature removes the need to run a dedicated archive infrastructure for some use cases, letting developers perform on-demand historical queries via GetBlock RPC API.

Archive functionality is included with all Shared Node subscriptions, excluding the Free plan. No additional fee required.

Archive support is provided for a set of popular protocol mainnets, including Ethereum, BSC, Polygon, Base, Arbitrum, TRON, Sui, Cardano, etc.

Look for the small history icon ( ) when picking a protocol during the . It indicates that Archive mode is available for that blockchain.

1. Sign in to your GetBlock dashboard and make sure you’re on the Shared Node tab.

2. Click Get endpoint and choose a required blockchain protocol.

1. Find the Mode toggle and switch the Archive mode on.

1. Finish configuring endpoint details by choosing the API interface and server location as usual.

After clicking Get, the new Archive endpoint appears in your Endpoints list. The endpoint URLs will follow the existing GetBlock format but point to archive nodes.

Archive endpoints usage remains subject to your plan’s .

However, serving requests from archive infrastructure involves heavier storage and compute power compared to regular full nodes.

Therefore, enabling the Archive mode affects how CU usage is calculated:

• GetBlock applies a 2× Compute Unit (CU) multiplier to all requests made through the Archive endpoint.

• The multiplier is applied to all requests made to an archive endpoint, even if the invoked RPC call does not require a historical state.

You can review the per-chain CU values for each method on our page.

Example:

If eth_getBalance costs 20 CU on a standard shared endpoint for a given chain, the same call to an Archive-enabled shared endpoint will cost 40 CU.

Plan accordingly and consider using standard Full mode endpoints for non-archive traffic to avoid unnecessary CU consumption.

• Use archive endpoints only for workloads that require a historical state. For transactions or current state queries, use a standard Full mode to save CU.

• Monitor CU consumption on the dashboard and set alerts for spikes or when usage nears your plan limit.

• If you run sustained, high-volume archive queries, consider using a Dedicated Node.

what you’re building — our team can guide you to the most efficient archive node setup.

Dedicated Nodes are fully private blockchain nodes deployed and managed for your team. With two distinct performance presets, you can balance throughput, SLA, and budget to fit your workload.

Available tiers:

1. High Performance Tier: Designed to provide maximum available resources, throughput, and reliability. It is intended for applications where performance and availability are critical. The focus is on delivering the highest service levels and supporting the most demanding production workloads.

2. Standard Performance Tier: Designed to offer enterprise-grade performance sufficient for the majority of professional and business use cases, but at a more cost-efficient level. It targets demanding business applications and sustained usage, but without the additional (and sometimes excessive) headroom reserved for High Performance tier.

By providing these options, GetBlock helps you to deploy Dedicated Nodes that are tailored to your application’s technical, operational, and budget requirements.

When deploying a Dedicated Node, you can choose between High and Standard setups to align with your application’s resource needs and expected workload.

• Select High if your workload is latency-sensitive, demands very high concurrent throughput, or is critical to business continuity.

• Select Standard for typical production apps, where workload is within supported performance bounds.

Configuring tiers is available for all supported protocols unless there are specific infrastructure limitations for a given network. In this case, a chain will only support a single tier.

Dedicated Nodes are billed at a set monthly rate determined by configured settings:

1. Performance tier: Total cost scales with the performance tier selected – High tier is priced at a premium relative to the Standard tier.

2. Blockchain network: Each protocol has different hardware requirements, which impact both High and Standard tier pricing.

3. Node mode: Full or Archive.

4. Client parameters.

Refer to your Dashboard for up-to-date pricing details and protocol-specific options.

To select a tier during node setup, open the Dedicated Node dashboard:

1. Select protocol, network, deployment region, node mode, and a preferred client.

2. As a final step, choose the Performance Tier (High or Standard).

1. Review updated performance and pricing details.

Your dedicated node will be ready for use upon activation. To switch between tiers after deploying, reach out to support.

For advanced workloads or unique requirements, our engineering team can help craft a custom private node solution beyond the High/Standard presets. for tailored deployments.

BSC accelerated node is a high-performance dedicated node deployed on top of high-speed networking layers via the Blockchain Distributed Network (BDN). It observes state changes, mempool activity, and block production events significantly faster than standard peer-to-peer setups, serving traders, validators, dApps, and more with low latency.

Interested in building on BSC using an Accelerated Dedicated Node? Reach us for more information.

How It Works

In a standard setup, your node receives data through the BSC peer-to-peer gossip network:

With BDN Gateway acceleration, your node receives data through two channels simultaneously:

Your dedicated node receives data from both the BDN fast path and the standard P2P layer, ensuring it always has the freshest state available.

Architecture Details

1. Connection: We connect your dedicated node's P2P interface to the GetBlock Data center.

2. Data Flow: The node receives transactions and blocks from both the standard P2P layer and the BDN propagation network.

3. Automatic Selection: Your node automatically uses the first source to deliver data.

The BDN Gateway improves the delivery speed of:

1. Traders: To buy and sell tokens faster and submit transactions

2. Developers: To build a lower-latency dApp, access fresher data, and deliver more responsive user experiences

3. Validators: To receive transactions and block earlier than other validators and improve participation and rewards.

Node acceleration directly benefits latency-sensitive applications:

• Trading Bots: React to price movements and arbitrage opportunities faster

• Liquidation Systems: Monitor positions with fresher state data

• Analytics Pipelines: Process blocks and transactions with minimal delay

• MEV Strategies: Observe mempool activity before competitors

While node acceleration improves data reception passively, you can further improve your dApp or workflow by:

• for direct access to BDN data

• with accelerated propagation

• Using private transactions for or

GetBlock EVM Stream delivers blockchain events in real time for wallets, payment services, DeFi applications, and analytics platforms. You select a network, event types, and filters, then receive updates over a persistent WebSocket connection.

This reduces the need to continuously poll RPC endpoints, extract events from blocks, and maintain event delivery infrastructure. Filters for addresses, contracts, and other parameters let applications receive the data they need while saving cost.

Use cases and supported topics

With EVM Data Stream, you can carry out the following operations:

EVM Data Stream is live on four networks. Each has its own WebSocket endpoint, and every topic is available on every network:

EVM Data Stream is charged by usage in Compute Units (CU). Standard pricing costs 10 CU per delivered event. Usage depends on the number of notifications delivered to the customer after filters are applied; for example;

• 1,000 events = 10,000 CU.

• 100,000 events = 1,000,000 CU.

• 1,000,000 events = 10,000,000 CU.

Each notification counts separately. One transaction can generate multiple notifications; delivering the same event to multiple subscriptions is counted separately. Precise filters help customers control data volume and CU consumption.

• : connect and receive your first events.

• : keep your state correct when blocks are replaced.

• : methods, all 15 topics, limits, and errors.

GetBlock Crypto AML is a compliance-grade risk-screening service for crypto addresses and transactions. It evaluates wallet addresses or transaction hashes and sends a detailed structured risk report thats contains a composite score, an exposure breakdown, and FATF-aligned flags within seconds.

It is built to give small teams, exchanges, OTC desks, and individual traders the same FATF-aligned data and scoring as large compliance vendors, but without KYB, annual contracts, or lengthy onboarding.

Before you accept, send, or clear crypto funds, you will have to answer this question:

has this wallet been used by sanctioned entities, darknet markets, mixers, ransomware, or scams?

Crypto AML answers that by tracing the address's on-chain history, wallet-to-wallet links, direct counterparty interactions, and public sanctions data — then condensing it into a decision-ready report.

Typical uses:

• Screen a counterparty before a transfer, while it is still reversible.

• Safely accept incoming funds so a downstream exchange doesn't flag or lock the deposit.

• Onboard customers / KYT — screen wallets during onboarding or ongoing monitoring.

Crypto AML currently covers five networks — chosen because they carry the bulk of emerging-market exchange and remittance volume:

The engine combines on-chain and off-chain data:

• On-chain: behavioral patterns, wallet clusters, counterparty flow, smart contract exposure, etc.

• Off-chain: sanctions feeds, public attribution data, law-enforcement intelligence.

Choose the access method that fits your workflow:

• Web — Select a network, enter a wallet address or transaction hash, and view the report. Export a PDF and keep an audit-ready history in your account.

• REST API — Integrate bearer-authenticated screening endpoints into your backend.

Choose a pricing model:

• Pay as you go: Top up your prepaid balance with a card or crypto. Each check deducts credits.

• Bulk packages: Buy checks upfront for a lower per-check rate. Larger packages receive larger discounts. Reach out to the

How to make HTTP requests with curl using JSON config file

Using GetBlock’s JSON configuration file with curl is particularly helpful when you need to access various node endpoints without hardcoding API keys in the code:

1. Download the getblock.config.json file from your GetBlock account;

2. Make sure you have jq installed. jq is a versatile command-line tool that enables extracting values from JSON files;

3. Navigate to your workspace or directory where you have imported the getblock.config.json file and open a terminal;

4. Now, you can make a GET request to a selected node endpoint using the curl command.

Connect to Ethereum nodes and other EVM-compatible networks using web3.js and GetBlock’s JS configuration file.

1. Make sure the web3.js library is added to your project. In order to do that, use one of the following methods:

• Npm: npm install web3

• Yarn: yarn add web3

• Pure js link: dist/web3.min.js

1. Download the getblock.config.js file from your GetBlock account. Add this file to your project directory.

2. Import the getblock module to a .js file that configures a new Web3 instance:

1. Connect to an Ethereum node and start sending API calls using web3.js over HTTP or WebSocket in the format below:

Use go() method to access an entire endpoint or token() to fetch the token.

Set up GetBlock’s JS config file in Hardhat following the steps below:

1. Ensure you have Hardhat installed as a dependency in your Node.js project or run the following command to do so:

1. Navigate to your GetBlock account and install the getblock.config.js file. Copy and paste it into your working directory;

2. Open the hardhat.config.js file from your project directory and import the getblock module:

1. To set up GetBlock as a provider, modify the Hardhat configuration file with the credentials as shown below. Use go() method to access an entire endpoint or token() to fetch the token only.

This short guide shows you how to create an RPC endpoint (an RPC URL) for any supported protocol in your GetBlock Shared Node dashboard to connect it to your app, script, or wallet.

The steps below cover how to generate a new endpoint URL with an Access Token:

Generate and add as many access tokens as required for this protocol. Each token is a unique endpoint for you and your application to interact with the blockchain.

When creating an endpoint in your GetBlock Dashboard, for select protocols, you can choose between two node access modes – Full and Archive. This selection determines how much historical blockchain data your endpoint can access.

• Full mode: Standard full (pruned) node behavior — current state lookups, sending transactions, reading blocks, etc.

• Archive mode: Enables access to the historical chain state. Useful for querying balances, contract storage, UTXO sets, executing historical calls, simulating transactions at a past block, or reconstructing chain state for analytics and audits.

The created URL is shown on the endpoints list so you can copy it and start calling the node. Use the right-side menu () to roll (regenerate) or delete the endpoint from the list.

Brave Wallet supports many networks and offers extensive customization options. However, each of its chains uses a public RPC API endpoint, which is very bad for privacy and efficiency.

GetBlock’s private RPC nodes can solve this problem. After downloading the Brave browser and setting up the wallet, visit and get one of the 100+ available chain endpoints.

Every wallet’s network can be modified this way, and this step-by-step guide shows how to do that.

You need to set up the Brave wallet and prepare the GetBlock API endpoints.

Brave Wallet is inseparable from the Brave browser. So, download and install the browser from the . It’s available for desktop, Android, and iOS.

After opening the browser, look at the wallet icon in the upper right corner. Click on it to open the Brave Wallet. Import the account using a seed phrase or create a new one.

This section contains all the Flashblock methods available on the Base network

In this section, you will learn how to fetch the latest Flashblock — the current in-progress block containing every preconfirmed transaction — using either:

• Axios (JavaScript / Node.js)

• Python (Requests library)

Before you begin, you must have already installed or on your local machine (for the Axios example) or Python and pip (for the Python example).

Optimism runs on the OP Stack (chain ID 10), the reference implementation for which Flashblocks' Rollup-Boost sidecar was built. Flashblocks are available on Optimism Mainnet and Optimism Sepolia (chain ID 11155420), served over the standard Optimism RPC interface so existing tooling reads preconfirmed state without modification.

Before you start:

1. Create a JSON-RPC endpoint for the Ethereum blockchain from your GetBlock account.

2. Replace the endpoint URLs in the examples below with your actual URLs.

Run the following command to retrieve the latest block number:

Flashblocks deliver ~200ms transaction preconfirmations on Base by streaming partial blocks before the next full block is sealed. Each 2-second Base block is divided into ten Flashblocks streamed at 200ms intervals, exposing preconfirmed state through the standard JSON-RPC pending block tag.

Yellowstone gRPC is a high-performance Solana Geyser plugin that provides real-time streaming access to on-chain data. Built by Triton One, it delivers blocks, transactions, and account updates with millisecond-level latency directly from Solana validators.

GetBlock offers managed Yellowstone gRPC endpoints as an add-on to Dedicated Solana Node subscriptions, eliminating the need for infrastructure setup and maintenance.

• Near-zero latency: Streams data directly from validators, often hundreds of milliseconds faster than standard RPC/WebSocket APIs

This cancels a subscription created with eth_subscribe. The subscription ID is no longer valid after this call.

GetBlock offers four main service options: Shared Nodes, Limitless Node, Dedicated Nodes, and Enterprise Solutions. This page provides a high-level overview of these services.

You can explore detailed pricing and plans from your dashboard in the “Pricing” section or via .

Shared nodes operate on a resource-sharing model, where multiple clients access the same underlying node infrastructure maintained by GetBlock.

Our Shared Nodes deliver the perfect balance between affordability and performance:

MetaMask is a blockchain wallet available as a mobile application and a browser extension. It allows you to interact with Ethereum-based decentralized applications (dApps) directly from your browser.

This step-by-step tutorial will guide you through connecting GetBlock’s powerful nodes to your MetaMask wallet.

If you don’t already have MetaMask, download and install it from the official website: .

MetaMask extension is officially supported on Chrome, Brave, Firefox, Microsoft Edge, and Opera browsers.

Generate a JSON-RPC URL for the selected network from your GetBlock and copy it.

If the network is already in your list but uses a default RPC provider, you can switch to GetBlock by following these steps:

Solana Shreds Streaming delivers raw block data directly from validators over UDP before the block is assembled. It gives you the earliest possible view of what is happening on Solana — earlier than any standard RPC or gRPC feed.

A Solana leader does not publish a finished block all at once. As it produces a block, it splits the data into small fragments called shreds and streams them across the network through Turbine, Solana's stake-weighted propagation layer. Other validators receive the shreds and reassemble them into a complete block.