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
1
Go to GetBlock
Visit the homepage and click on the 'Dashboard' button in the upper-right corner, or use this direct link.
2
Choose the sign-up method
Register with Email
Enter your name and email address, then verify your email to activate the account.
Sign in via Google
3
Review and accept policies
During registration, you will be asked to accept our and .
Access the dashboard
Once you've created an account and signed in, you'll be directed to the GetBlock .
You can create endpoints
Monitor your usage plan
Access statistics.
Check your User ID
Click on your profile icon
Click on the Copy Icon to copy your User ID
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.
GetBlock's Sign-Up page, where users can register to access blockchain services
GetBlock user Dashboard
Welcome
Welcome to GetBlock! We make it easy for developers and businesses to connect to 130+ blockchain networks.
With our tools and services, you can focus on building your dApp without worrying about the technical details of setting up and managing blockchain nodes.
From DeFi apps and NFT platforms to analytics tools, AppChains, and more, GetBlock provides the infrastructure to help you build, test, and scale your blockchain-powered solutions.
Core GetBlock Services
Services
Description
Discover GetBlock
Popular chains
Get started with our most in-demand blockchain networks.
Plans and limits
GetBlock offers scalable plans tailored to developers and businesses, providing flexible solutions for both small projects and high-traffic platforms.
GetBlock offers flexible plans and features to support developers and businesses at any stage, from small projects to high-traffic platforms. This section covers available plans, scaling features, and managing subscriptions and payments.
Using Web3 libraries
Learn how to interact with blockchain networks through GetBlock’s node infrastructure using popular web3 libraries.
Here you'll find step-by-step instructions on how to integrate popular developer libraries like Web3.js,Ethers.js, and others with GetBlock API.
These libraries allow developers to interact with Ethereum and other EVM-compatible blockchains to read data, send transactions, and deploy smart contracts.
The guide covers setting up your connection to GetBlock and performing basic operations.
Endpoint setup
Configure and manage blockchain node endpoints through GetBlock, offering easy creation of shared nodes
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.
Testing RPC connection
This section provides simple examples to help you test your connection to the blockchain, using Ethereum API as a reference.
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.
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)
Create your account, explore plans & features, and make your first API call
Guides
Set up endpoints, manage access tokens, and integrate GetBlock APIs step-by-step
API Reference
View supported networks, available endpoints, and full API specifications
From free access to enterprise-grade solutions, we’ve got options for every stage of your project.
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 balancefor 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
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 you create is assigned a unique 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.
Starter, Pro & Enterprise users can refill their CU balance or switch to another plan for increased limits:
Click the "Top Up" button on the Dashboard.
Select the number of CUs you’d like to add or choose the recommended plan (if prompted) based on your usage needs.
Confirm and finalize your purchase.
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.
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:
Click "Change" on the Dashboard next to the Rate Limit section.
Fill out and submit a request form, choosing your desired RPS limit, CU amount, and number of Access Tokens.
Our team will review your request and reach out to you with next steps shortly.
This feature is perfect for users who need higher transaction throughput without changing their plan. For more demanding needs, consider .
For example, here’s how to fetch the latest Ethereum block number:
Response:
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:
Go to your GetBlock Dashboard.
Locate the endpoint associated with the token.
Click the three-dot icon () next to the endpoint.
Select the option to either roll (regenerate) or delete the token.
Regenerate or delete your access token
This authentication method ensures that all your interactions with GetBlock’s services remain secure, reliable, and easy to manage.
This guide explains how GetBlock users can connect to blockchain nodes to create accounts and send transactions.
In blockchains, ‘account’ should be referred to as a pair of private and public keys. Blockchains ‘recognize’ their users and balances by these keypairs.
Unlike login/password pairs in traditional computational solutions, in modern blockchains, every account can be restored with a private key only.
So, to broadcast transactions to a decentralized network, we need first to create (or restore) our account. The whole set of interactions is organized via Web3.js library.
Creating accounts
First, initialize the Web3.js library and set up the connection to a blockchain node:
Next, we can create an account on the testnet:
We can also restore an account from an existing private key:
You may ask what does ‘eth’ mean when we’re interacting with BNB Chain? No mistake, it reflects the fact that BNB Smart Chain is fully compatible with Ethereum Virtual Machine.
Sending transactions
In blockchains, transactions should be signed (authorized) to be ‘included’ into blockchains (confirmed by its consensus of miners or validators).
Here’s how our transactions are created. 0.01 ETH is used for demo.
That’s how the transaction looks before being included in the blockchain. Once signed, it can be sent to the network of nodes.
That’s it: your account is good to go and its transaction is submitted successfully!
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.
Updating your payment details
To update your payment information while you have an active subscription:
Go to Pricing → Manage Plans.
Click ‘Edit Payment Method’.
Enter your updated payment details and save the changes.
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.
Web3.js integration
Learn how to use Web3.js, a widely-used JavaScript library for connecting to GetBlock nodes.
Web3.js is a JavaScript library built for interacting with the Ethereum blockchain and other EVM-compatible chains. It is used to send JSON-RPC calls to the Ethereum node via HTTP, IPC, or WebSocket connection to read data from the blockchain, make transactions, or deploy smart contracts.
Install Web3.js
Use your preferred package manager:
npminstallweb3
yarnaddweb3
dist/web3.min.js
Set up your connection to GetBlock
For additional methods and options, refer to the official .
TronWeb integration
In this guide, we will show you how to get started with TronWeb to connect to GetBlock.
TronWeb is a JavaScript library of TRON full node’s API functions that is used to deploy smart contracts, query blockchain and contract information, trade on the decentralized exchanges and change the blockchain state.
Firstly, you will need to add the TronWeb library to your project.
Npm:
npm install tronweb
Yarn:
yarn add tronweb
In your javascript file, define TronWeb:
When you instantiate TronWeb you can define:
fullNode
solidityNode
eventServer
privateKey
you can also set a
fullHost
Which works as a jolly. If you do so, though, the more precise specification has priority. Supposing you are using a server which provides everything, like TronGrid, you can instantiate TronWeb as:
For retro-compatibility, though, you can continue to use the old approach, where any parameter is passed separately (using the GetBlock node as an example here):
After this you can call any TronWeb method:
All API references can be found in the project documentation at
Method response:
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.
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.
Select the desired network from the drop-down list on the sidebar.
Paste the access token copied from your account instead of {YOUR_ACCESS_TOKEN}.
This token will grant you the necessary permissions to explore our node functionalities.
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 (address, blockNumber)
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:
Download the getblock.config.json
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.
The steps below cover how to generate a new endpoint URL with an Access Token:
1
Log in to your GetBlock account and navigate to the Dashboard
2
Choosing your plan
Compare GetBlock's subscription options to find the one that fits your project.
GetBlock offers three main service options—Shared Nodes, Dedicated Nodes, and Enterprise Solutions. This page provides a high-level overview of these services.
You can explore detailed pricing and plans from your dashboard in the “Pricing” section or via .
Shared nodes
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.
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
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
The Dashboard provides a quick snapshot of key metrics:
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
Ethers.js integration
Set up GetBlock as a provider using Ethers.js library to interact with the blockchain and streamline your dApp development process.
Ethers.js is a lightweight JavaScript library for interacting with Ethereum and other EVM-compatible blockchains. It is commonly used by developers to build decentralized applications (dApps) and manage Ethereum-based operations like deploying smart contracts, interacting with them, and managing user wallets.
Install Ethers.js
Add Ethers.js to your project using your preferred package manager:
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
Code
Error message
Solution
Please, account for VAT when planning your payments.
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.
Selecting fiat as a payment method
Crypto payments
Using Postman to send a JSON-RPC request to an Ethereum node via GetBlock
const Web3 = require('web3');
//Set up the provider (replace ACCESS-TOKEN with your actual token)
const web3 = new Web3('https://go.getblock.io/<ACCESS-TOKEN>/');
Make sure you have jq installed. jq is a versatile command-line tool that enables extracting values from JSON files;
Navigate to your workspace or directory where you have imported the getblock.config.json file and open a terminal;
Now, you can make a GET request to a selected node endpoint using the curl command:
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.
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
Download the getblock.config.js file from your GetBlock account. Add this file to your project directory.
Import the getblock module to a .js file that configures a new Web3 instance:
Connect to an Ethereum node and start sending API calls using web3.js over HTTP or WebSocket in the format below:
Use go() method to access an entire endpoint or token() to fetch the token.
How to use the JS config with Hardhat
Set up GetBlock’s JS config file in Hardhat following the steps below:
Ensure you have Hardhat installed as a dependency in your Node.js project or run the following command to do so:
Navigate to your GetBlock account and install the getblock.config.js file. Copy and paste it into your working directory;
Open the hardhat.config.js file from your project directory and import the getblock module:
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.
// Import the Web3 library
const Web3 = require('web3');
// Set GetBlock as the provider (replace ACCESS_TOKEN with your actual token)
var web3 = new Web3('https://go.getblock.io/ACCESS_TOKEN');
// Initialize web3 method
web3.eth.getBlockNumber().then(console.log);
curl -X GET https://go.getblock.io/"$(jq -r '.shared.btc.mainnet.rest[0]' getblock.config.json)"/rest/chaininfo.json
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()}`
));
// Import the Ethers library
const { ethers } = require('ethers');
// Set up the provider (replace ACCESS_TOKEN with your actual token)
const provider = new ethers.JsonRpcProvider('https://go.getblock.io/ACCESS_TOKEN');
//Call a method using the provider
const main = async () => {
const blockNumber = await provider.getBlockNumber();
console.log("Latest Block Number:", blockNumber);
};
// Call the main function
main();
,
(contract, slot, blockNumber),
(address, blockNumber), etc.
Call view functions against historical state: e.g. eth_call(..., 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 ( ) when picking a protocol during the endpoint setup. It indicates that Archive mode is available for that blockchain.
How to enable the Archive mode
Sign in to your GetBlock dashboard and make sure you’re on the Shared Node tab.
Click Get endpoint and choose a required blockchain protocol.
Find the Mode toggle and switch the Archivemode on.
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.
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 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 what you’re building — our team can guide you to the most efficient archive node setup.
If you need an archive data for a chain not covered by shared Archive mode, request a . Dedicated Nodes can be deployed in archive mode for any supported blockchain and come with additional benefits like:
Click Get endpoint to open the endpoint setup menu
4
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)
5
Click 'Get' and have the endpoint URL with an access token generated.
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.
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.
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 () to roll (regenerate) or delete the endpoint from the list.
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.
All GetBlock endpoints follow a predictable format. The visible difference is the hostname reflecting the region selected during the setup.
Endpoint examples:
The token encodes the protocol, networks, and routing on the server — clients don’t need to specify a chain in the URL.
Selecting the Archive mode for an endpoint changes how requests are billed in Compute Units (CU). Learn more in the .
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.
Shared nodes operate on a
resource-sharing model
, where multiple clients access the same underlying node infrastructure maintained by GetBlock.
GetBlock shared node service options
Our Shared Nodes deliver the perfect balance between affordability and performance:
Cost efficiency: Benefit from our pricing model based on Compute Units (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.
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.
GetBlock private node features and pricing
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.
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 to learn more about how we tailor services to fit complex, high-demand environments.
This option is ideal for developers and teams looking for reliable connectivity to various blockchain networks without the higher costs of dedicated server resources.
If your project demands the fastest, most reliable blockchain infrastructure, a Dedicated Node from GetBlock is a perfect choice.
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.
In the setup window:
Select the blockchain protocol and the network type (e.g., mainnet, testnet, devnet, etc)
Customize your dedicated node with the following options:
Node type: Choose between Full Node or Archive Node
Pick a deployment location: Germany (Frankfurt), USA (New York), Singapore
Node client: Choose your preferred node implementation (e.g., Geth)
API interface: Review available interface types
Under the Performance section, select a :
High: premium specs, max throughput
Standard: enterprise specs, optimized pricing for moderate-high loads
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
Select any add-ons you need and click Next.
Step 3: Payment
On the final screen:
Review the final pricing and node settings
Billing Contact — Enter your contact information so the GetBlock team can notify you when your node is ready.
Payment method — Choose between Credit Card or Crypto.
Subscription — Enable the subscription toggle if you want to ensure your node renews automatically each billing cycle.
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.
Managing your dedicated node
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:
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.
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.
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.
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.
Your current plan details
Remaining CU balance
Rate limit based on your plan
Total requests made in the last 24 hours
Detailed statistics
For more detailed analysis, visit the Statistics tab in the dashboard.
Select the time period, protocol name, networks (mainnet/testnet), region, and API interfaces to analyze the data by parameters.
The Statistics tab shows more in-depth and customizable data analysis for your endpoints
All data is displayed through infographics, including:
Number of requests and CUs
Response statuses
Method call distribution
Rate limit rejections
Notifications and email communication
GetBlock provides automated email updates for key account and subscription events:
Account registration
Successful order payments (Shared, Dedicated services, and Top-Ups)
Start of grace period
Subscription expiration
Dedicated node deployed and activated
Recurring payment cancelled
Users can also choose whether to receive marketing communications from GetBlock. This preference can be managed in Account Settings → General by enabling or disabling the “I want to receive marketing offers” option.
Customize the data view by parameters or by accesstokens using the dropdown menu.
Email notifications are delivered only toaccounts 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.
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
Most use cases
Single nonce, atomic execution, slightly higher gas
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
Next Steps
Learn how to submit transactions via Multicall3 or Bundle method to the private mempool.
Access denied
Double-check that <ACCESS_TOKEN> is correctly replaced with your actual token. Ensure there are no trailing spaces.
404
Could not resolve host
Verify that the URL https://go.getblock.io/<ACCESS_TOKEN>/ is correct.
429
Too many requests
Check your GetBlock account for usage limits. Upgrade your plan if necessary.
JSON-RPC errors
Code
Error message
Solution
32601
The method does not exist/is not available
Verify the method name (eth_blockNumber, eth_getBalance, etc.) against the blockchain's JSON-RPC .
32602
Invalid argument
Ensure the parameters in the params array match the expected format for the method.
401
const TronWeb = require('tronweb');
const tronWeb = new TronWeb({
fullHost: "https://go.getblock.io/<ACCESS-TOKEN>/"
})
const fullNode = new TronWeb.providers.HttpProvider("https://go.getblock.io/<ACCESS-TOKEN>/")
const solidityNode = new TronWeb.providers.HttpProvider("https://go.getblock.io/<ACCESS-TOKEN>/")
const eventServer = new TronWeb.providers.HttpProvider("https://go.getblock.io/<ACCESS-TOKEN>/")
const tronWeb = new TronWeb(fullNode, solidityNode, eventServer)
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:
How to gain access to Tron energy
How to top up your balanace
Delegate Resources
Check Prices
How to Access Dashboard
1
Create an account on using Gmail, Metamask, or GitHub
2
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:
How to Top Up Your Balance
Before you can delegate resources, you need to fund your USD balance:
1
Click the "Top Up" button in the balance bar at the top of the dashboard
2
Select a preset amount ($50, $100, $500) or enter a custom amount (minimum $10)
3
Choose your payment method: Card or Crypto
How to Delegate Resources
Go to the Delegate tab and select Manual mode.
1. Delegate Energy
1
Select the Energy sub-tab
2
Enter the target TRON address (starts with T, 34 characters)
3
Set the Energy amount (30,000–5,000,000)
4
2. Delegate Bandwidth
1
Select the Bandwidth sub-tab
2
Enter the target TRON address
3
Set the Bandwidth amount (1,000–200,000)
4
3. Activate Address
If you need to delegate to a brand-new TRON address that has never been used, you must activate it first:
1
Select the Activate sub-tab
2
Enter the target TRON address
3
Click "Activate Address
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:
1
Enter Energy amount (30,000–5,000,000)
2
Select duration: 1 hour, 1 day, 3 days, 7 days, or 14 days
3
Click "Check Price"
4
How to Manage API Keys
To use the API, you need an API key:
1
Go to Delegate → API mode
2
Click "+ Add Key" (requires a funded balance)
3
Copy and securely store the key immediately — it is shown only once
4
Next Steps
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
https://api.getblock.io/tron-energy
Authentication
All requests require an API key in the header:
Quick Example
Generate keys in your dashboard under Delegate → API.
All responses return JSON. Successful delegations include:
Endpoints
Endpoint
Method
Description
Rate Limits
30 requests/minute per API key
Up to 5 API keys per account
Error Codes
Pricing
You pay in USD. The price is calculated based on the current TRX/USD rate. You are charged only after the delegation is confirmed — if the order fails, nothing is deducted.
For example, 32,000 Energy for 24h costs approximately $1.60–$1.80, depending on the current TRX rate.
How to Get a TRON RPC Endpoint
Step-by-step guide to getting a fast, reliable TRON RPC endpoint
TRON processes more USDT transfers than any other blockchain. If you're building payment systems, wallets, trading bots, or any application that touches TRC-20 tokens, you need a reliable TRON RPC endpoint. Here's how to set one up with GetBlock.
Step-by-Step: Get Your TRON RPC Endpoint
1
Create a GetBlock Account
Go to and sign up. You can register with email or via Google/GitHub OAuth.
2
Create a TRON Endpoint
Once logged in:
Click "Shared Nodes" in the left sidebar
3
Copy Your Endpoint URL
Your endpoint URL looks like this:
4
Test the Connection
Code Sample
TRON API Interfaces
TRON supports multiple API interfaces. GetBlock offers:
Interface
Use Case
Most TRON developers use the HTTP API with TronWeb library.
What's Next?
Processing USDT at scale? for dedicated TRON infrastructure.
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
You top up your GetBlock account with USD (using your card)
You request delegation via API or dashboard — specifying target address, Energy amount, and duration
GetBlock delegates Energy from their staked TRX pool to your target address instantly
Available Operations
Next Steps
Using cURL for testing
These examples provide a starting point for testing your connection and querying blockchain data using cURL commands.
Before you start:
Create a JSON-RPC endpoint for the Ethereum blockchain from your GetBlock account.
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:
If successful, the response will include the current block number in hexadecimal value:
Get the chain ID
Identify the blockchain network with the eth_chainId method:
Response example:
In this example, 0x1 indicates the Ethereum Mainnet. The chain ID helps confirm which blockchain network you are interacting with.
Check account balance by address
Retrieve the balance of an Ethereum address using eth_getBalance. Replace <ACCOUNT_ADDRESS> with the target wallet address:
Example response:
The result field shows the account balance in wei (1 ether = 10¹⁸ wei).
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:
Bandwidth
Energy.
If these resources are insufficient, TRX is burned to cover the costs.
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 and get one of the 100+ available chain endpoints.
Every wallet’s network can be modified this way, and this step-by-step guide shows how to do that.
How to Get an Avalanche RPC Endpoint
Step-by-step guide to getting a fast, reliable Avalanche RPC endpoint
Avalanche's C-Chain provides EVM-compatible smart contract execution with sub-second finality. Whether you're building DeFi protocols, NFT platforms, or gaming applications on Avalanche, this guide gets you connected in minutes.
Features
C-Chain — full EVM compatibility
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:
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.
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? for more information.
The Indexed Archive Solution
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:
fast data streaming (StreamFirst)
intelligent transaction routing (LandFirst)
into a single, integrated solution for professional trading operations.
addressActivate - 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 a TRON address on the blockchain. Required before delegating Energy or Bandwidth to a new (never-used) address.
Body Parameter
orders/{order_id} - TRON energy
Example code for the orders/{order_id} JSON RPC method. Сomplete guide on how to use orders/{order_id} JSON RPC in GetBlock Web3 documentation.
This retrieves the details of a previously placed order. Useful if you received a 202 response and need to check the final status.
Path Parameter
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? for more information.
How It Works
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.
This step-by-step tutorial will guide you through connecting GetBlock’s powerful nodes to your MetaMask wallet.
Before you start
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
How to Get an Optimism RPC Endpoint
Step-by-step guide to getting a fast, reliable Optimism RPC endpoint
Optimism (OP Mainnet) is a leading Ethereum L2 and the foundation of the Superchain ecosystem. With sub-dollar transaction costs and full EVM compatibility, it hosts major protocols like Velodrome, Synthetix, and Aave. Here's how to get a reliable OP Mainnet RPC endpoint.
Features
Archive data access (all plans)
Manage API Keys
Dashboard — view your balance, usage charts, deposit history, and order activity
Delegate — delegate Energy or Bandwidth to TRON addresses, manage API keys
API Docs — reference documentation with cURL examples for all endpoints
4
Complete the payment — your balance updates instantly
Your USD balance is shared across all GetBlock products.
Choose the duration: 1h, 3h, 6h, 12h, or 1 day
5
Click "Delegate Energy"
Duration is fixed at 1 hour for Bandwidth
5
Click "Delegate Bandwidth"
The result shows: price in SUN per unit, total TRX, and total USD
You can create up to 5 API keys
5
To revoke a key, click "Revoke" next to it — the key stops working immediately
Activation costs a fixed 1.87 TRX, charged in USD at the current TRX/USD rate.
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 or getProgramAccounts 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.
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
Note that gRPC is not supported in browsers, so Yellowstone is intended for backend services.
POST
Activate a new TRON address
/orders/{order_id}
GET
Check order status
/api/price-estimate
POST
Get real-time price quote
Rate limit exceeded (30 requests/min per API key)
502
Provider error — the upstream delegation service is temporarily unavailable
/delegateEnergy
POST
Delegate Energy (30K–5M) for 1h–14d
/delegateBandwidth
POST
Delegate Bandwidth (1K–200K) for 1h
HTTP Status
Meaning
400
Invalid request parameters (bad address, volume, duration, or resource type)
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>/
Click "Create New Endpoint" or the "+" button
Select:
Protocol: TRON
Network: Mainnet or Testnet
API Interface: gRPC (Fullnode) or JSON-RPC (Fullnode) or REST (Fullnode) or gRPC (Solidity) or JSON-RPC (Solidity)
Region: Frankfurt (EU) or New York or Singapore
Click "Create": Your endpoint URL will be generated immediately.
importTronWebfrom"tronweb";consttronWeb=newTronWeb({fullHost:"https://go.getblock.io/<YOUR-ACCESS-TOKEN>/",});// Get TRX balanceconstbalance=awaittronWeb.trx.getBalance("TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g");console.log(`Balance: ${balance/1e6} TRX`);// Get USDT balance (TRC-20)constcontract=awaittronWeb.contract().at("TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t");//constusdtBalance=awaitcontract.balanceOf("TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g").call();console.log(`USDT: ${usdtBalance/1e6}`);
import requestsurl ="https://go.getblock.io/<YOUR-ACCESS-TOKEN>/"# Get latest blockresponse = requests.post(f"{url}wallet/getnowblock")block = response.json()print(f"Block: {block['block_header']['raw_data']['number']}# Get account inforesponse = requests.post(f"{url}wallet/getaccount",json={"address":"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g","visible":True})print(f"Balance: {response.json().get('balance',0)/
SUN: The Base Unit of TRX
SUN is the smallest unit of TRX, analogous to satoshi in Bitcoin or wei in Ethereum.
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
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
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:
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)
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.
Cost when burning: 1 Bandwidth = 1,000 SUN (0.001 TRX)
Cost when burning: 1 Energy = 100 SUN (0.0001 TRX)
GET https://api.trongrid.io/wallet/getchainparameters
Current rates: 1 Energy = 100 SUN (0.0001 TRX), 1 Bandwidth = 1,000 SUN (0.001 TRX)
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. It’s available for desktop, Android, and iOS.
After opening the browser, look at the wallet icon in the upper right corner. Click on it to open the Brave Wallet. Import the account using a seed phrase or create a new one.
Now, it’s time to prepare the working part: the GetBlock node.
Get a custom RPC API endpoint
Proceed to the GetBlock dashboard and create an account or log in.
Click on the Get button to add a new RPC endpoint, and select the Ethereum mainnet.
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.
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.
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.
1
Go to Brave Wallet settings
In the upper right corner of the wallet interface, click on the three-dot options () button and select Settings. Here, a list of supported networks can be found.
2
Locate the network in the list
If the network of interest is already present, such as with Ethereum, click on the three-dot options () button right of Ethereum and then select Edit to open the account settings.
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.
3
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.
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 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.
1
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.
After clicking on it, Brave fills all required fields automatically.
2
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.
Voila—the free and highly secure Polygon zkEVM node endpoint is ready.
3
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.
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.
As with GetBlock’s Ethereum node, track the compute units usage at the GetBlock dashboard.
Using custom GetBlock nodes improves the Web3 experience in many ways:
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.
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 and suggest it.
Archive data access (all plans)
Trace & Debug methods (Starter+)
WebSocket support
Multi-region (Frankfurt, New York, Singapore)
Dedicated Nodes available
Step-by-Step: Get Your Avalanche RPC Endpoint
1
Create a GetBlock Account
Go to GetBlock Dashboard and sign up. You can register with email or via Google/GitHub OAuth.
Building on Avalanche? Contact us for custom infrastructure.
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.
Reference High vs Standard tier comparison
Feature
High Performance
Standard Performance
Resource allocation
Maximum hardware and bandwidth
Balanced hardware profile
Throughput
Highest supported
High
Dedicated Node pricing
Dedicated Nodes are billed at a set monthly rate determined by configured settings:
Performance tier: Total cost scales with the performance tier selected – High tier is priced at a premium relative to the Standard tier.
Blockchain network: Each protocol has different hardware requirements, which impact both High and Standard tier pricing.
Node mode: Full or Archive.
Client parameters.
Refer to your Dashboard for up-to-date pricing details and protocol-specific options.
Dedicated Node pricing in the GetBlock Dashboard
Steps to configure dedicated node tiers
To select a tier during node setup, open the Dedicated Node dashboard:
Select protocol, network, deployment region, node mode, and a preferred client.
As a final step, choose the Performance Tier (High or Standard).
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 for tailored deployments.
Always check available configurations in your dashboard
Monthly costs are always shown during configuration in the Dashboard for each supported network and region.
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
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
Interested in building on Solana with TradeFirst? Reach us for more information.
Core Value Proposition
TradeFirst provides two-sided latency optimization for Solana trading:
Signal Detection Side: Faster awareness of on-chain events via StreamFirst (data streaming).
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
StreamFirst (Data Streaming)
Accelerated Yellowstone gRPC implementation
Optimized shred-stream network access
Fastest on-chain data delivery for signal detection
LandFirst (Multi-Path Routing)
SWQoS priority connections
Jito integration
Geo routing
Stake density topology
Leadership scheduling
Technical Architecture
How TradeFirst Works
Complete Trading Cycle:
Signal Detection: StreamFirst delivers on-chain updates 17ms faster than standard methods
Strategy Execution: Your trading logic analyzes data and generates orders
Transaction Submission: Blazar optimizes transaction structure and routing
Timing Control: SubSlot precisely times submission within the slot window
Path Selection: LandFirst routes via optimal path (SWQoS or Jito)
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:
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
Future Addition:
Shred Stream Access (coming soon): Direct raw shred delivery for even earlier data access
Description
target_address
string
Yes
TRON wallet to activate (starts with T, 34 characters)
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.
Shared Nodes operate on a system of limits defined by Compute Units (CUs) and Requests Per Second (RPS). Each plan also determines how many access tokens you can generate.
With Dedicated Nodes, you’re not limited by CUs or RPS.
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:
: 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 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.
Plan
Free
Starter
Advanced
Pro
Enterprise
To see the full comparison table, navigate to .
The plan is ideal if you’re just starting out and do not have complex calls or large request volumes.
CU: 50,000/day
Throughput: 20 requests per second (RPS)
Managing unused & extra CUs
If you don’t use all your allocated CUs within a month, the unused amount will carry over to the next month as long as your subscription isactive and renewed. If your subscription expires or is not renewed on time, the remaining CUs will be lost.
Dedicated node limits
Our Dedicated Node service is perfect for teams and projects that demand absolute freedom from rate limits and CU monitoring.
CU: Unlimited
Rate: Unlimited
If you’re unsure which plan best fits your needs, our team is ready to help! or visit our page for more information.\
delegateBandwidth - TRON energy
Example code for the delegateBandwidth JSON RPC method. Сomplete guide on how to use delegateBandwidth JSON RPC in GetBlock Web3 documentation.
This delegates bandwidth to a TRON address. Same flow as Energy — instant result in most cases.
Body Parameter
Parameter
Request Sample
Request
Response Sample
delegateEnergy - TRON energy
Example code for the delegateEnergy JSON RPC method. Сomplete guide on how to use delegateEnergy JSON RPC in GetBlock Web3 documentation.
This endpoint delegates energy to a TRON address. In most cases, the order completes immediately with status "success".
Parameter
Parameter
Request
Response
Aptos (APT)
Aptos Network API Reference for seamless interaction with APT nodes, enabling fast, secure, and scalable transactions on a next-generation Layer 1 blockchain.
Overview of Aptos Network Methods
Aptos is a Layer 1 blockchain built with the Move programming language, designed to deliver a fast, secure, scalable, and upgradeable ecosystem. With its modular architecture, Aptos enables frequent upgrades, rapid adoption of new technologies, and strong support for emerging use cases. The Aptos API provides developers with the ability to interact with the blockchain seamlessly and possibly. You can do the following with the Aptos API:
Query real-time blockchain data
Manage and monitor accounts and balances
Interact with smart contracts
Submit and track transactions
Monitor network activity in real-time
Each method will provide you with the following:
Clear description of functionality and use cases
Required input parameters
Sample requests and responses
Supported network
Note: This API is compatible only with Aptos Mainnet.
Quickstart
In this section, you will learn how to make your first call with either:
Axios
Python
Quickstart with Axios
Before you begin, you must have already installed npm or yarn on your local machine. If not, check out or .
Set up your project using this command:
For npm:
Or yarn:
This creates a project directory named aptos-api-quickstart and initialises a Node.js project within it.
Install Axios using this command:
Using npm:
Using yarn:
Create a new file and name it index.js. This is where you will make your first call.
Set ES module "type": "module" in your
Quickstart with Python and Requests
Before you begin, you must have installed Python and Pip on your local machine.
Set up your project using this command:
Set up a virtual environment to isolate dependencies:
Install the requests library:
Create a new file called and insert the following code:
Endpoint Grouping
Blockchain Information
/v1
Account-Related
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
Supported Data Streams
Yellowstone gRPC supports streaming the full range of Solana events:
Stream Type
Description
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
Getting Started
Prerequisites
To use Yellowstone gRPC on GetBlock:
A GetBlock account (sign up at )
A 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:
Additional Resources
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 or visit our .
price-estimate - TRON Energy
Example code for the price-estimate JSON RPC method. Сomplete guide on how to use price-estimate JSON RPC in GetBlock Web3 documentation.
This get a real-time price estimate for Energy delegation before placing an order.
Body Parameter
Parameter
Type
Request Sample
Response Sample
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.
By combining software-level acceleration with network-level optimization, StreamFirst enables developers to receive blockchain data faster than traditional RPC methods. This reduces the consistent polling updates, which either lead to timeouts or rate-limiting issues.
Interested in building on Solana with StreamFirst? Reach us for more information.
Core Stack
StreamFirst consists of two core optimization layers:
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.
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
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:
Block Production: Solana validators produce blocks and fragment them into "shreds."
State Reconstruction: Shreds are decoded and reassembled into transactions and account updates
Accelerated Processing: Optimized Yellowstone plugin processes data with reduced overhead
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
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
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
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
How to Get a Polygon RPC Endpoint
Step-by-step guide to getting a fast, reliable Polygon RPC endpoint.
Polygon PoS is one of the most widely used Ethereum scaling solutions, powering DeFi protocols, NFT marketplaces, gaming applications, and enterprise solutions.
Available Service on GetBlock
Archive data: query historical state at any block (all plans)
WebSocket: real-time subscriptions via wss://go.getblock.io/<TOKEN>/
Multi-region: Frankfurt, New York, Singapore
Dedicated Nodes: unlimited RPS, from $1,000/mo
This guide shows you how to get a reliable Polygon RPC endpoint — from free development access to production-grade infrastructure.
Step-by-Step: Get Your Polygon RPC Endpoint
1
Create a GetBlock Account
Go to and sign up. You can register with email or via Google/GitHub OAuth.
2
Code Example
Plans
Use Case
Plan
CU
RPS
What's Next?
Need enterprise Polygon infrastructure? .
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 for more information.
Core Technology Stack
LandFirst automatically routes transactions through three complementary delivery mechanisms:
GetBlock's Own SWQoS Connections
Direct partnerships with high-stakes Solana validators
Guaranteed priority capacity through stake-weighted allocation
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.
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
HFT & Arbitrage
Fast, reliable execution for high-frequency trading, arbitrage, market-making, and position rebalancing — especially when every millisecond counts.
MEV & Keeper / Liquidation Bots
Ensures deterministic transaction landing for backruns, front-runs, liquidation races, and other MEV or keeper-bot strategies.
NFT Sniping & High-Demand Mints
Gives an edge for time-sensitive NFT events such as limited-supply mints, snipes, and competitive auctions.
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.
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
/v1/accounts/{account_hash} - Aptos
Example code for the /v1/accounts/{account_hash} json-rpc method. Сomplete guide on how to use /v1/accounts/{account_hash} json-rpc in GetBlock.io Web3 documentation.
This endpoint retrieves account details, such as the number of transactions submitted by an account and its authentication key.
Supported Networks
Mainnet
Parameters
Parameter
Data type
Description
Required
In
Request Example
URL
Example
Response
Response Definition
Value
Type
Description
Use Cases
This method can be used for:
Wallets to fetch sequence numbers before sending transactions (to prevent replay attacks).
Creating an account overview page or profile in a dApp.
Validating if an account exists on-chain to avoid sending assets to the wrong account.
Code Examples
Python (requests)
Node.js (Axios)
Replace <ACCESS_TOKEN> with your actual access token from GetBlock.
Error Handling
You may encounter responses like:
This means the account hash is incorrect or the account does not exist on-chain at the current ledger state.
403 → Access token is missing.
Integration with Web3
By integrating /v1/accounts/{account_hash}, developers can:
Fetch sequence numbers for transaction signing.
Validate account existence and state (useful for onboarding users).
Support wallet and dApp account management.
Enable reliable transaction pipelines.
/v1 - Aptos
Example code for the /v1 JSON-RPC method. Сomplete guide on how to use /v1 json-rpc in GetBlock.io Web3 documentation.
This endpoint retrieves the latest information from the Aptos blockchain ledger, such as current chain ID, node role, latest and oldest ledger versions, epoch, block height, and more.
In short, it provides an overview of Aptos and its health status.
Supported Network
Mainnet
Parameters
None
Request
URL (endpoint)
Example (cURL)
Response
Response Definition
Value
Data type
Description
Use Case
The /v1/info endpoint is useful for checking if a node is online and responding.
For example:
Developers can verify the latest block or ledger version to ensure the node is up-to-date.
Applications can notify users about the health of the blockchain, such as showing a modal alerting them to the current state when they log in to a dApp.
Code Example (Axios)
Replace <ACCESS_TOKEN> with your actual access token from GetBlock.
Error Handling
When using this endpoint, you may encounter:
404 → Incorrect or incomplete access token.
500 → Network issues.
How to fix:
Use a stable and strong network connection.
Check or re-copy your access token.
Verify the URL to ensure it is correct and complete.
Integration
It is recommended to use this endpoint first to check the current status of the blockchain before integrating other endpoints into your application.
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 for screening wallets and smart contracts — fraud risk, AML exposure, and rug pull detection in one API.
The service runs on pure on-chain behavioral analysis — no source code review, no off-chain data — across Ethereum, BNB Smart Chain, and Base.
Choose Your Crypto Audit API:
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 , check out it , or access its
Wallet Risk
A faster, lighter check focused on a single binary outcome: is this address safe to interact with? Returns a risk score and the flags that drove it. Use this when latency matters and a full audit is more than the use case needs — payment flows, point-of-sale, real-time wallet connect.
Learn more about , check out it , or access its
Rug Pull Checker
A predictive check for smart contract and liquidity pool addresses. Analyzes the on-chain behavior of the contract creator and individual liquidity providers — tracing through intermediate contracts to the source wallet — and returns a rug pull risk score (0–100), risk level (LOW / MEDIUM / HIGH), creator trust score, per-LP trust scores, and behavioral flags. The underlying AI model is trained on 336K smart contracts.
Learn more about , check out it , or access its
How to Access
Two ways to use Crypto Address Audit, depending on the workflow.
Via the : This runs a check on the wallet/contract address through the UI. Paste an address, and run the check. No code required. Best for ad-hoc analysis, manual due diligence, and trying the service before integrating it.
— 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. .
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.
Next Step
How to Get an Arbitrum RPC Endpoint
Step-by-step guide to getting a fast, reliable Arbitrum RPC endpoint
Arbitrum One is the leading Ethereum L2 by TVL, hosting major DeFi protocols like GMX, Aave, Uniswap, and Camelot. If you're building on Arbitrum, you need a reliable RPC endpoint that can handle the network's high throughput without rate-limiting your application.
Features
EVM-compatible — use the same tools as Ethereum (ethers.js, web3.js, Hardhat, Foundry)
What Are Token Extensions
Solana Token Extensions: guide to types, use cases & why they matter for SPL tokens
The Solana Program Library (SPL) Token program defines a standard for creating, minting, transferring, and burning both fungible and non-fungible tokens, similar to the ERC-20 and ERC-721 standards in Ethereum. This program has a restricted definition, hence requiring developers to build custom code to add functionality beyond what is originally provided. This is time-consuming and difficult to achieve adoption across the ecosystem.
Solana's programming model requires that programs be included in transactions alongside accounts, making it complicated to craft transactions involving multiple token programs. Additionally, each forked version introduces unaudited code, raising security concerns.
Then comes the Token Extension (Token-2022). This is a more advanced token program that maintains the original functionalities while expanding its capacity beyond the fundamentals (e.g., token transfers, minting, etc.). The difference lies in the optional extensions you can enable to add new capabilities natively.
Applications with high transaction volumes & large user bases, mission-critical systems, and any workflow where latency and throughput are the top priority
Most production dApps, wallets, and enterprise tools or projects that need guaranteed resources but do not require the maximum performance tier
GetBlock Product Demo
Type
Required
Description
target_address
string
Yes
TRON wallet address (starts with T, 34 characters)
Clients who want to increase their usage limits can choose between the higher-tier options.
This is a monthly subscription designed for use cases that are growing beyond the free tier. It offers a significant increase in CU compared to the Free plan.
CU: 50M per month (~1.6M/day)
Throughput: 100 requests per second (RPS)
Access Tokens: 10
Additional CU packages can be purchased as needed.
The Advanced Plan is a mid-to-upper tier, production-ready plan, suitable for moderate-to-high traffic applications.
CU: 220M per month (~7.2M/day)
Throughput: 300 requests per second (RPS)
Access Tokens: 25
Add extra compute units (CU) to your account balance when needed without switching plans
The Pro Plan is built for applications that need significantly higher throughput and increased resource availability compared to lower tier plans.
CU: 600M per month (~20M/day)
Throughput: 500 requests per second (RPS)
Access Tokens: 50
Purchase additional CU packages when required
The Enterprise plan is fully customizable with tailored CU allocations, rate limits, and access tokens to meet exceptionally high call volumes and performance requirements.
CU: Custom monthly allocation based on your demands
Throughput: Custom
Access Tokens: Custom
Additional CU packages can be purchased on demand
Price/month
$0
$49
$199
$499
Your balance of CUs for Shared Nodes is distributed on all endpoints added under the ‘Shared nodes’ tab.
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.
Building DeFi on Arbitrum? Talk to us about enterprise-grade infrastructure.
Arbitrum mainnet Dedicated Nodes may have custom pricing due to higher infrastructure requirements. for details.
Why Token Extensions Matter
Token Extensions address a growing need: permissioned tokens on a permissionless network. This makes Solana viable for:
Institutional adoption – Banks, asset managers, and regulated entities (e.g., Paxos with USDP) can issue compliant tokens with built-in controls like clawback capabilities and KYC-gated transfers
Real-World Asset (RWA) tokenization – Securities, bonds, and other regulated assets require features like transfer restrictions and mandatory compliance checks
Creator economies – NFT royalties, transfer taxes, and holder rewards can be enforced at the protocol level rather than relying on marketplace cooperation
Available Extensions
Token Extensions are divided into two categories:
Mint Extensions (Applied to Token Mints)
Extension
Description
Potential Use Cases
Real-World Example
Confidential Transfers
Protects the confidentiality of user balances within a transfer, as well as hiding transaction amounts
It sends a JSON-RPC request to an Ethereum node through an RPC endpoint. The node processes the request and returns the data.
For example:
Step-by-Step: Get Your Ethereum RPC Endpoint
1
Create a GetBlock Account
Go to and sign up. You can register with email or via Google/GitHub OAuth.
2
Using Your Endpoint with Popular Libraries
WebSocket Endpoint for Real-Time Data
For real-time events (new blocks, pending transactions, log subscriptions), use a WebSocket connection:
WebSocket endpoint format:
Subscribe to new blocks
Ethereum Testnet Endpoints
For development and testing, use testnet endpoints. GetBlock supports:
Testnet
Purpose
How to Get Tokens
Archive Data Access
Need to query the historical state at any past block? Enable archive mode on your endpoint.
Archive data lets you:
Call eth_getBalance at any historical block
Execute eth_call against old contract state
Run debug_traceTransaction for any past transaction
Archive mode is available on all paid plans and Dedicated Nodes.
Example — get balance at a specific historical block:
What's Next?
Need help choosing the right setup for your Ethereum project? , and we'll help you find the best configuration.
How to Get a TON RPC Endpoint
Step-by-step guide to getting a fast, reliable TON RPC endpoint
The Open Network (TON) has become the leading blockchain for Telegram-integrated applications, mini-apps, and payments. With TON's unique architecture (TVM, not EVM) and the massive Telegram user base, demand for reliable TON RPC access is growing fast. Here's how to set up a TON endpoint with GetBlock.
TON's API is Different from EVM Chains
TON uses its own HTTP API — not the JSON-RPC standard used by Ethereum and EVM chains. TON API methods include:
getAddressInformation — get account balance and state
getTransactions — fetch transaction history
detectAddress — normalize address formats
estimateFee — estimate transaction cost
sendBoc — submit transactions
Step-by-Step: Get Your TON RPC Endpoint
1
Create a GetBlock Account
Go to and sign up. You can register with email or via Google/GitHub OAuth.
2
Code Example
Why GetBlock for TON?
Reliable infrastructure — 99.9%+ uptime vs unreliable public endpoints
No rate limiting drama — up to 500 RPS vs public endpoint throttling
Global reach — Frankfurt, New York, Singapore
Plans
Use Case
Plan
CU
RPS
What's Next?
Building a Telegram Mini App at scale? for custom TON infrastructure.
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
https://services.getblock.io/v1
Authentication
All requests require an API key in the header:
How to Get Address Audit API Key
Go to your
Click on the product icon on the Navbar
Scroll down and Select Address Audit
After that, select the API key tab
On the API Key tab, click on the plus icon, and your API key will be generated for you automatically
QuickStart
In this example, you will be auditing a wallet address:
Axios (JavaScript / Node.js)
Python (Requests library)
Before you begin, you must have already installed or on your local machine (for the Axios example) or Python and pip (for the Python example).
1
Setup project
Create and initialize a new project:
2
Next Step
How to Get a Base RPC Endpoint
Step-by-step guide to getting a fast, reliable Base RPC endpoint
Base has become one of the most active Ethereum Layer 2 networks for DeFi, social apps, and onchain consumer products.
If you're building on Base for the first time or scaling a production application, this guide gets you set up with a reliable RPC endpoint in minutes.
Step-by-Step: Get Your Base RPC Endpoint
1
Create a GetBlock Account
Go to and sign up. You can register with email or via Google/GitHub OAuth.
2
Create an Avalanche Endpoint
Once logged in:
Click "Shared Nodes" in the left sidebar
3
Copy Your Endpoint URL
Your endpoint URL looks like this:
4
Test the Connection
Code Examples
How to Connect MetaMask to Base via GetBlock
MetaMask → Add Network → Add manually
Enter:
Network Name: Base Mainnet (GetBlock)
Base Sepolia Testnet:
Chain ID: 84532
Explorer: https://sepolia.basescan.org
Why a Dedicated RPC Provider For Base?
Base inherits Ethereum's security while offering:
Low gas fees (~$0.01 per transaction)
EVM compatibility — deploy existing Solidity contracts without changes
Coinbase ecosystem — seamless fiat on-ramp integration
But Base's popularity means public RPC endpoints are frequently congested. A dedicated provider like GetBlock gives you consistent performance with up to 500 RPS and 99.9%+ uptime.
Base Flashblocks Support
Base introduced Flashblocks — a mechanism for pre-confirmation of transactions at sub-second speeds. GetBlock supports Flashblocks, enabling your application to react to transactions inclusions faster than waiting for full block confirmation.
Choosing Your Plan
Use Case
Plan
Why
What's Next?
Scaling on Base? for dedicated infrastructure with custom performance tuning.
Overview
GetBlock API docs: RPC endpoints, SDK guides, and developer tools. Everything you need to connect and build on 100+ blockchain networks
Getting Started with GetBlock
To get started, follow these steps:
Sign up: Create an account to access your Access Token.
Generate access token: Navigate to the dashboard, and generate your first access token for API authentication.
Choose the blockchain name and type: Select the blockchain network you want to interact with, set up testnet/mainnet, and choose the interface you’re going to use.
Send your first request:
Key Features of GetBlock
GetBlock is offering one of the most comprehensive APIs toolkits in the segment supporting hundreds of dApps with fast and reliable connection to blockchain nodes.
100+ blockchains in store
Seamless connection to full and archive nodes
Shared and dedicated nodes: Tailored for your dApp’s needs.
Programmable and non-programmable blockchains
L1 and L2 protocols
See full list:
All mainstream RPC interfaces
WebSockets
JSON RPC
GraphQL
REST API
Add them in Lego-like manner:
Industry-leading suite of add-ons and ready-made APIs
DAS API
Firehose
Blockbook
Yellowstone Geyser
Need more? Don’t hesitate to contact sales:
Examples for Console REST API Requests
cURL
Most *nix-based systems come with cURL pre-installed. cURL is a command-line tool and library for transferring data with URLs. To check if cURL is installed, run the following command:
Example of requesting the latest block number using the GetBlock API and cURL:
Python
To run Python examples, ensure Python is installed along with the requests package. You can install the package using the following command:
Example:
JavaScript
For JavaScript examples, you'll need Node.js version 18 or later. Follow the official documentation to install the latest stable version globally. Verify your installation by running:
Ruby
To execute Ruby examples, install Ruby on your machine. Refer to the official installation guide for details. Confirm installation by running:
Supported networks
We provide APIs for a wide range of networks, including:
Example code for the /v1/accounts/{account_hash}/events/{event_handle}/{field_name} JSON-RPC method. Сomplete guide on how to use /v1/accounts/{account_hash}/events/{event_handle}/{field_name} json-rp
This endpoint retrieves events for a given account using an event handle struct and a field name within that struct. It allows more precise event queries compared to using only the creation number.
Supported Network
- Mainnet
Parameters
Parameter
Data type
Description
Required
In
Request Example
Base URL
Example (cURL)
Response Example
Response Parameters
Field
Type
Description
Use Cases
This endpoint can be used to:
Query specific event handles such as deposit_events or withdraw_events.
Display transaction logs tied to particular smart contracts or account resources.
Track contract-specific activity within dApps for analytics or notifications.
Code Examples
Python (requests)
Node.js (Axios)
Replace <ACCESS_TOKEN> with your actual GetBlock API token.
Error Handling
Status Code
Error Message
Cause
Integration with Web3
By integrating /v1/accounts/{account_hash}/events/{event_handle}/{field_name}, developers can:
Track token-specific events like deposits, withdrawals, mints, or burns.
Enable in-wallet notifications (e.g., “You received 250 APT”).
Monitor DeFi or NFT protocol activity by subscribing to contract events.
Enhance analytics dashboards by focusing on targeted on-chain event streams.
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 workspacewhere 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.
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:
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.
Contract Details: verification of basic contract properties (open source, proxy, self-destruct, withdrawal rights, blacklist). Does not affect the Rug Pull Probability.
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 Risk Check provides a quick go/no-go signal e.g "Can this wallet be trusted?"
What Wallet Risk Does?
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.
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.
Example code for the /v1/accounts/{account_hash}/events/{creation_number} JSON-RPC method. Сomplete guide on how to use /v1/accounts/{account_hash}/events/{creation_number} json-rpc in GetBlock.io Web
This endpoint retrieves events for a given account based on the creation number of the event handle. Events are emitted during transactions and serve as logs of on-chain actions such as token transfers, deposits, or contract interactions.
Example code for the /v1/accounts/{account_hash}/module/{module_name} JSON-RPC method. Сomplete guide on how to use /v1/accounts/{account_hash}/module/{module_name}json-rpc in GetBlock.io Web3 documen
This endpoint fetches detailed information about a single smart contract (module) deployed under a specific Aptos account. The response contains the module's bytecode and ABI, providing a complete description of its functions, structs, and on-chain logic.
Supported Network
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.
Non-Transferable + Transfer Hooks: If tokens can't transfer, a hook has no work to do
Non-Transferable + Transfer Fees: No transfers means no fees to collect
Confidential Transfers + Transfer Hooks: Hooks need to read transfer amounts, but confidential transfers encrypt them
importTonWebfrom"tonweb";consttonweb=newTonWeb(newTonWeb.HttpProvider("https://go.getblock.io/<YOUR-ACCESS-TOKEN>/"));// Get balanceconstbalance=awaittonweb.getBalance("EQDtFpEwcFAEcRe5mLVh2N6C0x-_hJEM7W61_JLnSF74p4q2");console.log(`Balance: ${TonWeb.utils.fromNano(balance)} TON`);
import{JsonRpcProvider,formatEther}from"ethers";constprovider=newJsonRpcProvider("https://go.getblock.io/<YOUR-ACCESS-TOKEN>/");constblockNumber=awaitprovider.getBlockNumber();console.log("Latest Base block:",blockNumber);constbalance=awaitprovider.getBalance("0xYOUR_ADDRESS");console.log(`Balance: ${formatEther(balance)} ETH`);
from web3 import Web3w3 =Web3(Web3.HTTPProvider("https://go.getblock.io/<YOUR-ACCESS-TOKEN>/"))print("Chain ID:", w3.eth.chain_id)# 8453print("Latest block:", w3.eth.block_number)
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.
Sign in to your GetBlock account. If you don’t have a user account yet, create one following this guide.
Click on the profile icon in the bottom-left corner of the sidebar. Select "Create new team" from the dropdown menu.
A popup window will appear. Assign a team name and click the "Create team" button.
Once the space is created, navigate to Account Settings > Team to manage team settings or add teammates.
Adding teammates
The creator of the team account controls who gets invited and manages user roles.
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.
Go to Account Settings > Team.
Click "Add team member" in the top-right corner.
Request the User ID from the teammate (they can find it under Account Settings > General).
Enter the name, User ID, and send the invite.
The user gets a notification and can accept the invite.
Go to Account Settings > My Team.
Click "Add team member" in the top-right corner.
Enter the teammate's name and email address.
A team member is marked as when they have successfully accepted the invitation and joined the team.
If the invitation has been sent but not yet accepted, their status remains .
Managing roles & permissions
Once the user has joined, the team owner or an admin can update their permissions:
Go to My Team in Account Settings.
Click the three-dot menu (⋮) next to a team member.
Select "Edit access level".
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.
Save changes.
Roles-based permissions
This table provides a breakdown of actions team account users can perform based on their role.
Action
Owner
Admin
Member
Create & manage access tokens
✅
✅
🔓
Manage subscriptions & payments
✅
Revoking team access
To remove a user from your team account:
Navigate to Team in the Account Settings.
Click the three-dot menu (⋮) next to the team member name.
Select "Remove" from the dropdown menu.
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.
When you have a pending team invitation, a notification badge appears on your account icon .
Click your account icon to view an invitation.
Click "Accept" if you're ready to join.
After accepting the invitation, you are given access to your team’s workspace. Your will be determined by the team owner or admin.
When someone who is not yet registered on GetBlock receives a team invitation, they must first sign up for an account:
Check your inbox for an email invitation from GetBlock.
Clicking the invitation link redirects you to the sign-up page.
Create a secure password for your new account.
Switching between personal & team accounts
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.
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 or visit our Contact Center. You can also use the Help button within your GetBlock dashboard to access support or submit a request.
Limits on GetBlock team accounts:
Each user can create up to 3 teams.
A user can be invited to an unlimited number of teams
If a Member has no permissions assigned, they will have View-Only access by default.
If you need someone to help manage other team members, be sure to give them Admin status.
When removed from a team, users lose access to that team workspace but keep their personal account.
A team user does not lose access to their personal account. They can still use and manage their own endpoints and subscriptions.
Difference Between Rug Pull Checker And Wallet Audit
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.
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
Supported Networks
Ethereum
BNB Smart Chain
Base
How Rug Pull Probability Is Calculated
There are four steps involved, which are:
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.
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.
Analyze the liquidity providers (LPs): run each LP through the Fraud Detector and obtain the Trust Score for each LP.
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)
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.
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.
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.
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.
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.
Need a custom setup (higher rate limits, dedicated infrastructure, SLA, or volume pricing)? .
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
Wallet Risk Check
Wallet Audit
Response time
< 100ms
Several seconds
Trust Score
Yes
Yes
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%
Select the choice of your network using the dropdown:
Enter the wallet address:
Click on Run Check:
Scroll down to see the analysis:
This report includes the following:
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
AML Analysis: This shows 18 risk categories with each parameter displayed as No (clean) or Yes (flag detected).
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.
If you want to interact with or integrate this service via API, check the Wallet risk endpoint.
The service only works with regular wallets (EOA — Externally Owned Accounts). Contract addresses are not supported.
Need a custom setup (higher rate limits, dedicated infrastructure, SLA, or volume pricing)? .
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.
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.
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.
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
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.
Example:
Investor A: Wallet Rank in top 10K, Experience = 9, Risk Capability = 7, Intentions: Staking = HIGH → long-term holder, priority allocation
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.
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
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
i. Risk Willingness: This measures psychological willingness to take risks. Determined by on-chain behavior: leverage usage, volatile assets, experimental protocols.
ii. Experience Level: This measures the depth and duration of Web3 activity: number of protocols, activity duration, transaction complexity, and multi-chain activity.
iii. Risk Capability: This measures financial ability to withstand losses, weighted by behavioral risk appetite.
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.
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.
Predicted trust score: The main safety indicator — the probability that the wallet is legitimate. Displayed as a percentage from 0% to 100%.
If you want to interact with or integrate this service via API, check the Wallet audit endpoint.
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.
Limitations
The service only works with regular wallets (EOA — Externally Owned Accounts). Contract addresses are not supported.
Need a custom setup (higher rate limits, dedicated infrastructure, SLA, or volume pricing)? .
Parameters
Parameter
Data type
Description
Required
In
account_hash
string
Aptos account address.
Yes
Path
Request
Base URL
Request Example (cURL)
Response
Response Parameter Definition
Field
Type
Description
version
string
Ledger version number at which the event was recorded.
guid
object
Globally unique identifier (GUID) for the event.
Use Cases
This method can be used for:
Tracking account-level activity logs such as deposits, withdrawals, and transfers.
Building blockchain explorers that display historical event data.
Monitoring DeFi or NFT protocols that emit custom contract events.
Triggering real-time alerts when specific on-chain events occur.
Code Examples
Node.js (Axios)
Python (Request)
Replace <ACCESS_TOKEN> with your actual GetBlock access token.
Error Handling
Status Code
Error Message
Cause
400
Invalid account address
The provided account_hash is invalid.
401
Unauthorized
Missing or invalid <ACCESS_TOKEN>.
Integration with Web3
By integrating /v1/accounts/{account_hash}/events/{creation_number}, developers can:
Optimise event tracking for NFT, DeFi, and gaming applications.
Build real-time activity feeds from on-chain actions.
Map blockchain transactions into user-friendly notifications.
Support advanced analytics for blockchain event visualisation.
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
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
Each endpoint in “My endpoints” list shows its current subscription status.
Subscription status breakdown
Status
Dashboard View
Manage Plans View
Active
(Recurring Payment)
Active
(One-Time Payment)
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 card.
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
Go to Dedicated Nodes tab from your dashboard. Look for the subscription alert widget.
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).
Choose a new period and review details. Proceed to checkout.
Complete the payment by following the instructions provided.
Check the "Payment History" under the Pricing tab to track the progress.
Video guide
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.
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.
Option 2: From “Endpoints” list
Navigate to your main dashboard and switch to the Dedicated Nodes tab.
Choose a node to extend. Expand the node’s details and click "Extend" to begin the process.
Follow the pop-up instructions to select the new subscription period and finalize the process.
Option 3: Via the "Manage Plans" menu
Navigate to Pricing > Manage Plans.
Review all subscriptions. Subscriptions nearing expiration are listed at the top.
Follow the same steps: Select your node, choose a new period, and confirm your payment.
How to keep your Dedicated Node running smoothly
If you face any issues with renewal or extensions, feel free to reach out to GetBlock support—we’re happy to assist.
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.
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.
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.
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
This model ensures costs are aligned with actual infrastructure usage.
How CUs are calculated
Every API call "spends" a number of Compute Units. The total value is determined by three main factors:
Base CU cost (chain multiplier) reflecting the network's resource intensity
Method-specific multiplier which varies by API method
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:
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:
Chains
Multiplier
Explanation
2. Method-specific multipliers
Different API methods put different loads on backend nodes. For example:
eth_blockNumber is lightweight since it just returns the latest block number.
trace_replayBlockTransactions 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.
Ethereum RPC Method
Method Multiplier
Base Chain Multiplier
Total CU
Calculation example for debug_traceTransaction:
For full details on all methods - including exact multipliers and total CU values for each protocol - please refer to our .
3. Archive modifier
GetBlock Shared Node endpoints can be configured in to provide historical state access from managed archive nodes.
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.
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 help 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.
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.
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:
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
Example
1
Set up the project
2
Create a new file named index.js. This is where you will make your first call.
3
Extension sample
You can extend this code for a DEX swap by encoding the router call and including it as the second Multicall3 call:
Troubleshooting
Problem
Solution
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.
How to Listen to High-Value SOL Transactions via Yellowstone Geyser gRPC with GetBlock
How to Build an App to Track Large Solana Transactions with GetBlock Yellowstone Geyer gRPC
Monitoring high-value SOL transactions is essential for understanding the dynamics of the Solana network. By using tools like Yellowstone Geyser gRPC with GetBlock, developers can gain real-time insights into significant financial movements, enabling them to make informed decisions and capitalize on trends within the Solana ecosystem.
In this tutorial, you'll build a monitoring app that detects high-value SOL transfers the moment they occur on the Solana blockchain.
You'll learn how to:
Connect to GetBlock's Yellowstone gRPC service for ultra-low latency blockchain data streaming
Subscribe to Solana's System Program to capture all native SOL transfers
Parse transfer instruction data to extract amounts, sender addresses, and recipient addresses
Filter transactions based on transfer amount thresholds
Display real-time alerts with formatted output and explorer links
Track statistics, including total volume and largest transfers
Technology Stack:
Node.js
- Official Yellowstone gRPC client
- Base58 encoding for Solana addresses
GetBlock's Dedicated Solana Node with Yellowstone add-on
Prerequisites
Before you begin, ensure you have:
Node.js v18 or higher is installed on your system
Basic JavaScript knowledge
A GetBlock account - Free sign-up available at getblock.io
A Dedicated Solana Node subscription on GetBlock - Required for Yellowstone gRPC access
Step 1: Set Up Your GetBlock Yellowstone Endpoint
Deploy Your Dedicated Solana Node
First, you need to deploy a dedicated Solana node on GetBlock with the Yellowstone gRPC add-on enabled.
1. Sign up or log in
Go to GetBlock
Create an account or log in to your existing account
2. Deploy your dedicated node
Navigate to your user Dashboard
Switch to the "Dedicated nodes" tab
Scroll down to "My endpoints."
3. Enable the Yellowstone gRPC add-on
In Step 3 of your node setup (Select API and Add-ons)
Check the box for Yellowstone gRPC under Add-ons
Complete payout and finalize the setup
Generate Your gRPC Access Token
Once your node is live, you'll create an access token to authenticate your gRPC connections.
1. Return to your dashboard
Go to "My endpoints" in your Dedicated node dashboard and generate a gRPC Access Token
2. Your endpoint URL
You'll receive an HTTPS-style gRPC endpoint URL based on your chosen region:
Step 2: Initialize Your Project
Open your terminal and create a new directory:
Initialize Node.js Project
Install the required packages:
Create a new file:
Configure package.json:
"type": "module" - Enables ES6 import/export syntax (required for modern JavaScript)
"main": "sol-transfer-monitor.js" - Specifies the entry point of your application
"scripts" - Defines shortcuts like npm start
Project Structure
Create the following files to have a basic structure for your project:
Create a .gitignore file:
Step 3: Start Building Your Monitor
Import Dependencies
What this does:
Client - The main class for establishing a connection to GetBlock's Yellowstone gRPC service
CommitmentLevel- Configuration options that determine how finalized transactions should be before you receive them (PROCESSED = fastest but can be rolled back, CONFIRMED = balanced, FINALIZED = slowest but guaranteed)
bs58
Add Your GetBlock Configuration
What this does: Stores your GetBlock credentials for authenticating your connection.
Add Solana System Program Constants
What this does:
SYSTEM_PROGRAM - This is the unique identifier for Solana's built-in System Program, which is responsible for all native SOL transfers on the network. Every time someone sends SOL from one wallet to another, this program processes it.
MIN_TRANSFER_AMOUNT - Sets the threshold for what qualifies as a "high-value" transfer. Only transfers of 100 SOL or more will trigger an alert. You can adjust this to any amount (e.g., 50 SOL, 1000 SOL, etc.).
Add Statistics Tracker
What this does:
Creates an object to track key metrics about the transfers you're monitoring. It records:
When the monitor started
How many high-value transfers have been detected
Step 4: Build Utility Functions
Now you'll add helper functions to format data and display results.
Add SOL Formatter
What this does:
Converts lamports (Solana's smallest unit) to SOL for human-readable display. Solana stores all amounts in lamports, where 1 SOL equals 1 billion lamports (similar to how 1 Bitcoin = 100 million satoshis). This function divides by 1 billion and rounds to 4 decimal places, so 5,500,000,000 lamports becomes "5.5000 SOL".
Add Display Function
What this does:
Formats and displays all transfer information clearly. It first updates your running statistics (incrementing the transfer count, adding to total volume, and checking if this is the largest transfer seen).
Then it converts the amount from lamports to SOL and prints out all the details, including sender, recipient, transaction signature, and slot number.
Finally, it includes clickable Solscan explorer links so you can investigate the transaction, sender, and recipient in more detail.
Step 5: Build the Transfer Parser
Now you'll create the function that extracts transfer details from instruction data.
Add Transfer Instruction Parser
What this does:
Extracts the transfer amount and account addresses from a System Program instruction.
Step 6: Build the Main Monitor Function
Now you'll create the core function that connects to GetBlock and processes blockchain data.
Part A: Start the Function and Connect
What this does:
Initializes the monitor by displaying startup information and establishing a connection to GetBlock.
Creates a new Client instance using your endpoint and token, then opens a bidirectional streaming connection.
The subscribe() method returns a stream object that handles both sending requests to GetBlock and receiving blockchain data.
Part B: Configure Subscription
What this does:
Builds the subscription request that tells GetBlock exactly what blockchain data you want to receive.
It filters sol_transfers
Send transactions that interact with the system
Part C: Handle Incoming Data
What this does:
Sets up an event handler that processes every message GetBlock sends through the stream.
Part D: Process Instructions
What this does:
Loops through each instruction in the transaction to find and process SOL transfers.
Part E: Handle Stream Events
What this does:
Sets up handlers for stream connection issues.
If the stream encounters an error (network problem, authentication issue, etc.), it logs the error message and rejects the Promise, which will trigger the auto-restart logic in the main() function.
The "end" and "close" events indicate the stream has been terminated gracefully, so it resolves the Promise normally.
Part F: Send Subscription Request
What this does:
Send your subscription request to GetBlock to activate the stream.
Once the request is sent successfully, it confirms that monitoring is active.
The callback function checks if there was an error sending the request - if so, it rejects the Promise; otherwise, it displays a success message. This completes the monitorHighValueTransfers() function.
Step 7: Add Execution Code
Finally, add the code to run your monitor and handle shutdown.
Add Main Execution Function
What this does:
Wraps your monitor in an auto-restart loop. If the monitor crashes for any reason (network disconnection, API error, unexpected data format), it catches the error, displays an error message, waits 5 seconds, and then automatically restarts the monitor. This ensures your monitor keeps running even if temporary issues occur.
Add Shutdown Handler
What this does:
Handles shutdown when you press Ctrl+C or cmd+C. Instead of abruptly terminating, it displays a summary of your monitoring session, including total transfers detected, cumulative volume, the largest transfer amount with a link to view it, and how long the monitor was running. Then it cleanly exits the process.
Start the Monitor
What this does:
Run everything. This is the last line of your sol-transfer-monitor.js file and triggers the execution of your monitor.
TestStep 8: Tets Your Monitor
1. Start the Monitor
Expected Output:
Troubleshooting
Permission denied:
This means that your access token is missing or incomplete, or you are using the wrong Base URL.
2. No Transfers Showing
High-value transfers (100+ SOL) are less common than you might expect
Try lowering MIN_TRANSFER_AMOUNT to 10 or 50 SOL to see more activity
Use CommitmentLevel.PROCESSED for faster updates (though some may be rolled back)
Conclusion
In this guide, you've learnt how to build a monitor app that tracks high-value SOL transactions on Solana networks. It shows you the steps involved, such as:
Example code for the /v1/accounts/{account_hash}/resource/{resource_type} JSON-RPC method. Сomplete guide on how to use /v1/accounts/{account_hash}/resource/{resource_type} json-rpc in GetBlock.io Web
This endpoint gets an individual resource from a given account and at a specific ledger version. This is more specific than /resources since it targets one resource type directly.
Supported Networks
Mainnet
Parameters
Request Example
Base URL
Example(cURL)
Response
Response Parameter Definition
Value
Data type
Description
Use Cases
This method can be used to:
Fetch a specific token balance without retrieving all account resources.
Query a single resource type (like a staking pool or NFT ownership).
Used in wallets and DeFi apps where targeted resource data is required.
Code Examples
Python (Requests)
Node(Axios)
Error handling
The possible error you may experience includes the following:
Integration with Web3
By integrating /v1/accounts/{account_hash}/resource/{resource_type, developers can:
Query a single CoinStore to show token balances in wallets.
Validate a user’s participation in staking, liquidity pools, or governance.
Reduce bandwidth by fetching only the resource you need, instead of all resources.
How to Get a BNB Smart Chain (BSC) RPC Endpoint
Step-by-step guide to getting a fast, reliableBSC RPC endpoint
BNB Smart Chain remains one of the most active blockchains for DeFi, trading bots, and dApp development. With block times under 3 seconds and significantly lower gas fees than Ethereum, BSC handles massive transaction volumes, and your RPC infrastructure needs to keep pace.
This guide walks you through setting up BSC RPC access with GetBlock, from free development endpoints to Accelerated Dedicated Nodes with private mempool support.
Step-by-Step: Get Your BSC RPC Endpoint
1
creation_number
integer
The creation number of the event handle to be retrieved.
Yes
Path
start
string
Starting point or offset for retrieving events. Defaults to showing the latest transactions if omitted.
No
Query
limit
integer
Maximum number of events to retrieve per request. Defaults to the standard page size if not provided.
No
Query
guid.creation_number
string
Creation number assigned to this event stream within the account.
guid.account_address
string
Address of the account that owns this event handle.
sequence_number
string
Sequential index of this event in the event stream.
type
string
Fully qualified event type (e.g., 0x1::account::WithdrawEvent).
data
object
Additional data payload associated with the event (depends on event type).
404
Event stream not found
No event stream exists for the given creation_number.
422
Invalid creation number
Malformed or unsupported creation number format.
500
Internal server error
Node or network failure while retrieving events.
module_name
string
The name of the smart contract module.
Yes
Path
ledger_version
string
The ledger version to retrieve the module state. Optional parameter.
No
Query
abi.address
string
Account address where the module is deployed.
abi.name
string
Name of the module.
abi.exposed_functions
array
List of public functions, including parameters, return types, and visibility.
abi.structs
array
Struct definitions with fields and type information.
500
Internal server error
Node or network issue. Retry the request later.
\
-H"Content-Type: application/json"\
-d'{
"jsonrpc": "2.0",
"method": "eth_blockNumber",
"params": [],
"id": "getblock.io"
}'
"id":"getblock.io",
"result":"0x134A5B2"
}
// The result field contains the latest block number in hexadecimal.
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
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
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%
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.
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.
Recommendations: These show activities based on the wallet's risk profile. Examples: WBTC holding, ETH holding, Stablecoin lending.
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.
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.
AML Analysis: This shows wallet check across 18+ parameters for links to criminal activity. Each parameter is displayed as Yes or No.
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
- A library that converts Solana's binary address format into the human-readable base58 strings you see on blockchain explorers (like "9wFFyRfZBsuAha4YcuxcXLKwMxJR...")
config: This loads the .env file
the cumulative volume of all transfers
information about the largest transfer seen so far.
Only receive transactions that are CONFIRMED
Filters by minimum transfer threshold
Displays formatted results with links
Tracks cumulative statistics
Handles errors and auto-reconnects
Save both pieces of information:
Base Endpoint: https://go.getblock.io (or your region)
Access Token: The alphanumeric token generated
You'll use these in your code to authenticate with GetBlock's Yellowstone service.
You'll build everything in a single file called sol-transfer-monitor.js.
If you chose a different region during setup, use that base URL instead (e.g., https://go.getblock.us or https://go.getblock.asia).
If anything goes wrong during parsing (malformed data, missing accounts, etc.), it catches the error and returns null.
import Client from "@triton-one/yellowstone-grpc";
import { CommitmentLevel } from "@triton-one/yellowstone-grpc";
import bs58 from "bs58";
import { config } from "dotenv";
config();
const ENDPOINT = "https://go.getblock.io"; // Your region's endpoint
const TOKEN = process.env.GETBLOCK_TOKEN; // Your generated token
// System Program (handles all native SOL transfers)
const SYSTEM_PROGRAM = "11111111111111111111111111111111";
// Minimum transfer amount in SOL to alert on
const MIN_TRANSFER_AMOUNT = 100; // 100 SOL threshold
function parseTransferInstruction(instruction, accountKeys) {
try {
const data = Buffer.from(instruction.data);
// System program transfer instruction has type 2
// Data format: [4 bytes: instruction type (2)][8 bytes: lamports amount]
if (data.length < 12) return null;
const instructionType = data.readUInt32LE(0);
if (instructionType !== 2) return null; // Not a transfer instruction
const lamports = data.readBigUInt64LE(4);
// Get from and to accounts
const accountIndices = Array.from(instruction.accounts);
if (accountIndices.length < 2) return null;
const fromAccount = bs58.encode(Buffer.from(accountKeys[accountIndices[0]]));
const toAccount = bs58.encode(Buffer.from(accountKeys[accountIndices[1]]));
return {
amount: Number(lamports),
from: fromAccount,
to: toAccount
};
} catch (error) {
return null;
}
}
async function monitorHighValueTransfers() {
console.log("Starting High Value SOL Transfer Monitor");
console.log(`Minimum amount: ${MIN_TRANSFER_AMOUNT} SOL`);
console.log(`Watching: Native SOL transfers\n`);
console.log("Waiting for high value transfers...\n");
return new Promise(async (resolve, reject) => {
try {
const client = new Client(ENDPOINT, TOKEN, undefined);
const stream = await client.subscribe();
> [email protected] start
> node sol-transfer-monitor.js
[[email protected]] injecting env (1) from .env -- tip: ⚙️ load multiple .env files with { path: ['.env.local', '.env'] }
Starting High Value SOL Transfer Monitor
Minimum amount: 100 SOL
Watching: Native SOL transfers
Waiting for high value transfers...
Subscription active - monitoring blockchain...
================================================================================
HIGH VALUE TRANSFER #1
================================================================================
AMOUNT: 1990.0000 SOL
FROM: 5tzFkiKscXHK5ZXCGbXZxdw7gTjjD1mBwuoFbhUvuAi9
TO: 53AXjkQHZQEbHZvV55VHtcZtFzBzArLZZG5AF4ufkRhv
SIGNATURE: 4uJgnfRohiq6c9CDWUtk3w94ouYGya5dGkx4LSS5tuFGDRypuXtN7cQLLy3eNj5V1b5PwEWccJqLak1Rnd9kRtTB
SLOT: 382899112
EXPLORE:
TX: https://solscan.io/tx/4uJgnfRohiq6c9CDWUtk3w94ouYGya5dGkx4LSS5tuFGDRypuXtN7cQLLy3eNj5V1b5PwEWccJqLak1Rnd9kRtTB
From: https://solscan.io/account/5tzFkiKscXHK5ZXCGbXZxdw7gTjjD1mBwuoFbhUvuAi9
To: https://solscan.io/account/53AXjkQHZQEbHZvV55VHtcZtFzBzArLZZG5AF4ufkRhv
================================================================================
^C
Shutting down...
Total high value transfers: 7
Total volume: 5519.0244 SOL
Largest transfer: 2272.0770 SOL
Largest TX: https://solscan.io/tx/3p92tKFb4AGRUJKA87vJD4fYcb3Z9wKi5AuUskA6TAR5SYciZxL3qmSH88ubQP3g7xSJQjC5kEeMSr7Lhhn8Hkc4
Uptime: 1m 50s
The user will receive an invitation email with a link to sign up and join the team.
Check the boxes to agree to the Terms of Service and Privacy Policy and complete the registration.
Once registered, you’ll have your personal GetBlock account. Additionally, you gain access to the team’s dashboard and resources based on permissions given by the team owner or admin.
Need high-performance BSC infrastructure for trading or DeFi? Contact us to discuss Accelerated Dedicated Nodes with private mempool and bundle support.
Expiring Soon
(One-Time Payment)
In Grace Period
(Recurring /One-Time)
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
Request Example
Response Example
Response Parameters
Error Handling
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:
How to Create Tokens With Metadata On Solana Using Token-2022
Create Solana SPL tokens with metadata using Token-2022 program — developer guide
Now that you have learnt about , in this guide, you will be learning how to create a simple token with metadata extension
Prerequistics
Before you begin, ensure you have the following:
How to Build a Solana AI Agent
Learn how to build an AI agent that swap token, checks balance and transfers on Solana
AI agents are autonomous systems that perform operations or tasks without human intervention. These agents act independently, as set up by users. For example, if you set up your agent to send a reminder or a report to your friend, this agent will perform the task on your behalf without your friend knowing that the action was performed by itself.
Create a new file index.js . This will serve as your working file
2
Import all the dependencies:
import {
Keypair,
SystemProgram,
Transaction,
sendAndConfirmTransaction }
from "@solana/web3.js";
import { TOKEN_2022_PROGRAM_ID,
ExtensionType,
createInitializeMintInstruction,
createInitializeMetadataPointerInstruction,
getMintLen,
TYPE_SIZE,
LENGTH_SIZE }
from "@solana/spl-token";
import { createInitializeInstruction, pack } from "@solana/spl-token-metadata";
import { connection, payer } from "./config.js";
3
Generate an account for the mint address
4
Define the token metadata:
5
Calculate the metadata space and rent needed for the mint account:
This ensures our token mint account has sufficient space for the extensions you use or else the metadata initialization would fail with an insufficient lamports error.
6
Define the structure of the transaction:
This creates the mint address, initializes the mint, metadata, points to the mint itself as the metadata account, and sends the transaction.
Complete code
7
Run the code using this command:
8
Result:
Verify on the :
Conclusion
In this guide, you have learnt how to create a token with metadata extension. This guide also walks you through generating a Mint account for your token.
import { Connection, Keypair } from "@solana/web3.js";
import bs58 from "bs58";
import 'dotenv/config'
// Replace with your GetBlock endpoint
const GETBLOCK_RPC_URL = process.env.RPC_URL;
// Create connection to Solana via GetBlock
const connection = new Connection(GETBLOCK_RPC_URL, "confirmed");
// Load keypair from private key in .env
const payer = Keypair.fromSecretKey(bs58.decode(process.env.PRIVATE_KEY));
export { connection, payer};
This guide uses Solana Devnet. If you want to make use of Mainnet, go to your and get a Solana mainnet access token.
Monitor wallets and automate transfers
Mint NFTs based on social media triggers
Core Stack of AI Agents
Just like every area of development has its own stack for building applications, AI agent development has its own stack, typically consisting of three layers:
Large Language Models (LLMs): The reasoning brain of every AI agent. LMs handle natural language understanding, interpret user requests, process blockchain data, and decide which actions to take.
Agent Frameworks: These define the agent's structure, personality, and interactions with external platforms. Examples include ElizaOS, LangChain, Rig, and AgentiPy.
Blockchain Toolkits: SDKs that enable agents to interact with networks like Solana. Examples include the Solana Agent Kit and GOAT Toolkit.
Why Are AI Agents Important in Blockchain?
Simplification of Complex Tasks: AI agents can handle complex DeFi tasks, such as finding the best yield, rebalancing portfolios, or executing arbitrage trades faster than humans.
Enhanced Security: They provide continuous monitoring of vulnerabilities in smart contracts and wallets and detect fraudulent activity in real time.
Simplified User Experience (Web3 Adoption): AI agents act as intermediaries, translating natural-language requests into complex on-chain actions, reducing technical barriers for users.
Decentralized Autonomous Interactions: Agents can hold funds, sign transactions, and interact with dApps autonomously, creating new, self-sustaining, AI-driven economic ecosystems.
Intelligent Data Processing: They provide an insightful report on vast, immutable datasets on the blockchain to support better decision-making.
Now that you've learnt about AI agents, their core stack, and its importance. In this guide, you will be learning how to build an AI agent on Solana, a fast and growing blockchain network. This agent will be able to transfer SOL to USDC and check your account balance as seen below:
Create agent.ts file, this is where you will be building your AI agent
5
Import your dependencies:
6
Initialize your Agent
This:
Connect the AI agent to Solana Devnet and access your wallet to perform actions
Empower the agent with tools for swapping(jupiter()), launch token(pumpfun()
7
Create Interface for interaction:
This defines an interactive CLI chat loop between you and the AI agent and also logs any errors.
8
Run the agent using this command
You can make any request in any language, as seen below:
You can see that it interprets your natural language, uses the tools plugin to get the right response for it
Extend AI Agent capacity
Improve the capacity of your agent by adding more tools:
Mint NFT:
Best Practice
Store private keys in .env only — never commit this file.
Use a dedicated burner wallet with minimal funds for testing
On mainnet, double-check all transactions before confirming.
Conclusion
In this guide, you have learn what AI agents are, their core stack, and how to build one for yourself to send, swap, launch a token, and check your account balance.
You: What is my wallet address and how much sol do i have left
Agent: Your wallet address is `5C7dUe5ZDWBCYQ5eqtGPRyz7CQYk2aK4FhZTDYQeji7r`, and you have approximately 7.94991 SOL left in your wallet.
You: Send 0.05 sol to 3xk5f92EhRfDSD29W9ZWKmX2x7DXkc6TpMW8TpX5eFU8
Agent: The transaction to send 0.05 SOL to the address `3xk5f92EhRfDSD29W9ZWKmX2x7DXkc6TpMW8TpX5eFU8` has been successfully completed. You can view the transaction details with the hash: [2ZK5U6pJ7i6j8nDRvdidgEyPnRPivzyBddUrJGebnefApFFXcvmomYNGZVC85XNjnAG5PTnuUyCwFYtjp55HNfLX](https://explorer.solana.com/tx/2ZK5U6pJ7i6j8nDRvdidgEyPnRPivzyBddUrJGebnefApFFXcvmomYNGZVC85XNjnAG5PTnuUyCwFYtjp55HNfLX).
You: Если вы обращаетесь в поддержку, можно сказать: "Подскажите, пожалуйста, мой адрес кошелька и баланс SOL"
Agent: Ваш адрес кошелька: `5C7dUe5ZDWBCYQ5eqtGPRyz7CQYk2aK4FhZTDYQeji7r`.
К сожалению, возникла ошибка при попытке получить баланс SOL. Пожалуйста, проверьте правильность адреса кошелька и попробуйте снова.
Fetch transaction data (getTransaction, getSignaturesForAddress)
Submit transactions (sendTransaction)
Monitor real-time events via WebSocket (accountSubscribe, logsSubscribe)
Access slot and block information (getSlot, getBlock)
Solana's JSON-RPC API follows a different specification than Ethereum — it's not EVM-based, so you'll use Solana-specific libraries like @solana/web3.js or solana-py.
Endpoint format:
Step-by-Step: Get Your Solana RPC Endpoint
1
Create a GetBlock Account
Go to GetBlock Dashboard and sign up. You can register with email or via Google/GitHub OAuth.
2
Create a Solana Endpoint
Once logged in:
Click "Shared Nodes" in the left sidebar
Click "Create New Endpoint" or the "+" button
Select:
Protocol: Solana (SOL)
Network: Mainnet
Click "Create": Your endpoint URL will be generated immediately.
3
Copy Your Endpoint URL
Your endpoint URL looks like this:
4
Test the Connection
Code Examples
import{Connection,PublicKey,LAMPORTS_PER_SOL}
from solana.rpc.api import Clientfrom solders.pubkey
import requests
url = "https://go.getblock.io/<YOUR-ACCESS-TOKEN>/"
headers = {"Content-Type": "application/json"}
# Get token accounts for a wallet
payload = {
"jsonrpc": "2.0",
"id": 1,
"method": "getTokenAccountsByOwner",
"params": [
"7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU",
{"programId": "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"},
{"encoding": "jsonParsed"}
]
}
response = requests.post(url, headers=headers, json=payload)
accounts = response.json()["result"]["value"]
for acc in accounts:
info = acc["account"]["data"]["parsed"]["info"]
print(f"Token: {info['mint']}, Amount: {info['tokenAmount']['uiAmountString']}")
use solana_client::rpc_client::RpcClient;
use solana_sdk::pubkey::Pubkey;
use std::str::FromStr;
fn main() {
let client = RpcClient::new("https://go.getblock.io/<YOUR-ACCESS-TOKEN>/");
// Get current slot
let slot = client.get_slot().unwrap();
println!("Current slot: {}", slot);
// Get balance
let pubkey = Pubkey::from_str("7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU").unwrap();
let balance = client.get_balance(&pubkey).unwrap();
println!("Balance: {} SOL", balance as f64 / 1e9);
}
WebSocket for Real-Time Solana Data
Solana's WebSocket API is essential for real-time monitoring:
wss://go.getblock.io/<YOUR-ACCESS-TOKEN>/
import WebSocket from "ws";
const ws = new WebSocket("wss://go.getblock.io/<YOUR-ACCESS-TOKEN>/");
ws.on("open", () => {
// Subscribe to SOL balance changes for an address
ws.send(JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "accountSubscribe",
params: [
"7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU",
{ encoding: "jsonParsed", commitment: "confirmed" }
]
}));
});
ws.on("message", (data) => {
const msg = JSON.parse(data);
if (msg.method === "accountNotification") {
console.log("Account updated:", msg.params.result.value);
}
});
Solana is especially demanding on RPC infrastructure:
Challenge
Public RPC
GetBlock
Rate limits
Aggressive (2-5 RPS)
Up to 500 RPS
getSignaturesForAddress depth
Often limited to recent
Full history available
Advanced Solana Infrastructure on GetBlock
1. Yellowstone gRPC (Geyser Plugin)
For applications that need the fastest possible data e.g., trading bots, MEV searchers, indexers. GetBlock offers managed Yellowstone gRPC endpoints as an add-on to Dedicated Solana Nodes.
Why Yellowstone gRPC over standard RPC:
Near-zero latency: streams data directly from validators
Millions of events per minute: handles Solana's full throughput
Rich filtering: subscribe only to accounts/programs you care about
Protobuf encoding: parsed, typed data instead of base64
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
Troubleshooting
Problem
Solution
Next Steps
To increase the priority for inclusion in your private transactions, see
How to extend your node subscription with a card payment
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
How To Optimize Solana Transactions with Priority Fees
Learn how to land your Solana transaction faster using priority fee and GetBlock
Solana processes thousands of transactions per second, but during periods of high network activity, your transactions may compete for block space. Priority fees let you bid for faster inclusion in the validator's queue, ensuring your time-sensitive transactions reach the network quickly.
In this guide, you'll learn about priority fees, when you should use them, how to calculate compute uint(CU), and how to create one for yourself.
What Are Priority Fees?
Priority fees are optional fees you add to a Solana transaction to increase its scheduling priority. Think of them as a tip to validators—transactions with higher priority fees get processed before those with lower fees or no fees at all.
/v1/accounts/{account_hash}/modules - Aptos
Example code for the /v1/accounts/{account_hash}/modules JSON-RPC method. Сomplete guide on how to use /v1/accounts/{account_hash}/modules json-rpc in GetBlock.io Web3 documentation.
This endpoint gets all modules(known as smart contracts)’ bytecode deployed under a specific account at a specific ledger version. These modules define smart contract logic and can include structs, resources, and functions.
Supported Network
API Interface: JSON-RPC or WebSocket or MEV protected (JSON-RPC)
Region: Frankfurt (EU), New York (US), or Singapore (APAC)
A package manager installed on your laptop(Preferrably npm)
Project Setup
1
Create a new project directory
mkdir priority-fees
cd priority-fees
2
Install the dependencies:
npm install @solana/web3.js dotenv base58
Package Description
Package
Description
3
Create a .env file and add the following details:
4
Create index.ts file, this is where you will be writing your script
5
Import your dependencies and load the .env variables:
6
Build the Transfer Instruction
This creates the instruction to move SOL. LAMPORTS_PER_SOL (1,000,000,000) converts from SOL to the smallest unit (lamports).
7
Simulate to Estimate Compute Units
This:
Wraps the transfer instruction in a versioned transaction (the modern Solana format) for simulation.
Gets a recent blockhash — required to build a valid transaction even for simulation.
8
Get a Dynamic Priority Fee and calculate the total cost
This helps gain insight into what was recently paid for priority fees and calculate what you paid, rather than guessing, which can prevent wastage or setting the fee too low.
9
Build the final transaction
This:
Assembles 3 instructions: CU limit → priority fee → SOL transfer, then attaches blockhash and fee payer.
Signs with the private key, submits, waits for confirmation, and returns the signature.
10
Run the code using this command
11
Result
You will get a response like this:
This should show the estimated CU, the total priority fee used, and the transaction hash
Best Practices
Never hardcode compute unit limits. Simulation catches errors before they cost you fees:
Network conditions change. Fetch recent fees instead of using static values:
Conclusion
Priority fees are a powerful tool for ensuring your Solana transactions reach their destination quickly during network congestion. The key steps are:
Build your instructions - Create the core transaction logic
Simulate - Get actual compute unit requirements
Fetch network fees - Understand current market rates
Add compute budget - Set limit and price (in that order, before main instructions)
Send - Sign and submit with appropriate commitment level
// Good: Simulate and use actual consumption + buffer
const simulation = await connection.simulateTransaction(tx);
const estimatedCU = Math.ceil(simulation.value.unitsConsumed * 1.1);
// Bad: Hardcoded value wastes money or fails
const estimatedCU = 1_400_000; // Don't do this
// Good: Adapt to current network conditions
const fees = await connection.getRecentPrioritizationFees();
const dynamicFee = calculatePercentile(fees, 75);
// Bad: Static fee may be too low or waste money
const staticFee = 50_000; // Don't do this
During normal network conditions, transactions land fine without priority fees. Only add them when speed matters or when the network is congested.
You're charged based on the compute unit limit you set, not what you actually use. If you set a limit of 200,000 CU but only use 50,000, you still pay for 200,000. This is why simulation matters.
Devnet RPC URL is used for this guide. If you want to interact with the Mainnet, then make use of
Mainnet
Parameters
Parameter
Data Type
Description
Required
In
account_hash
string
Aptos account address
Yes
Path
Request Example
Base URL
Example(cURL)
Response
Response Parameter Definition
Field
Description
bytecode
The bytecode representation of the module
abi
The Application Binary Interface (ABI) of the Move module
address
The address of the Aptos account
Use Cases
This endpoint can be used to:
Verify what functions and structs are exposed to dApps.
Assist in smart contract audits by fetching bytecode and ABIs.
Identify available functions, structs, and bytecode before interacting with a contract.
Code Examples
Python (Requests)
Node(Axios)
Error handling
Some of the errors you may face are:
403, which means your access token is incorrect or does not exist. To resolve this, you need to get a new access token or recheck your access token.
500, which means a Node or network issue. Retry later
404, which means the resources were not found. To resolve this, use the right account_hash, or it is not a smart contract address.
Integration with Web3
By integrating /v1/accounts/{account_hash}/modules, developers can:
Build contract explorers that Show deployed modules, their functions, and structs on user-friendly dashboards.
Enable smart contract interactions
Integrate module inspection for debugging, auditing, and testing workflows.
dApps can query other on-chain modules to understand what functions are available for reuse.
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
Connect to the MEV WebSocket endpoint with your API key:
Parameter
Type
Required
Description
Example
1
Set up the project
2
Create a new file named index.js. This is where you will make your first call.
3
Example: DEX Arbitrage
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.
Reference Addresses
Address
Comparing Bundles and Private Transactions
Choose the appropriate method based on your use case:
Best Practices
1. Use Sequential Nonces
All transactions in a bundle must have consecutive nonces starting from your wallet's current nonce:
2. Include a Priority Fee
Adding a fee payment as the final transaction increases the likelihood of bundle inclusion:
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
Simulate Before Submitting
Test your transaction logic before submitting a bundle by simulating each transaction:
The visibility of the function (public, private, or friend)
is_entry
Indicates if the function is an entry function
is_view
Indicates if the function is a view function
generic_type_params
The generic type parameters associated with the Move function
constraints
Any constraints associated with the function
params
The parameters associated with the Move function
return
The return type of the function
structs
The list of structs defined within the module
name (struct)
The struct name
is_native
Indicates if the module is native (implemented outside Move)
abilities
The list of abilities or capabilities provided by the module
fields
The list of fields defined within the struct
type
The field type
Dry-runs the transaction against the network without actually submitting it. Returns how many compute units it would use.
Takes the simulated CU count, adds a 10% buffer, then adds 600 extra to account for the two ComputeBudget instructions that will be in the final transaction but weren't in the simulation. Falls back to 200,000 if the simulation returned nothing.
Decodes private key, creates wallet keypair, parses recipient address, calls function with 0.001 SOL.
Complete Working Example
Here's a full example that puts everything together:
Arbitrage opportunities
Extreme priority
Network congestion detected
Increase from baseline
Time-sensitive operations
High priority minimum
@solana/web3.js
Standard library for talking to the Solana blockchain and RPCs
dotenv
Loads your .env file so secrets are not hardcoded in the source
base58
Decodes base58 private keys into a format the code can use
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
Here, you will be checking if you are connected to streams
How to Subscribe to Streams
To subscribe to streams, there are four parameters you can make use of as seen below:
Stream
Description
Use Case
1. Block Streams (bdnBlocks)
Subscribe to new blocks as they're produced.
Include Options
Field
Description
Example: Subscribe to Blocks
2. Transaction Streams (newTxs / pendingTxs)
Subscribe to mempool transactions as they propagate through the network.
Include Options
Field
Description
Filters
Reduce bandwidth by filtering server-side:
Filter
Type
Description
Example: Monitor PancakeSwap Transactions
3. Transaction Receipts (txReceipts)
Subscribe to transaction confirmations.
Include Options
Field
Description
Example:
Unsubscribing
To stop receiving notifications, unsubscribe using the subscription ID:
Best Practices
1. Request Only What You Need
Use Server-Side Filters
Handle Reconnection
Process Messages Asynchronously
Rate Limits
Tier
Concurrent Subscriptions
Message Rate
Contact to upgrade your tier.
Troubleshooting
Problem
Solution
Next Step
with accelerated propagation
Using private transactions for or
Quickstart guide
Follow these steps to activate the Solana Yellowstone gRPC add-on on GetBlock
GetBlock offers SOL nodes 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 subscription on GetBlock. Here’s how to set it up with gRPC API:
Sign up / log in: Create an account at GetBlock.io or log in to your existing account.
Deploy a dedicated Solana node:
Go to your user dashboard, switch the tab to “Dedicated nodes”, and scroll down to “My endpoints”
Enable the gRPC add-on: In Step 3 (Select API and Add‑ons) of your node setup, check Yellowstone gRPC under Add‑ons.
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 .
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).
Example endpoint URLs:
When establishing your gRPC channel, the authentication is handled via an access token:
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 , 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
Developers can integrate Yellowstone streams using standard gRPC client libraries. Triton’s Yellowstone repository includes 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:
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:
Connect to the gRPC endpoint and subscribe to the stream:
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.
Setup & run:
Make sure the following dependencies are installed:
Go Example (go-client/main.go):
Make sure you clone the Yellowstone repo (for the examples.grpc module):
Python Example (python-client/stream.py):
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.
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 , , or historical queries.
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 or reach out via .
"id":1,
"method":"mev_sendBundle",
"params":{
"transactions":["0xf86c...","0xf86c..."],
"mev_builders":{"all":""},
"blocks_count":5
}
}
"id":1,
"result":{
"bundleHash":"0x..."
}
}
Pending transactions
Front-running protection
txReceipts
Transaction receipts after confirmation
Trade confirmation
Transaction value (hex)
gas_price
Gas price (hex)
input
Transaction calldata
array
Function selectors (first 4 bytes of calldata)
Unlimited
Unlimited
Implement automatic reconnection (see example above)
Re-subscribe after each reconnect—subscriptions don't persist
isBlockhashValid: Checks whether a given blockhash is still valid.
getVersion: Returns version info for both the gRPC plugin and the connected Solana node
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.
slots
slots: SlotsFilter
Slot numbers as they’re processed by leader
blocks
blocks: BlocksFilter
Block metadata (slot, parent slot, timestamp)
All Dedicated Node plan subscribers receive the Yellowstone gRPC API at no extra cost together with their Solana node.
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.
GetBlock provides a single TLS endpoint – you don’t need to open or configure a different port for gRPC access.
All filters can be combined in the same request.
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.
// 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>/
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)
cd rust-client
cargo build
cargo run
[dependencies]
yellowstone-grpc = { git = "https://github.com/rpcpool/yellowstone-grpc", branch = "main" }
tonic = "0.9"
tokio = { version = "1", features = ["full"] }
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);
}
}
How to Build Basic-level Model-Context Protocol with GetBlock API Endpoints
A step-by-step guide on how to build MCP with GetBlock API
The Model-Context Protocol (MCP) is an open standard created by Anthropic that provides a universal way for AI assistants to connect to external data sources and tools.
With MCP, AI applications can connect to various data sources (e.g., local files, databases), tools (e.g., search engines, calculators), and workflows (e.g., specialized prompts)—enabling them to access key information and perform tasks effectively.
You can picture MCP as a "USB-C for AI":
Before USB-C: Every device had different charging ports
After USB-C: One universal port works with everything
Similarly, MCP creates a universal "port" for AI assistants to connect to data.
In short, MCP helps AI applications access the right information at the right time, thereby reducing the likelihood of incorrect or misleading responses.
In this guide, you will learn how to:
Get a GetBlock Access Token for Ethereum's API endpoint
A basic MCP server with three core capabilities:
Check ETH balance for any Ethereum address
Prerequisites
Basic understanding of JavaScript
Must have installed and
A GetBlock
Technology Stack:
Node.js: JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts.
This allows applications to provide the context for LLMs in a standardized way.
: TypeScript-first validation library.
Step 1: Project Initialization
Set up your project directory using this command:
Install Dependencies:
@modelcontextprotocol/sdk: Core MCP server functionality that provides McpServer class and transport mechanisms.
ethers: Js library for interacting with Blockchain e.g Ethereum.
"main": "server.js" - Specifies entry point of your application
"bin" - Allows running server as npx mcp-ethereum
Get GetBlock's API Access Token
Log in to your
On your dashboard, scroll and click on Get Endpoint
Create the following files to have a basic structure for your project:
Step 2: Server File Setup
1. Import dependencies
What this does:
Reads API token from environment variable
Creates Ethers provider pointing to GetBlock endpoint
All blockchain queries route through GetBlock's infrastructure
3. Create MCP server instance
Configuration:
name - Unique identifier for your server
version - Semantic version for tracking updates
console.error() - Logs to stderr (separate from data output)
4. Implement Blockchain Query Tools
Tool 1: Get ETH Balance
This tool fetches the ETH balance for any Ethereum address:
What this does:
Register the tool
Validates Ethereum address format
Queries Ethereum blockchain through GetBlock
Returns balance in Wei (smallest unit)
Tool 2: Get Gas Price
This tool retrieves current Ethereum gas prices:
What it does:
Register the tool
Fetch gas price
Converts the gas price from Wei to Gwei (1 Gwei = 10^9 Wei)
Tool 3: Get Block Number
This tool returns the latest Ethereum block number.
What this does:
Get the latest block
Includes server timestamp for correlation
5: Server Startup and Connection
Create a Server connection with Claude desktop
What this does:
const transport = new StdioServerTransport(): create communication channel between the client(Claude Desktop) and the server(script)
Links MCP server to transport mechanism
Registers all tools with MCP client
Start the server and shut down:
What this does:
SIGINT - Handles Ctrl+C interrupts
When the user runs npm run start , this will start the server.
Step 3: Configuration and Deployment
Open your Claude Desktop
Click on Settings
Scroll down and Click on Developer
Under Local MCP Server
Add the following configuration:
Config Location:
Edit Configuration:
Add the following configuration:
Config Location:
Add the following configuration:
Config Location:
Step 4: Testing Your Server
Test 1: Check ETH Balance
Expected: Claude calls get_eth_balance tool and shows balance e.g
The ETH balance for address 0xd1af2dac4e0a9d1f58b99e2f42bc0320ed74a7cd is 0.000104792219532 ETH (approximately 104,792,219,532,000 wei).
Test 2: Gas Price
Expected: Claude calls get_gas_price tool and shows price in Gwei e.g
The current Ethereum gas price is 0.071638489 Gwei (or about 71.6 million wei).
For EIP-1559 transactions:
Max Fee Per Gas: 0.143276976 Gwei
Max Priority Fee Per Gas: 0.000000002 Gwei
This is relatively low gas pricing, which means it's a good time for transactions on the Ethereum network.
Test 3: Block Number
Expected: Claude calls get_block_number tool and shows block e.g
The latest Ethereum block number is 23,811,857 on the Ethereum Mainnet, as of 2025-11-16 at 12:50:34 UTC.
Step 4: Advanced Tests
Test 4: Multiple Queries
Expected: Claude calls both tools and provides analysis e.g
Balance for 0xd1af2dac4e0a9d1f58b99e2f42bc0320ed74a7cd:
0.000104792219532 ETH
Current Gas Price Assessment: The current gas price of 0.063 Gwei is very low. This is excellent for making transactions!
For context:
Low gas: < 20 Gwei
Test 5: Natural Language
Expected: Claude checks gas price and provides a recommendation e.g
Yes, now is an excellent time to send an Ethereum transaction! Here's why:
The current gas price of 0.060 Gwei is extremely low. To put this in perspective, a standard ETH transfer (21,000 gas units) would only cost about:
0.060 Gwei × 21,000 = 0.00000126 ETH (roughly $0.004 USD)
This is about as cheap as gas fees get on Ethereum. Gas prices can spike to 30-100+ Gwei during busy periods, which would make the same transaction 500-1600x more expensive.
However, one thing to consider: The address you checked (0xd1af...a7cd) only has 0.0001048 ETH. While the gas is cheap right now, you'd still need to ensure you're leaving enough in the wallet to cover the gas fee for any transaction you want to make.
If you're planning to send transactions from a different address with more funds, or if you're just doing something simple like a basic ETH transfer, this is definitely an opportune moment to take advantage of these low gas prices!
Troubleshooting
If you experience this error:
This means that:
Your GetBlock token is missing or incorrect
The base URL is not correct.
Conclusion
In this guide, you've successfully functional MCP server that connects AI assistants to blockchain data using the GetBlock API. Now you know what MCP is, how to set up your project, get your GetBlock Token and get a response directly from your Claude.
Additional Resources
Get current gas prices
Retrieve the latest block number
Claude configuration and deployment
Ethers: A library for interacting with the Ethereum blockchain and its ecosystem.
: a schema that validates user inputs before processing.
command
"scripts" - Defines shortcuts like npm start
Select the Ethereum Mainnet network
Under API Interface, select JSON-RPC
Click on Create to get your endpoint
Your endpoint will look like:
f. Save the token in .env file in this format:
Project Structure
Converts Wei to human-readable ETH e.g 1500000000000000000 → "1.5"
Return MCP content format
JSON stringified with 2-space indentation
Includes raw Wei value for precision
Starts listening for incoming requests
, click on
Edit Config
Add the following configuration:
Average gas: 20-50 Gwei
High gas: 50-100 Gwei
Very high gas: > 100 Gwei
At 0.063 Gwei, you're looking at extremely cheap transaction costs right now. This is a great time to interact with the Ethereum network if you're planning any transactions.
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ethers } from "ethers";
import { z } from "zod";
// Validate environment
const GETBLOCK_TOKEN = process.env.GETBLOCK_TOKEN;
// Initialise Ethers provider with GetBlock
const provider = new ethers.JsonRpcProvider(
`https://go.getblock.us/${GETBLOCK_TOKEN}/`
);
// Create MCP server with modern API
const server = new McpServer({
name: "ethereum-mcp-server",
version: "1.0.0",
});
console.error("✅ Ethereum MCP Server initialized");
async function main() {
try {
// Create stdio transport for Claude Desktop
const transport = new StdioServerTransport();
// Connect server to transport
await server.connect(transport);
console.error("🚀 Ethereum MCP Server is running!");
console.error("📡 Connected via stdio transport");
console.error("⏳ Waiting for tool calls...");
} catch (error) {
console.error("❌ Failed to start server:", error);
process.exit(1);
}
}
How to Track Pump.fun Token Mints with GetBlock’s Yellowstone gRPC
A complete guide on how to track Pump.fun token launches on Solana in real-time using GetBlock’s Yellowstone gRPC service.
Overview
Traditional blockchain monitoring relies on polling RPC endpoints every few seconds, which introduces significant latency (2-5 seconds) and checking for updates that may not exist.
GetBlock's Yellowstone gRPC service solves this by streaming data from Solana validators in real time.
Here is a comparison:
Traditional RPC Polling
Websocket
Yellowstone gRPC
Why GetBlock’s Yellowstone gRPC?
GetBlock provides access to Solana's Yellowstone Geyser gRPC plugin, delivering real-time blockchain data through a high-performance streaming protocol:
Ultra-Low Latency: Direct streaming from validators with ~400ms latency vs 2-5 seconds with traditional RPC polling
Efficient Filtering: Subscribe only to the specific programs and accounts you need, reducing bandwidth and processing overhead
Bidirectional Streaming: Single persistent connection handles both requests and data flow, eliminating polling waste
In this guide, you will learn how to:
Connects to GetBlock's Yellowstone gRPC service
Subscribes to all transactions involving Pump.fun's program
Filters for token creation instructions specifically
Parses instruction data to extract token metadata
Prerequisites
Before you begin, ensure you have:
and npm installed
Basic knowledge of JavaScript
A
A Dedicated Solana Node subscription on GetBlock - Required for Yellowstone gRPC access
Technology Stack:
Node.js
- Official Yellowstone gRPC client
- Base58 encoding for Solana addresses
GetBlock’s Dedicated Solana Node with Yellowstone add-on
Step 1: Set Up Your GetBlock’s Yellowstone Endpoint
Deploy Your Dedicated Solana Node
First, you need to deploy a dedicated Solana node on GetBlock with the Yellowstone gRPC add-on enabled.
1. Sign up or log in
Go to
Create an account or log in to your existing account
2. Deploy your dedicated node
Navigate to your user Dashboard
Switch to the "Dedicated nodes" tab
Scroll down to "My endpoints"
3. Enable the Yellowstone gRPC add-on
In Step 3 of your node setup (Select API and Add-ons)
Check the box for Yellowstone gRPC under Add-ons
Complete payout and finalise the setup
Generate a Yellowstone gRPC Access Token
Once your node is live, you'll create an access token to authenticate your gRPC connections.
1. Return to your dashboard
Under your dedicated node dashboard, click on "My endpoints".
Select Yellowstone gRPC
Click on Add to generate an access token
2. Your endpoint URL
You'll receive an HTTPS-style gRPC endpoint URL based on your chosen region:
Step 2: Set up Development Environment
Create a directory for your project
Install Dependencies:
What these packages do:
- Official client for connecting to Yellowstone gRPC services (works with GetBlock)
- Encodes binary data to base58 format (Solana's address format). Version 5.0.0 supports vanilla js.
Project Structure
Create the following files to have a basic structure for your project:
Step 3: Start Building Your Monitor
Import dependencies into pumpfun-monitor.js :
What this does:
yellowstone gRPC Client for connecting to GetBlock
CommitmentLevel Settings for choosing transaction confirmation speed
bs58 for converting binary data into human-readable Solana addresses.
Add your GetBlock configuration:
What this does:
Stores your GetBlock credentials.
Add Pump.fun constants:
What this does:
PUMPFUN_PROGRAM - The unique program ID for Pump.fun on Solana
CREATE_DISCRIMINATOR - The 8-byte identifier that marks token creation instructions (derived from hashing "global:create")
Add statistics tracker:
This creates an object to track how many tokens you've detected and when the last one appeared.
Step 4: Build Data Parser Functions
Now, you'll add a function to decode the binary data from Pump.fun's instruction format.
Add string decoder:
What this does:
Pump.fun stores strings as [4 bytes for length][UTF-8 string data]. This function reads that format and returns both the string value and how many bytes were consumed.
Add Instruction Parser:
What this does:
Reads the token's metadata from Pump.fun's instruction data format. The data is organized like this:
First 8 bytes: Discriminator (identifies this as a "create" instruction)
Token name (e.g., "Super Doge")
Step 5: Add Account Address Extractor
The next step is to create a function that extracts account addresses to identify newly created tokens' mint address, bonding curve pool address and creator's wallet address.
What this does:
Extracts three key addresses from the instruction:
accounts[0] - The newly created token's mint address
accounts[2] - The bonding curve pool address
Step 6: Add Instruction Verifier
The next step is to verify the instruction:
What this does:
Verifies two things:
The instruction calling Pump.fun's program
The first 8 bytes which match the create discriminator
Step 7: Add Display Function
The next step is to add a function that displays the data in a readable format:
What this does:
Formats and displays all token information in a readable format
Updates statistics
Includes Solscan link to the token, transaction hash and creator.
Step 8: Build the Main Monitor Function
Now you'll create the core function that connects to GetBlock and processes blockchain data.
Part A: Start the Function and Connect
What this does:
Creates a client connection to GetBlock using your credentials and opens a bi-directional streaming connection.
Part B: Configure Subscription
What this does:
Tells GetBlock you only want transactions involving Pump.fun's program, with CONFIRMED commitment level (~2-3 seconds, balanced speed/reliability).
Part C: Handle Incoming Data
What this does:
Processes each message from GetBlock - responds to keep-alive pings and extracts transaction data.
Part D: Process Instructions
What this does:
For each instruction, it checks if it's a create, parses metadata, extracts addresses, and displays results.
Part E: Handle Errors
What this does:
It handles stream errors and connection closures.
Part F: Send Request
What this does:
Sends your subscription request to GetBlock and confirms the connection is active.
Step 9: Add Execution Code
Finally, add the code to run your monitor:
What this does:
Runs your monitor and automatically restarts it if it crashes.
What this does:
Handles Ctrl+C to show final statistics before shutdown.
Step 10: Run Your Monitor
Run the following command in your terminal to start the server:
Expected Output
You'll see:
This means you're connected to GetBlock and monitoring is active.
When a Token Appears
When a new token appears, it displays like this:
Congratulations 🎉, you've successfully created an application that tracks Pump.fun token minted.
Troubleshooting
Connection issues:
This means there is a connection glitch:
Verify your ENDPOINT and TOKEN in pumpfun-monitor.js
Check your GetBlock dashboard to confirm if the node is active
Test your internet connection
Tokens not showing:
Be patient - Pump.fun typically has 50-200 tokens per day
Visit to verify tokens are being created
Try CommitmentLevel.PROCESSED for faster updates
Parser Errors:
These warnings are normal. This means some transactions aren't structured.
Security Best Practices
This is highly recommended to use environment variables instead of hard-coding. Create an .env file and store your token like this:
and reference it in your pumpfun-monitor.js like this:
Conclusion
In this guide, you learn how to build a tracking application that monitors Pump.fun token minted using GetBlock Yellowstone gRPC. This guide explains the importance of using GetBlock Yellowstone gRPC, how to get your Yellowstone gRPC token, set up the application to get the expected result.
It also explains how to troubleshoot some errors you may encounter and possible ways to enhance the security and maintainability of your applications.
Additional Resources
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
How to Monitor Liquidity Pools on Solana DEXes with GetBlock's Yellowstone gRPC
Step-by-step guide for building a Node.js app to track real-time swaps on Solana using GetBlock's Yellowstone gRPC
Monitoring liquidity pools on Solana decentralised exchanges (DEXes) in real-time is crucial for traders and developers who want to stay updated with the latest market conditions and make informed decisions.
GetBlock's Yellowstone gRPC service allows developers to fetch data directly from Solana validators easily with low latency - appropriately ~400ms latency.
In this guide, you'll build a monitor that tracks every swap happening on a specific Solana DEX liquidity pool, regardless of which platform (Jupiter, Raydium, Phantom Wallet, etc.) the user is trading with.
You'll learn how to:
Connect to GetBlock's Yellowstone gRPC service for ultra-low latency blockchain data streaming
No Infrastructure Needed: GetBlock manages validators, updates, and monitoring across global data centers (Europe, USA, Asia)
Simple Integration: Standard HTTPS endpoint with token authentication, works with existing gRPC client libraries.
Displays formatted output with Solscan explorer links
Tracks statistics and auto-reconnects on errors
Under "
Protocol
", select Solana
Set the network to Mainnet
Click Get
Token symbol (e.g., "SDOGE")
Metadata URI (link to token image and details)
accounts[7] - The creator's wallet address
2-5 second delays, constant API requests, high resource usage
1-3 second delays, server pushes updates when available
~400ms latency, bidirectional streaming, direct validator connection
Ensure you securely store both the base endpoint and the access token. You'll need them in your code to authenticate with GetBlock's Yellowstone service.
GetBlock provides a single TLS endpoint - you don't need to configure different ports or protocols. Everything works over standard HTTPS (port 443).
[email protected] because version 6.x + uses ES modules only, which don't work with vanilla js - require() statements.
Replace YOUR_ACCESS_TOKEN with the actual token you generated in Step 1.
If you chose a different region, use that endpoint instead (e.g., https://go.getblock.us/<ACCESS_TOKEN> or https://go.getblock.asia/<ACCESS_TOKEN>.
The function starts at byte 8 (after the discriminator) and reads each string one by one using the decodeString helper function.
These are defined by Pump.fun's program structure.
Only instructions passing both checks are token creations.
This section is broken into smaller parts for clarity.
This completes the monitorPumpfunMints() function - everything above is part of this one function in your pumpfun-monitor.js file.
Remember to add the .env file in your .gitignore file.
Create the following files to have a basic structure for your project:
Step 3: Start Building Your Monitor
Import Dependencies
Create a new file pool-monitor.js and add:
What this does:
Client- The main class you'll use to connect to GetBlock's Yellowstone gRPC service and create a streaming connection
CommitmentLevel - Solana has different levels of transaction finality (how "confirmed" a transaction is). You'll use this to choose how finalised you want transactions to be before receiving them
bs58 - A library that converts Solana's binary address data (which is just bytes) into the readable base58 format you see on block explorers (like 8sLbNZ...)
config() - To load the .env variables.
Add Your GetBlock Configuration
What this does:
Stores your GetBlock credentials that you created in Step 1. Replace YOUR_ACCESS_TOKEN with the actual token you generated. If you chose a different region, use that endpoint instead (e.g., https://go.getblock.us or https://go.getblock.asia).
Add Pool Configuration
What this does:
TARGET_POOL - The unique address of the liquidity pool you're monitoring. This is the SOL/USDC Concentrated Liquidity pool on Raydium, one of the most active trading pools on Solana, with over 140,000 transactions per day
POOL_NAME - A human-readable name for display purposes
Add DEX Program IDs
What this does:
Stores the unique program IDs for major Solana DEX platforms. These are like addresses for the programs (smart contracts) themselves. When someone makes a swap, their transaction calls one of these programs. By checking which program was called, you can identify if the swap came from:
Raydium_AMM - Raydium's standard automated market maker
JUPITER_V6 - Jupiter's DEX aggregator (finds best prices across multiple DEXes)
Add Statistics Tracker
What this does:
It creates a simple object to track two key pieces of information: when the monitor was started (startTime) and the total number of successful swaps detected (totalSwaps).
This allows you to view cumulative statistics when you stop the program.
Step 4: Build the Swap Source Identifier
Now you'll add a function to identify which platform initiated each swap.
What this does:
This function examines all the instructions in a transaction to figure out where the swap came from.
Understanding how this works:
Every Solana transaction contains one or more "instructions" - think of these as individual commands or steps
Each instruction calls a specific program (smart contract)
The programIdIndex points to which program being called
We look up that program's address using accountKeys[programIdx] and convert it from binary to a readable format using bs58.encode()
Then we check if it matches any of our known DEX programs (Jupiter, Raydium CLMM, or Raydium AMM)
If none match, you label it as "Other" (could be another DEX or aggregator like Orca, Phantom Swap, etc.)
Step 5: Add Display Function
What this does:
Formats and displays each swap in a readable way to your terminal.
Break down:
stats.totalSwaps++ - Increments the counter every time we display a swap
"=".repeat(80) - Creates a visual separator line (80 equal signs)
SOURCE - Shows which platform was used (Jupiter, Raydium, etc.)
TRADER - The Solana wallet address that initiated the swap
SIGNATURE - A unique identifier for this transaction (like a transaction hash)
SLOT - Solana's equivalent of a block number - tells you exactly when this happened on the blockchain
TIME - The local time when you received this swap notification
EXPLORE section - Provides clickable links to:
View the full transaction details on Solscan (a Solana block explorer)
View the pool itself and all its activity
Step 6: Build the Main Monitor Function
Now you'll create the core function that connects to GetBlock and processes blockchain data.
Part A: Start the Function and Connect
What this does:
Prints a startup message so you know the monitor is launching
Creates a Promise so this function can run asynchronously and handle errors properly
new Client(ENDPOINT, TOKEN, undefined)- Creates a connection client using your GetBlock credentials.
await client.subscribe() - Opens a bidirectional streaming connection to GetBlock's Yellowstone service. This is the "pipe" through which blockchain data will flow to your application
Part B: Configure Subscription
What this does:
Tells GetBlock exactly what data you want to receive
Part C: Handle Incoming Data
What this does:
Sets up an event listener that processes each message GetBlock sends you.
Part D: Process and Display Swaps
What this does:
processes each transaction and:
Checks if the transaction failed - txMeta.err will be present if the transaction failed. We skip these because failed swaps aren't useful to track (they might be due to slippage, insufficient balance, etc.)
Identifies the source - Calls our identifySwapSource() function to determine if it came from Jupiter, Raydium, or elsewhere
Gets the trader - In Solana, the first account in accountKeys is always the signer (the person who initiated the transaction). We convert it from binary to a readable format
Display severything - Calls our displaySwap() function with all the collected information
Part E: Handle Stream Events
What this does:
Handles different connection states such as:
error - If something goes wrong with the connection (network issue, GetBlock problem, etc.), we log the error and reject the Promise. This will trigger our auto-reconnect logic later
end - The stream ended gracefully (normal shutdown)
close - The connection closed (either normally or due to an error)
Both end and close resolve the Promise, which allows the program to shut down cleanly or restart if needed.
Part F: Send Subscription Request
What this does:
Sends your subscription configuration to GetBlock and confirms the connection is active.
Step 7: Add Auto-Restart Functionality
Add the code to run your monitor with automatic restart on errors:
What this does:
Provides resilience by automatically restarting if something goes wrong.
Step 8: Add Shutdown
Finally, add the code to handle Ctrl+C successfully:
Step 9: Test Your Monitor
Run the Monitor
Expected output:
You'll see:
What you see:
SOURCE- This swap came through Jupiter's aggregator
TRADER - The wallet address that made the swap
SIGNATURE - Unique transaction ID (click the link to see full details on Solscan)
SLOT - Happened at blockchain slot 376,205,017
TIME- Your local time when you received this notification
The SOL/USDC pool typically has 140,000+ swaps per day, so you should see activity within seconds of starting the monitor.
Troubleshooting
Connection Issues:
Verify your ENDPOINT and TOKEN in pool-monitor.js
Check your GetBlock dashboard, confirm the node is active
Test your internet connection
No Swaps Showing:
If you don't see any swaps after a minute:
The SOL/USDC pool is extremely active, so this is unusual
Check that your subscription was successful (you should see "✅ Subscription active")
Try CommitmentLevel.PROCESSED for faster updates
Processing Errors:
These are normal. Occasionally, some transactions have non-standard formats
Your monitor will skip these and continue running
Failed transactions are automatically filtered out
Conclusion
In this guide, you've learn how to build a monitor that fetches liquidity pools on Solana DEXes with GetBlock's Yellowstone gRPC. This guide exposes you to the importance of using GetBlock's Yellowstone gRPC and how to set up the project effectively.
🚀 Starting Liquidity Pool Swap Monitor
🎯 Pool: SOL/USDC
📍 Address: 8sLbNZoA1cfnvMJLPfp98ZLAnFSYCFApfJKMbiXNLwxj
Waiting for swaps...
✅ Subscription active - monitoring pool swaps...
This means you're connected to GetBlock and monitoring is active!
When a Swap Appears
================================================================================
✅ SWAP #1 on SOL/USDC
================================================================================
🔀 SOURCE: Jupiter
👤 TRADER: 9wFFyRfZBsuAha4YcuxcXLKwMxJR43S7fPfQLusDBzvT
📜 SIGNATURE: 5TYqzsc8kGY7vMGDZxEbBFWGnEUPTQQMpk9kRvx3H8p2
🎰 SLOT: 376205017
⏰ TIME: 14:32:18
🔍 EXPLORE:
TX: https://solscan.io/tx/5TYqzsc8kGY7vMGDZxEbBFWGnEUPTQQMpk9kRvx3H8p2
Pool: https://solscan.io/account/8sLbNZoA1cfnvMJLPfp98ZLAnFSYCFApfJKMbiXNLwxj
================================================================================
"Connection refused"
Error processing transaction warnings
Ensure you securely store both the base endpoint and the access token. You'll need them in your code to authenticate with GetBlock's Yellowstone service.
[email protected] because version 6.x + uses ES modules only, which don't work with vanilla js - require() statements.
You'll build everything in a single file called pool-monitor.js. Let's start creating it piece by piece.
Why this matters:
Users don't always trade directly on Raydium. They might use Jupiter (which finds the best price by checking multiple DEXes) or their wallet's built-in swap feature. This function shows you the actual entry point the user used, which is interesting for understanding trading patterns.
Why formatted output matters:
Raw blockchain data is hard to read. This function turns binary data and hex strings into useful information that helps you understand what's happening.
This is broken into smaller parts for clarity.
Unlike making individual API requests (like asking "what's new?" every few seconds), this creates a persistent stream. GetBlock will push data to you immediately as it happens on the blockchain.
At this stage, your monitor is fully connected, subscribed, and waiting for swaps. Every time someone trades on the SOL/USDC pool through any platform, you'll receive the data within ~400ms and display it.
This ensures your monitor keeps running even if there's a temporary problem. In production, you'd want to add limits (don't restart forever if there's a permanent issue), but this is great for getting started.
How to Build Pump.fun to PumpSwap and Raydium Migrations Listener with GetBlock
A step-by-step guide on how to build a real-time listener for Pump.fun token migrations to both PumpSwap and Raydium using GetBlock API
Pump.fun is a Solana-based memecoin launchpad that uses a bonding curve mechanism to initiate token distribution. When a token reaches an approximate market cap of $69,000, it graduates from the bonding curve. At this point, $12,000 of liquidity is deposited to either Raydium DEX or PumpSwap (Pump.fun's native DEX). This migration creates immediate trading opportunities for developers and traders who can detect these events in real-time.
March 2025, Pump.fun introduced , her own decentralized exchange. Since then, most tokens have migrated to PumpSwap instead of Raydium. This guide will show you how to track migrations to both destinations.
How Pump.fun Migrations Work
Tokens on Pump.fun start trading on a bonding curve mechanism. When the bonding curve reaches completion (approximately $69,000 market cap), the protocol executes a migration.
Migration Flow:
Bonding Curve Phase: Token trades on Pump.fun using bonding curve pricing
Completion Trigger: Bonding curve reaches ~$69k market cap
Migration Transaction: Pump.fun migration account executes the migration
Key Addresses
Program
Address
In this guide, you will learn how to:
Get a GetBlock Access Token for Solana's API endpoint
Build a WebSocket listener that detects Pump.fun migrations to both PumpSwap and Raydium
Process transaction logs to extract token and pool information
Distinguish between PumpSwap and Raydium migrations
Prerequisites
Basic understanding of JavaScript
A GetBlock
Node.js installed (v18 or higher)
Technology Stack
Node.js: JavaScript runtime environment for building server applications
Official Solana JavaScript SDK for blockchain interactions
: WebSocket client library for real-time connections
Step 1: Project Initialization
Set up your project directory using this command:
Install Dependencies:
Configure package.json:
"type": "module" - Enables ES6 import/export syntax (required for modern JavaScript)
"main": "server.js" - Specifies entry point of your application
"scripts" - Defines shortcuts like npm start
Get GetBlock's API Access Token
Log in to your
On your dashboard, scroll and click on Get Endpoint
Select the Solana Mainnet network
Your WebSocket endpoint will look like:
Also get the HTTP endpoint for transaction fetching:
Return to the dashboard
Select JSON-RPC (https://) under API Interface
Your HTTP endpoint will look like:
Save both endpoints in a .env file in your project root:
Project Structure
Create the following files to have a basic structure for your project:
Create a .gitignore file:
Step 2: Server File Setup
1. Import Dependencies and Configuration
What this does:
Imports necessary libraries for Solana interactions and WebSocket connections
Loads API endpoints securely from environment variables
Validates that the required configuration is present
Defines the key addresses we'll monitor for migrations
2. Create the Migration Listener Class
Breaking down the constructor:
The constructor initializes all the state we need to track. Let me explain each property:
this.ws - Will hold our WebSocket connection to GetBlock
this.connection - HTTP connection for fetching full transaction details
this.subscriptionId - The ID returned when we subscribe to logs
3. Create an Interval check
What this does:
The start() method kicks everything off. It checks if the Websocket is connected or not.
The checkRunning() method creates a timer that runs every 60 seconds (60000 milliseconds). This serves two purposes:
It shows the listener is still running
4. Create GetBlock Websocket Connection
What this does:
The connect() method creates a new WebSocket connection to GetBlock. Then it sets up four event listeners:
open - Called when the connection is established
message
5. Subscribe to Migration Events
What this does:
Uses Solana's logsSubscribe method to monitor transactions
Filters for transactions mentioning the Pump.fun migration account
Uses confirmed commitment for faster notifications (1-2 seconds)
6. Handle Incoming Messages
What this does:
Parses incoming WebSocket messages
Handles subscription confirmation and stores subscription ID
Processes log notifications for migration detection
7. Process Transaction Logs
What this does:
Checks transaction logs for migration keywords like:
Skips failed transactions
Fetches full transaction details when migration is detected
8. Fetch Full Transaction Details
What this does:
Waits 1 second for the transaction to propagate
Fetches complete transaction from Solana via HTTP
Extracts and displays migration data
9. Extract Migration Data
What this does:
Handles both versioned and legacy Solana transactions
Detects Raydium migrations by checking for Raydium program ID
Detects PumpSwap migrations by checking for Pump.fun program ID
Extracts relevant addresses (token, pool, LP mint)
10. Display Migration Results
What this does:
Displays Raydium migrations with pool and LP mint info
Displays PumpSwap migrations with bonding curve info
Provides links to Solscan and trading platforms
11. Handle Reconnections
What this does:
Implements exponential backoff for reconnections (2s, 4s, 8s, etc.)
Caps reconnection delay at 30 seconds
Exits after 10 failed reconnection attempts
12. Initialize and Run
What this does:
Handles graceful shutdown on Ctrl+C
Catches uncaught errors
Step 4: Testing Your Listener
Start your migration listener:
Expected Output:
Test 1: Real-time PumpSwap Migration
When a token migrates to PumpSwap:
Test 2: Real-time Raydium Migration
When a token migrates to Raydium (rare):
Test 3: Check if alive
Every minute:
Troubleshooting
1. Missing access token or Connection error
This means that:
You haven't set up your environment variable as follows in this guide
Your Access token is incorrect or incomplete
2. Only seeing PumpSwap migrations or no migration at all
This is expected. Since March 2025, most tokens (95%+) have migrated to PumpSwap instead of Raydium. Also, migration doesn't happen frequently.
Not receiving any logs
Solution:
Verify subscription succeeded (you should see ✅ Subscribed with ID)
Check GetBlock dashboard for API usage limits
Verify transactions exist at
Conclusion
In this guide, you've built an app that listens to Pump.fun token migrations to both PumpSwap and Raydium using GetBlock's Solana infrastructure. You learn:
How to connect to GetBlock's WebSocket API for real-time blockchain data
How to subscribe to specific account activities on Solana
How to distinguish between PumpSwap and Raydium migrations
How to extract token addresses and pool information from transactions
Additional Resources
How To Build a Base Flashblocks Listener
A step-by-step guide to subscribing to Base Flashblocks and building trading applications around ultra-fast blockchain data.
Traditional blockchain confirmations are slow. On Ethereum Layer 2 networks, such as Base, blocks are produced every 2 seconds. While this is already faster than Ethereum's ~12-second blocks, it's still an eternity for time-sensitive applications like trading bots, real-time games, or DeFi protocols where milliseconds matter.
Flashblocks break the limitation of traditional blocks by creating mini-blocks every 200 milliseconds, providing users with instant transaction status while still retaining cryptographic security.
In this guide, you'll learn what base flashblocks are, their importance, data structure and step-by-step instructions on how to build a base flashblocks listener.
Liquidity Deployment: $12,000 of liquidity is deposited into either:
PumpSwap (Pump.fun's DEX) - Most common since March 2025
Raydium AMM - Less common, but still happens
Handle reconnections and error scenarios
Display migration data in a user-friendly format
dotenv: Environment variable management for secure configuration
Under API Interface, select
WebSocket (wss://)
Click on Create to get your endpoint
Click Create
MIGRATION_ACCOUNT - This is the Pump.fun account that executes all migrations
RAYDIUM_PROGRAM - The Raydium program ID to detect Raydium migrations.
PUMPFUN_PROGRAM - The Pump.fun program ID to detect PumpSwap migrations.
this.isConnected - Boolean flag to track connection status
this.reconnectAttempts - Counter for reconnection attempts (we limit it to 10)
this.raydiumMigrationCount & this.pumpswapMigrationCount - Separate counters for each migration type
this.migrations - Array to store all detected migrations
this.startTime - Timestamp when listener started (for runtime tracking)
this.totalLogsReceived - Counter for all logs received (helps with debugging)
It provides statistics: runtime, total logs received, and migrations detected by type
- Called whenever we receive data
error - Called if something goes wrong
close - Called when the connection drops
When the connection opens, handleOpen() runs. It sets isConnected to true, resets the reconnection counter (since you've successfully connected), and most importantly, subscribes to the logs you need.
How to handle versioned Solana transactions
How to implement robust reconnection logic
Pump.fun Program
6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P
Pump.fun Migration Account
39azUYFWPz3VHgKCf3VChUwbpURdCHRxjWVowf5jUJjg
Raydium Liquidity Pool V4
675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8
The Pump.fun migration account manages both types of migrations.
For PumpSwap migrations, it calls migrate instruction on the Pump.fun program.
For Raydium migrations, it calls the initialize2 instruction on Raydium's Liquidity Pool V4 program.
Keep your endpoints safe, as they contain your access token
Your script will be written inside server.js
Migration isn't frequent and may not occur within an hour. This is good for debugging—if no logs appear, it's a sign there's an issue with the subscription. This ensures that monitoring is active.
//Missing api key or environment variable
❌ Missing required environment variables
Please set GETBLOCK_WS_ENDPOINT and GETBLOCK_HTTP_ENDPOINT in .env file
//Connection error(403)
🔌 Connecting to GetBlock WebSocket...
❌ WebSocket error: Unexpected server response: 403
🔌 Connection closed
What Are Base Flashblocks?
Flashblocks are sub-blocks (or "mini-blocks") streamed every 200 milliseconds — that's 10x faster than Base's standard 2-second block time. Developed in collaboration with Flashbots and launched on Base Mainnet in July 2025, Flashblocks provide preconfirmations: ultra-fast signals that arrive before the next full block is sealed.
Here's how it works:
Standard Base blocks: Created every 2 seconds, containing all transactions
Flashblocks: 10 sub-blocks per full block, streamed every 200ms
Each Flashblock contains ~10% of the transactions (by gas) of a regular block
A series of Flashblocks can be combined to recreate a full block
Importance of Flashblocks for Trading
For trading applications, Flashblocks unlock several critical advantages:
Near-instant transaction feedback: Know within 200ms if your transaction was included
Front-running prevention: Once a Flashblock is built and broadcast, its transaction ordering is locked. Later-arriving transactions with higher fees can't jump ahead
Real-time state updates: See balance changes, liquidity shifts, and price movements as they happen
CEX-like experience on DEXs: Trading feels instant, not sluggish
What You're Building
In this tutorial, you'll build a Go application that:
Connects to the Base Flashblocks WebSocket stream
Handles both plain JSON and Brotli-compressed messages
Parses Flashblock data structures (transactions, receipts, balance updates)
Displays real-time blockchain activity
This forms the foundation for building trading bots, monitoring tools, or any application that needs ultra-low-latency blockchain data.
Understanding the Flashblock Data Structure
Before diving into code, let's understand what data you'll receive. Each Flashblock message contains three main components:
1. The Root Structure
The Index field tells you which of the 10 Flashblocks within a full block you're receiving (0 through 9).
2. BlockDiff — The Block Changes
Key fields for trading applications:
Transactions: Array of raw transaction data included in this Flashblock
StateRoot: Cryptographic proof of the blockchain state after these transactions
GasUsed: Total gas consumed by transactions in this Flashblock
3. Metadata — Balances and Receipts
This is where the trading gold is:
BlockNumber: The full block number this Flashblock belongs to
NewAccountBalances: Map of addresses to their updated ETH balances
Receipts: Transaction receipts with execution results and event logs
4. Receipts — Transaction Results
Receipts come in two flavors: EIP-1559 (modern) and Legacy. The Logs array contains event emissions — crucial for detecting swaps, transfers, and other contract events.
Create a new directory for your project and initialize the Go module:
Install the required dependencies:
Your go.mod file should look like this:
Building the Listener
Create main.go and start with the package and imports:
This imports standard library packages for JSON handling, logging, and signal management, plus our two external dependencies.
Define WebSocket endpoints and the data structures described earlier:
Now define all the data structures:
The GetData() and GetType() helper methods on Receipt let us work with receipts without worrying about whether they're EIP-1559 or Legacy format.
Implement the main routine: flag parsing, selecting the endpoint, connecting via WebSocket, and setting up message processing and graceful shutdown.
This covers:
Flag parsing for -network
WebSocket connection via gorilla/websocket
Signal handling for graceful shutdown
Message loop reading text or binary (Brotli) messages
Flashblock messages are typically Brotli-compressed. Decompress them with:
Unmarshal JSON into structs and print a readable summary.
Pretty-print the flashblock:
This output shows:
Flashblock index (0-9)
Block number and hash
Gas usage and roots
Transaction list (truncated hashes)
Balance update count
Receipt summaries
Running the Listener
1. Build and Run
Expected Output
When running, you'll see Flashblocks streaming in real-time:
You'll see new Flashblocks appear approximately every 200 milliseconds.
Shutting Down
Press Ctrl+C to stop the listener. It will send a proper WebSocket close message before exiting:
Extending for Trading Applications
Now that you have the basic listener working, here are some ways to extend it for trading:
1. Filter Transactions by Address
Monitor specific addresses (your wallet, a DEX router, etc.):
2. Detect Swap Events
Watch for Uniswap V2/V3 swap events by checking the first topic (event signature):
3. Track Balance Changes
Monitor when specific addresses receive or send ETH:
Important Considerations
Preconfirmation vs. Finality
Flashblocks provide preconfirmations, not final confirmations. While extremely reliable, there's a small chance (during rare reorgs) that a Flashblock's data might differ from the final block.
For critical transactions:
Use Flashblocks for fast UI feedback
Wait for full block confirmation for settlement
Rate Limits
The public endpoints (wss://mainnet.flashblocks.base.org/ws) are rate-limited. For production applications:
Use a node provider (GetBlock) with Flashblocks support
Consider running your own Flashblocks-aware node
Handling Disconnections
In production, add reconnection logic:
Complete Code
Here's the full main.go file:
Full Code
main.go
package main
import (
"bytes"
"encoding/json"
"flag"
"fmt"
"io"
"log"
"os"
"os/signal"
"syscall"
"github.com/andybalholm/brotli"
"github.com/gorilla/websocket"
)
const (
mainnetWSURL = "wss://mainnet.flashblocks.base.org/ws"
sepoliaWSURL = "wss://sepolia.flashblocks.base.org/ws"
)
// Flashblock represents the root structure of a flashblock message
type Flashblock struct {
Diff BlockDiff `json:"diff"`
Index int `json:"index"`
Metadata Metadata `json:"metadata"`
}
// BlockDiff contains the block differences/updates
type BlockDiff struct {
BlobGasUsed string `json:"blob_gas_used"`
BlockHash string `json:"block_hash"`
GasUsed string `json:"gas_used"`
LogsBloom string `json:"logs_bloom"`
ReceiptsRoot string `json:"receipts_root"`
StateRoot string `json:"state_root"`
Transactions []string `json:"transactions"`
Withdrawals []any `json:"withdrawals"`
WithdrawalsRoot string `json:"withdrawals_root"`
}
// Metadata contains block metadata including balances and receipts
type Metadata struct {
BlockNumber uint64 `json:"block_number"`
NewAccountBalances map[string]string `json:"new_account_balances"`
Receipts map[string]Receipt `json:"receipts"`
}
// Receipt represents a transaction receipt (can be EIP-1559 or Legacy)
type Receipt struct {
Eip1559 *ReceiptData `json:"Eip1559,omitempty"`
Legacy *ReceiptData `json:"Legacy,omitempty"`
}
// GetData returns the receipt data regardless of type
func (r *Receipt) GetData() *ReceiptData {
if r.Eip1559 != nil {
return r.Eip1559
}
return r.Legacy
}
// GetType returns the receipt type as a string
func (r *Receipt) GetType() string {
if r.Eip1559 != nil {
return "EIP-1559"
}
if r.Legacy != nil {
return "Legacy"
}
return "Unknown"
}
// ReceiptData contains the actual receipt information
type ReceiptData struct {
CumulativeGasUsed string `json:"cumulativeGasUsed"`
Logs []Log `json:"logs"`
Status string `json:"status"`
}
// Log represents an event log
type Log struct {
Address string `json:"address"`
Data string `json:"data"`
Topics []string `json:"topics"`
}
func main() {
network := flag.String("network", "mainnet", "Network to connect to: mainnet or sepolia")
flag.Parse()
var wsURL string
switch *network {
case "mainnet":
wsURL = mainnetWSURL
case "sepolia":
wsURL = sepoliaWSURL
default:
log.Fatalf("Invalid network: %s. Use 'mainnet' or 'sepolia'", *network)
}
log.Printf("Connecting to Base flashblocks on %s: %s", *network, wsURL)
conn, _, err := websocket.DefaultDialer.Dial(wsURL, nil)
if err != nil {
log.Fatalf("Failed to connect to WebSocket: %v", err)
}
defer conn.Close()
log.Println("Connected! Listening for flashblocks...")
// Handle graceful shutdown
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
done := make(chan struct{})
go func() {
defer close(done)
for {
messageType, message, err := conn.ReadMessage()
if err != nil {
if websocket.IsCloseError(err, websocket.CloseNormalClosure, websocket.CloseGoingAway) {
log.Println("WebSocket closed normally")
return
}
log.Printf("Error reading message: %v", err)
return
}
switch messageType {
case websocket.TextMessage:
handleFlashblockJSON(message)
case websocket.BinaryMessage:
decoded, err := decodeBrotli(message)
if err != nil {
log.Printf("Error decoding Brotli: %v", err)
log.Printf("Raw binary message length: %d bytes", len(message))
continue
}
handleFlashblockJSON(decoded)
default:
log.Printf("Received unknown message type: %d", messageType)
}
}
}()
select {
case <-done:
log.Println("Connection closed")
case sig := <-sigChan:
log.Printf("Received signal %v, shutting down...", sig)
err := conn.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseNormalClosure, ""))
if err != nil {
log.Printf("Error sending close message: %v", err)
}
}
}
func decodeBrotli(data []byte) ([]byte, error) {
reader := brotli.NewReader(bytes.NewReader(data))
return io.ReadAll(reader)
}
func handleFlashblockJSON(data []byte) {
var flashblock Flashblock
if err := json.Unmarshal(data, &flashblock); err != nil {
log.Printf("Error parsing flashblock JSON: %v", err)
log.Printf("Raw data: %s", string(data))
return
}
printFlashblock(&flashblock)
}
func printFlashblock(fb *Flashblock) {
fmt.Println("═══════════════════════════════════════════════════════════════")
fmt.Printf("FLASHBLOCK #%d | Block: %d | Hash: %s\n",
fb.Index,
fb.Metadata.BlockNumber,
truncateHash(fb.Diff.BlockHash))
fmt.Println("═══════════════════════════════════════════════════════════════")
fmt.Printf(" Gas Used: %s\n", fb.Diff.GasUsed)
fmt.Printf(" Blob Gas Used: %s\n", fb.Diff.BlobGasUsed)
fmt.Printf(" State Root: %s\n", truncateHash(fb.Diff.StateRoot))
fmt.Printf(" Receipts Root: %s\n", truncateHash(fb.Diff.ReceiptsRoot))
fmt.Printf("\n Transactions: %d\n", len(fb.Diff.Transactions))
for i, tx := range fb.Diff.Transactions {
fmt.Printf(" [%d] %s...\n", i, truncateHash(tx))
}
fmt.Printf("\n Account Balance Updates: %d\n", len(fb.Metadata.NewAccountBalances))
fmt.Printf("\n Receipts: %d\n", len(fb.Metadata.Receipts))
receiptCount := 0
for txHash, receipt := range fb.Metadata.Receipts {
if receiptCount >= 3 {
fmt.Printf(" ... and %d more receipts\n", len(fb.Metadata.Receipts)-3)
break
}
data := receipt.GetData()
if data != nil {
fmt.Printf(" [%s] %s - Status: %s, Logs: %d\n",
receipt.GetType(),
truncateHash(txHash),
data.Status,
len(data.Logs))
}
receiptCount++
}
fmt.Println()
}
func truncateHash(hash string) string {
if len(hash) <= 20 {
return hash
}
return hash[:10] + "..." + hash[len(hash)-8:]
}
Conclusion
You've built a real-time Base Flashblocks listener in Go that:
Connects to the Flashblocks WebSocket stream
Handles Brotli-compressed messages
Parses and displays transaction data, receipts, and balance updates
type Flashblock struct {
Diff BlockDiff `json:"diff"` // Block differences/updates
Index int `json:"index"` // Flashblock index (0-9 within a block)
Metadata Metadata `json:"metadata"` // Block metadata
}
func printFlashblock(fb *Flashblock) {
fmt.Println("═══════════════════════════════════════════════════════════════")
fmt.Printf("FLASHBLOCK #%d | Block: %d | Hash: %s\n",
fb.Index,
fb.Metadata.BlockNumber,
truncateHash(fb.Diff.BlockHash))
fmt.Println("═══════════════════════════════════════════════════════════════")
fmt.Printf(" Gas Used: %s\n", fb.Diff.GasUsed)
fmt.Printf(" Blob Gas Used: %s\n", fb.Diff.BlobGasUsed)
fmt.Printf(" State Root: %s\n", truncateHash(fb.Diff.StateRoot))
fmt.Printf(" Receipts Root: %s\n", truncateHash(fb.Diff.ReceiptsRoot))
fmt.Printf("\n Transactions: %d\n", len(fb.Diff.Transactions))
for i, tx := range fb.Diff.Transactions {
fmt.Printf(" [%d] %s...\n", i, truncateHash(tx))
}
fmt.Printf("\n Account Balance Updates: %d\n", len(fb.Metadata.NewAccountBalances))
fmt.Printf("\n Receipts: %d\n", len(fb.Metadata.Receipts))
receiptCount := 0
for txHash, receipt := range fb.Metadata.Receipts {
if receiptCount >= 3 {
fmt.Printf(" ... and %d more receipts\n", len(fb.Metadata.Receipts)-3)
break
}
data := receipt.GetData()
if data != nil {
fmt.Printf(" [%s] %s - Status: %s, Logs: %d\n",
receipt.GetType(),
truncateHash(txHash),
data.Status,
len(data.Logs))
}
receiptCount++
}
fmt.Println()
}
func truncateHash(hash string) string {
if len(hash) <= 20 {
return hash
}
return hash[:10] + "..." + hash[len(hash)-8:]
}
# Build the application
go build -o flashblocks-listener
# Run on mainnet (default)
./flashblocks-listener
# Run on Sepolia testnet
./flashblocks-listener -network=sepolia
^C2026/01/23 12:06:59 Received signal interrupt, shutting down...
func filterByAddress(fb *Flashblock, targetAddress string) {
for txHash, receipt := range fb.Metadata.Receipts {
data := receipt.GetData()
if data == nil {
continue
}
for _, logEntry := range data.Logs {
if strings.EqualFold(logEntry.Address, targetAddress) {
fmt.Printf("Activity detected! TX: %s\n", txHash)
// Process the event...
}
}
}
}
const (
// Uniswap V2 Swap event signature
uniswapV2Swap = "0xd78ad95fa46c994b6551d0da85fc275fe613ce37657fb8d5e3d130840159d822"
// Uniswap V3 Swap event signature
uniswapV3Swap = "0xc42079f94a6350d7e6235f29174924f928cc2ac818eb64fed8004e115fbcca67"
)
func detectSwaps(fb *Flashblock) {
for txHash, receipt := range fb.Metadata.Receipts {
data := receipt.GetData()
if data == nil {
continue
}
for _, logEntry := range data.Logs {
if len(logEntry.Topics) > 0 {
switch logEntry.Topics[0] {
case uniswapV2Swap:
fmt.Printf("Uniswap V2 Swap in TX: %s\n", txHash)
case uniswapV3Swap:
fmt.Printf("Uniswap V3 Swap in TX: %s\n", txHash)
}
}
}
}
}
func trackBalanceChanges(fb *Flashblock, watchAddresses []string) {
for _, addr := range watchAddresses {
if newBalance, exists := fb.Metadata.NewAccountBalances[addr]; exists {
fmt.Printf("Balance update for %s: %s\n", addr, newBalance)
}
}
}
Think of it like texting vs. email. Traditional blocks are like writing an entire email, proofreading it, and hitting send. Flashblocks are like texting — you send each line instantly and keep going.
How to Build a Hyperliquid Whale Tracker Bot with GetBlock
A step by step guide on how to build an Hyperliquid Whale Tracker Bot using GetBlock API
Whales are entities, such as DAOs or companies, that hold a large amount of a particular cryptocurrency, sufficient to influence the market price through their transactions. Their trade alone can either deflate or inflate the market price. While some whales engage in large trades that have a natural market effect, others may intentionally try to manipulate the market for profit.
The Whale Tracking Bot is a bot that monitors on-chain activities of whales. It reports their transactions to you, thereby providing a clear analysis to inform predictions about potential market movements.
Identifies large trades based on configurable thresholds
Detects whale walls in the orderbook
Prerequisites
Basic knowledge of JavaScript
Must have installed and
A
A
Step 1. Create Telegram Bot
Bot Token:
Open Telegram and search for @BotFather
Send /newbot and follow instructions
Step 2. Set up Development Environment
Before you begin, you need to set up your development environment:
Step 3. Getting your HyperEVM Websocket Token
Log in to your
On your dashboard, scroll and click on Get Endpoint
Select the HyperEVM Mainnet network
Project Structure
Create the following files to have a basic structure for your project:
Step 4. Set up Environment Variables
Update the .env file in the root of your project and add the following variables:
Step 5. Build Whale Tracker Bot
1. Import dependencies:
Import the dependencies and load the environment variables from .env file
2. Set up configuration settings:
Set up configuration settings for your application, including environment variables and other constants.
3. Create the Main Class with Private Fields:
Why private fields?
# prefix makes fields private (ES2022 feature)
Prevents external code from modifying internal state
Better encapsulation and code organization
4. Connect to Hyperliquid WebSocket:
Event handlers:
open - Triggered when the connection is established
message - Receives data from the server
error - Handles connection errors
5. Subscribe to Data Streams:
Subscription types:
allMids - Current market prices for all symbols
trades - Real-time trade executions
l2Book - Level 2 orderbook (buy/sell walls)
6. Handle Incoming Messages:
Message routing:
Parse JSON data from WebSocket
Route to the appropriate handler based on channel type
Graceful error handling with try-catch
7. Update Price Cache
Why cache prices?
Used for calculating USD value of trades
Avoids repeated API calls
Provides a fallback when price data is missing
8. Analyze Trades for Whales
Trade data structure:
coin - Market symbol (BTC, ETH, etc.)
side - 'B' for buy, 'A' for ask/sell
px - Price (as string)
9. Track Whale Addresses
Whale profile includes:
Total trading volume (cumulative)
Number of trades executed
First and last seen timestamps
Set of markets they trade in
10. Analyze Orderbook for Whale Walls
Orderbook structure:
levels[0] - Bid side (buy orders)
levels[1] - Ask side (sell orders)
Each level is [price, size] array
Whale walls:
Large limit orders in the orderbook
Can act as support (bids) or resistance (asks)
Indicate where whales are defending price levels
11. Send Trade Notifications
Notification features:
Color-coded emojis (green=buy, red=sell)
Shortened wallet address for readability
Historical stats for known whales
Special highlight for mega trades ($500k+)
12. Implement Telegram Batching
Why batch alerts?
Telegram has rate limits (1 message/second)
Batching prevents hitting limits during high activity
Combines multiple alerts into one clean summary
Configurable interval (default: 10 seconds)
13. Implement Telegram Queue System
Queue system benefits:
Messages are queued and processed sequentially
Respects Telegram's rate limits
Automatic retry on 429 errors
Non-blocking (uses async/await)
14. Test Telegram Connection
Connection test:
Validates bot token on startup
Shows bot username
Sends test message
Provides helpful error messages
15. Implement Auto-Reconnection
Reconnection strategy:
Exponential backoff (delays increase)
Maximum 5 attempts
Caps at 30 seconds between tries
Separate handling for different connections
16. Generate Statistics Dashboard
Statistics include:
Total number of whale trades detected
Number of unique whale addresses
Top 10 whales ranked by volume
Individual whale profiles with activity metrics
17. Create the Start Method
Startup sequence:
Display configuration
Test Telegram connection
Connect to Hyperliquid WebSocket
Optionally connect to HyperEVM
18. Initialize and Run the Bot
Proper shutdown:
Closes WebSocket connections properly
Prevents data loss or hanging connections
Running and Testing the Application
Open your terminal and run the following command:
Expected result in console:
Expected result in Telegram:
Troubleshooting
You may run into a WebSocket 503 Error:
This means that your WebSocket endpoint is incorrect. Check your .env file and ensure it's in this pattern:
Then, restart the server.
Conclusion
In this guide, you have successfully learn and built a Hyperliquid Whale Tracker Bot that monitors and alerts all whale trade activities — from major buys to large sell-offs — and even detects whale walls in the order book.
By integrating the GetBlock WebSocket API, you can rest assured of fast, reliable, and real-time data delivery, ensuring you never miss significant market movements.
class HyperliquidWhaleTracker {
// Private fields (only accessible within the class)
#ws = null; // Hyperliquid WebSocket connection
#wsHyperEVM = null; // HyperEVM WebSocket connection
#reconnectAttempts = 0; // Track reconnection attempts
#maxReconnectAttempts = 5; // Maximum reconnection tries
#priceCache = new Map(); // Store current prices
#whaleAddresses = new Map(); // Track whale wallet addresses
#tradeCount = 0; // Total whale trades detected
#telegramQueue = []; // Queue for Telegram messages
#isSendingTelegram = false; // Flag for queue processing
#lastTelegramSent = 0; // Timestamp of last message
#TELEGRAM_DELAY = 1500; // Delay between messages (ms)
#pendingAlerts = []; // Batch alerts before sending
#batchTimer = null; // Timer for batching
constructor() {
this.HYPERLIQUID_WS_URL = 'wss://api.hyperliquid.xyz/ws';
}
}
async connectHyperliquid() {
console.log('Connecting to Hyperliquid Info WebSocket...');
this.#ws = new WebSocket(this.HYPERLIQUID_WS_URL);
this.#ws.on('open', () => {
console.log('✅ Connected to Hyperliquid Info API');
this.#subscribeToTrades();
this.#subscribeToOrderbook();
});
this.#ws.on('message', (data) => this.#handleHyperliquidMessage(data));
this.#ws.on('error', (error) => console.error('Hyperliquid error:', error.message));
this.#ws.on('close', () => this.#handleReconnect('hyperliquid'));
}
#subscribeToTrades() {
// Subscribe to price updates
this.#ws.send(JSON.stringify({
method: 'subscribe',
subscription: { type: 'allMids' }
}));
// Subscribe to trades for each tracked symbol
for (const symbol of CONFIG.TRACKED_SYMBOLS) {
this.#ws.send(JSON.stringify({
method: 'subscribe',
subscription: { type: 'trades', coin: symbol }
}));
}
console.log('📡 Subscribed to Hyperliquid trades');
}
#subscribeToOrderbook() {
// Subscribe to orderbook depth for whale wall detection
for (const symbol of CONFIG.TRACKED_SYMBOLS) {
this.#ws.send(JSON.stringify({
method: 'subscribe',
subscription: { type: 'l2Book', coin: symbol }
}));
}
console.log('📊 Subscribed to orderbook data');
}
#handleHyperliquidMessage(data) {
try {
const message = JSON.parse(data.toString());
// Route messages based on channel type
switch (message.channel) {
case 'trades':
message.data?.forEach(trade => this.#analyzeTrade(trade));
break;
case 'allMids':
this.#updatePrices(message.data);
break;
case 'l2Book':
this.#analyzeOrderbook(message.data);
break;
}
} catch (error) {
console.error('Error parsing message:', error.message);
}
}
#updatePrices(midsData) {
if (!midsData?.mids) return;
// Store current prices in a Map for quick lookup
for (const [symbol, price] of Object.entries(midsData.mids)) {
this.#priceCache.set(symbol, parseFloat(price));
}
}
#analyzeTrade(trade) {
try {
const { coin, side, px, sz, time, user, hash, tid } = trade;
const price = parseFloat(px);
const size = parseFloat(sz);
const value = price * size; // Calculate USD value
// Check if trade meets whale threshold
if (value < CONFIG.WHALE_THRESHOLD_USD && size < CONFIG.WHALE_THRESHOLD_SIZE) {
return; // Not a whale trade, skip
}
// Track the whale's address
if (user) {
this.#trackWhaleAddress(user, value, coin);
}
// Send notification
this.#notifyWhaleTrade({
coin,
side,
price,
size,
value,
time: new Date(time).toLocaleString(),
user: user || 'Unknown',
hash: hash || null,
tradeId: tid || null
});
this.#tradeCount++;
} catch (error) {
console.error('Error analyzing trade:', error.message);
}
}
#trackWhaleAddress(address, value, coin) {
const whale = this.#whaleAddresses.get(address);
if (whale) {
// Existing whale - update stats
whale.totalVolume += value;
whale.tradeCount++;
whale.lastSeen = new Date();
whale.coins.add(coin);
} else {
// New whale - create profile
this.#whaleAddresses.set(address, {
address,
totalVolume: value,
tradeCount: 1,
firstSeen: new Date(),
lastSeen: new Date(),
coins: new Set([coin])
});
}
}
#analyzeOrderbook(bookData) {
try {
const { coin, levels } = bookData;
if (!Array.isArray(levels)) return;
const largeOrders = [];
// Analyze both bid (buy) and ask (sell) sides
for (const [index, side] of ['BID', 'ASK'].entries()) {
if (!Array.isArray(levels[index])) continue;
for (const level of levels[index]) {
// Handle different data formats
const [price, size] = Array.isArray(level)
? level
: [level.px, level.sz];
if (!price || !size) continue;
const value = parseFloat(price) * parseFloat(size);
// Check if it's a whale-sized order
if (value >= CONFIG.WHALE_THRESHOLD_USD) {
largeOrders.push({
side,
price: parseFloat(price),
size: parseFloat(size),
value
});
}
}
}
if (largeOrders.length > 0) {
this.#notifyWhaleOrder(coin, largeOrders);
}
} catch (error) {
console.error('Error analyzing orderbook:', error.message);
}
}
Connecting to GetBlock WebSocket...
WebSocket error: Error: Unexpected server response: 503
WebSocket connection closed
Reconnecting in 16 seconds... (Attempt 4)
# correct format
HYPEREVM_WSS=wss://go.getblock.io/<ACCESS_TOKEN>
node index.js
How to Build a Pay-Per-Request Blockchain API With x402 and GetBlock
Build a pay-per-request blockchain data API using the x402 protocol and GetBlock's node infrastructure.
Overview
The x402 protocol is an open payment method that enables developers and service providers to charge for and sell their APIs and content via HTTP without requiring third-party integrations, credential setup, or gas fees.
The x402 protocol brings the HTTP 402 "Payment Required" status code to life. Originally reserved in the HTTP specification for future use with digital payments, x402 finally implements this vision, enabling micropayments to be made directly over HTTP.
How it works
Frank adds "payment required" to his API endpoints
His client requests a protected resource,
The server responds with 402 Payment Required along with payment details.
All of this happens in seconds, without traditional payment infrastructure.
Traditional API monetization requires
With x402
Components of x402
The x402 ecosystem consists of three main components, which are:
Client Side:
This is the interface e.g frontend, that users interact with, which initiates a request to access a paid resource. It handles the payment requirements, prepare payment payload and resubmits the request with payment.
Server Side:
The server is the resource provider enforcing payment for access to its services, such as API services, content providers, or any HTTP-accessible resource requiring monetization. It defines payment requirements, verifies payment payloads, settles transactions, and provides the resources.
Facilitators:
The facilitator is an optional but recommended service that verifies and settles payment between clients and servers.
Architecture Overview
Key Components Explained:
Component
Role
SDK to Use
Who is x402 For?
API Developers — Monetize your APIs without managing subscriptions or API keys
AI Agents — Enable autonomous systems to pay for resources programmatically
Content Creators — Charge per article, image, or download
Real-Life Use Cases
AI Agent Economy — AI agents paying for web searches, API calls, or compute resources
Pay-Per-Article News — Read individual articles without monthly subscriptions
Blockchain Data Services — Pay-per-query for on-chain analytics
What You're Building
In this guide, you'll build a complete pay-per-request blockchain data API:
Backend: Express.js server with x402 payment middleware
Frontend: Vanilla JavaScript dApp with MetaMask integration
Data Source: GetBlock's Ethereum node API
Endpoints you'll create:
Endpoint
Price
Description
Prerequisites
Node.js 18+
MetaMask wallet
Base Sepolia USDC (from )
(free tier available)
A. Project Setup
Step 1: Create Project Directories
Step 2: Initialize Server Package
Step 3: Install Dependencies
Dependency Overview:
Package
Purpose
Step 4: Configure package.json
Update server/package.json:
Folder Structure
Create the following project structure:
Backend: Express Server with x402
Step 1: Environment Configuration
Create server/.env:
Step 2: Create the Server
Create server/server.js and add the following code:
Frontend: Vanilla JS dApp
Create client/index.html and add the following code:
Running the Application
Step 1: Start the Server
You should see:
Step 2: Access the Frontend
Open your browser and navigate to:
Your frontend should look like this:
Connect your wallet
Select any of the endpoints you want to access
Sign the request
The payment is then verified, scroll down to see the result
Troubleshooting
"Failed to create payment payload: Address undefined": This means the wallet client was not properly initialized. Make sure you're using getAddress() to normalize the address:
CORS Errors: This means the server not configured for x402 headers. Ensure CORS middleware includes x402 headers:
"Facilitator does not support scheme": This mean the facilitator is unreachable or doesn't support your network. To resolve this:
i. Check internet connection
ii. Try an alternative facilitator: https://facilitator.payai.network
iii. Verify you're using the correct network ID: eip155:84532
"Facilitator Connectivity Issues"
If the default facilitator is down, you can try:
Wallet Signing Problems
If MetaMask shows an error during signing:
Check network — Ensure you're on Base Sepolia (Chain ID 84532)
Check balance — Ensure you have enough USDC for the request
Debug Mode
Enable the debug log by clicking "Toggle Debug Log" at the bottom of the page. This shows:
Connection steps
Network switching
Signing requests
API responses
Resources
Conclusion
In this guide, you learnt what x402 is all about, including its use cases, components, architecture diagram etc. You also learnt how to set up the project and built a complete pay-per-request blockchain data API using x402 and GetBlock.
The client signs a payment authorisation
He/she retries the request and receives the data.
Instant micropayments — Charge per request
Fraud prevention and rate limiting
Built-in rate limiting — Users only call what they pay for
Transaction or gas fee
Gasless fee
Third-party service that verifies payment signatures and settles USDC transfers.
https://x402.org/facilitator
https://facilitator.payai.network
Data Providers — Sell real-time data feeds with per-request pricing
Blockchain Services — Offer RPC access, indexing, or analytics with micropayments
Premium API Access — Charge for rate-limited or enhanced API endpoints
Decentralized CDN — Pay nodes for bandwidth and storage per request
# Your wallet address to receive payments
PAYMENT_WALLET_ADDRESS=0xYourWalletAddressHere
# GetBlock API key (optional - will use mock data if not set)
GETBLOCK_API_KEY=your_getblock_api_key_here
# Server port
PORT=4021
server/server.js
import express from "express";
import cors from "cors";
import path from "path";
import { fileURLToPath } from "url";
import { paymentMiddleware } from "@x402/express";
import { x402ResourceServer, HTTPFacilitatorClient } from "@x402/core/server";
import { registerExactEvmScheme } from "@x402/evm/exact/server";
import axios from "axios";
import "dotenv/config";
// ES Module directory resolution
const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);
const app = express();
// =============================================================================
// CORS Configuration
// =============================================================================
// x402 uses custom headers for payment data, so we need to expose them
app.use(
cors({
origin: true,
credentials: true,
methods: ["GET", "POST", "OPTIONS"],
allowedHeaders: [
"Content-Type",
"Authorization",
"X-PAYMENT",
"X-Payment",
"x-payment",
],
exposedHeaders: [
"X-PAYMENT-RESPONSE",
"X-Payment-Response",
"x-payment-response",
"X-PAYMENT-REQUIRED",
"X-Payment-Required",
"x-payment-required",
],
})
);
app.use(express.json());
// =============================================================================
// Request Logging (for debugging)
// =============================================================================
app.use((req, res, next) => {
console.log(`[${new Date().toISOString()}] ${req.method} ${req.path}`);
const paymentHeader = req.headers["x-payment"] || req.headers["X-PAYMENT"];
if (paymentHeader) {
console.log(" Payment header present (length:", paymentHeader.length, ")");
}
next();
});
// =============================================================================
// Configuration
// =============================================================================
const payTo = process.env.PAYMENT_WALLET_ADDRESS;
const GETBLOCK_API_KEY = process.env.GETBLOCK_API_KEY;
const GETBLOCK_URL = GETBLOCK_API_KEY
? `https://go.getblock.io/${GETBLOCK_API_KEY}`
: null;
console.log("\n📋 Configuration:");
console.log(` Payment wallet: ${payTo}`);
console.log(` GetBlock API: ${GETBLOCK_API_KEY ? "Configured" : "Not configured (using mock data)"}`);
// Validate required config
if (!payTo) {
console.error("❌ Missing PAYMENT_WALLET_ADDRESS in .env");
process.exit(1);
}
// =============================================================================
// GetBlock API Helper
// =============================================================================
async function callGetBlock(method, params = []) {
// If no API key, return mock data for demo purposes
if (!GETBLOCK_URL) {
console.log(" Using mock data (no GetBlock API key)");
if (method === "eth_blockNumber") {
const mockBlock = Math.floor(Date.now() / 1000);
return { result: "0x" + mockBlock.toString(16) };
}
if (method === "eth_gasPrice") {
return { result: "0x" + (20 * 1e9).toString(16) }; // 20 Gwei
}
return { result: null };
}
// Call GetBlock API
try {
const response = await axios.post(GETBLOCK_URL, {
jsonrpc: "2.0",
id: "getblock",
method,
params,
});
return response.data;
} catch (error) {
console.error(" GetBlock API error:", error.message);
throw error;
}
}
// =============================================================================
// x402 Setup
// =============================================================================
// Initialize the facilitator client
// The facilitator verifies payment signatures and settles transactions
const facilitatorUrl = "https://facilitator.payai.network";
console.log(` Facilitator: ${facilitatorUrl}`);
const facilitatorClient = new HTTPFacilitatorClient({
url: facilitatorUrl,
});
// Create the resource server and register the EVM payment scheme
const server = new x402ResourceServer(facilitatorClient);
registerExactEvmScheme(server);
// =============================================================================
// Payment Route Configuration
// =============================================================================
// Define which routes require payment and how much they cost
const paymentConfig = {
"GET /api/eth/block/latest": {
accepts: [
{
scheme: "exact", // Payment scheme (exact amount)
price: "$0.001", // Price in USD
network: "eip155:84532", // Base Sepolia (CAIP-2 format)
payTo, // Your wallet address
},
],
description: "Get latest Ethereum block number",
mimeType: "application/json",
},
"GET /api/eth/gas": {
accepts: [
{
scheme: "exact",
price: "$0.001",
network: "eip155:84532",
payTo,
},
],
description: "Get current gas price",
mimeType: "application/json",
},
};
// Apply the payment middleware
// This intercepts requests to protected routes and verifies payment
app.use(paymentMiddleware(paymentConfig, server));
// =============================================================================
// Static Files & Routes
// =============================================================================
// Serve the frontend
app.use(express.static(__dirname));
app.get("/", (req, res) => {
res.sendFile(path.join(__dirname, "../client/index.html"));
});
// Free endpoint: API information
app.get("/api", (req, res) => {
res.json({
message: "GetBlock x402 API",
version: "1.0.0",
network: "Base Sepolia (eip155:84532)",
facilitator: facilitatorUrl,
payTo,
endpoints: [
{
path: "/api/eth/block/latest",
price: "$0.001 USDC",
description: "Get latest Ethereum block number",
},
{
path: "/api/eth/gas",
price: "$0.001 USDC",
description: "Get current gas price",
},
],
});
});
// =============================================================================
// Protected Endpoints (require payment)
// =============================================================================
// Get latest block number
app.get("/api/eth/block/latest", async (req, res) => {
console.log(" ✓ Payment verified - serving block data");
try {
const result = await callGetBlock("eth_blockNumber");
res.json({
blockNumber: result.result,
decimal: parseInt(result.result, 16),
timestamp: new Date().toISOString(),
source: GETBLOCK_URL ? "getblock" : "mock",
});
} catch (error) {
console.error(" Error fetching block number:", error.message);
res.status(500).json({ error: error.message });
}
});
// Get current gas price
app.get("/api/eth/gas", async (req, res) => {
console.log(" ✓ Payment verified - serving gas data");
try {
const result = await callGetBlock("eth_gasPrice");
const gasPriceWei = BigInt(result.result);
res.json({
gasPriceWei: result.result,
gasPriceGwei: (Number(gasPriceWei) / 1e9).toFixed(2),
timestamp: new Date().toISOString(),
source: GETBLOCK_URL ? "getblock" : "mock",
});
} catch (error) {
console.error(" Error fetching gas price:", error.message);
res.status(500).json({ error: error.message });
}
});
// =============================================================================
// Error Handling
// =============================================================================
app.use((err, req, res, next) => {
console.error("Server error:", err);
res.status(500).json({ error: err.message });
});
// =============================================================================
// Start Server
// =============================================================================
const PORT = process.env.PORT || 4021;
app.listen(PORT, () => {
console.log(`Server running at http://localhost:${PORT}`);
console.log("Protected endpoints:");
Object.entries(paymentConfig).forEach(([route, config]) => {
console.log(` ${route} - ${config.accepts[0].price} USDC`);
})
});
const facilitatorClient = new HTTPFacilitatorClient({
url: "https://x402.org/facilitator", // Alternative facilitator
});
Clients do not need to manage accounts, credentials, or session tokens beyond their crypto wallet. All interactions are stateless and occur over standard HTTP requests.
Servers do not need to manage client identities or maintain session state. Verification and settlement are handled per request.
Replace 0xYourWalletAddressHere with your actual MetaMask wallet address. This is where you'll receive USDC payments.
