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 6 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 6 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 6 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 6 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 6 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 6 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 5 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 5 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 6 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 6 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 6 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 6 months ago
Onboarding tour
Interactive walkthrough that helps new users explore dashboard features and set up and test their first endpoint.
sub services 6 months ago
Onboarding tour
Interactive walkthrough that helps new users explore dashboard features and set up and test their first endpoint.
sub services 6 months ago
Planned
IP whitelisting
Provide access to whitelisted IPs which I can add in personal account to every node, endpoint or whole account’s artifacts.
Dmitrii Petrov 6 months ago
Planned
IP whitelisting
Provide access to whitelisted IPs which I can add in personal account to every node, endpoint or whole account’s artifacts.
Dmitrii Petrov 6 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 6 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 6 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 6 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 6 months ago
Boost RPC
A button that temporarily increases the RPS limit for a selected endpoint. Useful during traffic spikes, syncs, or testing without changing the plan permanently.
sub services 6 months ago
Boost RPC
A button that temporarily increases the RPS limit for a selected endpoint. Useful during traffic spikes, syncs, or testing without changing the plan permanently.
sub services 6 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 3 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 3 months ago