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

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

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.

Docs will be here soon!

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.

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

Getting Started

Create your account, explore plans & features, and make your first API call

Guides

Set up endpoints, manage access tokens, and integrate GetBlock APIs step-by-step

API Reference

View supported networks, available endpoints, and full API specifications

Popular chains

Get started with our most in-demand blockchain networks.

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:

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.

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

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

Fiat payments

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

• If the card balance is insufficient: GetBlock will retry the payment after three days. If the retry fails, the plan will be frozen until the payment is resolved.

To update your payment information while you have an active subscription:

1. Go to Pricing → Manage Plans.

2. Click ‘Edit Payment Method’.

3. Enter your updated payment details and save the changes.

Users can top up their accounts with cryptocurrency through NOWPayments.

How it works:

• Payments are processed as one-time transactions: add funds as needed.

• Supported cryptocurrencies: any token on any network available through NOWPayments at the time of payment.

• Fees: blockchain network fees apply.

Before you start:

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

2. Replace <ACCESS_TOKEN> in the examples below with your actual Access Token.

Fetch the current block number

Run the following command to retrieve the latest block number:

curl --location --request POST 'https://shared.eu-central-1.getblock.io/<ACCESS_TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_blockNumber",
    "params": [],
    "id": "getblock.io"
}'

If successful, the response will include the current block number in hexadecimal value:

Identify the blockchain network with the eth_chainId method:

Response example:

In this example, 0x1 indicates the Ethereum Mainnet. The chain ID helps confirm which blockchain network you are interacting with.

Retrieve the balance of an Ethereum address using eth_getBalance. Replace <ACCOUNT_ADDRESS> with the target wallet address:

Example response:

The result field shows the account balance in wei (1 ether = 10¹⁸ wei).

Connection issues

JSON-RPC errors

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.

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.

What it does

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

• Wallet queries: Request a full wallet at once using an xpub or an output descriptor. Blockbook derives the addresses and returns the combined result, so you do not track each address yourself.

• Derivation support: The add-on covers the BIP44, BIP49, BIP84, and BIP86 (Taproot) schemes, so it reads legacy, SegWit, native SegWit, and Taproot wallets.

• Filtering and paging: Page through large result sets and filter transactions by block-height range.

An xpub query, for instance, returns the balance for the entire wallet, the derived addresses, and the transactions, sorted by block height with the newest first.

Supported networks

Because Blockbook indexes unspent outputs by address, the configurator offers it only on Bitcoin-type chains:

Each chain's paths and methods are listed under its own entry in the API reference. The schema is shared across all of them, so a query written for one chain works on another with only the endpoint changed.

Benefits

• Wallet-level answers: One xpub call returns a full wallet, instead of many per-address calls.

• No indexer to build: You skip building and operating an address index next to your node.

• Direct UTXO access: You read unspent outputs to construct a spending transaction.

• Broad wallet coverage: Legacy through Taproot wallets are all supported.

When to use it

• You build a Bitcoin wallet or a portfolio tracker.

• You need address balances or transaction history on a UTXO chain.

• You construct transactions and need the UTXOs behind an address.

Limitations

• Blockbook serves UTXO (Bitcoin-type) chains. It does not apply to account-based chains such as Ethereum.

• The interface serves many coins through a shared schema, so some fields apply only to specific chains.

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.

• 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.

• 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.

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.

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.

• 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.

• 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.

• 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.

• 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.

• 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.

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:

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:

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.

The server exposes four tools to any connected agent:

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.

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.

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).

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.

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.

The current CU balance for Shared Node users is displayed on the Dashboard. This shows how many Compute Units (CUs) are left before running out.

With the "Top Up" feature, users can add more Compute Units to their account or upgrade to higher monthly limits.

Starter, Growth, Advanced, Scale, Pro, Premium & Enterprise users can refill their CU balance or switch to another plan for increased limits:

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

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.

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.

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 https://getblock.io/pricing/.

Shared Nodes

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:

• Cost efficiency: Benefit from our pricing model based on , so you only pay for the resources needed for your current workload.

• Flexible pricing: Options range from a free to high-volume plans — accessible for individual developers and smaller teams while supporting the scaling needs of growing dApps.

• Consistent performance: Each plan enforces a Requests Per Second (RPS) limit, preventing individual spikes from impacting overall quality.

• Multi-chain accessibility: Prototype, test, and deploy applications across different networks without the complexities of deploying infrastructure for each blockchain individually.

• Regional endpoints: Connect to the nearest datacenter — Frankfurt (EU), New York (US), Singapore (APAC) — to minimize network latency.

• Archive data access: Run full historical blockchain queries.

• Tiered support levels: Support options adapt to your requirements, from basic help to priority support when you need it most.

Limitless Node is the middle ground between Shared and Dedicated Nodes. It's an isolated endpoint with guaranteed RPS and a flat monthly fee. Pricing is set by throughput rather than Compute Units, so you can send unlimited requests within your RPS tier without per-request metering.

• Dedicated routing to ensure consistent performance and throughput.

• Fixed RPS tiers: Choose the throughput level that matches your workload, from smaller setups to higher-volume production traffic.

• No Compute Unit (CU) or request limits: Each plan includes a set RPS limit with unlimited requests within that tier.

A Dedicated Node is a private RPC server deployed solely for your use case. That means consistent throughput, no API rate throttling due to other users, and better uptime guarantees.

This option is ideal for users that require high performance, full control over node configuration, and a flawless connection to the blockchain without any limitations:

• Mission-critical reliability: Maximized uptime and robust failover mechanisms for even more reliable service.

• Unlimited usage: No per-second request caps or CU tracking.

• Low latency: With servers available in Europe, Asia, and the USA, choose the optimal server location to minimize latency and enhance performance for your users.

This option is designed to meet the needs of organizations operating at scale or applications that require extra resources, features, and dedicated support.

What’s included:

• 99.9%+ uptime guarantee

• Customizable node configurations and integrations

• Performance optimization via load balancers

• Advanced analytics and alert systems

Visit the to learn more about how we tailor services to fit complex, high-demand environments.

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.

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.

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.

What is Yellowstone gRPC?

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.

How Yellowstone gRPC Geyser works

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.

Supported data streams & subscriptions

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

• Account updates (writes): Every time an account’s data changes, a notification is emitted.

• Transactions: Each transaction processed by the leader generates a stream event with all associated account changes.

• Ledger entries: Low‑level entry/shred events (raw blocks of ledger data) can also be streamed.

Every update stream can include full transaction metadata, instruction details, and parsed logs – essentially everything you’d see in a or call, but pushed in real time.

In addition to streaming methods, Dragon’s Mouth also exposes several unary RPCs via the same gRPC interface for quick queries about:

• The Slot;

• Block height;

• Latest blockhash;

• Valid blockhash.

Together, this provides a way to both fetch state on demand and receive updates in real time.

• Near-zero latency: By streaming directly from leaders, Dragon’s Mouth delivers updates often hundreds of milliseconds faster than standard RPC/WebSocket APIs.

• High throughput: The plugin can handle millions of events per minute under load, built for Solana’s high transaction volume. Optional compression can be applied for even more efficiency.

• Built-in support for bi-directional streaming: Keep-alives, ping/pong frames help maintain long-lived connections.

Overall, applications can keep pace with Solana’s peak TPS without data loss, receive only relevant updates, save bandwidth, and react faster.

Solana gRPC streaming capabilities are crucial for time-sensitive applications, apps that need to react the moment on-chain state changes without manual refreshes.

gRPC API ideal use cases include:

• High-frequency trading or arbitrage systems (e.g. MEV bots);

• On-chain indexers & archives;

• Live analytics;

• Real-time monitors for DEXes, NFTs, wallets, etc.;

Using Yellowstone gRPC for your Solana data means you get a high-throughput, low-latency, bidirectional streaming channel.

Instead of polling REST endpoints every few seconds or using Solana’s WebSocket API (which typically only updates after a block finalizes), the gRPC interface allows tracking every new event down the wire as it happens.

Overall, it removes much of the boilerplate: your backend code subscribes once, then simply reacts to incoming messages

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.

Before you start

Set up your wallet

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

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

Get a custom RPC URL

Generate a JSON-RPC URL for the selected network from your GetBlock account 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:

1. Click on the current network name in MetaMask to open the dropdown of networks.

2. Find the network you want to edit and click the settings menunext to it. Select 'Edit'.

1. Open the ‘Default RPC URL’ dropdown and select 'Add RPC URL'.

2. Paste the JSON-RPC endpoint URL from your GetBlock account (https://shared.eu-central-1.getblock.io/<ACCESS_TOKEN>/).

3. Name the new RPC URL for easier identification.

1. Click 'Add URL', then 'Save' to confirm.

You can now switch between RPC URLs for that network as needed.

If the network isn’t in your list, you can add it as a custom network. For this example, we will add the Polygon zkEVM to MetaMask.

1. Click on the current network name.

2. Select 'Add a custom network'.

1. Fill in the required fields:

1. Click 'Save', and the custom network will be added and selected as default.

Solana Shreds Streaming delivers raw block data straight 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.

What a shred is

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.

Every standard data feed sits at the end of that journey. It waits for the shreds to travel through Turbine, for the block to be reassembled, and for a commitment level to be reached before it reports anything. Shreds streaming skips the wait by reading the shreds at the source.

What you receive

From the shreds you reconstruct transaction intent as the leader is packing it: transaction signatures, the accounts involved, the instructions (program, accounts, data), address-lookup-table references, and slot numbers. This arrives roughly 100 to 500 milliseconds earlier than a standard commitment-based feed reports the same activity.

That head start is the entire point. In latency-sensitive strategies, seeing a transaction before it is confirmed is the difference between reacting first and reacting too late.

1. As a dedicated node add-on. You attach shreds streaming to your Solana dedicated node, giving your node and your workloads a faster, steadier source of block data.

2. As a standalone service — no node needed. You top up credits, open a UDP port, and start receiving shreds. You do not run or rent a Solana node at all. Decoding the shreds gives you the transaction data directly, and your credit balance meters the usage.

The service connects to validators and forwards their shreds to your listener over UDP. UDP carries the data at wire speed: it has no handshake and no retransmission, so it removes the overhead that slows a TCP-based feed. You run a listener on an open UDP port, decode the incoming shreds into transactions, and act on them.

• The earliest view of the chain: You act on transaction intent before a standard feed reports it.

• Lower tail latency: Shreds arrive with less timing variance, so the feed stays steady slot after slot.

• A redundant data path: Direct shreds add a second source next to Turbine, which helps in remote or less-peered regions.

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

• You run an MEV searcher and need to react first.

• You run a liquidation bot where a few milliseconds decide the outcome.

• Pre-execution data only: Shreds show intent, not results. You do not get success or failure, balance changes, logs, or compute usage, so some transactions you observe will later fail. Treat the stream as a signal, and confirm outcomes through a normal feed.

• Possible packet loss: UDP trades reliability for speed, so a raw stream can drop a packet. This is acceptable for speed-critical work, but you design for it.

• You decode the stream: Raw shreds need a listener that decodes them. This is a low-level integration, not a single RPC call.

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).

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

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.

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.

• 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.

• 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.

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.

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.

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.

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? for more information.

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.

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.

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)

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.

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).

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,

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.

1. You add one or more entries to the allowlist. An entry is a single IP address, such as 203.0.113.10

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

Quickstart

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).

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

Solana Market Data gives you low-latency, ready-to-use market data from Solana without the need to build and maintain your own indexing and data-processing infrastructure.

Instead of working with raw blockchain transactions, decoding different DEX programs, and building aggregation pipelines yourself, you can consume already processed market data through a simple API.

What you can get

Solana Market Data provides trading information aggregated across supported Solana venues.

Depending on how much processing you want to handle yourself, you can work with:

You can choose between lower-level trade data and higher-level market metrics that are already calculated for you.

Building the same pipeline yourself requires you to collect Solana transactions, support multiple trading venues, decode swaps, normalize the data, and continuously calculate market metrics.

Solana Market Data handles this processing for you.

This allows you to focus on building your:

• trading application;

• analytics platform;

• market dashboard;

• trading strategy;

Getting started is straightforward:

1. Activate Solana Market Data and get access with your API key.

2. Choose the data you need — for example Trades, VWAP, Volume, or Candles.

3. Query or stream the data using HTTP, WebSocket, or Yellowstone-compatible gRPC.

Explore the available Market Data methods, learn how to connect to the API, or try the service directly in the Playground.

StreamFirst is GetBlock's infrastructure solution for delivering faster (ultra-low latency) on-chain state updates from the Solana blockchain.

By combining software-level acceleration with network-level optimization, StreamFirst enables developers to receive blockchain data faster than traditional RPC methods. This reduces the consistent polling updates, which either lead to timeouts or rate-limiting issues.

Interested in building on Solana with StreamFirst? Reach us for more information.

Core Stack

StreamFirst consists of two core optimization layers:

1. Software-level acceleration: Accelerated Yellowstone gRPC implementation

2. Network-level acceleration: Optimized shred-stream delivery via direct validator connections.

StreamFirst optimizes the entire pipeline from validator broadcast to application delivery:

• The network layer ensures the earliest possible data reception

• Software layer ensures minimal processing latency

• Result: Fastest end-to-end delivery of on-chain state updates

Yellowstone is a high-performance Geyser plugin that streams real-time blockchain data via gRPC interfaces. As a result of our partnership with the core Yellowstone team members, GetBlock's Accelerated Yellowstone implementation includes:

• Optimized data serialization: Optimized the original version of the low-level logic to improve the speed of state updates compared to the original Yellowstone implementation, and reduced overhead in encoding and transmitting blockchain state.

• Enhanced filtering mechanisms: More efficient subscription management for accounts, transactions, slots, and blocks

• Improved connection handling: Better resource management for sustained high-throughput streams

Solana validators propagate blocks by breaking them into small fragments called "shreds" and distributing them via the Turbine protocol. StreamFirst taps into this raw data stream:

• Direct shred reception: Receives block fragments (shreds) via UDP as validators broadcast them.

• Early state reconstruction: Rebuilds block data before it's fully confirmed and distributed via standard RPC

GetBlock operates as a top-tier Solana node provider in Frankfurt, a zone with the highest density of Solana validator stake. This strategic positioning provides:

• Proximity to major validators: Direct access to high-stake validators concentrated in the region

• Ultra-low network latency: 6ms latency within Europe

• Optimal shred reception: Positioned to receive validator broadcasts with minimal delay

The combination means you get blockchain state updates as validators are producing blocks, not after they've been fully processed and distributed.

Data Flow:

1. Block Production: Solana validators produce blocks and fragment them into "shreds."

2. State Reconstruction: Shreds are decoded and reassembled into transactions and account updates

3. Accelerated Processing: Optimized Yellowstone plugin processes data with reduced overhead

Traditional RPC methods introduce latency at multiple stages:

• Waiting for block confirmation

• HTTP request/response overhead

• JSON parsing and serialization

StreamFirst bypasses these bottlenecks by:

• Receiving data at the validator propagation speed

• Using binary gRPC protocol (faster than JSON)

• Streaming continuously without polling

StreamFirst is ideal for applications where milliseconds matter:

• High-frequency trading bots: React to price changes before slower competitors

• MEV searchers: Identify arbitrage opportunities in real-time

• DeFi protocols: Monitor liquidation events and oracle updates instantly

StreamFirst supports all standard Yellowstone gRPC subscription types:

• Account updates: Monitor balance changes, data modifications, and ownership transfers

• Transaction streams: Receive all transactions or filter by program/account

• Slot updates: Track block production and commitment levels

StreamFirst is available as an add-on for GetBlock's dedicated Solana nodes. It's configured as a plugin in the node configurator and requires:

• Dedicated node subscription

• Geographic proximity to GetBlock's validator network for optimal performance

• Additional fee based on data throughput requirements

StreamFirst gives developers a competitive edge by delivering Solana blockchain data at near-validator speed. The combination of accelerated Yellowstone software and optimized shard-stream networking, optimized shred-stream networking, and strategic Frankfurt positioning ensures low latency between your customer and dedicated node. This ensures your dApp has the earliest possible view of on-chain activity—critical for time-sensitive operations in DeFi, trading, and real-time analytics.

For consultation on optimal deployment architecture for your specific use case, contact

1. Activate Solana Market Data

Choose Solana Market Data in your GetBlock account and activate a subscription. You can pay using whichever option works best for you:

• Card

• Crypto

• Prepaid credits