# Welcome

Welcome to GetBlock! We make it easy for developers and businesses to connect to 130+ blockchain networks.

<figure><img src="/files/5YNCRFNRjbeZ4Xn0lpL8" alt=""><figcaption></figcaption></figure>

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.

{% embed url="<https://www.youtube.com/watch?v=fl3NwMBIxOQ>" %}
GetBlock Product Demo
{% endembed %}

### Core GetBlock Services

| Services                 | Description                                                                                                                               |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **Plug-and-Play access** | Our ready-to-use blockchain nodes and APIs help you get started immediately.                                                              |
| **99.9% uptime**         | Reliable 24/7 connection to multiple blockchain networks.                                                                                 |
| **Multi-chain support**  | Connect to Bitcoin, Ethereum, BNB Chain, Polygon, Solana, TON, and 100+ other networks. (And we support new protocols before anyone else) |
| **Flexible plans**       | From free access to enterprise-grade solutions, we’ve got options for every stage of your project.                                        |
| **Custom solutions**     | Need something unique? We can build tailored solutions for your specific blockchain needs.                                                |
| **24/7 Expert support**  | Our team is here to help with integrations, troubleshooting, and scaling.                                                                 |

## Discover GetBlock

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><mark style="color:blue;"><strong>Getting Started</strong></mark></td><td>Create your account, explore plans &#x26; features, and make your first API call</td><td></td><td><a href="/files/xWUoQfpc0XaLni2YLMgb">/files/xWUoQfpc0XaLni2YLMgb</a></td><td><a href="/pages/mVgnRqAFZCAbhLhEnSZG">/pages/mVgnRqAFZCAbhLhEnSZG</a></td></tr><tr><td><mark style="color:blue;"><strong>Guides</strong></mark></td><td>Set up endpoints, manage access tokens, and integrate GetBlock APIs step-by-step</td><td></td><td><a href="/files/zlQhfk77YmHREgWyPMp6">/files/zlQhfk77YmHREgWyPMp6</a></td><td><a href="/pages/R4pUHuTKY14ectSvd4TO">/pages/R4pUHuTKY14ectSvd4TO</a></td></tr><tr><td><mark style="color:blue;"><strong>API Reference</strong></mark></td><td>View supported networks, available endpoints, and full API specifications</td><td></td><td><a href="/files/YxptuIB6Qew9b78pWSJX">/files/YxptuIB6Qew9b78pWSJX</a></td><td><a href="/pages/411OdmnFkdjqCUVWSdSO">/pages/411OdmnFkdjqCUVWSdSO</a></td></tr></tbody></table>

## Popular chains

Get started with our most in-demand blockchain networks.

| [<img src="/files/gMsJNoQfWkKzgpysX1q2" alt="" data-size="line">](/api-reference/ethereum-eth) [**Ethereum**](/api-reference/ethereum-eth)                      | [<img src="/files/fTRlK0YynPulf6r8ROek" alt="" data-size="line">](broken://pages/qpv9G2ZjzzyJVbPHk5S0) [**Tron**](broken://pages/qpv9G2ZjzzyJVbPHk5S0)   | [<img src="/files/I6z3clRfGHijS50Vtsmo" alt="" data-size="line">](/api-reference/arbitrum-arb) [**Arbitrum**](/api-reference/arbitrum-arb) |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| [<img src="/files/F66kIpOv6GEbREOxgUw4" alt="" data-size="line">](/api-reference/bnb-smart-chain-bsc) [**BNB Smart Chain**](/api-reference/bnb-smart-chain-bsc) | [<img src="/files/BKJlM7C7P0WqZBNPizh4" alt="" data-size="line">](broken://pages/ZHMjSxoQmr16o5LvhymF) [**Solana**](broken://pages/ZHMjSxoQmr16o5LvhymF) | [<img src="/files/magJuiefWcvVHpY8SNuH" alt="" data-size="line">](/api-reference/optimism-op) [**Optimism**](/api-reference/optimism-op)   |
| [<img src="/files/8LnDjNXKSuUccCWyFdqB" alt="" data-size="line">](/api-reference/polygon-matic) [**Polygon**](/api-reference/polygon-matic)                     | [<img src="/files/HOHD0wP53ft1vSCRx8U0" alt="" data-size="line">](/api-reference/avalanche-avax) [**Avalanche**](/api-reference/avalanche-avax)          | [<img src="/files/PEqA1wJaXK02AhkO0Zxj" alt="" data-size="line">](/api-reference/base) [**Base**](/api-reference/base)                     |


# How to set up an account

To start using GetBlock's services, you need to register for an account. You’ll be ready to go in just a few clicks

### How to Sign Up

{% stepper %}
{% step %}
**Go to GetBlock**

Visit the [homepage](https://getblock.io/) and click on the 'Dashboard' button in the upper-right corner, or use [this direct link](https://account.getblock.io/sign-up).

<figure><img src="/files/A7xUr5hwZ1c8zStGBvO9" alt="How to create an account on GetBlock"><figcaption><p>GetBlock's Sign-Up page, where users can register to access blockchain services</p></figcaption></figure>
{% endstep %}

{% step %}
**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.
  {% endstep %}

{% step %}
**Review and accept policies**

During registration, you will be asked to accept our [Terms of Service](https://getblock.io/terms-of-service/) and [Privacy Policy](https://getblock.io/privacy-policy/).
{% endstep %}
{% endstepper %}

### Access the dashboard

Once you've created an account and signed in, you'll be directed to the GetBlock [**Dashboard**](https://account.getblock.io).&#x20;

* You can create endpoints
* Monitor your usage plan
* Access statistics.

<figure><img src="/files/Z9Fq94lA3AdJQUivVJpS" alt="GetBlock user dashboard for managing blockchain node access"><figcaption><p>GetBlock user Dashboard</p></figcaption></figure>

### Check your User ID

1. Click on your profile icon

<figure><img src="/files/3YwQHV0SonHoFV9w4FAu" alt="profile icon"><figcaption></figcaption></figure>

2. Click on the **Copy** Icon to copy your **User ID**

<figure><img src="/files/2LXniyVHDAYzyCpNvMwa" alt="Where to find the GetBlock user ID"><figcaption></figcaption></figure>


# Team accounts setup

Set up your team account on GetBlock, invite and onboard team members with this step-by-step guide.

A team account is **a shared workspace** **where multiple users can collaborate**. This setup is ideal for companies and teams using GetBlock services.

**Key benefits:**

* **Organized collaboration:** Work together on company resources.
* **Enhanced security:** Role-based access limits each member to only the features they need.
* **Efficient management:** Easily switch between personal and team accounts.

A **team account user** is a regular GetBlock user. When invited to a team, they can work on company resources, manage service plans or team settings, provided the corresponding permissions are granted.

***

### Creating a team account on GetBlock

This part covers a step-by-step guide to setting up your team workspace.

1. Sign in to your GetBlock account. If you don’t have a user account yet, create one following [this guide](/getting-started/how-to-set-up-an-account).
2. Click on the **profile icon** in the bottom-left corner of the sidebar. Select "**Create new team**" from the dropdown menu.

<figure><img src="/files/kItmybm0mNkclcd2Qj5R" alt="How to create a team account on GetBlock"><figcaption></figcaption></figure>

3. A popup window will appear. Assign a team name and click the "**Create team**" button.

<figure><img src="/files/8geS11qm2WUt1FAm4nns" alt="Creating an enterprise account with RPC node provider GetBlock"><figcaption></figcaption></figure>

3. Once the space is created, navigate to **Account Settings** > **Team** to manage team settings or add teammates.

<figure><img src="/files/W3UBGBeVGbN7494ZYWrx" alt="Collaboration feature for GetBlock enterprise users"><figcaption></figcaption></figure>

***

### Adding teammates

The creator of the team account controls who gets invited and manages user roles.

{% hint style="warning" %}
**Limits on GetBlock team accounts:**

* Each user can create up to **3 teams**.
* A user can be invited to an **unlimited number of teams**.
* One team can have a maximum of **30 users.**
  {% endhint %}

You can invite team members to join your team account using either their email address or GetBlock User ID.

* **If the teammate has a GetBlock account**: You can invite them using their **ID**. Since they are already registered, they just need to accept the invitation.
* **If the teammate is not registered on GetBlock**: Invite them via **email** so they can first create an account before joining the team.

{% tabs %}
{% tab title="The teammate has a GetBlock account" %}

1. Go to **Account Settings > Team**.
2. Click **"Add team member"** in the top-right corner.
3. Request the **User ID** from the teammate (they can find it under **Account Settings** > **General**).
4. Enter the name, User I&#x44;**,** and **send the invite**.

<figure><img src="/files/mcyg6W3JMQtKzaqmwcTb" alt="Adding users to the team account on GetBlock"><figcaption></figcaption></figure>

The user gets a notification and can accept the invite.
{% endtab %}

{% tab title="The teammate is not registered on GetBlock" %}

1. Go to **Account Settings > My Team**.
2. Click **"Add team member"** in the top-right corner.
3. Enter the teammate's name and **email address.**
4. Send the invite.

{% hint style="warning" %}
The invite link is valid for 30 minutes. If it expires, please resend an invitation.
{% endhint %}

<figure><img src="/files/F8ScRTmSqXQW7VKacGPk" alt="Inviting teammates to GetBlock&#x27;s team account"><figcaption></figcaption></figure>

The user will receive an invitation email with a link to sign up and join the team.
{% endtab %}
{% endtabs %}

A team member is marked as ![Active](/files/Si6CXUCrAV8zdC9KoIh8) when they have successfully accepted the invitation and joined the team.

If the invitation has been sent but not yet accepted, their status remains ![Pending](/files/oTjPRgnkWTz8GmCy1qyS).

***

### Managing roles & permissions

Once the user has joined, the team owner or an admin can update their permissions:

1. Go to **My Team** in Account Settings.
2. Click the **three-dot menu** (⋮) next to a team member.
3. Select **"Edit access level"**.
4. Assign **permissions**:
   * **Endpoints:** Create and manage node endpoints, access tokens, and view statistics.
   * **Subscriptions & payments:** Handle payments and plans.
   * **Admin:** Includes all the above permissions, plus the access to manage team settings and member roles.
5. Save changes.

<figure><img src="/files/k921inX4pjYzmNVGFB7d" alt="Managing team account user permissions and roles"><figcaption></figcaption></figure>

{% hint style="warning" %}
If a Member has no permissions assigned, they will have **View-Only access** by default.
{% endhint %}

#### **Roles-based permissions**

This table provides a breakdown of actions team account users can perform based on their role.

<table><thead><tr><th width="358.49609375">Action</th><th width="103.0234375" align="center">Owner</th><th width="108.4375" align="center">Admin</th><th align="center">Member</th></tr></thead><tbody><tr><td>Create &#x26; manage access tokens</td><td align="center">✅</td><td align="center">✅</td><td align="center"><a data-footnote-ref href="#user-content-fn-1">🔓</a></td></tr><tr><td>Manage subscriptions &#x26; payments</td><td align="center">✅</td><td align="center">✅</td><td align="center"><a data-footnote-ref href="#user-content-fn-2">🔓</a></td></tr><tr><td>Add &#x26; remove team members</td><td align="center">✅</td><td align="center">✅</td><td align="center">❌</td></tr><tr><td>Edit access levels</td><td align="center">✅</td><td align="center">✅</td><td align="center">❌</td></tr><tr><td>Promote to Admin</td><td align="center">✅</td><td align="center">❌</td><td align="center">❌</td></tr></tbody></table>

{% hint style="success" %}
If you need someone to help manage other team members, be sure to give them **Admin** status.
{% endhint %}

***

### Revoking team access

To remove a user from your team account:

1. Navigate to **Team** in the **Account Settings**.
2. Click the **three-dot menu** (⋮) next to the team member name.
3. Select **"Remove"** from the dropdown menu.

<figure><img src="/files/VvLZWgS5eHy9UDrRydXi" alt="Instructions to remove a team user from the GetBlock team account"><figcaption></figcaption></figure>

{% hint style="success" %}
When removed from a team, users lose access to that team workspace but keep their personal account.
{% endhint %}

***

### How to join a team account

If you’ve been invited to a team on GetBlock, follow these steps to accept the invitation and join the team.

{% tabs %}
{% tab title="Registered on GetBlock" %}
When you have a pending team invitation, a notification badge appears on your account icon <img src="/files/W7VI6Y1VJbrTvuJxdrT5" alt="" data-size="line">.

1. Click your **account icon** to view an invitation.
2. Click **"Accept"** if you're ready to join.

<figure><img src="/files/oWFSGYzrmqL0iuS244DB" alt="How to join a team account on GetBlock"><figcaption></figcaption></figure>

3. After accepting the invitation, you are given access to your team’s workspace. Your [role and permissions](#roles-based-permissions) will be **determined by the team owner or admin**.

<figure><img src="/files/6C8PF9PwpJm92kBcuxEX" alt="Viewing permissions for team account users"><figcaption></figcaption></figure>
{% endtab %}

{% tab title="New to GetBlock" %}
When someone who is not yet registered on GetBlock receives a team invitation, they must first sign up for an account:

1. Check your **inbox** for an email invitation from GetBlock.
2. Clicking the **invitation link** redirects you to the sign-up page.
3. Create a **secure password** for your new account.
4. Check the boxes to agree to the **Terms of Service and Privacy Policy** and complete the registration.

{% hint style="warning" %}
The invite link is **valid for 30 minutes**. If it expires, ask the team **owner** or **admin** to send a new invitation.
{% endhint %}

<figure><img src="/files/4V61vN8ljFhM8jtrt7IV" alt="GetBlock sign-up page"><figcaption></figcaption></figure>

Once registered, you’ll have your personal GetBlock account. Additionally, you gain access to the team’s dashboard and resources based on [permissions](#roles-based-permissions) given by the team owner or admin.

{% hint style="info" %}
**Next steps: Explore GetBlock**

Now that you’ve joined a team, here are a few useful resources to help you get started:

* [**Getting Started** ](/)– Learn more about GetBlock.
* [**Managing Endpoints** ](/getting-started/endpoint-setup)– How to create and manage node endpoints.
* [**Plans & Limits**](/getting-started/plans-and-limits) – Understanding plans and payments.
  {% endhint %}
  {% endtab %}
  {% endtabs %}

***

### **Switching between personal & team accounts**

{% hint style="success" %}
A team user **does not lose** access to their personal account. They can still use and manage their own endpoints and subscriptions.
{% endhint %}

To switch between your personal account and any team accounts you are part of:

* Click the **account icon** in the left panel.
* A dropdown will show all **teams & personal accounts**.
* Switch between them as needed.

<figure><img src="/files/1XLBvWs0ZJXFQq65af5q" alt="Using GetBlock&#x27;s personal and team accounts"><figcaption></figcaption></figure>

The teams list is sorted by recent activity, with the most recently accessed accounts at the top.

***

### **Best practices for team security**

* Regularly review and **audit permissions**. Revoke access for users who are no longer active.
* Grant admin privileges only to **trusted team members**.
* Give Members **only the necessary permissions** (e.g., endpoints access or subscriptions management).
* Never **share login credentials**—use team accounts instead.

***

### **Need help?**

If you run into any issues or have questions, please check out our [FAQ](https://getblock.io/faq/) or visit our [Contact Center](https://getblock.io/contact/). You can also use the **Help** button within your GetBlock dashboard to access support or submit a request.

[^1]: Not enabled by default; must be assigned by an Owner or Admin

[^2]: Not enabled by default, must be assigned by an Owner or Admin


# Access token management

GetBlock uses a secure authentication method based on access tokens to ensure that only authorized users can interact with blockchain nodes.

Every [endpoint](/getting-started/endpoint-setup) you create is assigned a unique access token:

```markup
https://go.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.

{% hint style="info" %}
Access tokens **cannot** **be** **sent** in **headers**.
{% endhint %}

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

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_blockNumber",
    "params": [],
    "id": "getblock.io"
}'
```

Response:

```json
{"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 (![](/files/AMlx63gJ4QN41nifFWGU)) next to the endpoint.
4. Select the option to either **roll** (regenerate) or **delete** the token.

<figure><img src="/files/hVyKUhcuOQY0jX4JK6AR" alt="How to manage GetBlock access tokens"><figcaption><p>Regenerate or delete your access token</p></figcaption></figure>

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


# Plans and limits

GetBlock offers flexible RPC plans and features to support developers and businesses at any stage, from small projects to high-traffic platforms

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

<table data-column-title-hidden data-view="cards"><thead><tr><th>Title</th><th></th><th data-hidden data-card-target data-type="content-ref">Target</th></tr></thead><tbody><tr><td><mark style="color:$primary;">Choosing Your Plan</mark></td><td>Compare Shared Nodes, Limitless Node, and Dedicated Nodes.</td><td><a href="/spaces/FOeg95CadVyFvyLi70Bh/pages/iHxZiz8nc1UlFhebQA9e">/spaces/FOeg95CadVyFvyLi70Bh/pages/iHxZiz8nc1UlFhebQA9e</a></td></tr><tr><td><mark style="color:$primary;">CU and Rate Limits</mark></td><td>GetBlock's Compute Unit (CU) and requests-per-second (RPS) limits across plans.</td><td><a href="/pages/CnDqqWS3NzCn3BWzJiIS">/pages/CnDqqWS3NzCn3BWzJiIS</a></td></tr><tr><td><mark style="color:$primary;">Limitless Node</mark></td><td>Explore the Limitless plan without CU and request limits.</td><td><a href="/pages/zJqkw6KQGW6thdvSyseW">/pages/zJqkw6KQGW6thdvSyseW</a></td></tr><tr><td><mark style="color:$primary;">What counts as a CU?</mark></td><td>Compute Units (CUs) explained.</td><td><a href="/pages/djR6qJbFewD6N5talLM7">/pages/djR6qJbFewD6N5talLM7</a></td></tr><tr><td><mark style="color:$primary;">Top up CUs</mark></td><td>Add more CUs to your active plan.</td><td><a href="/pages/Ns7FI1xrutAYq3FHIB30">/pages/Ns7FI1xrutAYq3FHIB30</a></td></tr><tr><td><mark style="color:$primary;">Dedicated Nodes</mark></td><td>Manage &#x26; extend Dedicated Node subscriptions.</td><td><a href="/pages/udr2z6pv940urtNu3CCK">/pages/udr2z6pv940urtNu3CCK</a></td></tr><tr><td><mark style="color:$primary;">Payment Methods</mark></td><td>Set up billing with fiat or crypto.</td><td><a href="/pages/Pl2Bvmz2D7cotv2tDrqD">/pages/Pl2Bvmz2D7cotv2tDrqD</a></td></tr></tbody></table>


# Choosing your plan

Compare GetBlock's subscription options to find the one that fits your project.

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.

<figure><img src="/files/9tIwQRdB5cFfIAy4Hc8b" alt="GetBlock shared RPC node pricing and plans"><figcaption></figcaption></figure>

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

* **Cost efficiency:** Benefit from our pricing model based on [**Compute Units (CU)**](/getting-started/plans-and-limits/what-counts-as-a-cu), 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.

{% hint style="success" %}
This option is ideal for developers and teams looking for reliable connectivity to various blockchain networks without the higher costs of dedicated server resources.
{% endhint %}

***

### Limitless Node

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.

<figure><img src="/files/O8lO7p90trZIPrIe6TQD" alt="GetBlock&#x27;s blockchain RPC Plan without request limits"><figcaption></figcaption></figure>

* **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.
* **Multi-region geo-routing**: Traffic is routed to the nearest healthy node across Europe, the USA, and Asia.
* **Fixed pricing**: Flat monthly or yearly fee with no usage-based charges.
* **24/7 support**: Priority coverage with a response time under 5 minutes.

{% hint style="success" %}
Limitless Node fits workloads with high but predictable request volumes, where a Shared plan's Compute Unit billing is hard to forecast, but a full Dedicated Node is more than you need.
{% endhint %}

***

### Dedicated Nodes

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.

{% hint style="success" %}
If your project demands the fastest, most reliable blockchain infrastructure, a Dedicated Node from GetBlock is a perfect choice.
{% endhint %}

<figure><img src="/files/tkmU70qml6vzDGdiYAK6" alt="What does it cost to deploy a private blockchain node"><figcaption></figcaption></figure>

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.
* **Fully customizable**: Complete control over your node configurations, including access to archive data.
* **Predictable pricing**:
  * Full Node: from $1,000/month;
  * Archive Node: from $1,500/month.
* **Expert support**: 24/7 coverage and immediate issue resolution.

{% hint style="info" %}
A few **high-resource blockchain** settings (e.g., Solana mainnet, Arbitrum mainnet, NEAR mainnet) may come with **custom pricing** due to their intense infrastructure requirements.
{% endhint %}

***

### Enterprise solutions

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
* Priority assistance from GetBlock experts

Visit the [Enterprise Solutions page](https://getblock.io/enterprise-api/) to learn more about how we tailor services to fit complex, high-demand environments.


# Limitless Node

A dedicated RPC endpoint with guaranteed RPS and no request limits, at a flat monthly price. For Ethereum, Solana, Bitcoin and other Tier-1 blockchains.

**Limitless Node** is a dedicated RPC endpoint with a **guaranteed RPS** and **no Compute Unit (CU) limits**. You pick an RPS tier on a single chain, pay a **fixed monthly fee**, and send as many requests as your throughput allows. There's no usage-based billing and no overage charges.

Architecturally, it's a middle layer between Shared RPS and Dedicated Nodes: more throughput and isolation than a shared plan, at a fraction of the cost of a full private node.

{% hint style="success" %}
Limitless Node is the right fit for applications that generate a high volume of RPC requests and need predictable monthly costs without provisioning a full Dedicated Node. Common use cases include indexers, bots, wallet backends, AI agents, and analytics platforms.
{% endhint %}

***

### What's included

Every Limitless Node includes:

* **Guaranteed requests-per-second (RPS)** throughput with no per-method throttling
* **Unlimited requests** within your RPS tier, no CU-based billing
* **No concurrent connection limits** for parallel workloads
* **No restrictions on RPC method usage**. All standard and heavy RPC methods are supported
* **Full node** and **archive node** configurations for supported chains
* **Isolated capacity** and **dedicated routing** for a single network
* **Multi-region geo-routing** across Europe, the USA, and Asia to minimize latency through geographic proximity
* One instance can have **multiple** [**access tokens**](/getting-started/authentication-with-access-tokens)**,** each a separate credential that can be regenerated or removed independently of the others
* **24/7 customer support** with a response time under 5 minutes
* **Pricing is fixed and predictable** because it is throughput-based rather than usage-based

{% hint style="success" %}
Limitless Node is a standalone product. You don't need an existing Shared or Dedicated plan to use it. You get a fully isolated RPC endpoint from day one.&#x20;
{% endhint %}

***

### Supported chains

One Limitless Node subscription corresponds to one blockchain network. The service is currently available on 11 high-demand blockchains:

<table data-view="cards"><thead><tr><th></th></tr></thead><tbody><tr><td><img src="/files/gMsJNoQfWkKzgpysX1q2" alt="" data-size="line"> Ethereum</td></tr><tr><td><img src="/files/BKJlM7C7P0WqZBNPizh4" alt="" data-size="line"> Solana</td></tr><tr><td><img src="/files/YTeY5jNOhOikDU39dUC6" alt="" data-size="line"> Bitcoin </td></tr><tr><td><img src="/files/PEqA1wJaXK02AhkO0Zxj" alt="" data-size="line"> Base</td></tr><tr><td><img src="/files/SFioQmrRMvsH4T9lqAF1" alt="" data-size="line"> BNB Smart Chain</td></tr><tr><td><img src="/files/fTRlK0YynPulf6r8ROek" alt="" data-size="line"> Tron </td></tr><tr><td><img src="/files/8LnDjNXKSuUccCWyFdqB" alt="" data-size="line"> Polygon</td></tr><tr><td><img src="/files/HOHD0wP53ft1vSCRx8U0" alt="" data-size="line"> Avalanche  </td></tr><tr><td><img src="/files/I6z3clRfGHijS50Vtsmo" alt="" data-size="line"> Arbitrum </td></tr><tr><td><img src="/files/magJuiefWcvVHpY8SNuH" alt="" data-size="line"> Optimism</td></tr><tr><td><img src="/files/QNC2xqOcDOPWefsbZyNn" alt="" data-size="line"> Sui</td></tr></tbody></table>

{% hint style="info" %}
Additional networks may be added over time. If you need a chain that isn't listed yet, a custom RPS ceiling, or multi-region redundancy,[ contact our team](https://getblock.io/contact/).
{% endhint %}

***

### RPS tiers and pricing

Pick the tier that matches your current traffic. Within your RPS cap, requests are unlimited. There is no monthly request quota and no CU metering.

#### EVM Chains, Bitcoin, TRON, Sui - Full and Archive Nodes

{% tabs %}
{% tab title="Full Node" %}

| RPS Tier | Price (monthly) | Requests  |
| -------- | --------------- | --------- |
| 25 RPS   | $150/mo         | Unlimited |
| 50 RPS   | $300/mo         | Unlimited |
| 150 RPS  | $500/mo         | Unlimited |
| 300 RPS  | $1,000/mo       | Unlimited |

Supported networks: Arbitrum, Avalanche, Base, Bitcoin, BNB Smart Chain, Ethereum, Optimism, Polygon, Sui, TRON
{% endtab %}

{% tab title="Archive Node" %}

| RPS Tier | Price (monthly) | Requests  |
| -------- | --------------- | --------- |
| 15 RPS   | $150/mo         | Unlimited |
| 30 RPS   | $300/mo         | Unlimited |
| 50 RPS   | $500/mo         | Unlimited |
| 100 RPS  | $1,000/mo       | Unlimited |

Supported Networks: Arbitrum, Base, BNB Smart Chain, Ethereum, Optimism, Polygon, Sui, TRON
{% endtab %}
{% endtabs %}

#### Solana  - Full Node&#x20;

| RPS Tier | Price (monthly) | Request   |
| -------- | --------------- | --------- |
| 5 RPS    | $150/mo         | Unlimited |
| 15 RPS   | $450/mo         | Unlimited |
| 30 RPS   | $900/mo         | Unlimited |
| 50 RPS   | $1,500/mo       | Unlimited |

Prices shown are for monthly billing. Annual billing saves 20%. You can move between tiers at any time with no lock-in.

{% hint style="warning" %}
Requests above your RPS limit are rate-limited and return a standard rate-limit response. **We do not charge overage fees**. If you consistently reach your limit, consider upgrading to a higher tier.
{% endhint %}

***

### Deploy a Limitless Node

You can configure and launch a Limitless Node from your GetBlock **Dashboard** → **Limitless Nodes.**

1. In your account, open Limitless Nodes and click Create new node.
2. Configure the node:
   1. The blockchain network
   2. Mode - Full or Archiv&#x65;*\**&#x20;
   3. Node location&#x20;
   4. API interface (all supported interfaces included by default)
3. Select an RPS plan
4. Choose a billing term: 1, 6, or 12 months
5. Complete checkout

*\*Not every network offers an archive tier. Check availability in your dashboard first.*

If you need a chain that isn't listed, [contact our team](https://getblock.io/contact/) directly.  We can also recommend a tier based on your workload.

***

#### Next steps

* [Endpoint setup](/getting-started/endpoint-setup)&#x20;
* [Testing RPC connection](/getting-started/testing-rpc-connection)
* [API Reference](/api-reference/overview)
* [Limitless Node Homepage](https://getblock.io/limitless-node/)


# Dedicated nodes: Manage & extend subscriptions

Track and extend your dedicated node subscriptions on GetBlock.

This page explains how to manage your **dedicated node subscriptions**, including checking their status and extending the service duration—all from your user account.

***

### Tracking subscription status

You can monitor the status of your dedicated node subscriptions in three different ways.

#### 1. Dashboard

<figure><img src="/files/p9P2gZiDY3GsD0yjj8P1" alt="tracking the status of dedicated blockchain node subscriptions from GetBlock account"><figcaption></figcaption></figure>

The widget on your dashboard alerts you when your subscription is about to expire or is in a grace period. Click the widget to open a pop-up that lists all nodes that require renewal.

#### 2. Plan manager

<figure><img src="/files/02Z5gOfXRybEgVAQ60T9" alt="How to manage dedicated node plans and subsciriptions from GetBlock&#x27;s user account"><figcaption></figcaption></figure>

The **Manage Plans** section can be found by navigating to the “**Pricing**” option in the left-side menu. You'll see three tabs: click on “**Manage Plans**” to view all your subscriptions in one place.

#### 3. "Endpoints" list

<figure><img src="/files/gTKvaG4tWK6EKs7NdA3v" alt="Checking the status of dedicated node subscriptions from the main GetBlock user dashboard"><figcaption></figcaption></figure>

Each endpoint in “**My endpoints**” list shows its current subscription status.

***

#### Subscription status breakdown

<table><thead><tr><th width="201.48828125" align="center">Status</th><th width="219.43359375" align="center">Dashboard View</th><th align="center" valign="middle">Manage Plans View</th></tr></thead><tbody><tr><td align="center"><p><a data-footnote-ref href="#user-content-fn-1">Active</a></p><p>(<mark style="color:orange;">Recurring Payment)</mark></p></td><td align="center"><img src="/files/5uf5HpRoKauVq3womB0i" alt=""></td><td align="center" valign="middle"><img src="/files/LeXSfeoAx4JOYTgXrSPh" alt=""></td></tr><tr><td align="center"><p><a data-footnote-ref href="#user-content-fn-2">Active</a></p><p>(<mark style="color:green;">One-Time Payment)</mark></p></td><td align="center"><img src="/files/lI8vFCLGNkOiqapTfZWB" alt=""></td><td align="center" valign="middle"><img src="/files/BpDlS4c6unOEZLR8008h" alt=""></td></tr><tr><td align="center"><p><a data-footnote-ref href="#user-content-fn-3">Expiring Soon</a></p><p>(<mark style="color:green;">One-Time Payment</mark>)</p></td><td align="center"><img src="/files/gOWT6G9M14mQlUntvTtu" alt=""></td><td align="center" valign="middle"><img src="/files/1y7Tc82n0MeyFwn9BIJZ" alt=""></td></tr><tr><td align="center"><p><a data-footnote-ref href="#user-content-fn-4">In Grace Period</a></p><p>(<mark style="color:orange;">Recurring</mark> /<mark style="color:green;">One-Time</mark>)</p></td><td align="center"><img src="/files/mfUYh9EDziFrbGFZK3qb" alt=""></td><td align="center" valign="middle"><img src="/files/FYhLgzwU35lZB1b84zga" alt=""></td></tr></tbody></table>

***

### Changing the subscription period

You can modify your subscription period at any time **if you’re on a one-time payment plan** paid with:

* Cryptocurrency;
* Credit car&#x64;**.**

{% hint style="warning" %}
**Note on Recurring Payments**

Users **cannot manually extend a plan** when using recurring payments. These subscriptions renew automatically at the end of a billing cycle.

However, if a payment **fails** (e.g., due to an expired card or insufficient funds), your subscription will enter a **3-day grace period**. During this time, your node remains active, allowing you to **update your payment details and retry the renewal** before the service is interrupted.
{% endhint %}

#### Available options

You can extend your subscription to one of the following periods:

* 1 month
* 6 months
* 12 months

***

### How to extend your Dedicated Node plan

There are three ways to extend your subscription.

#### Option 1: The Dedicated Nodes dashboard

1. Go to **Dedicated Nodes** tab from your dashboar&#x64;**.** Look for the subscription alert widget.

<figure><img src="/files/vHaVWNfVJ55OMUJnw1ys" alt="How to manage node subscriptions from the GetBlock dashboard"><figcaption></figcaption></figure>

2. Click the widget to see a list of nodes needing renewal and choose one. A pop-up will show extension options (**1**, **6**, or **12 months**).

<figure><img src="/files/Y1GAunMkFL6lfmxDJ3lm" alt="How to extend dedicated node plan using GetBlock"><figcaption></figcaption></figure>

2. **Choose a new period** and review details. Proceed to checkout.
3. Complete the payment by following the instructions provided.
4. Check the "**Payment History**" under the **Pricing** tab to track the progress.

#### Video guide

{% tabs %}
{% tab title="Fiat payments" %}
**For fiat (credit card) payments:**

* Payments are processed via **Paddle**.
* **VAT may apply** depending on the user's location.
* The extension is applied **instantly** once the payment is completed.

{% embed url="<https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFOeg95CadVyFvyLi70Bh%2Fuploads%2F8pIYDgoi9y0CC2FAKCOb%2FExtendingDedicNodes_Widget_Paddle.mp4?alt=media&token=e5db1173-11ce-43a7-9ca0-af3de0a6e62c>" %}
How to extend your node subscription with a card payment
{% endembed %}
{% endtab %}

{% tab title="Cryptocurrency payments" %}
**For crypto payments**:

* Payments are processed via **NOWPayments**.
* Make sure to account for **network fees** to avoid payment issues.
* The extension is applied **after blockchain confirmation**, which may take a few minutes.

{% embed url="<https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFOeg95CadVyFvyLi70Bh%2Fuploads%2FakJE50bGOIdiyyIyo61n%2FExtending_nodes_CryptoPayments.mp4?alt=media&token=f539d7e3-d430-4665-a39c-d09f7a6f1ce9>" fullWidth="false" %}
{% endtab %}
{% endtabs %}

#### Option 2: From “Endpoints” list

1. Navigate to your main dashboard and switch to the **Dedicated Nodes** tab.
2. **Choose a node to extend.** Expand the node’s details and click **"Extend"** to begin the process.
3. Follow the pop-up instructions to select the **new subscription period** and finalize the process.

<figure><img src="/files/RsqaBhaSDk7aMeXsRYDx" alt="Managing RPC node subscriptions from the main dashboard&#x27;s endpoints list"><figcaption></figcaption></figure>

#### Option 3: Via the "Manage Plans" menu

1. Navigate to **Pricing > Manage Plans**.
2. **Review all subscriptions**. Subscriptions nearing expiration are listed at the top.
3. **Follow the same steps:** Select your node, choose a new period, and confirm your payment.

<figure><img src="/files/butcYG5XnDue5If8KD51" alt="Flexible dedicated RPC node plan subscription"><figcaption></figcaption></figure>

***

### How to keep your Dedicated Node running smoothly

* [ ] **Keep an eye on your subscription.** Check your dashboard or plan manager to track expiration dates. Status tracking is now easier with our latest updates.
* [ ] Avoid disruptions by **renewing before your subscription ends**. This ensures your node remains active and accessible without downtime.
* [ ] For **recurring payments**, ensure your card information is up to date. Payment failures (e.g., expired card) can interrupt service.

If you face any issues with renewal or extensions, feel free to reach out to GetBlock support—we’re happy to assist.

[^1]: Your node subscription renews automatically at the end of each billing cycle using a saved payment method.

[^2]: The node is active under a one-time payment plan and will not renew automatically. To continue using the service, you’ll need to manually extend the subscription before it expires.

[^3]: The subscription will expire soon (within 3 days). Renewal is required.

[^4]: After the subscription expires, there is a 3-day grace period where the node remains active. During this time, you can renew your subscription or resolve payment issues (update billing details).


# CU and rate limits

GetBlock provides access to over 100 blockchains. CU and rate limits depend on the selected plan.

This guide explains how limits work across all available plans, helping you understand what’s included and how to choose the option that best fits your current workload and future growth.

{% hint style="success" %}

* **Shared Nodes** operate on a system of limits defined by Compute Units (**CUs**) and Requests Per Second (**RPS**). Each plan also determines how many endpoints you can use simultaneously.
* **Limitless Node** has no CU limits - only an RPS limit.
* With **Dedicated Nodes**, you’re not limited by CUs or RPS.
  {% endhint %}

***

### Shared node limits

GetBlock’s shared node service is subject to several usage limits. These are the key limits that directly affect costs and performance:

* [**CU (Compute Units)**](/getting-started/plans-and-limits/what-counts-as-a-cu): Measures the computational effort required to process requests. Different shared node plans include a varying number of CUs that you can use in a month.
* **RPS (Requests Per Second)**: Each plan enforces a maximum number of requests you can send every second. While you’re not billed per request, staying within this limit is critical to maintaining optimal service quality.
* [**Access Tokens**](/getting-started/authentication-with-access-tokens)**:** Access tokens are unique identifiers used to authenticate your connection to GetBlock’s node infrastructure, generated when you create an endpoint. The limitation on your plan determines how many of these access tokens (and therefore endpoints) you can create.

<table data-search="false"><thead><tr><th>Plan</th><th width="129.24566650390625">Price (monthly)</th><th width="120.96441650390625">CU Allocation</th><th width="105.6171875">RPS Limit</th><th width="133.4599609375">Access Tokens (Endpoints)</th><th width="102.822021484375" data-type="checkbox">CU Top-ups</th></tr></thead><tbody><tr><td>Free</td><td>$0</td><td>50,000 / day</td><td>20 RPS</td><td>2</td><td>false</td></tr><tr><td>Starter</td><td>$49</td><td>90M / mo</td><td>250 RPS</td><td>30</td><td>true</td></tr><tr><td>Growth</td><td>$99</td><td>185M / mo</td><td>300 RPS</td><td>45</td><td>true</td></tr><tr><td>Advanced</td><td>$199</td><td>385M / mo</td><td>450 RPS</td><td>75</td><td>true</td></tr><tr><td>Scale</td><td>$349</td><td>700M / mo</td><td>600 RPS</td><td>105</td><td>true</td></tr><tr><td>Pro</td><td>$499</td><td>1B / mo</td><td>800 RPS</td><td>150</td><td>true</td></tr><tr><td>Premium</td><td>$699</td><td>1.6B / mo</td><td>800 RPS</td><td>225</td><td>true</td></tr><tr><td>Enterprise</td><td>from $999</td><td>Custom</td><td>Custom</td><td>Custom</td><td>true</td></tr></tbody></table>

Check <https://getblock.io/pricing/> for current pricing and annual discounts across all tiers.

{% hint style="info" %}
Your **balance of CUs for Shared Nodes** is distributed on **all endpoints** added under the ‘Shared nodes’ tab.
{% endhint %}

{% tabs %}
{% tab title="Free" %}
The plan is ideal if you’re **just starting out** and do not have complex calls or large request volumes.

<figure><img src="/files/8mZNbqMDhJ0YPPb9UIbG" alt="GetBlock&#x27;s free RPC node plan limits"><figcaption></figcaption></figure>

* **CU**: 50,000/day
* **Throughput**: 20 requests per second (RPS)
* **Access Tokens**: 2

{% hint style="warning" %}
**Compute Units** are **renewed daily**, but unused CUs cannot be transferred to the next day.
{% endhint %}

To increase usage limits, choose between the higher-tier options.
{% endtab %}

{% tab title="Starter" %}
For use cases that are growing beyond the free tier — a first production app or side project. Offers a **significant increase in CU** and **RPS** compared to the Free plan.&#x20;

<figure><img src="/files/aOTtNor6NQnMAioHc64W" alt="Starter plan limits for Shared RPC nodes by GetBlock"><figcaption></figcaption></figure>

* **CU**: 90M per month (\~3M/day)
* **Throughput**: 250 requests per second (RPS)
* **Access Tokens**: 30
* Additional CU packages can be purchased as needed.
  {% endtab %}

{% tab title="Growth" %}
For apps with a growing user base: higher daily call volumes and room for several services or environments at once.

<figure><img src="/files/VoT39loJZt757HZgCLkw" alt="GetBlock &#x22;Growth&#x22; RPC plan limits"><figcaption></figcaption></figure>

* **CU**: 185M per month (\~6.2M/day)
* **Throughput**: 300 requests per second (RPS)
* **Access Tokens**: 45
* Additional CU packages can be purchased as needed.
  {% endtab %}

{% tab title="Advanced" %}
**Mid-to-upper tier, production-ready** plan, suitable for moderate-to-high traffic applications.

<figure><img src="/files/pFZj1LpcZQVdYDkqM04A" alt="GetBlock Advanced plan CU limits and RPS limits"><figcaption></figcaption></figure>

* **CU**: 385M per month (\~12.8M/day)
* **Throughput**: 450 requests per second (RPS)
* **Access Tokens**: 75
* Add extra compute units (CU) to your account balance when needed without switching plans
  {% endtab %}

{% tab title="Scale" %}
For larger apps and teams. More CU headroom and endpoints to run many services or environments from one account.

<figure><img src="/files/4h04UymtJHKMk1f80DIv" alt="GetBlock&#x27;s &#x22;Scale&#x22; RPC node plan limits - Compute Units (CUs) and requests-per-second"><figcaption></figcaption></figure>

* **CU**: 700M per month (\~23.3M/day)
* **Throughput**: 600 requests per second (RPS)
* **Access** **Tokens**: 105
* Extra CU packages also available
  {% endtab %}

{% tab title="Pro" %}
For applications that need significantly **higher throughput** and **increased resource availability** compared to lower tier plans.

<figure><img src="/files/wgvOGLPu4i3JfNVLmomd" alt="GetBlock&#x27;s &#x22;Pro&#x22; subscription plan CU allowance and rate limits"><figcaption></figcaption></figure>

* **CU**: 1B per month (\~33.3M/day)
* **Throughput**: 800 requests per second (RPS)
* **Access Tokens**: 150
* Purchase additional CU packages when required
  {% endtab %}

{% tab title="Premium" %}
**Highest** standard tier before custom Enterprise terms. Built for sustained high-volume production traffic.

<figure><img src="/files/hQW3Y3Ne10gJqlHXYAVj" alt="GetBlock&#x27;s RPC plan with highest request and RPS limits - &#x22;Premium&#x22;"><figcaption></figcaption></figure>

* **CU**: 1.6B per month (\~53.3M/day)
* **Throughput**: 800 requests per second (RPS)
* **Access Tokens**: 225
* CU top-ups available
  {% endtab %}

{% tab title="Enterprise" %}
**Fully customizable** with tailored CU allocations, rate limits, and access tokens to meet exceptionally high call volumes and performance requirements.

<figure><img src="/files/ED4eyGfM7bfjVe3MUhRs" alt="GetBlock&#x27;s Enterprise plan with custom usage limit settings"><figcaption></figcaption></figure>

* **CU**: Custom monthly allocation based on your demands
* **Throughput**: Custom
* **Access Tokens**: Custom
* Additional CU packages can be purchased on demand
  {% endtab %}
  {% endtabs %}

***

#### Managing unused & extra CUs

Your monthly plan CUs (main balance) are **valid for the current billing cycle** only. The balance **is reset** when your subscription renews. Main-balance CUs don't carry over.

Extra CUs (extra balance) — anything on top of your plan allocation — do **carry over to the next month**, as long as your subscription stays active and renews on time.

{% hint style="success" %}
If your demand exceeds the included limits, you can **purchase extra CU packages**. This means that even within a given plan, there’s room for scaling without an immediate need to move to a higher tier.

* [Top up CUs and boost limits](/getting-started/plans-and-limits/top-up-cus-and-boost-limits)
  {% endhint %}

***

### Limitless node limits

Limitless Node removes Compute Unit limits entirely. You can send unlimited requests within the RPS tier you choose.

<figure><img src="/files/4o0NpUceZPfuJEaxSJki" alt="GetBlock&#x27;s Limitless Node with fixed RPS and unlimited requests"><figcaption></figcaption></figure>

* **CU**: No limit&#x20;
* **Rate limit**: Capped at selected RPS tier

{% hint style="info" %}
See [Limitless Node](/getting-started/plans-and-limits/limitless-node) for tiers, supported chains, and setup.
{% endhint %}

***

### Dedicated node limits

Our Dedicated Node service is perfect for teams and projects that demand absolute freedom from rate limits and CU monitoring.

<figure><img src="/files/ssghd4RcFuMt41sF8tX3" alt="Dedicated node for scalable and unlimited RPC node access"><figcaption></figcaption></figure>

* **CU**: Unlimited
* **Rate limit**: Unlimited

***

If you’re unsure which plan best fits your needs, our team is ready to help! [Contact our support team](https://getblock.io/contact/) or visit our [Choosing your plan](/getting-started/plans-and-limits/choosing-your-plan) page for more information.


# What counts as a CU

Learn what Compute Units (CUs) are and how GetBlock calculates them to track and price API calls

In our **Shared Node** plans, we use **CU-based pricing**. **CUs, Compute Units,** is a way to measure the computational resources that each API request consumes.

{% hint style="info" %}

#### Request vs CU

**Requests** are the raw number of calls (e.g., an RPC method call) you make to the node, while **Compute Units** show how much computing power each call uses.
{% endhint %}

Instead of charging a fixed fee for every call, GetBlock calculates the “cost” of processing a request based on **the actual computational work involved** – such as CPU & memory usage, and disk I/O.

Here's how it works:

* Different shared node plans include different allocations of Compute Units (CUs)
* Each API call deducts an amount based on the resources it consumes
* Users can track their remaining CUs in real time on the dashboard

<figure><img src="/files/koaP376V4kQTrPFXSnL5" alt="How to check your CU balance in GetBlock accounts"><figcaption></figcaption></figure>

This model ensures costs are aligned with actual infrastructure usage.

{% hint style="info" %}
**Learn More**

* [CU and rate limits](/getting-started/plans-and-limits/cu-and-rate-limits) — Check how many CUs are included in each plan.
  {% endhint %}

***

### How CUs are calculated

Every API call "spends" a number of Compute Units. The total value is determined by three main factors:

1. **Base CU cost** (chain multiplier) reflecting the network's resource intensity
2. **Method-specific multiplier** which varies by API method
3. **Archive Modifier** applied when a request is served by an archive node

The total Compute Units for an API call are calculated using the following formula:

$$
\text{Total CU} = \text{Chain Multiplier} \times \text{Method Multiplier} \times \text{Archive Modifier}
$$

Where:

* **Archive Modifier = 1** for standard full-node requests
* **Archive Modifier = 2** for requests served by archive endpoint

***

#### 1. Chain-based multipliers

Not all blockchains are built or operate the same way. GetBlock accounts for inherent differences between networks by assigning **chain multipliers** based on factors such as:

* Protocol complexity and the size of the blockchain data
* Node infrastructure costs
* Operational overhead

Here’s how blockchains are grouped based on their average resource intensity:

<table><thead><tr><th width="456.10504150390625" align="center">Chains</th><th align="center">Multiplier</th></tr></thead><tbody><tr><td align="center">Algorand, Bitcoin, Bitcoin Cash, Dash, Dogecoin, Ethereum Classic, Litecoin, Near, Rootstock, Sonic,Telos, Zcash, <em>others</em></td><td align="center">10</td></tr><tr><td align="center">Aptos, Arbitrum, Avalanche, BNB Smart Chain, Base, Blast, Cosmos, Cronos, Ethereum, Flow, Gnosis, Harmony, Kaia, Linea, OKT, Optimism, Polygon, Polygon zkEVM, Tezos, Tron, XRP, opBNB</td><td align="center">20</td></tr><tr><td align="center">Allora, Avail, Bahamut, Chiliz, Zilliqa, Xphere</td><td align="center">30</td></tr><tr><td align="center">0g, Akash, Atleta, Berachain, Bitlayer, Botanix, Cardano, Core, Cronos zkEVM, Etherlink, Flare, Goat, Gravity, IOTA, IOTA EVM, Immutable zkEVM, Matchain, Metis, Midnight, Monad, Movement, Nervos, Oasis, Rollux, Siacoin, Solana, Somnia, Soneium, Stacks, Stellar, Swellchain, TON, Taiko, Tenet, XDC, Xai, Zora</td><td align="center">50</td></tr><tr><td align="center">Kusama, Polkadot</td><td align="center">60</td></tr><tr><td align="center">ZKsync</td><td align="center">80</td></tr><tr><td align="center">Arbitrum Nova, Celo, Corn, Ink, Lens, Scroll, Shiba Inu, StarkNet, Sui, TAC, Unichain</td><td align="center">100</td></tr><tr><td align="center">Filecoin</td><td align="center">140</td></tr><tr><td align="center">Ronin</td><td align="center">180</td></tr><tr><td align="center">B3, Electroneum, Incentiv</td><td align="center">200</td></tr><tr><td align="center">Moonbeam, Sei</td><td align="center">300</td></tr></tbody></table>

***

#### 2. Method-specific multipliers

Different API methods **put different loads on backend nodes**. For example:

* <mark style="color:green;">`eth_blockNumber`</mark> is lightweight since it just returns the latest block number.
* <mark style="color:green;">`trace_replayBlockTransactions`</mark> executes a full replay of all txs in a block and can be extremely heavy.

Therefore, individual blockchain methods have their own multipliers, depending on how computationally demanding each particular operation is.

The example table below shows some Ethereum blockchain methods with their associated multipliers and total CU calculated **for the full node queries**.

<table><thead><tr><th width="271.0625">Ethereum RPC Method</th><th align="center">Method Multiplier</th><th align="center">Base Chain Multiplier</th><th align="center">Total CU</th></tr></thead><tbody><tr><td><code>eth_blockNumber</code></td><td align="center">1</td><td align="center">20</td><td align="center">20</td></tr><tr><td><code>eth_getTransactionByHash</code></td><td align="center">1</td><td align="center">20</td><td align="center">20</td></tr><tr><td><code>debug_traceTransaction</code></td><td align="center">2</td><td align="center">20</td><td align="center">40</td></tr><tr><td><code>debug_traceBlock</code></td><td align="center">2</td><td align="center">20</td><td align="center">40</td></tr><tr><td><code>trace_call</code></td><td align="center">2</td><td align="center">20</td><td align="center">40</td></tr><tr><td><code>trace_transaction</code></td><td align="center">2</td><td align="center">20</td><td align="center">40</td></tr><tr><td><code>txpool_status</code></td><td align="center">2</td><td align="center">20</td><td align="center">40</td></tr><tr><td><code>trace_replayTransaction</code></td><td align="center">4</td><td align="center">20</td><td align="center">80</td></tr></tbody></table>

> Calculation example for <mark style="color:green;">`debug_traceTransaction`</mark>:\
> \
> $$20\ (\text{Ethereum base multiplier}) \times 2\ (\text{method multiplier}) = \mathbf{40\ CU}$$

For full details on all methods - including exact multipliers and total CU values for each protocol - please refer to our [Compute Units page](https://getblock.io/pricing/compute-units/).

***

#### 3. Archive modifier

GetBlock Shared Node endpoints can be configured in [Archive Mode](/getting-started/endpoint-setup/enabling-archive-mode) to provide historical state access from managed archive nodes.&#x20;

To reflect the heavier load on node infrastructure, requests to these endpoints use an Archive Modifier of 2 applied on top of an existing method multiplier.

*Example:* Ethereum (chain multiplier = 20), `debug_traceTransaction` (method multiplier = 2):

* Regular full-node request: `20 × 2 × 1 = 40 CU`
* Archive-mode request: `20 × 2 × 2 = 80 CU` (archive modifier applied)

The table below shows CU costs for some Ethereum RPC methods when requests are sent to an archive-enabled endpoint (Archive Modifier = 2).

<table data-full-width="false"><thead><tr><th width="231.4617919921875">Ethereum RPC Method</th><th width="109.1995849609375" align="right">Method Multiplier</th><th width="109.8236083984375" align="right">Base Chain Multiplier</th><th width="102.37060546875" align="right">Archive Modifier</th><th width="111.1553955078125" align="right">Total CU (Archive Endpoint)</th></tr></thead><tbody><tr><td><code>eth_blockNumber</code></td><td align="right">1</td><td align="right">20</td><td align="right">2</td><td align="right">40</td></tr><tr><td><code>eth_getTransactionByHash</code></td><td align="right">1</td><td align="right">20</td><td align="right">2</td><td align="right">40</td></tr><tr><td><code>debug_traceTransaction</code></td><td align="right">2</td><td align="right">20</td><td align="right">2</td><td align="right">80</td></tr><tr><td><code>debug_traceBlock</code></td><td align="right">2</td><td align="right">20</td><td align="right">2</td><td align="right">80</td></tr><tr><td><code>trace_call</code></td><td align="right">2</td><td align="right">20</td><td align="right">2</td><td align="right">80</td></tr><tr><td><code>trace_transaction</code></td><td align="right">2</td><td align="right">20</td><td align="right">2</td><td align="right">80</td></tr><tr><td><code>txpool_status</code></td><td align="right">2</td><td align="right">20</td><td align="right">2</td><td align="right">80</td></tr><tr><td><code>trace_replayTransaction</code></td><td align="right">4</td><td align="right">20</td><td align="right">2</td><td align="right">160</td></tr></tbody></table>

{% hint style="info" %}

#### The Archive Modifier is applied to all requests sent to an archive-enabled endpoint.

If a request is routed to an archive endpoint, the Archive Modifier = 2, even if the specific method does not require historical state.

Requests sent to full node endpoints use Archive Modifier = 1.
{% endhint %}

*The tables above includes selected RPC methods for illustration purposes. The complete list of all CU costs is maintained on the* [*Compute Units page*](https://getblock.io/pricing/compute-units/)*.*&#x20;

***

### Why we use the CU system at GetBlock?

#### 🛡️ **It helps keep infrastructure stable**

Tracking and pricing requests based on how “heavy” they are:

* Discourages abuse (like hammering archive calls) and protects node performance & uptime.
* Makes it easier for GetBlock to scale and optimize resources behind the scenes.

#### 💰 **Compute Units provide a fair, usage-based billing model**

A simple per-request pricing model would charge the same for all methods, which isn’t scalable or logical. The CU model fixes this imbalance.

#### ⚙️ To h**elp developers build smarter**

Because each API call has a clear CU cost, you can spot inefficiencies quickly (e.g. which parts of your dApp consume the most), making it easier to fine-tune performance.


# Top up CUs and boost limits

GetBlock users can top up their CU balance or upgrade to higher limits directly from their Dashboard, with a few click.

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.

***

### Add Compute Units: Paid plan users

<figure><img src="/files/74xHqCtx0V0Zdhp8GjKW" alt="topping up GetBlock CU balance"><figcaption></figcaption></figure>

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

1. Click the "**Top Up**" button on the **Dashboard**.
2. Select the **number of CUs** you’d like to add or choose the recommended plan (if prompted) based on your usage needs.
3. **Confirm** and finalize your purchase.

<figure><img src="/files/LjQxNUd91ZpFN18ngx8m" alt="How to add CU to your GetBlock RPC node package balance"><figcaption></figcaption></figure>

Your account balance will be updated immediately upon successful payment.

***

### **Increase CU limits: Free plan users**

Free plan users **cannot top up their Compute Units directly**. Instead, you have the option to upgrade to one of our monthly paid plans, providing significantly higher limits and extra features.

<figure><img src="/files/nQRBZCyeThQz99OQTYx0" alt="Switching from free GetBlock plan to higher limit plans"><figcaption></figcaption></figure>

***

### Boost CU, RPS, and Access Token limits

If you're on the **Enterprise** plan (our customizable Shared Node plan), you can additionally request **higher RPS** and **Access Token limits**. Here’s how:

1. Click "**Change**" on the Dashboard next to the **Rate Limit** section.

<figure><img src="/files/3IDl0haXPxxzJz928Hib" alt="Increasing RPC node limits"><figcaption></figcaption></figure>

2. Fill out and submit a **request form**, choosing your desired RPS limit, CU amount, and number of Access Tokens.

<figure><img src="/files/ebGVh5T4GiFUZHRCsgeq" alt="Customizing GetBlock&#x27;s Enterprise plan usage limits"><figcaption></figcaption></figure>

3. Our team will review your request and reach out to you with next steps shortly.

{% hint style="success" %}
This feature is perfect for users who need higher transaction throughput without changing their plan. For more demanding needs, consider [Dedicated Nodes](https://getblock.io/dedicated-nodes/).
{% endhint %}


# Payment methods

GetBlock supports both fiat and crypto payments.

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

<figure><img src="/files/POwQpYrLhKCBhUUXIbO8" alt="How to pay with fiat on GetBlock"><figcaption><p>Selecting fiat as a payment method</p></figcaption></figure>

{% hint style="warning" %}
Please, account for VAT when planning your payments.
{% endhint %}

***

#### Updating your payment details

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.

<figure><img src="/files/cD1QC5GjzR1RBmzLN7YS" alt="changing billing data in GetBlock accounts"><figcaption></figcaption></figure>

***

### Crypto payments

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.

<figure><img src="/files/KjhnBo6jd4MpnqpBRIYX" alt="How to pay for RPC nodes with crypto"><figcaption><p>Crypto payments</p></figcaption></figure>

{% hint style="warning" %}
If the network fees are insufficient or the transaction fails, the payment will not be processed and the subscription plan will not be activated. **Please, include enough gas fees to ensure the transaction processes successfully**.
{% endhint %}


# Endpoint setup

Configure, set up and manage blockchain node endpoints with GetBlock.

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

{% columns %}
{% column %}
{% content-ref url="/pages/JaAw7joQ9T6nTnJkXqmj" %}
[Creating node endpoints](/getting-started/endpoint-setup/creating-node-endpoints)
{% endcontent-ref %}
{% endcolumn %}

{% column %}
{% content-ref url="/pages/Wy30Ft4zhAT3CLa3JEhY" %}
[Enabling archive mode](/getting-started/endpoint-setup/enabling-archive-mode)
{% endcontent-ref %}
{% endcolumn %}
{% endcolumns %}

{% columns %}
{% column %}
{% content-ref url="/pages/XykvLPG3GAguEFp4CjCC" %}
[Configuring dedicated nodes](/getting-started/endpoint-setup/configuring-dedicated-nodes)
{% endcontent-ref %}
{% endcolumn %}

{% column %}
{% content-ref url="/pages/uCy0HoYoBe8bVkmLBMeF" %}
[Using GetBlock configuration files](/getting-started/endpoint-setup/using-getblock-configuration-files)
{% endcontent-ref %}
{% endcolumn %}
{% endcolumns %}


# Creating node endpoints

Follow the steps below to set up an endpoint and generate access tokens for your project.

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.

{% hint style="success" %}
In GetBlock, an *endpoint URL* includes your unique **Access Token** — the credential that authenticates RPC requests. GetBlock’s UI sometimes labels the whole endpoint provisioning flow “Get Access Token” because a new RPC URL is created together with the token.

Related:

* [Access token management](/getting-started/authentication-with-access-tokens)
* [GetBlock Deploys Major Security Upgrade: Introducing Access Tokens](https://getblock.io/blog/getblock-deploys-major-security-upgrade-introducing-access-tokens/)
  {% endhint %}

***

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

{% stepper %}
{% step %}
Log in to your GetBlock account and navigate to the **Dashboard**
{% endstep %}

{% step %}
Find the **Endpoints** section on the Dashboard
{% endstep %}

{% step %}
Click **Get endpoint** to open the endpoint setup menu

<figure><img src="/files/XJy1ecljbs82vXL4jsxG" alt="GetBlock RPC endpoint setup interface"><figcaption></figcaption></figure>
{% endstep %}

{% step %}
In the modal that opens, select:

* The desired blockchain **protocol** (Ethereum, BNB Chain, Polygon, etc.)
* The **network** you want to interact with: mainnet or testnet
* Node **mode:** full (default) or archive
* The **API** interface that you need (JSON-RPC, WebSockets, GraphQL, etc.)
* One of the available server **locations** (Frankfurt, New York, or Singapore)

<figure><img src="/files/8hEmvkS3RnWI3iXVCPV9" alt="How to create a node endpoint for blockchain API access"><figcaption></figcaption></figure>
{% endstep %}

{% step %}
Click 'Get' and have the endpoint URL with an access token generated.
{% endstep %}
{% endstepper %}

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.

{% hint style="info" %}
All GetBlock endpoints follow a predictable format. The visible difference is the hostname reflecting the region selected during the setup.

**Endpoint examples**:

```markup
EU (Frankfurt):   https://go.getblock.io/<ACCESS_TOKEN>/
US (New York):    https://go.getblock.us/<ACCESS_TOKEN>/
Asia (Singapore): https://go.getblock.asia/<ACCESS_TOKEN>/
```

The token encodes the protocol, networks, and routing on the server — clients don’t need to specify a chain in the URL.
{% endhint %}

***

### Full vs Archive mode

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.

{% hint style="info" %}
Selecting the Archive mode for an endpoint changes how requests are billed in Compute Units (CU). Learn more in the [Archive mode guide](/getting-started/endpoint-setup/enabling-archive-mode).
{% endhint %}

***

### Viewing and managing endpoints

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

<figure><img src="/files/NQfXmLQFpsMIL6Y2THvu" alt="Blockchain RPC nodes list within the GetBlock account"><figcaption></figcaption></figure>

{% hint style="warning" %}
Because the Access Token is embedded, **the URL is the credential**. Keep it secret and store securely. If the URL is exposed, regenerate or revoke it from your GetBlock account.
{% endhint %}


# Enabling archive mode

Enable Archive Mode on your GetBlock Shared Node API to access the full blockchain history and run historical queries

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 [`eth_getBalance`](broken://pages/OvREWedjZcQXOfAINKFw)`(address, blockNumber)`, [`eth_getStorageAt`](broken://pages/Z0x91Xd7rpVHeey1bVlX)`(contract, slot, blockNumber)`, [`eth_getCode`](broken://pages/7DySAS1tp87clonhiSNK)`(address, blockNumber)`, etc.
* Call view functions against historical state: e.g. [`eth_call`](broken://pages/wdvTR5ND1nsYC5wFdcMi)`(..., 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 mode availability & coverage

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 ( <img src="/files/vHlQIWlk4BmghSpqJ2Yh" alt="history/clock icon" data-size="original"> ) when picking a protocol during the [endpoint setup](/getting-started/endpoint-setup/creating-node-endpoints). It indicates that Archive mode is available for that blockchain.

<figure><img src="/files/SFNzvTrak0DXkMcykOld" alt="Archive blockchain data access via GetBlock RPC endpoints"><figcaption></figcaption></figure>

{% hint style="success" %}
If you need an archive data for a chain not covered by shared Archive mode, request a [Dedicated Node](/getting-started/endpoint-setup/configuring-dedicated-nodes). **Dedicated Nodes** can be deployed in archive mode for **any supported blockchain** and come with additional benefits like:

1. Full blockchain history at the highest throughput
2. Unlimited query capacity
3. Custom node builds & tooling
   {% endhint %}

***

### How to enable the Archive mode

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.

<figure><img src="/files/yRCMZAsEm1cxecK9uhKO" alt="Get RPC endpoint button on GetBlock&#x27;s dashboard"><figcaption></figcaption></figure>

3. Find the Mode toggle and switch the **Archive** **mode** on.

<figure><img src="/files/MVsNLqc9fDVDrrMSN3Oo" alt=""><figcaption></figcaption></figure>

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

***

### CU billing for Shared Archive endpoints

Archive endpoints usage remains subject to your plan’s [CU limits and performance characteristics](https://docs.getblock.io/getting-started/plans-and-limits/cu-and-rate-limits).

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 [Compute Units](https://getblock.io/pricing/compute-units/) 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.

***

### Best practices

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

***

#### 💬 Need help with archive blockchain data?

[Tell us](https://getblock.io/contact/) what you’re building — our team can guide you to the most efficient archive node setup.


# Configuring dedicated nodes

Deploy dedicated nodes from your GetBlock Dashboard. Fully self-service. This guide covers customizing your node settings and completing the setup process.

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

<figure><img src="/files/vsxh7ihkhP3TAozMzrVm" alt="How to set up a private blockchain node with GetBlock"><figcaption></figcaption></figure>

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.

### Step 1: Configure your node

<figure><img src="/files/iJJmVkA5tVF4vBEaz8yK" alt="GetBlock dedicated node configuration tool"><figcaption></figcaption></figure>

In the setup window:

1. Select the blockchain protocol and the network type (e.g., mainnet, testnet, devnet, etc)
2. Customize your dedicated node with the following options:
   1. **Node type**: Choose between Full Node or Archive Node
   2. **Pick a deployment location**: Germany (Frankfurt), USA (New York), Singapore
   3. **Node client**: Choose your preferred node implementation (e.g., Geth)
   4. **API interface**: Review available interface types
3. Under the **Performance** section, select a [performance tier](/getting-started/endpoint-setup/configuring-dedicated-nodes/dedicated-node-performance-tiers):
   1. **High**: premium specs, max throughput
   2. **Standard**: enterprise specs, optimized pricing for moderate-high loads
4. Choose a subscription length — 1, 6, or 12 months — at the top of the summary panel (available discounts are applied automatically)

Verify all selected configurations in the summary section and proceed to the next step.

### Step 2: Select add-ons

On the **Add-ons** screen, you can extend your node with additional capabilities:

* **Included add-ons** are available at no extra cost depending on your configuration
* **Advanced add-ons** are billed in addition to the base node price

<figure><img src="/files/JSlDDiBcbXH3qriR9JDF" alt="GetBlock Dedicated RPC node add-ons "><figcaption></figcaption></figure>

Select any add-ons you need and click **Next**.

### Step 3: Payment

<figure><img src="/files/ac6nA7oslQQ4ONk2NbIa" alt="GetBlock private blockchain server ordering"><figcaption></figcaption></figure>

On the final screen:

1. **Review** the final pricing and node settings
2. **Billing Contact** — Enter your contact information so the GetBlock team can notify you when your node is ready.&#x20;
3. **Payment method** — Choose between **Credit Card** or **Crypto**.
4. **Subscription** — Enable the subscription toggle if you want to ensure your node renews automatically each billing cycle.
5. When ready, click **Go to Payment**.

Once payment is confirmed, the deployment status will be visible on your Dashboard → Dedicated Nodes tab and Pricing → Manage Plans. Track the payment status from Pricing → Payment History. &#x20;

{% hint style="info" %}
You can also create additional dedicated nodes by repeating these steps. If additional support is required during setup, you can contact the GetBlock support team directly from your dashboard.
{% endhint %}

***

### Managing your dedicated node

<figure><img src="/files/36uB39dxUZC4RhlCVH4p" alt="How to use GetBlock dedicated nodes"><figcaption></figcaption></figure>

Once your node is deployed, it appears in the left-hand sidebar. Each node has its own page — select a node from the sidebar to open it.

Three tabs are available for managing the node:

1. **Endpoints**: lists all endpoints associated with your node. To add a new one, click + Get endpoint. You can create multiple endpoints per node with different API interfaces. Endpoints for add-ons can also be created from this tab.
2. **Add-ons**: the central place to manage all add-ons. From here you can add a new add-on to an existing node, cancel an active add-on, create an endpoint.
3. **Statistics**: provides a detailed breakdown of usage metrics for your node.

Use the Invoices and Subscription buttons in the top-right corner of the node view to manage billing.&#x20;


# Dedicated node performance tiers

GetBlock’s Dedicated Nodes are available in two performance tiers – High and Standard. Choose the right balance of performance and cost for your private infrastructure

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.

***

### Dedicated Node tiers overview

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.

{% hint style="success" %}
Always check available configurations in your dashboard
{% endhint %}

#### *Reference High vs Standard tier comparison*&#x20;

<table><thead><tr><th width="208.7109375">Feature</th><th>High Performance</th><th>Standard Performance</th></tr></thead><tbody><tr><td><strong>Resource allocation</strong></td><td>Maximum hardware and bandwidth</td><td>Balanced hardware profile</td></tr><tr><td><strong>Throughput</strong></td><td>Highest supported</td><td>High</td></tr><tr><td><strong>Uptime SLA</strong></td><td>99.95%</td><td>99.9%</td></tr><tr><td><strong>Recommended for</strong></td><td>Applications with high transaction volumes &#x26; large user bases, mission-critical systems, and any workflow where latency and throughput are the top priority</td><td>Most production dApps, wallets, and enterprise tools or projects that need guaranteed resources but do not require the maximum performance tier</td></tr></tbody></table>

***

### Dedicated Node pricing

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.

{% hint style="success" %}
Monthly costs are always shown during configuration in the **Dashboard** for each supported network and region.
{% endhint %}

<figure><img src="/files/g0jKSA07jDiHGknhsUYr" alt="GetBlock private node configuration tool with pricing" width="533"><figcaption><p>Dedicated Node pricing in the GetBlock Dashboard</p></figcaption></figure>

***

### Steps to configure dedicated node tiers

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

<figure><img src="/files/wipq46ZFsXhAX2TViy9L" alt="Setting up a Dedicated Node performance tier via GetBlock dashboard" width="375"><figcaption></figcaption></figure>

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

***

#### **Need a more customized setup?**

For advanced workloads or unique requirements, our engineering team can help craft a custom private node solution beyond the High/Standard presets. [Contact us](https://getblock.io/contact/) for tailored deployments.


# Using GetBlock configuration files

GetBlock’s configuration file provides a more organized and flexible way to interact with blockchain nodes and networks without exposing sensitive API keys or credentials in the code.

## 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](https://jqlang.github.io/jq/download/) 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:

```bash
curl -X GET https://go.getblock.io/"$(jq -r '.shared.btc.mainnet.rest[0]' getblock.config.json)"/rest/chaininfo.json
```

## How to use GetBlock’s JavaScript config with Web3.js

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`

2. Download the `getblock.config.js` file from your GetBlock account. Add this file to your project directory.
3. Import the `getblock` module to a .js file that configures a new Web3 instance:

```javascript
const { getblock } = require('./getblock.config.js');
```

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

```javascript
const { getblock } = require('./getblock.config.js');
var Web3 = require('web3');

// Create the JSON-RPC provider
var web3Rpc = new Web3(new Web3.providers.HttpProvider(
        getblock.shared.eth.mainnet.rpc[0].go()
));

// Create the WebSocket provider
var web3Ws = new Web3.providers.WebsocketProvider(
        `wss://go.getblock.io/${getblock.shared.eth.mainnet.ws[0].token()}`
));
```

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

## How to use the JS config with Hardhat

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:

```bash
npm install --save-dev hardhat
```

2. Navigate to your GetBlock account and install the `getblock.config.js` file. Copy and paste it into your working directory;
3. Open the `hardhat.config.js` file from your project directory and import the `getblock` module:

```javascript
const { getblock } = require('./getblock.config.js');
```

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

```javascript
const { getblock } = require('./getblock.config.js'); 

module.exports = {
  defaultNetwork: "sepolia",
  networks: {
    hardhat: {
    },
    sepolia: {
      url: getblock.shared.eth.sepolia.rpc[0].go() // https://go.getblock.io/<ACCESS-TOKEN>/
    },
    goerli: {
      url: `https://go.getblock.io/${getblock.shared.eth.goerli.rpc[0].token()}` // <ACCESS-TOKEN>
    },
  },
  solidity: {
    version: "0.8.19",
    settings: {
      optimizer: {
        enabled: true,
        runs: 200
      }
    }
  },
  paths: {
    sources: "./contracts",
    tests: "./test",
    cache: "./cache",
    artifacts: "./artifacts"
  },
  mocha: {
    timeout: 40000
  }
}
```


# Testing RPC connection

This section provides simple examples to help you test your connection to the blockchain, using Ethereum API as a reference.


# Using cURL for testing

These examples provide a starting point for testing your connection and querying blockchain data using cURL commands.

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:

```bash
curl --location --request POST 'https://go.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:

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

### Get the chain ID

Identify the blockchain network with the `eth_chainId` method:

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS_TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_chainId",
    "params": [],
    "id": "getblock.io"
}'
```

Response example:

```json
{
  "jsonrpc": "2.0",
  "id": "getblock.io",
  "result": "0x1"
}
```

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

### Check account balance by address

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

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS_TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": ["<ACCOUNT_ADDRESS>", "latest"],
    "id": "getblock.io"
}'
```

Example response:

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0x5a70dac3910910"
}
```

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

{% hint style="info" %}
For a list of supported RPC methods with examples, navigate to [API Reference](https://github.com/GetBlock-io/getblock-docs/blob/main/guides/testing-rpc-connection/broken-reference/README.md).
{% endhint %}


# Postman Collection

Download the Postman GetBlock’s collection to test our service. It includes all the accessible endpoints of our nodes and ready-to-go examples.

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}`.

<figure><img src="/files/MvZOv8csBMYiZR5fwi2t" alt="Using Postman Collection for Ethereum JSON-RPC request"><figcaption><p>Using Postman to send a JSON-RPC request to an Ethereum node via GetBlock</p></figcaption></figure>

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


# Errors and troubleshooting

This page provides a guide to common JSON-RPC and HTTP errors when testing your connection with GetBlock's API.

### Connection issues

<table><thead><tr><th width="205">Code</th><th width="154">Error message</th><th>Solution</th></tr></thead><tbody><tr><td>401</td><td>Access denied</td><td>Double-check that <code>&#x3C;ACCESS_TOKEN></code> is correctly replaced with your actual token. Ensure there are no trailing spaces.</td></tr><tr><td>404</td><td>Could not resolve host</td><td>Verify that the URL <code>https://go.getblock.io/&#x3C;ACCESS_TOKEN>/</code> is correct.</td></tr><tr><td>429</td><td>Too many requests</td><td>Check your GetBlock account for usage limits. Upgrade your plan if necessary.</td></tr></tbody></table>

### JSON-RPC errors

<table><thead><tr><th width="205">Code</th><th width="158">Error message</th><th>Solution</th></tr></thead><tbody><tr><td>32601</td><td>The method does not exist/is not available</td><td>Verify the method name (<code>eth_blockNumber</code>, <code>eth_getBalance</code>, etc.) against the blockchain's JSON-RPC <a href="https://github.com/GetBlock-io/getblock-docs/blob/main/guides/testing-rpc-connection/broken-reference/README.md">specifications</a>.</td></tr><tr><td>32602</td><td>Invalid argument</td><td>Ensure the parameters in the <code>params</code> array match the expected format for the method.</td></tr><tr><td>32700</td><td>Parse error</td><td>Double-check your JSON syntax. Ensure your request is properly formatted.</td></tr></tbody></table>


# Monitoring and analytics

Track and manage your usage and node service subscriptions with GetBlock.

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

### Dashboard

<figure><img src="/files/1ReDrSvwnaxP6ABBzbAF" alt="How to track your GetBlock blockchain node usage statistics"><figcaption></figcaption></figure>

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.

{% hint style="info" %}
Customize the data view by **parameters** or by **access** **tokens** using the dropdown menu.
{% endhint %}

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

<figure><img src="/files/zYUQbQyTlV5NFKcIvCFA" alt="How to track your blokchain API usage"><figcaption><p>The Statistics tab shows more in-depth and customizable data analysis for your endpoints</p></figcaption></figure>

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&#x20;
* Dedicated node deployed and activated
* Recurring payment cancelled

{% hint style="warning" %}
Email notifications are **delivered only to** **accounts** with a **verified email address** provided during registration.

Users who registered using third-party authentication methods, such as MetaMask login, may not receive email notifications.
{% endhint %}

<figure><img src="/files/IJTUaSIJvz5423l5N1WV" alt="Managing your blockchain RPC node usage with notifications" width="375"><figcaption></figcaption></figure>

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.


# Connect to GetBlock with MetaMask

Learn how to set up custom RPC URL on MetaMask for faster, more reliable, and secure blockchain interactions.

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.

{% hint style="success" %}
Using GetBlock nodes with MetaMask makes your blockchain experience faster and more reliable than using default RPCs:

* Connect directly to trusted nodes for secure transactions.
* Enjoy quicker transactions and smoother dApp interactions.
* Experience less downtime, even during busy network periods
  {% endhint %}

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](https://getblock.io/) and copy it.

<figure><img src="/files/z4ksvaEeyRTZMrhiZREV" alt="How to get a custom RPC URL for MetaMask"><figcaption><p>Generate an RPC URL for MetaMask</p></figcaption></figure>

{% hint style="info" %}
Rename your endpoints to clearly indicate their purpose.
{% endhint %}

***

### Add GetBlock RPC to an existing network

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 menu<img src="/files/4DWWQRq8EOlSbU9OjM18" alt="" data-size="original">next to it. Select 'Edit'.

<figure><img src="/files/24qkOY9g88Tl3vMkOXTn" alt="How to set up the custom RPC URL on MetaMask"><figcaption></figcaption></figure>

3. Open the ‘**Default RPC URL**’ dropdown and select '**Add RPC URL'**.
4. Paste the JSON-RPC endpoint URL from your GetBlock account (`https://go.getblock.io/<ACCESS_TOKEN>/`).
5. Name the new RPC URL for easier identification.

<figure><img src="/files/ifGsEdAX80kR4ietgU9j" alt="How to change the RPC URL on MetaMask"><figcaption></figcaption></figure>

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

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

***

### Add a new network to MetaMask

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**'.

<figure><img src="/files/ClEy7losBbtDZR6EJsTN" alt="Adding a new network to MetaMask using custom RPC URL"><figcaption></figcaption></figure>

3. Fill in the required fields:

<table><thead><tr><th width="147">Field</th><th width="256">Description</th><th width="353">Example</th></tr></thead><tbody><tr><td><strong>RPC URL</strong></td><td>The network's JSON-RPC URL from your GetBlock account</td><td><em><mark style="color:blue;">https://go.getblock.io/&#x3C;ACCESS_TOKEN>/</mark></em></td></tr><tr><td><strong>Chain ID</strong></td><td>The ID of the network</td><td><em><mark style="color:blue;">1101</mark></em></td></tr><tr><td><strong>Network name</strong></td><td>Fetched automatically based on Chain ID</td><td><em><mark style="color:blue;">Polygon zkEVM</mark></em></td></tr><tr><td><strong>Currency symbol</strong></td><td>Suggested automatically based on Chain ID</td><td><em><mark style="color:blue;">ETH</mark></em></td></tr><tr><td><strong>Block explorer URL</strong></td><td>Optional field</td><td><em><mark style="color:blue;">https://zkevm.polygonscan.com/</mark></em></td></tr></tbody></table>

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

{% hint style="info" %}
You can get the Chain ID of an EVM-compatible network (e.g. Polygon zkEVM) sending a request to your endpoint with this curl command:

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_chainId",
    "params": [],
    "id": "getblock.io"
  }'
```

{% endhint %}


# Connect Brave Wallet to GetBlock

Explore how to add custom GetBlock RPC endpoints to Brave Wallet for greater security, transaction speed, and reliability

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 <https://account.getblock.io/> and get one of the 100+ available chain endpoints.

{% hint style="success" %}
Using custom GetBlock nodes improves the Web3 experience in many ways:

* Secure connections without privacy breaches
* Lower latency and higher transaction speed
* No overloads even during high chain activities
  {% endhint %}

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

***

### Before you start

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

#### Download Brave and set up the wallet

Brave Wallet is inseparable from the Brave browser. So, download and install the browser from the [official website](https://brave.com/wallet/). It’s available for desktop, Android, and iOS.

<figure><img src="/files/D7PWQq9wsTVtKyTC2qTJ" alt="Downloading Brave browser with integrated wallet"><figcaption></figcaption></figure>

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.

<figure><img src="/files/aRO3NKkqy1EkBCOSYRzU" alt="How to start using a Brave browser wallet"><figcaption></figcaption></figure>

Now, it’s time to prepare the working part: the GetBlock node.

#### Get a custom RPC API endpoint

<figure><img src="/files/OAC9d9LynEqbmbfqa27j" alt="Creating Ethereum access token in GetBlock"><figcaption></figcaption></figure>

1. Proceed to the **GetBlock dashboard** and create an account or log in.
2. Click on the **Get** button to add a new RPC endpoint, and select the Ethereum mainnet.
3. Pick the endpoint **location**. Currently, Frankfurt, Singapore, and New York endpoints are available for a free node. Selecting the physically closest one is usually the best option.
4. Click Get, and the endpoint is ready.

It’s now available via the access token URL and can be used to perform transactions, deploy smart contracts, and much more.

<figure><img src="/files/JY8LuompeNMTske0g9da" alt="Getting an ETH RPC URL for Brave wallet"><figcaption></figcaption></figure>

{% hint style="info" %}
Without a subscription, you may have only **2 endpoints** simultaneously. If you need more, consider deleting those you don’t need at the given moment.
{% endhint %}

Free node endpoints offer a generous 50,000 free Compute Units per day with a 20 RPS limit. It’s more than enough for single-person activities.

***

### Modify an existing EVM network

Brave Wallet supports a wide range of EVM and non-EVM networks. Let’s modify an Ethereum account.

{% stepper %}
{% step %}
**Go to Brave Wallet settings**

In the upper right corner of the wallet interface, click on the three-dot options (![three-dot menu](/files/4DWWQRq8EOlSbU9OjM18)) button and select **Settings**. Here, a list of supported networks can be found.

<figure><img src="/files/3f25INnDNLkz9naAgeCz" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}
**Locate the network in the list**

If the network of interest is already present, such as with Ethereum, click on the three-dot options (![](/files/4DWWQRq8EOlSbU9OjM18)) button right of Ethereum and then select **Edit** to open the account settings.

<figure><img src="/files/MMlKdBSs3ZJu6pCc7Qae" alt="Exploring Brave Wallet network accounts"><figcaption></figcaption></figure>

Look at the **RPC URLs** settings fro Ethereum: usually, a default Brave Wallet endpoint is present here. As every wallet user connects to it by default, it’s overloaded and insecure. That’s why a custom RPC URL is essential for Web3 activities.
{% endstep %}

{% step %}
**Add a custom API URL to the network**

Go to the GetBlock dashboard and copy the newly obtained Ethereum RPC access token. Add it under **RPC URLs** as shown below.

<figure><img src="/files/JIpsbiQvXDJe001SBsxz" alt="Adding GetBlock Ethereum endpoint to Brave Wallet"><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}

Go to the wallet, and try to perform some actions with the Ethereum account:

* Check the balance
* Connect to dApps
* Execute smart contracts
* Make a transaction

In the GetBlock dashboard, track the remaining [compute unit](/getting-started/plans-and-limits/cu-and-rate-limits) balance.

***

### Add a new EVM network

If a network of interest isn’t included in the network list, it can be added manually. Let’s add the Polygon zkEVM network, a zero-knowledge L2.

{% hint style="success" %}
Brave Wallet is very convenient for managing blockchain networks, with hundreds of EVM protocols available. GetBlock almost certainly has a node endpoint for active and popular ones.

If you genuinely believe that a network is unfairly missing, you may [contact us](https://getblock.io/contact/) and suggest it.
{% endhint %}

{% stepper %}
{% step %}
**Search the network ID in Brave settings**

Return to the Wallet Networks menu. Instead of selecting existing networks, click on the Add button. Start typing “polygon zkevm” to locate the network quickly.

<figure><img src="/files/eK8X6v0L9cHT8oXdnMeT" alt="Adding Polygon to Brave"><figcaption></figcaption></figure>

After clicking on it, Brave fills all required fields automatically.
{% endstep %}

{% step %}
**Get a network’s RPC URL at GetBlock**

Return to the GetBlock dashboard, click Get again, and select Polygon zkEVM mainnet this time. Currently, only the Frankfurt region is available for zkEVM nodes.

<figure><img src="/files/myWyKr3uT4tECZsWOZm3" alt="Creating zkEVM access token in GetBlock"><figcaption></figcaption></figure>

Voila—the free and highly secure Polygon zkEVM node endpoint is ready.
{% endstep %}

{% step %}
**Add a custom API URL to the new network**

Copy the access token and go to the Brave settings. Add the new RPC URLs field and paste the access token.

<figure><img src="/files/Yj1mNYUpNhVKppvcT3eD" alt="Adding GetBlock zkEVM endpoint to Brave Wallet’"><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}

It’s recommended to assign a custom account name, such as “Polygon zkEVM GetBlock,” to distinguish the dedicated account.

Then, return to the wallet and locate a new Polygon zkEVM account with the ETH native token and a custom name.

<figure><img src="/files/MY0IRNt0AZ5ZDZ1JZjbT" alt="New Polygon zkEVM account with GetBlock endpoint"><figcaption></figcaption></figure>

As with GetBlock’s Ethereum node, track the compute units usage at the GetBlock dashboard.


# GetBlock Docs MCP server

Connect the GetBlock Docs MCP server to Claude, Claude Code, Cursor, VS Code, or ChatGPT and query the documentation directly from your AI assistant.

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:

```bash
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 four tools to any connected agent:

| Tool                  | What the agent does with it                                                         |
| --------------------- | ----------------------------------------------------------------------------------- |
| `searchDocumentation` | Searches all of docs.getblock.io and returns matching pages with excerpts and links |
| `getPage`             | Fetches the full markdown content of a specific docs page by URL                    |
| `askQuestion`         | Asks a question and gets an answer grounded in the documentation                    |
| `sendFeedback`        | Sends feedback about the documentation back to the GetBlock team                    |

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

{% tabs %}
{% tab title="Claude" %}
In claude.ai or the Claude Desktop app:

1. Go to **Settings → Connectors → Add custom connector**.
2. Name it `GetBlock Docs` and paste `https://docs.getblock.io/~gitbook/mcp`.
3. Enable it from the tools menu in any chat.
   {% endtab %}

{% tab title="Claude Code" %}
Run one command in your terminal:

```bash
claude mcp add --transport http getblock-docs https://docs.getblock.io/~gitbook/mcp
```

Verify the connection with `/mcp` inside a session.
{% endtab %}

{% tab title="Cursor" %}
Go to **Settings → MCP → Add new MCP server**, or add to `.cursor/mcp.json`:

```json
{
  "mcpServers": {
    "getblock-docs": { "url": "https://docs.getblock.io/~gitbook/mcp" }
  }
}
```

{% endtab %}

{% tab title="VS Code" %}
Run **MCP: Add Server** from the Command Palette and choose HTTP, or add to `.vscode/mcp.json`:

{% code overflow="wrap" %}

```json
{
  "servers": {
    "getblock-docs": { "type": "http", "url": "https://docs.getblock.io/~gitbook/mcp" }
  }
}
```

{% endcode %}
{% endtab %}

{% tab title="ChatGPT" %}

1. Enable **Developer mode** under **Settings → Apps & Connectors**.
2. Choose **Create connector** and paste `https://docs.getblock.io/~gitbook/mcp` (no authentication).
3. The connector becomes available in chat and deep research.
   {% endtab %}
   {% endtabs %}

{% hint style="info" %}
Migrating an existing project to GetBlock? Point your connected assistant at the [Migrate to GetBlock with AI](/migration/migrate-to-getblock-with-ai) guide and it will walk through the migration for you.
{% endhint %}


# Overview

Learn what each GetBlock add-on does, the problem it solves, and which blockchain it serves

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.

{% hint style="warning" %}
Every add-on in this section is **blockchain-specific**: it exists for one chain or one family of chains, and the configurator offers it only when your node runs a chain it supports. For services that work on every blockchain, see [Extra Services for Dedicated Nodes](/extra-services-for-dedicated-nodes/overview).
{% endhint %}

## The add-ons at a glance

| Add-on                                                | It solves                                                 | Blockchain                 |
| ----------------------------------------------------- | --------------------------------------------------------- | -------------------------- |
| [Beacon API](/add-ons/beacon-api)                     | The `eth_*` API cannot see validators, slots, or finality | Ethereum                   |
| [Blockbook](/add-ons/blockbook)                       | A plain node cannot answer address or wallet queries      | UTXO chains (Bitcoin-type) |
| [ERC-4337](/add-ons/erc-4337)                         | Standard clients do not serve account-abstraction methods | EVM chains                 |
| [Overlay Methods](/add-ons/overlay-methods)           | Data a contract never emitted does not exist on-chain     | EVM chains                 |
| [MEV Protection](/add-ons/mev-protection)             | Bots see your transactions in the public mempool          | EVM chains                 |
| [Yellowstone gRPC API](/add-ons/yellowstone-grpc-api) | Standard RPC and WebSockets report Solana events too late | Solana                     |

### What each add-on gives you

#### 1. [Beacon API](/add-ons/beacon-api)&#x20;

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.

#### 2. [Blockbook](/add-ons/blockbook) — UTXO chains

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.

#### 3. [ERC-4337](/add-ons/erc-4337) — EVM chains

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

#### 4. [Overlay Methods](/add-ons/overlay-methods) — EVM chains

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.

{% hint style="info" %}
Overlay Methods is not a plugin on top of a standard node. It is a separate custom `reth` build (Oregon) that replaces the standard dedicated node. The catalog lists it as an add-on for consistency.
{% endhint %}

#### 5. [MEV Protection](/add-ons/mev-protection) — EVM chains

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.

#### 6. [Yellowstone gRPC API](/add-ons/yellowstone-grpc-api) — Solana

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.

### How to enable an add-on

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.


# Beacon API

GetBlock Beacon API: access the Ethereum consensus layer (Proof-of-Stake), separate from the usual JSON-RPC execution layer.

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.

```mermaid
flowchart TB
    Node[Ethereum dedicated node] --> EL["Execution layer<br/>eth_* JSON-RPC<br/>blocks, transactions, state"]
    Node --> CL["Consensus layer<br/>Beacon API<br/>slots, epochs, validators"]
```

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


# Blockbook

GetBlock Blockbook: an address and wallet indexer for UTXO chains such as Bitcoin.

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.

```mermaid
flowchart LR
    BC[UTXO chain] --> BB["Blockbook index<br/>by address and xpub"]
    BB --> Q["Your query:<br/>balance · transactions · UTXOs"]
```

### What it does

* **Address queries:** Ask for the balance, the transaction history, or the unspent outputs of a single address.
* **Wallet queries:** Ask for a whole wallet at once with 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.

### 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, which you need 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.


# ERC-4337

GetBlock ERC-4337 Methods: access bundler RPC calls for smart accounts, so gasless and batched transactions work without your own UserOperation relay.

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.

### How a UserOperation flows

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.

```mermaid
sequenceDiagram
    participant C as Your client
    participant B as Bundler sidecar
    participant E as EntryPoint contract
    C->>B: eth_sendUserOperation
    B->>B: validate and queue in UserOp mempool
    B->>E: submit bundle on-chain
    C->>B: eth_getUserOperationReceipt
    B-->>C: result
```

### The methods

| Method                         | Purpose                                            |
| ------------------------------ | -------------------------------------------------- |
| `eth_sendUserOperation`        | Submit a UserOperation to the bundler mempool      |
| `eth_estimateUserOperationGas` | Estimate the gas a UserOperation needs             |
| `eth_getUserOperationByHash`   | Fetch a UserOperation by its hash                  |
| `eth_getUserOperationReceipt`  | Get the receipt for a UserOperation                |
| `eth_supportedEntryPoints`     | List the EntryPoint contracts the bundler supports |

### Benefits

* **Native ERC-4337 support:** You get the full account-abstraction RPC on a node that does not provide it by default.
* **Gasless transactions:** With a paymaster, your users transact without holding native ETH, because the paymaster sponsors the gas.
* **No bundler to run:** You build on smart-contract wallets without operating and maintaining your own bundler.

### When to use it

* You build a product around smart-contract wallets.
* You run a paymaster or a gas-sponsorship flow.
* You build account-abstraction infrastructure and need a reliable bundler RPC.


# Overlay Methods

GetBlock Overlay Methods: access debug/trace over a block range and replay history with modified contract bytecode, without any real on-chain deployment.

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.

{% hint style="info" %}
This is not a plugin on top of a standard node. It is a separate custom `reth` build (Oregon) that replaces the standard dedicated node. The catalog lists it as an add-on for consistency
{% endhint %}

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.

```mermaid
flowchart LR
    H[Real historical blocks] --> O["Oregon reth<br/>replay with modified bytecode"]
    B[Your modified bytecode] --> O
    O --> R[Logs and events that<br/>never existed on-chain]
```

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.


# MEV Protection

GetBlock MEV Protection routes your transactions through a private mempool against front-running and sandwich attacks

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.

```mermaid
flowchart LR
    U[Your transaction] --> MP[Public mempool<br/>visible to everyone]
    MP --> BB[Block builder<br/>chooses order]
    BB --> BL[Block]
```

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

```mermaid
flowchart LR
    U[Your transaction] --> PM[Private mempool<br/>via Merkle]
    PM --> BB[Block builder]
    BB --> BL[Block]
    S[MEV bot] -. cannot see .-> PM
```

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.


# Yellowstone gRPC API

Power your Solana dApps and backends with the fastest, most reliable streaming data available. Yellowstone gRPC add-on is for apps that need every live event as fast as the network can deliver.

## Overview

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

***

## Key Features

* **Near-zero latency**: Streams data directly from validators, often hundreds of milliseconds faster than standard RPC/WebSocket APIs
* **High throughput**: Handles millions of events per minute under load
* **Comprehensive streaming**: Monitor accounts, transactions, blocks, slots, and program interactions in real-time
* **Rich filtering**: Subscribe only to relevant updates using account keys, owner programs, or commitment levels
* **Protobuf encoding**: Receive parsed, typed messages instead of raw base64 data
* **Bidirectional streaming**: Maintain long-lived connections with built-in keep-alives

***

## Supported Data Streams

Yellowstone gRPC supports streaming the full range of Solana events:

| Stream Type      | Description                                                   |
| ---------------- | ------------------------------------------------------------- |
| **Accounts**     | Real-time account updates including lamports, owner, and data |
| **Transactions** | Full transaction data with metadata and instruction details   |
| **Blocks**       | Block metadata including slot, parent slot, and timestamp     |
| **Slots**        | Slot notifications as they're processed by the leader         |
| **Block Meta**   | Block metadata with transaction counts and execution status   |

***

## Use Cases

Yellowstone gRPC is ideal for time-sensitive applications that need to react instantly to on-chain state changes:

* High-frequency trading and MEV bots
* On-chain indexers and data archives
* Real-time analytics dashboards
* DEX monitors and price feeds
* DeFi strategy engines
* Alerting and notification systems
* NFT marketplace trackers
* Wallet activity monitors

{% hint style="info" %}
**Note**: gRPC is not supported in browsers. Yellowstone is designed for backend services and server-side applications.
{% endhint %}

***

## Getting Started

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><mark style="color:blue;"><strong>Overview</strong></mark></td><td>Learn how Yellowstone gRPC works and why it's essential for real-time Solana applications</td><td><a href="/pages/fzc2q4ipTlaoOG6NspDZ">/pages/fzc2q4ipTlaoOG6NspDZ</a></td></tr><tr><td><mark style="color:blue;"><strong>Quickstart Guide</strong></mark></td><td>Enable the add-on and start streaming data with code examples in TypeScript, Python, Go, and Rust</td><td><a href="/pages/dNGDBl1qjPbE6crdV7nN">/pages/dNGDBl1qjPbE6crdV7nN</a></td></tr></tbody></table>

***

## Prerequisites

To use Yellowstone gRPC on GetBlock:

* A GetBlock account (sign up at [getblock.io](https://getblock.io))
* A [Dedicated Solana Node](https://docs.getblock.io/getting-started/plans-and-limits/choosing-your-plan) subscription
* Yellowstone gRPC add-on enabled (included at no extra cost with Dedicated Nodes)

***

## Quick Example

Here's a minimal TypeScript example to start streaming account updates:

```typescript
import Client, {
  SubscribeRequest,
  CommitmentLevel
} from "@triton-one/yellowstone-grpc";

const client = new Client("https://go.getblock.io/", "YOUR_ACCESS_TOKEN");
const stream = await client.subscribe();

stream.write({
  accounts: ["YourWalletPubkeyHere"],
  commitment: CommitmentLevel.PROCESSED,
} as SubscribeRequest);

stream.on("data", (msg) => {
  if (msg.accountChange) {
    console.log(`Account updated: ${msg.accountChange.pubkey}`);
  }
});
```

***

## Additional Resources

* [Yellowstone gRPC GitHub Repository](https://github.com/rpcpool/yellowstone-grpc)
* [GetBlock Solana Nodes](https://getblock.io/nodes/sol/)
* [GetBlock Support](https://getblock.io/contact/)

***

## Need Help?

Our support team is available 24/7 to assist with:

* Add-on activation and endpoint setup
* Integration guidance and troubleshooting
* Performance optimization
* Custom solutions for enterprise needs

Contact us through the [GetBlock dashboard](https://getblock.io) or visit our [support page](https://getblock.io/contact/).


# Overview

Yellowstone gRPC is a Solana Geyser plugin developed by Triton One that feeds your application a continuous, low-latency stream of on-chain data

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.
* **Block notifications**: Clients can subscribe to be notified when a new block is completed.
* **Slot notifications**: New slot boundaries (leaders or votes) can trigger slot events.

Every update stream can include full transaction metadata, instruction details, and parsed logs – essentially everything you’d see in a [`getTransaction`](broken://pages/Uq52KBzXkGJCxir4qAiU) or [`getProgramAccounts`](broken://pages/8Soxi7IGm7ZbsMCKHKCK) 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.

***

### Yellowstone gRPC API features

* **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.
* **Comprehensive streaming**: Clients can monitor virtually anything: token mints, program interactions, votes, etc.
* **Protobuf/binary encoding**: Each message arrives **parsed** and **typed**, not raw base64. Clients get structured fields (account diffs, token balance changes, parsed logs, etc.) instead of raw blobs.
* **Rich filtering**: You can apply filters (by account key, owner program, data patterns, commitment level, etc.) so only matching updates are streamed.

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

***

### Solana Geyser gRPC plugin use cases

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.;
* Alerting & notification systems;
* DeFi strategy engines;
* ..and any app that needs push‑style updates.

{% hint style="info" %}
Note that gRPC is not supported in browsers, so Yellowstone is intended for backend services.
{% endhint %}

***

### Why use Yellowstone gRPC API?

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


# Quickstart guide

Follow these steps to activate the Solana Yellowstone gRPC add-on on GetBlock

GetBlock offers[ SOL nodes](https://getblock.io/nodes/sol/) with the Solana Geyser gRPC plugin, so you can start using it immediately, without any node setup and maintenance — simply enable the add-on and point your gRPC client at our endpoints.

### Prerequisites

* A GetBlock account with a Dedicated Solana Node subscription
* Your gRPC endpoint URL with access token (found in GetBlock dashboard)

#### Enabling the Solana gRPC add-on on GetBlock

The Yellowstone gRPC add-on to Solana currently requires a [Dedicated Node](https://docs.getblock.io/getting-started/plans-and-limits/choosing-your-plan) subscription on GetBlock. Here’s how to set it up with gRPC API:

1. **Sign up / log in**: Create an account at GetBlock.io or log in to your existing account.
2. **Deploy a dedicated Solana node:**
   1. Go to your user **dashboard**, switch the tab to “**Dedicated nodes**”, and scroll down to “My endpoints”
   2. Choose **Solana** under “Protocol”, set the network to **mainnet**.
   3. Click on **Get**.

<figure><img src="/files/SyavVgTPYr72R5gWYCVj" alt="Deploying a private Solana node with GetBlock RPC provider"><figcaption></figcaption></figure>

3. **Enable the gRPC add-on**: In Step 3 (Select API and Add‑ons) of your node setup, check **Yellowstone gRPC** under Add‑ons.

<figure><img src="/files/nZkHjtJAMtsbbW7gY9cy" alt="Configuring a dedicated SOL node on GetBlock"><figcaption></figcaption></figure>

{% hint style="success" %}
All **Dedicated Node plan subscribers** receive the Yellowstone gRPC API **at no extra cost** together with their Solana node.
{% endhint %}

Once your node is live, you’ll be able to create gRPC endpoints to begin using the add-on.

#### Get your gRPC endpoint

Return to **My endpoints** in your Dedicated node dashboard and generate a gRPC [Access Token](https://docs.getblock.io/getting-started/authentication-with-access-tokens).

<p align="center"><img src="/files/5PLcUrNzdO3xT3TfdotN" alt=""><br></p>

The dashboard will generate your new HTTPS‐style gRPC endpoint URL.

#### Endpoint & authentication

The endpoint URL will be used by your gRPC client to authenticate and interact with the Solana network. Regional domain determines which data center you’re talking to (Europe, US, or Asia).

{% hint style="info" %}
Your **node’s region** is locked in when you deploy it, during the setup flow. Once the node is provisioned in that region, all your endpoint URLs will correspond to the location you selected.
{% endhint %}

Example endpoint URLs:

```http
// Europe (Frankfurt)
https://go.getblock.io/<YOUR_ACCESS_TOKEN>/

// USA (New York)
https://go.getblock.us/<YOUR_ACCESS_TOKEN>/

// Asia (Singapore)
https://go.getblock.asia/<YOUR_ACCESS_TOKEN>/

```

When establishing your gRPC channel, the authentication is handled via an access token:

```typescript
ENDPOINT = 'https://go.getblock.io';
TOKEN = 'YOUR_GETBLOCK_ACCESS_TOKEN';
```

{% hint style="info" %}
GetBlock provides a single TLS endpoint – you don’t need to open or configure a different port for gRPC access.
{% endhint %}

***

### Subscribing to Data Streams: Code examples

Dragon’s Mouth uses **gRPC over HTTP/2** for all communication. Its message schemas are defined in Protocol Buffer (`.proto`) files, included in the [Yellowstone repository](https://github.com/rpcpool/yellowstone-grpc/tree/master), which specify all the RPC methods and data types.

The power of Yellowstone is real‑time streaming: open a single bi‑directional stream, send a `SubscribeRequest` with your filters, and get back a sequence of `SubscribeUpdate` messages.

Here are the main subscription targets:

| Stream Field        | Proto Name                                   | What You Get                                         |
| ------------------- | -------------------------------------------- | ---------------------------------------------------- |
| `slots`             | `slots: SlotsFilter`                         | Slot numbers as they’re processed by leader          |
| `blocks`            | `blocks: BlocksFilter`                       | Block metadata (slot, parent slot, timestamp)        |
| `blocksMeta`        | `blocksMeta: BlocksFilter`                   | Block metadata + transaction counts + status         |
| `accounts`          | `accounts: AccountsFilter`                   | Account lamports, owner, executable flag, rent epoch |
| `accountsDataSlice` | `accountsDataSlice: AccountsDataSliceFilter` | Partial account data blobs                           |
| `transactions`      | `transactions: TransactionsFilter`           | Full transaction data + meta                         |

{% hint style="info" %}
All filters can be combined in the same request.
{% endhint %}

Developers can integrate Yellowstone streams using standard gRPC client libraries. Triton’s Yellowstone repository includes [example clients](https://github.com/rpcpool/yellowstone-grpc/tree/master/examples) in **Rust**, **Python**, **Go**, and **TypeScript**.

The part below will show common ways to initialize your **connection to the GetBlock gRPC endpoint** and open a bidirectional subscription stream (`Subscribe`) with filters.

***

#### 1. CLI (using `grpcurl`)

A generic tool like grpcurl is perfect to just poke at the API and explore method calls:

```bash
# 1) List services and methods 
grpcurl \
  -insecure \
  -authority go.getblock.io \
  -H "x-access-token: YOUR_ACCESS_TOKEN" \
  go.getblock.io:443 \
  list

# 2) Subscribe to slots
grpcurl \
  -insecure \
  -authority go.getblock.io \
  -H "x-access-token: YOUR_ACCESS_TOKEN" \
  go.getblock.io:443 \
  geyser.Geyser/Subscribe \
  -d '{ "slots": { "slots": []{} } }'

```

***

#### 2. Using a high‑level SDK (Node.js / TypeScript)

The `triton-one/yellowstone-grpc` repository is the official client toolkit for Solana’s Yellowstone (Geyser) gRPC API.

It wraps the raw gRPC calls in friendly methods, handles reconnects, back‑pressure, and includes TypeScript types out of the box – easiest to get started with minimal boilerplate.

**Install the SDK**:

```bash
npm install @triton-one/yellowstone-grpc
# or
yarn add @triton-one/yellowstone-grpc
```

**Connect to the gRPC endpoint and subscribe to the stream**:

```typescript
import Client, {
 SubscribeRequest,
 CommitmentLevel,
 SubscribeResponse,
} from "@triton-one/yellowstone-grpc";


async function main() {
 // Initialize
 const ENDPOINT = "https://go.getblock.io/";
 const TOKEN    = "<YOUR_ACCESS_TOKEN>";
 const client   = new Client(ENDPOINT, TOKEN);


  // Open a bidirectional stream
 const stream = await client.subscribe();


 // send a request to start all streams
 stream.write({
   accounts:   ["YourWalletPubkeyHere"],
   programs:   [],
   commitment: CommitmentLevel.PROCESSED,
 } as SubscribeRequest);

 stream.on("data", (msg: SubscribeResponse) => {
   if (msg.accountChange) {
     console.log(
       `▶ Account ${msg.accountChange.pubkey} = ${msg.accountChange.lamports}`
     );
   }
 });


 // End the stream
 stream.end();
 await client.close();
}


main().catch(console.error);

```

***

#### 3. Python, Rust, and Go streaming examples

Below are minimal examples using Triton's **Yellowstone helper libraries** to stream real-time data from Solana via gRPC.

{% tabs %}
{% tab title="Go" %}
**Setup & run**:

```bash
cd go-client
go mod tidy
go run main.go
```

Make sure the following **dependencies** are installed:

```bash
go get github.com/rpcpool/yellowstone-grpc/examples/golang@latest
go get google.golang.org/grpc@latest
```

**Go Example** (`go-client/main.go`):

```go
import (
   "context"
   "fmt"
   "log"
   "time"

   ygrpc "github.com/rpcpool/yellowstone-grpc/examples/golang/pkg/grpc"
   pb "github.com/rpcpool/yellowstone-grpc/examples/golang/pkg/proto"
   "google.golang.org/grpc/metadata"
)

func main() {
   endpoint := "go.getblock.io:443"
   token := "YOUR_GETBLOCK_TOKEN"

   client, err := ygrpc.NewGrpcConnection(context.Background(), endpoint)
   if err != nil {
       log.Fatalf("Connection error: %v", err)
   }
   defer client.Close()

   ctx := metadata.AppendToOutgoingContext(context.Background(), "x-token", token)
   stream, err := client.Subscribe(ctx)
   if err != nil {
       log.Fatalf("Subscription error: %v", err)
   }


   req := &pb.SubscribeRequest{
       Accounts: map[string]*pb.SubscribeRequestFilterAccounts{
           "example": {
               Account: []string{"YOUR_WATCHED_ACCOUNT"},
           },
       },
       Commitment: pb.CommitmentLevel_CONFIRMED,
   }


   if err := stream.Send(req); err != nil {
       log.Fatalf("Send error: %v", err)
   }


   fmt.Println("Streaming...")
   for {
       res, err := stream.Recv()
       if err != nil {
           log.Printf("Stream error: %v", err)
           time.Sleep(time.Second)
           continue
       }
       fmt.Printf("Update at slot %d for %s\n", res.GetSlot(), res.GetAccount().GetAccount().GetPubkey())
   }
}
```

{% endtab %}

{% tab title="Python" %}
Make sure you clone the Yellowstone repo (for the `examples.grpc` module):

```bash
git clone https://github.com/rpcpool/yellowstone-grpc
export PYTHONPATH=$PYTHONPATH:$(pwd)/yellowstone-grpc/examples/python
```

**Python Example** (`python-client/stream.py`):

```python
from examples.grpc import new_client
import time
from google.protobuf.json_format import MessageToDict

endpoint = "go.getblock.io:443"
token = "YOUR_GETBLOCK_TOKEN"

channel, client = new_client(endpoint, token)

req = {
   "accounts": {
       "example": {
           "account": ["YOUR_WATCHED_ACCOUNT"]
       }
   },
   "commitment": "CONFIRMED"
}

stream = client.Subscribe(iter([req]))

for update in stream:
   print("Update:", MessageToDict(update))
   time.sleep(0.5)
```

{% endtab %}

{% tab title="Rust" %}
**Setup**:

```bash
cd rust-client
cargo build
cargo run
```

Ensure your **Cargo.toml** includes:

```toml
[dependencies]
yellowstone-grpc = { git = "https://github.com/rpcpool/yellowstone-grpc", branch = "main" }
tonic = "0.9"
tokio = { version = "1", features = ["full"] }
```

**Rust Example** (`rust-client/src/main.rs`):

```rust
use tonic::metadata::MetadataValue;
use yellowstone_grpc::client::{subscribe_with_token, SubscribeRequest};

#[tokio::main]
async fn main() {
   let endpoint = "https://go.getblock.io";
   let token = "YOUR_GETBLOCK_TOKEN";

   let mut stream = subscribe_with_token(endpoint, token, SubscribeRequest {
       accounts: Some({
           let mut m = std::collections::HashMap::new();
           m.insert("example".to_string(), vec!["YOUR_WATCHED_ACCOUNT".to_string()]);
           m
       }),
       commitment: Some("confirmed".into()),
       ..Default::default()
   }).await.expect("stream failed");

   println!("Streaming...");
   while let Some(Ok(update)) = stream.message().await {
       println!("Update: {:?}", update);
   }
}
```

{% endtab %}
{% endtabs %}

***

### Unary RPC methods

In addition to streaming subscriptions, the same gRPC interface also provides unary RPCs for quick, one-off queries:

* **`getSlot`**: Returns the current slot number.
* **`getBlockHeight`**: Retrieves the current block height.
* **`getLatestBlockhash`**: Fetches the most recent blockhash.
* **`isBlockhashValid`**: Checks whether a given blockhash is still valid.
* **`getVersion`**: Returns version info for both the gRPC plugin and the connected Solana node

You can call these methods directly on the gRPC client without opening a streaming connection.

***

### Yellowstone gRPC best practices

Before you start streaming data with the Yellowstone Geyser plugin, consider these recommendations:

* **Filtering is crucial**: Always narrow your subscription to only the `accounts` or `programs` you need. Excessive or empty filters can overwhelm clients and hit rate limits.
* **Combine with JSON‑RPC**: Use gRPC for real‑time streaming. Continue to use GetBlock’s JSON‑RPC Solana endpoints for on‑demand calls like [`getBlock`](broken://pages/qfijVOnnvj0tmM2T2mDt), [`sendTransaction`](broken://pages/164SGSO9dftxQ39PHwbH), or historical queries.
* **Keeping your stream alive**: gRPC streams may time out if idle. The Yellowstone plugin can handle keep-alive pings. In your `SubscribeRequest`, you can set `ping: true` to respond to server pings (or send a minimal ping message periodically) to keep the stream alive.
* **Selecting the right commitment levels**: Choose **`processed`**, **`confirmed`**, or **`finalized`** in your `SubscribeRequest` to balance between lowest latency (`processed`) and highest certainty (`finalized`). For most real‑time use cases (dashboards, bots), use `processed` to see intra‑slot updates.

{% hint style="info" %}

#### About commitment levels

In Solana’s commitment hierarchy, you have *processed*, *confirmed*, and *finalized:*

* **Finalized**: After full consensus & finalized in the ledger.
* **Confirmed**: Once a supermajority of validators have voted.
* **Processed**: Means the validator has received and executed the transaction, but it may not yet have enough votes to be considered confirmed/finalized – (“intra-slot”).

*Streaming at “processed” gives you every transaction and account write the moment the leader executes it, well before it appears in a confirmed block.*
{% endhint %}

***

With these examples and notes, you should be able to jump right into using GetBlock’s Yellowstone gRPC API in the language of your choice.

### 💬 Need help?

Check out the [Yellowstone gRPC docs](https://github.com/rpcpool/yellowstone-grpc) or reach out via [GetBlock support](https://getblock.io/contact/).


# Overview

Learn more about extra services specifically for GetBlock dedicated nodes

A GetBlock dedicated node gives you isolated compute for one workload. These extra services extend that node. Each service solves one specific problem that a standard node cannot solve on its own.

{% hint style="info" %}
The extra services are for Dedicated Nodes and available to all blockchains. The one exception is Solana Shreds Streaming, which is Solana-specific and is also offered as a standalone, credit-based service without a node.
{% endhint %}

### Extra Services for Dedicated Nodes at a glance

<table data-search="false"><thead><tr><th>Extra services</th><th>It solves</th><th>Price/mo</th></tr></thead><tbody><tr><td><a href="/pages/e276aef076bcc258e476ca8588bbfbace5b35793">Advanced Analytics</a></td><td>You cannot see how your node is used</td><td>$199</td></tr><tr><td><a href="/pages/6fc958d86ddd183493265f2450bff085883d5f5a">Automatic RPC Failover</a></td><td>Your app breaks when the node degrades</td><td>$199</td></tr><tr><td><a href="/pages/f8e33f15dcb6dfb664cfbd421ae68724bcdae8e5">Custom Endpoint URL</a></td><td>Your endpoint URL exposes a random hash</td><td>$199</td></tr><tr><td><a href="/pages/5ac15340311b33a32fda99af95e5a03c6322898d">Dedicated Ingress Proxy</a></td><td>Other traffic shares your routing layer</td><td>$199</td></tr><tr><td><a href="/pages/07878a2781aa41014314a227c4f666020a4e43ae">IP Allowlist</a></td><td>Anyone with the key can call the node</td><td>$199</td></tr><tr><td><a href="/pages/3054581c741127eac16e5b7fd2a7dbeb555ae72d">Nonstandard Client Support</a></td><td>You need a namespace or client we do not run by default</td><td>$500</td></tr><tr><td><a href="/pages/zDKW4HMVGLoYKt77nJrc">Solana Shreds Streaming</a></td><td>Standard feeds report Solana activity too late</td><td>On request</td></tr><tr><td><a href="/pages/c9810944b435b34d4fe29715032c941af2da3e97">Unified Multichain Endpoint</a></td><td>You manage one URL per chain</td><td>$199</td></tr><tr><td><a href="/pages/79d90dbce031dc4726a30fc7a7a9cf63f7eb8113">Zero-Hop Node Access</a></td><td>The proxy layer adds latency you cannot afford</td><td>$199</td></tr></tbody></table>

{% hint style="info" %}

### These prices are temporary

All prices are preliminary and per month. They add to your dedicated node subscription. They do not replace it.
{% endhint %}

### What each service gives you

#### 1. [Advanced Analytics](/extra-services-for-dedicated-nodes/advanced-analytics)

A private Grafana workspace that records every request your node handles and turns it into time-series charts: request volume, latency as percentiles (p50, p95, p99), and error rate — sliced by RPC method, by access key, and by region. You can trace a latency spike to the exact method behind it, attribute cost to a team or customer, size capacity from measured traffic, and spot a key that starts behaving abnormally.

#### 2. [Automatic RPC Failover](/extra-services-for-dedicated-nodes/automatic-rpc-failover)

Health-checks your node at set intervals and treats it as degraded when it lags the chain head, its error rate rises, or its latency crosses a limit. Degraded traffic moves to GetBlock's shared RPC pool automatically and moves back once the node recovers — the endpoint URL never changes, so your application never notices the switch. Client upgrades and maintenance windows stop being downtime.

#### 3. [Custom Endpoint URL](/extra-services-for-dedicated-nodes/custom-endpoint-url)

Serves your node from a domain you own — `rpc.yourapp.com` via a CNAME record — instead of the autogenerated address with a random access token in the path. Authentication moves to a header such as `x-access-token`, so the secret no longer travels inside the URL, where it tends to end up in server logs and browser history. The URL also survives token rotation.

#### 4. [Dedicated Ingress Proxy](/extra-services-for-dedicated-nodes/dedicated-ingress-proxy)

A dedicated node isolates the compute, but every request still passes through a shared ingress layer that terminates TLS, checks authentication, applies rate limits, and routes the request. This service gives you a proxy fleet that serves only your traffic: no other customer's surge can slow your gateway, the added latency stays predictable, and the rate-limit and routing rules become yours to configure.

**Use it when** you run at high request rates and the shared gateway has become the limit, or your compliance rules require an isolated traffic path end to end. **Skip it when** your traffic is moderate and the shared gateway keeps up — it isolates the routing layer, not the node's compute.

#### 5. [IP Allowlist](/extra-services-for-dedicated-nodes/ip-allowlist)

Restricts your endpoint by source IP: only requests from addresses you approved reach the node; everything else is rejected at the gateway with `403 Forbidden`, before it consumes node capacity or quota. Entries can be single addresses or CIDR subnets, IPv4 and IPv6. A token authenticates *who* is calling; the allowlist controls *where* the call comes from — so a leaked token alone is no longer enough.

#### 6. [Nonstandard Client Support](/extra-services-for-dedicated-nodes/nonstandard-client-support)

Runs what a default node deliberately leaves off: the `debug`, `trace`, `txpool`, or `admin` namespaces; a specific client version, patched build, or private fork; custom flags or a custom tracer. You describe what you need, and GetBlock deploys and operates it — upgrades, monitoring, and incidents included — so you get the exotic setup without owning its operations.

#### 7. [Solana Shreds Streaming](/extra-services-for-dedicated-nodes/solana-shreds-streaming)

Delivers raw block fragments (shreds) straight from validators over UDP, before the block is assembled — roughly 100 to 500 milliseconds before a standard commitment-based feed reports the same activity. You decode the shreds into transaction intent as the leader is packing it: signatures, accounts, instructions, and slot numbers. It comes in two modes: attached to your Solana dedicated node, or as a standalone credit-based service with no node at all.

#### 8. [Unified Multichain Endpoint](/extra-services-for-dedicated-nodes/unified-multichain-endpoint)

Collapses your per-chain endpoints into one URL and one credential. You keep your dedicated nodes but reach them all through a single unified endpoint, selecting the target chain with a subdomain, a path, or a chain-id parameter. Rate limits and the IP allowlist are set once and apply to every chain behind it, so adding a network no longer adds another endpoint and key to configure, rotate, and keep in sync.

#### 9. [Zero-Hop Node Access](/extra-services-for-dedicated-nodes/zero-hop-node-access)

Removes the gateway and load balancer from the path and connects your application straight to your node. Those layers each add a small amount of time and, worse for trading, a small amount of variance; a fixed direct route removes both. Because you always reach the same node, you also keep a consistent view of the mempool and chain state. Pair it with a node in the region closest to your systems for the largest gain.

{% hint style="warning" %}
Zero-Hop Node Access and Automatic RPC Failover pull in opposite directions by design: one removes the routing layer, the other depends on it. Choose the one that fits the workload rather than enabling both.
{% endhint %}

### How to choose

* Set up a dedicated node from your account dashboard. It covers most workloads on its own.
* Add a capability only when you have the problem it solves.
* Read the "When you can skip it" section on each page before you buy.
* For blockchain-specific capabilities — Beacon API, Blockbook, ERC-4337, Overlay Methods, MEV Protection, Yellowstone gRPC — see the [Add-ons](/add-ons/overview) section instead.

### How to enable an add-on

To add any of these to your dedicated node, use the configurator setting of Dedicated Nodes or contact the support team for assistance.


# Advanced Analytics

A private Grafana workspace for your dedicated node. It shows how your node is used in real time.

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. &#x20;

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,&#x20;
3. and by region&#x20;

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.

```mermaid
flowchart TB
    R[Every request] --> M["Volume · Latency · Errors"]
    M --> D1[By method]
    M --> D2[By access key]
    M --> D3[By region]
```

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.

### Benefits

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

### When to use 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.

### Limitations

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.


# Automatic RPC Failover

GetBlock Automatic RPC Failover switches your traffic to shared RPC automatically when your dedicated node degrades.

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.

```mermaid
flowchart LR
    App[Your application<br/>one endpoint URL] --> R{Node<br/>healthy?}
    R -- Yes --> DN[Dedicated node]
    R -- No --> SP[Shared RPC pool]
    DN -. recovers .-> R
```

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.


# Custom Endpoint URL

GetBlock Custom Endpoint URL: replace the autogenerated hash with your own URL for your dedicated node.

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 `go.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. &#x20;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.

```mermaid
flowchart LR
    A[Your application] --> D[rpc.yourapp.com]
    D -->|CNAME| G[Your GetBlock node]
    A -. token in header, not in URL .-> D
```

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.


# Dedicated Ingress Proxy

GetBlock Dedicated Ingress Proxy gives you your own routing layer, fully isolated from all other traffic.

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.

```mermaid
flowchart TB
    subgraph Standard["Standard: shared ingress"]
        CA[Customer A] --> SP[Shared proxy]
        CB[Customer B] --> SP
        You1[You] --> SP
        SP --> Nodes[Nodes]
    end
    subgraph Dedicated["With this add-on: dedicated ingress"]
        You2[You only] --> YP[Your proxy] --> YN[Your node]
    end
```

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


# IP Allowlist

GetBlock IP Allowlist: a network security control that restricts access to your RPC endpoint based on the source IP address of each request.

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.

```mermaid
flowchart LR
    A[Incoming request] --> B{Source IP<br/>on allowlist?}
    B -- Yes --> C[Forward to node]
    B -- No --> D[Reject: 403 Forbidden<br/>before any processing]
```

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.

### Before you begin

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.

### Benefits

* **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.
* **Explicit access control:** You decide exactly which servers and environments can reach the endpoint.

### When to use it

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.

### Limitations

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.


# Solana Shreds Streaming

GetBlock Solana Shreds Streaming delivers raw block data straight from validators, over UDP, before the block is assembled.

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.

```mermaid
flowchart LR
    L[Leader validator] -->|shreds| T[Turbine<br/>stake-weighted hops]
    T --> RPC[Standard feed<br/>waits for reassembly<br/>+ commitment]
    L -->|direct shred stream| UDP[Your UDP listener<br/>earliest view]
```

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

### Two ways to use it

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.

### How the standalone service works

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.

### Benefits

* **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.
* **No node required:** In standalone mode you receive data without the cost and the operations of a full Solana node.

### When to use it

* 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.
* You run high-frequency analytics that need the earliest possible data.

### Limitations

* **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.
* **Solana only:** Shreds are a Solana concept; the service does not apply to other chains.

### Delivery

| Field             | Value                                                   |
| ----------------- | ------------------------------------------------------- |
| Protocol          | UDP (raw shreds)                                        |
| Access modes      | Dedicated node add-on · standalone credit-based service |
| Available Regions | `eu-central-1`, `us-east-1`, `ap-southeast-1`           |


# Nonstandard Client Support

GetBlock Nonstandard Client Support runs extra namespaces, private forks, and exotic configs — all on managed infrastructure.

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.

```mermaid
flowchart LR
    subgraph Default
        D[Standard client<br/>standard namespaces]
    end
    subgraph "With this add-on"
        C["Custom build<br/>extra namespaces · fork · flags"]
        S[Managed by GetBlock:<br/>upgrades · monitoring · incidents]
        C --- S
    end
```

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.


# Unified Multichain Endpoint

GetBlock Unified Multichain Endpoint: use one URL for every node and chain in your stack.

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.

```mermaid
flowchart LR
    App["Your application<br/>one URL · one token"] --> E[Unified endpoint]
    E --> C1[Ethereum]
    E --> C2[Polygon]
    E --> C3[BSC]
    E --> C4[Solana]
```

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.


# Zero-hop Node Access

GetBlock Zero-hop Node Access: connect straight to your dedicated node, bypassing the proxy layer entirely.

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.

```mermaid
flowchart TB
    subgraph Standard["Standard path"]
        A1[Your app] --> G[Gateway] --> LB[Load balancer] --> N1[Node]
    end
    subgraph ZeroHop["Zero-Hop path"]
        A2[Your app] --> N2[Node]
    end
```

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.

{% hint style="warning" %}
Zero-Hop and [Automatic RPC Failover](/extra-services-for-dedicated-nodes/automatic-rpc-failover) pull in opposite directions by design: one removes the routing layer, the other depends on it. Choose the one that fits the workload rather than enabling both.&#x20;
{% endhint %}


# BSC Accelerated Dedicated Node

GetBlock's BSC Accelerated Dedicated Node enables users to have direct access to fast, robust, and high-performance network layers.

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***](https://getblock.io/contact) ***for more information.***

### How It Works

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

{% @mermaid/diagram content="graph TD
subgraph "Standard setup(200-500ms)"
A\[Validator] --> B\[P2P Network]
B --> C\[Your Node]
C --> D\[Your Application]
end" %}

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

{% @mermaid/diagram content="graph TD
subgraph "Accelerated Node(<50ms)"
A\[BDN] --> B\[GetBlock Data Center]
B --> C\[Your Dedicated Node]

end" %}

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.

### What Accelerated Node Gets:

The BDN Gateway improves the delivery speed of:

| Data Type             | Description                    | Impact                                                                 |
| --------------------- | ------------------------------ | ---------------------------------------------------------------------- |
| **New Blocks**        | Block headers and transactions | React to state changes faster                                          |
| **Mempool Updates**   | Pending transactions           | See opportunities earlier                                              |
| **State Transitions** | Account and contract state     | Fresher data for decisions                                             |
| **Transaction**       | Submiting Trsanction           | Submit single transactions or bundles with optimized propagation paths |

### Who is this for:

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.

### Benefits for Your Workloads

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

{% hint style="success" %}
No Action Required

* **Automatic**: Enabled when you provision an accelerated dedicated node
* **Transparent**: Your existing RPC calls work unchanged
* **Managed**: GetBlock handles all Gateway maintenance and updates

Your application code remains the same. The improvement happens at the infrastructure layer, giving you faster data without code changes.
{% endhint %}

### What to do With Accerelated Node

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

* [Subscribing to real-time streams](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/how-to-subscribe-to-stream) for direct access to BDN data
* [Submitting transactions to public mempool ](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/how-to-submit-transactions-to-public-mempool)with accelerated propagation
* Using private transactions for [MEV protection ](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/sending-transactions-to-private-mempool-priority-fee)or [without MEV Protection](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/how-to-submit-a-transaction-to-private-mempool)


# How to Subscribe to Stream

Learn how to direct real-time access to transaction and block streams sourced from the BDN, bypassing RPC node-level execution and processing entirely.

Stream subscription provides you with direct access to blockchain data as it propagates through the BDN network. This is very good for users e.g traders who want to get data earlier e.g new released token \
\
With a stream subscription, you enjoy:

* **Faster blocks**: Receive new blocks before standard RPC propagation
* **Mempool access**: See pending transactions before they're mined
* **Lower latency:** Edge infrastructure minimizes network hops

### Code Sample

Here, you will be checking if you are connected to streams

{% tabs %}
{% tab title="Endpoint" %}

```bash
wss://go.getblock.io/<ACCESS_TOKEN>
```

{% endtab %}

{% tab title="Code" %}
{% code title="index.js" %}

```javascript
//npm install ws dotenv
import WebSocket from "ws";
import "dotenv/config";

const ws = new WebSocket(
  `wss://go.getblock.io/${process.env.ACCESS_TOKEN}`,
);

ws.on("open", () => {
  console.log("Connected to BSC streams");
});

ws.on("error", (err) => {
  console.error("WebSocket error:", err.message);
});
```

{% endcode %}
{% endtab %}

{% tab title="Response" %}

```bash
> bsc-node@1.0.0 start
> node index.js

Connected to BSC streams
```

{% endtab %}
{% endtabs %}

### How to Subscribe to Streams

To subscribe to streams, there are four parameters you can make use of as seen below:&#x20;

| Stream       | Description                              | Use Case                    |
| ------------ | ---------------------------------------- | --------------------------- |
| `bdnBlocks`  | New blocks with headers and transactions | Block monitoring, analytics |
| `newTxs`     | New transactions entering mempool        | MEV detection, copy trading |
| `pendingTxs` | Pending transactions                     | Front-running protection    |
| `txReceipts` | Transaction receipts after confirmation  | Trade confirmation          |

#### 1. Block Streams (bdnBlocks)

Subscribe to new blocks as they're produced.

**Include Options**

| Field          | Description                                               |
| -------------- | --------------------------------------------------------- |
| `header`       | Block header (number, hash, timestamp, gasUsed, gasLimit) |
| `transactions` | Full transaction list                                     |
| `hash`         | Block hash only                                           |

**Example: Subscribe to Blocks**

{% tabs %}
{% tab title="Code" %}
{% code title="subscribe-blocks.js" %}

```javascript
import WebSocket from "ws";
import "dotenv/config";

const ws = new WebSocket(`wss://go.getblock.io/${process.env.ACCESS_TOKEN}`);

ws.on("open", () => {
  console.log("Connected");

  // Subscribe to new blocks
  ws.send(
    JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "subscribe",
      params: ["bdnBlocks", { include: ["header", "transactions", "hash"] }],
    }),
  );
});

ws.on("message", (data) => {
  const message = JSON.parse(data);

  // Subscription confirmation
  if (message.id === 1 && message.result) {
    console.log("Subscribed! ID:", parseInt(message.result));
    return;
  }

  // Block notification
  if (message.params?.result) {
    const block = message.params.result;
    console.log("New block:", {
      number: parseInt(block.header.number, 16),
      hash: block.header.hash,
      txCount: block.transactions?.length || 0,
    });
  }
});

```

{% endcode %}
{% endtab %}

{% tab title="Response" %}

```json
Connected
Subscribed! ID: 9
New block: { number: 84411561, hash: undefined, txCount: 86 }
New block: { number: 84411562, hash: undefined, txCount: 105 }
New block: { number: 84411563, hash: undefined, txCount: 66 }
New block: { number: 84411564, hash: undefined, txCount: 66 }
New block: { number: 84411565, hash: undefined, txCount: 78 }
New block: { number: 84411566, hash: undefined, txCount: 93 }
New block: { number: 84411567, hash: undefined, txCount: 63 }
```

{% endtab %}
{% endtabs %}

#### 2. Transaction Streams (newTxs / pendingTxs)

Subscribe to mempool transactions as they propagate through the network.

**Include Options**

| Field       | Description             |
| ----------- | ----------------------- |
| `tx_hash`   | Transaction hash        |
| `from`      | Sender address          |
| `to`        | Recipient address       |
| `value`     | Transaction value (hex) |
| `gas_price` | Gas price (hex)         |
| `input`     | Transaction calldata    |

**Filters**

Reduce bandwidth by filtering server-side:

| Filter      | Type  | Description                                    |
| ----------- | ----- | ---------------------------------------------- |
| `to`        | array | Transaction recipient addresses                |
| `from`      | array | Transaction sender addresses                   |
| `method_id` | array | Function selectors (first 4 bytes of calldata) |

**Example: Monitor PancakeSwap Transactions**

{% tabs %}
{% tab title="pendingTxs code" %}

<pre class="language-javascript" data-title="monitor-pancakeswap.js"><code class="lang-javascript">import WebSocket from "ws";
import { ethers } from "ethers";
import "dotenv/config";

const PANCAKE_ROUTER = "0x10ED43C718714eb63d5aA57B78B54704E256024E";

const SWAP_METHODS = {
  "0x38ed1739": "swapExactTokensForTokens",
  "0x7ff36ab5": "swapExactETHForTokens",
  "0x18cbafe5": "swapExactTokensForETH",
  "0xfb3bdb41": "swapETHForExactTokens",
  "0x5c11d795": "swapExactTokensForTokensSupportingFeeOnTransferTokens",
  "0xb6f9de95": "swapExactETHForTokensSupportingFeeOnTransferTokens",
};

function monitorPancakeSwap() {
  const ws = new WebSocket(`wss://go.getblock.io/${process.env.ACCESS_TOKEN}`);

  ws.on("open", () => {
    console.log("🔌 Connected to BSC stream");
    console.log("📊 Monitoring PancakeSwap...\n");

<strong>    ws.send(
</strong><strong>      JSON.stringify({
</strong><strong>        jsonrpc: "2.0",
</strong><strong>        id: 1,
</strong><strong>        method: "subscribe",
</strong><strong>        params: [
</strong><strong>          "pendingTxs",
</strong><strong>          {
</strong><strong>            include: ["tx_hash", "from", "to", "value", "input", "gas_price"],
</strong><strong>            filters: {
</strong><strong>              to: [PANCAKE_ROUTER],
</strong><strong>            },
</strong><strong>          },
</strong><strong>        ],
</strong><strong>      }),
</strong><strong>    );
</strong><strong>  });
</strong>
  ws.on("message", (data) => {
    const msg = JSON.parse(data);

    // Subscription confirmed
    if (msg.id === 1) {
      console.log("✅ Subscribed to PancakeSwap transactions\n");
      return;
    }

    // New transaction
    if (msg.params?.result) {
      const tx = msg.params.result;
      const methodId = tx.input?.slice(0, 10);
      const methodName = SWAP_METHODS[methodId] || "unknown";

      if (SWAP_METHODS[methodId]) {
        const value = ethers.formatEther(tx.value || "0");
        const gasPrice = ethers.formatUnits(tx.gas_price || "0", "gwei");

        console.log("🔄 Swap detected:");
        console.log(`   Hash: ${tx.tx_hash.slice(0, 18)}...`);
        console.log(`   Method: ${methodName}`);
        console.log(`   From: ${tx.from.slice(0, 10)}...`);
        console.log(`   Value: ${value} BNB`);
        console.log(`   Gas: ${gasPrice} gwei`);
        console.log("");
      }
    }
  });

  ws.on("close", () => {
    console.log("Disconnected, reconnecting in 5s...");
    setTimeout(monitorPancakeSwap, 5000);
  });

  ws.on("error", (err) => {
    console.error("WebSocket error:", err.message);
  });
}

monitorPancakeSwap();

</code></pre>

{% endtab %}

{% tab title="Response" %}

```json
{
  "tx_hash": "0xdef456...",
  "from": "0xabc...",
  "to": "0x10ED43C718714eb63d5aA57B78B54704E256024E",
  "value": "0x16345785d8a0000",
  "gas_price": "0xb2d05e00",
  "input": "0x38ed1739..."
}
```

{% endtab %}

{% tab title="newTx code" %}

<pre class="language-js" data-overflow="wrap"><code class="lang-js">import WebSocket from 'ws';
import 'dotenv/config';

const PANCAKE_ROUTER = '0x10ED43C718714eb63d5aA57B78B54704E256024E';

const SWAP_METHODS = {
  '0x38ed1739': 'swapExactTokensForTokens',
  '0x7ff36ab5': 'swapExactETHForTokens',
  '0x18cbafe5': 'swapExactTokensForETH',
  '0xfb3bdb41': 'swapETHForExactTokens',
};

function monitorNewTxs() {
  const ws = new WebSocket(`wss://go.getblock.io/${process.env.ACCESS_TOKEN}`);

  ws.on('open', () => {
    console.log('Connected to BSC stream');
    console.log('Monitoring confirmed PancakeSwap swaps...\n');

<strong>    ws.send(JSON.stringify({
</strong><strong>      jsonrpc: '2.0',
</strong><strong>      id: 1,
</strong><strong>      method: 'subscribe',
</strong><strong>      params: ['newTxs', {
</strong><strong>        include: ['tx_hash', 'from', 'to', 'value', 'input'],
</strong><strong>        filters: {
</strong><strong>          to: [PANCAKE_ROUTER],
</strong><strong>          method_id: Object.keys(SWAP_METHODS)
</strong><strong>        }
</strong><strong>      }]
</strong><strong>    }));
</strong><strong>  });
</strong>
  ws.on('message', (data) => {
    const msg = JSON.parse(data);

    if (msg.id === 1) {
      console.log('Subscribed to confirmed PancakeSwap transactions\n');
      return;
    }

    if (msg.params?.result) {
      const tx = msg.params.result;
      const methodId = tx.input?.slice(0, 10);
      const methodName = SWAP_METHODS[methodId] || 'unknown';

      console.log('Confirmed swap:');
      console.log(`  Hash:   ${tx.tx_hash}`);
      console.log(`  Method: ${methodName}`);
      console.log(`  From:   ${tx.from}`);
      console.log(`  To:     ${tx.to}`);
      console.log(`  Value:  ${tx.value}`);
      console.log('');
    }
  });

  ws.on('close', () => {
    console.log('Disconnected, reconnecting in 5s...');
    setTimeout(monitorNewTxs, 5000);
  });

  ws.on('error', (err) => {
    console.error('WebSocket error:', err.message);
  });
}

monitorNewTxs();

</code></pre>

{% endtab %}

{% tab title="Response" %}
{% code overflow="wrap" %}

```bash
{
    "jsonrpc":"2.0",
    "id":1,
    "result":"0x11"
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

#### 3. Transaction Receipts (txReceipts)

Subscribe to transaction confirmations.

**Include Options**

| Field     | Description              |
| --------- | ------------------------ |
| `receipt` | Full transaction receipt |
| `logs`    | Event logs emitted       |

Example:&#x20;

{% tabs %}
{% tab title="Code" %}

<pre class="language-javascript"><code class="lang-javascript">import WebSocket from 'ws';
import 'dotenv/config';

const ws = new WebSocket(`wss://go.getblock.io/${process.env.ACCESS_TOKEN}`);

ws.on("open", () => {
  console.log("Connected");

  // Subscribe to new blocks
<strong>  ws.send(JSON.stringify({
</strong><strong>    jsonrpc: '2.0',
</strong><strong>    id: 1,
</strong><strong>    method: 'subscribe',
</strong><strong>    params: ['txReceipts', {
</strong><strong>      include: ['receipt', 'logs']
</strong><strong>    }]
</strong><strong>  }));
</strong><strong>});
</strong>
ws.on("message", (data) => {
  const message = JSON.parse(data);
  console.log(message)})
</code></pre>

{% endtab %}

{% tab title="Response" %}
{% code overflow="wrap" %}

```bash
{ 
  jsonrpc: '2.0', 
  id: 1, 
  result: '0x10' 
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

#### Unsubscribing

To stop receiving notifications, unsubscribe using the subscription ID:

{% tabs %}
{% tab title="code sample" %}
{% code title="unsubscribe.js" overflow="wrap" %}

```js
import WebSocket from "ws";
import "dotenv/config";
const ws = new WebSocket(`wss://go.getblock.io/${process.env.ACCESS_TOKEN}`);
ws.on("open", () => {
  console.log("Connected");

ws.send(
  JSON.stringify({
    jsonrpc: "2.0",
    id: 10,
    method: "unsubscribe",
    params: ["23"], // Subscription ID
  }),
);})

ws.on("message", (data) => {
  const message = JSON.parse(data);
  console.log(JSON.stringify(message, null, 2));
});
```

{% endcode %}
{% endtab %}

{% tab title="Response" %}
{% code overflow="wrap" %}

```bash
{ 
    jsonrpc: '2.0', 
    id: 10, 
    result: true 
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

## Best Practices

1\. Request Only What You Need

{% tabs %}
{% tab title="Don't ❌" %}

```js
// ❌ Bad: Request everything
include: ['tx_contents']  // Large payloads, high bandwidth
```

{% endtab %}

{% tab title="Do ✅" %}

```js
// ✅ Good: Request specific fields
include: ['tx_hash', 'from', 'to', 'value']  // Small payloads
```

{% endtab %}
{% endtabs %}

2. Use Server-Side Filters

{% tabs %}
{% tab title="Don't ❌" %}

```js
// ❌ Bad: Filter client-side
params: ['newTxs', { include: ['tx_contents'] }]
// Then filter in your code... wasteful!
```

{% endtab %}

{% tab title="Do ✅" %}

```js
// ✅ Good: Filter server-side
params: ['newTxs', {
  include: ['tx_hash', 'to', 'input'],
  filters: { to: ['0xTargetContract'] }
}]
```

{% endtab %}
{% endtabs %}

3. Handle Reconnection

```javascript
function createConnection() {
  const ws = new WebSocket(`wss://bsc.getblock.io/mev/ws?api_key=${API_KEY}`);
  
  ws.on('close', () => {
    console.log('Disconnected, reconnecting...');
    setTimeout(createConnection, 5000);
  });
  
  ws.on('open', () => {
    // Re-subscribe after reconnect
    subscribeToFeeds(ws);
  });
  
  return ws;
}
```

4. Process Messages Asynchronously

```javascript
ws.on('message', async (data) => {
  // Don't block the message loop
  setImmediate(() => {
    processMessage(JSON.parse(data));
  });
});
```

## Rate Limits

| Tier       | Concurrent Subscriptions | Message Rate |
| ---------- | ------------------------ | ------------ |
| Standard   | 5                        | 1,000/sec    |
| Pro        | 20                       | 10,000/sec   |
| Enterprise | Unlimited                | Unlimited    |

***Contact*** [***support***](mailto:support@getblock.io) ***to upgrade your tier.***

## Troubleshooting

| Problem              | Solution                                                                                                                                                                                 |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| No messages received | <p></p><ul><li>Check subscription response—did you receive a subscription ID?</li><li>Verify filters aren't too restrictive</li><li>Confirm your API key is valid and active</li></ul>   |
| High latency         | <p></p><ul><li>Reduce the number of <code>include</code> fields</li><li>Add filters to reduce message volume</li><li>Check your network connection</li></ul>                             |
| Missed messages      | <p></p><ul><li>Process messages asynchronously</li><li>Increase your message queue buffer</li><li>Consider multiple connections for different streams</li></ul>                          |
| Connection Drop      | <p></p><ul><li>Implement automatic reconnection (see example above)</li><li>Re-subscribe after each reconnect—subscriptions don't persist</li><li>Check your network stability</li></ul> |

### Next Step

1. [Submitting transactions to public mempool ](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/how-to-submit-transactions-to-public-mempool)with accelerated propagation
2. Using private transactions for [MEV protection ](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/sending-transactions-to-private-mempool-priority-fee)or [without MEV Protection](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/how-to-submit-a-transaction-to-private-mempool)


# How to Submit Transactions to Public Mempool

Learn how to submit transactions to the BNB Chain public mempool through GetBlock's BDN fast path.

This process involves submitting transactions to the BNB Chain public mempool via GetBlock's BDN fast path. Your transaction propagates to validators significantly faster than through standard P2P gossip, increasing the probability of earlier block inclusion.

### When to Use Public Mempool

Use public mempool submission when:

* You want faster propagation without hiding your transaction
* MEV exposure is acceptable for your use case
* You're competing on speed rather than privacy
* You need broad validator visibility quickly

*For MEV-sensitive transactions, see* [*Private Transactions*](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/sending-transactions-to-private-mempool-priority-fee) *instead.*

### Sample Request

{% tabs %}
{% tab title="Endpoint" %}

```bash
wss://go.getblock.io/<ACCESS_TOKEN>
```

{% endtab %}

{% tab title="Method" %}

```bash
blxr_tx
```

{% endtab %}

{% tab title="Transaction Parameters" %}

| Parameter    | Type   | Required | Description                        |
| ------------ | ------ | -------- | ---------------------------------- |
| `nonce`      | int    | Yes      | Transaction count for your address |
| `to`         | string | Yes      | Recipient address                  |
| `value`      | BigInt | Yes      | Amount in wei                      |
| `gasPrice`   | BigInt | Yes      | Gas price (minimum 3 gwei)         |
| `gasLimit`   | int    | Yes      | Gas limit for execution            |
| `data`       | string | No       | Calldata for contract calls        |
| `chainId`    | int    | Yes      | `56` for BSC Mainnet               |
| {% endtab %} |        |          |                                    |

{% tab title="Request Format" %}

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "blxr_tx",
  "params": ["0x<signed_transaction_hex>"]
}
```

{% endtab %}

{% tab title="Response Format" %}

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x<transaction_hash>"
}
```

{% endtab %}
{% endtabs %}

### How to Submit a Transaction to Public Mempool

{% stepper %}
{% step %}
Set up the project

{% tabs %}
{% tab title="npm" %}

```bash
mkdir transaction-public-mempool
cd transaction-public-mempool
npm init -y
npm install ws ethers dotenv
```

{% endtab %}

{% tab title="yarn" %}

```bash
mkdir transaction-public-mempool
cd transaction-public-mempool
yarn init -y
yarn ws ethers dotenv
```

{% endtab %}
{% endtabs %}
{% endstep %}

{% step %}
Create a new file named `index.js`. This is where you will make your first call.
{% endstep %}

{% step %}
Set the ES module `"type": "module"` in your `package.json`.
{% endstep %}

{% step %}
Create `.env` file and add the following:

{% code overflow="wrap" %}

```js
ACCESS_TOKEN=your-accelerated-node-endpoint
RPC_URL=your-normal-bsc-node-endppoint //e.g https
PRIVATE_KEY=your-wallet-private-key
TO_ADDRESS=the-receiver-address
```

{% endcode %}
{% endstep %}

{% step %}
Add the following code to `index.js`:
{% endstep %}

{% step %}

```javascript
import WebSocket from "ws";
import { ethers } from "ethers";
import "dotenv/config";
```

{% endstep %}

{% step %}
Create and Sign Your Transaction

```javascript
const PRIVATE_KEY = process.env.PRIVATE_KEY;
const RPC_URL = process.env.RPC_URL;
const provider = new ethers.JsonRpcProvider(RPC_URL);
const wallet = new ethers.Wallet(PRIVATE_KEY, provider);

// Get current nonce
const nonce = await provider.getTransactionCount(wallet.address);
// Build transaction
const tx = {
  nonce: nonce,
  to: process.env.TO_ADDRESS,
  value: ethers.parseEther("0.001"),
  gasPrice: ethers.parseUnits("3", "gwei"), // Minimum 3 gwei for BSC
  gasLimit: 21000,
  chainId: 56, // BSC Mainnet
};
// Sign transaction
const signedTx = await wallet.signTransaction(tx); 
const signedTxNoPrefix = signedTx.startsWith("0x")
  ? signedTx.slice(2)
  : signedTx;
```

{% endstep %}

{% step %}
Submit via WebSocket

```javascript
const ws = new WebSocket(process.env.ACCESS_TOKEN);
ws.on("open", () => {
  ws.send(
    JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "blxr_tx",
      params: {"transaction": signedTxNoPrefix},
    }),
  );
});
ws.on("message", (data) => {
  const response = JSON.parse(data);
  if (response.result?.txHash) {
  const hash = response.result.txHash;
  console.log("TX Hash:", hash);
  console.log(`https://bscscan.com/tx/${hash}`);
} else if (response.error) {
    console.error("❌ Error:", response.error.message);
  }
  ws.close();
});
```

{% endstep %}

{% step %}
Response

```bash
01f86c380384b2d05e0082520894d26ea0f03100358b2ebd4c9638f042aada9a1bcf87038d7ea4c6800080c001a04647f98754480337ae409bcc225f2d62b706b47f31385221421cea20e41080b0a03ae32f07bb7110c4153c2ab121c152db7d3030d54cc0c5341f0b75b20e3d439d
TX Hash: 00d4fe2db5c667ce549318cf621913af1bcb130022ec51020cbb6cae2b7eedce
https://bscscan.com/tx/00d4fe2db5c667ce549318cf621913af1bcb130022ec51020cbb6cae2b7eedce
```

{% endstep %}
{% endstepper %}

<details>

<summary>Complete Example: BNB Transfer</summary>

```javascript
import WebSocket from "ws";
import { ethers } from "ethers";
import "dotenv/config";

const PRIVATE_KEY = process.env.PRIVATE_KEY;
const RPC_URL = process.env.RPC_URL;
const provider = new ethers.JsonRpcProvider(RPC_URL);
const wallet = new ethers.Wallet(PRIVATE_KEY, provider);


// Get current nonce
const nonce = await provider.getTransactionCount(wallet.address);

// Build transaction
const tx = {
  nonce: nonce,
  to: "0xd26ea0f03100358b2Ebd4c9638f042aAda9a1BcF",
  value: ethers.parseEther("0.001"),
  gasPrice: ethers.parseUnits("3", "gwei"), // Minimum 3 gwei for BSC
  gasLimit: 21000,
  chainId: 56, // BSC Mainnet
};

// Sign transaction
const signedTx = await wallet.signTransaction(tx); // e.g. "0xabcdef..."
const signedTxNoPrefix = signedTx.startsWith("0x")
  ? signedTx.slice(2)
  : signedTx;

console.log(signedTxNoPrefix);

const ws = new WebSocket(process.env.ACCESS_TOKEN);
ws.on("open", () => {
  ws.send(
    JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "blxr_tx",
      params: {"transaction": signedTxNoPrefix},
    }),
  );
});

ws.on("message", (data) => {
  const response = JSON.parse(data);
  if (response.result?.txHash) {
  const hash = response.result.txHash;
  console.log("TX Hash:", hash);
  console.log(`https://bscscan.com/tx/${hash}`);
} else if (response.error) {
    console.error("❌ Error:", response.error.message);
  }

  ws.close();
});
```

</details>

<details>

<summary>Complete Example: Token Swap on PancakeSwap</summary>

```javascript
import WebSocket from 'ws';
import { ethers } from 'ethers';
import 'dotenv/config';

const PRIVATE_KEY = process.env.PRIVATE_KEY;
const RPC_URL = process.env.RPC_URL;

const PANCAKE_ROUTER = '0x10ED43C718714eb63d5aA57B78B54704E256024E';
const WBNB = '0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c';

async function swapBNBForToken(tokenAddress, amountBNB, minAmountOut) {
  const provider = new ethers.JsonRpcProvider(RPC_URL);
  const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
  
  // Router ABI
  const routerABI = [
    'function swapExactETHForTokens(uint256 amountOutMin, address[] path, address to, uint256 deadline) payable'
  ];
  const router = new ethers.Contract(PANCAKE_ROUTER, routerABI, wallet);
  
  // Build swap calldata
  const deadline = Math.floor(Date.now() / 1000) + 300;  // 5 minutes
  const swapData = router.interface.encodeFunctionData('swapExactETHForTokens', [
    minAmountOut,
    [WBNB, tokenAddress],
    wallet.address,
    deadline
  ]);
  
  // Get nonce
  const nonce = await provider.getTransactionCount(wallet.address);
  
  // Build transaction
  const tx = {
    nonce: nonce,
    to: PANCAKE_ROUTER,
    value: ethers.parseEther(amountBNB),
    data: swapData,
    gasPrice: ethers.parseUnits('3', 'gwei'),
    gasLimit: 300000,  // Higher gas limit for swaps
    chainId: 56
  };
  
  // Sign transaction
  const signedTx = await wallet.signTransaction(tx);
  const signedTxNoPrefix = signedTx.startsWith("0x")
 ? signedTx.slice(2)
 : signedTx;
  
  console.log('Swap details:');
  console.log('  Amount:', amountBNB, 'BNB');
  console.log('  Token:', tokenAddress);
  console.log('  Min out:', ethers.formatEther(minAmountOut));
  
  // Submit via BDN
 const ws = new WebSocket(`wss://go.getblock.io/${process.env.ACCESS_TOKEN}`);
  
  return new Promise((resolve, reject) => {
    ws.on('open', () => {
      ws.send(JSON.stringify({
        jsonrpc: '2.0',
        id: 1,
        method: "blxr_tx",
        params: {"transaction": signedTxNoPrefix},
      }));
    });
    
    ws.on('message', (data) => {
      const response = JSON.parse(data);
      ws.close();
      
      if (response.result) {
        console.log('\n✅ Swap submitted!');
        console.log('TX Hash:', response.result);
        resolve(response.result);
      } else {
        console.error('\n❌ Error:', response.error);
        reject(response.error);
      }
    });
  });
}

// Usage: Swap 0.001 BNB for BUSD
swapBNBForToken(
  '0xe9e7CEA3DedcA5984780Bafc599bD69ADd087D56',  // BUSD
  '0.001',                                          // 0.001 BNB
  ethers.parseEther('50')                         // Min 50 BUSD
).catch(console.error);
```

</details>

### Gas Price Recommendations

| Priority | Gas Price | Use Case              |
| -------- | --------- | --------------------- |
| Standard | 3 gwei    | Regular transfers     |
| Fast     | 5 gwei    | Time-sensitive trades |
| Urgent   | 10+ gwei  | Competitive scenarios |

{% hint style="info" %}
Note: Higher gas prices increase inclusion priority but also increase transaction cost.
{% endhint %}

### Troubleshooting

1. **"nonce too low"**

Your nonce is behind the network state. Fetch the latest:

```javascript
const nonce = await provider.getTransactionCount(wallet.address, 'pending');
```

2. **"insufficient funds"**

Ensure you have enough BNB for both the transaction value and gas:

```
Required = value + (gasPrice × gasLimit)
```

3. **"replacement transaction underpriced"**

If replacing a pending transaction, increase the gas price by at least 10%:

```javascript
const newGasPrice = existingGasPrice * 110n / 100n;
```

4. **Transaction not included**

* Increase gas price for higher priority
* Check that the transaction is valid
* Verify sufficient balance

## Next Steps

For transactions that need MEV protection, see:

* [Private Transactions](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/how-to-submit-a-transaction-to-private-mempool) — Hidden from public mempool
* [Private Transactions with Tips](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/sending-transactions-to-private-mempool-priority-fee) — Prioritized private submission


# How to Submit a Transaction to Private Mempool

Learn how to submit transaction to private mempool directly to block builders, protecting you from MEV extraction until it's included in a block.

When you submit a transaction to the public mempool, it's visible to everyone. MEV bots can:

* **Sandwich your trade:** Place orders before and after yours to extract value
* **Front-run you:** Copy your trade and execute it first
* **Back-run you:** Profit from the price impact you create

Meanwhile, Private transactions eliminate this exposure by hiding your transactions until they are included.

<figure><img src="/files/ml3rLGTnkZljG6Tn5Udj" alt="" width="563"><figcaption></figcaption></figure>

### Private TX vs Public Mempool

| Aspect          | Public Mempool              | Private TX             |
| --------------- | --------------------------- | ---------------------- |
| Visibility      | Everyone sees it            | Only builders see it   |
| MEV exposure    | Vulnerable                  | Protected              |
| Inclusion speed | Gas price dependent         | Builder dependent      |
| Best for        | Speed-competitive scenarios | Value-sensitive trades |

### When to Use Private Transactions

Use private transactions when:

* Executing large swaps that could be sandwiched
* Trading tokens with low liquidity
* Running strategies you don't want copied
* Protecting any transaction from front-running

### Request Sample

{% tabs %}
{% tab title="Endpoint" %}

```bash
wss://go.getblock.io/<ACCESS_TOKEN>
```

{% endtab %}

{% tab title="Method" %}

```bash
bsc_private_tx
```

{% endtab %}

{% tab title="Parameters" %}

| Parameter      | Type   | Required | Description                             |
| -------------- | ------ | -------- | --------------------------------------- |
| `transaction`  | string | Yes      | Signed raw transaction hex              |
| `mev_builders` | array  | No       | Builders to send to. Default: `["all"]` |
| {% endtab %}   |        |          |                                         |

{% tab title="Request Format" %}

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "bsc_private_tx",
  "params": {
    "transaction": "0xf86c...",
    "mev_builders": ["all"]
  }
}
```

{% endtab %}

{% tab title="Response Format" %}

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "txHash": "0x..."
  }
}
```

{% endtab %}
{% endtabs %}

### How to Submit Transaction to Private Mempool

{% stepper %}
{% step %}
Set up the project

{% tabs %}
{% tab title="npm" %}

```bash
mkdir transaction-private-mempool
cd transaction-private-mempool
npm init -y
npm install ws ethers dotenv
```

{% endtab %}

{% tab title="yarn" %}

```bash
mkdir transaction-private-mempool
cd transaction-private-mempool
yarn init -y
yarn ws ethers
```

{% endtab %}
{% endtabs %}
{% endstep %}

{% step %}
Set the ES module `"type": "module"` in your package.json.
{% endstep %}

{% step %}
Create a file and name it `index.js`
{% endstep %}

{% step %}
Create `.env` file and add the following:

{% code overflow="wrap" %}

```js
ACCESS_TOKEN=your-accelerated-node-endpoint
RPC_URL=your-normal-bsc-node-endppoint //e.g https
PRIVATE_KEY=your-wallet-private-key
```

{% endcode %}
{% endstep %}

{% step %}
Import the dependencies

```javascript
import WebSocket from 'ws';
import { ethers } from 'ethers';
import 'dotenv/config';

const PRIVATE_KEY = process.env.PRIVATE_KEY;
const RPC_URL = process.env.RPC_URL
```

{% endstep %}

{% step %}
Create and Sign Your Transaction

```javascript
const provider = new ethers.JsonRpcProvider(RPC_URL);
const wallet = new ethers.Wallet(PRIVATE_KEY, provider);

// Get current nonce
const nonce = await provider.getTransactionCount(wallet.address);

// Build transaction
const tx = {
  nonce: nonce,
  to: '0xRECIPIENT_ADDRESS',
  value: ethers.parseEther('0.1'),
  gasPrice: ethers.parseUnits('3', 'gwei'),
  gasLimit: 21000,
  chainId: 56
};

// Sign transaction
const signedTx = await wallet.signTransaction(tx);
```

{% endstep %}

{% step %}
Submit Privately

```javascript
const ws = new WebSocket(`wss://go.getblock.io/${process.env.ACCESS_TOKEN}`);

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

ws.on('message', (data) => {
  const response = JSON.parse(data);
  
  if (response.result) {
    console.log('✅ Private TX submitted!');
    console.log('TX Hash:', response.result.txHash);
  } else {
    console.error('❌ Error:', response.error);
  }
  
  ws.close();
});
```

{% endstep %}

{% step %}
Response

{% code overflow="wrap" %}

```bash
Wallet: 0xD1AF2dAc4e0a....
Recipient: 0xd26ea.....
Amount: 0.001 BNB
Mode: Private (MEV Protected)

Submitting private transaction...

✅ Private transaction submitted!
TX Hash: 14223ac9adf33b77e4b52e8612dd351517b1bbc5b771567089994a6183f46df2
BSCScan: https://bscscan.com/tx/14223ac9adf33b77e4b52e8612dd351517b1bbc5b771567089994a6183f46df2
```

{% endcode %}
{% endstep %}
{% endstepper %}

<details>

<summary>Complete Example: Private BNB Transfer</summary>

```javascript
import WebSocket from "ws";
import { ethers } from "ethers";
import "dotenv/config";

const PRIVATE_KEY = process.env.PRIVATE_KEY;
const RPC_URL = process.env.RPC_URL;

async function sendPrivateTransaction(recipient, amountBNB) {
  const provider = new ethers.JsonRpcProvider(RPC_URL);
  const wallet = new ethers.Wallet(PRIVATE_KEY, provider);

  console.log("Wallet:", wallet.address);
  console.log("Recipient:", recipient);
  console.log("Amount:", amountBNB, "BNB");
  console.log("Mode: Private (MEV Protected)");

  // Get nonce
  const nonce = await provider.getTransactionCount(wallet.address);

  // Build transaction
  const signedTx = await wallet.signTransaction({
    nonce: nonce,
    to: recipient,
    value: ethers.parseEther(amountBNB),
    gasPrice: ethers.parseUnits("3", "gwei"),
    gasLimit: 21000,
    chainId: 56,
  });
const signedTxNoPrefix = signedTx.startsWith("0x")
  ? signedTx.slice(2)
  : signedTx;


  // Submit privately
  const ws = new WebSocket(process.env.ACCESS_TOKEN);

  return new Promise((resolve, reject) => {
    ws.on("open", () => {
      console.log("\nSubmitting private transaction...");

      ws.send(
        JSON.stringify({
          jsonrpc: "2.0",
          id: 1,
          method: "bsc_private_tx",
          params: {
            transaction: signedTxNoPrefix,
            mev_builders: ["all"],
          },
        }),
      );
    });

    ws.on("message", (data) => {
      const response = JSON.parse(data);
      ws.close();

      if (response.result) {
        console.log("\n✅ Private transaction submitted!");
        console.log("TX Hash:", response.result.txHash);
        console.log(
          "BSCScan:",
          `https://bscscan.com/tx/${response.result.txHash}`,
        );
        resolve(response.result.txHash);
      } else {
        console.error("\n❌ Error:", response.error);
        reject(response.error);
      }
    });

    ws.on("error", reject);
  });
}

// Usage
sendPrivateTransaction(process.env.TO_ADDRESS, "0.001").catch(console.error);

```

</details>

<details>

<summary>Complete Example: MEV-Protected PancakeSwap Trade</summary>

```javascript
import  WebSocket from 'ws';
import { ethers } from 'ethers';
import 'dotenv/config';

const PRIVATE_KEY = process.env.PRIVATE_KEY;
const RPC_URL = process.env.RPC_URL;
const PANCAKE_ROUTER = '0x10ED43C718714eb63d5aA57B78B54704E256024E';
const WBNB = '0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c';

async function privateSwap(tokenAddress, amountBNB, minAmountOut) {
  const provider = new ethers.JsonRpcProvider(RPC_URL);
  const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
  
  // Router ABI
  const routerABI = [
    'function swapExactETHForTokens(uint256 amountOutMin, address[] path, address to, uint256 deadline) payable'
  ];
  const router = new ethers.Contract(PANCAKE_ROUTER, routerABI, wallet);
  
  // Build swap calldata
  const deadline = Math.floor(Date.now() / 1000) + 300;
  const swapData = router.interface.encodeFunctionData('swapExactETHForTokens', [
    minAmountOut,
    [WBNB, tokenAddress],
    wallet.address,
    deadline
  ]);
  
  // Get nonce
  const nonce = await provider.getTransactionCount(wallet.address);
  
  // Sign transaction
  const signedTx = await wallet.signTransaction({
    nonce: nonce,
    to: PANCAKE_ROUTER,
    value: ethers.parseEther(amountBNB),
    data: swapData,
    gasPrice: ethers.parseUnits('3', 'gwei'),
    gasLimit: 300000,
    chainId: 56
  });
  
  console.log('Swap details:');
  console.log('  Amount:', amountBNB, 'BNB');
  console.log('  Token:', tokenAddress);
  console.log('  Min out:', ethers.formatEther(minAmountOut));
  console.log('  Mode: Private (MEV Protected)');
  
  // Submit privately
  const ws = new WebSocket(`wss://go.getblock.io/${process.env.ACCESS_TOKEN}`);
  
  return new Promise((resolve, reject) => {
    ws.on('open', () => {
      ws.send(JSON.stringify({
        jsonrpc: '2.0',
        id: 1,
        method: 'bsc_private_tx',
        params: {
          transaction: signedTx,
          mev_builders: ['all']
        }
      }));
    });
    
    ws.on('message', (data) => {
      const response = JSON.parse(data);
      ws.close();
      
      if (response.result) {
        console.log('\n✅ Private swap submitted!');
        console.log('TX Hash:', response.result.txHash);
        console.log('BSCScan:', `https://bscscan.com/tx/${response.result.txHash}`);
        resolve(response.result.txHash);
      } else {
        console.error('\n❌ Error:', response.error);
        reject(response.error);
      }
    });
  });
}

// Usage: Swap 1 BNB for BUSD (MEV protected)
privateSwap(
  '0xe9e7CEA3DedcA5984780Bafc599bD69ADd087D56',  // BUSD
  '1.0',                                          // 1 BNB
  ethers.parseEther('200')                        // Min 200 BUSD
).catch(console.error);
```

</details>

### Selecting Specific Builders

There are list of builders who should receive the transaction without delay. There are:

* `bloxroute`: bloXroute internal builder(default)
* `all`: all builders
* Other options: `48club`, `blockrazor`, `jetbldr`, `nodereal`

```javascript
params: {
  transaction: signedTx,
  mev_builders: ['48club', 'bloxroute']  // Specific builders only
}
```

### Troubleshooting

<table><thead><tr><th width="283.4609375">Problem</th><th>Solution</th></tr></thead><tbody><tr><td>Transaction not included</td><td><p></p><p>Without a priority tip, private transactions compete based on gas fees alone. If your transaction isn't being included:</p><ul><li>Increase gas price — Higher gas = higher priority for builders</li><li>Add a priority tip — See <a href="/pages/Wtc83r35jvlheJeDOrVs">Private Transactions with Tips</a></li><li>Try specific builders — Some builders may be more responsive</li></ul></td></tr><tr><td>"Invalid transaction"</td><td><p></p><ul><li>Verify your transaction is properly signed</li><li>Check the chain ID is <code>56</code> (BSC Mainnet)</li><li>Ensure the nonce is correct</li></ul></td></tr><tr><td>Connection issues</td><td><p></p><ul><li>Verify your API key is valid</li><li>Check network connectivity</li><li>Try reconnecting after a few seconds</li></ul></td></tr></tbody></table>

### Next Steps

To increase the priority for inclusion in your private transactions, see [Private Transactions with Tips.](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/sending-transactions-to-private-mempool-priority-fee)


# Sending Transactions to Private Mempool (Priority Fee)

Learn how to add tips to transaction while sending to private mempool

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

## Choosing a Method

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

| Method                                                                                                                                            | Best For                                           | Trade-offs                                          |
| ------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | --------------------------------------------------- |
| [**Multicall3**](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/sending-transactions-to-private-mempool-priority-fee/how-to-use-multicall3) | Most use cases                                     | Single nonce, atomic execution, slightly higher gas |
| [**Bundle**](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/sending-transactions-to-private-mempool-priority-fee/how-to-use-bundle)         | Advanced scenarios requiring separate transactions | Two nonces, more complex setup                      |

### Different Between Bundles and  Transactions

Choose the appropriate method based on your use case:

| **Method**                | `bsc_privateTx`                    | `mev_sendBundle`                 |
| ------------------------- | ---------------------------------- | -------------------------------- |
| **Transaction count**     | Single                             | Multiple                         |
| **Atomicity**             | Not applicable                     | All-or-nothing execution         |
| **Use cases**             | Simple transfers, individual swaps | Arbitrage, multi-step operations |
| **Adding priority fees**  | Via Multicall3                     | Separate transaction in bundle   |
| **`mev_builders` format** | Array: `["all"]`                   | Object: `{"all": ""}`            |

### Next Steps

Learn how to submit transactions via [Multicall3](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/sending-transactions-to-private-mempool-priority-fee/how-to-use-multicall3) or [Bundle](/bsc-advanced-tooling/bsc-accelerated-dedicated-node/sending-transactions-to-private-mempool-priority-fee/how-to-use-bundle) method to the private mempool.&#x20;


# How to Use Multicall3

Multicall3 batches multiple operations into a single transaction with atomic execution.

Multicall3 batches multiple operations into a single transaction with atomic execution using `bsc_private_tx` to get MEV protection with internal fee payment.&#x20;

This is very good for most use cases, e.g., DEX swaps, token purchases, etc but consumes a lot of gas. If any part fails, the entire transaction reverts.

### **How it works**

This is how Multicall3 works:

{% @mermaid/diagram content="graph TD
A(\[Your Wallet]) --> B

```
subgraph Execution ["Smart Contract Execution"]
    B[Multicall3 Contract]
    B --> C[Call 1: Send tip to gateway fee address]
    B --> D[Call 2: Execute your actual transaction]
end

C --> E
D --> E

subgraph Submission ["MEV-Protected Submission"]
    E[bsc_private_tx]
end" %}
```

### Prerequisites

You must have the following:

* Node.js v18 or later installed
* A funded BSC wallet with sufficient BNB for transactions and gas
* GetBlock's BSC Accelerated Dedication Node

### Reference Addresses

| Address                                      | Purpose               |
| -------------------------------------------- | --------------------- |
| `0xcA11bde05977b3631167028862bE2a173976CA11` | Multicall3 contract   |
| `0x6374Ca2da5646C73Eb444aB99780495d61035f9b` | Gateway fee recipient |

### Example

{% stepper %}
{% step %}
Set up the project

{% tabs %}
{% tab title="npm" %}

```bash
mkdir multicall3-example
cd multicall3-example
npm init -y
npm install ws ethers dotenv
```

{% endtab %}

{% tab title="yarn" %}

```bash
mkdir multicall3-example
cd multicall3-example
yarn init -y
yarn ws ethers
```

{% endtab %}
{% endtabs %}
{% endstep %}

{% step %}
Create a new file named `index.js`. This is where you will make your first call.
{% endstep %}

{% step %}
Set the ES module `"type": "module"` in your `package.json`.
{% endstep %}

{% step %}
Create `.env` file and add the following:

{% code overflow="wrap" %}

```js
ACCESS_TOKEN=your-accelerated-node-endpoint
RPC_URL=your-normal-bsc-node-endppoint //e.g https
PRIVATE_KEY=your-wallet-private-key
```

{% endcode %}
{% endstep %}

{% step %}
Add the following code to `index.js`:

The following example demonstrates a simple BNB transfer with a priority fee:

{% code overflow="wrap" %}

```js
import WebSocket from "ws"; 
import { ethers } from "ethers";
import "dotenv/config";
const PRIVATE_KEY = process.env.PRIVATE_KEY
const RPC_URL = process.env.RPC_URL;

// Constants
const MULTICALL3 = "0xcA11bde05977b3631167028862bE2a173976CA11";
const BLOXROUTE_FEE = "0x6374Ca2da5646C73Eb444aB99780495d61035f9b";

const MULTICALL_ABI = [
  "function aggregate3Value(tuple(address target, bool allowFailure, uint256 value, bytes callData)[] calls) payable returns (tuple(bool success, bytes returnData)[])",
];

async function sendPrivateTxWithTip() {
  const provider = new ethers.JsonRpcProvider(RPC_URL);
  const wallet = new ethers.Wallet(PRIVATE_KEY, provider);

  console.log("Wallet:", wallet.address);

  // Define amounts
  const tipAmount = ethers.parseEther("0.0001"); // 0.0001 BNB tip
  const transferAmount = ethers.parseEther("0.001"); // Your actual transfer
  const totalValue = tipAmount + transferAmount;

  // Build Multicall3 calls
  const calls = [
    {
      target: BLOXROUTE_FEE, // Tip payment FIRST
      allowFailure: false,
      value: tipAmount,
      callData: "0x", // Empty = simple transfer
    },
    {
      target: process.env.TO_ADDRESS, // Your actual transaction
      allowFailure: false,
      value: transferAmount,
      callData: "0x", // Or your contract calldata
    },
  ];
  // Encode Multicall3 call
  const multicall = new ethers.Contract(MULTICALL3, MULTICALL_ABI, wallet);
  const data = multicall.interface.encodeFunctionData("aggregate3Value", [
    calls,
  ]);
  // Get nonce
  const nonce = await provider.getTransactionCount(wallet.address);
  // Sign transaction
  const signedTx = await wallet.signTransaction({
    nonce: nonce,
    to: MULTICALL3,
    value: totalValue,
    data: data,
    gasPrice: ethers.parseUnits("3", "gwei"),
    gasLimit: 150000, // Higher for Multicall3
    chainId: 56,
  });
  const signedTxNoPrefix = signedTx.startsWith("0x")
  ? signedTx.slice(2)
  : signedTx;

  console.log("Transaction built:");
  console.log("  Tip:", ethers.formatEther(tipAmount), "BNB");
  console.log("  Transfer:", ethers.formatEther(transferAmount), "BNB");
  console.log("  Total:", ethers.formatEther(totalValue), "BNB");

  // Send via bsc_private_tx
  const ws = new WebSocket(process.env.ACCESS_TOKEN);

  ws.on("open", () => {
    const request = {
      jsonrpc: "2.0",
      id: 1,
      method: "bsc_private_tx",
      params: {
        transaction: signedTxNoPrefix,
        mev_builders: ["all"],
      },
    };

    console.log("\nSending private TX with tip...");
    ws.send(JSON.stringify(request));
  });

  ws.on("message", (data) => {
    const response = JSON.parse(data);

    if (response.result) {
      console.log("\n✅ Transaction submitted!");
      console.log("TX Hash:", response.result.txHash);
      console.log(
        "BSCScan:",
        `https://bscscan.com/tx/${response.result.txHash}`,
      );
    } else {
      console.error("\n❌ Error:", response.error);
    }

    ws.close();
  });
}
sendPrivateTxWithTip().catch(console.error);

```

{% endcode %}
{% endstep %}

{% step %}
Run the code using this command:

```bash
node index.js
```

{% endstep %}

{% step %}
Sample response

{% code overflow="wrap" %}

```bash
Wallet: 0xD1AF2dAc.....
Transaction built:
  Tip: 0.0001 BNB
  Transfer: 0.001 BNB
  Total: 0.0011 BNB
Sending private TX with tip...
✅ Transaction submitted!
TX Hash: 61bd625be986bb45e9fb495a5dba7bf39e00fd6871176971663436465311c970
BSCScan: https://bscscan.com/tx/61bd625be986bb45e9fb495a5dba7bf39e00fd6871176971663436465311c970
```

{% endcode %}
{% endstep %}
{% endstepper %}

### Extension sample&#x20;

You can extend this code for a DEX swap by encoding the router call and including it as the second Multicall3 call:

{% code overflow="wrap" %}

```javascript
const PANCAKE_ROUTER = '0x10ED43C718714eb63d5aA57B78B54704E256024E';
const WBNB = '0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c';
const TOKEN_ADDRESS = '0xYOUR_TOKEN_ADDRESS';

// Build the swap calldata
const routerABI = [
  'function swapExactETHForTokens(uint256 amountOutMin, address[] path, address to, uint256 deadline)'
];
const router = new ethers.Contract(PANCAKE_ROUTER, routerABI, wallet);

const deadline = Math.floor(Date.now() / 1000) + 300;  // 5 minutes from now
const swapData = router.interface.encodeFunctionData('swapExactETHForTokens', [
  minAmountOut,
  [WBNB, TOKEN_ADDRESS],
  wallet.address,
  deadline
]);

// Construct the Multicall3 calls
const calls = [
  {
    target: BLOXROUTE_FEE,
    allowFailure: false,
    value: ethers.parseEther('0.0005'),  // Priority fee
    callData: '0x'
  },
  {
    target: PANCAKE_ROUTER,
    allowFailure: false,
    value: ethers.parseEther('1.0'),  // Swap amount
    callData: swapData
  }
];
```

{% endcode %}

### Troubleshooting

| Problem                   | Solution                                                                                                                                                       |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "Multicall3: call failed" | <p></p><ul><li>Check you have enough BNB for all calls + gas</li><li>Increase gas limit to 200000</li><li>Verify target addresses are correct</li></ul>        |
| TX not included           | <p></p><ul><li>Increase tip amount</li><li>Check if you're rate limited</li><li>Verify TX is valid (simulate first)</li></ul>                                  |
| Low priority despite tip  | <p></p><ul><li>Increase tip amount</li><li>Check builder status</li><li>Try different builders: <code>mev\_builders: \["48club", "bloxroute"]</code></li></ul> |

### Conclusion

This is the simplest method for adding tips to private transactions: batch multiple operations into a single transaction with atomic execution. \
This is very good and highly recommended for day-to-day activities like sending transactions or DEX swaps. &#x20;


# How to use Bundle

This guide explains how to submit transaction bundles on BNB Smart Chain using GetBlock's MEV endpoint.

A bundle is a group of transactions submitted together with a guarantee that either all transactions execute in sequence or none are included. This atomic execution model supports several advanced use cases:

* **Arbitrage:** Execute a buy on one DEX and a sell on another within the same block, ensuring both trades complete, or neither does
* **Liquidations:** Check a position's health and liquidate it atomically, preventing front-running
* **Complex strategies:** Coordinate multi-step transactions with guaranteed execution order

### Prerequisites

Before submitting bundles, ensure you have:

* A GetBlock API key with MEV endpoint access
* Node.js v16 or later
* A funded BSC wallet with sufficient BNB for all transactions and gas

### Sample Request

{% tabs %}
{% tab title="Endpoint" %}
Connect to the MEV WebSocket endpoint with your API key:

```bash
wss://go.getblock.io/<ACCESS_TOKEN>
```

{% endtab %}

{% tab title="Parameters" %}

| Parameter      | Type    | Required | Description                                                                         |
| -------------- | ------- | -------- | ----------------------------------------------------------------------------------- |
| `transactions` | array   | Yes      | Array of signed raw transactions (hex-encoded)                                      |
| `mev_builders` | object  | No       | Target builders. Use `{"all": ""}` for all builders, or specify individual builders |
| `blocks_count` | integer | No       | Number of blocks the bundle remains valid. Default: 5, Maximum: 20                  |
| {% endtab %}   |         |          |                                                                                     |

{% tab title="Request Format" %}
Submit bundles using the `mev_sendBundle` method:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "mev_sendBundle",
  "params": {
    "transactions": ["0xf86c...", "0xf86c..."],
    "mev_builders": { "all": "" },
    "blocks_count": 5
  }
}
```

{% endtab %}

{% tab title="Response Format" %}
A successful submission returns a bundle hash:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "bundleHash": "0x..."
  }
}
```

{% endtab %}
{% endtabs %}

### Example

{% stepper %}
{% step %}
Set up the project

{% tabs %}
{% tab title="npm" %}

```bash
mkdir bundle-example
cd bundle-example
npm init -y
npm install ws ethers dotenv
```

{% endtab %}

{% tab title="yarn" %}

```bash
mkdir bundle-example
cd bundle-example
yarn init -y
yarn ws ethers dotenv
```

{% endtab %}
{% endtabs %}
{% endstep %}

{% step %}
Create a new file named `index.js`. This is where you will make your first call.
{% endstep %}

{% step %}
Set the ES module `"type": "module"` in your `package.json`.
{% endstep %}

{% step %}
Create `.env` file and add the following:

{% code overflow="wrap" %}

```js
ACCESS_TOKEN=your-accelerated-node-endpoint
RPC_URL=your-normal-bsc-node-endppoint //e.g https
PRIVATE_KEY=your-wallet-private-key
```

{% endcode %}
{% endstep %}

{% step %}
Add the following code to `index.js`:

The following example demonstrates a simple BNB transfer with a priority fee:

{% code overflow="wrap" %}

```js
import WebSocket from "ws";
import { ethers } from "ethers";
import "dotenv/config";
const PRIVATE_KEY = process.env.PRIVATE_KEY;
const RPC_URL = process.env.RPC_URL;
async function submitBundle() {
  const provider = new ethers.JsonRpcProvider(RPC_URL);
  const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
  // Get the current nonce for your wallet
  const nonce = await provider.getTransactionCount(wallet.address);
  // Transaction 1: First operation
  const tx1 = await wallet.signTransaction({
    nonce: nonce,
    to: DEX_A,
    value: ethers.parseEther("0.001"),
    data: buyCalldata,
    gasPrice: ethers.parseUnits("3", "gwei"),
    gasLimit: 300000,
    chainId: 56,
  });
  // Transaction 2: Second operation (must use nonce + 1)
  const tx2 = await wallet.signTransaction({
    nonce: nonce + 1,
    to: DEX_B,
    value: 0,
    data: sellCalldata,
    gasPrice: ethers.parseUnits("3", "gwei"),
    gasLimit: 300000,
    chainId: 56,
  });
  // Connect to the MEV endpoint
  const ws = new WebSocket(process.env.ACCESS_TOKEN);

  ws.on("open", () => {
    ws.send(
      JSON.stringify({
        jsonrpc: "2.0",
        id: 1,
        method: "mev_sendBundle",
        params: {
          transactions: [tx1.slice(2), tx2.slice(2)],
          mev_builders: { all: "" },
          blocks_count: 5,
        },
      }),
    );
  });
  ws.on("message", (data) => {
    const response = JSON.parse(data);

    if (response.result) {
      console.log("Bundle submitted successfully");
      console.log("Bundle Hash:", response.result.bundleHash);
    } else {
      console.error("Submission failed:", response.error);
    }

    ws.close();
  });
}
submitBundle();
```

{% endcode %}
{% endstep %}

{% step %}
Run the code using this command:

```bash
node index.js
```

{% endstep %}

{% step %}
Sample response

```
```

{% endstep %}
{% endstepper %}

### Example: DEX Arbitrage

<details>

<summary>This example demonstrates a complete arbitrage strategy: buying a token on PancakeSwap V2 and selling on PancakeSwap V3 within the same block, with an optional priority fee.</summary>

#### Reference Addresses

| Address                                      | Purpose                |
| -------------------------------------------- | ---------------------- |
| `0x10ED43C718714eb63d5aA57B78B54704E256024E` | PancakeSwap V2 Router  |
| `0x13f4EA83D0bd40E75C8222255bc855a974568Dd4` | PancakeSwap V3 Router  |
| `0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c` | WBNB                   |
| `0x6374Ca2da5646C73Eb444aB99780495d61035f9b` | Priority fee recipient |

#### Code Example

{% code overflow="wrap" %}

```javascript
const WebSocket = require('ws');
const { ethers } = require('ethers');
import 'dotenv/config';

const PRIVATE_KEY = process.env.PRIVATE_KEY;
const RPC_URL= process.env.RPC_URL

// Contract addresses
const PANCAKE_V2_ROUTER = '0x10ED43C718714eb63d5aA57B78B54704E256024E';
const PANCAKE_V3_ROUTER = '0x13f4EA83D0bd40E75C8222255bc855a974568Dd4';
const FEE_ADDRESS = '0x6374Ca2da5646C73Eb444aB99780495d61035f9b';
const WBNB = '0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c';
const TOKEN = '0xYOUR_TOKEN';

async function arbitrage() {
  const provider = new ethers.JsonRpcProvider(RPC_URL);
  const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
  
  const nonce = await provider.getTransactionCount(wallet.address);
  const deadline = Math.floor(Date.now() / 1000) + 300;
  
  // Encode the V2 swap
  const v2ABI = [
    'function swapExactETHForTokens(uint256 amountOutMin, address[] path, address to, uint256 deadline) payable'
  ];
  const v2Router = new ethers.Contract(PANCAKE_V2_ROUTER, v2ABI, wallet);
  
  const buyData = v2Router.interface.encodeFunctionData('swapExactETHForTokens', [
    0,  // amountOutMin (set appropriately in production)
    [WBNB, TOKEN],
    wallet.address,
    deadline
  ]);
  
  // Transaction 1: Buy on PancakeSwap V2
  const tx1 = await wallet.signTransaction({
    nonce: nonce,
    to: PANCAKE_V2_ROUTER,
    value: ethers.parseEther('1.0'),
    data: buyData,
    gasPrice: ethers.parseUnits('3', 'gwei'),
    gasLimit: 300000,
    chainId: 56
  });
  
  // Transaction 2: Sell on PancakeSwap V3
  // Note: V3 uses a different interface; replace with your actual V3 swap calldata
  const tx2 = await wallet.signTransaction({
    nonce: nonce + 1,
    to: PANCAKE_V3_ROUTER,
    value: 0,
    data: '0x...',  // Your V3 swap calldata
    gasPrice: ethers.parseUnits('3', 'gwei'),
    gasLimit: 300000,
    chainId: 56
  });
  
  // Transaction 3: Priority fee (optional but recommended)
  const tx3 = await wallet.signTransaction({
    nonce: nonce + 2,
    to: FEE_ADDRESS,
    value: ethers.parseEther('0.001'),
    gasPrice: ethers.parseUnits('3', 'gwei'),
    gasLimit: 21000,
    chainId: 56
  });
  
  // Submit the bundle
  const ws = new WebSocket(process.env.ACCESS_TOKEN);
  
  return new Promise((resolve, reject) => {
    ws.on('open', () => {
      ws.send(JSON.stringify({
        jsonrpc: '2.0',
        id: 1,
        method: 'mev_sendBundle',
        params: {
          transactions: [tx1, tx2, tx3],
          mev_builders: { all: '' },
          blocks_count: 3  // Short validity for time-sensitive arbitrage
        }
      }));
    });
    
    ws.on('message', (data) => {
      const response = JSON.parse(data);
      ws.close();
      
      if (response.result) {
        console.log('Bundle submitted successfully');
        console.log('Bundle Hash:', response.result.bundleHash);
        resolve(response.result.bundleHash);
      } else {
        console.error('Submission failed:', response.error);
        reject(response.error);
      }
    });
  });
}

arbitrage();
```

{% endcode %}

</details>

### Comparing Bundles and Private Transactions

Choose the appropriate method based on your use case:

| Aspect                | `bsc_privateTx`                    | `mev_sendBundle`                 |
| --------------------- | ---------------------------------- | -------------------------------- |
| Transaction count     | Single                             | Multiple                         |
| Atomicity             | Not applicable                     | All-or-nothing execution         |
| Use cases             | Simple transfers, individual swaps | Arbitrage, multi-step operations |
| Adding priority fees  | Via Multicall3                     | Separate transaction in bundle   |
| `mev_builders` format | Array: `["all"]`                   | Object: `{"all": ""}`            |

### Best Practices

1\. Use Sequential Nonces

All transactions in a bundle must have consecutive nonces starting from your wallet's current nonce:

```javascript
const nonce = await provider.getTransactionCount(wallet.address);

// Transaction 1: nonce
// Transaction 2: nonce + 1
// Transaction 3: nonce + 2
```

2\. Include a Priority Fee

Adding a fee payment as the final transaction increases the likelihood of bundle inclusion:

```javascript
const feeTx = await wallet.signTransaction({
  nonce: lastNonce,
  to: '0x6374Ca2da5646C73Eb444aB99780495d61035f9b',
  value: ethers.parseEther('0.001'),
  gasPrice: ethers.parseUnits('3', 'gwei'),
  gasLimit: 21000,
  chainId: 56
});
```

### Choose an Appropriate blocks\_count Value

The `blocks_count` parameter determines how long your bundle remains valid. Shorter validity periods signal higher urgency to builders:

| Use Case                 | Recommended blocks\_count |
| ------------------------ | ------------------------- |
| Time-sensitive arbitrage | 2–3                       |
| Standard bundles         | 5                         |
| Less urgent operations   | 10–20                     |

## Simulate Before Submitting

Test your transaction logic before submitting a bundle by simulating each transaction:

```javascript
await provider.call({
  to: tx1.to,
  data: tx1.data,
  value: tx1.value
});
```

### Troubleshooting

| Problem                | Solution                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Bundle Not Included    | <p>If your bundle is not included after the specified block count:</p><ul><li><strong>Increase the priority fee</strong> — Add a higher fee payment transaction</li><li><strong>Verify nonce sequence</strong> — Nonces must be strictly consecutive with no gaps</li><li><strong>Reduce blocks\_count</strong> — Shorter validity signals higher priority to builders</li><li><strong>Validate each transaction</strong> — Ensure every transaction in the bundle is valid independently</li></ul> |
| "Invalid bundle" Error | <p></p><p>This error indicates a formatting or validation issue:</p><ul><li><strong>Check parameter format</strong> — The <code>transactions</code> parameter must be an array; <code>mev\_builders</code> must be an object</li><li><strong>Verify signatures</strong> — All transactions must be properly signed</li><li><strong>Confirm chain ID</strong> — Use chain ID 56 for BSC Mainnet</li></ul>                                                                                            |
| Partial Execution      | <p></p><p>Bundles execute atomically, so partial execution should not occur. If you observe partial execution:</p><ul><li><strong>Contact support</strong> — This indicates a potential builder issue</li><li><strong>Verify using the bundle hash</strong> — Check the bundle status on a block explorer</li></ul>                                                                                                                                                                                 |


# Overview

GetBlock Crypto AML is a compliance-grade risk-screening service for crypto addresses and transactions

GetBlock **Crypto** [**AML**](#user-content-fn-1)[^1] 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[^2]-aligned flags within seconds.

It is built to give small teams, exchanges, OTC[^3] desks, and individual traders the same FATF[^2]-aligned data and scoring as large compliance vendors, but **without** [**KYB**](#user-content-fn-4)[^4]**, annual contracts, or lengthy onboarding**.

{% hint style="info" %}
Access this service through your GetBlock account using a browser or the REST API. Charges use your existing credit balance.
{% endhint %}

### The problem it solves

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.

### Supported networks

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

| Tag   | Network      |
| ----- | ------------ |
| `ETH` | Ethereum     |
| `TRX` | TRON         |
| `BTC` | Bitcoin      |
| `LTC` | Litecoin     |
| `BCH` | Bitcoin Cash |

{% hint style="info" %}
More networks are on the roadmap (Solana, Arbitrum, Optimism). The `currencyTag` used in the API path is the tag from the table above (e.g. `ETH`, `BTC`).
{% endhint %}

#### Sources of signals

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.

{% hint style="info" %}
For the full model, thresholds, and how these combine into a score, see [**How risk scoring works**](/crypto-aml/how-risk-scoring-works).
{% endhint %}

### Access Crypto AML

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 three bearer-authenticated screening endpoints into your backend.

{% hint style="success" %}
Web and API checks use the same prepaid credit balance.
{% endhint %}

### Pricing

Choose a pricing model:

* **Pay as you go:** Top up your prepaid balance with a card or crypto. Each check deducts credits, starting at about $0.20. There are no subscriptions or minimums.
* **Bulk packages:** Buy checks upfront for a lower per-check rate. Larger packages receive larger discounts. Reach out to the [Sales team](mailto:support@getblock.io)

[^1]: Anti-Money Laundering (AML) consists of the laws, rules, and procedures used to stop criminals from hiding illegal "dirty" money as clean, legal income.

[^2]: The **Financial Action Task Force (FATF)** is an intergovernmental policy-making body founded in 1989 by the G7 to establish global standards for combating money laundering, terrorist financing, and proliferation financing.

[^3]: over-the-counter

[^4]: KYB (Know Your Business) is the process of verifying corporate entities, institutional clients, and merchant partners instead of individual retail users.


# How Risk Scoring Works

Learn how Crypto AML evaluates signals, assigns risk bands, and reports exposure.

Crypto AML evaluates on-chain and off-chain signals for each wallet. It returns a composite risk score, risk band, exposure breakdown, flags, and attribution.

### Scoring process

Each check has three stages:

1. **Signals — "what we read":** The engine evaluates more than 30 criteria across two data families.
2. **Scoring engine:** Weighted signals produce a score from `0` to `100`. The engine combines supervised machine-learning models with heuristic rules. Median latency is under 400 ms.
3. **Return the report:** The report includes a composite score, band, exposure breakdown, FATF[^1]-aligned flags, and attribution.

{% hint style="info" %}
Conceptually, the scoring calculation is `score = Σ wᵢ·sᵢ`. Each `wᵢ` is a signal weight. Each `sᵢ` is a signal value.
{% endhint %}

### Signals evaluated

{% tabs %}
{% tab title="On-chain" %}

* On-chain behavioral patterns
* Wallet clusters
* Counterparty flow
* Smart contract exposure
* Direct & indirect exposure (hop distance to flagged addresses)
* Transaction volume & value concentration
* Peel-chain & layering patterns
* Mixer/tumbler interaction
* Bridge & cross-chain movement
* Wallet age & activity cadence
* Dormancy and sudden-reactivation signals
* Token-level exposure (per-asset flow scoring)
  {% endtab %}

{% tab title="Off-chain" %}

* Sanctions feeds (OFAC, EU, UN, and national lists)
* Public attribution data
* Law-enforcement intelligence
* Darknet-market address databases
* Ransomware & extortion address feeds
* Scam, phishing & fraud reports
* Exchange & VASP attribution
* Known mixer/tumbler service lists
* High-risk jurisdiction indicators
* Reported hack & exploit address sets
  {% endtab %}
  {% endtabs %}

### Risk bands and thresholds

The composite `riskScore` ranges from `0` to `100`. It maps to one `riskBand`. The thresholds are exact:

| **Band (`riskBand`)** | **Label** | **Score range** | **Meaning**                                                                           |
| --------------------- | --------- | --------------- | ------------------------------------------------------------------------------------- |
| `low`                 | Low       | **0–24**        | No material risk indicators in the current evaluation.                                |
| `medium`              | Medium    | **25–49**       | Minor exposure detected. Reasonable to proceed after a quick review.                  |
| `high`                | High      | **50–74**       | Notable exposure to risky counterparties. Review details before accepting funds.      |
| `very-high`           | Very high | **75–100**      | Strong match with high-risk activity. Do not transact without enhanced due diligence. |

{% hint style="info" %}
**Scores are estimates, not definitive verdicts.** They combine weighted signals, machine-learning models, and updated data sources. So it is an estimate, not a definitive verdict. The same address can score slightly differently over time as on-chain activity, attribution data, and sanctions feeds change, and a result may sit near a band boundary. Treat the score and band as **one input to your own risk decision**, apply your own policy thresholds, and account for this natural fluctuation when acting on any particular result.

For **origin-of-funds** investigations, use our [**KYT**](#user-content-fn-2)[^2] **tool**. It traces movements between an address, its counterparties, and related addresses.
{% endhint %}

### FATF flags

Each report includes discrete FATF[^1]-aligned flags for case records. The product can return these flags:

* `sanctions_list_match` — *Sanctions list match*
* `darknet_market_exposure` — *Darknet market exposure*
* `mixer_interaction` — *Mixer/tumbler interaction*
* *Ransomware-associated cluster*, *Scam/phishing cluster*, and *High-risk jurisdiction*

{% hint style="info" %}
Values in `snake_case` are API values. Italic text is the UI label.
{% endhint %}

### Risk Categories

<table data-search="false"><thead><tr><th width="231.03125">API category</th><th width="157.353515625">Public label</th><th>Group</th><th width="226.708984375">Customer-facing meaning</th></tr></thead><tbody><tr><td><code>cyberThreatActivity</code></td><td>Cyber threat activity</td><td>Risk</td><td>Activity linked to hacking, phishing, malicious software, stolen credentials, compromised wallets or accounts, and attacks against blockchain protocols or digital services.</td></tr><tr><td><code>extortionActivity</code></td><td>Extortion activity</td><td>Risk</td><td>Activity involving ransomware-related extortion, ransom demands, blackmail, or other coercive attempts to obtain assets.</td></tr><tr><td><code>fraudulentSchemes</code></td><td>Fraudulent schemes</td><td>Risk</td><td>Deceptive schemes intended to obtain funds or assets, including scams and fraudulent investment structures.</td></tr><tr><td><code>stolenAssets</code></td><td>Stolen assets</td><td>Risk</td><td>Funds or other digital assets reported as stolen, misappropriated, or connected to theft.</td></tr><tr><td><code>darknetActivity</code></td><td>Darknet activity</td><td>Risk</td><td>Activity associated with darknet marketplaces or services used for illegal purposes.</td></tr><tr><td><code>illegalGoodsTrafficking</code></td><td>Illegal goods trafficking</td><td>Risk</td><td>Activity associated with the production, sale, or distribution of prohibited goods, including controlled drugs or weapons.</td></tr><tr><td><code>childAbuse</code></td><td>Child abuse</td><td>Risk</td><td>Activity associated with the abuse or exploitation of children.</td></tr><tr><td><code>humanExploitation</code></td><td>Human exploitation</td><td>Risk</td><td>Activity associated with human trafficking, forced exploitation, or the unlawful trade of people.</td></tr><tr><td><code>terrorismAndExtremism</code></td><td>Terrorism and extremism</td><td>Risk</td><td>Activity associated with terrorist or extremist organizations, their operations, support, or financing.</td></tr><tr><td><code>proliferationFinancing</code></td><td>Proliferation financing</td><td>Risk</td><td>Activity associated with financing the proliferation of weapons of mass destruction.</td></tr><tr><td><code>transactionObfuscation</code></td><td>Transaction obfuscation</td><td>Risk</td><td>Use of services or techniques intended to conceal transaction origins, destinations, ownership, or movement of funds.</td></tr><tr><td><code>gambling</code></td><td>Gambling</td><td>Risk</td><td>Activity associated with gambling services.</td></tr><tr><td><code>otherCriminalActivity</code></td><td>Other criminal activity</td><td>Risk</td><td>Criminal activity that cannot be represented by a more specific public risk category.</td></tr><tr><td><code>sanctions</code></td><td>Sanctions</td><td>Compliance</td><td>A reported connection to an official sanctions designation or a jurisdiction subject to sanctions restrictions.</td></tr><tr><td><code>jurisdictionRisk</code></td><td>Jurisdiction risk</td><td>Compliance</td><td>Exposure associated with a jurisdiction identified as presenting elevated AML or counter-terrorist-financing risk.</td></tr><tr><td><code>limitedComplianceControls</code></td><td>Limited compliance controls</td><td>Compliance</td><td>Exposure to a service with weak, missing, or insufficient identity verification and compliance controls.</td></tr><tr><td><code>legalAndRegulatoryAttention</code></td><td>Legal and regulatory attention</td><td>Compliance</td><td>A signal requiring enhanced review because of regulatory, legal, enforcement, political-exposure, litigation, or asset-seizure context.</td></tr><tr><td><code>otherComplianceRisk</code></td><td>Other compliance risk</td><td>Compliance</td><td>A compliance-related concern that does not fit a more specific public category.</td></tr><tr><td><code>insufficientInformation</code></td><td>Insufficient information</td><td>Compliance</td><td>Available information is not sufficient to assign a meaningful risk or entity category.</td></tr><tr><td><code>assetRestriction</code></td><td>Asset restriction</td><td>Compliance</td><td>A specific asset associated with the address has been restricted or blocked by its issuer or another responsible authority.</td></tr><tr><td><code>assetTradingService</code></td><td>Asset trading service</td><td>Entity / service</td><td>A service used to buy, sell, or exchange digital assets, including direct and brokered trading models.</td></tr><tr><td><code>decentralizedFinance</code></td><td>Decentralized finance</td><td>Entity / service</td><td>A decentralized protocol or application providing trading, lending, staking, or other financial functionality.</td></tr><tr><td><code>walletAndCustody</code></td><td>Wallet and custody</td><td>Entity / service</td><td>A wallet or custody service that stores, manages, or safeguards digital assets.</td></tr><tr><td><code>paymentsAndCommerce</code></td><td>Payments and commerce</td><td>Entity / service</td><td>A service facilitating cryptocurrency payments, purchases, or commercial transactions.</td></tr><tr><td><code>fundraisingAndInvestment</code></td><td>Fundraising and investment</td><td>Entity / service</td><td>Activity involving investment products, fundraising, donations, crowdfunding, or charitable funding.</td></tr><tr><td><code>miningActivity</code></td><td>Mining activity</td><td>Entity / service</td><td>Activity associated with cryptocurrency mining, mining pools, or remotely provided mining services.</td></tr><tr><td><code>onchainApplication</code></td><td>On-chain application</td><td>Entity / service</td><td>A blockchain application or smart-contract-based service, including games and digital-asset applications.</td></tr><tr><td><code>technologyInfrastructure</code></td><td>Technology infrastructure</td><td>Entity / service</td><td>Technical infrastructure or hosting used to support blockchain or digital-asset services.</td></tr><tr><td><code>institutionalEntity</code></td><td>Institutional entity</td><td>Entity / service</td><td>A government, political, educational, cultural, or media organization.</td></tr><tr><td><code>personalWallet</code></td><td>Personal wallet</td><td>Entity / service</td><td>An address attributed to an individual rather than an identified service or organization.</td></tr><tr><td><code>adultContentService</code></td><td>Adult content service</td><td>Entity / service</td><td>A service associated with adult content or related commercial activity.</td></tr></tbody></table>

### Exposure in the detailed report

The detailed API v2 and UI reports score several exposure axes. This prevents a clean balance from masking historical risk:

<table><thead><tr><th width="206.55078125">Axis</th><th>What it measures</th></tr></thead><tbody><tr><td><strong>Historical exposure</strong></td><td>Aggregated risk across the wallet's entire on-chain history.</td></tr><tr><td><strong>Current exposure</strong></td><td>Risk weighted to the current balance and recent activity from about 90 days.</td></tr><tr><td><strong>Direct interaction risk</strong></td><td>Exposure from counterparties one hop away — scored separately for incoming and outgoing flow.</td></tr><tr><td><strong>Token-level breakdown</strong></td><td>Each token on the wallet is scored independently — a clean ETH balance does not mask a risky USDT flow.</td></tr></tbody></table>

### Attribution

The report includes attribution when it can establish an identity:

* `cluster` — A cluster identifier, such as `cluster_4f2a`.
* `labels` — Entity names or inferred tags, such as `["sanctioned_entity", "mixer"]`.

[^1]: The **Financial Action Task Force (FATF)** is an intergovernmental policy-making body founded in 1989 by the G7 to establish global standards for combating money laundering, terrorist financing, and proliferation financing.

[^2]: KYT stands for **Know Your Transaction**. It is an anti-money laundering (AML) and risk-mitigation process that tracks, analyzes, and evaluates financial transfers—especially in the cryptocurrency and fintech sectors—to detect illicit activities, sanctions exposure, and suspicious patterns in real time


# Run a check in the dashboard

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

{% hint style="info" %}
Getting started takes three things: sign up with an email, top up balance, and start screening. **No KYB and no annual contract.**
{% endhint %}

Entry point: [https://account.getblock.io/products/aml-check](https://account.getblock.io/products)→ **Run a check**.

### Screening in three steps

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

<table><thead><tr><th width="86.8984375">Step</th><th>Action</th></tr></thead><tbody><tr><td><strong>01</strong></td><td><strong>Pick a network</strong> — <code>ETH</code>, <code>TRX</code> , <code>BTC</code>,  <code>LTC</code>, <code>BCH</code> </td></tr><tr><td><strong>02</strong></td><td><strong>Paste a wallet or transaction</strong> — an address or a transaction hash.</td></tr><tr><td><strong>03</strong></td><td><strong>Read the report</strong> — a risk score, exposure breakdown, and FATF flags in seconds.</td></tr></tbody></table>

#### Reading the result 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.
* **Owner** — the known entity believed to control the address, such as an exchange or service. An owner is an identity signal and does **not** have its own risk score.
* **Cluster** — a group of addresses linked through common control or on-chain behaviour. Unlike an owner, a cluster has its own risk score and can raise the wallet’s total score even when the address has little history or no risky current balance.
* **Labels** — external-list memberships associated with the address, such as an issuer freeze, sanctions reference, or functional role such as contract deployer. Critical labels are highlighted, but a label is not automatically a risk score or proof of wrongdoing.
* **Why this score** — the principal wallet-wide drivers, including FATF category matches, cluster risk, and confirmed external reports. Each driver has its own impact level; these values do not add up directly to the total score.
* **FATF indicators** — flagged counterparties grouped by category, direction of funds, interaction count, and risk level. Rows are evaluated independently and should not be added together.
* **Wallet exposure** — when available, a composition view showing each category’s share of the screened historical exposure. These percentages are exposure shares, **not** risk scores and **not** percentages of the current wallet balance.
* **Calculation ID and PDF export** — the calculation ID identifies the exact screening result. Save it with the PDF and timestamp so the decision can be reconstructed later.

{% hint style="success" %}
Every check can be **exported as a PDF** — address, score, exposure breakdown and flags — ready to attach to a case file. Checks are also stored server-side under your account.
{% endhint %}

#### Telegram bot (coming soon)

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

{% hint style="warning" %}
Reports are generated for informational purposes only. Risk scores are probabilistic and provided "as is" — they must not be the sole basis for regulatory, legal or financial decisions.
{% endhint %}


# Run check via API

## Using the AML API

GetBlock Crypto AML screens crypto wallets and transactions for money-laundering and sanctions risk. Send an address or a transaction hash, get back a JSON risk report — a 0–100 score, the components that produced it, and attribution.

Two endpoints, one for each target:

| Target                                    | Endpoint                    |
| ----------------------------------------- | --------------------------- |
| [A wallet](#screening-a-wallet)           | `POST /v1/aml/wallet-check` |
| [A transaction](#screening-a-transaction) | `POST /v1/aml/tx-check`     |

Both are bearer-authenticated, billed per check from your prepaid balance, and return the report inside a `data` envelope.

### Authentication

The AML API uses bearer auth with a single token per account — the same token that powers UI billing.

```http
Authorization: Bearer YOUR_API_TOKEN
Content-Type: application/json
```

Generate a token in the dashboard: **API keys** → [account.getblock.io/settings/api-keys](https://account.getblock.io/settings/api-keys)

**Base URL:** `https://services.getblock.io`

### Supported networks

| Value | Network             |
| ----- | ------------------- |
| `eth` | Ethereum            |
| `trx` | TRON                |
| `btc` | Bitcoin             |
| `ltc` | Litecoin            |
| `bch` | Bitcoin Cash        |
| —     | TON *(coming soon)* |

Values are case-insensitive. Any other value returns `400`:

```json
{ "data": null, "error": "Supported networks: bch, btc, eth, ltc, trx" }
```

***

## Screening a wallet

Covers every asset the address holds, in one report. Use it to check a counterparty before you transact, or to screen a wallet at onboarding.

#### Request

`POST /v1/aml/wallet-check`

| Field     | Type   | Required | Description                                            |
| --------- | ------ | -------- | ------------------------------------------------------ |
| `address` | string | yes      | Wallet address to screen. Must be valid for `network`. |
| `network` | string | yes      | See [supported networks](#supported-networks) above.   |

```bash
curl -X POST "https://services.getblock.io/v1/aml/wallet-check" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"address":"0x8589427373D6D84E98730D7795D8f6f8731FDA16","network":"eth"}'
```

#### Response

```json
{
  "data": {
    "contractVersion": "2",
    "coverage": "walletOverall",
    "overallRiskScore": 100,
    "tokenList": [],
    "breakdown": {
      "history": {
        "score": 40.15,
        "tags": [
          {
            "category": "dex",
            "share": 99.95
          },
          {
            "category": "hacking",
            "share": 0.05
          }
        ]
      },
      "externalReports": {
        "score": 100
      },
      "fatf": {
        "score": 100,
        "flags": [
          {
            "flow": "out",
            "reason": "hacking",
            "count": 5,
            "score": 75
          },
          {
            "flow": "in",
            "reason": "phishing",
            "count": 1,
            "score": 75
          }
        ]
      },
      "tokenFlags": {
        "score": 0
      }
    },
    "attribution": {
      "cluster": {
        "names": [
          "Ronin Bridge Exploiter",
          "OFAC SDN LAZARUS GROUP 13-09-2019"
        ],
        "score": 100
      },
      "categories": [
        "blacklist-usdc",
        "blacklist-usdt"
      ]
    },
    "tokenRisks": {},
    "calculationUid": "2329ec43-8275-4e6f-a07c-0f27807fa586"
  }
}

```

| Field                       | Type      | Description                                                                                                                |
| --------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------- |
| `contractVersion`           | string    | Response-contract version.                                                                                                 |
| `coverage`                  | string    | Scope of the result. `walletOverall` means the score applies to the wallet as a whole on the selected network.             |
| `overallRiskScore`          | number    | Wallet-wide risk score from `0` to `100`. This is the headline result.                                                     |
| `tokenList`                 | string\[] | Assets included in token-specific exposure.                                                                                |
| `breakdown`                 | object    | Wallet-wide evidence supporting the result.                                                                                |
| `breakdown.history`         | object    | Historical wallet exposure. Read its risk value from `score`; `tags`, when present, describe the exposure composition.     |
| `breakdown.externalReports` | object    | Risk derived from confirmed external reports.                                                                              |
| `breakdown.fatf`            | object    | FATF-relevant counterparty indicators. Optional `flags` contain direction, reason, interaction count and individual score. |
| `breakdown.tokenFlags`      | object    | Wallet-wide token-related flags. Present structurally, but may contain only `score: 0`.                                    |
| `attribution`               | object    | Identity, cluster and external-list information associated with the address.                                               |
| `attribution.owners`        | string\[] | Known entities believed to control the address. Owner is an identity signal and has no separate score. Optional.           |
| `attribution.cluster`       | object    | On-chain cluster attribution. Its `score` is always present; `names` and `tags` are optional.                              |
| `attribution.categories`    | string\[] | External-list labels such as issuer freezes, sanctions references or functional roles. Optional                            |
| `calculationUid`            | string    | Identifier of this screening calculation. Store it with the result and decision. Optional.                                 |

Each `*_risk` and `*_flags` field is an object — read `cluster_risk.risk_score`, not `cluster_risk`. Only `overall_risk_score` and `risk_score` are guaranteed; treat the rest as optional.

**Read the blocks, not just the score.** In the example above the wallet is nearly empty and every block is `0` except `cluster_risk: 70` — the score comes entirely from the cluster it belongs to, which `owners` names as Tornado Cash.

***

## Screening a transaction

Screens one transferred asset within a transaction, with its senders and receivers.

#### Request

`POST /v1/aml/tx-check`

| Field     | Type   | Required | Description                                                    |
| --------- | ------ | -------- | -------------------------------------------------------------- |
| `tx`      | string | yes      | Transaction hash to screen.                                    |
| `network` | string | yes      | See supported networks above.                                  |
| `asset`   | string | no       | Which transferred asset to score. Defaults to the native coin. |

A transaction carries specific transfers — the native coin, a token, or both. Each has its own counterparties and is scored on its own, so `asset` selects which transfer to score:

| Network      | Native | Tokens         |
| ------------ | ------ | -------------- |
| Ethereum     | `eth`  | `usdt`, `usdc` |
| TRON         | `trx`  | `usdt`         |
| Bitcoin      | `btc`  | —              |
| Litecoin     | `ltc`  | —              |
| Bitcoin Cash | `bch`  | —              |

Omit `asset` and the native coin is screened. More tokens are in the pipeline.

**Name the asset you're screening** — a check on a USDT payment should carry `"asset": "usdt"`, so the report covers the transfer you actually care about.

```bash
curl -X POST "https://services.getblock.io/v1/aml/tx-check" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tx":"YOUR_TX_HASH","network":"trx","asset":"usdt"}'
```

#### Response

```json
{
  "data": {
    "risk_score": 100,
    "addresses_in": {
      "0x1a2a1c938ce3ec39b6d47113c7955baa9dd454f2": 40,
      "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2": 34.85
    },
    "addresses_out": {
      "0x098b716b8aaf21512996dc57eb0615e2383e2f96": 100,
      "0x1a2a1c938ce3ec39b6d47113c7955baa9dd454f2": 40
    },
    "risk_tags": [
      { "tag": "dex(defi)",  "percent": 82.58 },
      { "tag": "exchange",    "percent": 9.39 },
      { "tag": "lending",     "percent": 4.35 },
      { "tag": "marketplace", "percent": 2.34 },
      { "tag": "hot_wallet",  "percent": 0.29 },
      { "tag": "mixer",       "percent": 0.15 },
      { "tag": "sanction",    "percent": 0.01 }
    ]
  }
}

```

.

***

### Reading the score

The headline number is 0–100, higher is riskier — `overall_risk_score` for wallets, `risk_score` for transactions.

Thresholds are your policy, not a verdict from the API. A common starting point: 0–24 proceed · 25–49 light review · 50–74 manual review · 75–100 block pending enhanced due diligence.

Scores move over time as a wallet keeps transacting. Store the score and the `calculation_uid` you acted on, so a decision can be reconstructed later.

{% hint style="info" %}
**How to use these scores**

Every check runs a deep analysis. We trace the wallet's transaction graph in both directions — inbound and outbound, across multiple hops — resolve cluster membership to establish who controls the funds, and score the wallet's history and its current holdings as separate questions. On top of that sit our own attribution work, machine learning models, and continuously updated sanctions and blacklist data. That is why a report tells you *where* risk comes from, not just how much.

**The result is an estimate, and it moves.** Risk scoring is probabilistic by nature. The same address can score differently over time as it keeps transacting, as counterparties change, and as attribution and sanctions data are updated. A score is a considered judgement built from many weighted signals — not a fixed property of the address.

**Use it to decide how much scrutiny a case deserves.** The right question is rarely "is this wallet good or bad?" — it is "does this one need enhanced due diligence, or can it proceed?" Read the risk blocks, not just the headline number: a `100` driven by `cluster_risk` on a regulated exchange means something very different from a `100` driven by `coins_risk` and `fatf_flags`. Set your own thresholds, apply your own policy, and record the `calculation_uid` you acted on so the decision can be reconstructed later.

**KYT is coming.** We're building a Know Your Transaction tool — a visual graph of an address, its counterparties and their interconnections — for cases where you need to trace the origin of funds yourself. Stay tuned.
{% endhint %}

{% hint style="warning" %}
Risk scores are probabilistic and provided "as is." Use them to inform your own risk decisions — not as the sole basis for regulatory, legal or financial decisions.
{% endhint %}

***

**See also:** Using AML via the API · How risk scoring works · Using AML via the UI


# Crypto Address Audit: Risk & Compliance APIs

Crypto Address Audit is GetBlock's risk and compliance suite for screening blockchain addresses before any interaction.

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](https://getblock.io/wallet-audit-check/), check out it [docs](/crypto-address-audit/wallet-audit), or access its [endpoint](/crypto-address-audit/api-reference/wallet-audit-endpoint)

2. **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 [Wallet Risk](https://getblock.io/wallet-risk-check/), check out it [docs](/crypto-address-audit/wallet-risk), or access its [endpoint](/crypto-address-audit/api-reference/wallet-risk-endpoint)

3. **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 [Rug Pull Checker](https://getblock.io/rug-pull-checker/), check out it [docs](/crypto-address-audit/rug-pull-checker), or access its [endpoint](/crypto-address-audit/api-reference/rug-pull-checker-endpoint)

### How to Access

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

1. Via the [Dashboard](https://account.getblock.io/products/address-audit): 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. [**Via the API** ](https://account.getblock.io/products/address-audit#api-keys)— 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. [Access the available endpoints here](/crypto-address-audit/api-reference).

### Pricing & Limits

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.

| Parameter         | Value           |
| ----------------- | --------------- |
| Free daily quota  | 5 requests      |
| Price per request | $0.20 USD       |
| Billing method    | Prepaid balance |

### How to Top Up Your Prepaid Credit

1. On your [account dashboard](https://account.getblock.io/), click on the credit balance as seen below:

<figure><img src="/files/84wN4NdK2appkBdXbYug" alt=""><figcaption></figcaption></figure>

2. Click on **Top Up**

<figure><img src="/files/gtHR0XUYcZGdzvihZvLV" alt=""><figcaption></figcaption></figure>

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

<figure><img src="/files/q5knyjXBu5vdpexkxgqk" alt=""><figcaption></figcaption></figure>

4. After that, click on **Proceed to checkout**
5. You'll be routed to another page to complete your payment

<figure><img src="/files/KxAK6AzClpxLFjLNqC7x" alt=""><figcaption></figcaption></figure>

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

{% hint style="info" %}
**Need a custom setup** (higher rate limits, dedicated infrastructure, SLA, or volume pricing)? [Contact the GetBlock team](https://getblock.io/contact/).
{% endhint %}

### Next Step

1. [Wallet Audit Doc](/crypto-address-audit/wallet-audit)
2. [Wallet Risk Doc](/crypto-address-audit/wallet-risk)
3. [Rug Pull Checker Doc](/crypto-address-audit/rug-pull-checker)
4. [Address Audit API Reference](/crypto-address-audit/api-reference)
5. [Wallet Audit Homepage](https://getblock.io/wallet-audit-check/)
6. [Wallet Risk Homepage](https://getblock.io/wallet-risk-check/)
7. [Rug Pull Checker Homepage](https://getblock.io/rug-pull-check/)


# Wallet Audit

GetBlock Wallet Audit: assess on-chain risk, AML exposure, and wallet behavior in seconds.

Wallet audit is a service that conducts risk assessments for an automated wallet on the blockchain. The service analyzes on-chain wallet behavior and provides a comprehensive report that includes a trust score, an AML check, a behavioral profile, a protocol interaction history, and predictive intentions.

{% hint style="warning" %}
*Wallet Audit provides automated risk indicators based on publicly available on-chain data. The results are for informational purposes only and do not constitute AML compliance verification, legal advice, or regulatory screening. We do not guarantee the accuracy or completeness of the data. The decision to interact with an address is made by the user.*
{% endhint %}

### Use Cases

Wallet Audit provides a complete behavioral wallet profile, not just a "fraud / not fraud" check. Below are six key scenarios where a full audit creates measurable value.

#### **1.  DeFi Protocol — Personalized Onboarding**

All users connecting to the protocol see the same interface, regardless of their experience, preferences, or financial capabilities. Beginners get lost in complex products, while experienced users don't see what they need.

With Wallet Audit, the moment a wallet connects, an audit runs instantly. Based on Risk Willingness, Experience, and Intentions, the protocol surfaces relevant products.&#x20;

**Example**:

* Beginner (Experience = 2, Risk Willingness = 3) → simple ETH staking, basic pools
* Experienced user (Experience = 10, Intentions: Leveraged Lending = HIGH) → directly to margin products, concentrated liquidity

> **Parameters used:** Experience Level, Risk Willingness, Intentions, Protocols

#### **2. Lending Protocol — Borrower Assessment**

In DeFi lending, all borrowers are assessed equally — only by collateral volume. There is no data on the borrower's financial stability or behavioral history.

With Wallet Audit, Risk Capability, Total Balance, and Experience, determine maximum loan size and collateral requirements.&#x20;

**Example**:

* Wallet A: Risk Capability = 1, balance $0.09, Experience = 10 → experienced but without funds. High collateral, low limit.
* Wallet B: Risk Capability = 8, balance $100K, Experience = 9 → experienced and financially stable. Standard collateral, increased limit.

> **Parameters used:** Risk Capability, Total Balance, Experience Level, Risk Willingness

#### **3. Growth/Marketing — User Base Segmentation**

Marketing campaigns in Web3 operate "blindly". The protocol only knows wallet addresses but doesn't understand who its users are, what they do, or what they need.

With Wallet Audit, a mass audit of connected wallets uses Transaction Categories, Protocols, and Intentions to split the base into cohorts for targeted marketing.&#x20;

Example:

* 40% of users with Prob\_Trade = HIGH and Uniswap interaction → launch a DEX aggregator for them
* 25% with Prob\_Lend = HIGH and Aave, Compound protocols → cross-promo with lending product
* 15% with Prob\_NFT = HIGH → partnership with NFT marketplace

> **Parameters used:** Transaction Categories, Protocols, Intentions, Experience Level

#### **4. Token Sale/Launchpad — Investor Quality Filtering**

Token sales are filled with airdrop farmers and bots who dump tokens on the first day of listing. Real investors don't receive allocation.

With Wallet Audit, Wallet Rank, Experience, and Risk Capability, provide objective applicant scoring. Allocation priority goes to wallets with a verified history.&#x20;

Example:

* Investor A: Wallet Rank in top 10K, Experience = 9, Risk Capability = 7, Intentions: Staking = HIGH → long-term holder, priority allocation
* Investor B: fresh wallet, 3 transactions, Wallet Rank = 0, Experience = 1 → likely farmer, low priority

> **Parameters used:** Wallet Rank, Experience Level, Risk Capability, Intentions, Transaction Count

#### **5. Quest Platforms — Adaptive Tasks and Sybil Protection**

Quest platforms (Layer3, Zealy, Galxe) offer the same tasks to everyone. Too difficult for beginners, too easy for experienced users. Bot farms collect rewards intended for real users.

With Wallet Audit, Experience and Protocols determine different quests for different levels, while Wallet Rank filters sybil accounts from real users.&#x20;

Example:

* Beginner (Experience = 2) → quest: "Make your first swap on Uniswap", "Stake ETH via Lido"
* Experienced (Experience = 8, Protocols: Aave, Lido, Curve) → quest: "Provide concentrated liquidity on Uniswap V3", "Create a leveraged position on Aave"
* Sybil filter: Wallet Rank < threshold or Transaction Count < 15 → wallet does not receive rewards

> **Parameters used:** Experience Level, Protocols, Wallet Rank, Transaction Count, Intentions

#### **6. Airdrop Campaigns — Farmer Filtering**

Most airdrop campaigns distribute tokens indiscriminately to everyone. Result — 80%+ of recipients sell on the first day, the price crashes, and real protocol users don't receive a fair allocation.

With Wallet Audit, Wallet Rank, Experience, and Transaction Categories objectively assess whether a wallet belongs to a real protocol user.

Example:

* Tier 1 (increased airdrop): Wallet Rank in top 20K, Experience >= 7, Transaction Categories include the protocol core category, AML = clean
* Tier 2 (standard airdrop): Wallet Rank in top 100K, Experience >= 4
* Exclusion: Wallet Rank = 0, Experience = 1, fewer than 15 transactions → airdrop farmer, does not receive allocation

> **Parameters used:** Wallet Rank, Experience Level, Transaction Categories, Predicted Trust, AML Analysis

{% hint style="danger" %}

### Limitations

* The service only works with regular wallets (EOA — Externally Owned Accounts). **Contract addresses are not supported.**
* A minimum of 10–15 transactions is required to calculate an accurate predictive score. Wallets with less history lack sufficient data for a reliable assessment
  {% endhint %}

### Supported Network

1. Ethereum(ETH)
2. BNB Smart Chain(BSC)
3. Base

### How to Audit a Wallet Address&#x20;

1. Go to your [GetBlock Account Dashboard](https://account.getblock.io/products/address-audit#check)

<figure><img src="/files/u8IbGyaJUxek1mn9OKL9" alt=""><figcaption></figcaption></figure>

2. Select the network you want to work with:

<figure><img src="/files/gO1qaWhfmdpQh42OpTZg" alt=""><figcaption></figcaption></figure>

3. Enter the wallet address you want to analyze:

<figure><img src="/files/M618gVF8rp8iZxqbupjQ" alt=""><figcaption></figcaption></figure>

4. Click on **Run Check:**<br>

<figure><img src="/files/OjSzIggHN1JmJGxXAweL" alt=""><figcaption></figcaption></figure>

5. Scroll down to see the analysis:

<figure><img src="/files/RIFVSH4VwMTB3hvJM4Nw" alt=""><figcaption></figcaption></figure>

<details>

<summary><strong>This report includes the following:</strong></summary>

1. Wallet balance, age, and number of transactions
2. Risk Willingness / Experience Level / Risk Capability scale

&#x20;         i. Risk Willingness: This measures psychological willingness to take risks. Determined by on-chain behavior: leverage usage, volatile assets, experimental protocols.

&#x20;          ii. Experience Level: This measures the depth and duration of Web3 activity: number of protocols, activity duration, transaction complexity, and multi-chain activity.

&#x20;           iii. Risk Capability: This measures financial ability to withstand losses, weighted by behavioral risk appetite.&#x20;

&#x20;      Roughly: available capital × Risk Willingness. A wallet with high willingness but a small balance gets a low Risk Capability — it can act riskily but cannot absorb meaningful loss.&#x20;

&#x20;       The reverse is also true: a large balance with low willingness scores low because the capital stays idle. ChainAware does not disclose the exact formula but considers asset size, diversification, and portfolio composition.&#x20;

3. Predicted trust score: The main safety indicator — the probability that the wallet is legitimate. Displayed as a percentage from 0% to 100%.

   | Range     | Level       | Interpretation                                           |
   | --------- | ----------- | -------------------------------------------------------- |
   | 80–100%   | Low Risk    | Behavior typical of legitimate wallets                   |
   | 50–80%    | Medium Risk | Warning signals present, additional analysis recommended |
   | Below 50% | High Risk   | Behavioral patterns match known fraud schemes            |
4. Intentions: This predicts the next actions across categories, each receiving a score of HIGH, MEDIUM, or LOW, calculated based on the wallet's entire historical activity.
5. Recommendations: These show activities based on the wallet's risk profile. Examples: WBTC holding, ETH holding, Stablecoin lending.
6. Transaction: This shows the breakdown of historical transactions by type: DeFi, Decentralized Exchanges, Layer 1, Layer 2, NFT, Bridge, Lending & Borrowing, Business Services, Gaming. Shows the number of transactions in each category.
7. Protocols: This lists the specific protocols and services the wallet has interacted with, along with transaction counts. Examples: 1inch, Uniswap, Wrapped Ether, Tether, Zora, Arbitrum, Starknet, Opensea.
8. AML Analysis: This shows wallet check across 18+ parameters for links to criminal activity. Each parameter is displayed as Yes or No.

</details>

If you want to interact with or integrate this service via API, check the [Wallet audit endpoint.](/crypto-address-audit/api-reference/wallet-audit-endpoint)

{% hint style="info" %}
**Need a custom setup** (higher rate limits, dedicated infrastructure, SLA, or volume pricing)? [Contact the GetBlock team](https://getblock.io/contact/).&#x20;
{% endhint %}

### Next Step

1. [Wallet Risk Doc](/crypto-address-audit/wallet-risk)
2. [Rug Pull Checker Doc](/crypto-address-audit/crypto-address-audit-risk-and-compliance-apis)
3. [Address Audit API Reference](/crypto-address-audit/api-reference)
4. [Wallet Audit Homepage](https://getblock.io/wallet-audit-check/)
5. [Wallet Risk Homepage](https://getblock.io/wallet-risk-check/)
6. [Rug Pull Checker Homepage](https://getblock.io/rug-pull-check/)


# Wallet Risk

GetBlock Wallet Risk: fast AI fraud screening for wallets — risk score, level, and flags.

Wallet Risk Check is a quick blockchain wallet risk assessment service. It returns an AI-predictive trust score, screening across 18 AML risk categories, and a sanctions check — in a single API call with response time under 100ms.

This is a lightweight version of [Wallet Audit](/crypto-address-audit/wallet-audit). Wallet Risk Check provides a quick go/no-go signal e.g "Can this wallet be trusted?"

{% hint style="info" %}
For a full behavioral profile (intentions, experience, protocols, transactions), use [Wallet Audit.](/crypto-address-audit/wallet-audit)
{% endhint %}

### What Wallet Risk Does?

* Predicted Trust Score (0–100%): AI-predictive trust score
* AML Risk Screening: screening across 18 risk categories (cybercrime, money laundering, phishing, etc.)
* Sanctions Check: verification against sanctions lists

### Difference Between Wallet Risk And Wallet Audit

| <p><br></p>                   | Wallet Risk Check                 | Wallet Audit                      |
| ----------------------------- | --------------------------------- | --------------------------------- |
| Response time                 | < 100ms                           | Several seconds                   |
| Trust Score                   | Yes                               | Yes                               |
| AML Screening (18 categories) | Yes                               | Yes                               |
| Sanctions Check               | Yes                               | Yes                               |
| Intentions (14 categories)    | No                                | Yes                               |
| Experience / Risk Profile     | No                                | Yes                               |
| Protocols / Categories        | No                                | Yes                               |
| Wallet Overview / Rank        | No                                | Yes                               |
| Networks                      | 5 (ETH, BNB, Base, Polygon, TRON) | 3 (ETH, BNB, Base)                |
| When to use                   | Quick screening: allow / reject   | Deep analysis: who is this wallet |

### How Predicted Trust Score is Calculated

They are two-step logic involved in this calculation:

#### Step 1: AML Check (hard override)

If at least one field in forensic\_details = "1" → probabilityFraud is automatically set to 1.0 (Predicted Trust = 0%). The ML model is not invoked. Any AML flag = automatic maximum risk.

#### Step 2: ML Model (if AML is clean)

If all forensic\_details fields = "0" → the predictive AI model analyzes on-chain wallet behavior and returns probabilityFraud from 0.0 to 1.0. Predicted Trust = 1 − probabilityFraud.

Examples:

* vitalik.eth: all forensic\_details = "0" → ML model → probabilityFraud = 0.042 → Predicted Trust = 95.8%
* Fraudulent wallet: money\_laundering = "1" → hard override → probabilityFraud = 1.0 → Predicted Trust = 0%

{% hint style="danger" %}

### Limitations

* The service only works with regular wallets (EOA — Externally Owned Accounts). **Contract addresses are not supported.**
* A minimum of 10–15 transactions is required to calculate an accurate predictive score. Wallets with less history lack sufficient data for a reliable assessment
  {% endhint %}

### Supported Networks

1. Ethereum(ETH)
2. BNB Smart Chain
3. Base&#x20;
4. Polygon
5. TRON

### How to Check the Risk In A Wallet Address

1. Go to your [GetBlock Account Dashboard](https://account.getblock.io/products/address-audit#check) and click **Wallet Risk**

<figure><img src="/files/mlMuZFimMxvKIX9Fhknm" alt="wallet risk"><figcaption></figcaption></figure>

2. Select the choice of your network using the dropdown:

<figure><img src="/files/fNWUdiiNW8lPSFsL7K6i" alt="network selection"><figcaption></figcaption></figure>

3. Enter the wallet address:

<figure><img src="/files/KWgt8uiaG8hzDENOwnzK" alt=""><figcaption></figcaption></figure>

4. Click on **Run Check:**

<figure><img src="/files/OjSzIggHN1JmJGxXAweL" alt=""><figcaption></figcaption></figure>

5. Scroll down to see the analysis:

<figure><img src="/files/vll6qw5eVnFhQv8NmTD5" alt=""><figcaption></figcaption></figure>

<details>

<summary><strong>This report includes the following:</strong></summary>

1. Predicted trust score: This is the main indicator of a wallet's level of trust, ranging from 0% to 100%. Calculated as 1 − probability of fraud. Displayed with a status badge (Not Fraud / Fraud / New Address) and a sanctions badge (Not Sanctioned / Sanctioned).

| Predicted Trust | Level       | Interpretation                                                 |
| --------------- | ----------- | -------------------------------------------------------------- |
| 80–100%         | Low Risk    | Wallet with clean history                                      |
| 50–79%          | Medium Risk | Risk factors detected, full Wallet Audit recommended           |
| 0–49%           | High Risk   | Wallet is highly likely associated with fraudulent activity    |
| 0% (auto)       | AML Flag    | At least one AML flag detected — score automatically set to 0% |

2. AML Analysis: This shows 18 risk categories with each parameter displayed as  No (clean) or Yes (flag detected).

{% hint style="warning" %}
*If at least one parameter forensic\_details = "1" → probabilityFraud is automatically set to 1.0 (i.e. Predicted Trust = 0%). This is a hard override; the ML model is not used.*
{% endhint %}

3. Sanctions Check: This shows sanctions list verification. It displayed as a badge: Not Sanctioned (green) or Sanctioned (red). If the wallet is sanctioned, the category, name, and source link are displayed.

</details>

If you want to interact with or integrate this service via API, check the [Wallet risk endpoint.](/crypto-address-audit/api-reference/wallet-risk-endpoint)

{% hint style="info" %}
**Need a custom setup** (higher rate limits, dedicated infrastructure, SLA, or volume pricing)? [Contact the GetBlock team](https://getblock.io/contact/).&#x20;
{% endhint %}

### Next Step

1. [Wallet Audit Doc](/crypto-address-audit/wallet-audit)
2. [Rug Pull Checker Doc](/crypto-address-audit/crypto-address-audit-risk-and-compliance-apis)
3. [Address Audit API Reference](/crypto-address-audit/api-reference)
4. [Wallet Audit Homepage](https://getblock.io/wallet-audit-check/)
5. [Wallet Risk Homepage](https://getblock.io/wallet-risk-check/)
6. [Rug Pull Checker Homepage](https://getblock.io/rug-pull-check/)


# Rug Pull Checker

GetBlock Rug Pull Checker: AI rug pull detection for smart contracts — score, trust, and flag

Rug Pull Checks is a smart-contract rug-pull risk assessment service. The service analyzes contracts across two independent dimensions and returns an overall risk score.

Two independent analysis blocks:

1. Rug Pull Probability: AI-predictive score (0–100%). Analyzes the behavior of the contract creator and liquidity providers (LPs) based on their on-chain history. Does not analyze contract code.
2. Contract Details: verification of basic contract properties (open source, proxy, self-destruct, withdrawal rights, blacklist). Does not affect the Rug Pull Probability.

{% hint style="warning" %}
These are two independent blocks. Contract Details (green checkmarks) do not affect the Rug Pull Probability. A contract with clean code, but a suspicious creator will receive a high risk score.
{% endhint %}

### Difference Between Rug Pull Checker And Wallet Audit

| <p><br></p>      | **Rug Pull Checks**                                | **Wallet Audit**                       |
| ---------------- | -------------------------------------------------- | -------------------------------------- |
| Input            | Smart contract address                             | Wallet address (EOA)                   |
| What it analyzes | Creator behavior + LPs + basic contract properties | On-chain wallet behavior, AML, intent  |
| Primary score    | Rug Pull Probability (0–100%)                      | Predicted Trust (0–100%)               |
| When to use      | Before investing in a contract/pool/token          | Before transacting with a counterparty |

### Difference Between Rug Pull Checker And Risk API (Hexens Glider)

GetBlock also provides the Risk API service, powered by Hexens Glider Token Risks. This is a fundamentally different product; they do not compete but complement each other.

| <p><br></p>      | **Rug Pull Checks**                                            | **Risk API**                                                                                                    |
| ---------------- | -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| Provider         | ChainAware.ai                                                  | Hexens (Glider Token Risks)                                                                                     |
| What it analyzes | Behavior of the contract creator and liquidity providers (LPs) | Smart contract code — logic of each function and dependencies                                                   |
| Method           | Behavioral AI/ML — analysis of on-chain wallet history         | Static code analysis — parsing of ERC-20 function logic                                                         |
| Key question     | "Can the people behind this contract be trusted?"              | "Is there malicious code in this contract?"                                                                     |
| What it catches  | Suspicious creators, new LP addresses, links to fraud wallets  | Honeypot, hidden mint, blacklist, selfdestruct, hidden fees, backdoors, pausable proxy, etc. (22+ threat types) |
| Networks         | ETH, BNB, Base                                                 | 32+ EVM chains                                                                                                  |
| Analogy          | Catches the "bomber by handwriting"                            | Catches the "bomb in the code"                                                                                  |

{% hint style="info" %}
Both products complement each other: ChainAware may give a green light to a contract with a clean deployer, but with a honeypot in the code. Hexens may show clean code, but the contract was created by a wallet that previously executed a rug pull. Using the two gives a full picture.
{% endhint %}

{% hint style="warning" %}
Disclaimer

Rug Pull Check provides automated risk indicators based on publicly available on-chain data. Results are informational in nature and do not constitute investment advice, a security audit, or legal counsel. The predictive model accuracy is 68% — 32% of rug pulls may go undetected. We do not guarantee the accuracy or completeness of the data. The decision to interact with a contract is made by the user.
{% endhint %}

### Supported Networks

1. Ethereum
2. BNB Smart Chain
3. Base

### How Rug Pull Probability Is Calculated&#x20;

There are four steps involved, which are:

1. Find the contract creator: It identifies the wallet that deployed the contract and runs it through the Fraud Detector to obtain the creator's Trust Score.
2. Trace the deployment chain: if the contract was deployed by another contract, it follows the chain to the actual wallet. **The obfuscation through the chain itself is a red flag.**
3. Analyze the liquidity providers (LPs): run each LP through the Fraud Detector and obtain the Trust Score for each LP.
4. Generate the Rug Pull Probability: based on the combination of the creator's Trust Score + LP Trust Scores.

#### What increases the risk score:

* New creator address (no history to evaluate)
* Low Trust Score for the creator (behavioral history matches fraud patterns)
* New addresses adding liquidity (classic rug pull pattern)
* Low Trust Score for LPs
* Obfuscated deployment chain (contract deploys contract)

#### What decreases the risk score:

* Creator with a long clean on-chain history
* LPs with high Trust Scores
* Transparent addresses without routing through mixers

> Accuracy: 68%

The algorithm correctly identifies 68 out of 100 rug pulls based on purely behavioral analysis, without code analysis. The 32% miss rate consists of more sophisticated operators who invest in building a legitimate-looking wallet history before executing a rug pull.

{% hint style="danger" %}

#### Limitations

* The service works only with smart contracts. If a regular wallet address (EOA) is submitted, an empty result will be returned. To check wallets, use Wallet Audit.
* Rug Pull Probability does not analyze the contract source code. It evaluates the behavior of the people behind the contract, not the code.
* Data freshness depends on the last ChainAware scan (lastChecked field).
  {% endhint %}

### How to Check the Risk In A Wallet Address

1. Go to your [GetBlock Account Dashboard](https://account.getblock.io/products/address-audit#check) and click **Rug Pull**

<figure><img src="/files/Yay5sTjdQ2BuZNGW15Bu" alt=""><figcaption></figcaption></figure>

2. Select the choice of your network using the dropdown:

<figure><img src="/files/nAJUbpn1mQhg3ZGZyrrJ" alt=""><figcaption></figcaption></figure>

3. Enter the contract address:

<figure><img src="/files/qJKCcdTNI4UTaiRjVbvN" alt=""><figcaption></figcaption></figure>

4. Click on **Run Check**
5. Scroll down to see the analysis:

<figure><img src="/files/0I4QUmivxkAQgyT0VaYV" alt=""><figcaption></figcaption></figure>

<details>

<summary><strong>This report includes the following:</strong></summary>

1. Contract name
2. Contract address
3. Creator wallet address
4. Network
5. Badges
6. Rug Pull probability: The primary indicator, ranging from 0% to 100%, is displayed with a progress bar and a High Risk / Medium Risk / Low Risk label.
7. Contract details: This contains parameters that are displayed as a green checkmark (safe) or a red flag (risk).

</details>

If you want to interact with or integrate this service via API, check the [Rug pull checker endpoint](/crypto-address-audit/api-reference/rug-pull-checker-endpoint).

{% hint style="info" %}
**Need a custom setup** (higher rate limits, dedicated infrastructure, SLA, or volume pricing)? [Contact the GetBlock team](https://getblock.io/contact/).&#x20;
{% endhint %}

### Next Step

* [Address Audit API Reference](/crypto-address-audit/api-reference)
* [Wallet Audit Homepage](https://getblock.io/wallet-audit-check/)
* [Wallet Risk Homepage](https://getblock.io/wallet-risk-check/)
* [Rug Pull Checker Homepage](https://getblock.io/rug-pull-check/)


# API Reference

This contain all the endpoints, pricing and error codes to access Address Audit service

The GetBlock Address Audit API provides access to all address audit services, which you can integrate into your dApp, including wallet audit, wallet riska nd rug pull checker

### Base URL

{% code overflow="wrap" %}

```bash
https://services.getblock.io/v1
```

{% endcode %}

### Authentication

All requests require an API key in the header:

```bash
Authorization: Bearer <API_KEY>
```

### How to Get Address Audit API Key

1. Go to your [account dashboard](https://account.getblock.io/)
2. Click on the product icon on the Navbar

<figure><img src="/files/sfUZ0q2P1TnSU6uuMX6p" alt=""><figcaption></figcaption></figure>

3. Scroll down and Select **Address Audit**
4. After that, select the **API key** tab
5. On the **API Key** tab, click on the plus icon, and your API key will be generated for you automatically

<figure><img src="/files/UIjTyWYUs4q7O59XzWgr" alt=""><figcaption></figcaption></figure>

{% hint style="warning" %}
Ensure you store your API Key securely
{% endhint %}

### QuickStart

In this example, you will be auditing a wallet address:&#x20;

* **Axios** (JavaScript / Node.js)
* **Python** (Requests library)

Before you begin, you must have already installed [`npm`](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) or [`yarn`](https://classic.yarnpkg.com/lang/en/docs/install) on your local machine (for the Axios example) or Python and pip (for the Python example).

{% tabs %}
{% tab title="JavaScript (Axios)" %}
{% stepper %}
{% step %}

#### Setup project

Create and initialize a new project:

```bash
mkdir wallet-audit-quickstart
cd wallet-audit-quickstart
npm init --yes
```

{% endstep %}

{% step %}

#### Install Axios

```bash
npm install axios
```

{% endstep %}

{% step %}

#### Create file

Create a new file named `index.js`. This is where you will make your first call.
{% endstep %}

{% step %}

#### Set ES module type

Set the ES module `"type": "module"` in your `package.json`.
{% endstep %}

{% step %}

#### Add code

Add the following code to `index.js`:

{% code title="index.js" %}

```javascript
import axios from "axios";

const data = 
  {  "network": "ETH", "address": "0xa45f...a675"};

const config = {
  method: "post",
  url: "https://services.getblock.io/v1/wallet-audit/check",
  headers: {
    Authorization: "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
  },
  data: data,
};

axios(config)
  .then((response) => console.log(JSON.stringify(response.data, null, 2)))
  .catch((error) => console.log(error));

```

{% endcode %}

> Replace `<YOUR_API_KEY>` with your actual API Key from the GetBlock dashboard.
> {% endstep %}

{% step %}

#### Run the script

```bash
node index.js
```

Expected output (example):

```json
{
    "data": {
        "message": "Success",
        "walletAddress": "0xa45f...a675",
        "status": "Fraud",
        "probabilityFraud": "0.9329851866",
        "token": null,
        "chain": "ETH",
        "lastChecked": "2026-03-19T07:02:56.000Z",
        "forensic_details": {
            "cybercrime": "0",
            "money_laundering": "0",
            "number_of_malicious_contracts_created": "0",
            "gas_abuse": "0",
            "financial_crime": "0",
            "darkweb_transactions": "0",
            "reinit": "0",
            "phishing_activities": "0",
            "fake_kyc": "0",
            "blacklist_doubt": "0",
            "fake_standard_interface": "0",
            "data_source": "",
            "stealing_attack": "0",
            "blackmail_activities": "0",
            "sanctioned": "0",
            "malicious_mining_activities": "0",
            "mixer": "0",
            "fake_token": "0",
            "honeypot_related_address": "0"
        },
        "checked_times": 3,
        "createdAt": "2026-03-19T06:52:28.000Z",
        "updatedAt": "2026-05-15T17:01:48.000Z",
        "sanctionData": [
            {
                "id": 205813,
                "trustscore_id": 18360032,
                "category": null,
                "name": null,
                "description": null,
                "url": null,
                "isSanctioned": false,
                "createdAt": "2026-05-15T17:01:48.000Z",
                "updatedAt": "2026-05-15T17:01:48.000Z"
            }
        ]
    }
}
```

{% endstep %}
{% endstepper %}
{% endtab %}

{% tab title="Python (Requests)" %}
{% stepper %}
{% step %}

#### Setup the project directory

```bash
mkdir wallet-audit-quickstart
cd wallet-audit-quickstart
```

{% endstep %}

{% step %}

#### Create and activate a virtual environment

```bash
python -m venv venv
source venv/bin/activate

# On Windows, use:
venv\Scripts\activate
```

{% endstep %}

{% step %}

#### Install requests

```bash
pip install requests
```

{% endstep %}

{% step %}

#### Create script

Create a file called `main.py` with the following content:

{% code title="main.py" overflow="wrap" %}

```python
import requests
import json

url = "https://services.getblock.io/v1/wallet-audit/check"

payload = json.dumps({  "network": "ETH", "address": "0xa45f...a675"})

headers = {
      "Authorization": "Bearer YOUR_API_KEY",
  "Content-Type": "application/json",
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endcode %}

> Replace `<YOUR_API_KEY>` with your actual GetBlock API Key.
> {% endstep %}

{% step %}

#### Run the script

```bash
python main.py
```

{% endstep %}
{% endstepper %}
{% endtab %}
{% endtabs %}

### Next Step

* [Wallet Risk endpoint](/crypto-address-audit/api-reference/wallet-risk-endpoint)
* [Wallet Audit endpoint](/crypto-address-audit/api-reference/wallet-audit-endpoint)
* [Rug Pull Checker endpoint](/crypto-address-audit/api-reference/rug-pull-checker-endpoint)
* [Wallet Audit Homepage](https://getblock.io/wallet-audit-check/)
* [Wallet Risk Homepage](https://getblock.io/wallet-risk-check/)
* [Rug Pull Checker Homepage](https://getblock.io/rug-pull-check/)


# Wallet Audit Endpoint

Example code for the /wallet-audit/audit method. Сomplete guide on how to use /wallet-audit/audit in GetBlock Address Audit documentation.

This method performs a comprehensive fraud audit on a wallet address. Proxied to ChainAware.

## Body Parameters

| Parameter | Type   | Required | Description                                         |
| --------- | ------ | -------- | --------------------------------------------------- |
| network   | string | Yes      | The blockchain network to verify(ETH, BNB, or BASE) |
| address   | string | Yes      | the wallet address                                  |

## Request Example

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
curl --location --request POST 'https://services.getblock.io/v1/wallet-audit/audit' \
-- header 'Authorization: Bearer YOUR_API_KEY',
--header 'Content-Type: application/json' \
--data-raw ' {  "network": "ETH", "address": "0xa45f...a675"}'
```

{% endcode %}
{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from "axios";

const data = 
  {  "network": "ETH", "address": "0xa45f...a675"};

const config = {
  method: "post",
  url: "https://services.getblock.io/v1/wallet-audit/audit",
  headers: {
    Authorization: "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
  },
  data: data,
};

axios(config)
  .then((response) => console.log(JSON.stringify(response.data, null, 2)))
  .catch((error) => console.log(error));

```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import requests
import json

url = "https://services.getblock.io/v1/wallet-audit/audit"

payload = json.dumps({  "network": "ETH", "address": "0xa45f...a675"})

headers = {
      "Authorization": "Bearer YOUR_API_KEY",
  "Content-Type": "application/json",
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({  "network": "ETH", "address": "0xa45f...a675"});

    let response = client
        .post("https://services.getblock.io/v1/wallet-audit/audit")
        .header("Content-Type", "application/json")
        .header("Authorization: "Bearer YOUR_API_KEY")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "data": {
        "message": "Success",
        "walletAddress": "0xa45f...a675",
        "status": "Fraud",
        "probabilityFraud": "0.9329851866",
        "token": null,
        "chain": "ETH",
        "lastChecked": "2026-03-19T07:02:56.000Z",
        "forensic_details": {
            "cybercrime": "0",
            "money_laundering": "0",
            "number_of_malicious_contracts_created": "0",
            "gas_abuse": "0",
            "financial_crime": "0",
            "darkweb_transactions": "0",
            "reinit": "0",
            "phishing_activities": "0",
            "fake_kyc": "0",
            "blacklist_doubt": "0",
            "fake_standard_interface": "0",
            "data_source": "",
            "stealing_attack": "0",
            "blackmail_activities": "0",
            "sanctioned": "0",
            "malicious_mining_activities": "0",
            "mixer": "0",
            "fake_token": "0",
            "honeypot_related_address": "0"
        },
        "categories": [],
        "riskProfile": [
            {
                "Category": "Stable Coin",
                "Balance_age": 0
            },
            {
                "Category": "1to10",
                "Balance_age": 100
            },
            {
                "Category": "10to20",
                "Balance_age": 0
            },
            {
                "Category": "20to30",
                "Balance_age": 0
            },
            {
                "Category": "30to50",
                "Balance_age": 0
            },
            {
                "Category": "50to100",
                "Balance_age": 0
            },
            {
                "Category": "100to200",
                "Balance_age": 0
            },
            {
                "Category": "200to300",
                "Balance_age": 0
            },
            {
                "Category": "300+",
                "Balance_age": 0
            },
            {
                "Category": "Meme Token",
                "Balance_age": 0
            },
            {
                "Category": "Risk_Profile",
                "Balance_age": 2
            }
        ],
        "segmentInfo": "{\"Maker\":0,\"Aave_borrow\":0,\"Aave_lend\":0,\"Lido\":0,\"Compound_lend\":0,\"Compound_borrow\":0}",
        "experience": {
            "Type": "Experience",
            "Value": 0
        },
        "intention": {
            "Type": "Intentions",
            "Value": {
                "Prob_Borrow": "Low",
                "Prob_Gamble": "Low",
                "Prob_Game": "Medium",
                "Prob_Lend": "High",
                "Prob_Leverage_Long": "Low",
                "Prob_Leverage_Long_ETH": "Low",
                "Prob_Leveraged_Lend": "Low",
                "Prob_Leveraged_Stake": "Low",
                "Prob_Leveraged_Stake_ETH": "Low",
                "Prob_NFT": "Medium",
                "Prob_Stake": "Low",
                "Prob_Stake_ETH": "Medium",
                "Prob_Trade": "High",
                "Prob_Yield_Farm": "Low"
            }
        },
        "protocols": [],
        "userDetails": {
            "wallet_age_days": 349,
            "total_balance_usd": 0.26,
            "transaction_count": 2,
            "wallet_rank": 0
        },
        "riskCapability": 1,
        "recommendation": {
            "Type": "Recommendation",
            "Value": [
                "WBTC holding",
                "ETH holding",
                "Stablecoin lending",
                "Stablecoin lending with FIFs (SmartCredit.io)"
            ]
        },
        "checked_times": 6,
        "createdAt": "2026-03-19T06:52:28.000Z",
        "updatedAt": "2026-05-15T17:17:02.000Z",
        "sanctionData": [
            {
                "id": 205878,
                "trustscore_id": 18360032,
                "category": null,
                "name": null,
                "description": null,
                "url": null,
                "isSanctioned": false,
                "createdAt": "2026-05-15T17:17:02.000Z",
                "updatedAt": "2026-05-15T17:17:02.000Z"
            }
        ]
    }
}
```

{% endcode %}

## Response Parameters

| **Field Path**                             | **Type**          | **Example**                                            | **Description**                                                                                                                                                                                                                                                 |
| ------------------------------------------ | ----------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| status                                     | string            | `"Not Fraud"`                                          | ML model verdict. Possible values: `"Not Fraud"`, `"Fraud"`, `"New Address"`.                                                                                                                                                                                   |
| probabilityFraud                           | string            | `"0.0191140026"`                                       | Fraud probability score ranging from `0.0` to `1.0`.                                                                                                                                                                                                            |
| walletAddress                              | string            | `"0xa45f..."`                                          | The audited blockchain wallet address.                                                                                                                                                                                                                          |
| chain                                      | string            | `"ETH"`                                                | The network/blockchain name (e.g., `"ETH"`).                                                                                                                                                                                                                    |
| lastChecked                                | string (ISO 8601) | `"2026-04-15T12:02:21Z"`                               | Timestamp of the most recent fraud analysis.                                                                                                                                                                                                                    |
| checked\_times                             | number            | `183`                                                  | Total number of times this address has been checked.                                                                                                                                                                                                            |
| createdAt                                  | string (ISO 8601) | `"2023-07-19T10:15:00Z"`                               | Record creation timestamp.                                                                                                                                                                                                                                      |
| updatedAt                                  | string (ISO 8601) | `"2026-05-08T14:30:22Z"`                               | Last update timestamp.                                                                                                                                                                                                                                          |
| forensic\_details                          | object            | *See sub-fields below*                                 | Contains 18 AML flags. Each is `"0"` (clean) or `"1"` (flagged). If any flag is `"1"`, `probabilityFraud` defaults to `1.0`.                                                                                                                                    |
| ↳ `.cybercrime`                            | string            | `"0"`                                                  | Cybercrime activity.                                                                                                                                                                                                                                            |
| ↳ `.money_laundering`                      | string            | `"0"`                                                  | Money laundering activity.                                                                                                                                                                                                                                      |
| ↳ `.number_of_malicious_contracts_created` | string            | `"0"`                                                  | Creation of malicious smart contracts.                                                                                                                                                                                                                          |
| ↳ `.gas_abuse`                             | string            | `"0"`                                                  | Gas price manipulation behavior.                                                                                                                                                                                                                                |
| ↳ `.financial_crime`                       | string            | `"0"`                                                  | General financial crime flag.                                                                                                                                                                                                                                   |
| ↳ `.darkweb_transactions`                  | string            | `"0"`                                                  | Transactions associated with darkweb marketplaces.                                                                                                                                                                                                              |
| ↳ `.reinit`                                | string            | `"0"`                                                  | Smart contract reinitialization abuse.                                                                                                                                                                                                                          |
| ↳ `.phishing_activities`                   | string            | `"0"`                                                  | Phishing vector participation.                                                                                                                                                                                                                                  |
| ↳ `.fake_kyc`                              | string            | `"0"`                                                  | Use or association with fake KYC data.                                                                                                                                                                                                                          |
| ↳ `.blacklist_doubt`                       | string            | `"0"`                                                  | Association with blacklisted entities.                                                                                                                                                                                                                          |
| ↳ `.fake_standard_interface`               | string            | `"0"`                                                  | Spoofed/fake token interface usage.                                                                                                                                                                                                                             |
| ↳ `.stealing_attack`                       | string            | `"0"`                                                  | Active theft or exploit activity.                                                                                                                                                                                                                               |
| ↳ `.blackmail_activities`                  | string            | `"0"`                                                  | Blackmail or extortion activities.                                                                                                                                                                                                                              |
| ↳ `.sanctioned`                            | string            | `"0"`                                                  | Presence on known sanctions lists.                                                                                                                                                                                                                              |
| ↳ `.malicious_mining_activities`           | string            | `"0"`                                                  | Malicious or hijacked mining operations.                                                                                                                                                                                                                        |
| ↳ `.mixer`                                 | string            | `"0"`                                                  | Interaction with crypto mixing services (e.g., Tornado Cash).                                                                                                                                                                                                   |
| ↳ `.fake_token`                            | string            | `"0"`                                                  | Creation or deployment of fake/honeypot tokens.                                                                                                                                                                                                                 |
| ↳ `.honeypot_related_address`              | string            | `"0"`                                                  | Association with honeypot contract setups.                                                                                                                                                                                                                      |
| categories                                 | array (object)    | `[{"Category": "NFT", "Count": 12}]`                   | Transaction count breakdown by category. Examples: `"Decentralized Exchanges"`, `"Bridge"`, `"NFT"`, `"Layer 1"`, `"Layer 2"`, `"Lending & Borrowing"`.                                                                                                         |
| riskProfile                                | array (object)    | `[{"Category": "Stable Coin", "Balance_age": "..."}]`  | Balance distribution. Categories include: `"Stable Coin"`, `"1to10"`, `"10to20"`, ..., `"300+"`, `"Meme Token"`, `"Risk_Profile"`. *Note: The "Risk\_Profile" entry represents the Risk Willingness score in the UI.*                                           |
| segmentInfo                                | string (JSON)     | `"{\"Maker\":0,\"Aave_borrow\":0,...}"`                | Protocol interaction flags packed as a JSON string. `1` = interacted, `0` = not. Supported keys: `Maker`, `Aave_borrow`, `Aave_lend`, `Lido`, `Uniswap`, `Compound_lend`, `Compound_borrow`.                                                                    |
| experience                                 | object            | `{"Type": "Experience", "Value": 8}`                   | User experience rating mapped on a scale of `1-10`.                                                                                                                                                                                                             |
| intention                                  | object            | *See description*                                      | Expected behavior map. Format: `{"Type": "Intentions", "Value": { ... }}` where `Value` contains 14 sub-keys, each rated as `"Low"`, `"Medium"`, or `"High"`.                                                                                                   |
| ↳ *Sub-keys*                               | string            | `"Low"`, `"Medium"`, `"High"`                          | `Prob_Borrow`, `Prob_Gamble`, `Prob_Game`, `Prob_Lend`, `Prob_Leverage_Long`, `Prob_Leverage_Long_ETH`, `Prob_Leveraged_Lend`, `Prob_Leveraged_Stake`, `Prob_Leveraged_Stake_ETH`, `Prob_NFT`, `Prob_Stake`, `Prob_Stake_ETH`, `Prob_Trade`, `Prob_Yield_Farm`. |
| protocols                                  | array (object)    | `[{"Protocol": "Uniswap", "Count": 45}]`               | Array of specific protocols the wallet has interacted with alongside their usage frequency.                                                                                                                                                                     |
| userDetails                                | object            | *See sub-fields below*                                 | General metadata and structural metrics of the wallet.                                                                                                                                                                                                          |
| ↳ `.wallet_age_days`                       | number            | `1024`                                                 | Age of the wallet in days.                                                                                                                                                                                                                                      |
| ↳ `.total_balance_usd`                     | number            | `15430.50`                                             | Current aggregate wallet balance in USD.                                                                                                                                                                                                                        |
| ↳ `.transaction_count`                     | number            | `450`                                                  | Cumulative historical transaction count.                                                                                                                                                                                                                        |
| ↳ `.wallet_rank`                           | number            | `88`                                                   | Internal wallet ranking score.                                                                                                                                                                                                                                  |
| riskCapability                             | number            | `7`                                                    | User's risk capability evaluated on a scale of `1-10`.                                                                                                                                                                                                          |
| recommendation                             | object            | `{"Type": "Recommendation", "Value": ["ETH holding"]}` | Tailored system recommendations. `Value` is an array of strings (e.g., `["ETH holding", "Stablecoin lending"]`).                                                                                                                                                |
| sanctionData                               | array (object)    | *See sub-fields below*                                 | Definitive sanction matches associated with this address.                                                                                                                                                                                                       |
| ↳ `.isSanctioned`                          | boolean           | `false`                                                | `true` if sanctioned, `false` if clean.                                                                                                                                                                                                                         |
| ↳ `.category`                              | string (nullable) | `"Terrorism"`                                          | Category of sanction if applicable; otherwise `null`.                                                                                                                                                                                                           |
| ↳ `.name`                                  | string (nullable) | `"Entity Name"`                                        | Official name of the sanctioned entity/person; otherwise `null`.                                                                                                                                                                                                |
| ↳ `.description`                           | string (nullable) | `"Details here..."`                                    | Contextual details regarding the sanction; otherwise `null`.                                                                                                                                                                                                    |
| ↳ `.url`                                   | string (nullable) | `"https://..."`                                        | Reference URL providing sanction evidence; otherwise `null`.                                                                                                                                                                                                    |

## Error Handling

| Status | Description                       |
| ------ | --------------------------------- |
| 400    | Invalid network or missing fields |
| 401    | Missing or invalid auth           |
| 402    | Insufficient balance              |
| 502    | Provider error                    |


# Wallet Risk Endpoint

Example code for the /wallet-audit/check method. Сomplete guide on how to use /wallet-audit/check in GetBlock Address Audit documentation.

This method performs a quick risk score check on a wallet address. Supports more networks than the full audit.

## Body Parameters

| Parameter | Type   | Required | Description                                                   |
| --------- | ------ | -------- | ------------------------------------------------------------- |
| network   | string | Yes      | The blockchain network to verify(ETH, BNB,POLY, TRON or BASE) |
| address   | string | Yes      | the wallet address                                            |

## Request Example

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
curl --location --request POST 'https://services.getblock.io/v1/wallet-audit/check' \
-- header 'Authorization: Bearer YOUR_API_KEY',
--header 'Content-Type: application/json' \
--data-raw ' {  "network": "ETH", "address": "0xa45f...a675"}'
```

{% endcode %}
{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from "axios";

const data = 
  {  "network": "ETH", "address": "0xa45f...a675"};

const config = {
  method: "post",
  url: "https://services.getblock.io/v1/wallet-audit/check",
  headers: {
    Authorization: "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
  },
  data: data,
};

axios(config)
  .then((response) => console.log(JSON.stringify(response.data, null, 2)))
  .catch((error) => console.log(error));

```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import requests
import json

url = "https://services.getblock.io/v1/wallet-audit/check"

payload = json.dumps({  "network": "ETH", "address": "0xa45f...a675"})

headers = {
      "Authorization": "Bearer YOUR_API_KEY",
  "Content-Type": "application/json",
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({  "network": "ETH", "address": "0xa45f...a675"});

    let response = client
        .post("https://services.getblock.io/v1/wallet-audit/check")
        .header("Content-Type", "application/json")
        .header("Authorization: "Bearer YOUR_API_KEY")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "data": {
        "message": "Success",
        "walletAddress": "0xa45f...a675",
        "status": "Fraud",
        "probabilityFraud": "0.9329851866",
        "token": null,
        "chain": "ETH",
        "lastChecked": "2026-03-19T07:02:56.000Z",
        "forensic_details": {
            "cybercrime": "0",
            "money_laundering": "0",
            "number_of_malicious_contracts_created": "0",
            "gas_abuse": "0",
            "financial_crime": "0",
            "darkweb_transactions": "0",
            "reinit": "0",
            "phishing_activities": "0",
            "fake_kyc": "0",
            "blacklist_doubt": "0",
            "fake_standard_interface": "0",
            "data_source": "",
            "stealing_attack": "0",
            "blackmail_activities": "0",
            "sanctioned": "0",
            "malicious_mining_activities": "0",
            "mixer": "0",
            "fake_token": "0",
            "honeypot_related_address": "0"
        },
        "checked_times": 7,
        "createdAt": "2026-03-19T06:52:28.000Z",
        "updatedAt": "2026-05-18T11:11:19.000Z",
        "sanctionData": [
            {
                "id": 212143,
                "trustscore_id": 18360032,
                "category": null,
                "name": null,
                "description": null,
                "url": null,
                "isSanctioned": false,
                "createdAt": "2026-05-18T11:11:19.000Z",
                "updatedAt": "2026-05-18T11:11:19.000Z"
            }
        ]
    }
}
```

{% endcode %}

## Response Parameters

| **Field Path**                             | **Type**          | **Example**              | **Description**                                                                                                              |
| ------------------------------------------ | ----------------- | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------- |
| status                                     | string            | `"Not Fraud"`            | ML model verdict. Possible values: `"Not Fraud"`, `"Fraud"`, `"New Address"`.                                                |
| probabilityFraud                           | string            | `"0.0191140026"`         | Fraud probability score ranging from `0.0` to `1.0`.                                                                         |
| walletAddress                              | string            | `"0xa45f..."`            | The audited blockchain wallet address.                                                                                       |
| chain                                      | string            | `"ETH"`                  | The network/blockchain name (e.g., `"ETH"`).                                                                                 |
| lastChecked                                | string (ISO 8601) | `"2026-04-15T12:02:21Z"` | Timestamp of the most recent fraud analysis.                                                                                 |
| checked\_times                             | number            | `169`                    | Total number of times this address has been checked.                                                                         |
| createdAt                                  | string (ISO 8601) | `"2023-07-19T10:15:00Z"` | Record creation timestamp.                                                                                                   |
| updatedAt                                  | string (ISO 8601) | `"2026-05-08T14:30:22Z"` | Last update timestamp.                                                                                                       |
| forensic\_details                          | object            | *See sub-fields below*   | Contains 18 AML flags. Each is `"0"` (clean) or `"1"` (flagged). If any flag is `"1"`, `probabilityFraud` defaults to `1.0`. |
| ↳ `.cybercrime`                            | string            | `"0"`                    | Cybercrime activity flag.                                                                                                    |
| ↳ `.money_laundering`                      | string            | `"0"`                    | Money laundering flag.                                                                                                       |
| ↳ `.number_of_malicious_contracts_created` | string            | `"0"`                    | Creation of malicious smart contracts flag.                                                                                  |
| ↳ `.gas_abuse`                             | string            | `"0"`                    | Gas price manipulation behavior flag.                                                                                        |
| ↳ `.financial_crime`                       | string            | `"0"`                    | General financial crime flag.                                                                                                |
| ↳ `.darkweb_transactions`                  | string            | `"0"`                    | Transactions associated with darkweb marketplaces flag.                                                                      |
| ↳ `.reinit`                                | string            | `"0"`                    | Smart contract reinitialization abuse flag.                                                                                  |
| ↳ `.phishing_activities`                   | string            | `"0"`                    | Phishing vector participation flag.                                                                                          |
| ↳ `.fake_kyc`                              | string            | `"0"`                    | Use or association with fake KYC data flag.                                                                                  |
| ↳ `.blacklist_doubt`                       | string            | `"0"`                    | Association with blacklisted entities flag.                                                                                  |
| ↳ `.fake_standard_interface`               | string            | `"0"`                    | Spoofed/fake token interface usage flag.                                                                                     |
| ↳ `.stealing_attack`                       | string            | `"0"`                    | Active theft or exploit activity flag.                                                                                       |
| ↳ `.blackmail_activities`                  | string            | `"0"`                    | Blackmail or extortion activities flag.                                                                                      |
| ↳ `.sanctioned`                            | string            | `"0"`                    | Presence on known sanctions lists flag.                                                                                      |
| ↳ `.malicious_mining_activities`           | string            | `"0"`                    | Malicious or hijacked mining operations flag.                                                                                |
| ↳ `.mixer`                                 | string            | `"0"`                    | Interaction with crypto mixing services (e.g., Tornado Cash) flag.                                                           |
| ↳ `.fake_token`                            | string            | `"0"`                    | Creation or deployment of fake/honeypot tokens flag.                                                                         |
| ↳ `.honeypot_related_address`              | string            | `"0"`                    | Association with honeypot contract setups flag.                                                                              |
| sanctionData                               | array (object)    | *See sub-fields below*   | Definitive sanction matches associated with this address.                                                                    |
| ↳ `.isSanctioned`                          | boolean           | `false`                  | `true` if sanctioned, `false` if clean.                                                                                      |
| ↳ `.category`                              | string (nullable) | `"Terrorism"`            | Category of sanction if applicable; otherwise `null`.                                                                        |
| ↳ `.name`                                  | string (nullable) | `"Entity Name"`          | Official name of the sanctioned entity/person; otherwise `null`.                                                             |
| ↳ `.description`                           | string (nullable) | `"Details here..."`      | Contextual details regarding the sanction; otherwise `null`.                                                                 |
| ↳ `.url`                                   | string (nullable) | `"https://..."`          | Reference URL providing sanction evidence; otherwise `null`.                                                                 |

## Error Handling

| Status | Description                       |
| ------ | --------------------------------- |
| 400    | Invalid network or missing fields |
| 401    | Missing or invalid auth           |
| 402    | Insufficient balance              |
| 502    | Provider error                    |


# Rug Pull Checker Endpoint

Example code for the /rug-pull/check method. Сomplete guide on how to use /rug-pull/check in GetBlock Address Audit documentation.

This method checks a smart contract for rug pull indicators. Proxied to ChainAware.

## Body Parameters

| Parameter         | Type   | Required | Description                                                   |
| ----------------- | ------ | -------- | ------------------------------------------------------------- |
| network           | string | Yes      | The blockchain network to verify(ETH, BNB,POLY, TRON or BASE) |
| contract\_address | string | Yes      | the contract address                                          |

## Request Example

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
curl --location --request POST 'https://services.getblock.io/v1/rug-pull/check' \
-- header 'Authorization: Bearer YOUR_API_KEY',
--header 'Content-Type: application/json' \
--data-raw ' {  "network": "ETH", "contract_address": "0xdac17f958d2ee523a2206206994597c13d831ec7"}'
```

{% endcode %}
{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from "axios";

const data = 
  {  "network": "ETH", "contract_address": "0xdac17f958d2ee523a2206206994597c13d831ec7"};

const config = {
  method: "post",
  url: "https://services.getblock.io/v1/rug-pull/check",
  headers: {
    Authorization: "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
  },
  data: data,
};

axios(config)
  .then((response) => console.log(JSON.stringify(response.data, null, 2)))
  .catch((error) => console.log(error));

```

{% endtab %}

{% tab title="Python (Requests)" %}
{% code overflow="wrap" %}

```python
import requests
import json

url = "https://services.getblock.io/v1/rug-pull/check"

payload = json.dumps({  "network": "ETH", "contract_address": "0xdac17f958d2ee523a2206206994597c13d831ec7"})

headers = {
      "Authorization": "Bearer YOUR_API_KEY",
  "Content-Type": "application/json",
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endcode %}
{% endtab %}

{% tab title="Rust (Reqwest)" %}
{% code overflow="wrap" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({  "network": "ETH", "contract_address": "0xdac17f958d2ee523a2206206994597c13d831ec7"});

    let response = client
        .post("https://services.getblock.io/v1/rug-pull/check")
        .header("Content-Type", "application/json")
        .header("Authorization: "Bearer YOUR_API_KEY")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "data": {
        "message": "Success",
        "contractAddress": "0xdac17f958d2ee523a2206206994597c13d831ec7",
        "pairAddress": null,
        "contractCreatorAddress": "0x36928500bc1dcd7af6a2b4008875cc336b927d57",
        "risk_score": 0,
        "risk_status": null,
        "risk_indicators": {},
        "status": "Not Fraud",
        "probabilityFraud": "0.0028322712",
        "chain": "ETH",
        "lastChecked": "2026-05-14T14:23:18.000Z",
        "contractCreationTime": "2017-11-28T00:41:21.000Z",
        "forensic_details": {
            "owner": {
                "owner_address": "0xc6cde7c39eb2f0f0095f41570af89efc2c1ea828",
                "owner_name": "owner",
                "owner_type": "contract"
            },
            "privilege_withdraw": 0,
            "withdraw_missing": 0,
            "is_open_source": 1,
            "blacklist": 1,
            "contract_name": "TetherToken",
            "selfdestruct": 0,
            "is_proxy": 0,
            "approval_abuse": 0
        },
        "checked_times": 1,
        "createdAt": "2025-09-04T04:55:17.000Z",
        "updatedAt": "2026-05-14T14:23:20.000Z"
    }
}
```

{% endcode %}

## Response Parameters

| **Field Path**          | **Type**          | **Example**                  | **Description**                                                                                                                               |
| ----------------------- | ----------------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| status                  | string            | `"Fraud"`                    | Model verdict. Possible values: `"Fraud"`, `"Not Fraud"`, `"Investable"`, `"Not Investable"`, `"Safe"`.                                       |
| probabilityFraud        | number            | `0.5488`                     | Rug pull probability score ranging from `0.0` to `1.0`.                                                                                       |
| contractCreationTime    | string (ISO 8601) | `"2021-11-10T12:00:00.000Z"` | Exact timestamp when the smart contract was deployed.                                                                                         |
| lastChecked             | string (ISO 8601) | `"2026-03-25T18:42:00.000Z"` | Timestamp of the most recent security and fraud analysis.                                                                                     |
| chain                   | string            | `"ETH"`                      | The network/blockchain name (e.g., `"ETH"`).                                                                                                  |
| forensic\_details       | object            | *See sub-fields below*       | Deep analysis of the contract's security properties. Core flags are binary: `0` (clean) or `1` (flagged).                                     |
| ↳ `.contract_name`      | string            | `"PFToken"`                  | The registered name of the smart contract.                                                                                                    |
| ↳ `.is_open_source`     | number (0/1)      | `1`                          | Indicates if the source code is verified on the network explorer.                                                                             |
| ↳ `.is_proxy`           | number (0/1)      | `0`                          | Indicates if the contract uses a proxy pattern (allowing the underlying logic to be replaced).                                                |
| ↳ `.selfdestruct`       | number (0/1)      | `0`                          | Indicates if the contract contains a `selfdestruct` function capability.                                                                      |
| ↳ `.privilege_withdraw` | number (0/1)      | `0`                          | Indicates if the owner has excessive privileges to arbitrarily withdraw user assets.                                                          |
| ↳ `.withdraw_missing`   | number (0/1)      | `0`                          | Indicates if critical withdrawal mechanisms are missing, preventing users from recovering funds.                                              |
| ↳ `.blacklist`          | number (0/1)      | `0`                          | Indicates if the contract owner has the power to blacklist specific wallet addresses.                                                         |
| ↳ `.approval_abuse`     | number (0/1)      | `0`                          | Indicates if the owner can potentially abuse token allowances/approvals given by users.                                                       |
| ↳ \`.owner\*\*          | object            | *See sub-fields below*       | Details regarding the administrative ownership of the smart contract.                                                                         |
| ↳ `.owner_type`         | string            | `"contract"`                 | The type of owner account. Possible values: `"contract"` (Multi-sig/DAO/Other contract) or `"eoa"` (Externally Owned Account/Regular wallet). |
| ↳ `.owner_address`      | string (nullable) | `null`                       | The public address of the owner. Returns `null` if the contract ownership has been renounced.                                                 |

## Error Handling

| Status | Description                       |
| ------ | --------------------------------- |
| 400    | Invalid network or missing fields |
| 401    | Missing or invalid auth           |
| 402    | Insufficient balance              |
| 502    | Provider error                    |


# Overview

GetBlock exposes Flashblocks' data on supported OP Stack networks through the standard JSON-RPC and WebSocket interfaces.

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.

## How to Use Flashblocks

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.

{% hint style="info" %}
Flashblocks are simply a class of [RPC API methods](/flashblocks/flashblocks-api) that are now active on GetBlock endpoints for Base and Optimism. If you already run either chain with GetBlock, the new methods are available on your existing endpoint. If you are new, set up a Base or Optimism endpoint from the [GetBlock dashboard,](https://account.getblock.io) and the methods are there.
{% endhint %}

## Supported Networks

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

* [**Base**](/flashblocks/base-flashblocks)&#x20;
* [**Optimism**](/flashblocks/optimism-flashblocks.)


# Base Flashblocks

Flashblocks-specific RPC methods, WebSocket subscriptions, and the infrastructure stream schema for Base pre-confirmations.

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.

### Endpoints

| Transport | URL                                      |
| --------- | ---------------------------------------- |
| HTTP      | `https://go.getblock.io/<ACCESS-TOKEN>/` |
| WebSocket | `wss://go.getblock.io/<ACCESS-TOKEN>/`   |

{% hint style="info" %}
The `pending` tag works over HTTP. Flashblocks subscriptions require the WebSocket endpoint.
{% endhint %}

### Flashblocks-Aware Methods

<table data-search="false"><thead><tr><th>Method</th><th>Usage</th></tr></thead><tbody><tr><td><code>eth_getTransactionCount</code></td><td>Pass <code>"pending"</code> for a nonce that accounts for Flashblock transactions</td></tr><tr><td><code>eth_getStorageAt</code></td><td>Pass <code>"pending"</code> for storage at preconfirmed state</td></tr><tr><td><code>eth_getBalance</code></td><td>Pass <code>"pending"</code> for the balance at the latest Flashblock state</td></tr><tr><td><code>eth_getBlockByNumber</code></td><td>Pass <code>"pending"</code> to retrieve the current Flashblock</td></tr><tr><td><code>eth_getBlockReceipt</code></td><td>Pass <code>"pending"</code> to get receipts for all pre-confirmed transactions in the current Flashblock.</td></tr><tr><td><code>eth_getBlockTransactionCountByNumber</code></td><td>Pass <code>"pending"</code> to get the count of pre-confirmed transactions in the current Flashblock.</td></tr><tr><td><code>eth_estimateGas</code></td><td>Pass <code>"pending"</code> to estimate gas against preconfirmed state</td></tr><tr><td><code>eth_call</code></td><td>Pass <code>"pending"</code> to execute against preconfirmed state</td></tr><tr><td><code>eth_simulateV1</code></td><td>Simulates against the latest preconfirmed state</td></tr><tr><td><code>eth_getLogs</code></td><td>Pass  <code>"fromBlock": "pending"</code> and <code>"toBlock": "pending"</code> to query logs from pre-confirmed transactions, updated every ~200ms.</td></tr><tr><td><code>eth_getCode</code></td><td>Pass <code>"pending"</code> for contract code at preconfirmed state</td></tr><tr><td><code>base_transactionStatus</code></td><td>Reports whether a transaction hash is present in the mempool</td></tr><tr><td><code>eth_subscribe</code></td><td>Opens a Flashblocks WebSocket subscription</td></tr><tr><td><code>eth_unsubscribe</code></td><td>Cancels an active Flashblocks subscription</td></tr></tbody></table>

### Example

The example below reads the `pending` balance of the Base WETH contract `0x4200000000000000000000000000000000000006`. Substitute any supported method and parameters; the `"pending"` tag is what selects Flashblock state.

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": ["0x4200000000000000000000000000000000000006", "pending"],
    "id": "getblock.io"
}'
```

{% endcode %}
{% endtab %}

{% tab title="Axios" %}
{% code title="example.js" %}

```javascript
const axios = require('axios');

const response = await axios.post('https://go.getblock.io/<ACCESS-TOKEN>/', {
    jsonrpc: '2.0',
    method: 'eth_getBalance',
    params: ['0x4200000000000000000000000000000000000006', 'pending'],
    id: 'getblock.io'
}, {
    headers: { 'Content-Type': 'application/json' }
});

console.log(response.data.result);
```

{% endcode %}
{% endtab %}

{% tab title="Request(Python)" %}
{% code title="example.py" %}

```python
import requests

response = requests.post(
    'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers={'Content-Type': 'application/json'},
    json={
        'jsonrpc': '2.0',
        'method': 'eth_getBalance',
        'params': ['0x4200000000000000000000000000000000000006', 'pending'],
        'id': 'getblock.io'
    }
)

print(response.json())
```

{% endcode %}
{% endtab %}

{% tab title="Rust" %}
{% code title="example.rs" %}

```rust
use reqwest::Client;
use serde_json::{json, Value};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&json!({
            "jsonrpc": "2.0",
            "method": "eth_getBalance",
            "params": ["0x4200000000000000000000000000000000000006", "pending"],
            "id": "getblock.io"
        }))
        .send()
        .await?
        .json::<Value>()
        .await?;

    println!("Result: {}", response["result"]);
    Ok(())
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

#### Response

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0x3bdf5275488a29a8a57c"
}
```

### Use Cases

* **Instant UI Feedback**: Update wallet and dApp interfaces the moment a transaction is preconfirmed, without waiting for a sealed block.
* **Responsive Swaps**: Surface preconfirmed swap results on decentralized exchanges with sub-second latency.
* **Onchain Gaming**: Reflect game state changes as soon as actions are included in a Flashblock.
* **Nonce Management**: Use `eth_getTransactionCount` with `pending` to avoid nonce collisions when submitting transactions in rapid succession.
* **Preconfirmed Receipts**: Poll `eth_getTransactionReceipt` on a 200ms interval to confirm inclusion at Flashblock cadence.


# Optimism Flashblocks.

Flashblocks-specific RPC methods, WebSocket subscriptions, and the infrastructure stream schema for Optimism pre-confirmations.

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.

### Endpoints

| Transport | URL                                      |
| --------- | ---------------------------------------- |
| HTTP      | `https://go.getblock.io/<ACCESS-TOKEN>/` |
| WebSocket | `wss://go.getblock.io/<ACCESS-TOKEN>/`   |

{% hint style="info" %}
The `pending` tag works over HTTP. Flashblocks subscriptions require the WebSocket endpoint.
{% endhint %}

### Flashblocks-Aware Methods

<table data-search="false"><thead><tr><th>Method</th><th>Usage</th></tr></thead><tbody><tr><td><code>eth_getTransactionCount</code></td><td>Pass <code>"pending"</code> for a nonce that accounts for Flashblock transactions</td></tr><tr><td><code>eth_getStorageAt</code></td><td>Pass <code>"pending"</code> for storage at preconfirmed state</td></tr><tr><td><code>eth_getBalance</code></td><td>Pass <code>"pending"</code> for the balance at the latest Flashblock state</td></tr><tr><td><code>eth_getBlockByNumber</code></td><td>Pass <code>"pending"</code> to retrieve the current Flashblock</td></tr><tr><td><code>eth_getBlockReceipt</code></td><td>Pass <code>"pending"</code> to get receipts for all pre-confirmed transactions in the current Flashblock.</td></tr><tr><td><code>eth_getBlockTransactionCountByNumber</code></td><td>Pass <code>"pending"</code> to get the count of pre-confirmed transactions in the current Flashblock.</td></tr><tr><td><code>eth_estimateGas</code></td><td>Pass <code>"pending"</code> to estimate gas against preconfirmed state</td></tr><tr><td><code>eth_call</code></td><td>Pass <code>"pending"</code> to execute against preconfirmed state</td></tr><tr><td><code>eth_simulateV1</code></td><td>Simulates against the latest preconfirmed state</td></tr><tr><td><code>eth_getLogs</code></td><td>Pass  <code>"fromBlock": "pending"</code> and <code>"toBlock": "pending"</code> to query logs from pre-confirmed transactions, updated every ~200ms.</td></tr><tr><td><code>eth_getCode</code></td><td>Pass <code>"pending"</code> for contract code at preconfirmed state</td></tr><tr><td><code>eth_subscribe</code></td><td>Opens a Flashblocks WebSocket subscription</td></tr><tr><td><code>eth_unsubscribe</code></td><td>Cancels an active Flashblocks subscription</td></tr></tbody></table>

### Example

The example below reads the `pending` balance of the Optimism WETH contract `0x4200000000000000000000000000000000000006`. Substitute any supported method and parameters; the `"pending"` tag is what selects Flashblock state.

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": ["0x4200000000000000000000000000000000000006", "pending"],
    "id": "getblock.io"
}'
```

{% endcode %}
{% endtab %}

{% tab title="Axios" %}
{% code title="example.js" %}

```javascript
const axios = require('axios');

const response = await axios.post('https://go.getblock.io/<ACCESS-TOKEN>/', {
    jsonrpc: '2.0',
    method: 'eth_getBalance',
    params: ['0x4200000000000000000000000000000000000006', 'pending'],
    id: 'getblock.io'
}, {
    headers: { 'Content-Type': 'application/json' }
});

console.log(response.data.result);
```

{% endcode %}
{% endtab %}

{% tab title="Request" %}
{% code title="example.py" %}

```python
import requests

response = requests.post(
    'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers={'Content-Type': 'application/json'},
    json={
        'jsonrpc': '2.0',
        'method': 'eth_getBalance',
        'params': ['0x4200000000000000000000000000000000000006', 'pending'],
        'id': 'getblock.io'
    }
)

print(response.json())
```

{% endcode %}
{% endtab %}

{% tab title="Rust" %}
{% code title="example.rs" %}

```rust
use reqwest::Client;
use serde_json::{json, Value};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&json!({
            "jsonrpc": "2.0",
            "method": "eth_getBalance",
            "params": ["0x4200000000000000000000000000000000000006", "pending"],
            "id": "getblock.io"
        }))
        .send()
        .await?
        .json::<Value>()
        .await?;

    println!("Result: {}", response["result"]);
    Ok(())
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

#### Response

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0x0de0b6b3a7640000"
}
```

The `result` is the hex-encoded balance in wei at the latest Flashblock. The same request with the `"latest"` tag returns the value at the last sealed block.

## Use Cases

* **Trading Platforms**: Surface preconfirmed order and swap results with sub-second latency.
* **Prediction Markets**: Reflect changes in market state as soon as transactions are preconfirmed.
* **Wallets**: Show instant transaction feedback and real-time balance updates before a block is sealed.
* **Nonce Management**: Use `eth_getTransactionCount` with `pending` to avoid nonce collisions during rapid submission.
* **Preconfirmed Receipts**: Poll `eth_getTransactionReceipt` to confirm inclusion at Flashblock cadence.


# Flashblocks API

Flashblocks API on the Base network: fetch the latest in-progress block, including all preconfirmed transactions. Quickstart examples in JavaScript and Python

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

{% hint style="info" %}

### To make use of Flashblocks:

Flashblocks are simply a class of RPC API methods that are now active on GetBlock endpoints for Base and Optimism. If you already run either chain with GetBlock, the new methods are available on your existing endpoint; if you are new, set up a Base or Optimism endpoint from the [GetBlock dashboard](https://account.getblock.io/) and the methods are there.
{% endhint %}

### 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 [`npm`](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) or [`yarn`](https://classic.yarnpkg.com/lang/en/docs/install) on your local machine (for the Axios example) or Python and pip (for the Python example).

{% tabs %}
{% tab title="JavaScript (Axios)" %}
{% stepper %}
{% step %}

### Setup project

```bash
mkdir flashblocks-quickstart
cd flashblocks-quickstart
npm init --yes
```

{% endstep %}

{% step %}

### Install Axios

```bash
npm install axios
```

{% endstep %}

{% step %}

### Create file

Create a new file named `index.js`. This is where you will make your first call.
{% endstep %}

{% step %}

### Set ES module type

Set the ES module `"type": "module"` in your `package.json`.
{% endstep %}

{% step %}

### Add code

{% code title="index.js" overflow="wrap" %}

```javascript
import axios from 'axios';

// Fetch the latest Flashblock (in-progress block with preconfirmed transactions)
const data = JSON.stringify({
    "jsonrpc": "2.0",
    "method": "eth_getBlockByNumber",
    "params": ["pending", false],
    "id": "getblock.io"
});

const config = {
    method: 'post',
    url: 'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers: {
        'Content-Type': 'application/json'
    },
    data: data
};

axios(config)
    .then(response => console.log(JSON.stringify(response.data, null, 2)))
    .catch(error => console.log(error));
```

{% endcode %}

Replace `<ACCESS-TOKEN>` with your actual access token from GetBlock (Base or Optimism endpoint).
{% endstep %}

{% step %}

### Run the script

```bash
node index.js
```

The response contains the current in-progress block, updated every 200ms (Base) or 250ms (Optimism). Call it again a few hundred milliseconds later and you'll see additional transactions included as new Flashblocks land.
{% endstep %}

{% step %}

### Result

{% code overflow="wrap" %}

```bash
{
    "jsonrpc": "2.0",
    "result": {
        "hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "parentHash": "0x64c3e43c9701407d6fb8bd853782a7fc77ba7f63e55a1cd1c5eaa1c0eaf3e8c4",
        "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
        "miner": "0x4200000000000000000000000000000000000011",
        "stateRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "transactionsRoot": "0x38131951ed5e3c8fa20b3cb08a75ccc33cb19e3a3cdf6260eae76a173900b934",
        "receiptsRoot": "0x83434863672598b03e64b1effdb3ad205345ad5114fd8b55995ad26571663a40",
        "logsBloom": "0x363031c23351743880d55105b76437b4e05246402bc44898a3353f4531021a41092f44aab543e301cf9f41d3a1a636817fd88880854d2114e7260fc360b46ef01f7a875144df34dc8f308f08ab498b24167c560d99ff32b5b0d3676a87638c373f9ea87cbe7a0b186609584f972b2ca8b1608b028894556464c28195591b539094351a2d3b3979be4623f816c522b87e372b826b2aa47a4cf27f20759540d4990e742b86a08811cf5e40b7370dcec2807bc44273421c8e5afff70b23407a5cd2be20996a72898ce94611dcd1ab2590a5080d878a8e78f83af193c6c3f908ec64621ebd8c179c90a3b4420f2c0aeb5cb6f0ba86c2b59e2956b2343d70af419883",
        "difficulty": "0x0",
        "number": "0x2de03b4",
        "gasLimit": "0x17d78400",
        "gasUsed": "0x11b1f57",
        "timestamp": "0x6a46644b",
        "extraData": "0x01000000640000000500000000004c4b40",
        "mixHash": "0xcb2806e22a6932ee882e44cb4899082c4eb130745740b14f5110d32c0e463236",
        "nonce": "0x0000000000000000",
        "baseFeePerGas": "0x4c4b40",
        "withdrawalsRoot": "0x5a6218671840987892338b76625664c7060d7b55b9e82414f9117f5388c406d4",
        "blobGasUsed": "0x351e14",
        "excessBlobGas": "0x0",
        "parentBeaconBlockRoot": "0x41922b97f16dd4c26d9680c0888d6eca48a96638988a310578c91cb1f76865ea",
        "requestsHash": "0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
        "uncles": [],
        "transactions": [
            "0x736d0f7b161888aef73271d4d147fa4ba5a4a42b1ef018fdab3605091aee21e3"      "0xe58be418f85a1281a3c0ba4951c33edf948568879acda466663d568512ec8e92",        "0x5bf2fba339a689973db07c54e1c22556c07a0c7fdcdf3f4918b2b7bd6fee75ab"     "0xa6bec80fa9c94c0d330e27421e414eaef85cc39800120a557b3e93dcb9e81adb",
            "0x7f291369918ece59ccc88efde10a9807aa7da285dfec7744d5cc184b75227ba8"
        ],
        "withdrawals": []
    },
    "id": 1
}

```

{% endcode %}
{% endstep %}
{% endstepper %}
{% endtab %}

{% tab title="Python (Requests)" %}
{% stepper %}
{% step %}

### Setup the project directory

```bash
mkdir flashblocks-quickstart
cd flashblocks-quickstart
```

{% endstep %}

{% step %}

### Create and activate a virtual environment

```bash
python -m venv venv
source venv/bin/activate

# On Windows, use venv\Scripts\activate
```

{% endstep %}

{% step %}

### Install requests

```bash
pip install requests
```

{% endstep %}

{% step %}

### Create script

{% code title="main.py" %}

```python
import requests
import json

url = "https://go.getblock.io/<ACCESS-TOKEN>/"

payload = json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_getBlockByNumber",
    "params": ["pending", False],
    "id": "getblock.io"
})

headers = {
    'Content-Type': 'application/json'
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endcode %}

Replace `<ACCESS-TOKEN>` with your actual GetBlock access token.
{% endstep %}

{% step %}

### Run the script

```bash
python main.py
```

{% endstep %}
{% endstepper %}
{% endtab %}
{% endtabs %}


# eth\_getTransactionCount - Flashblocks

Example code for the eth\_getTransactionCount Flashblocks method. Complete guide on how to use eth\_getTransactionCount Flashblocks in GetBlock Web3 documentation.

This returns the transaction count (nonce) for an address. When called with `"pending"`, the returned nonce already accounts for transactions currently sitting in Flashblocks — preventing nonce collisions when an account submits many transactions in rapid succession.&#x20;

This is especially valuable for high-frequency trading bots and any application that fires more than one transaction per 2-second block.

## Parameters

| Parameter | Type            | Required | Description      |
| --------- | --------------- | -------- | ---------------- |
| address   | DATA (20 bytes) | Yes      | Address to check |
| block     | QUANTITY        | TAG      | Yes              |

## Request Example

{% tabs %}
{% tab title="cURL" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_getTransactionCount",
    "params": [
        "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
        "pending"
    ],
    "id": "getblock.io"
}'
```

{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from 'axios';

const data = JSON.stringify({
    "jsonrpc": "2.0",
    "method": "eth_getTransactionCount",
    "params": [
        "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
        "pending"
    ],
    "id": "getblock.io"
});

const config = {
    method: 'post',
    url: 'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers: {
        'Content-Type': 'application/json'
    },
    data: data
};

axios(config)
    .then(response => console.log(JSON.stringify(response.data, null, 2)))
    .catch(error => console.log(error));
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import requests
import json

url = "https://go.getblock.io/<ACCESS-TOKEN>/"

payload = json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_getTransactionCount",
    "params": [
        "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
        "pending"
    ],
    "id": "getblock.io"
})

headers = {
    'Content-Type': 'application/json'
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_getTransactionCount",
        "params": [
                "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
                "pending"
        ],
        "id": "getblock.io"
});

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0x42"
}
```

{% endcode %}

## Response Parameters

| Field  | Type     | Description                                                                  |
| ------ | -------- | ---------------------------------------------------------------------------- |
| result | QUANTITY | Transaction count / next nonce in hex, including transactions in Flashblocks |

## Use Cases

* Constructing the next transaction with the correct nonce, even during high-frequency submission
* Preventing 'nonce too low' errors when submitting multiple transactions per block
* Trading bot infrastructure — the primary use case for the pending nonce

## Error Handling

| Status Code | Error Message     | Cause                                          |
| ----------- | ----------------- | ---------------------------------------------- |
| 403         | Forbidden         | Missing or invalid `<ACCESS-TOKEN>`            |
| -32602      | Invalid params    | Request parameters are missing or malformed    |
| -32603      | Internal error    | Server-side error while processing the request |
| 429         | Too Many Requests | Rate limit exceeded for your plan              |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

// Generic JSON-RPC call — 'pending' returns Flashblocks-preconfirmed state:
const result = await provider.send('eth_getTransactionCount', ["0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a", "pending"]);
console.log(result);

// Many standard methods have typed wrappers on ethers Provider that accept 'pending':
// provider.getBalance(addr, 'pending'), provider.getTransactionCount(addr, 'pending'), etc.
```

{% endtab %}

{% tab title="viem" %}

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

// viem's read methods accept blockTag: 'pending' for Flashblocks-preconfirmed state:
const result = await client.request({
    method: 'eth_getTransactionCount',
    params: ["0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a", "pending"]
});
console.log(result);

// Typed wrappers also accept blockTag: 'pending':
// client.getBalance({ address, blockTag: 'pending' })
// client.getBlock({ blockTag: 'pending' })
```

{% endtab %}
{% endtabs %}


# eth\_getStorageAt - Flashblocks

Example code for the eth\_getStorageAt Flashblock method. Complete guide on how to use eth\_getStorageAt Flashblock in GetBlock Web3 documentation.

This returns the value stored at a specific storage slot of a contract. When called with `"pending"`, reflects storage changes from every transaction preconfirmed into the latest Flashblock — letting applications read intermediate contract state before block seal.

## Parameters

| Parameter | Type            | Required | Description              |
| --------- | --------------- | -------- | ------------------------ |
| address   | DATA (20 bytes) | Yes      | Contract address         |
| slot      | QUANTITY        | Yes      | Storage slot index (hex) |
| block     | QUANTITY        | TAG      | Yes                      |

## Request Example

{% tabs %}
{% tab title="cURL" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_getStorageAt",
    "params": [
        "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
        "0x0",
        "pending"
    ],
    "id": "getblock.io"
}'
```

{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from 'axios';

const data = JSON.stringify({
    "jsonrpc": "2.0",
    "method": "eth_getStorageAt",
    "params": [
        "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
        "0x0",
        "pending"
    ],
    "id": "getblock.io"
});

const config = {
    method: 'post',
    url: 'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers: {
        'Content-Type': 'application/json'
    },
    data: data
};

axios(config)
    .then(response => console.log(JSON.stringify(response.data, null, 2)))
    .catch(error => console.log(error));
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import requests
import json

url = "https://go.getblock.io/<ACCESS-TOKEN>/"

payload = json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_getStorageAt",
    "params": [
        "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
        "0x0",
        "pending"
    ],
    "id": "getblock.io"
})

headers = {
    'Content-Type': 'application/json'
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_getStorageAt",
        "params": [
                "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
                "0x0",
                "pending"
        ],
        "id": "getblock.io"
});

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0x0000000000000000000000000000000000000000000000000000000000000064"
}
```

{% endcode %}

## Response Parameters

| Field  | Type            | Description                                              |
| ------ | --------------- | -------------------------------------------------------- |
| result | DATA (32 bytes) | Value at the storage slot, reflecting preconfirmed state |

## Use Cases

* Reading contract state that has been updated by preconfirmed transactions
* Monitoring internal state changes in real-time (e.g. AMM reserves, oracle prices)
* Auditing tools that need to-the-Flashblock state visibility

## Error Handling

| Status Code | Error Message     | Cause                                          |
| ----------- | ----------------- | ---------------------------------------------- |
| 403         | Forbidden         | Missing or invalid `<ACCESS-TOKEN>`            |
| -32602      | Invalid params    | Request parameters are missing or malformed    |
| -32603      | Internal error    | Server-side error while processing the request |
| 429         | Too Many Requests | Rate limit exceeded for your plan              |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

// Generic JSON-RPC call — 'pending' returns Flashblocks-preconfirmed state:
const result = await provider.send('eth_getStorageAt', ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "0x0", "pending"]);
console.log(result);

// Many standard methods have typed wrappers on ethers Provider that accept 'pending':
// provider.getBalance(addr, 'pending'), provider.getTransactionCount(addr, 'pending'), etc.
```

{% endtab %}

{% tab title="viem" %}

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

// viem's read methods accept blockTag: 'pending' for Flashblocks-preconfirmed state:
const result = await client.request({
    method: 'eth_getStorageAt',
    params: ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "0x0", "pending"]
});
console.log(result);

// Typed wrappers also accept blockTag: 'pending':
// client.getBalance({ address, blockTag: 'pending' })
// client.getBlock({ blockTag: 'pending' })
```

{% endtab %}
{% endtabs %}


# eth\_getBalance - Flashblocks

Example code for the eth\_getBalance Flashblocksmethod. Complete guide on how to use eth\_getBalance Flashblocks in GetBlock Web3 documentation.

This returns the ETH balance of an address in wei. When called with `"pending"`, includes the effect of every transaction preconfirmed into the latest Flashblock — usually within 200ms (Base) or 250ms (Optimism) of the user's submission. Applications that update balance UIs on the `pending` tag give users near-instant feedback that a transfer has landed.

## Parameters

| Parameter | Type            | Required | Description      |
| --------- | --------------- | -------- | ---------------- |
| address   | DATA (20 bytes) | Yes      | Address to check |
| block     | QUANTITY        | TAG      | Yes              |

## Request Example

{% tabs %}
{% tab title="cURL" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": [
        "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
        "pending"
    ],
    "id": "getblock.io"
}'
```

{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from 'axios';

const data = JSON.stringify({
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": [
        "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
        "pending"
    ],
    "id": "getblock.io"
});

const config = {
    method: 'post',
    url: 'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers: {
        'Content-Type': 'application/json'
    },
    data: data
};

axios(config)
    .then(response => console.log(JSON.stringify(response.data, null, 2)))
    .catch(error => console.log(error));
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import requests
import json

url = "https://go.getblock.io/<ACCESS-TOKEN>/"

payload = json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": [
        "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
        "pending"
    ],
    "id": "getblock.io"
})

headers = {
    'Content-Type': 'application/json'
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_getBalance",
        "params": [
                "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
                "pending"
        ],
        "id": "getblock.io"
});

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0x1bc16d674ec80000"
}
```

{% endcode %}

## Response Parameters

| Field  | Type     | Description                                      |
| ------ | -------- | ------------------------------------------------ |
| result | QUANTITY | Balance in wei (hex). Divide by 10^18 to get ETH |

## Use Cases

* Wallet UIs showing near-instant balance updates after a transfer
* Payment applications confirming a payment has been received before block seal
* Trading bots that need to know current available balance including unsealed transfers

## Error Handling

| Status Code | Error Message     | Cause                                                                                                 |
| ----------- | ----------------- | ----------------------------------------------------------------------------------------------------- |
| 403         | Forbidden         | Missing or invalid `<ACCESS-TOKEN>`                                                                   |
| -32602      | Invalid params    | Request parameters are missing or malformed                                                           |
| -32601      | Method not found  | Method does not exist or is not enabled on this endpoint. Confirm your endpoint is Flashblocks-aware. |
| -32603      | Internal error    | Server-side error while processing the request                                                        |
| 429         | Too Many Requests | Rate limit exceeded for your plan                                                                     |
| -32602      | Invalid address   | Address is not a valid 20-byte hex string                                                             |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}
{% code overflow="wrap" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

// Generic JSON-RPC call — 'pending' returns Flashblocks-preconfirmed state:
const result = await provider.send('eth_getBalance', ["0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a", "pending"]);
console.log(result);

// Many standard methods have typed wrappers on ethers Provider that accept 'pending':
// provider.getBalance(addr, 'pending'), provider.getTransactionCount(addr, 'pending'), etc.
```

{% endcode %}
{% endtab %}

{% tab title="viem" %}

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

// viem's read methods accept blockTag: 'pending' for Flashblocks-preconfirmed state:
const result = await client.request({
    method: 'eth_getBalance',
    params: ["0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a", "pending"]
});
console.log(result);

// Typed wrappers also accept blockTag: 'pending':
// client.getBalance({ address, blockTag: 'pending' })
// client.getBlock({ blockTag: 'pending' })
```

{% endtab %}
{% endtabs %}


# eth\_getBlockByNumber - Flashblocks

Example code for the eth\_getBlockByNumber Flashblocks method. Complete guide on how to use eth\_getBlockByNumber  Flashblocks in GetBlock Web3 documentation.

This returns the current in-progress Flashblock when called with `"pending"` — including every transaction that has landed in Flashblocks since the last block sealed. Pass `true` as the second parameter for full transaction objects; `false` for hashes only. When called with `"latest"`, returns the last sealed block as usual. Preconfirmed Flashblocks are distinguishable from finalized blocks by their zero `stateRoot` and by the absence of a final block hash.

## Parameters

| Parameter        | Type     | Required | Description                                                  |
| ---------------- | -------- | -------- | ------------------------------------------------------------ |
| blockNumber      | QUANTITY | TAG      | Yes                                                          |
| fullTransactions | boolean  | Yes      | `true` for full transaction objects, `false` for hashes only |

## Request Example

{% tabs %}
{% tab title="cURL" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_getBlockByNumber",
    "params": [
        "pending",
        false
    ],
    "id": "getblock.io"
}'
```

{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from 'axios';

const data = JSON.stringify({
    "jsonrpc": "2.0",
    "method": "eth_getBlockByNumber",
    "params": [
        "pending",
        false
    ],
    "id": "getblock.io"
});

const config = {
    method: 'post',
    url: 'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers: {
        'Content-Type': 'application/json'
    },
    data: data
};

axios(config)
    .then(response => console.log(JSON.stringify(response.data, null, 2)))
    .catch(error => console.log(error));
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import requests
import json

url = "https://go.getblock.io/<ACCESS-TOKEN>/"

payload = json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_getBlockByNumber",
    "params": [
        "pending",
        false
    ],
    "id": "getblock.io"
})

headers = {
    'Content-Type': 'application/json'
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_getBlockByNumber",
        "params": [
                "pending",
                false
        ],
        "id": "getblock.io"
});

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": {
        "number": "0x16e3600",
        "hash": null,
        "parentHash": "0x47edbdc8da5cd1b3127ea8f1ce5da6739fa39e7e6d2eb1c9b50f1c83de0a98b4",
        "timestamp": "0x68f3b85f",
        "miner": "0x4200000000000000000000000000000000000011",
        "gasLimit": "0x3938700",
        "gasUsed": "0x1c2b40",
        "baseFeePerGas": "0x2540be400",
        "stateRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "transactions": [
            "0xa8f9b3c7d2e4f6a1b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6"
        ],
        "size": "0x42a"
    }
}
```

{% endcode %}

## Response Parameters

| Field               | Type     | Description                                                                         |
| ------------------- | -------- | ----------------------------------------------------------------------------------- |
| result.number       | QUANTITY | In-progress block number (the same as the next `latest` will be)                    |
| result.hash         | DATA     | `null` for Flashblocks (block not yet sealed) — a real hash appears only after seal |
| result.parentHash   | DATA     | Parent block hash (last sealed block)                                               |
| result.stateRoot    | DATA     | Zero hash on Flashblocks (state not yet committed); real root when block seals      |
| result.transactions | array    | Every transaction preconfirmed into Flashblocks so far in this in-progress block    |
| result.timestamp    | QUANTITY | Timestamp of the in-progress block                                                  |

## Use Cases

* Fast block scanning — read the current preconfirmed state up to 1.8 seconds before the block seals
* Building real-time DeFi dashboards that show transactions as they land
* MEV analysis — inspecting sequencer-ordered transactions before finalization
* Detecting the current Flashblock index to time downstream operations

## Error Handling

| Status Code | Error Message         | Cause                                                                          |
| ----------- | --------------------- | ------------------------------------------------------------------------------ |
| 403         | Forbidden             | Missing or invalid `<ACCESS-TOKEN>`                                            |
| -32602      | Invalid params        | Request parameters are missing or malformed                                    |
| -32603      | Internal error        | Server-side error while processing the request                                 |
| 429         | Too Many Requests     | Rate limit exceeded for your plan                                              |
| -32000      | Sequencer unavailable | Flashblocks stream is temporarily down — response falls back to `latest` state |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}
{% code overflow="wrap" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

// Generic JSON-RPC call — 'pending' returns Flashblocks-preconfirmed state:
const result = await provider.send('eth_getBlockByNumber', ["pending", false]);
console.log(result);

// Many standard methods have typed wrappers on ethers Provider that accept 'pending':
// provider.getBalance(addr, 'pending'), provider.getTransactionCount(addr, 'pending'), etc.
```

{% endcode %}
{% endtab %}

{% tab title="viem" %}

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

// viem's read methods accept blockTag: 'pending' for Flashblocks-preconfirmed state:
const result = await client.request({
    method: 'eth_getBlockByNumber',
    params: ["pending", false]
});
console.log(result);

// Typed wrappers also accept blockTag: 'pending':
// client.getBalance({ address, blockTag: 'pending' })
// client.getBlock({ blockTag: 'pending' })
```

{% endtab %}
{% endtabs %}


# eth\_getBlockReceipt - Flashblocks

Example code for the eth\_getBlockReceipt  Flashblocks method. Complete guide on how to use eth\_getBlockReceipt Flashblocks in GetBlock Web3 documentation.

This returns the receipt of a block — preconfirmed OR finalized. Preconfirmed receipts are identifiable by their zero `blockHash` (`0x00...00`) and `blockNumber: null`. Once the parent block seals (within 2 seconds), the same receipt returns with a real block hash. This zero-hash convention is the canonical way to distinguish preconfirmed vs finalized receipts without additional RPC calls.

## Parameters

| Parameter   | Type     | Required | Description |
| ----------- | -------- | -------- | ----------- |
| blockNumber | QUANTITY | TAG      | Yes         |

## Request Example

{% tabs %}
{% tab title="cURL" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
  "jsonrpc": "2.0",
  "method": "eth_getBlockReceipts",
  "params": [
    "pending"
  ],
  "id": "getblock.io"
}'
```

{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from 'axios';

const data = JSON.stringify({
  "jsonrpc": "2.0",
  "method": "eth_getBlockReceipts",
  "params": [
    "pending"
  ],
  "id": "getblock.io"
});

const config = {
    method: 'post',
    url: 'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers: {
        'Content-Type': 'application/json'
    },
    data: data
};

axios(config)
    .then(response => console.log(JSON.stringify(response.data, null, 2)))
    .catch(error => console.log(error));
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import requests
import json

url = "https://go.getblock.io/<ACCESS-TOKEN>/"

payload = json.dumps({{
  "jsonrpc": "2.0",
  "method": "eth_getBlockReceipts",
  "params": [
    "pending"
  ],
  "id": "getblock.io"
})

headers = {
    'Content-Type': 'application/json'
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({
  "jsonrpc": "2.0",
  "method": "eth_getBlockReceipts",
  "params": [
    "pending"
  ],
  "id": "getblock.io"
});

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "result": [
        {
            "type": "0x7e",
            "status": "0x1",
            "cumulativeGasUsed": "0xb496",
            "logs": [],
            "depositNonce": "0x2ddfd39",
            "depositReceiptVersion": "0x1",
            "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
            "transactionHash": "0xd6586cd3a1cf6f2a79dfdc513863cbaff925578131dc9e42872acdc3dab4aee9",
            "transactionIndex": "0x0",
            "blockHash": "0xe9526259318b13325e3926a3d29a4323d53d7e3c25ebfcf6b0f7ace7376af639",
            "blockNumber": "0x2ddfd36",
            "gasUsed": "0xb496",
            "effectiveGasPrice": "0x0",
            "blobGasUsed": "0x41e8",
            "from": "0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001",
            "to": "0x4200000000000000000000000000000000000015",
            "contractAddress": null,
            "l1GasPrice": "0x1564212e",
            "l1GasUsed": "0x72a",
            "l1Fee": "0x0",
            "l1BaseFeeScalar": "0x8dd",
            "l1BlobBaseFee": "0x1571d4a",
            "l1BlobBaseFeeScalar": "0x101c12",
            "daFootprintGasScalar": "0x94"
  }
   ],
    "id": "getblock.io"
}
```

{% endcode %}

## Response Parameters

| Field                    | Type         | Description                                                                      |
| ------------------------ | ------------ | -------------------------------------------------------------------------------- |
| result.blockHash         | DATA         | `0x00...00` (zero hash) for preconfirmed receipts; real block hash for finalized |
| result.blockNumber       | QUANTITY     | `null` for preconfirmed; block number in hex for finalized                       |
| result.status            | QUANTITY     | `0x1` = success, `0x0` = reverted                                                |
| result.gasUsed           | QUANTITY     | Actual gas consumed                                                              |
| result.effectiveGasPrice | QUANTITY     | Effective gas price paid                                                         |
| result.logs              | array of Log | Event logs emitted during execution                                              |

## Use Cases

* Wallet UIs showing preconfirmed transaction success within 200ms of submission
* Polling for confirmed inclusion at 200ms cadence instead of 2s
* Distinguishing 'transaction preconfirmed' vs 'transaction finalized' UX states
* Detecting transaction revert or success before block seal

## Error Handling

| Status Code | Error Message     | Cause                                          |
| ----------- | ----------------- | ---------------------------------------------- |
| 403         | Forbidden         | Missing or invalid `<ACCESS-TOKEN>`            |
| -32602      | Invalid params    | Request parameters are missing or malformed    |
| -32603      | Internal error    | Server-side error while processing the request |
| 429         | Too Many Requests | Rate limit exceeded for your plan              |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}
{% code overflow="wrap" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

// Generic JSON-RPC call — 'pending' returns Flashblocks-preconfirmed state:
const result = await provider.send('eth_getBlockReceipts', ["pending"]);
console.log(result);

// Many standard methods have typed wrappers on ethers Provider that accept 'pending':
```

{% endcode %}
{% endtab %}

{% tab title="viem" %}
{% code overflow="wrap" %}

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

// viem's read methods accept blockTag: 'pending' for Flashblocks-preconfirmed state:
const result = await client.request({
    method: 'eth_getBlockReceipts',
    params: ["pending"]
});
console.log(result);
```

{% endcode %}
{% endtab %}
{% endtabs %}


# eth\_getBlockTransactionCountByNumber - Flashblocks

Example code for eth\_getBlockTransactionCountByNumber Flashblocks method. Complete guide on how to use eth\_getBlockTransactionCountByNumber Flashblocks in GetBlock Web3 documentation.

This returns the pending number of transactions in a block.&#x20;

## Parameters

| Parameter    | Type     | Required | Description             |
| ------------ | -------- | -------- | ----------------------- |
| block number | QUANTITY | TAG, Yes | the pending transaction |

## Request Example

{% tabs %}
{% tab title="cURL" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
  "jsonrpc": "2.0",
  "method": "eth_getBlockTransactionCountByNumber",
  "params": [
    "pending"
  ],
  "id": "getblock.io"
}'
```

{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from 'axios';

const data = JSON.stringify({
  "jsonrpc": "2.0",
  "method": "eth_getBlockTransactionCountByNumber",
  "params": [
    "pending"
  ],
  "id": "getblock.io"
});

const config = {
    method: 'post',
    url: 'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers: {
        'Content-Type': 'application/json'
    },
    data: data
};

axios(config)
    .then(response => console.log(JSON.stringify(response.data, null, 2)))
    .catch(error => console.log(error));
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import requests
import json

url = "https://go.getblock.io/<ACCESS-TOKEN>/"

payload = json.dumps({
  "jsonrpc": "2.0",
  "method": "eth_getBlockTransactionCountByNumber",
  "params": [
    "pending"
  ],
  "id": "getblock.io"
})

headers = {
    'Content-Type': 'application/json'
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_getTransactionByHash",
        "params": [
                "0xa8f9b3c7d2e4f6a1b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6"
        ],
        "id": "getblock.io"
});

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "result": "0x8b",
    "id": "getblock.io"
}

```

{% endcode %}

## Response Parameters

| Field  | Type   | Description                                            |
| ------ | ------ | ------------------------------------------------------ |
| result | string | `0x00...00` for preconfirmed; real hash once finalized |

## Use Cases

* Confirming a transaction has been received and included in a Flashblock
* Reading calldata / value of a preconfirmed transaction for follow-up processing
* Building activity feeds with sub-second latency

## Error Handling

| Status Code | Error Message     | Cause                                          |
| ----------- | ----------------- | ---------------------------------------------- |
| 403         | Forbidden         | Missing or invalid `<ACCESS-TOKEN>`            |
| -32602      | Invalid params    | Request parameters are missing or malformed    |
| -32603      | Internal error    | Server-side error while processing the request |
| 429         | Too Many Requests | Rate limit exceeded for your plan              |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}
{% code overflow="wrap" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

// Generic JSON-RPC call — 'pending' returns Flashblocks-preconfirmed state:
const result = await provider.send('eth_getBlockTransactionCountByNumber', ["pending"]);
console.log(result);
```

{% endcode %}
{% endtab %}

{% tab title="viem" %}

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

// viem's read methods accept blockTag: 'pending' for Flashblocks-preconfirmed state:
const result = await client.request({
    method: 'eth_getBlockTransactionCountByNumber',
    params: ["pending"]
});
console.log(result);
```

{% endtab %}
{% endtabs %}


# eth\_estimateGas - Flashblocks

Example code for the eth\_estimateGas - Flashblocks method. Complete guide on how to use eth\_estimateGas - Flashblocks in GetBlock Web3 documentation.

This estimates the gas needed to execute a transaction without submitting it. When called with `"pending"`, the estimate is computed against state including preconfirmed transactions in the latest Flashblock — giving more accurate estimates for transactions that depend on state changes happening in the current block.

## Parameters

| Parameter  | Type     | Required | Description                                                                     |
| ---------- | -------- | -------- | ------------------------------------------------------------------------------- |
| callObject | object   | Yes      | Same shape as `eth_call` parameters                                             |
| block      | QUANTITY | No       | `"pending"` for gas estimate against preconfirmed state (default is `"latest"`) |

## Request Example

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_estimateGas",
    "params": [
        {
            "from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
            "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
            "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0"
        },
        "pending"
    ],
    "id": "getblock.io"
}'
```

{% endcode %}
{% endtab %}

{% tab title="JavaScript (Axios)" %}
{% code overflow="wrap" %}

```javascript
import axios from 'axios';

const data = JSON.stringify({
    "jsonrpc": "2.0",
    "method": "eth_estimateGas",
    "params": [
        {
            "from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
            "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
            "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0"
        },
        "pending"
    ],
    "id": "getblock.io"
});

const config = {
    method: 'post',
    url: 'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers: {
        'Content-Type': 'application/json'
    },
    data: data
};

axios(config)
    .then(response => console.log(JSON.stringify(response.data, null, 2)))
    .catch(error => console.log(error));
```

{% endcode %}
{% endtab %}

{% tab title="Python (Requests)" %}
{% code overflow="wrap" %}

```python
import requests
import json

url = "https://go.getblock.io/<ACCESS-TOKEN>/"

payload = json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_estimateGas",
    "params": [
        {
            "from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
            "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
            "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0"
        },
        "pending"
    ],
    "id": "getblock.io"
})

headers = {
    'Content-Type': 'application/json'
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endcode %}
{% endtab %}

{% tab title="Rust (Reqwest)" %}
{% code overflow="wrap" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_estimateGas",
        "params": [
                {
                        "from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a",
                        "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
                        "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0"
                },
                "pending"
        ],
        "id": "getblock.io"
});

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0xc350"
}
```

{% endcode %}

## Response Parameters

| Field  | Type     | Description               |
| ------ | -------- | ------------------------- |
| result | QUANTITY | Estimated gas units (hex) |

## Use Cases

* Accurate gas estimation for transactions that depend on preconfirmed state (e.g. sequential swaps in a bundle)
* Detecting transactions that would revert given preconfirmed state changes
* Wallet fee suggestion UIs with Flashblocks-aware accuracy

## Error Handling

| Status Code | Error Message      | Cause                                                                                |
| ----------- | ------------------ | ------------------------------------------------------------------------------------ |
| 403         | Forbidden          | Missing or invalid `<ACCESS-TOKEN>`                                                  |
| -32602      | Invalid params     | Request parameters are missing or malformed                                          |
| -32603      | Internal error     | Server-side error while processing the request                                       |
| 429         | Too Many Requests  | Rate limit exceeded for your plan                                                    |
| 3           | execution reverted | Transaction would revert against the preconfirmed state — estimation cannot complete |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}
{% code overflow="wrap" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

// Generic JSON-RPC call — 'pending' returns Flashblocks-preconfirmed state:
const result = await provider.send('eth_estimateGas', [{"from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a", "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0"}, "pending"]);
console.log(result);

// Many standard methods have typed wrappers on ethers Provider that accept 'pending':
// provider.getBalance(addr, 'pending'), provider.getTransactionCount(addr, 'pending'), etc.
```

{% endcode %}
{% endtab %}

{% tab title="viem" %}
{% code overflow="wrap" %}

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

// viem's read methods accept blockTag: 'pending' for Flashblocks-preconfirmed state:
const result = await client.request({
    method: 'eth_estimateGas',
    params: [{"from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a", "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0"}, "pending"]
});
console.log(result);

// Typed wrappers also accept blockTag: 'pending':
// client.getBalance({ address, blockTag: 'pending' })
// client.getBlock({ blockTag: 'pending' })
```

{% endcode %}
{% endtab %}
{% endtabs %}


# eth\_call - Flashblocks

Example code for the eth\_call - Flashblocks method. Complete guide on how to use eth\_call - Flashblocks in GetBlock Web3 documentation.

This executes a read-only contract call without creating a transaction. When the block reference is `"pending"`, the call executes against state including every transaction preconfirmed into the latest Flashblocks. This lets applications compute derived values (token balances, oracle prices, pool reserves) reflecting the freshest possible state.

## Parameters

| Parameter  | Type     | Required | Description                                                                                               |
| ---------- | -------- | -------- | --------------------------------------------------------------------------------------------------------- |
| callObject | object   | Yes      | Call params: `to`, `data`, `from` (optional), `gas` (optional), `gasPrice` (optional), `value` (optional) |
| block      | QUANTITY | TAG      | Yes                                                                                                       |

## Request Example

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_call",
    "params": [
        {
            "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
            "data": "0x70a082310000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a"
        },
        "pending"
    ],
    "id": "getblock.io"
}'
```

{% endcode %}
{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from 'axios';

const data = JSON.stringify({
    "jsonrpc": "2.0",
    "method": "eth_call",
    "params": [
        {
            "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
            "data": "0x70a082310000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a"
        },
        "pending"
    ],
    "id": "getblock.io"
});

const config = {
    method: 'post',
    url: 'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers: {
        'Content-Type': 'application/json'
    },
    data: data
};

axios(config)
    .then(response => console.log(JSON.stringify(response.data, null, 2)))
    .catch(error => console.log(error));
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import requests
import json

url = "https://go.getblock.io/<ACCESS-TOKEN>/"

payload = json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_call",
    "params": [
        {
            "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
            "data": "0x70a082310000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a"
        },
        "pending"
    ],
    "id": "getblock.io"
})

headers = {
    'Content-Type': 'application/json'
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_call",
        "params": [
                {
                        "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
                        "data": "0x70a082310000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a"
                },
                "pending"
        ],
        "id": "getblock.io"
});

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0x000000000000000000000000000000000000000000000000000000000098967f"
}
```

## Response Parameters

| Field  | Type | Description                                     |
| ------ | ---- | ----------------------------------------------- |
| result | DATA | ABI-encoded return value from the contract call |

## Use Cases

* Reading ERC-20 balances / allowances reflecting the latest preconfirmed transfers
* Fetching oracle prices with sub-block latency
* Pre-flight quotes for DEX swaps against the freshest reserves
* Any read that needs to reflect state 200ms ahead of the standard `latest` tag

## Error Handling

| Status Code | Error Message       | Cause                                                                |
| ----------- | ------------------- | -------------------------------------------------------------------- |
| 403         | Forbidden           | Missing or invalid `<ACCESS-TOKEN>`                                  |
| -32602      | Invalid params      | Request parameters are missing or malformed                          |
| -32603      | Internal error      | Server-side error while processing the request                       |
| 429         | Too Many Requests   | Rate limit exceeded for your plan                                    |
| 3           | execution reverted  | Contract execution reverted — the contract's logic rejected the call |
| -32602      | Invalid call object | Malformed call parameters                                            |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

// Generic JSON-RPC call — 'pending' returns Flashblocks-preconfirmed state:
const result = await provider.send('eth_call', [{"to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "data": "0x70a082310000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a"}, "pending"]);
console.log(result);

// Many standard methods have typed wrappers on ethers Provider that accept 'pending':
// provider.getBalance(addr, 'pending'), provider.getTransactionCount(addr, 'pending'), etc.
```

{% endtab %}

{% tab title="viem" %}

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

// viem's read methods accept blockTag: 'pending' for Flashblocks-preconfirmed state:
const result = await client.request({
    method: 'eth_call',
    params: [{"to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "data": "0x70a082310000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a"}, "pending"]
});
console.log(result);

// Typed wrappers also accept blockTag: 'pending':
// client.getBalance({ address, blockTag: 'pending' })
// client.getBlock({ blockTag: 'pending' })
```

{% endtab %}
{% endtabs %}


# eth\_simulateV1 - Flashblocks

Example code for the eth\_simulateV1 - Flashblocks method. Complete guide on how to use eth\_simulateV1 - Flashblocks in GetBlock Web3 documentation.

This simulates a bundle of transactions against the latest Flashblocks — including state overrides, transfer tracing, and full validation. This is critical for MEV searchers, liquidation bots, and any application that needs to know "what would happen if I submitted this bundle right now, given the preconfirmed state?" The simulation reflects every transaction already committed to the in-progress block.

## Parameters

| Parameter        | Type     | Required | Description                                                                                                |
| ---------------- | -------- | -------- | ---------------------------------------------------------------------------------------------------------- |
| simulationParams | object   | Yes      | Simulation object: `blockStateCalls` (array of call bundles), `traceTransfers` (bool), `validation` (bool) |
| block            | QUANTITY | TAG      | Yes                                                                                                        |

## Request Example

{% tabs %}
{% tab title="cURL" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_simulateV1",
    "params": [
        {
            "blockStateCalls": [
                {
                    "calls": [
                        {
                            "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
                            "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0",
                            "from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a"
                        }
                    ],
                    "stateOverrides": {}
                }
            ],
            "traceTransfers": true,
            "validation": true
        },
        "pending"
    ],
    "id": "getblock.io"
}'
```

{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from 'axios';

const data = JSON.stringify({
    "jsonrpc": "2.0",
    "method": "eth_simulateV1",
    "params": [
        {
            "blockStateCalls": [
                {
                    "calls": [
                        {
                            "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
                            "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0",
                            "from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a"
                        }
                    ],
                    "stateOverrides": {}
                }
            ],
            "traceTransfers": true,
            "validation": true
        },
        "pending"
    ],
    "id": "getblock.io"
});

const config = {
    method: 'post',
    url: 'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers: {
        'Content-Type': 'application/json'
    },
    data: data
};

axios(config)
    .then(response => console.log(JSON.stringify(response.data, null, 2)))
    .catch(error => console.log(error));
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import requests
import json

url = "https://go.getblock.io/<ACCESS-TOKEN>/"

payload = json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_simulateV1",
    "params": [
        {
            "blockStateCalls": [
                {
                    "calls": [
                        {
                            "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
                            "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0",
                            "from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a"
                        }
                    ],
                    "stateOverrides": {}
                }
            ],
            "traceTransfers": true,
            "validation": true
        },
        "pending"
    ],
    "id": "getblock.io"
})

headers = {
    'Content-Type': 'application/json'
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_simulateV1",
        "params": [
                {
                        "blockStateCalls": [
                                {
                                        "calls": [
                                                {
                                                        "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
                                                        "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0",
                                                        "from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a"
                                                }
                                        ],
                                        "stateOverrides": {}
                                }
                        ],
                        "traceTransfers": true,
                        "validation": true
                },
                "pending"
        ],
        "id": "getblock.io"
});

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": [
        {
            "number": "0x16e3600",
            "hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
            "timestamp": "0x68f3b85f",
            "gasLimit": "0x3938700",
            "gasUsed": "0x5208",
            "calls": [
                {
                    "status": "0x1",
                    "gasUsed": "0x5208",
                    "returnData": "0x0000000000000000000000000000000000000000000000000000000000000001",
                    "logs": [
                        {
                            "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
                            "topics": [
                                "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
                            ],
                            "data": "0x00000000000000000000000000000000000000000000000000000000000186a0"
                        }
                    ]
                }
            ]
        }
    ]
}
```

{% endcode %}

## Response Parameters

| Field                         | Type     | Description                                                |
| ----------------------------- | -------- | ---------------------------------------------------------- |
| result                        | array    | Simulated block(s) — one entry per block state call bundle |
| result\[].calls               | array    | Per-call simulation result                                 |
| result\[].calls\[].status     | QUANTITY | `0x1` = success, `0x0` = reverted                          |
| result\[].calls\[].gasUsed    | QUANTITY | Gas consumed by the call                                   |
| result\[].calls\[].returnData | DATA     | ABI-encoded return value                                   |
| result\[].calls\[].logs       | array    | Event logs the call would emit                             |

## Use Cases

* MEV searchers testing bundle profitability against preconfirmed state
* Liquidation bots validating a liquidation call would succeed at the current preconfirmed price
* DEX aggregators simulating multi-hop swap routes against the freshest reserves
* Wallet UX preflight — showing users the projected outcome of their transaction before signing

## Error Handling

| Status Code | Error Message                 | Cause                                          |
| ----------- | ----------------------------- | ---------------------------------------------- |
| 403         | Forbidden                     | Missing or invalid `<ACCESS-TOKEN>`            |
| -32602      | Invalid params                | Request parameters are missing or malformed    |
| -32603      | Internal error                | Server-side error while processing the request |
| 429         | Too Many Requests             | Rate limit exceeded for your plan              |
| 3           | execution reverted            | One or more calls in the simulation reverted   |
| -32602      | Invalid simulation parameters | Malformed simulation object                    |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}
{% code overflow="wrap" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

// Flashblocks-specific methods use the raw send interface:
const result = await provider.send('eth_simulateV1', [{"blockStateCalls": [{"calls": [{"to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0", "from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a"}], "stateOverrides": {}}], "traceTransfers": true, "validation": true}, "pending"]);
console.log(result);
```

{% endcode %}
{% endtab %}

{% tab title="viem" %}
{% code overflow="wrap" %}

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

// Flashblocks-specific methods need the raw request transport:
const result = await client.request({
    method: 'eth_simulateV1',
    params: [{"blockStateCalls": [{"calls": [{"to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "data": "0xa9059cbb0000000000000000000000007a25d0f0ff6a25f36de0a19c3d5f6dc2c6eaed6a00000000000000000000000000000000000000000000000000000000000186a0", "from": "0x7a25d0f0Ff6a25f36De0a19C3d5f6dC2C6EAeD6a"}], "stateOverrides": {}}], "traceTransfers": true, "validation": true}, "pending"]
});
console.log(result);
```

{% endcode %}
{% endtab %}
{% endtabs %}


# eth\_getLogs - Flashblocks

Example code for the eth\_getLogs JSON-RPC method. Complete guide on how to use eth\_getLogs JSON-RPC in GetBlock Web3 documentation.

This returns query logs from pre-confirmed transactions, updated every \~200ms.&#x20;

## Parameters

| Parameter    | Type   | Required | Description           |
| ------------ | ------ | -------- | --------------------- |
| filterObject | object | Yes      | Filter options object |

### Filter Object

| Field     | Type         | Required | Description                                                   |
| --------- | ------------ | -------- | ------------------------------------------------------------- |
| fromBlock | string       | No       | Start block number (hex) or "latest", "earliest" or "pending" |
| toBlock   | string       | No       | End block number (hex) or "latest", "earliest"                |
| address   | string/array | No       | Contract address or array of addresses                        |
| topics    | array        | No       | Array of topic filters (up to 4 topics)                       |
| blockHash | string       | No       | Specific block hash (alternative to fromBlock/toBlock)        |

## Request

{% tabs %}
{% tab title="cURL" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_getLogs",
    "params": [{
      "fromBlock": "pending",
      "toBlock": "pending",
      "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]
    }],
    "id": 1
  }'
```

{% endtab %}

{% tab title="Axios" %}
{% code overflow="wrap" %}

```javascript
const axios = require('axios');

// Query ERC-20 Transfer events
const transferTopic = '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef';

const response = await axios.post('https://go.getblock.io/<ACCESS-TOKEN>/', {
    "jsonrpc": "2.0",
    "method": "eth_getLogs",
    "params": [{
      "fromBlock": "pending",
      "toBlock": "pending",
      "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
    }],
    "id": 1
  }, {
    headers: { 'Content-Type': 'application/json' }
});

const logs = response.data.result;
console.log('Found', logs.length, 'transfer events');
logs.forEach(log => {
    console.log('Block:', parseInt(log.blockNumber, 16));
    console.log('Tx:', log.transactionHash);
});
```

{% endcode %}
{% endtab %}

{% tab title="Request" %}

```python
import requests

# ERC-20 Transfer event signature
transfer_topic = '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef'

response = requests.post(
    'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers={'Content-Type': 'application/json'},
    json={
    "jsonrpc": "2.0",
    "method": "eth_getLogs",
    "params": [{
      "fromBlock": "pending",
      "toBlock": "pending",
      "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    }],
    "id": "getblock.io"
  }
)

result = response.json()
logs = result['result']
print(f'Found {len(logs)} transfer events')
for log in logs:
    print(f'Block: {int(log["blockNumber"], 16)}')
```

{% endtab %}
{% endtabs %}

## Response

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "result": [
        {
            "address": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
            "topics": [
                "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
                "0x000000000000000000000000b2cc224c1c9fee385f8ad6a55b4d94e92359dc59",
                "0x00000000000000000000000051c72848c68a965f66fa7a88855f9f7784502a7f"
            ],
            "data": "0x00000000000000000000000000000000000000000000000000000000c2c9d499",
            "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
            "blockNumber": "0x2ddffa0",
            "blockTimestamp": "0x6a465c23",
            "transactionHash": "0xfe22be1e04c2b149559b7244f4c5b03693a071cfa5a834590dc16bed318ebeab",
            "transactionIndex": "0x1",
            "logIndex": "0x0",
            "removed": false
        },
        {
            "address": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
            "topics": [
                "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
                "0x0000000000000000000000004e962bb3889bf030368f56810a9c96b83cb3e778",
                "0x00000000000000000000000051c72848c68a965f66fa7a88855f9f7784502a7f"
            ],
            "data": "0x00000000000000000000000000000000000000000000000000000001309ccb9c",
            "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
            "blockNumber": "0x2ddffa0",
            "blockTimestamp": "0x6a465c23",
            "transactionHash": "0x201d890aee2c4b934801032f2b72e888c6a332cda7ccd76cf9e549bd166bf91a",
            "transactionIndex": "0x3",
            "logIndex": "0x3",
            "removed": false
        },
        {
            "address": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
            "topics": [
                "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
                "0x000000000000000000000000d4dc229a997a73e86c13e3ce8019be02cd4827a6",
                "0x0000000000000000000000009e7243b98a8a9713cb9dc37fe9f18879f0e64dcb"
            ],
            "data": "0x0000000000000000000000000000000000000000000000000000000000d7057c",
            "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
            "blockNumber": "0x2ddffa0",
            "blockTimestamp": "0x6a465c23",
            "transactionHash": "0x0f9c2aee37cff0d3cc5564c685923f6d19ec5c7c6a0d7234ee6fe06655950a2b",
            "transactionIndex": "0xb",
            "logIndex": "0x7",
            "removed": false
        },
        {
            "address": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
            "topics": [
                "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
                "0x00000000000000000000000040378d78b14f46c35e2f69590b733e5275ac1d3b",
                "0x000000000000000000000000fb08f1c035c05d5c12e12657baee1d1d951c2c6c"
            ],
            "data": "0x0000000000000000000000000000000000000000000000000000000005f5e100",
            "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
            "blockNumber": "0x2ddffa0",
            "blockTimestamp": "0x6a465c23",
            "transactionHash": "0xc93d2aca48444c29d5538c2a79fe8bc13047f4efa656e0cc6877db0de8ea553c",
            "transactionIndex": "0xd",
            "logIndex": "0xb",
            "removed": false
        },
    ],
    "id": "getblock.io"
}
```

{% endcode %}

## Response Parameters

| Parameter        | Type    | Description                                |
| ---------------- | ------- | ------------------------------------------ |
| address          | string  | Contract address that emitted the log      |
| topics           | array   | Indexed event parameters (up to 4)         |
| data             | string  | Non-indexed event data (hex)               |
| blockNumber      | string  | Block number in hex                        |
| transactionHash  | string  | Transaction hash                           |
| transactionIndex | string  | Transaction index in block (hex)           |
| blockHash        | string  | Block hash                                 |
| logIndex         | string  | Log index in block (hex)                   |
| removed          | boolean | True if log was removed due to chain reorg |

## Use Cases

* Token Transfer Tracking: Monitor ERC-20/ERC-721 transfers
* DEX Event Processing: Track swaps, liquidity events
* Contract Event Indexing: Build event-driven databases
* Real-time Notifications: Alert on specific events
* Historical Analysis: Analyze past contract activity

## Error Handling

| Error Code | Message                        | Description                           |
| ---------- | ------------------------------ | ------------------------------------- |
| -32602     | Invalid params                 | Invalid filter object                 |
| -32603     | Internal error                 | Query range too large or node failure |
| -32005     | Query returned more than limit | Too many logs in response             |

## SDK Integration

{% tabs %}
{% tab title="Ethers.js" %}

```javascript
const { ethers } = require('ethers');

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

async function getLogs() {
    // Using filter
    const filter = {
        address: '0x4200000000000000000000000000000000000006', // WETH
        topics: [
            ethers.id('Transfer(address,address,uint256)')
        ],
        fromBlock: 'pending',
        toBlock: 'latest'
    };
    
    const logs = await provider.getLogs(filter);
    
    logs.forEach(log => {
        console.log('Block:', log.blockNumber);
        console.log('Tx:', log.transactionHash);
        console.log('Data:', log.data);
    });
    
    return logs;
}

// Using Contract interface for parsed events
async function getTransferEvents() {
    const abi = ['event Transfer(address indexed from, address indexed to, uint256 value)'];
    const contract = new ethers.Contract(
        '0x4200000000000000000000000000000000000006',
        abi,
        provider
    );
    
    const filter = contract.filters.Transfer();
    const events = await contract.queryFilter(filter, -100, 'latest');
    
    events.forEach(event => {
        console.log('From:', event.args.from);
        console.log('To:', event.args.to);
        console.log('Value:', ethers.formatEther(event.args.value));
    });
    
    return events;
}

getLogs();
```

{% endtab %}

{% tab title="Viem" %}
{% code overflow="wrap" %}

```javascript
import { createPublicClient, http, parseAbiItem } from 'viem';
import { base } from 'viem/chains';

const client = createPublicClient({
    chain: base,
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

async function getLogs() {
    const logs = await client.getLogs({
        address: '0x4200000000000000000000000000000000000006',
        event: parseAbiItem('event Transfer(address indexed from, address indexed to, uint256 value)'),
        fromBlock: 'pending',
        toBlock: 'latest'
    });
    
    logs.forEach(log => {
        console.log('From:', log.args.from);
        console.log('To:', log.args.to);
        console.log('Value:', log.args.value);
    });
    
    return logs;
}

// Watch for new logs
async function watchLogs() {
    const unwatch = client.watchEvent({
        address: '0x4200000000000000000000000000000000000006',
        event: parseAbiItem('event Transfer(address indexed from, address indexed to, uint256 value)'),
        onLogs: logs => {
            logs.forEach(log => {
                console.log('New Transfer:', log.args);
            });
        }
    });
    
    return unwatch;
}

getLogs();
```

{% endcode %}
{% endtab %}
{% endtabs %}


# eth\_getCode - Flashblocks

Example code for the eth\_getCode JSON-RPC method. Complete guide on how to use eth\_getCode JSON-RPC in GetBlock Web3 documentation.

The `eth_getCode` method returns the bytecode at a given address. This is used to determine if an address is a smart contract and to retrieve the deployed contract code. When the block reference is `"pending"`, Flashblocks detect contract deployments before the block seals.

## Parameters

| Parameter      | Type   | Required | Description                         |
| -------------- | ------ | -------- | ----------------------------------- |
| address        | string | Yes      | 20-byte address to check            |
| blockParameter | string | Yes      | Block number in hex, or "`pending`" |

## Request

{% tabs %}
{% tab title="cURL" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "eth_getCode",
    "params": [
    "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "pending",
    ]
    "id": "getblock.io"
}'
```

{% endtab %}

{% tab title="Axios (JavaScript)" %}

```javascript
const axios = require('axios');

const response = await axios.post('https://go.getblock.io/<ACCESS-TOKEN>/', {
    jsonrpc: '2.0',
    method: 'eth_getCode',
    params: [
    '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913',
    'pending'],
    id: 'getblock.io'
}, {
    headers: { 'Content-Type': 'application/json' }
});

const code = response.data.result;
const isContract = code !== '0x';
console.log('Is Contract:', isContract);
console.log('Code Length:', (code.length - 2) / 2, 'bytes');
```

{% endtab %}

{% tab title="Requests (Python)" %}

```python
import requests

response = requests.post(
    'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers={'Content-Type': 'application/json'},
    json={
        'jsonrpc': '2.0',
        'method': 'eth_getCode',
        'params': [
    '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913',
    'pending'],
        'id': 'getblock.io'
    }
)

result = response.json()
code = result['result']
is_contract = code != '0x'
print(f'Is Contract: {is_contract}')
print(f'Code Length: {(len(code) - 2) // 2} bytes')
```

{% endtab %}

{% tab title="Rust" %}

```rust
use reqwest::Client;
use serde_json::{json, Value};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();
    
    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&json!({
            "jsonrpc": "2.0",
            "method": "eth_getCode",
            "params": [
    "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "pending"],
            "id": "getblock.io"
        }))
        .send()
        .await?
        .json::<Value>()
        .await?;
    
    let code = response["result"].as_str().unwrap();
    let is_contract = code != "0x";
    println!("Is Contract: {}", is_contract);
    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0x608060405234801561001057600080fd5b50..."
}
```

## Response Parameters

| Parameter | Type   | Description                                          |
| --------- | ------ | ---------------------------------------------------- |
| jsonrpc   | string | JSON-RPC protocol version ("2.0")                    |
| id        | string | Request identifier matching the request              |
| result    | string | Bytecode at the address (hex). Returns "0x" for EOAs |

## Use Cases

* Contract Detection: Verify if address is a smart contract
* Security Analysis: Examine contract bytecode for vulnerabilities
* Contract Verification: Compare deployed code with source
* Proxy Detection: Identify proxy patterns in bytecode
* Contract Indexing: Catalog deployed contracts

## Error Handling

| Error Code | Message        | Description            |
| ---------- | -------------- | ---------------------- |
| -32602     | Invalid params | Invalid address format |
| -32603     | Internal error | Node internal failure  |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}
{% code overflow="wrap" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

// Generic JSON-RPC call — 'pending' returns Flashblocks-preconfirmed state:
const result = await provider.send('eth_code', [
    "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "pending"]);
console.log(result);
```

{% endcode %}
{% endtab %}

{% tab title="viem" %}
{% code overflow="wrap" %}

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

// viem's read methods accept blockTag: 'pending' for Flashblocks-preconfirmed state:
const result = await client.request({
    method: 'eth_code',
    params: [
    "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "pending"]
});
console.log(result);

// Typed wrappers also accept blockTag: 'pending':
// client.getBlock({ blockTag: 'pending' })
```

{% endcode %}
{% endtab %}
{% endtabs %}


# newFlashblocks - Flashblocks

Example code for the newFlashblocks Flashblocks method. Complete guide on how to use newFlashblocks Flashblocks in GetBlock Web3 documentation.

This subscribes to the full Flashblocks payload stream as each preconfirmed sub-block is built. Each notification delivers a Flashblocks Object containing `payload_id`, `index` (0-9 on Base, 0-7 on Optimism), `diff` (the delta since the previous Flashblocks), and — on the first Flashblocks of a new block (`index: 0`) — a `base` field with the block's initial state. This is the lowest-latency Flashblocks subscription and the canonical way to build sub-block indexers.

{% hint style="warning" %}
**WebSocket-only method.** This method requires the WebSocket transport at `wss://go.getblock.io/<ACCESS-TOKEN>/`. It will not work via HTTP POST. Preconfirmed events arrive at the Flashblocks cadence — approximately every 200ms on Base, 250ms on Optimism.
{% endhint %}

## Parameters

| Parameter        | Type   | Required | Description                |
| ---------------- | ------ | -------- | -------------------------- |
| subscriptionType | string | Yes      | Must be `"newFlashblocks"` |

## Request Example

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
# WebSocket-only. Use wscat (or similar) to connect first:
wscat -c 'wss://go.getblock.io/<ACCESS-TOKEN>/'

# Then send:
{"jsonrpc": "2.0", "method": "eth_subscribe", "params": ["newFlashblocks"], "id": "getblock.io"}
```

{% endcode %}
{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import WebSocket from 'ws';

const ws = new WebSocket('wss://go.getblock.io/<ACCESS-TOKEN>/');

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

ws.on('message', (data) => {
    const msg = JSON.parse(data.toString());
    if (msg.method === 'eth_subscription') {
        // Preconfirmed data update
        console.log(msg.params.result);
    } else {
        // Subscription ID response
        console.log('Subscribed:', msg.result);
    }
});
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import asyncio
import json
import websockets

async def main():
    async with websockets.connect('wss://go.getblock.io/<ACCESS-TOKEN>/') as ws:
        await ws.send(json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_subscribe",
    "params": [
        "newFlashblocks"
    ],
    "id": "getblock.io"
}))
        async for message in ws:
            msg = json.loads(message)
            if msg.get('method') == 'eth_subscription':
                # Preconfirmed data update
                print(msg['params']['result'])
            else:
                # Subscription ID response
                print('Subscribed:', msg.get('result'))

asyncio.run(main())
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use tokio_tungstenite::connect_async;
use tokio_tungstenite::tungstenite::Message;
use serde_json::json;
use futures_util::{SinkExt, StreamExt};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let (mut ws_stream, _) = connect_async("wss://go.getblock.io/<ACCESS-TOKEN>/").await?;

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_subscribe",
        "params": [
                "newFlashblocks"
        ],
        "id": "getblock.io"
});
    ws_stream.send(Message::Text(payload.to_string())).await?;

    while let Some(msg) = ws_stream.next().await {
        println!("{:?}", msg?);
    }
    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0x3b8cd9e5f4a7b2c1d0e3f4a5b6c7d8e9"
}
```

{% endcode %}

## Response Parameters

| Field  | Type   | Description                                                                                                                                                                   |
| ------ | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| result | string | Hex-encoded subscription ID. Each subsequent `eth_subscription` notification carries a Flashblocks Object payload with `payload_id`, `index`, `diff`, and (on index 0) `base` |

## Use Cases

* Sub-block indexers — the primary streaming source for Flashblocks-native data
* Real-time analytics dashboards showing block construction in progress
* Trading infrastructure that needs the earliest possible view of sequencer-ordered transactions
* MEV monitoring — observing preconfirmed transactions as they land

## Error Handling

| Status Code | Error Message     | Cause                                                         |
| ----------- | ----------------- | ------------------------------------------------------------- |
| 403         | Forbidden         | Missing or invalid `<ACCESS-TOKEN>`                           |
| -32602      | Invalid params    | Request parameters are missing or malformed                   |
| -32603      | Internal error    | Server-side error while processing the request                |
| 429         | Too Many Requests | Rate limit exceeded for your plan                             |
| -32600      | Invalid Request   | `newFlashblocks` subscription called over HTTP; use WebSocket |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.WebSocketProvider('wss://go.getblock.io/<ACCESS-TOKEN>/');

// Flashblocks subscription types aren't first-class in ethers — use the raw send interface:
const subscriptionId = await provider.send('eth_subscribe', ["newFlashblocks"]);
console.log('Subscribed:', subscriptionId);

// Listen for incoming events on the WebSocket transport
provider.websocket.addEventListener('message', (event) => {
    const msg = JSON.parse(event.data);
    if (msg.method === 'eth_subscription' && msg.params?.subscription === subscriptionId) {
        console.log('Flashblocks update:', msg.params.result);
    }
});
```

{% endtab %}

{% tab title="viem" %}

```javascript
import { createPublicClient, webSocket } from 'viem';

const client = createPublicClient({
    transport: webSocket('wss://go.getblock.io/<ACCESS-TOKEN>/')
});

// Flashblocks subscription types use the raw request interface:
const subscriptionId = await client.request({
    method: 'eth_subscribe',
    params: ["newFlashblocks"]
});
console.log('Subscribed:', subscriptionId);
```

{% endtab %}
{% endtabs %}


# pendingLogs - Flashblocks

Example code for the pendingLogs Flashblocks method. Complete guide on how to use pendingLogs  Flashblocks in GetBlock Web3 documentation.

This Subscribes to contract event logs emitted by preconfirmed transactions — sub-block latency for on-chain events. Filter by contract address (single or array) and event topics (same format as `eth_getLogs`).&#x20;

This is the fastest way to react to on-chain events, up to \~1.8 seconds ahead of the standard `logs` subscription.

{% hint style="warning" %}
**WebSocket-only method.** This method requires the WebSocket transport at `wss://go.getblock.io/<ACCESS-TOKEN>/`. It will not work via HTTP POST. Preconfirmed events arrive at the Flashblocks cadence — approximately every 200ms on Base, 250ms on Optimism.
{% endhint %}

## Parameters

| Parameter        | Type   | Required | Description                                                                                 |
| ---------------- | ------ | -------- | ------------------------------------------------------------------------------------------- |
| subscriptionType | string | Yes      | Must be `"pendingLogs"`                                                                     |
| filter           | object | No       | Filter object: `address` (single address or array), `topics` (same format as `eth_getLogs`) |

## Request Example

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
# WebSocket-only. Use wscat (or similar) to connect first:
wscat -c 'wss://go.getblock.io/<ACCESS-TOKEN>/'

# Then send:
{"jsonrpc": "2.0", "method": "eth_subscribe", "params": ["pendingLogs", {"address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]}], "id": "getblock.io"}
```

{% endcode %}
{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import WebSocket from 'ws';

const ws = new WebSocket('wss://go.getblock.io/<ACCESS-TOKEN>/');

ws.on('open', () => {
    ws.send(JSON.stringify({
    "jsonrpc": "2.0",
    "method": "eth_subscribe",
    "params": [
        "pendingLogs",
        {
            "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
            "topics": [
                "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
            ]
        }
    ],
    "id": "getblock.io"
}));
});

ws.on('message', (data) => {
    const msg = JSON.parse(data.toString());
    if (msg.method === 'eth_subscription') {
        // Preconfirmed data update
        console.log(msg.params.result);
    } else {
        // Subscription ID response
        console.log('Subscribed:', msg.result);
    }
});
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import asyncio
import json
import websockets

async def main():
    async with websockets.connect('wss://go.getblock.io/<ACCESS-TOKEN>/') as ws:
        await ws.send(json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_subscribe",
    "params": [
        "pendingLogs",
        {
            "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
            "topics": [
                "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
            ]
        }
    ],
    "id": "getblock.io"
}))
        async for message in ws:
            msg = json.loads(message)
            if msg.get('method') == 'eth_subscription':
                # Preconfirmed data update
                print(msg['params']['result'])
            else:
                # Subscription ID response
                print('Subscribed:', msg.get('result'))

asyncio.run(main())
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use tokio_tungstenite::connect_async;
use tokio_tungstenite::tungstenite::Message;
use serde_json::json;
use futures_util::{SinkExt, StreamExt};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let (mut ws_stream, _) = connect_async("wss://go.getblock.io/<ACCESS-TOKEN>/").await?;

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_subscribe",
        "params": [
                "pendingLogs",
                {
                        "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
                        "topics": [
                                "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
                        ]
                }
        ],
        "id": "getblock.io"
});
    ws_stream.send(Message::Text(payload.to_string())).await?;

    while let Some(msg) = ws_stream.next().await {
        println!("{:?}", msg?);
    }
    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0x7e2ef8b9c0d1e2f3a4b5c6d7e8f9a0b1"
}
```

{% endcode %}

## Response Parameters

| Field  | Type   | Description                                                                                                                         |
| ------ | ------ | ----------------------------------------------------------------------------------------------------------------------------------- |
| result | string | Hex-encoded subscription ID. Each subsequent notification carries a Log object matching the filter, from a preconfirmed transaction |

## Use Cases

* Real-time event indexers — the lowest-latency way to react to on-chain events
* Trading bots watching for specific ERC-20 transfers, DEX swaps, or oracle updates
* Liquidation bots watching for Aave/Compound account state changes
* Social/gaming applications reacting to on-chain events with instant UX feedback

## Error Handling

| Status Code | Error Message     | Cause                                                         |
| ----------- | ----------------- | ------------------------------------------------------------- |
| 403         | Forbidden         | Missing or invalid `<ACCESS-TOKEN>`                           |
| -32602      | Invalid params    | Request parameters are missing or malformed                   |
| -32603      | Internal error    | Server-side error while processing the request                |
| 429         | Too Many Requests | Rate limit exceeded for your plan                             |
| -32600      | Invalid Request   | Subscription called over HTTP; use WebSocket                  |
| -32602      | Invalid filter    | Filter object malformed — check `address` and `topics` format |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}
{% code overflow="wrap" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.WebSocketProvider('wss://go.getblock.io/<ACCESS-TOKEN>/');

// Flashblocks subscription types aren't first-class in ethers — use the raw send interface:
const subscriptionId = await provider.send('eth_subscribe', ["pendingLogs", {"address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]}]);
console.log('Subscribed:', subscriptionId);

// Listen for incoming events on the WebSocket transport
provider.websocket.addEventListener('message', (event) => {
    const msg = JSON.parse(event.data);
    if (msg.method === 'eth_subscription' && msg.params?.subscription === subscriptionId) {
        console.log('Flashblocks update:', msg.params.result);
    }
});
```

{% endcode %}
{% endtab %}

{% tab title="viem" %}
{% code overflow="wrap" %}

```javascript
import { createPublicClient, webSocket } from 'viem';

const client = createPublicClient({
    transport: webSocket('wss://go.getblock.io/<ACCESS-TOKEN>/')
});

// Flashblocks subscription types use the raw request interface:
const subscriptionId = await client.request({
    method: 'eth_subscribe',
    params: ["pendingLogs", {"address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]}]
});
console.log('Subscribed:', subscriptionId);
```

{% endcode %}
{% endtab %}
{% endtabs %}


# newFlashblockTransactions - Flashblocks

Example code for the newFlashblockTransactions Flashblocks method. Complete guide on how to use newFlashblockTransactions Flashblocks in GetBlock Web3 documentation.

This subscribes to individual preconfirmed transactions as they land in Flashblocks. Each notification carries one transaction. Pass `true` as a second parameter to include full transaction objects with associated logs; omit or pass `false` to receive only transaction hashes. Lighter-weight than `newFlashblocks` when you only care about the transaction stream and not the full block state.

{% hint style="warning" %}
**WebSocket-only method.** This method requires the WebSocket transport at `wss://go.getblock.io/<ACCESS-TOKEN>/`. It will not work via HTTP POST. Preconfirmed events arrive at the Flashblock cadence — approximately every 200ms on Base, 250ms on Optimism.
{% endhint %}

## Parameters

| Parameter          | Type    | Required | Description                                                                             |
| ------------------ | ------- | -------- | --------------------------------------------------------------------------------------- |
| subscriptionType   | string  | Yes      | Must be `"newFlashblockTransactions"`                                                   |
| includeFullObjects | boolean | No       | `true` to receive full transaction objects with logs; `false` (default) for hashes only |

## Request Example

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
# WebSocket-only. Use wscat (or similar) to connect first:
wscat -c 'wss://go.getblock.io/<ACCESS-TOKEN>/'

# Then send:
{"jsonrpc": "2.0", "method": "eth_subscribe", "params": ["newFlashblockTransactions", true], "id": "getblock.io"}
```

{% endcode %}
{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import WebSocket from 'ws';

const ws = new WebSocket('wss://go.getblock.io/<ACCESS-TOKEN>/');

ws.on('open', () => {
    ws.send(JSON.stringify({
    "jsonrpc": "2.0",
    "method": "eth_subscribe",
    "params": [
        "newFlashblockTransactions",
        true
    ],
    "id": "getblock.io"
}));
});

ws.on('message', (data) => {
    const msg = JSON.parse(data.toString());
    if (msg.method === 'eth_subscription') {
        // Preconfirmed data update
        console.log(msg.params.result);
    } else {
        // Subscription ID response
        console.log('Subscribed:', msg.result);
    }
});
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import asyncio
import json
import websockets

async def main():
    async with websockets.connect('wss://go.getblock.io/<ACCESS-TOKEN>/') as ws:
        await ws.send(json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_subscribe",
    "params": [
        "newFlashblockTransactions",
        true
    ],
    "id": "getblock.io"
}))
        async for message in ws:
            msg = json.loads(message)
            if msg.get('method') == 'eth_subscription':
                # Preconfirmed data update
                print(msg['params']['result'])
            else:
                # Subscription ID response
                print('Subscribed:', msg.get('result'))

asyncio.run(main())
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use tokio_tungstenite::connect_async;
use tokio_tungstenite::tungstenite::Message;
use serde_json::json;
use futures_util::{SinkExt, StreamExt};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let (mut ws_stream, _) = connect_async("wss://go.getblock.io/<ACCESS-TOKEN>/").await?;

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_subscribe",
        "params": [
                "newFlashblockTransactions",
                true
        ],
        "id": "getblock.io"
});
    ws_stream.send(Message::Text(payload.to_string())).await?;

    while let Some(msg) = ws_stream.next().await {
        println!("{:?}", msg?);
    }
    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": "0x5c1de6a7b8c9d0e1f2a3b4c5d6e7f8a9"
}
```

{% endcode %}

## Response Parameters

| Field  | Type   | Description                                                                                                                                                 |
| ------ | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| result | string | Hex-encoded subscription ID. Each subsequent notification carries either a transaction hash (default) or a full transaction object with logs (`true` param) |

## Use Cases

* Wallet infrastructure watching for a specific user's transactions to preconfirm
* Transaction-level analytics without the overhead of full block payloads
* Building activity feeds for accounts with sub-second latency
* Front-running detection at the sub-block level

## Error Handling

| Status Code | Error Message     | Cause                                          |
| ----------- | ----------------- | ---------------------------------------------- |
| 403         | Forbidden         | Missing or invalid `<ACCESS-TOKEN>`            |
| -32602      | Invalid params    | Request parameters are missing or malformed    |
| -32603      | Internal error    | Server-side error while processing the request |
| 429         | Too Many Requests | Rate limit exceeded for your plan              |
| -32600      | Invalid Request   | Subscription called over HTTP; use WebSocket   |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}
{% code overflow="wrap" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.WebSocketProvider('wss://go.getblock.io/<ACCESS-TOKEN>/');

// Flashblocks subscription types aren't first-class in ethers — use the raw send interface:
const subscriptionId = await provider.send('eth_subscribe', ["newFlashblockTransactions", true]);
console.log('Subscribed:', subscriptionId);

// Listen for incoming events on the WebSocket transport
provider.websocket.addEventListener('message', (event) => {
    const msg = JSON.parse(event.data);
    if (msg.method === 'eth_subscription' && msg.params?.subscription === subscriptionId) {
        console.log('Flashblocks update:', msg.params.result);
    }
});
```

{% endcode %}
{% endtab %}

{% tab title="viem" %}

```javascript
import { createPublicClient, webSocket } from 'viem';

const client = createPublicClient({
    transport: webSocket('wss://go.getblock.io/<ACCESS-TOKEN>/')
});

// Flashblocks subscription types use the raw request interface:
const subscriptionId = await client.request({
    method: 'eth_subscribe',
    params: ["newFlashblockTransactions", true]
});
console.log('Subscribed:', subscriptionId);
```

{% endtab %}
{% endtabs %}


# eth\_unsubscribe - Flashblocks

Example code for the eth\_unsubscribe Flashblocks method. Complete guide on how to use eth\_unsubscribe Flashblocks in GetBlock Web3 documentation.

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

| Parameter      | Type   | Required | Description                                      |
| -------------- | ------ | -------- | ------------------------------------------------ |
| subscriptionId | string | Yes      | The subscription ID returned by `eth_subscribe`. |

## Request Example

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
# WebSocket-only method. Use wscat (or similar) to connect first:
wscat -c 'wss://go.getblock.io/<ACCESS-TOKEN>/'

# Then send:
{"jsonrpc": "2.0", "method": "eth_unsubscribe", "params": ["0x9cef478923ff08bf67fde6c64013158d"], "id": "getblock.io"}
```

{% endcode %}
{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import WebSocket from 'ws';

const ws = new WebSocket('wss://go.getblock.io/<ACCESS-TOKEN>/');

ws.on('open', () => {
    ws.send(JSON.stringify({
    "jsonrpc": "2.0",
    "method": "eth_unsubscribe",
    "params": [
        "0x9cef478923ff08bf67fde6c64013158d"
    ],
    "id": "getblock.io"
}));
});

ws.on('message', (data) => {
    console.log(JSON.parse(data.toString()));
});
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import asyncio
import json
import websockets

async def main():
    async with websockets.connect('wss://go.getblock.io/<ACCESS-TOKEN>/') as ws:
        await ws.send(json.dumps({
    "jsonrpc": "2.0",
    "method": "eth_unsubscribe",
    "params": [
        "0x9cef478923ff08bf67fde6c64013158d"
    ],
    "id": "getblock.io"
}))
        async for message in ws:
            print(json.loads(message))

asyncio.run(main())
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use tokio_tungstenite::connect_async;
use tokio_tungstenite::tungstenite::Message;
use serde_json::json;
use futures_util::{SinkExt, StreamExt};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let (mut ws_stream, _) = connect_async("wss://go.getblock.io/<ACCESS-TOKEN>/").await?;

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "eth_unsubscribe",
        "params": [
                "0x9cef478923ff08bf67fde6c64013158d"
        ],
        "id": "getblock.io"
});
    ws_stream.send(Message::Text(payload.to_string())).await?;

    while let Some(msg) = ws_stream.next().await {
        println!("{:?}", msg?);
    }
    Ok(())
}
```

{% endtab %}
{% endtabs %}

### Response

{% code overflow="wrap" %}

```bash
{
    "jsonrpc": "2.0",
    "id": 1,
    "result": true
}
```

{% endcode %}

## Response Parameters

| Field  | Type    | Description                                                                                          |
| ------ | ------- | ---------------------------------------------------------------------------------------------------- |
| result | boolean | `true` if the subscription was successfully cancelled, `false` if the subscription ID was not found. |

## Error Handling

| Status Code | Error Message     | Cause                                          |
| ----------- | ----------------- | ---------------------------------------------- |
| 403         | Forbidden         | Missing or invalid `<ACCESS-TOKEN>`            |
| -32602      | Invalid params    | Request parameters are missing or malformed    |
| -32603      | Internal error    | Server-side error while processing the request |
| 429         | Too Many Requests | Rate limit exceeded for your plan              |
| -32600      | Invalid Request   | Subscription called over HTTP; use WebSocket   |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}
{% code overflow="wrap" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.WebSocketProvider('wss://go.getblock.io/<ACCESS-TOKEN>/');

// Flashblocks subscription types aren't first-class in ethers — use the raw send interface:
const subscriptionId = await provider.send('eth_usubscribe', ["0xf48bfa9af6a7f77897a0f0e59c1061bc"]);
console.log('Subscribed:', subscriptionId);
```

{% endcode %}
{% endtab %}

{% tab title="viem" %}

```javascript
import { createPublicClient, webSocket } from 'viem';

const client = createPublicClient({
    transport: webSocket('wss://go.getblock.io/<ACCESS-TOKEN>/')
});

// Flashblocks subscription types use the raw request interface:
const subscriptionId = await client.request({
   "method": "eth_unsubscribe", 
    "params": ["0xf48bfa9af6a7f77897a0f0e59c1061bc"]
});
console.log('Subscribed:', subscriptionId);
```

{% endtab %}
{% endtabs %}


# base\_transactionStatus - Flashblocks

Example code for the base\_transactionStatus Flashblocks method. Complete guide on how to use base\_transactionStatus Flashblocks in GetBlock Web3 documentation.

This Checks whether a specific transaction is currently present in the node's mempool. This confirms that a submitted transaction has been received by the sequencer *before* it appears in a Flashblocks — closing the gap between submission and first preconfirmation. Base-specific: this method exists on Base's Flashblocks endpoints but has no equivalent on Optimism.

{% hint style="warning" %}
**Base-only method.** This method is exposed by Base's Flashblocks infrastructure but has no equivalent on Optimism. Calling it against an Optimism endpoint will return `-32601 Method not found`.
{% endhint %}

## Parameters

| Parameter       | Type            | Required | Description                           |
| --------------- | --------------- | -------- | ------------------------------------- |
| transactionHash | DATA (32 bytes) | Yes      | The 32-byte transaction hash to query |

## Request Example

{% tabs %}
{% tab title="cURL" %}

```bash
curl --location --request POST 'https://go.getblock.io/<ACCESS-TOKEN>/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "base_transactionStatus",
    "params": [
        "0xa8f9b3c7d2e4f6a1b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6"
    ],
    "id": "getblock.io"
}'
```

{% endtab %}

{% tab title="JavaScript (Axios)" %}

```javascript
import axios from 'axios';

const data = JSON.stringify({
    "jsonrpc": "2.0",
    "method": "base_transactionStatus",
    "params": [
        "0xa8f9b3c7d2e4f6a1b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6"
    ],
    "id": "getblock.io"
});

const config = {
    method: 'post',
    url: 'https://go.getblock.io/<ACCESS-TOKEN>/',
    headers: {
        'Content-Type': 'application/json'
    },
    data: data
};

axios(config)
    .then(response => console.log(JSON.stringify(response.data, null, 2)))
    .catch(error => console.log(error));
```

{% endtab %}

{% tab title="Python (Requests)" %}

```python
import requests
import json

url = "https://go.getblock.io/<ACCESS-TOKEN>/"

payload = json.dumps({
    "jsonrpc": "2.0",
    "method": "base_transactionStatus",
    "params": [
        "0xa8f9b3c7d2e4f6a1b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6"
    ],
    "id": "getblock.io"
})

headers = {
    'Content-Type': 'application/json'
}

response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endtab %}

{% tab title="Rust (Reqwest)" %}

```rust
use reqwest::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();

    let payload = json!({
        "jsonrpc": "2.0",
        "method": "base_transactionStatus",
        "params": [
                "0xa8f9b3c7d2e4f6a1b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6"
        ],
        "id": "getblock.io"
});

    let response = client
        .post("https://go.getblock.io/<ACCESS-TOKEN>/")
        .header("Content-Type", "application/json")
        .json(&payload)
        .send()
        .await?;

    let result: serde_json::Value = response.json().await?;
    println!("{:#?}", result);

    Ok(())
}
```

{% endtab %}
{% endtabs %}

## Response Example

{% code overflow="wrap" %}

```json
{
    "jsonrpc": "2.0",
    "id": "getblock.io",
    "result": {
        "status": "Known"
    }
}
```

{% endcode %}

## Response Parameters

| Field         | Type   | Description                                                                                              |
| ------------- | ------ | -------------------------------------------------------------------------------------------------------- |
| result.status | string | `"Known"` if the transaction is present in the mempool; `"Unknown"` if it has not been seen by this node |

## Use Cases

* Confirming a submitted transaction reached the sequencer before it appears in a Flashblock
* Detecting transactions that were dropped or rejected before entering the mempool
* Debugging submission pipelines — distinguishing 'not submitted' from 'submitted but not yet preconfirmed'

## Error Handling

| Status Code | Error Message     | Cause                                          |
| ----------- | ----------------- | ---------------------------------------------- |
| 403         | Forbidden         | Missing or invalid `<ACCESS-TOKEN>`            |
| -32602      | Invalid params    | Request parameters are missing or malformed    |
| -32603      | Internal error    | Server-side error while processing the request |
| 429         | Too Many Requests | Rate limit exceeded for your plan              |

## SDK Integration

{% tabs %}
{% tab title="ethers.js" %}
{% code overflow="wrap" %}

```javascript
import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');

// Flashblocks-specific methods use the raw send interface:
const result = await provider.send('base_transactionStatus', ["0xa8f9b3c7d2e4f6a1b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6"]);
console.log(result);
```

{% endcode %}
{% endtab %}

{% tab title="viem" %}

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
    transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});

// Flashblocks-specific methods need the raw request transport:
const result = await client.request({
    method: 'base_transactionStatus',
    params: ["0xa8f9b3c7d2e4f6a1b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6"]
});
console.log(result);
```

{% endtab %}
{% endtabs %}


# Overview

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.

{% hint style="info" %}
**Solana Market Data** is designed for applications that need **live and recent trading data** — from trading dashboards and analytics platforms to automated and agentic trading systems.
{% endhint %}

### 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:

| Topic    | Description                                     | Required parameters |
| -------- | ----------------------------------------------- | ------------------- |
| `trades` | Normalized individual trades                    | None                |
| `block`  | Trading activity aggregated for one Solana slot | None                |
| `ohlcv`  | Open, high, low, close, and volume candles      | `window`            |
| `twap`   | Time-weighted average price                     | `window`            |
| `vwap`   | Volume-weighted average price                   | `window`            |
| `volume` | Trading volume and swap activity                | `window`            |
| `token`  | Token metadata                                  | None                |

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

### Why use Solana Market Data?

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;
* AI or automated trading agent.

### How to use it

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.

{% hint style="info" %}
You can also use the **Playground** to explore available methods and see the data before integrating it into your application.
{% endhint %}

### Which Topic Should I Use?

| If you need                                           | Use      |
| ----------------------------------------------------- | -------- |
| Individual trades and maximum calculation flexibility | `trades` |
| Market activity for each Solana slot                  | `block`  |
| Candles or price charts                               | `ohlcv`  |
| A price weighted by elapsed time                      | `twap`   |
| A price weighted by traded volume                     | `vwap`   |
| Buy, sell, and total market activity                  | `volume` |
| Token metadata                                        | `token`  |

### Next steps

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


# Getting Started

This guide walks you through the basic steps required to start using Solana Market Data.

### 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**

Select your preferred payment method in the **side drawer** and complete the purchase.

Once the subscription is active, your API key will be enabled for **Solana Market Data**.

{% hint style="info" %}
Need an API key? You can create one in **Settings → API Keys** in your GetBlock account.
{% endhint %}

### 2. Select a token pair

Solana Market Data returns market information for a specific token pair.

To choose the market you want to track, provide the mint addresses for:

* **Base Mint** — the asset you want to analyze
* **Quote Mint** — the asset used to price it

For example, to receive market data for **SOL/USDC**, select the corresponding **SOL** and **USDC** mint addresses as your base and quote assets.

The selected pair is then used across the available methods, such as **Trades, Blocks, VWAP, TWAP, Volume, and Candles**.

{% hint style="info" %}
You can select the Base Mint and Quote Mint directly in the **Playground** to explore the data for a specific pair before integrating it into your application.
{% endhint %}

### 3. Choose the data you need

**Solana Market Data** provides several levels of processed market information.

Choose the method that best matches your use case:

| Method                | Best for                                  |
| --------------------- | ----------------------------------------- |
| **Trades**            | Individual normalized trades              |
| **Blocks**            | Market activity aggregated by Solana slot |
| **VWAP**              | Volume-weighted market price              |
| **TWAP**              | Time-weighted market price                |
| **Volume**            | Trading activity and traded volume        |
| **Candles**           | OHLCV charts and price visualization      |
| **Buy/Sell Activity** | Comparing buying and selling activity     |

### 4. Select how you want to consume the data

You can access **Solana Market Data** through several protocols.

#### HTTP

Use HTTP when you need a single response or want to retrieve the latest available data.

Typical use cases include:

* getting the current VWAP;
* retrieving recent trades;
* loading data when your application starts.

#### WebSocket

Use WebSocket when you need continuous live updates.

It is suitable for:

* live dashboards;
* trading interfaces;
* continuously updated charts;
* real-time market monitoring.

#### gRPC

Use the gRPC interface for server-side streaming and integrations that already use a Yellowstone-style workflow.

It provides processed Solana market data while allowing you to keep a familiar streaming integration model.

### 5. Configure your request

The parameters depend on the selected method, but most requests start with a few common choices:

* the **base token**;
* the **quote token**;
* the market data method you want to use;
* a **time window** for methods such as VWAP, TWAP, Volume, or Candles.

For example, you can request market data for:

```
SOL / USDC
```

and then choose whether you want Trades, VWAP, Candles, or another available metric.

### Try it in the Playground

The easiest way to explore Solana Market Data before writing code is through the **Playground**.

Use it to:

1. choose a method;
2. select a token pair;
3. configure the available parameters;
4. send a query or start a stream;
5. inspect the returned data.

The Playground uses the same concepts exposed through the API, making it useful for understanding a method before integrating it into your application.

### 6. Integrate it into your application

Once you know which data you need, use the corresponding API method from your application.

A typical integration looks like this:

```
Choose a token pair
        ↓
Choose a market data method
        ↓
Query current/recent data
        ↓
Subscribe to live updates if needed
        ↓
Use the data in your application
```

For exact request parameters, response fields, and streaming behavior, continue to the documentation for the specific **Market Data method** or see the **API Reference**.


# Market data

A **Solana Market Data** subscription describes three things: the market pair to observe, the type of data to receive, and how that data should be delivered. The `base` and `quote` mint addresses identify the pair and its direction. The `topic` selects the resulting data model, such as individual trades, **OHLCV** candles, or an aggregated price. Topics such as `ohlcv`, `twap`, `vwap`, and `volume` also use `window` to define their calculation period.

After accepting a subscription, the service can first send recent rows requested through `hydrate` and then continue streaming live changes. The `throttle` option controls the minimum interval between those updates. It does not change the aggregation window or require the client to wait until that window closes.

The example below subscribes to one-minute **OHLCV** data for the SOL/USDC pair. It requests up to ten initial rows and asks the service to push subsequent changes no more frequently than once per second. Replace the mint addresses, topic, and window to match the market data required by your application.

### Subscribe Request

Subscribe with `getblock_subscribe` and pass one structured request object:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getblock_subscribe",
  "params": [
    {
      "source": "market",
      "topic": "ohlcv",
      "params": {
        "base": "So11111111111111111111111111111111111111112",
        "quote": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
        "window": "1m",
        "hydrate": 10,
        "throttle": "1s"
      }
    }
  ]
}
```

#### Market parameters

| Field     | Type    | Required                | Description                                                                            |
| --------- | ------- | ----------------------- | -------------------------------------------------------------------------------------- |
| `base`    | string  | No                      | Base58-encoded mint address of the base token.                                         |
| `quote`   | string  | No                      | Base58-encoded mint address of the quote token.                                        |
| `mint`    | string  | No                      | Base58-encoded token mint used only by the `token` topic.                              |
| `window`  | string  | Yes for windowed topics | Aggregation period.                                                                    |
| `hydrate` | integer | No                      | Number of initial rows requested when the subscription starts, from `1` through `100`. |

Accepted market windows are:

```
1s, 10s, 30s, 1m, 5m, 30m, 1h, 2h, 4h, 6h, 8h, 12h, 24h
```

`limit`, `from`, and `to` are query-only parameters and are not supported by the streaming API.

#### Optimistic delivery and reconciliation

Solana produces an ordered sequence of slots, but recently observed data can still change before the network reaches finality. Waiting for finalization before publishing every market event would add latency and could make the feed less useful for trading, monitoring, and automated execution.

Market Data therefore uses an optimistic streaming model. Rows are delivered as soon as they are available and can be corrected later through the same subscription. This gives latency-sensitive clients immediate access to new market activity while preserving a deterministic way to reconcile their local state.

The `window` parameter defines the aggregation period, not how long a client must wait for the first result. For example, a subscription with `"window": "10s"` can receive a row before the ten-second window closes. As more trades enter that window, the service sends the latest version of the row in `updates`. The `throttle` parameter controls the minimum interval between pushes and can be used to reduce the update frequency.

If a chain reorganization changes the transactions included in recent slots, affected rows can be corrected in two ways:

* `updates` contains the replacement value for an existing row;
* `deletes` contains a previously emitted row that is no longer valid on the currently observed canonical branch.

<br>

{% hint style="info" %}
\
Every changed row carries its stable `id`. Clients should maintain their local view by upserting rows from `inserts` and `updates`, then removing rows from `deletes` by `id`. A delete carries the row object, not only its identifier, so clients may also inspect or audit the removed value.

```
for (const row of [...(result.inserts ?? []), ...(result.updates ?? [])]) {
  rows.set(row.id, row)
}

for (const row of result.deletes ?? []) {
  rows.delete(row.id)
}
```

{% endhint %}

Applications that require finalized-only data can apply their own confirmation policy before treating optimistic rows as irreversible. Applications that prioritize minimum latency can act immediately, provided they also process later updates and deletes.

| Change set | Description                                                                                                  |
| ---------- | ------------------------------------------------------------------------------------------------------------ |
| `inserts`  | New rows, including the initial snapshot requested with `hydrate`.                                           |
| `updates`  | Full replacement rows for previously emitted IDs whose values changed, including active aggregation windows. |
| `deletes`  | Previously emitted rows that must be removed from the client's local state by `id`.                          |

A change-set property can be omitted when a notification contains no changes of that type. Clients should process all three categories and ignore unknown row fields for forward compatibility. Do not treat an `insert` as final merely because it was delivered first.

The Solana gateway preserves market row objects without renaming their fields. Most numeric and timestamp values are serialized as strings so clients do not lose precision. Boolean fields remain JSON booleans, and `id` can be a JSON number.

### Trades

The `trades` topic streams normalized individual trades for the selected pair. Use it when an application needs transaction-level activity or must calculate its own prices, indicators, and aggregations.

#### Response fields

| Field            | Description                                            |
| ---------------- | ------------------------------------------------------ |
| `id`             | Row identifier.                                        |
| `signature`      | Solana transaction signature.                          |
| `signer`         | Wallet that signed the transaction.                    |
| `slot`           | Solana slot in which the trade was observed.           |
| `timestamp`      | Trade timestamp in ISO 8601 format.                    |
| `base`           | Mint address of the base token.                        |
| `quote`          | Mint address of the quote token.                       |
| `base_amount`    | Base-token amount in the token's smallest units.       |
| `quote_amount`   | Quote-token amount in the token's smallest units.      |
| `base_decimals`  | Decimal precision of the base token.                   |
| `quote_decimals` | Decimal precision of the quote token.                  |
| `base_volume`    | Human-readable amount of the base token exchanged.     |
| `quote_volume`   | Human-readable amount of the quote token exchanged.    |
| `price`          | Trade price expressed in the quote token.              |
| `is_buy`         | `true` when the observed trade is classified as a buy. |

### Block

The `block` topic aggregates observed trading activity for the selected pair within one Solana slot. It provides a compact view of short-term activity without requiring clients to process every trade.

#### Response fields

| Field          | Description                                                 |
| -------------- | ----------------------------------------------------------- |
| `id`           | Row identifier.                                             |
| `slot`         | Solana slot covered by the aggregate.                       |
| `timestamp`    | Timestamp of the latest activity included in the aggregate. |
| `base`         | Mint address of the base token.                             |
| `quote`        | Mint address of the quote token.                            |
| `vwap`         | Volume-weighted average price for the slot.                 |
| `min`          | Lowest observed price in the slot.                          |
| `max`          | Highest observed price in the slot.                         |
| `base_volume`  | Total volume denominated in the base token.                 |
| `quote_volume` | Total volume denominated in the quote token.                |
| `total_volume` | Total trading volume for the slot.                          |
| `buy_volume`   | Volume attributed to buy swaps.                             |
| `sell_volume`  | Volume attributed to sell swaps.                            |
| `num_swaps`    | Total number of observed swaps.                             |
| `buy_swaps`    | Number of buy swaps.                                        |
| `sell_swaps`   | Number of sell swaps.                                       |

### OHLCV

The `ohlcv` topic provides ready-to-use candles for charts, token pages, dashboards, alerts, and other time-based market visualizations.

#### Response fields

| Field             | Description                                       |
| ----------------- | ------------------------------------------------- |
| `id`              | Candle identifier.                                |
| `base`            | Mint address of the base token.                   |
| `quote`           | Mint address of the quote token.                  |
| `timestamp`       | Timestamp associated with the latest candle data. |
| `window_duration` | Aggregation period used to build the candle.      |
| `open`            | First observed price in the window.               |
| `high`            | Highest observed price in the window.             |
| `low`             | Lowest observed price in the window.              |
| `close`           | Latest observed price in the window.              |
| `base_volume`     | Trading volume denominated in the base token.     |
| `quote_volume`    | Trading volume denominated in the quote token.    |
| `volume_usd`      | Trading volume expressed in USD.                  |
| `data_points`     | Number of observations included in the candle.    |
| `window_start`    | Start of the aggregation window.                  |
| `window_end`      | End of the aggregation window.                    |

### TWAP

The `twap` topic provides the time-weighted average price over the selected window. It gives equal weight to each period of time and is useful for smoother price monitoring and time-based execution benchmarks.

#### Response fields

| Field             | Description                                               |
| ----------------- | --------------------------------------------------------- |
| `id`              | Row identifier.                                           |
| `base`            | Mint address of the base token.                           |
| `quote`           | Mint address of the quote token.                          |
| `timestamp`       | Timestamp of the latest data included in the calculation. |
| `slot`            | Latest Solana slot included in the calculation.           |
| `window_duration` | Aggregation period used for the calculation.              |
| `twap`            | Time-weighted average price in the quote token.           |
| `twap_usd`        | Time-weighted average price expressed in USD.             |
| `current_price`   | Latest observed price for comparison with the average.    |
| `data_points`     | Number of observations included in the calculation.       |
| `window_start`    | Start of the calculation window.                          |
| `window_end`      | End of the calculation window.                            |

### VWAP

The `vwap` topic provides the volume-weighted average price over the selected window. Trades with more volume have more influence on the result, making VWAP useful for execution benchmarks and liquidity-aware market monitoring.

#### Response fields

| Field             | Description                                               |
| ----------------- | --------------------------------------------------------- |
| `id`              | Row identifier.                                           |
| `base`            | Mint address of the base token.                           |
| `quote`           | Mint address of the quote token.                          |
| `timestamp`       | Timestamp of the latest data included in the calculation. |
| `slot`            | Latest Solana slot included in the calculation.           |
| `window_duration` | Aggregation period used for the calculation.              |
| `vwap`            | Volume-weighted average price in the quote token.         |
| `vwap_usd`        | Volume-weighted average price expressed in USD.           |
| `total_volume`    | Volume included in the calculation.                       |
| `data_points`     | Number of observations included in the calculation.       |
| `window_start`    | Start of the calculation window.                          |
| `window_end`      | End of the calculation window.                            |

### Volume

The `volume` topic summarizes trading activity for the selected pair and window. Use it to monitor market participation, detect changes in activity, or build volume-based indicators.

#### Response fields

| Field             | Description                                                 |
| ----------------- | ----------------------------------------------------------- |
| `id`              | Row identifier.                                             |
| `base`            | Mint address of the base token.                             |
| `quote`           | Mint address of the quote token.                            |
| `timestamp`       | Timestamp of the latest activity included in the aggregate. |
| `window_duration` | Aggregation period used for the calculation.                |
| `base_volume`     | Total volume denominated in the base token.                 |
| `quote_volume`    | Total volume denominated in the quote token.                |
| `buy_volume`      | Volume attributed to buy swaps.                             |
| `sell_volume`     | Volume attributed to sell swaps.                            |
| `total_volume`    | Total trading volume in the window.                         |
| `total_swaps`     | Total number of swaps in the window.                        |
| `window_start`    | Start of the aggregation window.                            |
| `window_end`      | End of the aggregation window.                              |

#### Buy and sell pressure

Buy/sell pressure is not a separate public topic in the current API. Derive it from `buy_volume` and `sell_volume` returned by `volume`, or use the equivalent fields from `block` for slot-level analysis. For example:

```
pressure = (buy_volume - sell_volume) / (buy_volume + sell_volume)
```

Applications must handle a zero total volume before calculating the ratio.

### Token

The `token` topic streams metadata for a token selected with the `mint` parameter. It does not use `base`, `quote`, or `window`.

#### Response fields

| Field      | Description                     |
| ---------- | ------------------------------- |
| `id`       | Row identifier.                 |
| `mint`     | Token mint address.             |
| `name`     | Token name.                     |
| `symbol`   | Token ticker symbol.            |
| `decimals` | Decimal precision of the token. |
| `supply`   | Current token supply.           |


# Priority fee

Docs will be here soon!


# StreamFirst

An infrastructure for delivering the fastest on-chain updates by combining software-level acceleration (Fast Yellowstone) with optimized network traffic and routing (via shred-stream).

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

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***](https://getblock.io/contact) ***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

### How It Works

#### Accelerated Yellowstone gRPC

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

#### Shred-Stream Network Optimization

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.&#x20;
* **Early state reconstruction:** Rebuilds block data before it's fully confirmed and distributed via standard RPC

#### Frankfurt Data Center - Europe's Solana Hub

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

![](/files/dumPwd6r76oKKrkaJLdq)

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

### Technical Architecture

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
4. Client Delivery: Structured blockchain data streams to your application via standard gRPC

### Why StreamFirst is Important for Developers

#### Speed Advantages

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

{% hint style="success" %}
**Typical latency improvements:** 25-30ms faster than standard Yellowstone gRPC&#x20;
{% endhint %}

#### Use Cases

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
* NFT sniping tools: Detect new listings and mints before they propagate widely
* Analytics platforms: Collect comprehensive on-chain data with minimal delay
* Wallet applications: Show users' balance and transaction updates in real-time

#### Data Types Available

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
* Block data: Full block information, including all transactions and metadata
* Program logs: Subscribe to specific program execution logs

### Deployment and Availability

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

### Conclusion

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 [GetBlock support team](https://getblock.io/contact/)

<br>


# LandFirst

An infrastructure for fast transaction delivery in Solana through its own intelligent routing mechanism.

LandFirst is GetBlock's intelligent transaction-routing technology for processing faster transactions on Solana. It works by routing your transactions through multiple optimized delivery paths, including GetBlock’s Stake-Weighted Quality of Service (SWQoS) connections and the Jito auction mechanism.

***Interested in building on Solana with LandFirst?*** [***Reach us***](https://getblock.io/contact) ***for more information.***

#### Core Technology Stack

LandFirst automatically routes transactions through three complementary delivery mechanisms:

1. **GetBlock's Own SWQoS Connections**
   1. Direct partnerships with high-stakes Solana validators
   2. Guaranteed priority capacity through stake-weighted allocation
   3. GetBlock-operated infrastructure with validator peering
2. **Leased SWQoS Connections**
   1. Higher priority than unstaked RPC traffic, ensuring transactions cut ahead during congestion
   2. Reserve priority bandwidth specifically for LandFirst traffic
3. **Jito Block Engine Integration**
   1. MEV-aware auction mechanism for guaranteed inclusion
   2. Bundle support for atomic multi-transaction operations
   3. Priority placement through competitive tipping

By combining all three paths, LandFirst provides the highest probability of fast transaction inclusion on Solana.

### Technical Architecture

#### How It Works

LandFirst maximizes transaction inclusion by combining SWQoS priority routing, low-latency leader targeting, and parallel Jito submission. When a user sends a transaction, LandFirst checks the current leader schedule and picks the fastest path through our and our partners’ staked SWQoS validators, using private, low-hop connections to deliver the transaction directly to the upcoming leader with priority TPU capacity. At the same time, the transaction is also sent to Jito, where it enters the tip auction for guaranteed execution if the bundle wins. Whichever path lands first becomes the confirmed transaction, ensuring the highest possible probability of fast, next-block inclusion even under heavy network congestion.

{% @mermaid/diagram content="
flowchart TD

A\[Our Transaction] --> B\[LandFirst Intelligent Router]

B --> C\[Path Selection Algorithm]

C --> C1\[Analyze: Priority fee, Jito tip, network conditions]
C --> C2\[Check: Current or upcoming leader schedule]
C --> C3\[Select: Optimal routing path]

C --> D\[Parallel Submission]

D --> D1\[GetBlock SWQoS --> Validator GetBlock partner leader]
D --> D2\[Leased SWQoS --> Validator leased partner leader]
D --> D3\[Jito Bundle --> Jito Block Engine]

D --> E\[Block Leader Receives Transaction]

E --> F\[Transaction Lands in Block]

" %}

#### Routing Intelligence:

LandFirst analyzes each transaction and selects the optimal delivery path based on:

* Leader Schedule: Which validator is currently/soon producing blocks
* Network Conditions: Current congestion and validator responsiveness
* Transaction Priority: Priority fee amount and urgency
* Geographic Location: network topology that defines the lowest-path latency to the current leader.

#### Use Cases

1. **HFT & Arbitrage**

Fast, reliable execution for high-frequency trading, arbitrage, market-making, and position rebalancing — especially when every millisecond counts.

2. **MEV & Keeper / Liquidation Bots**

Ensures deterministic transaction landing for backruns, front-runs, liquidation races, and other MEV or keeper-bot strategies.

3. **NFT Sniping & High-Demand Mints**

Gives an edge for time-sensitive NFT events such as limited-supply mints, snipes, and competitive auctions.

4. **Critical Time-Sensitive Transactions**

For urgent or large-value moves — e.g. multi-sig operations, time-bound transfers, or high-stakes governance — where failure or delay is too costly.

### Different Between Multi-Path Routing Advantage vs. Standard RPC Transaction Submission

Standard RPC nodes submit transactions via single, unstaked TPU connections. During congestion, these transactions are deprioritized or dropped entirely.

| Aspect              | Standard RPC    | LandFirst                  |
| ------------------- | --------------- | -------------------------- |
| Routing paths       | Single path     | Three paths (SWQoS + Jito) |
| Validator priority  | None (unstaked) | High (stake-weighted)      |
| Congestion handling | Fails or delays | Adaptive routing           |
| Bundle support      | No              | Yes (via Jito)             |
| MEV protection      | No              | Yes (via Jito)             |
| Landing probability | 60-90% (varies) | 95%+ (measured)            |

### Available to Everyone

LandFirst is available on:

✅ Shared Node Plans - All shared RPC users benefit automatically\
✅ Dedicated Node Plans - Enhanced monitoring and configuration available\
✅ No Additional Fee - Included in standard RPC access (tips are optional)

***

For consultation on optimal deployment architecture for your specific use case, contact [GetBlock support team](https://getblock.io/contact/)

<br>


# TradeFirst

An infrastructure that combines other GetBlock and external infrastructures, specifically designed for high-frequency traders (HFT) on Solana.

TradeFirst is an infrastructure that combines other GetBlock and external infrastructures, specifically designed for high-frequency traders (HFT) on Solana. It combines multiple performance optimizations:&#x20;

* fast data streaming (StreamFirst)
* intelligent transaction routing (LandFirst)

into a single, integrated solution for professional trading operations.

***Interested in building on Solana with TradeFirst?*** [***Reach us***](https://getblock.io/contact) ***for more information.***

#### Core Value Proposition

TradeFirst provides two-sided latency optimization for Solana trading:

1. Signal Detection Side: Faster awareness of on-chain events via StreamFirst (data streaming).
2. Execution Side: Faster transaction delivery and inclusion via Blazar, SubSlot, and LandFirst routing

By optimizing both sides, TradeFirst enables traders to see opportunities earlier and execute trades faster than competitors using standard infrastructure.

#### Core Technology Stack

1. **StreamFirst (Data Streaming)**
   1. Accelerated Yellowstone gRPC implementation
   2. Optimized shred-stream network access
   3. Fastest on-chain data delivery for signal detection
2. **LandFirst (Multi-Path Routing)**
   1. SWQoS priority connections
3. **Jito integration**&#x20;
   1. Geo routing
   2. Stake density topology
   3. Leadership scheduling

{% hint style="success" %}
Future Addition:

* Shred Stream Access (coming soon): Direct raw shred delivery for even earlier data access
  {% endhint %}

### Technical Architecture

#### How TradeFirst Works

![](/files/7G3PqeyhvypimJenGcxt)

Complete Trading Cycle:

1. Signal Detection: StreamFirst delivers on-chain updates 17ms faster than standard methods
2. Strategy Execution: Your trading logic analyzes data and generates orders
3. Transaction Submission: Blazar optimizes transaction structure and routing
4. Timing Control: SubSlot precisely times submission within the slot window
5. Path Selection: LandFirst routes via optimal path (SWQoS or Jito)
6. Block Inclusion: Transaction lands in the current or next slot with high probability

### Use cases

This is highly recommended for High-frequency trading (HFT) traders, which is specifically designed for:&#x20;

1\. **High-Frequency Trading Firms**

These are professional trading teams running large volumes of rapid-fire transactions on Solana, including cross-DEX arbitrage, statistical arbitrage across correlated token pairs, tight-spread market making, and fast liquidity rebalancing. For them, execution speed and reliability directly impact profitability, making this solution an essential part of their trading infrastructure.

**2. MEV Searchers**

MEV searchers rely on precise timing and high-priority execution for strategies like sandwich attacks, liquidation sniping, protocol arbitrage, or fast NFT flips. Since these opportunities exist for only seconds—and often compete with other searchers—having stronger execution reliability gives them a significant edge.

**3. Algorithmic Trading Operations**

Algorithmic trading systems continuously react to on-chain data, whether they're following momentum signals, trading based on oracle movements, optimizing yield across protocols, or executing automated rebalancing strategies. These systems need a consistent, low-latency execution layer to ensure their models perform as expected without disruptions.

**4. Proprietary Trading Desks**

Small teams and professional traders running their own capital depend on solid infrastructure without wanting to build it in-house. They benefit from flexible setups that support diverse strategies, predictable pricing so they know their cost structure, and reliable support for performance tuning or issue resolution.

**5. Institutional Crypto Traders**

Institutions executing high-volume Solana strategies require enterprise-level stability, compliance-friendly monitoring, volume-based pricing, and service-level guarantees. This solution gives them the dependable infrastructure and dedicated support needed to operate at scale while maintaining regulatory and operational standards.

***

For consultation on optimal deployment architecture for your specific use case, contact [GetBlock support team](https://getblock.io/contact/)

<br>


# Solana Indexed Archive

Solana indexed archive data that allows users to efficiently query any historical information.

Solana Indexed Archive is a software development kit(SDK) that provides an indexed data layer, enabling instant access to the complete Solana blockchain history and real-time data through a single, high-performance API. Built on SQD Network infrastructure, it eliminates the need to work with raw Solana data, run archive nodes, or maintain complex indexing logic.

*Interested in building on Solana with Indexed Archive?* [*Reach us*](https://getblock.io/contact) *for more information.*

### The Indexed Archive Solution

* **Complete historical index:** Every block, transaction, instruction, log, and account update already parsed, normalized, and ready for queries
* **Unified access layer:** Single endpoint for both historical queries and live subscriptions
* **Developer-friendly SDK:** Typed queries, easy integration, no low-level Solana structures\
  Zero operational overhead: GetBlock operates all infrastructure
* &#x20;**Instant availability:** Full Solana history accessible immediately, no setup or backfilling

Using the SDK, you can easily build ETL pipelines that extract and transform on-chain data without handling raw Solana events, decoding account structures, or maintaining complex indexing logic. All blockchain data has already been extracted, indexed, and is immediately ready to use. Your only task is to define the query and specify the required filter.

### Technical Architecture

#### Layer 1: SQD Network - Decentralized Indexing

SQD Network continuously processes Solana's blockstream in a decentralized manner:

* Block processing: Every Solana block parsed immediately upon production
* Data extraction: Transactions, instructions, logs, account updates extracted
* Normalization: Raw data decoded and structured following standard schemas
* Enrichment: Relationships between transactions, accounts, and programs established
* Distributed storage: Indexed data stored across decentralized SQD infrastructure

#### Layer 2: GetBlock Portal - High-Performance Access Layer

GetBlock deploys and maintains a global network of Portal instances—high-performance gateways that:

* Provide unified interface: Single API endpoint for historical data and real-time subscriptions
* Ensure low latency: Geographically distributed clusters for fast global access
* Guarantee high availability: Redundant instances with automatic failover
* Handle scale: Optimized for large workloads and deep historical scans
* Abstract complexity: Clean API hides underlying distributed storage complexity

### What the Indexed Archive Includes

1. Blocks
   1. Block hash, slot number, parent slot
   2. Block time (Unix timestamp)
   3. Leader (validator) identity
   4. Transaction count
   5. Total compute units consumed
2. Transactions
   1. Signature (unique identifier)
   2. Fee payer address
   3. Success/failure status
   4. Error messages (if failed)
   5. Fee paid (lamports)
   6. Compute units used
   7. List of program invocations
3. Instructions
   1. Program ID (which program was called)
   2. Instruction index (order within transaction)
   3. Instruction data (decoded where possible)
   4. Accounts array (all accounts involved)
   5. Nested/inner instructions
4. Logs
   1. Program log messages
   2. Associated transaction signature
   3. Log level and content
   4. Timestamp
5. Account Updates
   1. Account public key
   2. Pre-transaction balance (lamports)
   3. Post-transaction balance (lamports)
   4. Owner program (pre and post)
   5. Data changes (what was modified)
   6. Rent epoch information

### Use Cases

#### Analytics and Trading

1. Deep historical analysis and backtesting
2. Real-time liquidity and TVL monitoring
3. Pattern recognition and signal generation

#### dApps and Wallets

1. Full transaction and asset history for any user
2. Instant UI updates based on on-chain events
3. Aggregation of data across DeFi and NFT protocols

#### Infrastructure Providers and Enterprises

1. Reliable data backbone for internal analytics
2. Foundation for B2B data services
3. No need to maintain validators or archive RPC setups

***

For consultation on optimal deployment architecture for your specific use case, contact [GetBlock support team](https://getblock.io/contact/).&#x20;


# Overview

Learn about GetBlock Tron Energy, how to rent Tron energy and bandwidth through API or Dashboard UI

GetBlock Tron Energy is a service that lets you rent TRON Energy and Bandwidth via a simple API or dashboard UI. Instead of locking up large amounts of TRX to stake, you pay in USD and receive delegated resources instantly.

### Key Benefits

* Save up to 68% compared to burning TRX for fees
* Pay in USD: no need to hold or stake TRX
* Instant delegation: resources are available immediately
* Flexible durations: 1 hour to 14 days
* RESTful API for automation: ideal for exchanges and payment services
* Dashboard UI for manual operations and monitoring
* Rate limit: 30 requests/min per API key

### **How It Works**

1. **You top up** your GetBlock account with USD (using your card)
2. **You request delegation** via API or dashboard — specifying target address, Energy amount, and duration
3. **GetBlock delegates Energy** from their staked TRX pool to your target address instantly
4. **Your target address transacts** using the delegated Energy (no TRX burning)
5. **Energy recovers** over 24 hours if partially used
6. **Delegation expires** at the end of the rental period — resources return to GetBlock

<figure><img src="/files/2pkxz61gB0zHinCLRwO7" alt=""><figcaption></figcaption></figure>

#### Available Operations

| Operation          | Description                                                                                    |
| ------------------ | ---------------------------------------------------------------------------------------------- |
| Delegate Energy    | Delegate 32,000–5,000,000 Energy for 1h–14d to any TRON address                                |
| Delegate Bandwidth | Delegate 1,000–200,000 Bandwidth for 1 hour to any TRON address                                |
| Activate Address   | Activate a new TRON address on the blockchain (required before delegation to unused addresses) |
| Check Price        | Get a real-time price estimate for Energy delegation                                           |
| Check Order Status | Retrieve details of a previously placed order                                                  |

### Next Steps

1. [Getting started](/tron-energy/getting-started)
2. [Tron Fee Model](/tron-energy/tron-fee-model)
3. [Pricing](/tron-energy/api-reference)
4. [API Reference](/tron-energy/api-reference)


# Getting Started

Learn how to access Tron energy, top your balance, delegate resources, check prices and manage API key from your dashboard.

The Dashboard tab gives you a comprehensive overview of your activity:

* USD Balance: your current balance with a quick Top Up button
* Usage: bar chart showing delegation activity (filter by 24h, 7 days, month, or all time)
* Deposit History: table of all top-ups with date, method, and amount
* TRON Energy Activity: full order history with address, type, volume, duration, price, status, and date
* Export: download order history as XLS or PDF

In this guide, you will learn how to easily navigate through the dashboard to get the following:

1. How to gain access to Tron energy
2. How to top up your balanace&#x20;
3. Delegate Resources
4. Check Prices
5. Manage API Keys

### How to Access Dashboard

{% stepper %}
{% step %}
Create an account on [GetBlock](https://account.getblock.io) using Gmail, Metamask, or GitHub
{% endstep %}

{% step %}
Under **products**, click on **Tron energy**. The system will automatically sync your GetBlock account with the Energy service.

The dashboard consists of three main tabs:

1. Dashboard — view your balance, usage charts, deposit history, and order activity
2. Delegate — delegate Energy or Bandwidth to TRON addresses, manage API keys
3. API Docs — reference documentation with cURL examples for all endpoints
   {% endstep %}
   {% endstepper %}

### How to Top Up Your Balance

Before you can delegate resources, you need to fund your USD balance:

{% stepper %}
{% step %}
Click the "Top Up" button in the balance bar at the top of the dashboard
{% endstep %}

{% step %}
Select a preset amount ($50, $100, $500) or enter a custom amount (minimum $10)
{% endstep %}

{% step %}
Choose your payment method: Card or Crypto
{% endstep %}

{% step %}
Complete the payment — your balance updates instantly

{% hint style="info" %}
Your USD balance is shared across all GetBlock products.
{% endhint %}
{% endstep %}
{% endstepper %}

### How to Delegate Resources

Go to the Delegate tab and select Manual mode.

#### 1. Delegate Energy

{% stepper %}
{% step %}
Select the Energy sub-tab
{% endstep %}

{% step %}
Enter the target TRON address (starts with T, 34 characters)
{% endstep %}

{% step %}
Set the Energy amount (30,000–5,000,000)
{% endstep %}

{% step %}
Choose the duration: 1h, 3h, 6h, 12h, or 1 day
{% endstep %}

{% step %}
Click "Delegate Energy"
{% endstep %}
{% endstepper %}

#### 2. Delegate Bandwidth

{% stepper %}
{% step %}
Select the Bandwidth sub-tab
{% endstep %}

{% step %}
Enter the target TRON address
{% endstep %}

{% step %}
Set the Bandwidth amount (1,000–200,000)
{% endstep %}

{% step %}
Duration is fixed at 1 hour for Bandwidth
{% endstep %}

{% step %}
Click "Delegate Bandwidth"
{% endstep %}
{% endstepper %}

#### 3. Activate Address

If you need to delegate to a brand-new TRON address that has never been used, you must activate it first:

{% stepper %}
{% step %}
Select the Activate sub-tab
{% endstep %}

{% step %}
Enter the target TRON address
{% endstep %}

{% step %}
Click "Activate Address

{% hint style="info" %}
Activation costs a fixed 1.87 TRX, charged in USD at the current TRX/USD rate.
{% endhint %}
{% endstep %}
{% endstepper %}

### How to Check Price

The Check Price panel is available on the right side of the Delegate form (Manual mode). Use it to get a real-time estimate before placing an order:

{% stepper %}
{% step %}
Enter Energy amount (30,000–5,000,000)
{% endstep %}

{% step %}
Select duration: 1 hour, 1 day, 3 days, 7 days, or 14 days
{% endstep %}

{% step %}
Click "Check Price"
{% endstep %}

{% step %}
The result shows: price in SUN per unit, total TRX, and total USD
{% endstep %}
{% endstepper %}

### How to Manage API Keys

To use the API, you need an API key:

{% stepper %}
{% step %}
Go to Delegate → API mode
{% endstep %}

{% step %}
Click "+ Add Key" (requires a funded balance)
{% endstep %}

{% step %}
Copy and securely store the key immediately — it is shown only once
{% endstep %}

{% step %}
You can create up to 5 API keys
{% endstep %}

{% step %}
To revoke a key, click "Revoke" next to it — the key stops working immediately
{% endstep %}
{% endstepper %}

### Next Steps

1. [Tron Fee Mode](/tron-energy/tron-fee-model)
2. [API Reference](/tron-energy/api-reference)


# TRON Fee Model

Learn how to calculate transaction fees in TRON

In Bitcoin and Ethereum, transaction fees are paid in the network’s native asset — in its smallest unit (satoshi, wei). TRON works differently; every transaction consumes two types of resources:

1. Bandwidth
2. Energy.&#x20;

If these resources are insufficient, TRX is burned to cover the costs.

#### SUN: The Base Unit of TRX

SUN is the smallest unit of TRX, analogous to **satoshi** in Bitcoin or **wei** in Ethereum.

```bash
1 TRX = 1,000,000 SUN
```

The cost of Energy and Bandwidth when burning TRX is expressed in SUN.

### Bandwidth

Bandwidth is the network throughput required to transmit transaction data.

* Consumed by every transaction
* 1 Bandwidth = 1 byte of transaction data
* Each account receives a free daily allowance of 600 Bandwidth, which resets automatically
* If Bandwidth is insufficient → TRX is burned

```bash
Cost when burning: 1 Bandwidth = 1,000 SUN (0.001 TRX)
```

#### Bandwidth Consumption Examples

| Operation             | Bandwidth Used  |
| --------------------- | --------------- |
| Sending TRX           | \~268 Bandwidth |
| Sending USDT (TRC-20) | \~345 Bandwidth |

TRC-10 token transfers consume only Bandwidth. TRC-20 token transfers (USDT and other smart contract tokens) consume both Bandwidth and Energy.

### Energy

Energy is the computational power required to execute smart contracts on the TRON Virtual Machine (TVM).

* Consumed only when calling a smart contract
* 1 Energy ≈ 1 microsecond of computation on TVM
* No free daily allowance
* If Energy is insufficient → TRX is burned

```bash
Cost when burning: 1 Energy = 100 SUN (0.0001 TRX)
```

#### Example: USDT (TRC-20) Transfer Energy Cost

A typical USDT transfer calls the function transfer(address to, uint256 value). The TVM executes a balance check, a storage write for the sender (debit), and a storage write for the recipient (credit).

The amount of Energy depends on whether a storage slot already exists for the recipient:

| Scenario                                     | Energy    | Reason                            |
| -------------------------------------------- | --------- | --------------------------------- |
| Activated address (has received USDT before) | \~65,000  | Updating an existing storage slot |
| Non-activated address (never received USDT)  | \~131,000 | Creating a new storage slot       |

### Transaction Cost When Burning TRX

Current network parameters (set via governance) can be retrieved with the following request:

```bash
GET https://api.trongrid.io/wallet/getchainparameters
Current rates: 1 Energy = 100 SUN (0.0001 TRX), 1 Bandwidth = 1,000 SUN (0.001 TRX)
```

#### Cost Calculation: USDT Transfer to Activated Address (\~65,000 Energy)

* Energy: 65,000 × 100 SUN = 6,500,000 SUN = 6.5 TRX
* Bandwidth: 345 × 1,000 SUN = 345,000 SUN = 0.345 TRX
* Total: \~6.85 TRX

#### Cost Calculation: USDT Transfer to New Address (\~131,000 Energy)

* Energy: 131,000 × 100 SUN = 13,100,000 SUN = 13.1 TRX
* Bandwidth: 345 × 1,000 SUN = 345,000 SUN = 0.345 TRX
* Total: \~13.45 TRX

### Where Energy Comes From: Staking and Delegation

TRON has a Stake 2.0 mechanism that allows users to obtain Energy without burning TRX:

#### 1. Staking (Freezing TRX)

A TRX holder freezes tokens via a system contract and receives Energy proportional to their share of the total network stake. The more TRX is frozen across the network, the less Energy each participant receives per unit of TRX. When unstaking, TRX is locked for a 14-day waiting period before it is returned.

#### 2. Delegation

An owner of staked TRX can delegate their resources (Energy or Bandwidth) to another address via delegateResource. The recipient uses the Energy, while the staker retains their TRX. Delegation can be locked for a minimum of 3 days, after which it can be revoked.

#### 3. Rental Market

This mechanism forms the basis of the Energy rental market: providers stake large amounts of TRX and delegate Energy to clients for a fee. The client receives Energy without having to lock up their own capital.

### Why Renting Energy Is More Cost-Effective Than Burning TRX

Rental providers buy Energy in bulk (by staking large amounts of TRX) and sell it at a price below the cost of burning. Current market prices range from 30 to 50 SUN per 1 Energy, depending on the provider and terms.

Example calculation at a rental price of 32 SUN per 1 Energy:

| Scenario                         | Renting   | Burning TRX | Savings |
| -------------------------------- | --------- | ----------- | ------- |
| Activated address (\~65K Energy) | \~2.1 TRX | 6.5 TRX     | \~68%   |
| New address (\~131K Energy)      | \~4.2 TRX | 13.1 TRX    | \~68%   |

For high-volume clients (exchanges, payment services, dApps), renting Energy significantly reduces operational costs.

### Energy Recovery

After being used, Energy on an account recovers linearly over 24 hours. This means that if an account has staked TRX and its Energy has been spent, the full amount will be available again after 24 hours. This also applies to rented (delegated) Energy — it is recovered on the recipient’s account during the rental period.

### Next Steps

1. [Pricing](broken://pages/e7LJxCH0Sl7Chxp5lyqW)
2. [API Reference](/tron-energy/api-reference)


# API Reference

This contain all the endpoints, pricing and error codes to access TRON energy

The GetBlock TRON Energy API lets you programmatically delegate Energy and Bandwidth to any TRON address. Automate fee optimization for exchanges, payment services, and dApps.

### Base URL

```bash
https://services.getblock.io/v1/tron-energy/
```

### Authentication

All requests require an API key in the header:

```bash
Authorization: Bearer YOUR_API_KEY
```

{% hint style="info" %}
**Getting your API key**\
\
Generate API keys under **Settings → API**. Open **Settings**, go to the **API** tab, and create a key for your needs. **Copy and save it right away** — treat it as a secret: anyone holding your API key can spend the credits you've topped up on the platform. Store it following security best practices (never commit it to code or share it in plain text).
{% endhint %}

### Request example

{% tabs %}
{% tab title="cURL" %}

```bash
curl -X POST https://services.getblock.io/v1/tron-energy/delegate-energy \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44" \
  -d '{"target_address": "TUo8...", "volume": 65000, "duration": "1d"}'

```

{% endtab %}

{% tab title="Response" %}
All responses return JSON. Successful delegations include:

```json
{
  "data": {
    "status": "success",
    "target_address": "TUo8...",
    "resource_type": "energy",
    "volume": 65000,
    "duration": "1d",
    "price_usd": "0.79",
    "trx_spent": 3,
    "order_id": "1H76d06176b8",
    "txid": "db47c131876a504ceee32f023a46cf3aa23629362e28c8c272c10ced8f1f27a8",
    "message": "Delegation completed successfully."
  }
}

```

{% endtab %}
{% endtabs %}

### Endpoints

| Endpoint              | Method | Description                           |
| --------------------- | ------ | ------------------------------------- |
| `/price-estimate`     | POST   | Get real-time price quote             |
| `/delegate-energy`    | POST   | Delegate Energy (30K–5M) for 5 min–7d |
| `/delegate-bandwidth` | POST   | Puchase and delegate TRON bandwidth   |

### Pricing

You pay in **Credits**. The price is calculated from two live inputs:

* the current TRX/USD exchange rate, and
* real-time energy demand on the network.

You are charged only after the delegation is confirmed — if the order fails, nothing is deducted from your balance.

**Energy prices fluctuate over time.** Demand follows on-chain activity across the world's major financial clusters — **Asia, Europe, and the US** — so the price rises and falls as different time zones become active and quiet through the day. The swing can be large: in calmer windows energy can be significantly cheaper — sometimes around half the price of peak hours.

{% hint style="info" %}
If getting a lower price matters to you, **monitor the live price and rent when it fits your budget.** There is no fixed "cheap hour" — because activity shifts between regions, the best window varies, so watch the actual numbers rather than relying on a fixed schedule.
{% endhint %}


# price-estimate - TRON energy

Example code for the price-estimate JSON RPC method

This get a real-time price estimate for Energy delegation before placing an order.

### Body Parameter

| Parameter    | Type    | Required | Description                                             |
| ------------ | ------- | -------- | ------------------------------------------------------- |
| resourceType | string  | Yes      | "energy", "bandwidth"(soon)                             |
| volume       | integer | Yes      | Energy amount: 30,000 - 5,000,000 (depends on duration) |
| duration     | string  | Yes      | "1h", "1d", "3d", "7d"                                  |

### Request Sample

```bash
curl -X POST https://services.getblock.io/v1/tron-energy/price-estimate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"resourceType": "energy", "volume": 65000, "duration": "1d"}'
```

### Response Sample

```bash
{
  "data": {
    "price_sun": "36",
    "trx": "2.3400",
    "price_usd": "0.7900",
    "reserve_usd": "0.9500"
  }
}
```


# delegate-energy - TRON energy

Example code for the delegate-energy JSON RPC method

This endpoint delegates energy to a TRON address. In most cases, the order completes immediately with status "success".

#### Parameter

| Parameter       | Type    | Required | Description                                        |
| --------------- | ------- | -------- | -------------------------------------------------- |
| target\_address | string  | Yes      | TRON wallet address (starts with T, 34 characters) |
| volume          | integer | Yes      | Energy amount: 30,000 — 5,000,000                  |
| duration        | string  | Yes      | "1h", "1d", "3d", "7d"                             |

### Idempotency

delegateEnergy charges your balance and may place an on-chain order. To make retries safe, send a unique key with each *intent*:

```
Idempotency-Key: 6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44
```

A UUID is recommended. Generate a **new** key for each purchase, and reuse the same key when retrying the exact same purchase.

| Situation                                         | Result                                                                |
| ------------------------------------------------- | --------------------------------------------------------------------- |
| Same key + **same** body                          | The original response is replayed. No second charge, no second order. |
| Same key + **different** body                     | `422`                                                                 |
| Same key on a **different** endpoint              | `409`                                                                 |
| Duplicate sent while the first is still in flight | `409` with a `Retry-After` header                                     |
| Idempotency store temporarily unavailable         | `503` with a `Retry-After` header (retry shortly)                     |

{% hint style="info" %}
Always send an idempotency key on write endpoints. It is the difference between a safe retry and an accidental double on-chain charge.
{% endhint %}

#### Request Sample

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
curl -X POST https://services.getblock.io/v1/tron-energy/delegate-energy \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44" \
  -d '{
    "target_address": "TUo8pycbvje...zw67bpPs4GLFyD",
    "volume": 65000,
    "duration": "1h"
  }'
```

{% endcode %}
{% endtab %}

{% tab title="Axios" %}
{% code overflow="wrap" %}

```javascript
import axios from 'axios';
const data = JSON.stringify({
    "target_address": "TUo8pycbvje...zw67bpPs4GLFyD",
    "volume": 65000,
    "duration": "1h"
  }
);

const config = {
    method: 'post',
    url: 'https://services.getblock.io/v1/tron-energy/delegate-energy',
    headers: {
        'Content-Type': 'application/json',
        'Authorization: Bearer YOUR_API_KEY'
        'Idempotency-Key: 6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44' \
    },
    data: data
};
axios(config)
    .then(response => console.log(JSON.stringify(response.data)))
    .catch(error => console.log(error));
```

{% endcode %}
{% endtab %}

{% tab title="Request" %}
{% code overflow="wrap" %}

```python
import requests
import json

url = "https://services.getblock.io/v1/tron-energy/delegate-energy"

payload = json.dumps({
    "target_address": "TUo8pycbvje...zw67bpPs4GLFyD",
    "volume": 65000,
    "duration": "1h"
  }
)

headers = {
        'Content-Type': 'application/json',
        'Authorization: Bearer YOUR_API_KEY',
        'Idempotency-Key: 6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44' 
    },
response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endcode %}
{% endtab %}

{% tab title="Rust" %}
{% code overflow="wrap" %}

```rust
use reqwest::header;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = reqwest::Client::new();

    let url = "https://services.getblock.io/v1/tron-energy/delegate-energy";
    let payload = r#"{{
    "target_address": "TUo8pycbvje...zw67bpPs4GLFyD",
    "volume": 65000,
    "duration": "1h"
  }
"#;

    let response = client
        .post(url)
        .header(header::CONTENT_TYPE, "application/json")
        .header(header::AUTHORIZATION, "Bearer YOUR_API_KEY")
        .header(header::IDEMPOTENCY_KEY: "6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44")
        .body(payload)
        .send()
        .await?;

    println!("{}", response.text().await?);

    Ok(())
}
```

{% endcode %}
{% endtab %}

{% tab title="GO" %}

```go
package main
import (
    "bytes"
    "encoding/json"
    "fmt"
    "net/http"
)
func main() {
    url := "https://services.getblock.io/v1/tron-energy/delegate-energy"
    payload := map[string]interface{}{
    "target_address": "TUo8pycbvje...zw67bpPs4GLFyD",
    "volume": 65000,
    "duration": "1h"
  }

    jsonData, _ := json.Marshal(payload)
    req, _ := http.NewRequest("POST", url, bytes.NewBuffer(jsonData))
    req.Header.Set("Authorization", "Bearer YOUR_API_KEY")
    req.Header.Set("Content-Type", "application/json")
    req.Header.Set("Idempotency-Key": "6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44")
    client := &http.Client{}
    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    
    var result map[string]interface{}
    json.NewDecoder(resp.Body).Decode(&result)
    fmt.Println(result)
}
```

{% endtab %}
{% endtabs %}

#### &#x20;Response&#x20;

```bash
{
  "data": {
    "status": "success",
    "target_address": "TUo8...",
    "resource_type": "energy",
    "volume": 65000,
    "duration": "1h",
    "price_usd": "0.59",
    "trx_spent": 3,
    "order_id": "1H76d06176b8",
    "txid": "db47c131876a504ceee32f023a4aa3aa23629362e...",
    "message": "Delegation completed successfully."
  }
}
```


# delegate-bandwidth - TRON energy

Example code for the delegate-bandwidth JSON RPC method. Сomplete guide on how to use delegate-bandwidth JSON RPC in GetBlock Web3 documentation.

This is used to purchase and delegate TRON bandwidth to a target address. Unlike energy, bandwidth orders may be confirmed asynchronously: if the provider accepts the order but on-chain delivery is not yet confirmed, the API returns `202` Accepted and no charge is applied until delivery is confirmed.

### Body Parameter

| Parameter       | Type    | Required | Description                                        |
| --------------- | ------- | -------- | -------------------------------------------------- |
| target\_address | string  | Yes      | TRON wallet address (starts with T, 34 characters) |
| volume          | integer | Yes      | Bandwidth amount: 1,000 — 200,000                  |
| duration        | string  | Yes      | "1h" (only 1 hour supported for Bandwidth)         |

### Request Sample

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
curl -X POST https://services.getblock.io/v1/tron-energy/delegate-bandwidth \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "target_address": "TUo8pycbvje9w2XYsNnnzw67bpPs4GLFyD",
    "volume": 5000,
    "duration": "1h"
  }
'
```

{% endcode %}
{% endtab %}

{% tab title="Axios" %}
{% code overflow="wrap" %}

```javascript
import axios from 'axios';
const data = JSON.stringify({
    "target_address": "TUo8pycbvje9w2XYsNnnzw67bpPs4GLFyD",
    "volume": 5000,
    "duration": "1h"
  }
);

const config = {
    method: 'post',
    url: 'https://services.getblock.io/v1/tron-energy/delegate-bandwidth',
    headers: {
        'Content-Type': 'application/json',
        'Authorization: Bearer YOUR_API_KEY'
    },
    data: data
};
axios(config)
    .then(response => console.log(JSON.stringify(response.data)))
    .catch(error => console.log(error));
```

{% endcode %}
{% endtab %}

{% tab title="Request" %}
{% code overflow="wrap" %}

```python
import requests
import json

url = "https://services.getblock.io/v1/tron-energy/delegate-bandwidth"

payload = json.dumps({
    "target_address": "TUo8pycbvje9w2XYsNnnzw67bpPs4GLFyD",
    "volume": 5000,
    "duration": "1h"
  }
)

headers = {
        'Content-Type': 'application/json',
        'Authorization: Bearer YOUR_API_KEY'
    },
response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endcode %}
{% endtab %}

{% tab title="Rust" %}
{% code overflow="wrap" %}

```rust
use reqwest::header;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = reqwest::Client::new();

    let url = "https://services.getblock.io/v1/tron-energy/delegate-bandwidth";
    let payload = r#"{
    "target_address": "TUo8pycbvje9w2XYsNnnzw67bpPs4GLFyD",
    "volume": 5000,
    "duration": "1h"
  }
"#;

    let response = client
        .post(url)
        .header(header::CONTENT_TYPE, "application/json")
        .header(header::AUTHORIZATION, "Bearer YOUR_API_KEY")
        .body(payload)
        .send()
        .await?;

    println!("{}", response.text().await?);

    Ok(())
}
```

{% endcode %}
{% endtab %}

{% tab title="GO" %}

```go
package main
import (
    "bytes"
    "encoding/json"
    "fmt"
    "net/http"
)
func main() {
    url := "https://services.getblock.io/v1/tron-energy/delegate-bandwidth"
    payload := map[string]interface{}{
    "target_address": "TUo8pycbvje9w2XYsNnnzw67bpPs4GLFyD",
    "volume": 5000,
    "duration": "1h"
  }

    jsonData, _ := json.Marshal(payload)
    req, _ := http.NewRequest("POST", url, bytes.NewBuffer(jsonData))
    req.Header.Set("Authorization", "Bearer YOUR_API_KEY")
    req.Header.Set("Content-Type", "application/json")
    client := &http.Client{}
    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    
    var result map[string]interface{}
    json.NewDecoder(resp.Body).Decode(&result)
    fmt.Println(result)
}
```

{% endtab %}
{% endtabs %}

{% hint style="warning" %}
Bandwidth only supports "1h" duration.
{% endhint %}

### Response Sample

{% tabs %}
{% tab title="200(Success)" %}

```bash
{
  "order_id": "clxyz123...",
  "status": "success",
  "target_address": "TUo8pycbvje9w2XYsNnnzw67bpPs4GLFyD",
  "resource_type": "energy",
  "volume": 65000,
  "duration": "3d",
  "price_usd": "4.97",
  "trx_spent": 20.12,
  "provider_order_id": 12345,
  "txid": "abc123def...",
  "message": "Order completed successfully."
}
```

{% endtab %}

{% tab title="202(Accepted)" %}
{% code overflow="wrap" %}

```bash
{
  "data": {
  "status": "accepted",
  "target_address": "TUo8pycbvje...zw67bpPs4GLFyD",
  "resource_type": "bandwidth",
  "volume": 1000,
  "duration": "1h",
  "provider_order_id": "36898a97-a8b9-46ea-b4cb-38a81e28992d",
  "message": "Order accepted by provider, awaiting on-chain confirmation."
 }
}
```

{% endcode %}
{% endtab %}
{% endtabs %}

### Idempotency

Send a unique Idempotency-Key header (UUID format recommended) to ensure safe retries:

| Scenario                       | Behavior                                        |
| ------------------------------ | ----------------------------------------------- |
| Same key + same body           | Original response replayed, no duplicate charge |
| Same key + different body      | 422                                             |
| Same key on different endpoint | 409                                             |
| In-flight duplicate request    | 409 with Retry-After header                     |

A retry of a 202 response replays the same 202 — it does not create a second order


# address-activate - TRON energy

Example code for the addressActivate JSON RPC method. Сomplete guide on how to use addressActivate JSON RPC in GetBlock Web3 documentation.

This activates (creates) a TRON address on-chain. This is required before delegating Energy or Bandwidth to a new (never-used) address.\
A newly generated TRON address must be activated before it\
can hold a balance or receive transfers. Activation is synchronous: the API returns 200 with the provider's\
activation receipt, and the realised on-chain cost is charged from your prepaid balance.&#x20;

{% hint style="info" %}
Fixed cost: 1.87 TRX, charged in USD at the current TRX/USD rate.
{% endhint %}

### Body Parameter

| Parameter       | Type   | Required | Description                                            |
| --------------- | ------ | -------- | ------------------------------------------------------ |
| target\_address | string | Yes      | TRON wallet to activate (starts with T, 34 characters) |

### Request Sample

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
curl -X POST https://services.getblock.io/v1/tron-energy/address-activate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44" \
  -d '{
    "target_address": "TUo8pycbvje9w2XYsNnnzw67bpPs4GLFyD"
  }'
```

{% endcode %}
{% endtab %}

{% tab title="Axios" %}
{% code overflow="wrap" %}

```javascript
import axios from 'axios';
const data = JSON.stringify({
    "target_address": "TUo8pycbvje9w2XYsNnnzw67bpPs4GLFyD"
  }
);

const config = {
    method: 'post',
    url: 'https://services.getblock.io/v1/tron-energy/address-activate',
    headers: {
        'Content-Type': 'application/json',
        'Authorization: Bearer YOUR_API_KEY'
        'Idempotency-Key: 6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44' \
    },
    data: data
};
axios(config)
    .then(response => console.log(JSON.stringify(response.data)))
    .catch(error => console.log(error));
```

{% endcode %}
{% endtab %}

{% tab title="Request" %}
{% code overflow="wrap" %}

```python
import requests
import json

url = "https://services.getblock.io/v1/tron-energy/address-activate"

payload = json.dumps({
    "target_address": "TUo8pycbvje9w2XYsNnnzw67bpPs4GLFyD"
  }
)

headers = {
        'Content-Type': 'application/json',
        'Authorization: Bearer YOUR_API_KEY',
        'Idempotency-Key: 6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44' 
    },
response = requests.post(url, headers=headers, data=payload)
print(response.text)
```

{% endcode %}
{% endtab %}

{% tab title="Rust" %}
{% code overflow="wrap" %}

```rust
use reqwest::header;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = reqwest::Client::new();

    let url = "https://services.getblock.io/v1/tron-energy/address-activate";
    let payload = r#"{
    "target_address": "TUo8pycbvje9w2XYsNnnzw67bpPs4GLFyD"
  }
"#;

    let response = client
        .post(url)
        .header(header::CONTENT_TYPE, "application/json")
        .header(header::AUTHORIZATION, "Bearer YOUR_API_KEY")
        .header(header::IDEMPOTENCY_KEY: "6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44")
        .body(payload)
        .send()
        .await?;

    println!("{}", response.text().await?);

    Ok(())
}
```

{% endcode %}
{% endtab %}

{% tab title="GO" %}

```go
package main
import (
    "bytes"
    "encoding/json"
    "fmt"
    "net/http"
)
func main() {
    url := "https://services.getblock.io/v1/tron-energy/address-activate"
    payload := map[string]interface{}{
    "target_address": "TUo8pycbvje9w2XYsNnnzw67bpPs4GLFyD"
  }

    jsonData, _ := json.Marshal(payload)
    req, _ := http.NewRequest("POST", url, bytes.NewBuffer(jsonData))
    req.Header.Set("Authorization", "Bearer YOUR_API_KEY")
    req.Header.Set("Content-Type", "application/json")
    req.Header.Set("Idempotency-Key": "6f9c2a1e-3b7d-4c08-9f21-2e5a7c0b1d44")
    client := &http.Client{}
    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    
    var result map[string]interface{}
    json.NewDecoder(resp.Body).Decode(&result)
    fmt.Println(result)
}
```

{% endtab %}
{% endtabs %}

### Response Sample

```bash
{
"data": {
"id": "a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
"address_to": "TUo8pycbvje...zw67bpPs4GLFyD",
"cost": 1700000,
"created_at": "2026-06-18T10:42:00Z"
        }
}
```

### Response Sample Definition

| Field       | Type    | Charged | Description                                                                 |
| ----------- | ------- | ------- | --------------------------------------------------------------------------- |
| id          | string  | No      | provider activation/order id                                                |
| address\_to | string  | No      | The TRON adrress that was activated                                         |
| cost        | integer | Yes     | realised on-chain cost in sun(1 TRX = 1,000,000 sun); this what is deducted |
| created\_at | string  | No      | RFC3339 timestamp of the activation                                         |

### Idempotency

Send a unique Idempotency-Key header (UUID format recommended) to ensure safe retries:

| Scenario                       | Behavior                                        |
| ------------------------------ | ----------------------------------------------- |
| Same key + same body           | Original response replayed, no duplicate charge |
| Same key + different body      | 422                                             |
| Same key on different endpoint | 409                                             |
| In-flight duplicate request    | 409 with Retry-After header                     |

A retry with the same key + body replays the original activation receipt — it does not activate the address twice or charge a second time.




---

[Next Page](/llms-full.txt/1)

