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.
GetBlock's Sign-Up page, where users can register to access blockchain services
2
Choose the sign-up method
Register with Email
Enter your name and email address, then verify your email to activate the account.
Sign in via Google
Google will share your name, email, language preferences, and profile picture with GetBlock.
Connect with MetaMask
Use a MetaMask wallet browser extension to sign up – no email or password required. If you don’t have a wallet extension installed, you’ll be prompted to add one.
WalletConnect
Sign in with MetaMask Mobile, Trust Wallet, Rabby, Ledger Live, or another WalletConnect-compatible wallet.
Once you've created an account and signed in, you'll be directed to the GetBlock Dashboard.
You can create endpoints
Monitor your usage plan
Access statistics.
GetBlock user Dashboard
Check your User ID
Click on your profile icon
Click on the Copy Icon to copy your User ID
Access token management
GetBlock uses a secure authentication method based on access tokens to ensure that only authorized users can interact with blockchain nodes.
Every endpoint 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.
Access tokens cannotbesent in headers.
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.
Plans and limits
GetBlock offers flexible RPC plans and features to support developers and businesses at any stage, from small projects to high-traffic platforms
Start here to choose a plan, understand usage limits, and manage billing.
Choosing Your Plan
Compare Shared Nodes, Limitless Node, and Dedicated Nodes.
CU and Rate Limits
GetBlock's Compute Unit (CU) and requests-per-second (RPS) limits across plans.
Limitless Node
Explore the Limitless plan without CU and request limits.
What counts as a CU?
Compute Units (CUs) explained.
Top up CUs
Add more CUs to your active plan.
Dedicated Nodes
Manage & extend Dedicated Node subscriptions.
Payment Methods
Set up billing with fiat or crypto.
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
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 Dedicated Nodes.
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.
Selecting fiat as a payment method
Please, account for VAT when planning your payments.
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.
Crypto 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.
Endpoint setup
Configure, set up and manage blockchain node endpoints with GetBlock.
This section covers creating shared node endpoints, generating access tokens, and configuring dedicated nodes with customizable settings.
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}.
Using Postman to send a JSON-RPC request to an Ethereum node via GetBlock
This token will grant you the necessary permissions to explore our node functionalities.
Errors and troubleshooting
This page provides a guide to common JSON-RPC and HTTP errors when testing your connection with GetBlock's API.
Connection issues
Code
Error message
Solution
401
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 specifications.
32602
Invalid argument
Ensure the parameters in the params array match the expected format for the method.
32700
Parse error
Double-check your JSON syntax. Ensure your request is properly formatted.
Overview
GetBlock exposes Flashblocks' data on supported OP Stack networks through the standard JSON-RPC and WebSocket interfaces.
Flashblocks are partial blocks streamed by the sequencer as it builds. The mechanism is powered by Rollup-Boost, a sequencer sidecar built by Flashbots in collaboration with OP Labs. A single OP Stack block is divided into ten Flashblocks streamed at 200ms intervals, each one a delta containing the new transactions and resulting state changes since the previous Flashblock. The preconfirmed state is surfaced through the standard Ethereum JSON-RPC interface using the pending block tag, so existing tooling reads Flashblock state without modification.
How Flashblocks Work
A standard OP Stack block is produced every 2 seconds. Flashblocks subdivide that interval into ten increments:
The sequencer publishes a new Flashblock every ~200ms (index 0 through 9 within each parent block).
index 0 carries the base block context; subsequent Flashblocks carry only the diff of new transactions and state changes.
Reading any supported method against the pending tag returns the accumulated preconfirmed state from the latest Flashblock.
The same call against latest returns the most recent fully sealed block.
Preconfirmations are strong signals, not guarantees. A streamed Flashblock can be excluded from the final block (a Flashblock reorg). The reorg rate is below 0.1%, but applications handling critical operations should confirm against finalized block data.
How to Use Flashblocks
There are two access patterns:
pending tag (request/response): Pass "pending" as the block parameter to any supported read method to get the latest preconfirmed value over HTTP. This is the recommended approach for most applications, as it provides stable behavior with automatic fallback to standard blocks if Flashblocks become unavailable.
WebSocket streaming (subscriptions): Open a WebSocket connection and subscribe to a Flashblocks topic to receive each Flashblock as it is produced — five times per second. This is intended for latency-sensitive consumers such as trading systems. Applications should avoid a hard dependency on the WebSocket stream and treat it as an optimization layer over the RPC interface.
Flashblocks are simply a class of RPC API methods that are now active on GetBlock endpoints for Base and Optimism. If you already run either chain with GetBlock, the new methods are available on your existing endpoint. If you are new, set up a Base or Optimism endpoint from the GetBlock dashboard, and the methods are there.
Supported Networks
Flashblocks are documented per network. Endpoints, method tables, and chain-specific methods are covered on the dedicated pages:
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
Authentication
All requests require an API key in the header:
Getting your API key
Generate API keys under Settings → API. Open Settings, go to the API tab, and create a key for your needs. Copy and save it right away — treat it as a secret: anyone holding your API key can spend the credits you've topped up on the platform. Store it following security best practices (never commit it to code or share it in plain text).
You pay in Credits. The price is calculated from two live inputs:
the current TRX/USD exchange rate, and
real-time energy demand on the network.
You are charged only after the delegation is confirmed — if the order fails, nothing is deducted from your balance.
Energy prices fluctuate over time. Demand follows on-chain activity across the world's major financial clusters — Asia, Europe, and the US — so the price rises and falls as different time zones become active and quiet through the day. The swing can be large: in calmer windows energy can be significantly cheaper — sometimes around half the price of peak hours.
If getting a lower price matters to you, monitor the live price and rent when it fits your budget. There is no fixed "cheap hour" — because activity shifts between regions, the best window varies, so watch the actual numbers rather than relying on a fixed schedule.
price-estimate - TRON energy
Example code for the price-estimate JSON RPC method
This get a real-time price estimate for Energy delegation before placing an order.
Body Parameter
Parameter
Type
Required
Description
resourceType
string
Yes
"energy", "bandwidth"(soon)
volume
integer
Yes
Energy amount: 30,000 - 5,000,000 (depends on duration)
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
Plug-and-Play access
Our ready-to-use blockchain nodes and APIs help you get started immediately.
99.9% uptime
Reliable 24/7 connection to multiple blockchain networks.
Multi-chain support
Connect to Bitcoin, Ethereum, BNB Chain, Polygon, Solana, TON, and 100+ other networks. (And we support new protocols before anyone else)
Flexible plans
From free access to enterprise-grade solutions, we’ve got options for every stage of your project.
Custom solutions
Need something unique? We can build tailored solutions for your specific blockchain needs.
24/7 Expert support
Our team is here to help with integrations, troubleshooting, and scaling.
Discover GetBlock
Getting Started
Create your account, explore plans & features, and make your first API call
Guides
Set up endpoints, manage access tokens, and integrate GetBlock APIs step-by-step
API Reference
View supported networks, available endpoints, and full API specifications
Popular chains
Get started with our most in-demand blockchain networks.
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.
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.
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 .
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.
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).
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 .
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".
This table provides a breakdown of actions team account users can perform based on their role.
Action
Owner
Admin
Member
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.
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.
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.
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).
If you run into any issues or have questions, please check out our or visit our . You can also use the Help button within your GetBlock dashboard to access support or submit a request.
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.
In GetBlock, an endpoint URL includes your unique Access Token — the credential that authenticates RPC requests. GetBlock’s UI sometimes labels the whole endpoint provisioning flow “Get Access Token” because a new RPC URL is created together with the token.
Related:
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
Find the Endpoints section on the Dashboard
3
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
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.
When creating an endpoint in your GetBlock Dashboard, for select protocols, you can choose between two node access modes – Full and Archive. This selection determines how much historical blockchain data your endpoint can access.
Full mode: Standard full (pruned) node behavior — current state lookups, sending transactions, reading blocks, etc.
Archive mode: Enables access to the historical chain state. Useful for querying balances, contract storage, UTXO sets, executing historical calls, simulating transactions at a past block, or reconstructing chain state for analytics and audits.
The created URL is shown on the endpoints list so you can copy it and start calling the node. Use the right-side menu () to roll (regenerate) or delete the endpoint from the list.
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)
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
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)
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.
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.
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.
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.
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.
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.
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 file from your GetBlock account;
Make sure you have installed. jq is a versatile command-line tool that enables extracting values from JSON files;
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:
The result field shows the account balance in wei (1 ether = 10¹⁸ wei).
For a list of supported RPC methods with examples, navigate to .
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:
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.
Customize the data view by parameters or by accesstokens using the dropdown menu.
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
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.
Users can also choose whether to receive marketing communications from GetBlock. This preference can be managed in Account Settings → General by enabling or disabling the “I want to receive marketing offers” option.
Connect to GetBlock with MetaMask
Learn how to set up custom RPC URL on MetaMask for faster, more reliable, and secure blockchain interactions.
MetaMask is a blockchain wallet available as a mobile application and a browser extension. It allows you to interact with Ethereum-based decentralized applications (dApps) directly from your browser.
This step-by-step tutorial will guide you through connecting GetBlock’s powerful nodes to your MetaMask wallet.
If you don’t already have MetaMask, download and install it from the official website: .
MetaMask extension is officially supported on Chrome, Brave, Firefox, Microsoft Edge, and Opera browsers.
Generate a JSON-RPC URL for the selected network from your GetBlock and copy it.
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.
In a standard setup, your node receives data through the BSC peer-to-peer gossip network:
With BDN Gateway acceleration, your node receives data through two channels simultaneously:
Your dedicated node receives data from both the BDN fast path and the standard P2P layer, ensuring it always has the freshest state available.
Sending Transactions to Private Mempool (Priority Fee)
Learn how to add tips to transaction while sending to private mempool
Priority fees incentivize builders to include your transaction faster and position it more favorably within a block. Adding a tip to your private transaction provides three key benefits:
Higher inclusion probability: Builders prioritize transactions with higher fees
Better block positioning: Achieve positions 1–2 more reliably
Faster confirmation: Reduce waiting time for transaction inclusion
Choosing a Method
They are Two approaches exist for adding priority fees to private transactions:
Method
Best For
Trade-offs
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
Next Steps
Learn how to submit transactions via Multicall3 or Bundle method to the private mempool.
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.
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.
Complete historical index: Every block, transaction, instruction, log, and account update already parsed, normalized, and ready for queries
Overview
GetBlock Crypto AML is a compliance-grade risk-screening service for crypto addresses and transactions
GetBlock Crypto AML is a compliance-grade risk-screening service for crypto addresses and transactions. Paste a wallet or a transaction hash, and get back a structured risk report — a composite score, an exposure breakdown, and FATF-aligned flags — in seconds.
It is built to give small teams, exchanges, OTC desks and individual traders the same FATF-aligned data and scoring that large compliance vendors offer, but without KYB, annual contracts, or lengthy onboarding. The same account and the same credit balance power both the browser UI and the REST API.
The problem it solves
Before you accept, send, or clear crypto funds, you often need to know: has this wallet touched sanctioned entities, darknet markets, mixers, ransomware, or scams? Crypto AML answers that by tracing the address's on-chain history, wallet-to-wallet links, direct counterparty interactions, and public sanctions data — then condensing it into a decision-ready report.
Typical uses:
Screen a counterparty before a transfer, while it is still reversible.
Accept incoming funds safely so a downstream exchange doesn't flag or lock the deposit.
Onboard customers / KYT — screen wallets during onboarding or ongoing monitoring.
Supported networks
Crypto AML currently covers five networks — chosen because they carry the bulk of emerging-market exchange and remittance volume:
Tag
Network
ETH
Ethereum
TRX
TRON
BTC
Bitcoin
More networks are on the roadmap (Solana, Arbitrum, Optimism). The currencyTag used in the API path is the tag from the table above (e.g. ETH, BTC).
Off-chain — sanctions feeds, public attribution data, law-enforcement intelligence.
For the full model, thresholds, and how these combine into a score, see How risk scoring works.
How to use?
Crypto AML exposes the data through two paths:
Web — a convenient browser flow: pick a network, paste a wallet or transaction, read the report, export a PDF, and keep an audit-ready history under your account.
REST API — three bearer-authenticated endpoints for developers who want to wire screening into their own backend.
Prepaid credits are burned in the UI and via the API draw from the same balance.
Pricing
Choose the model that fits how you work. With Pay-as-you-go, you top up a prepaid balance and we deduct it per check — starting from ~$0.20 / check, with no subscriptions and no minimums. Top up anytime with a card or crypto.
Prefer to buy in bulk? Our let you purchase packages of checks upfront and pay a lower per-check rate — the larger the package, the bigger the discount.
Run a check in the dashboard
The web UI is the fastest way to screen a wallet or transaction — no code required.
Getting started takes three things: sign up with an email, top up a small balance, and start screening. No KYB and no annual contract.
Token-level breakdown — for multi-token wallets, each asset is scored independently so a clean ETH balance doesn't mask a risky USDT flow.
Historical vs current exposure and direct interaction risk (incoming and outgoing flow scored separately).
Every check can be exported as a PDF — address, score, exposure breakdown and flags — ready to attach to a case file. Checks are also stored server-side under your account.
Telegram bot
Individuals can configure screenings and receive reports inside @GetBlockAMLBot — no separate dashboard needed (Coming soon).
UI states to expect
State
What you see
Loading
The check runs server-side;
Result
The report screen described above.
Empty / new address
A wallet with little on-chain history returns a low-signal result.
Reports are generated for informational purposes only. Risk scores are probabilistic and provided "as is" — they must not be the sole basis for regulatory, legal or financial decisions.
Run check via API
GetBlock Crypto AML also vailable via API. It return a JSON with a risk score, exposure breakdown and flags.
The AML API uses bearer auth with a single token per account — the same token that powers UI billing.
Generate a token from the dashboard: API keys →
Base URL:
The v2 (detailed) address endpoint returns:
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
Your target address transacts using the delegated Energy (no TRX burning)
Energy recovers over 24 hours if partially used
Delegation expires at the end of the rental period — resources return to GetBlock
Available Operations
Operation
Description
Delegate Energy
Delegate 30,000–5,000,000 Energy for 1h–14d to any TRON address
Delegate Bandwidth
Delegate 1,000–200,000 Bandwidth for 1 hour to any TRON address
Activate Address
Activate a new TRON address on the blockchain (required before delegation to unused addresses)
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)
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.
Yellowstone gRPC is the name given to the Dragon’s Mouth Geyser plugin’s gRPC interface in Triton One’s “Yellowstone” suite for Solana. It allows opening streams and subscribing to native Solana on-chain events, receiving every new update in real time, with millisecond-level latency.
By plugging directly into validators, it pushes new blocks, transactions, and account updates to your backend the moment they occur.
The Geyser Plugin hooks into validator callbacks for ledger events and publishes those events to its own internal queues. A gRPC server then streams the queued events over the network to subscribed clients.
Geyser gRPC supports streaming the full range of common Solana events
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.
C-Chain — full EVM compatibility
Archive data access (all plans)
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.
Archive data access (all plans)
Trace & Debug methods (Starter+)
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.
1
Go to and sign up. You can register with email or via Google/GitHub OAuth.
2
Once logged in:
Error
Invalid address/hash for the selected network, or insufficient balance.
Get a real-time price estimate for Energy delegation
Check Order Status
Retrieve details of a previously placed order
API interface: Review available interface types
Subscription — Enable the subscription toggle if you want to ensure your node renews automatically each billing cycle.
When ready, click Go to Payment.
Step 2: Select add-ons
Step 3: Payment
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.
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.
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 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.
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
What is Yellowstone gRPC?
How Yellowstone gRPC Geyser works
Supported data streams & subscriptions
Yellowstone gRPC API features
Solana Geyser gRPC plugin use cases
Note that gRPC is not supported in browsers, so Yellowstone is intended for backend services.
Why use Yellowstone gRPC API?
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:
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.
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.
How to make HTTP requests with curl using JSON config file
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()}`
));
All GetBlock endpoints follow a predictable format. The visible difference is the hostname reflecting the region selected during the setup.
Endpoint examples:
EU (Frankfurt): https://go.getblock.io/<ACCESS_TOKEN>/
US (New York): https://go.getblock.us/<ACCESS_TOKEN>/
Asia (Singapore): https://go.getblock.asia/<ACCESS_TOKEN>/
The token encodes the protocol, networks, and routing on the server — clients don’t need to specify a chain in the URL.
Full vs Archive mode
Selecting the Archive mode for an endpoint changes how requests are billed in Compute Units (CU). Learn more in the Archive mode guide.
Viewing and managing endpoints
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.
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.
Send the invite.
The user will receive an invitation email with a link to sign up and join the team.
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.
✅
🔓
Add & remove team members
✅
✅
❌
Edit access levels
✅
✅
❌
Promote to Admin
✅
❌
❌
After accepting the invitation, you are given access to your team’s workspace. Your role and permissions 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.
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 given by the team owner or admin.
Never share login credentials—use team accounts instead.
Create & manage access tokens
✅
✅
🔓
Manage subscriptions & payments
Creating a team account on GetBlock
Adding teammates
Limits on GetBlock team accounts:
Each user can create up to 3 teams.
A user can be invited to an unlimited number of teams.
One team can have a maximum of 30 users.
Managing roles & permissions
If a Member has no permissions assigned, they will have View-Only access by default.
Roles-based permissions
If you need someone to help manage other team members, be sure to give them Admin status.
Revoking team access
When removed from a team, users lose access to that team workspace but keep their personal account.
How to join a team account
Switching between personal & team accounts
A team user does not lose access to their personal account. They can still use and manage their own endpoints and subscriptions.
Automatic: Enabled when you provision an accelerated dedicated node
Transparent: Your existing RPC calls work unchanged
What to do With Accerelated Node
Interested in building on Solana with TradeFirst? Reach us for more information.
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.
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
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
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
Core Value Proposition
Core Technology Stack
Future Addition:
Shred Stream Access (coming soon): Direct raw shred delivery for even earlier data access
Risk scores are probabilistic and provided "as is." Use them to inform your own risk decisions — not as the sole basis for regulatory, legal or financial decisions.
,
(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 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.
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.
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.
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:
Building on Avalanche? Contact us for custom infrastructure.
Features
Step-by-Step: Get Your Avalanche RPC Endpoint
Code Sample
What's Next?
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.
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
GetBlock deploys and maintains a global network of Portal instances—high-performance gateways that:
Provide unified interface: Single API endpoint for historical data and real-time subscriptions
Ensure low latency: Geographically distributed clusters for fast global access
Guarantee high availability: Redundant instances with automatic failover
Handle scale: Optimized for large workloads and deep historical scans
Abstract complexity: Clean API hides underlying distributed storage complexity
Blocks
Block hash, slot number, parent slot
Block time (Unix timestamp)
Leader (validator) identity
Transaction count
Total compute units consumed
Transactions
Signature (unique identifier)
Fee payer address
Success/failure status
Instructions
Program ID (which program was called)
Instruction index (order within transaction)
Instruction data (decoded where possible)
Logs
Program log messages
Associated transaction signature
Log level and content
Account Updates
Account public key
Pre-transaction balance (lamports)
Post-transaction balance (lamports)
Deep historical analysis and backtesting
Real-time liquidity and TVL monitoring
Pattern recognition and signal generation
Full transaction and asset history for any user
Instant UI updates based on on-chain events
Aggregation of data across DeFi and NFT protocols
Reliable data backbone for internal analytics
Foundation for B2B data services
No need to maintain validators or archive RPC setups
For consultation on optimal deployment architecture for your specific use case, contact GetBlock support team.
A dedicated RPC endpoint with guaranteed RPS and no request limits, at a flat monthly price. For Ethereum, Solana, Bitcoin and other Tier-1 blockchains.
Limitless Node is a dedicated RPC endpoint with a guaranteed RPS and no Compute Unit (CU) limits. You pick an RPS tier on a single chain, pay a fixed monthly fee, and send as many requests as your throughput allows. There's no usage-based billing and no overage charges.
Architecturally, it's a middle layer between Shared RPS and Dedicated Nodes: more throughput and isolation than a shared plan, at a fraction of the cost of a full private node.
Limitless Node is the right fit for applications that generate a high volume of RPC requests and need predictable monthly costs without provisioning a full Dedicated Node. Common use cases include indexers, bots, wallet backends, AI agents, and analytics platforms.
What's included
Every Limitless Node includes:
Guaranteed requests-per-second (RPS) throughput with no per-method throttling
Unlimited requests within your RPS tier, no CU-based billing
No concurrent connection limits for parallel workloads
No restrictions on RPC method usage. All standard and heavy RPC methods are supported
Full node and archive node configurations available for supported chains
Isolated capacity and dedicated routing for a single network
Multi-region geo-routing across Europe, the USA, and Asia to minimize latency through geographic proximity
One instance can have multiple , each a separate credential that can be regenerated or removed independently of the others
24/7 customer support with a response time under 5 minutes
Pricing is fixed and predictable because it is throughput-based rather than usage-based
Pick the tier that matches your current traffic. Within your RPS cap, requests are unlimited. There is no monthly request quota and no CU metering.
RPS (requests-per-second) Tier
Price (monthly)
Requests
Best For
Prices shown are for monthly billing. Annual billing saves 20%. You can move between tiers at any time with no lock-in.
One Limitless Node subscription corresponds to one blockchain network. The service is currently available on 10 high-demand blockchains:
For now, our team provisions every Limitless Node individually so your instance is configured to your workload from day one. Self-serve setup from the dashboard is coming soon.
To get started:
Contact our team through a contact from on our website or your account.
Specify the requirements: blockchain network, desired RPS tier, node mode (full or archive), and preferred hosting region.
We finalize your configuration and provision a dedicated Limitless Node.
Our team can also recommend the right tier based on your workload.
Flashblocks API
Flashblocks API on the Base network: fetch the latest in-progress block, including all preconfirmed transactions. Quickstart examples in JavaScript and Python
This section contains all the Flashblock methods available on the Base network
Flashblocks are simply a class of RPC API methods that are now active on GetBlock endpoints for Base and Optimism. If you already run either chain with GetBlock, the new methods are available on your existing endpoint; if you are new, set up a Base or Optimism endpoint from the and the methods are there.
Quickstart
In this section, you will learn how to fetch the latest Flashblock — the current in-progress block containing every preconfirmed transaction — using either:
Axios (JavaScript / Node.js)
Python (Requests library)
Before you begin, you must have already installed or on your local machine (for the Axios example) or Python and pip (for the Python example).
1
2
3
Create a new file named index.js. This is where you will make your first call.
4
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
Yellowstone is a high-performance Geyser plugin that streams real-time blockchain data via gRPC interfaces. As a result of our partnership with the core Yellowstone team members, GetBlock's Accelerated Yellowstone implementation includes:
Optimized data serialization: Optimized the original version of the low-level logic to improve the speed of state updates compared to the original Yellowstone implementation, and reduced overhead in encoding and transmitting blockchain state.
Enhanced filtering mechanisms: More efficient subscription management for accounts, transactions, slots, and blocks
Improved connection handling: Better resource management for sustained high-throughput streams
Solana validators propagate blocks by breaking them into small fragments called "shreds" and distributing them via the Turbine protocol. StreamFirst taps into this raw data stream:
Direct shred reception: Receives block fragments (shreds) via UDP as validators broadcast them.
Early state reconstruction: Rebuilds block data before it's fully confirmed and distributed via standard RPC
GetBlock operates as a top-tier Solana node provider in Frankfurt, a zone with the highest density of Solana validator stake. This strategic positioning provides:
Proximity to major validators: Direct access to high-stake validators concentrated in the region
Ultra-low network latency: 6ms latency within Europe
Optimal shred reception: Positioned to receive validator broadcasts with minimal delay
The combination means you get blockchain state updates as validators are producing blocks, not after they've been fully processed and distributed.
Data Flow:
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
Traditional RPC methods introduce latency at multiple stages:
Waiting for block confirmation
HTTP request/response overhead
JSON parsing and serialization
StreamFirst bypasses these bottlenecks by:
Receiving data at the validator propagation speed
Using binary gRPC protocol (faster than JSON)
Streaming continuously without polling
StreamFirst is ideal for applications where milliseconds matter:
High-frequency trading bots: React to price changes before slower competitors
MEV searchers: Identify arbitrage opportunities in real-time
DeFi protocols: Monitor liquidation events and oracle updates instantly
StreamFirst supports all standard Yellowstone gRPC subscription types:
Account updates: Monitor balance changes, data modifications, and ownership transfers
Transaction streams: Receive all transactions or filter by program/account
Slot updates: Track block production and commitment levels
StreamFirst is available as an add-on for GetBlock's dedicated Solana nodes. It's configured as a plugin in the node configurator and requires:
Dedicated node subscription
Geographic proximity to GetBlock's validator network for optimal performance
Additional fee based on data throughput requirements
StreamFirst gives developers a competitive edge by delivering Solana blockchain data at near-validator speed. The combination of accelerated Yellowstone software and optimized shard-stream networking, optimized shred-stream networking, and strategic Frankfurt positioning ensures low latency between your customer and dedicated node. This ensures your dApp has the earliest possible view of on-chain activity—critical for time-sensitive operations in DeFi, trading, and real-time analytics.
For consultation on optimal deployment architecture for your specific use case, contact
How risk scoring works
Crypto AML combines advanced analytics, machine-learning models and deterministic rules to evaluate dozens of on-chain and off-chain factors in parallel. The result is a structured breakdown across exposure axes — not a single opaque number.
The pipeline
Every check runs through three stages:
Signals — "what we read". The engine reads 30+ criteria per wallet across two families of data.
Scoring engine. A weighted combination of every signal, mapped to a 0–100 range. Conceptually: score = Σ wᵢ·sᵢ over all signals i, blending supervised ML models with heuristic rules. Median latency is < 400 ms.
Output — "what you get". A composite score, a band, an exposure breakdown, FATF flags and attribution.
On-chain behavioural patterns
Wallet clusters
Counterparty flow
The 0–100 composite riskScore maps to one of four bands (riskBand). These thresholds are exact:
Alongside the score, each report lists discrete FATF-aligned flags you can cite in a case file. Values seen in the product include:
sanctions_list_match — Sanctions list match
darknet_market_exposure — Darknet market exposure
mixer_interaction — Mixer / tumbler interaction
The detailed view (API v2 / the UI report) scores risk along several axes so a clean present-day balance can't mask a risky history:
Axis
What it measures
Where identity can be established, the report includes attribution:
cluster — a cluster identifier (e.g. cluster_4f2a).
labels — entity names where known, inferred tags where not (e.g. ["sanctioned_entity", "mixer"]).
eth_unsubscribe - Flashblocks
Example code for the eth_unsubscribe Flashblocks method. Complete guide on how to use eth_unsubscribe Flashblocks in GetBlock Web3 documentation.
This cancels a subscription created with eth_subscribe. The subscription ID is no longer valid after this call.
Parameter
Type
Required
Description
Field
Type
Description
Status Code
Error Message
Cause
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
GetBlock-operated infrastructure with validator peering
Leased SWQoS Connections
Higher priority than unstaked RPC traffic, ensuring transactions cut ahead during congestion
Reserve priority bandwidth specifically for LandFirst traffic
Jito Block Engine Integration
MEV-aware auction mechanism for guaranteed inclusion
Bundle support for atomic multi-transaction operations
Priority placement through competitive tipping
By combining all three paths, LandFirst provides the highest probability of fast transaction inclusion on Solana.
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.
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.
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.
Standard RPC nodes submit transactions via single, unstaked TPU connections. During congestion, these transactions are deprioritized or dropped entirely.
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
Connect Brave Wallet to GetBlock
Explore how to add custom GetBlock RPC endpoints to Brave Wallet for greater security, transaction speed, and reliability
Brave Wallet supports many networks and offers extensive customization options. However, each of its chains uses a public RPC API endpoint, which is very bad for privacy and efficiency.
GetBlock’s private RPC nodes can solve this problem. After downloading the Brave browser and setting up the wallet, visit https://account.getblock.io/ and get one of the 100+ available chain endpoints.
Using custom GetBlock nodes improves the Web3 experience in many ways:
Secure connections without privacy breaches
Lower latency and higher transaction speed
Every wallet’s network can be modified this way, and this step-by-step guide shows how to do that.
Before you start
You need to set up the Brave wallet and prepare the GetBlock API endpoints.
Download Brave and set up the wallet
Brave Wallet is inseparable from the Brave browser. So, download and install the browser from the official website. 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.
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.
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.
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 (
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 balance.
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
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.
Yellowstone gRPC API
Power your Solana dApps and backends with the fastest, most reliable streaming data available. Yellowstone gRPC add-on is for apps that need every live event as fast as the network can deliver.
Overview
Yellowstone gRPC is a high-performance Solana Geyser plugin that provides real-time streaming access to on-chain data. Built by Triton One, it delivers blocks, transactions, and account updates with millisecond-level latency directly from Solana validators.
GetBlock offers managed Yellowstone gRPC endpoints as an add-on to Dedicated Solana Node subscriptions, eliminating the need for infrastructure setup and maintenance.
Key Features
Near-zero latency: Streams data directly from validators, often hundreds of milliseconds faster than standard RPC/WebSocket APIs
High throughput: Handles millions of events per minute under load
Comprehensive streaming: Monitor accounts, transactions, blocks, slots, and program interactions in real-time
Rich filtering: Subscribe only to relevant updates using account keys, owner programs, or commitment levels
Protobuf encoding: Receive parsed, typed messages instead of raw base64 data
Bidirectional streaming: Maintain long-lived connections with built-in keep-alives
Yellowstone gRPC supports streaming the full range of Solana events:
Stream Type
Description
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
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)
Here's a minimal TypeScript example to start streaming account updates:
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 .
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.
1
Go to and sign up. You can register with email or via Google/GitHub OAuth.
2
Once logged in:
Click "Shared Nodes" in the left sidebar
Use Case
Plan
CU
RPS
Need enterprise Polygon infrastructure? .
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.
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 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
TRC-10 token transfers consume only Bandwidth. TRC-20 token transfers (USDT and other smart contract tokens) consume both Bandwidth and 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
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:
Current network parameters (set via governance) can be retrieved with the following request:
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
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
TRON has a Stake 2.0 mechanism that allows users to obtain Energy without burning 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.
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.
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.
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:
For high-volume clients (exchanges, payment services, dApps), renting Energy significantly reduces operational costs.
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.
Crypto Address Audit: Risk & Compliance APIs
Crypto Address Audit is GetBlock's risk and compliance suite for screening blockchain addresses before any interaction.
Crypto Address Audit is GetBlock's AI-powered risk and compliance suite that screens wallets and smart contracts for fraud risk, AML exposure, and rug pull detection in a single API.
The service runs on pure on-chain behavioral analysis with no source code review and no off-chain data, across Ethereum, BNB Smart Chain, and Base.
Choose Your Crypto Audit API:
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
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. .
Crypto Address Audit uses a single subscription that covers all three services with a single API key.
Each user gets 5 free requests per day. After the free quota is used, each request costs $0.20 USD, deducted from the prepaid balance.
Parameter
Value
On your , click on the credit balance as seen below:
Click on Top Up
Select the amount you want to pay or enter the amount:
After that, click on Proceed to checkout
You'll be routed to another page to complete your payment
Once you've completed your payment, go back to your dashboard to see it reflected.
Optimism Flashblocks.
Flashblocks-specific RPC methods, WebSocket subscriptions, and the infrastructure stream schema for Optimism pre-confirmations.
Optimism runs on the OP Stack (chain ID 10), the reference implementation for which Flashblocks' Rollup-Boost sidecar was built. Flashblocks are available on Optimism Mainnet and Optimism Sepolia (chain ID 11155420), served over the standard Optimism RPC interface so existing tooling reads preconfirmed state without modification.
Transport
URL
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.
EVM-compatible — use the same tools as Ethereum (ethers.js, web3.js, Hardhat, Foundry)
Archive data — full historical state queries
Error messages (if failed)
Fee paid (lamports)
Compute units used
List of program invocations
Accounts array (all accounts involved)
Nested/inner instructions
Timestamp
Owner program (pre and post)
Data changes (what was modified)
Rent epoch information
string
low | medium | high | very-high.
message
string
Human-readable summary for the band.
exposure
array
{ category, share } — where risk comes from; share is 0–1.
Direct & indirect exposure (hop distance to flagged addresses)
Transaction volume & value concentration
Peel-chain & layering patterns
Mixer / tumbler interaction
Bridge & cross-chain movement
Wallet age & activity cadence
Dormancy and sudden-reactivation signals
Token-level exposure (per-asset flow scoring)
Sanctions feeds (OFAC, EU, UN, and national lists)
Public attribution data
Law-enforcement intelligence
Darknet-market address databases
Ransomware & extortion address feeds
Scam, phishing & fraud reports
Exchange & VASP attribution
Known mixer / tumbler service lists
High-risk jurisdiction indicators
Reported hack & exploit address sets
Medium
25–49
Minor exposure detected. Reasonable to proceed after a quick review.
high
High
50–74
Notable exposure to risky counterparties. Review details before accepting funds.
very-high
Very high
75–100
Strong match with high-risk activity. Do not transact without enhanced due diligence.
Ransomware-associated cluster
Scam / phishing cluster
High-risk jurisdiction
Token-level breakdown
Each token on the wallet is scored independently — a clean ETH balance does not mask a risky USDT flow.
Band (riskBand)
Label
Score range
Meaning
low
Low
0–24
No material risk indicators in the current evaluation.
Historical exposure
Aggregated risk across the wallet's entire on-chain history.
Current exposure
Risk weighted to the present-day balance and recent activity (last ~90 days).
Direct interaction risk
Exposure from counterparties one hop away — scored separately for incoming and outgoing flow.
Signals evaluated
Risk bands & thresholds
The score is the output of a complex, probabilistic system. It combines many weighted signals, machine-learning models and continuously updated data sources — so it is an estimate, not a definitive verdict. The same address can score slightly differently over time as on-chain activity, attribution data and sanctions feeds change, and a result may sit near a band boundary. Treat the score and band as one input to your own risk decision, apply your own policy thresholds, and account for this natural fluctuation when acting on any particular result.
If you have concerns about the origin of funds, you can use our KYT tool to trace fund movements in a graph form — following an address to its counterparties and their interconnections — and decide based on that.
FATF flags
Flag values shown in snake_case are the API form; the italic labels are the UI display form.
Exposure axes in the detailed report
Attribution
medium
GetBlock Product Demo
Slots
Slot notifications as they're processed by the leader
Block Meta
Block metadata with transaction counts and execution status
DeFi strategy engines
Alerting and notification systems
NFT marketplace trackers
Wallet activity monitors
Accounts
Real-time account updates including lamports, owner, and data
Transactions
Full transaction data with metadata and instruction details
Blocks
Block metadata including slot, parent slot, and timestamp
Supported Data Streams
Use Cases
Note: gRPC is not supported in browsers. Yellowstone is designed for backend services and server-side applications.
. Connect your application and start sending requests.
25 RPS
$150/mo
Unlimited
Testing & prototypes
50 RPS
Ethereum
Solana
Bitcoin
TRON
Base
Polygon
Arbitrum
Avalanche
Limitless Node is a standalone product. You don't need an existing Shared or Dedicated plan to use it. You get a fully isolated RPC endpoint from day one.
RPS tiers and pricing
Requests above your RPS limit are rate-limited and return a standard rate-limit response. We do not charge overage fees. If you consistently reach your limit, consider upgrading to a higher tier.
Supported chains
Additional networks may be added over time. If you need a chain that isn't listed yet, a custom RPS ceiling, or multi-region redundancy, contact our team.
Set the ES module "type": "module" in your package.json.
5
Add code
index.js
importaxiosfrom
Replace <ACCESS-TOKEN> with your actual access token from GetBlock (Base or Optimism endpoint).
6
Run the script
nodeindex.js
The response contains the current in-progress block, updated every 200ms (Base) or 250ms (Optimism). Call it again a few hundred milliseconds later and you'll see additional transactions included as new Flashblocks land.
import asyncio
import json
import websockets
async def main():
async with websockets.connect('wss://go.getblock.io/<ACCESS-TOKEN>/') as ws:
await ws.send(json.dumps({
"jsonrpc": "2.0",
"method": "eth_unsubscribe",
"params": [
"0x9cef478923ff08bf67fde6c64013158d"
],
"id": "getblock.io"
}))
async for message in ws:
print(json.loads(message))
asyncio.run(main())
use tokio_tungstenite::connect_async;
use tokio_tungstenite::tungstenite::Message;
use serde_json::json;
use futures_util::{SinkExt, StreamExt};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let (mut ws_stream, _) = connect_async("wss://go.getblock.io/<ACCESS-TOKEN>/").await?;
let payload = json!({
"jsonrpc": "2.0",
"method": "eth_unsubscribe",
"params": [
"0x9cef478923ff08bf67fde6c64013158d"
],
"id": "getblock.io"
});
ws_stream.send(Message::Text(payload.to_string())).await?;
while let Some(msg) = ws_stream.next().await {
println!("{:?}", msg?);
}
Ok(())
}
{
"jsonrpc": "2.0",
"id": 1,
"result": true
}
result
boolean
true if the subscription was successfully cancelled, false if the subscription ID was not found.
403
Forbidden
Missing or invalid <ACCESS-TOKEN>
-32602
Invalid params
Request parameters are missing or malformed
import { ethers } from 'ethers';
const provider = new ethers.WebSocketProvider('wss://go.getblock.io/<ACCESS-TOKEN>/');
// Flashblocks subscription types aren't first-class in ethers — use the raw send interface:
const subscriptionId = await provider.send('eth_usubscribe', ["0xf48bfa9af6a7f77897a0f0e59c1061bc"]);
console.log('Subscribed:', subscriptionId);
import { createPublicClient, webSocket } from 'viem';
const client = createPublicClient({
transport: webSocket('wss://go.getblock.io/<ACCESS-TOKEN>/')
});
// Flashblocks subscription types use the raw request interface:
const subscriptionId = await client.request({
"method": "eth_unsubscribe",
"params": ["0xf48bfa9af6a7f77897a0f0e59c1061bc"]
});
console.log('Subscribed:', subscriptionId);
Request Example
Response
Response Parameters
Error Handling
SDK Integration
# WebSocket-only method. Use wscat (or similar) to connect first:wscat-c'wss://go.getblock.io/<ACCESS-TOKEN>/'# Then send:{"jsonrpc":"2.0","method":"eth_unsubscribe","params
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.
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.
No overloads even during high chain activities
Get a custom RPC API endpoint
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.
Modify an existing EVM network
Add a new EVM network
Brave Wallet is very convenient for managing blockchain networks, with hundreds of EVM protocols available. GetBlock almost certainly has a node endpoint for active and popular ones.
If you genuinely believe that a network is unfairly missing, you may contact us and suggest it.
from web3 import Web3w3 =Web3(Web3.HTTPProvider("https://go.getblock.io/<YOUR-ACCESS-TOKEN>/"))print("Chain ID:", w3.eth.chain_id)# 137print("Block:", w3.eth.block_number)
Starter ($49/mo)
Managed: GetBlock handles all Gateway maintenance and updates
Your application code remains the same. The improvement happens at the infrastructure layer, giving you faster data without code changes.
State Transitions
Account and contract state
Fresher data for decisions
Transaction
Submiting Trsanction
Submit single transactions or bundles with optimized propagation paths
wss://go.getblock.io/<ACCESS-TOKEN>/
Method
Usage
eth_getTransactionCount
Pass "pending" for a nonce that accounts for Flashblock transactions
eth_getStorageAt
Pass "pending" for storage at preconfirmed state
eth_getBalance
Pass "pending" for the balance at the latest Flashblock state
The example below reads the pending balance of the Optimism WETH contract 0x4200000000000000000000000000000000000006. Substitute any supported method and parameters; the "pending" tag is what selects Flashblock state.
The result is the hex-encoded balance in wei at the latest Flashblock. The same request with the "latest" tag returns the value at the last sealed block.
Trading Platforms: Surface preconfirmed order and swap results with sub-second latency.
Prediction Markets: Reflect changes in market state as soon as transactions are preconfirmed.
Wallets: Show instant transaction feedback and real-time balance updates before a block is sealed.
Nonce Management: Use eth_getTransactionCount with pending to avoid nonce collisions during rapid submission.
Preconfirmed Receipts: Poll eth_getTransactionReceipt to confirm inclusion at Flashblock cadence.
Example code for the eth_getTransactionCount Flashblocks method. Complete guide on how to use eth_getTransactionCount Flashblocks in GetBlock Web3 documentation.
This returns the transaction count (nonce) for an address. When called with "pending", the returned nonce already accounts for transactions currently sitting in Flashblocks — preventing nonce collisions when an account submits many transactions in rapid succession.
This is especially valuable for high-frequency trading bots and any application that fires more than one transaction per 2-second block.
Parameters
Parameter
Type
Required
Description
Field
Type
Description
Constructing the next transaction with the correct nonce, even during high-frequency submission
Preventing 'nonce too low' errors when submitting multiple transactions per block
Trading bot infrastructure — the primary use case for the pending nonce
Status Code
Error Message
Cause
delegate-energy - TRON energy
Example code for the delegate-energy JSON RPC method
This endpoint delegates energy to a TRON address. In most cases, the order completes immediately with status "success".
Parameter
Parameter
Type
Required
Description
target_address
delegateEnergy charges your balance and may place an on-chain order. To make retries safe, send a unique key with each intent:
A UUID is recommended. Generate a new key for each purchase, and reuse the same key when retrying the exact same purchase.
Example code for eth_getBlockTransactionCountByNumber Flashblocks method. Complete guide on how to use eth_getBlockTransactionCountByNumber Flashblocks in GetBlock Web3 documentation.
This returns the pending number of transactions in a block.
Parameters
Parameter
Type
Required
Description
block number
Field
Type
Description
Confirming a transaction has been received and included in a Flashblock
Reading calldata / value of a preconfirmed transaction for follow-up processing
Building activity feeds with sub-second latency
Status Code
Error Message
Cause
eth_getStorageAt - Flashblocks
Example code for the eth_getStorageAt Flashblock method. Complete guide on how to use eth_getStorageAt Flashblock in GetBlock Web3 documentation.
This returns the value stored at a specific storage slot of a contract. When called with "pending", reflects storage changes from every transaction preconfirmed into the latest Flashblock — letting applications read intermediate contract state before block seal.
Parameters
Parameter
Type
Required
Description
Field
Type
Description
Reading contract state that has been updated by preconfirmed transactions
Monitoring internal state changes in real-time (e.g. AMM reserves, oracle prices)
Auditing tools that need to-the-Flashblock state visibility
Status Code
Error Message
Cause
eth_getBalance - Flashblocks
Example code for the eth_getBalance Flashblocksmethod. Complete guide on how to use eth_getBalance Flashblocks in GetBlock Web3 documentation.
This returns the ETH balance of an address in wei. When called with "pending", includes the effect of every transaction preconfirmed into the latest Flashblock — usually within 200ms (Base) or 250ms (Optimism) of the user's submission. Applications that update balance UIs on the pending tag give users near-instant feedback that a transfer has landed.
Parameters
Parameter
Type
Required
Description
Field
Type
Description
Wallet UIs showing near-instant balance updates after a transfer
Payment applications confirming a payment has been received before block seal
Trading bots that need to know current available balance including unsealed transfers
Status Code
Error Message
Cause
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 GetBlock Dashboard 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
Click "Create New Endpoint" or the "+" button
Select:
Protocol: Base
Network: Mainnet or Sepolia
3
Your endpoint URL looks like this:
4
MetaMask → Add Network → Add manually
Enter:
Network Name: Base Mainnet (GetBlock)
Base Sepolia Testnet:
Chain ID: 84532
Explorer: https://sepolia.basescan.org
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 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.
Use Case
Plan
Why
Scaling on Base? for dedicated infrastructure with custom performance tuning.
address-activate - TRON energy
Example code for the addressActivate JSON RPC method. Сomplete guide on how to use addressActivate JSON RPC in GetBlock Web3 documentation.
This activates (creates) a TRON address on-chain. This is required before delegating Energy or Bandwidth to a new (never-used) address.
A newly generated TRON address must be activated before it
can hold a balance or receive transfers. Activation is synchronous: the API returns 200 with the provider's
activation receipt, and the realised on-chain cost is charged from your prepaid balance.
Fixed cost: 1.87 TRX, charged in USD at the current TRX/USD rate.
Body Parameter
Parameter
Type
Required
Description
Field
Type
Charged
Description
Send a unique Idempotency-Key header (UUID format recommended) to ensure safe retries:
Scenario
Behavior
A retry with the same key + body replays the original activation receipt — it does not activate the address twice or charge a second time.
eth_getCode - Flashblocks
Example code for the eth_getCode JSON-RPC method. Complete guide on how to use eth_getCode JSON-RPC in GetBlock Web3 documentation.
The eth_getCode method returns the bytecode at a given address. This is used to determine if an address is a smart contract and to retrieve the deployed contract code. When the block reference is "pending", Flashblocks detect contract deployments before the block seals.
Parameters
Parameter
Type
Required
Description
Parameter
Type
Description
Contract Detection: Verify if address is a smart contract
Security Analysis: Examine contract bytecode for vulnerabilities
Contract Verification: Compare deployed code with source
Proxy Detection: Identify proxy patterns in bytecode
Error Code
Message
Description
base_transactionStatus - Flashblocks
Example code for the base_transactionStatus Flashblocks method. Complete guide on how to use base_transactionStatus Flashblocks in GetBlock Web3 documentation.
This Checks whether a specific transaction is currently present in the node's mempool. This confirms that a submitted transaction has been received by the sequencer before it appears in a Flashblocks — closing the gap between submission and first preconfirmation. Base-specific: this method exists on Base's Flashblocks endpoints but has no equivalent on Optimism.
Base-only method. This method is exposed by Base's Flashblocks infrastructure but has no equivalent on Optimism. Calling it against an Optimism endpoint will return -32601 Method not found.
Parameters
Parameter
Type
Required
Description
Field
Type
Description
Confirming a submitted transaction reached the sequencer before it appears in a Flashblock
Detecting transactions that were dropped or rejected before entering the mempool
Debugging submission pipelines — distinguishing 'not submitted' from 'submitted but not yet preconfirmed'
Status Code
Error Message
Cause
Base Flashblocks
Flashblocks-specific RPC methods, WebSocket subscriptions, and the infrastructure stream schema for Base pre-confirmations.
Flashblocks deliver ~200ms transaction preconfirmations on Base by streaming partial blocks before the next full block is sealed. Each 2-second Base block is divided into ten Flashblocks streamed at 200ms intervals, exposing preconfirmed state through the standard JSON-RPC pending block tag.
Endpoints
Transport
URL
HTTP
https://go.getblock.io/<ACCESS-TOKEN>/
Method
Usage
The example below reads the pending balance of the Base WETH contract 0x4200000000000000000000000000000000000006. Substitute any supported method and parameters; the "pending" tag is what selects Flashblock state.
Instant UI Feedback: Update wallet and dApp interfaces the moment a transaction is preconfirmed, without waiting for a sealed block.
Responsive Swaps: Surface preconfirmed swap results on decentralized exchanges with sub-second latency.
Onchain Gaming: Reflect game state changes as soon as actions are included in a Flashblock.
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
On the API Key tab, click on the plus icon, and your API key will be generated for you automatically
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
Create and initialize a new project:
2
3
Create a new file named index.js. This is where you will make your first call.
Dedicated nodes: Manage & extend subscriptions
Track and extend your dedicated node subscriptions on GetBlock.
This page explains how to manage your dedicated node subscriptions, including checking their status and extending the service duration—all from your user account.
Tracking subscription status
You can monitor the status of your dedicated node subscriptions in three different ways.
1. Dashboard
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.
Status
Dashboard View
Manage Plans View
You can modify your subscription period at any time if you’re on a one-time payment plan paid with:
Cryptocurrency;
Credit card.
You can extend your subscription to one of the following periods:
1 month
6 months
12 months
There are three ways to extend your subscription.
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.
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.
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.
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.
If you face any issues with renewal or extensions, feel free to reach out to GetBlock support—we’re happy to assist.
newFlashblocks - Flashblocks
Example code for the newFlashblocks Flashblocks method. Complete guide on how to use newFlashblocks Flashblocks in GetBlock Web3 documentation.
This subscribes to the full Flashblocks payload stream as each preconfirmed sub-block is built. Each notification delivers a Flashblocks Object containing payload_id, index (0-9 on Base, 0-7 on Optimism), diff (the delta since the previous Flashblocks), and — on the first Flashblocks of a new block (index: 0) — a base field with the block's initial state. This is the lowest-latency Flashblocks subscription and the canonical way to build sub-block indexers.
WebSocket-only method. This method requires the WebSocket transport at wss://go.getblock.io/<ACCESS-TOKEN>/. It will not work via HTTP POST. Preconfirmed events arrive at the Flashblocks cadence — approximately every 200ms on Base, 250ms on Optimism.
Parameters
Parameter
Type
Required
Description
Field
Type
Description
Sub-block indexers — the primary streaming source for Flashblocks-native data
Real-time analytics dashboards showing block construction in progress
Trading infrastructure that needs the earliest possible view of sequencer-ordered transactions
Status Code
Error Message
Cause
delegate-bandwidth - TRON energy
Example code for the delegate-bandwidth JSON RPC method. Сomplete guide on how to use delegate-bandwidth JSON RPC in GetBlock Web3 documentation.
This is used to purchase and delegate TRON bandwidth to a target address. Unlike energy, bandwidth orders may be confirmed asynchronously: if the provider accepts the order but on-chain delivery is not yet confirmed, the API returns 202 Accepted and no charge is applied until delivery is confirmed.
Body Parameter
Parameter
Type
Required
Description
Send a unique Idempotency-Key header (UUID format recommended) to ensure safe retries:
Scenario
Behavior
A retry of a 202 response replays the same 202 — it does not create a second order
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.
newFlashblockTransactions - Flashblocks
Example code for the newFlashblockTransactions Flashblocks method. Complete guide on how to use newFlashblockTransactions Flashblocks in GetBlock Web3 documentation.
This subscribes to individual preconfirmed transactions as they land in Flashblocks. Each notification carries one transaction. Pass true as a second parameter to include full transaction objects with associated logs; omit or pass false to receive only transaction hashes. Lighter-weight than newFlashblocks when you only care about the transaction stream and not the full block state.
Parameter
Type
Required
eth_getBlockReceipt - Flashblocks
Example code for the eth_getBlockReceipt Flashblocks method. Complete guide on how to use eth_getBlockReceipt Flashblocks in GetBlock Web3 documentation.
This returns the receipt of a block — preconfirmed OR finalized. Preconfirmed receipts are identifiable by their zero blockHash (0x00...00) and blockNumber: null. Once the parent block seals (within 2 seconds), the same receipt returns with a real block hash. This zero-hash convention is the canonical way to distinguish preconfirmed vs finalized receipts without additional RPC calls.
Parameter
Type
Required
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?"
AML Risk Screening: screening across 18 risk categories (cybercrime, money laundering, phishing, etc.)
pendingLogs - Flashblocks
Example code for the pendingLogs Flashblocks method. Complete guide on how to use pendingLogs Flashblocks in GetBlock Web3 documentation.
This Subscribes to contract event logs emitted by preconfirmed transactions — sub-block latency for on-chain events. Filter by contract address (single or array) and event topics (same format as eth_getLogs).
This is the fastest way to react to on-chain events, up to ~1.8 seconds ahead of the standard logs subscription.
Parameter
Type
Required
Description
How to Get an Ethereum RPC Endpoint
Step-by-step guide to getting a fast, reliable Ethereum RPC endpoint. Set up free or production-grade ETH RPC access with GetBlock in under 2 minutes.
An Ethereum RPC (Remote Procedure Call) endpoint is a URL that your application uses to send requests to an Ethereum node. When your dApp needs to:
Check a wallet balance (eth_getBalance)
Read a smart contract (eth_call)
eth_call - Flashblocks
Example code for the eth_call - Flashblocks method. Complete guide on how to use eth_call - Flashblocks in GetBlock Web3 documentation.
This executes a read-only contract call without creating a transaction. When the block reference is "pending", the call executes against state including every transaction preconfirmed into the latest Flashblocks. This lets applications compute derived values (token balances, oracle prices, pool reserves) reflecting the freshest possible state.
Parameter
Type
Required
Description
eth_estimateGas - Flashblocks
Example code for the eth_estimateGas - Flashblocks method. Complete guide on how to use eth_estimateGas - Flashblocks in GetBlock Web3 documentation.
This estimates the gas needed to execute a transaction without submitting it. When called with "pending", the estimate is computed against state including preconfirmed transactions in the latest Flashblock — giving more accurate estimates for transactions that depend on state changes happening in the current block.
Parameter
Type
Required
Description
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 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
"
:
[
"
0x9cef478923ff08bf67fde6c64013158d
"
],
"
id
"
:
"
getblock.io
"
}
eth_getBlockByNumber
Pass "pending" to retrieve the current Flashblock
eth_getBlockReceipt
Pass "pending" to get receipts for all pre-confirmed transactions in the current Flashblock.
eth_getBlockTransactionCountByNumber
Pass "pending" to get the count of pre-confirmed transactions in the current Flashblock.
eth_estimateGas
Pass "pending" to estimate gas against preconfirmed state
eth_call
Pass "pending" to execute against preconfirmed state
eth_simulateV1
Simulates against the latest preconfirmed state
eth_getLogs
Pass "fromBlock": "pending" and "toBlock": "pending" to query logs from pre-confirmed transactions, updated every ~200ms.
eth_getCode
Pass "pending" for contract code at preconfirmed state
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)
"Known" if the transaction is present in the mempool; "Unknown" if it has not been seen by this node
403
Forbidden
Missing or invalid <ACCESS-TOKEN>
-32602
Invalid params
Request parameters are missing or malformed
import { ethers } from 'ethers';
const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');
// Flashblocks-specific methods use the raw send interface:
const result = await provider.send('base_transactionStatus', ["0xa8f9b3c7d2e4f6a1b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6"]);
console.log(result);
import { createPublicClient, http } from 'viem';
const client = createPublicClient({
transport: http('https://go.getblock.io/<ACCESS-TOKEN>/')
});
// Flashblocks-specific methods need the raw request transport:
const result = await client.request({
method: 'base_transactionStatus',
params: ["0xa8f9b3c7d2e4f6a1b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6"]
});
console.log(result);
Make sure to account for network fees to avoid payment issues.
The extension is applied after blockchain confirmation, which may take a few minutes.
Active
(Recurring Payment)
Active
(One-Time Payment)
Subscription status breakdown
Changing the subscription period
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.
Available options
How to extend your Dedicated Node plan
Option 1: The Dedicated Nodes dashboard
Video guide
Option 2: From “Endpoints” list
Option 3: Via the "Manage Plans" menu
How to keep your Dedicated Node running smoothly
MEV monitoring — observing preconfirmed transactions as they land
-32603
Internal error
Server-side error while processing the request
429
Too Many Requests
Rate limit exceeded for your plan
-32600
Invalid Request
newFlashblocks subscription called over HTTP; use WebSocket
subscriptionType
string
Yes
Must be "newFlashblocks"
import asyncio
import json
import websockets
async def main():
async with websockets.connect('wss://go.getblock.io/<ACCESS-TOKEN>/') as ws:
await ws.send(json.dumps({
"jsonrpc": "2.0",
"method": "eth_subscribe",
"params": [
"newFlashblocks"
],
"id": "getblock.io"
}))
async for message in ws:
msg = json.loads(message)
if msg.get('method') == 'eth_subscription':
# Preconfirmed data update
print(msg['params']['result'])
else:
# Subscription ID response
print('Subscribed:', msg.get('result'))
asyncio.run(main())
use tokio_tungstenite::connect_async;
use tokio_tungstenite::tungstenite::Message;
use serde_json::json;
use futures_util::{SinkExt, StreamExt};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let (mut ws_stream, _) = connect_async("wss://go.getblock.io/<ACCESS-TOKEN>/").await?;
let payload = json!({
"jsonrpc": "2.0",
"method": "eth_subscribe",
"params": [
"newFlashblocks"
],
"id": "getblock.io"
});
ws_stream.send(Message::Text(payload.to_string())).await?;
while let Some(msg) = ws_stream.next().await {
println!("{:?}", msg?);
}
Ok(())
}
Hex-encoded subscription ID. Each subsequent eth_subscription notification carries a Flashblocks Object payload with payload_id, index, diff, and (on index 0) base
403
Forbidden
Missing or invalid <ACCESS-TOKEN>
-32602
Invalid params
Request parameters are missing or malformed
import { ethers } from 'ethers';
const provider = new ethers.WebSocketProvider('wss://go.getblock.io/<ACCESS-TOKEN>/');
// Flashblocks subscription types aren't first-class in ethers — use the raw send interface:
const subscriptionId = await provider.send('eth_subscribe', ["newFlashblocks"]);
console.log('Subscribed:', subscriptionId);
// Listen for incoming events on the WebSocket transport
provider.websocket.addEventListener('message', (event) => {
const msg = JSON.parse(event.data);
if (msg.method === 'eth_subscription' && msg.params?.subscription === subscriptionId) {
console.log('Flashblocks update:', msg.params.result);
}
});
import { createPublicClient, webSocket } from 'viem';
const client = createPublicClient({
transport: webSocket('wss://go.getblock.io/<ACCESS-TOKEN>/')
});
// Flashblocks subscription types use the raw request interface:
const subscriptionId = await client.request({
method: 'eth_subscribe',
params: ["newFlashblocks"]
});
console.log('Subscribed:', subscriptionId);
Request Example
Response Example
Response Parameters
Use Cases
Error Handling
SDK Integration
# WebSocket-only. Use wscat (or similar) to connect first:wscat-c'wss://go.getblock.io/<ACCESS-TOKEN>/'# Then send:{"jsonrpc":"2.0","method":"eth_subscribe","params
importWebSocketfrom'ws';constws=newWebSocket('wss://go.getblock.io/<ACCESS-TOKEN>/');ws.on('open',()=>{ws.send(JSON.stringify({"jsonrpc":"2.0","method":"eth_subscribe","params": ["newFlashblocks" ],"id":"getblock.io"}));});ws.on('message',(data)=>{constmsg=JSON.parse(data.toString());if (msg.method==='eth_subscription') { // Preconfirmed data updateconsole.log(msg.params.result);}else{ // Subscription ID responseconsole.log('Subscribed:',msg.result);}});
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)
Ethereum
BNB Smart Chain
Base
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.
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.
Difference Between Rug Pull Checker And Wallet Audit
Difference Between Rug Pull Checker And Risk API (Hexens Glider)
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.
Supported Networks
How Rug Pull Probability Is Calculated
What increases the risk score:
What decreases the risk score:
The service works only with smart contracts. If a regular wallet address (EOA) is submitted, an empty result will be returned. To check wallets, use Wallet Audit.
Rug Pull Probability does not analyze the contract source code. It evaluates the behavior of the people behind the contract, not the code.
How to Check the Risk In A Wallet Address
This report includes the following:
Contract name
Contract address
Need a custom setup (higher rate limits, dedicated infrastructure, SLA, or volume pricing)? .
Next Step
Description
subscriptionType
string
Yes
Must be "newFlashblockTransactions"
includeFullObjects
boolean
No
true to receive full transaction objects with logs; false (default) for hashes only
# WebSocket-only. Use wscat (or similar) to connect first:wscat-c'wss://go.getblock.io/<ACCESS-TOKEN>/
importWebSocketfrom'ws';
import asyncio
import json
import websockets
async def main():
async with websockets.connect('wss://go.getblock.io/<ACCESS-TOKEN>/') as ws:
await ws.send(json.dumps({
"jsonrpc": "2.0",
"method": "eth_subscribe",
"params": [
"newFlashblockTransactions",
true
],
"id": "getblock.io"
}))
async for message in ws:
msg = json.loads(message)
if msg.get('method') == 'eth_subscription':
# Preconfirmed data update
print(msg['params']['result'])
else:
# Subscription ID response
print('Subscribed:', msg.get('result'))
asyncio.run(main())
use tokio_tungstenite::connect_async;
use tokio_tungstenite::tungstenite::Message;
use serde_json::json;
use futures_util::{SinkExt, StreamExt};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let (mut ws_stream, _) = connect_async("wss://go.getblock.io/<ACCESS-TOKEN>/").await?;
let payload = json!({
"jsonrpc": "2.0",
"method": "eth_subscribe",
"params": [
"newFlashblockTransactions",
true
],
"id": "getblock.io"
});
ws_stream.send(Message::Text(payload.to_string())).await?;
while let Some(msg) = ws_stream.next().await {
println!("{:?}", msg?);
}
Ok(())
}
Field
Type
Description
result
string
Hex-encoded subscription ID. Each subsequent notification carries either a transaction hash (default) or a full transaction object with logs (true param)
Wallet infrastructure watching for a specific user's transactions to preconfirm
Transaction-level analytics without the overhead of full block payloads
Building activity feeds for accounts with sub-second latency
Front-running detection at the sub-block level
Status Code
Error Message
Cause
403
Forbidden
Missing or invalid <ACCESS-TOKEN>
-32602
Invalid params
Request parameters are missing or malformed
import { ethers } from 'ethers';
const provider = new ethers.WebSocketProvider('wss://go.getblock.io/<ACCESS-TOKEN>/');
// Flashblocks subscription types aren't first-class in ethers — use the raw send interface:
const subscriptionId = await provider.send('eth_subscribe', ["newFlashblockTransactions", true]);
console.log('Subscribed:', subscriptionId);
// Listen for incoming events on the WebSocket transport
provider.websocket.addEventListener('message', (event) => {
const msg = JSON.parse(event.data);
if (msg.method === 'eth_subscription' && msg.params?.subscription === subscriptionId) {
console.log('Flashblocks update:', msg.params.result);
}
});
import { createPublicClient, webSocket } from 'viem';
const client = createPublicClient({
transport: webSocket('wss://go.getblock.io/<ACCESS-TOKEN>/')
});
// Flashblocks subscription types use the raw request interface:
const subscriptionId = await client.request({
method: 'eth_subscribe',
params: ["newFlashblockTransactions", true]
});
console.log('Subscribed:', subscriptionId);
WebSocket-only method. This method requires the WebSocket transport at wss://go.getblock.io/<ACCESS-TOKEN>/. It will not work via HTTP POST. Preconfirmed events arrive at the Flashblock cadence — approximately every 200ms on Base, 250ms on Optimism.
use reqwest::Client;
use serde_json::json;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let client = Client::new();
let payload = json!({
"jsonrpc": "2.0",
"method": "eth_getBlockReceipts",
"params": [
"pending"
],
"id": "getblock.io"
});
let response = client
.post("https://go.getblock.io/<ACCESS-TOKEN>/")
.header("Content-Type", "application/json")
.json(&payload)
.send()
.await?;
let result: serde_json::Value = response.json().await?;
println!("{:#?}", result);
Ok(())
}
Field
Type
Description
result.blockHash
DATA
0x00...00 (zero hash) for preconfirmed receipts; real block hash for finalized
result.blockNumber
QUANTITY
null for preconfirmed; block number in hex for finalized
Wallet UIs showing preconfirmed transaction success within 200ms of submission
Polling for confirmed inclusion at 200ms cadence instead of 2s
Distinguishing 'transaction preconfirmed' vs 'transaction finalized' UX states
Detecting transaction revert or success before block seal
Status Code
Error Message
Cause
403
Forbidden
Missing or invalid <ACCESS-TOKEN>
-32602
Invalid params
Request parameters are missing or malformed
import { ethers } from 'ethers';
const provider = new ethers.JsonRpcProvider('https://go.getblock.io/<ACCESS-TOKEN>/');
// Generic JSON-RPC call — 'pending' returns Flashblocks-preconfirmed state:
const result = await provider.send('eth_getBlockReceipts', ["pending"]);
console.log(result);
// Many standard methods have typed wrappers on ethers Provider that accept 'pending':
Sanctions Check: verification against sanctions lists
Wallet Risk Check
Wallet Audit
Response time
< 100ms
Several seconds
Trust Score
Yes
They are two-step logic involved in this calculation:
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.
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%
The service only works with regular wallets (EOA — Externally Owned Accounts). Contract addresses are not supported.
A minimum of 10–15 transactions is required to calculate an accurate predictive score. Wallets with less history lack sufficient data for a reliable assessment
Supported Networks
How to Check the Risk In A Wallet Address
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).
Need a custom setup (higher rate limits, dedicated infrastructure, SLA, or volume pricing)? .
Next Step
subscriptionType
string
Yes
Must be "pendingLogs"
filter
object
No
Filter object: address (single address or array), topics (same format as eth_getLogs)
# WebSocket-only. Use wscat (or similar) to connect first:wscat-c'wss://go.getblock.io/<ACCESS-TOKEN>/
importWebSocketfrom'ws';
import asyncio
import json
import websockets
async def main():
async with websockets.connect('wss://go.getblock.io/<ACCESS-TOKEN>/') as ws:
await ws.send(json.dumps({
"jsonrpc": "2.0",
"method": "eth_subscribe",
"params": [
"pendingLogs",
{
"address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
]
}
],
"id": "getblock.io"
}))
async for message in ws:
msg = json.loads(message)
if msg.get('method') == 'eth_subscription':
# Preconfirmed data update
print(msg['params']['result'])
else:
# Subscription ID response
print('Subscribed:', msg.get('result'))
asyncio.run(main())
use tokio_tungstenite::connect_async;
use tokio_tungstenite::tungstenite::Message;
use serde_json::json;
use futures_util::{SinkExt, StreamExt};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let (mut ws_stream, _) = connect_async("wss://go.getblock.io/<ACCESS-TOKEN>/").await?;
let payload = json!({
"jsonrpc": "2.0",
"method": "eth_subscribe",
"params": [
"pendingLogs",
{
"address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
]
}
],
"id": "getblock.io"
});
ws_stream.send(Message::Text(payload.to_string())).await?;
while let Some(msg) = ws_stream.next().await {
println!("{:?}", msg?);
}
Ok(())
}
Field
Type
Description
result
string
Hex-encoded subscription ID. Each subsequent notification carries a Log object matching the filter, from a preconfirmed transaction
Real-time event indexers — the lowest-latency way to react to on-chain events
Trading bots watching for specific ERC-20 transfers, DEX swaps, or oracle updates
Liquidation bots watching for Aave/Compound account state changes
Social/gaming applications reacting to on-chain events with instant UX feedback
Status Code
Error Message
Cause
403
Forbidden
Missing or invalid <ACCESS-TOKEN>
-32602
Invalid params
Request parameters are missing or malformed
import { ethers } from 'ethers';
const provider = new ethers.WebSocketProvider('wss://go.getblock.io/<ACCESS-TOKEN>/');
// Flashblocks subscription types aren't first-class in ethers — use the raw send interface:
const subscriptionId = await provider.send('eth_subscribe', ["pendingLogs", {"address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]}]);
console.log('Subscribed:', subscriptionId);
// Listen for incoming events on the WebSocket transport
provider.websocket.addEventListener('message', (event) => {
const msg = JSON.parse(event.data);
if (msg.method === 'eth_subscription' && msg.params?.subscription === subscriptionId) {
console.log('Flashblocks update:', msg.params.result);
}
});
import { createPublicClient, webSocket } from 'viem';
const client = createPublicClient({
transport: webSocket('wss://go.getblock.io/<ACCESS-TOKEN>/')
});
// Flashblocks subscription types use the raw request interface:
const subscriptionId = await client.request({
method: 'eth_subscribe',
params: ["pendingLogs", {"address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]}]
});
console.log('Subscribed:', subscriptionId);
WebSocket-only method. This method requires the WebSocket transport at wss://go.getblock.io/<ACCESS-TOKEN>/. It will not work via HTTP POST. Preconfirmed events arrive at the Flashblocks cadence — approximately every 200ms on Base, 250ms on Optimism.
Building a Telegram Mini App at scale? Contact us for custom TON infrastructure.
TON's API is Different from EVM Chains
GetBlock supports the full TON HTTP API specification.
Step-by-Step: Get Your TON RPC Endpoint
Code Example
Why GetBlock for TON?
Plans
What's Next?
eth_getBlockByNumber - Flashblocks
Example code for the eth_getBlockByNumber Flashblocks method. Complete guide on how to use eth_getBlockByNumber Flashblocks in GetBlock Web3 documentation.
This returns the current in-progress Flashblock when called with "pending" — including every transaction that has landed in Flashblocks since the last block sealed. Pass true as the second parameter for full transaction objects; false for hashes only. When called with "latest", returns the last sealed block as usual. Preconfirmed Flashblocks are distinguishable from finalized blocks by their zero stateRoot and by the absence of a final block hash.
Parameters
Parameter
Type
Required
Description
Field
Type
Description
Fast block scanning — read the current preconfirmed state up to 1.8 seconds before the block seals
Building real-time DeFi dashboards that show transactions as they land
MEV analysis — inspecting sequencer-ordered transactions before finalization
Status Code
Error Message
Cause
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.
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.
Use Cases
Wallet Audit provides a complete behavioral wallet profile, not just a "fraud / not fraud" check. Below are six key scenarios where a full audit creates measurable value.
1. DeFi Protocol — Personalized Onboarding
All users connecting to the protocol see the same interface, regardless of their experience, preferences, or financial capabilities. Beginners get lost in complex products, while experienced users don't see what they need.
With Wallet Audit, the moment a wallet connects, an audit runs instantly. Based on Risk Willingness, Experience, and Intentions, the protocol surfaces relevant products.
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
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
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
If you want to interact with or integrate this service via API, check the
Migrate to GetBlock with AI
AI agent runbook to migrate your project's blockchain RPC endpoints to GetBlock using any coding agent.
This page is both a migration guide and an executable runbook for AI coding agents. Paste the one-liner below into any AI coding agent (Claude Code, Codex CLI, Cursor, Windsurf, Gemini CLI, Antigravity), and the agent fetches this page and follows it.
Quick start
Paste this into your AI agent:
get docs.getblock.io/migration/migrate-to-getblock-with-ai.md
The agent fetches this page and walks through the migration in three phases: Assess, Plan, and Implement. It stops after Plan and waits for your approval before making any changes to the code.
How the agent works with GetBlock
GetBlock's documentation is published as machine-readable Markdown. The agent does not need a custom integration to read it.
Documentation index:https://docs.getblock.io/llms.txt lists every doc page. The agent reads this first to discover what is available.
Full corpus in one file:https://docs.getblock.io/llms-full.txt is the entire documentation concatenated, for agents that prefer a single fetch.
Any page as Markdown: append .md to a doc URL, or fetch the page directly, to get clean Markdown instead of HTML.
The Assess and Plan phases run entirely on public docs and read-only checks. The Implement phase creates endpoints, which happens in the GetBlock dashboard. GetBlock endpoints embed your access token in the URL, so there is no API key to register with the agent and no auth header to manage.
Migrate this project's blockchain RPC endpoints to GetBlock.
Scan the codebase for every blockchain RPC endpoint other than GetBlock. Check source files, environment variables, config files (hardhat.config.*, foundry.toml, .env, truffle-config.js), and any hardcoded URLs.
For each endpoint found, identify:
The protocol and network (mainnet or a named testnet).
The interface in use: JSON-RPC, REST, WebSocket, GraphQL, or gRPC.
The methods called, and whether any need archive data (historical state, old blocks, eth_getLogs over wide ranges, trace or debug calls).
Verify GetBlock coverage for each protocol. Fetch https://docs.getblock.io/llms.txt, find the network's reference page, and confirm the network, the interface, and the specific methods are documented. Fetch the page as Markdown for method-level detail.
Report four buckets: fully covered, covered but needs a specific setting (archive mode, MEV protection, a specific region), unsupported, and any endpoints in the codebase that are already dead or deprecated.
Flag these GetBlock features explicitly when the codebase needs them, so the user selects them at endpoint-creation time:
Archive mode. A toggle when creating the endpoint. Required for historical state and full block-zero history. Available from the Starter plan up.
MEV protection. A selectable interface that routes transactions through private channels to shield them from front-running and sandwich attacks. Off by default.
Region routing. Endpoints resolve to a regional host: go.getblock.io (EU, Frankfurt), go.getblock.us
If the user is migrating from another RPC provider, estimate the GetBlock cost and the savings versus their current bill. GetBlock meters usage in Compute Units (CUs).
Get the user's current usage from their existing provider, lowest-friction path first:
QuickNode exposes usage through its Admin API. Ask the user for a QuickNode API key and fetch their billing-period usage and per-method breakdown.
Alchemy has no usage API. Ask for a screenshot of Settings, then Usage, and Settings, then Billing. Read the Compute Units used, plan, and spend straight from the image.
Any other provider or no programmatic access: ask for a screenshot of the usage and billing dashboard, or the approximate monthly request volume and current spend.
Pull GetBlock's live plans and the CU model from https://getblock.io/pricing and the Plans and limits doc page.
Route results based on volume: high-volume, dedicated-node needs, or enterprise terms go to GetBlock sales; self-serve volumes go straight to the dashboard.
If the user already has GetBlock endpoints, or is willing to create one test endpoint first:
For each method the codebase uses, send a test request to the matching GetBlock endpoint and confirm the response shape matches what the app expects.
If the codebase has known throughput patterns (batch calls, polling intervals, concurrent requests), test at that rate and watch for rate-limit responses.
Report what works, what fails, and any method or rate-limit gaps.
For each endpoint to migrate, lay out the exact replacement: which GetBlock network, interface, region, and mode (full or archive, MEV on or off) it maps to, and whether a new endpoint needs to be created. Flag anything that needs the user's decision (region choice, archive cost, unsupported chains that need a dedicated node or a sales conversation).
GetBlock endpoints are created in the dashboard, not via a remote API, so this phase involves a guided handoff and code changes.
Tell the user exactly which endpoints to create at https://account.getblock.io (or the GetBlock dashboard), with the precise settings from the approved plan:
protocol
network
interface
region,
Each created endpoint produces a URL of the form https://go.getblock.io/<ACCESS_TOKEN>/.
Have the user paste the new endpoint URLs.
Replace each old endpoint with its GetBlock equivalent across source, env files, and build configs.
Verify each swap with a live call before declaring it done (see snippets below).
Summarize what changed: files touched, endpoints swapped, and anything still pending (a dedicated node, a sales follow-up, an unverified method).
Need in the codebase
GetBlock equivalent
EVM chain ID check (confirms the endpoint is live and on the expected network):
Latest block height:
WebSocket smoke test:
Library swap examples the agent can apply directly:
For implementation issues, unsupported chains, or dedicated-node and enterprise questions, point the user to . Keep the token secret at every step: it is the full credential, embedded in the URL.
CU and rate limits
GetBlock provides access to over 100 blockchains. CU and rate limits depend on the selected plan.
This guide explains how limits work across all available plans, helping you understand what’s included and how to choose the option that best fits your current workload and future growth.
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.
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.
This is how Multicall3 works:
You must have the following:
Node.js v18 or later installed
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.
1
Go to and sign up. You can register with email or via Google/GitHub OAuth.
2
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.
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%
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 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.
Run the script
Region: Choose the closest — Frankfurt (EU), New York (US), or Singapore (APAC)
2.0
"
,
"method":"eth_blockNumber",
"params":[],
"id":"getblock.io"
}
2.0
"
,
"id":"getblock.io",
"result":"0x134A5B2"
}
// The result field contains the latest block number in hexadecimal.
Copy Your Endpoint URL
The long string after go.getblock.io/ is your access token — keep it private.
{"jsonrpc":"2.0","id":"getblock.io","result":"0x134A5B2"}// The result field contains the latest block number in hexadecimal.
Whether the project depends on streaming (WebSocket subscriptions, or Solana Yellowstone gRPC / Geyser).
(US, New York),
go.getblock.asia
(Asia, Singapore). Latency-sensitive workloads should pick the nearest region.
WebSocket. Same token, wss:// scheme: wss://go.getblock.io/<ACCESS_TOKEN>/.
Yellowstone gRPC / Geyser for high-throughput Solana streaming. Confirm availability on the Solana reference page.
REST and GraphQL interfaces where the protocol supports them (for example, TON REST, TRON HTTP API).
archive on/off,
MEV on/off.
Front-running protection
MEV Protected interface
Region pinning for latency
.io (Frankfurt), .us (New York), .asia (Singapore) host
Solana high-throughput streaming
Yellowstone gRPC / Geyser
REST or GraphQL interface
Select the matching interface where the protocol offers it
Many chains in one place
One account, one token format, 130+ networks
HTTP JSON-RPC
https://go.getblock.io/<ACCESS_TOKEN>/
WebSocket subscriptions
wss://go.getblock.io/<ACCESS_TOKEN>/
Historical / archive queries
Archive mode toggle at endpoint creation (Starter plan+)
Do not rely on training data for what GetBlock supports. Network coverage, methods, and interfaces change. Always verify against llms.txt and the live network reference pages. If something cannot be verified there, flag it as uncertain and point the user to GetBlock support rather than guessing.
Optional: on-chain reads during the dry run
If the agent needs to make live blockchain calls while testing (balances, transactions, block heights), GetBlock ships a local MCP server for ETH and Solana data queries: github.com/GetBlock-io/mcp-server. It runs locally with your access tokens as environment variables. This is optional. A plain curl against the new endpoint is enough to verify a migration.
Agent instructions
Assess
Coverage check
Cost and savings estimate
Do not quote prices from memory; they change. Fit the user's converted usage to the cheapest plan that covers it, and present the monthly GetBlock cost next to their current bill.
Dry run
Plan
STOP here. Present the plan and wait for the user to approve or adjust before changing anything. Do not edit code until the user confirms. Answer follow-up questions using the docs. For unsupported chains, point the user to GetBlock support for information on dedicated-node availability.
Implement
The token is the credential, so never ask the user to paste it into chat in plaintext; instead, reference it from the .env var.
5. Quest Platforms — Adaptive Tasks and Sybil Protection
6. Airdrop Campaigns — Farmer Filtering
Limitations
The service only works with regular wallets (EOA — Externally Owned Accounts). Contract addresses are not supported.
A minimum of 10–15 transactions is required to calculate an accurate predictive score. Wallets with less history lack sufficient data for a reliable assessment
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%.
Need a custom setup (higher rate limits, dedicated infrastructure, SLA, or volume pricing)? Contact the GetBlock team.
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: 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.
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)
Access Tokens: 2
To increase usage limits, choose between the higher-tier options.
For use cases that are growing beyond the free tier — a first production app or side project. Offers a significant increase in CU and RPS compared to the Free plan.
CU: 90M per month (~3M/day)
Throughput: 100 requests per second (RPS)
For apps with a growing user base: higher daily call volumes and room for several services or environments at once.
CU: 185M per month (~6.2M/day)
Throughput: 150 requests per second (RPS)
Mid-to-upper tier, production-ready plan, suitable for moderate-to-high traffic applications.
CU: 385M per month (~12.8M/day)
Throughput: 300 requests per second (RPS)
For larger apps and teams. More CU headroom and endpoints to run many services or environments from one account.
CU: 700M per month (~23.3M/day)
Throughput: 400 requests per second (RPS)
For applications that need significantly higher throughput and increased resource availability compared to lower tier plans.
CU: 1B per month (~33.3M/day)
Throughput: 500 requests per second (RPS)
Highest standard tier before custom Enterprise terms. Built for sustained high-volume production traffic.
CU: 1.6B per month (~53.3M/day)
Throughput: 700 requests per second (RPS)
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
Your monthly plan CUs (main balance) are valid for the current billing cycle only. The balance is reset when your subscription renews. Main-balance CUs don't carry over.
Extra CUs (extra balance) — anything on top of your plan allocation — do carry over to the next month, as long as your subscription stays active and renews on time.
Limitless Node removes Compute Unit limits entirely. You can send unlimited requests within the RPS tier you choose.
CU: No limit
Rate limit: Capped at selected RPS tier
Our Dedicated Node service is perfect for teams and projects that demand absolute freedom from rate limits and CU monitoring.
Shared Nodes operate on a system of limits defined by Compute Units (CUs) and Requests Per Second (RPS). Each plan also determines how many endpoints you can use simultaneously.
Limitless Node has no CU limits - only an RPS limit.
With Dedicated Nodes, you’re not limited by CUs or RPS.
Your balance of CUs for Shared Nodes is distributed on all endpoints added under the ‘Shared nodes’ tab.
Managing unused & extra CUs
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.
Limitless node limits
See for tiers, supported chains, and setup.
Dedicated node limits
A funded BSC wallet with sufficient BNB for transactions and gas
GetBlock's BSC Accelerated Dedication Node
Address
Purpose
0xcA11bde05977b3631167028862bE2a173976CA11
Multicall3 contract
0x6374Ca2da5646C73Eb444aB99780495d61035f9b
Gateway fee recipient
1
Set up the project
mkdirmulticall3-examplecdmulticall3-example
mkdirmulticall3-examplecdmulticall3-example
2
Create a new file named index.js. This is where you will make your first call.
3
Set the ES module "type": "module" in your package.json.
4
Create .env file and add the following:
5
Add the following code to index.js:
The following example demonstrates a simple BNB transfer with a priority fee:
6
Run the code using this command:
7
Sample response
You can extend this code for a DEX swap by encoding the router call and including it as the second Multicall3 call:
Problem
Solution
"Multicall3: call failed"
Check you have enough BNB for all calls + gas
Increase gas limit to 200000
Verify target addresses are correct
TX not included
Increase tip amount
Check if you're rate limited
Verify TX is valid (simulate first)
Low priority despite tip
Increase tip amount
Check builder status
Try different builders: mev_builders: ["48club", "bloxroute"]
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.
Need high-performance BSC infrastructure for trading or DeFi? Contact us to discuss Accelerated Dedicated Nodes with private mempool and bundle support.
Designed to offer enterprise-grade performance sufficient for the majority of professional and business use cases, but at a more cost-efficient level. It targets demanding business applications and sustained usage, but without the additional (and sometimes excessive) headroom reserved for High Performance tier.
By providing these options, GetBlock helps you to deploy Dedicated Nodes that are tailored to your application’s technical, operational, and budget requirements.
When deploying a Dedicated Node, you can choose between High and Standard setups to align with your application’s resource needs and expected workload.
Select High if your workload is latency-sensitive, demands very high concurrent throughput, or is critical to business continuity.
Select Standard for typical production apps, where workload is within supported performance bounds.
Configuring tiers is available for all supported protocols unless there are specific infrastructure limitations for a given network. In this case, a chain will only support a single tier.
Feature
High Performance
Standard Performance
Resource allocation
Maximum hardware and bandwidth
Balanced hardware profile
Throughput
Highest supported
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
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.
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.
Dedicated Node tiers overview
Always check available configurations in your dashboard
Reference High vs Standard tier comparison
Dedicated Node pricing
Monthly costs are always shown during configuration in the Dashboard for each supported network and region.
Steps to configure dedicated node tiers
Need a more customized setup?
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.
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.
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
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
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 .
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.
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.
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.
Rug Pull Checker Endpoint
Example code for the /rug-pull/check method. Сomplete guide on how to use /rug-pull/check in GetBlock Address Audit documentation.
This method checks a smart contract for rug pull indicators. Proxied to ChainAware.
Body Parameters
Parameter
Type
Required
Description
network
string
eth_simulateV1 - Flashblocks
Example code for the eth_simulateV1 - Flashblocks method. Complete guide on how to use eth_simulateV1 - Flashblocks in GetBlock Web3 documentation.
This simulates a bundle of transactions against the latest Flashblocks — including state overrides, transfer tracing, and full validation. This is critical for MEV searchers, liquidation bots, and any application that needs to know "what would happen if I submitted this bundle right now, given the preconfirmed state?" The simulation reflects every transaction already committed to the in-progress block.
Parameter
Type
Required
Description
,
2
)))
Access Tokens: 10
Additional CU packages can be purchased as needed.
Access Tokens
: 15
Additional CU packages can be purchased as needed.
Access Tokens: 25
Add extra compute units (CU) to your account balance when needed without switching plans
Access
Tokens
: 35
Extra CU packages also available
Access Tokens: 50
Purchase additional CU packages when required
Access Tokens: 75
CU top-ups available
Access Tokens: Custom
Additional CU packages can be purchased on demand
2
Starter
$49
90M / mo
100 RPS
10
Growth
$99
185M / mo
150 RPS
15
Advanced
$199
385M / mo
300 RPS
25
Scale
$349
700M / mo
400 RPS
35
Pro
$499
1B / mo
500 RPS
50
Premium
$699
1.6B / mo
700 RPS
75
Enterprise
from $999
Custom
Custom
Custom
Compute Units are renewed daily, but unused CUs cannot be transferred to the next day.
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
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.
Step-by-step guide to getting a fast, reliable Solana RPC endpoint.
Solana is the go-to chain for high-frequency trading, DeFi, and real-time applications — which means your RPC infrastructure needs to keep up.
A Solana RPC endpoint is a URL that connects your application to a Solana validator node. Through this endpoint, your app can:
Query account balances and token holdings (getBalance, getTokenAccountsByOwner)
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:
1
Go to and sign up. You can register with email or via Google/GitHub OAuth.
2
Once logged in:
Click "Shared Nodes" in the left sidebar
Solana's WebSocket API is essential for real-time monitoring:
Solana is especially demanding on RPC infrastructure:
Challenge
Public RPC
GetBlock
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
GetBlock's proprietary StreamFirst infrastructure delivers on-chain data faster than standard Yellowstone by combining:
Accelerated Yellowstone gRPC with optimized serialization
Shred-stream delivery: receives block fragments directly via UDP before blocks are fully confirmed
The Frankfurt data center provides 6ms latency within Europe and is positioned near the highest density of Solana validators.
For sending transactions with high landing probability:
SWQoS connections to high-stakes validators
Jito Block Engine integration for bundle support
Intelligent routing based on leader schedule and network conditions
Bundle support for atomic multi-transaction operations
Building something ambitious on Solana? about custom infrastructure — we specialize in high-performance Solana deployments.
Choosing your plan
Compare GetBlock's subscription options to find the one that fits your project.
GetBlock offers four main service options: Shared Nodes, Limitless Node, Dedicated Nodes, and Enterprise Solutions. This page provides a high-level overview of these services.
You can explore detailed pricing and plans from your dashboard in the “Pricing” section or via https://getblock.io/pricing/.
Shared Nodes
Shared nodes operate on a resource-sharing model, where multiple clients access the same underlying node infrastructure maintained by GetBlock.
Our Shared Nodes deliver the perfect balance between affordability and performance:
Cost efficiency: Benefit from our pricing model based on , so you only pay for the resources needed for your current workload.
Flexible pricing: Options range from a free to high-volume plans — accessible for individual developers and smaller teams while supporting the scaling needs of growing dApps.
Consistent performance: Each plan enforces a Requests Per Second (RPS) limit, preventing individual spikes from impacting overall quality.
Multi-chain accessibility: Prototype, test, and deploy applications across different networks without the complexities of deploying infrastructure for each blockchain individually.
Regional endpoints: Connect to the nearest datacenter — Frankfurt (EU), New York (US), Singapore (APAC) — to minimize network latency.
Archive data access: Run full historical blockchain queries.
Tiered support levels: Support options adapt to your requirements, from basic help to priority support when you need it most.
Limitless Node is the middle ground between Shared and Dedicated Nodes. It's an isolated endpoint with guaranteed RPS and a flat monthly fee. Pricing is set by throughput rather than Compute Units, so you can send unlimited requests within your RPS tier without per-request metering.
Dedicated routing to ensure consistent performance and throughput.
Fixed RPS tiers: Choose the throughput level that matches your workload, from smaller setups to higher-volume production traffic.
No Compute Unit (CU) or request limits: Each plan includes a set RPS limit with unlimited requests within that tier.
A Dedicated Node is a private RPC server deployed solely for your use case. That means consistent throughput, no API rate throttling due to other users, and better uptime guarantees.
This option is ideal for users that require high performance, full control over node configuration, and a flawless connection to the blockchain without any limitations:
Mission-critical reliability: Maximized uptime and robust failover mechanisms for even more reliable service.
Unlimited usage: No per-second request caps or CU tracking.
Low latency: With servers available in Europe, Asia, and the USA, choose the optimal server location to minimize latency and enhance performance for your users.
This option is designed to meet the needs of organizations operating at scale or applications that require extra resources, features, and dedicated support.
What’s included:
99.9%+ uptime guarantee
Customizable node configurations and integrations
Performance optimization via load balancers
Advanced analytics and alert systems
Visit the to learn more about how we tailor services to fit complex, high-demand environments.
How to extend your node subscription with a card payment
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.
Use public mempool submission when:
You want faster propagation without hiding your transaction
Multi-region geo-routing: Traffic is routed to the nearest healthy node across Europe, the USA, and Asia.
Fixed pricing: Flat monthly or yearly fee with no usage-based charges.
24/7 support: Priority coverage with a response time under 5 minutes.
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.
Priority assistance from GetBlock experts
This option is ideal for developers and teams looking for reliable connectivity to various blockchain networks without the higher costs of dedicated server resources.
Limitless Node
Limitless Node fits workloads with high but predictable request volumes, where a Shared plan's Compute Unit billing is hard to forecast, but a full Dedicated Node is more than you need.
Dedicated Nodes
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.
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);
}
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);
}
});
import{Connection,PublicKey,LAMPORTS_PER_SOL}from"@solana/web3.js";constconnection=newConnection("https://go.getblock.io/<YOUR-ACCESS-TOKEN>/","confirmed");// Get current slotconstslot=awaitconnection.getSlot();console.log("Current slot:",slot);// Get SOL balanceconstpubkey=newPublicKey("7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU");constbalance=awaitconnection.getBalance(pubkey);console.log(`Balance: ${balance/LAMPORTS_PER_SOL} SOL`);// Get recent blockhash (needed for transactions)const{blockhash}=awaitconnection.getLatestBlockhash();console.log("Blockhash:",blockhash);
from solana.rpc.api import Clientfrom solders.pubkey import Pubkeyclient =Client("https://go.getblock.io/<YOUR-ACCESS-TOKEN>/")# Get current slotslot = client.get_slot()print(f"Current slot: {slot.value}")# Get SOL balancepubkey = Pubkey.from_string("7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU")balance = client.get_balance(pubkey)print(f"Balance: {balance.value /1e9} SOL")# Get recent transactions for an addresssigs = client.get_signatures_for_address(pubkey,limit=5)for sig in sigs.value:print(f" TX: {sig.signature}")
Note: Higher gas prices increase inclusion priority but also increase transaction cost.
Troubleshooting
Next Steps
How to Submit Transaction to Private Mempool
Learn how to submit transaction to private mempool directly to block builders, protecting you from MEV extraction until it's included in a block.
When you submit a transaction to the public mempool, it's visible to everyone. MEV bots can:
Sandwich your trade: Place orders before and after yours to extract value
Front-run you: Copy your trade and execute it first
Back-run you: Profit from the price impact you create
Meanwhile, Private transactions eliminate this exposure by hiding your transactions until they are included.
Aspect
Public Mempool
Private TX
Use private transactions when:
Executing large swaps that could be sandwiched
Trading tokens with low liquidity
Running strategies you don't want copied
Protecting any transaction from front-running
Parameter
Type
Required
Description
1
Set up the project
2
Set the ES module "type": "module" in your package.json.
3
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
Problem
Solution
To increase the priority for inclusion in your private transactions, see
How to use Bundle
This guide explains how to submit transaction bundles on BNB Smart Chain using GetBlock's MEV endpoint.
A bundle is a group of transactions submitted together with a guarantee that either all transactions execute in sequence or none are included. This atomic execution model supports several advanced use cases:
Arbitrage: Execute a buy on one DEX and a sell on another within the same block, ensuring both trades complete, or neither does
Liquidations: Check a position's health and liquidate it atomically, preventing front-running
Quickstart guide
Follow these steps to activate the Solana Yellowstone gRPC add-on on GetBlock
GetBlock offers 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.
A GetBlock account with a Dedicated Solana Node subscription
Your gRPC endpoint URL with access token (found in GetBlock dashboard)
The Yellowstone gRPC add-on to Solana currently requires a subscription on GetBlock. Here’s how to set it up with gRPC API:
await provider.call({
to: tx1.to,
data: tx1.data,
value: tx1.value
});
Prerequisites
Sample Request
Example
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.
Address
Purpose
Comparing Bundles and Private Transactions
Best Practices
Choose an Appropriate blocks_count Value
Simulate Before Submitting
Troubleshooting
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”
Choose Solana under “Protocol”, set the network to mainnet.
Click on Get.
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.
Return to My endpoints in your Dedicated node dashboard and generate a gRPC Access Token.
The dashboard will generate your new HTTPS‐style gRPC endpoint URL.
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:
Dragon’s Mouth uses gRPC over HTTP/2 for all communication. Its message schemas are defined in Protocol Buffer (.proto) files, included in the Yellowstone repository, which specify all the RPC methods and data types.
The power of Yellowstone is real‑time streaming: open a single bi‑directional stream, send a SubscribeRequest with your filters, and get back a sequence of SubscribeUpdate messages.
Here are the main subscription targets:
Stream Field
Proto Name
What You Get
slots
slots: SlotsFilter
Slot numbers as they’re processed by leader
blocks
blocks: BlocksFilter
Block metadata (slot, parent slot, timestamp)
Developers can integrate Yellowstone streams using standard gRPC client libraries. Triton’s Yellowstone repository includes example clients 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.
A generic tool like grpcurl is perfect to just poke at the API and explore method calls:
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:
Below are minimal examples using Triton's Yellowstone helper libraries to stream real-time data from Solana via gRPC.
Setup & run:
cd go-client
go mod tidy
go run main.go
Make sure the following dependencies are installed:
go get github.com/rpcpool/yellowstone-grpc/examples/golang@latest
go get google.golang.org/grpc@latest
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)
Setup:
Ensure your Cargo.toml includes:
Rust Example (rust-client/src/main.rs):
In addition to streaming subscriptions, the same gRPC interface also provides unary RPCs for quick, one-off queries:
getSlot: Returns the current slot number.
getBlockHeight: Retrieves the current block height.
getLatestBlockhash: Fetches the most recent blockhash.
isBlockhashValid: Checks whether a given blockhash is still valid.
getVersion: Returns version info for both the gRPC plugin and the connected Solana node
You can call these methods directly on the gRPC client without opening a streaming connection.
Before you start streaming data with the Yellowstone Geyser plugin, consider these recommendations:
Filtering is crucial: Always narrow your subscription to only the accounts or programs you need. Excessive or empty filters can overwhelm clients and hit rate limits.
Combine with JSON‑RPC: Use gRPC for real‑time streaming. Continue to use GetBlock’s JSON‑RPC Solana endpoints for on‑demand calls like getBlock, sendTransaction, or historical queries.
Keeping your stream alive: gRPC streams may time out if idle. The Yellowstone plugin can handle keep-alive pings. In your SubscribeRequest, you can set ping: true to respond to server pings (or send a minimal ping message periodically) to keep the stream alive.
Selecting the right commitment levels: Choose processed, confirmed, or finalized in your SubscribeRequest to balance between lowest latency (processed) and highest certainty (finalized). For most real‑time use cases (dashboards, bots), use processed to see intra‑slot updates.
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.
// 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>/
npm install @triton-one/yellowstone-grpc
# or
yarn add @triton-one/yellowstone-grpc
import Client, {
SubscribeRequest,
CommitmentLevel,
SubscribeResponse,
} from "@triton-one/yellowstone-grpc";
async function main() {
// Initialize
const ENDPOINT = "https://go.getblock.io/";
const TOKEN = "<YOUR_ACCESS_TOKEN>";
const client = new Client(ENDPOINT, TOKEN);
// Open a bidirectional stream
const stream = await client.subscribe();
// send a request to start all streams
stream.write({
accounts: ["YourWalletPubkeyHere"],
programs: [],
commitment: CommitmentLevel.PROCESSED,
} as SubscribeRequest);
stream.on("data", (msg: SubscribeResponse) => {
if (msg.accountChange) {
console.log(
`▶ Account ${msg.accountChange.pubkey} = ${msg.accountChange.lamports}`
);
}
});
// End the stream
stream.end();
await client.close();
}
main().catch(console.error);
All Dedicated Node plan subscribers receive the Yellowstone gRPC API at no extra cost together with their Solana node.
Get your gRPC endpoint
Endpoint & authentication
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.
Subscribing to Data Streams: Code examples
All filters can be combined in the same request.
1. CLI (using grpcurl)
2. Using a high‑level SDK (Node.js / TypeScript)
3. Python, Rust, and Go streaming examples
Unary RPC methods
Yellowstone gRPC best practices
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.
💬 Need help?
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.
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