Planned
Unified Endpoint for Different Regions and Modes (Full / Archive)
Right now, it’s a bit inconvenient to manually switch between different endpoints for each region and mode. It would be great to have one universal endpoint that automatically connects to the right region (like EU, US, or Asia) and allows me to choose between Full or Archive mode using a simple parameter. This would make it much easier to manage connections and test different environments without changing URLs every time. It also helps keep scripts cleaner and reduces the risk of errors when switching networks.
Max M 4 months ago
Planned
Unified Endpoint for Different Regions and Modes (Full / Archive)
Right now, it’s a bit inconvenient to manually switch between different endpoints for each region and mode. It would be great to have one universal endpoint that automatically connects to the right region (like EU, US, or Asia) and allows me to choose between Full or Archive mode using a simple parameter. This would make it much easier to manage connections and test different environments without changing URLs every time. It also helps keep scripts cleaner and reduces the risk of errors when switching networks.
Max M 4 months ago
In Progress
Usage & subscription alerts via email
It’s getting really difficult to manage my nodes and subscriptions without alerts. We used to have notifications for CU usage and node expiration — that was incredibly helpful. Now that they’re gone, I often realize something has expired or hit the limit only after production requests start failing. When you’re running several networks like Polygon, BNB, or Solana, it’s just not realistic to keep checking everything manually in the dashboard. It would be great to bring those alerts back — usage thresholds, upcoming expirations, and maybe even email or Slack notifications. That feature saved a lot of time and prevented unnecessary downtime. Honestly, it was one of the most useful parts of the old dashboard, and I really miss it. 🙏
Max M 4 months ago
In Progress
Usage & subscription alerts via email
It’s getting really difficult to manage my nodes and subscriptions without alerts. We used to have notifications for CU usage and node expiration — that was incredibly helpful. Now that they’re gone, I often realize something has expired or hit the limit only after production requests start failing. When you’re running several networks like Polygon, BNB, or Solana, it’s just not realistic to keep checking everything manually in the dashboard. It would be great to bring those alerts back — usage thresholds, upcoming expirations, and maybe even email or Slack notifications. That feature saved a lot of time and prevented unnecessary downtime. Honestly, it was one of the most useful parts of the old dashboard, and I really miss it. 🙏
Max M 4 months ago
“Sandbox” environment for testing endpoints
When I’m integrating new networks (like Polygon, Arbitrum, or Near), I usually start by testing basic RPC calls — things like eth_getBlockByNumber, eth_call, or getBalance. The problem is, every one of these tests consumes real Compute Units (CU), even if I’m just debugging payloads, checking response formats, or running quick CI/CD checks. It would be super helpful to have a Sandbox Mode directly in the dashboard — a lightweight environment where we can run limited read-only RPC requests without burning CU. Here’s what I imagine: A simple toggle or section in each network tab: “🔧 Sandbox Mode.” When enabled, requests go through a sandbox endpoint The sandbox would return limited blockchain data (for example, the last 100 blocks), and only support read-only methods. That kind of setup would be perfect for: CI/CD health checks SDK testing Quick debugging before moving to production endpoints Even small limits (say, 50 requests per minute) would make a big difference. This feature would save a lot of CU during development and make it easier to experiment with new networks safely inside the dashboard. Thanks for considering! 🙌
Max M 4 months ago
“Sandbox” environment for testing endpoints
When I’m integrating new networks (like Polygon, Arbitrum, or Near), I usually start by testing basic RPC calls — things like eth_getBlockByNumber, eth_call, or getBalance. The problem is, every one of these tests consumes real Compute Units (CU), even if I’m just debugging payloads, checking response formats, or running quick CI/CD checks. It would be super helpful to have a Sandbox Mode directly in the dashboard — a lightweight environment where we can run limited read-only RPC requests without burning CU. Here’s what I imagine: A simple toggle or section in each network tab: “🔧 Sandbox Mode.” When enabled, requests go through a sandbox endpoint The sandbox would return limited blockchain data (for example, the last 100 blocks), and only support read-only methods. That kind of setup would be perfect for: CI/CD health checks SDK testing Quick debugging before moving to production endpoints Even small limits (say, 50 requests per minute) would make a big difference. This feature would save a lot of CU during development and make it easier to experiment with new networks safely inside the dashboard. Thanks for considering! 🙌
Max M 4 months ago
gRPC support for Tron
Lately a lot of users have been requesting gRPC support on shared Tron nodes as it would help them in their various projects
Mohammed Amuneh 4 months ago
gRPC support for Tron
Lately a lot of users have been requesting gRPC support on shared Tron nodes as it would help them in their various projects
Mohammed Amuneh 4 months ago
API endpoint for checking account balance and remaining CU
Users want to automatically monitor their account balance and CU usage to set up alerts in Prometheus/Blackbox Exporter, Grafana, and other monitoring systems. GetBlock currently does not provide a public API that returns: current account balance (USD or CU), CU included in the plan, CU usage and remaining CU, estimated time until depletion.
Nick D 3 months ago
API endpoint for checking account balance and remaining CU
Users want to automatically monitor their account balance and CU usage to set up alerts in Prometheus/Blackbox Exporter, Grafana, and other monitoring systems. GetBlock currently does not provide a public API that returns: current account balance (USD or CU), CU included in the plan, CU usage and remaining CU, estimated time until depletion.
Nick D 3 months ago
Solana archive node
As a data analyst working with Solana, I frequently need access to historical state data - not just recent transactions, but the exact state of accounts, token balances, and programs at a specific slot. The problem is that standard Solana RPC nodes (even full ones) only keep recent ledger data, usually covering just a few days or weeks. That means: You can’t fetch token balances or account data for a block from 2022 or even early 2023. Methods like getProgramAccounts, getBalance, or getAccountInfo only return current data — not historical state. Even if you use getBlock(slot), older slots are pruned and simply unavailable. For analytics, audits, and data integrity checks, this is a huge blocker. Example use cases: Compliance & auditing: verifying token flows or validator rewards from last year. Research: analyzing DeFi protocols’ evolution, like changes in TVL or staking behavior over time. Forensics: investigating exploits, tracing suspicious activity, or reconstructing on-chain events. Data science: building dashboards or ML models that rely on complete time-series data. To make this possible, we need an archive Solana node — one that stores the full historical ledger and allows queries like: getBlock(slot, { encoding: "jsonParsed" }) getAccountInfo(pubkey, { commitment: "finalized", slot: }) Even if access is rate-limited or premium-only, it’s critical for analytics and infrastructure projects. Right now, the only workaround is using third-party data providers or manually archiving data — both expensive and unreliable. Having a native archival RPC endpoint from GetBlock would be a game-changer for any serious Solana data work
Max M 4 months ago
Solana archive node
As a data analyst working with Solana, I frequently need access to historical state data - not just recent transactions, but the exact state of accounts, token balances, and programs at a specific slot. The problem is that standard Solana RPC nodes (even full ones) only keep recent ledger data, usually covering just a few days or weeks. That means: You can’t fetch token balances or account data for a block from 2022 or even early 2023. Methods like getProgramAccounts, getBalance, or getAccountInfo only return current data — not historical state. Even if you use getBlock(slot), older slots are pruned and simply unavailable. For analytics, audits, and data integrity checks, this is a huge blocker. Example use cases: Compliance & auditing: verifying token flows or validator rewards from last year. Research: analyzing DeFi protocols’ evolution, like changes in TVL or staking behavior over time. Forensics: investigating exploits, tracing suspicious activity, or reconstructing on-chain events. Data science: building dashboards or ML models that rely on complete time-series data. To make this possible, we need an archive Solana node — one that stores the full historical ledger and allows queries like: getBlock(slot, { encoding: "jsonParsed" }) getAccountInfo(pubkey, { commitment: "finalized", slot: }) Even if access is rate-limited or premium-only, it’s critical for analytics and infrastructure projects. Right now, the only workaround is using third-party data providers or manually archiving data — both expensive and unreliable. Having a native archival RPC endpoint from GetBlock would be a game-changer for any serious Solana data work
Max M 4 months ago
Interactive playground inside the documentation
When reading the docs, I spend half my time copying request examples into Postman, fixing missing quotes, and adjusting parameters before I can even test a call. It slows everything down. It would be awesome to have an interactive playground directly inside the documentation. For example, select a network, pick a method, hit ‘Run,’ and instantly see a real RPC response. That kind of embedded sandbox would make onboarding much faster for new developers and help experienced ones experiment directly from the docs — making the documentation truly interactive
Max M 4 months ago
Interactive playground inside the documentation
When reading the docs, I spend half my time copying request examples into Postman, fixing missing quotes, and adjusting parameters before I can even test a call. It slows everything down. It would be awesome to have an interactive playground directly inside the documentation. For example, select a network, pick a method, hit ‘Run,’ and instantly see a real RPC response. That kind of embedded sandbox would make onboarding much faster for new developers and help experienced ones experiment directly from the docs — making the documentation truly interactive
Max M 4 months ago
Price API (Indexing)
On-Chain Token Prices from DEXs like Uniswap / 1inch It would be super useful to have a Price API that gives access to real-time token prices directly from blockchain data (from DEX smart contracts like Uniswap, 1inch, PancakeSwap, etc). Right now, I have to rely on third-party price feeds, which often go down or don’t reflect on-chain prices accurately. Having an on-chain indexed Price API from GetBlock would save a lot of time for DeFi projects — we could easily display token prices, calculate portfolio values, or build dashboards that stay fully decentralized.
Max M 4 months ago
Price API (Indexing)
On-Chain Token Prices from DEXs like Uniswap / 1inch It would be super useful to have a Price API that gives access to real-time token prices directly from blockchain data (from DEX smart contracts like Uniswap, 1inch, PancakeSwap, etc). Right now, I have to rely on third-party price feeds, which often go down or don’t reflect on-chain prices accurately. Having an on-chain indexed Price API from GetBlock would save a lot of time for DeFi projects — we could easily display token prices, calculate portfolio values, or build dashboards that stay fully decentralized.
Max M 4 months ago
JavaScript SDK for easy multi-network access
It would be very useful to have an official JavaScript SDK that allows developers to easily connect to multiple blockchain networks using a single API key. The SDK should: Be easily embeddable into any JS/TS project Support multiple networks out of the box Handle configuration and provider setup internally Simplify onboarding and improve developer experience Such a library would significantly reduce integration time and make the platform more developer-friendly for web3 applications.
Max M About 2 months ago
JavaScript SDK for easy multi-network access
It would be very useful to have an official JavaScript SDK that allows developers to easily connect to multiple blockchain networks using a single API key. The SDK should: Be easily embeddable into any JS/TS project Support multiple networks out of the box Handle configuration and provider setup internally Simplify onboarding and improve developer experience Such a library would significantly reduce integration time and make the platform more developer-friendly for web3 applications.
Max M About 2 months ago
Pay-as-you-grow
Flexible pricing that scales with your usage as your project grows. Automatically pay for extra usage beyond plan limits without service interruption.
sub services 4 months ago
Pay-as-you-grow
Flexible pricing that scales with your usage as your project grows. Automatically pay for extra usage beyond plan limits without service interruption.
sub services 4 months ago
Webhook notifications for new blocks and smart contract events
Currently, our backend polls eth_blockNumber every three seconds just to check if a new block has appeared. It’s wasteful — consumes CU, adds traffic, and introduces delays in data updates. It would make much more sense to have webhook or push notifications from GetBlock. For example, when a new block or an ERC-20 Transfer() event appears, your service could send a POST request to our endpoint with a payload like { blockNumber, txCount, events[] }. This approach would: eliminate constant polling, deliver data in real time, speed up UI updates, and make real-time analytics possible without a websocket layer. Webhook triggers would be a huge improvement for anyone building DeFi services or on-chain activity trackers.”
Max M 4 months ago
Webhook notifications for new blocks and smart contract events
Currently, our backend polls eth_blockNumber every three seconds just to check if a new block has appeared. It’s wasteful — consumes CU, adds traffic, and introduces delays in data updates. It would make much more sense to have webhook or push notifications from GetBlock. For example, when a new block or an ERC-20 Transfer() event appears, your service could send a POST request to our endpoint with a payload like { blockNumber, txCount, events[] }. This approach would: eliminate constant polling, deliver data in real time, speed up UI updates, and make real-time analytics possible without a websocket layer. Webhook triggers would be a huge improvement for anyone building DeFi services or on-chain activity trackers.”
Max M 4 months ago
Onboarding tour
Interactive walkthrough that helps new users explore dashboard features and set up and test their first endpoint.
sub services 4 months ago
Onboarding tour
Interactive walkthrough that helps new users explore dashboard features and set up and test their first endpoint.
sub services 4 months ago