# The BNB Smart Chain methods the Triport dedicated pool now covers

> BSC used to be the read-only corner of the gateway. A dedicated pool closes the methods that a public gateway could not — wide log ranges, full history, debug traces and a WebSocket — and this is where each one lands against what other providers publish.

- Canonical: https://triport.io/blog/bsc-rpc-methods-now-covered
- Published: 2026-10-31
- Updated: 2026-10-31
- Author: Triport Engineering
- Category: Engineering
- Networks: BNB Smart Chain

## TL;DR

- The dedicated BSC pool closes six things a public BNB gateway cannot keep up: full history to genesis, transaction lookup by old hash, eth_getLogs over wide ranges, eth_getBlockReceipts for whole-block logs, debug_traceTransaction and debug_traceBlockByNumber, and a /ws/bsc socket for newHeads, logs and a stream of pending transaction hashes — and on the current load profile clients are not served 5xx or 429 on BSC.
- The method that moves the most is eth_getLogs: the Triport endpoint serves up to 50,000 blocks and 50,000 logs per response, against the previous 100-block ceiling, so a 100,000-block backfill of one contract is 2 calls instead of 1,000 — and a wide range still splits on a range or result-count error.
- Trace and WebSocket are where providers split: several sell debug/trace as an upper-tier or add-on feature and gate WebSocket to paid plans, so the honest comparison is not 'who has the method' but 'what plan the method needs'.

For most of this year BNB Smart Chain was the read-only corner of the gateway: 22 read methods, `eth_getLogs` capped at around 100 blocks, a routed-node `txpool` view, and no WebSocket. That was an honest reflection of what a pool of public BNB gateways can serve. A dedicated pool changes the ceiling, and this post is about which methods it closes on BSC and how each one lands against what other providers publish.

Nothing here is a latency claim and none of it is a throughput SLA. It is a list of methods that now return, the documented limits that bound them, and the public facts that let you compare.

## What a dedicated pool changes

A public gateway is shared infrastructure sized for the median caller. It answers `eth_blockNumber` and `eth_call` all day, but the expensive, scan-heavy methods are exactly the ones an operator rations first: a wide `eth_getLogs` is a multi-block bloom scan, `debug_traceBlockByNumber` re-executes every transaction in a block, and a `logs` subscription holds an open socket per client. On a shared BNB pool those are either capped hard or turned off, which is why the earlier BSC surface documented `eth_getLogs` as a 25/100-block per-node profile and published no trace or WebSocket at all.

A dedicated pool removes the sharing. The methods below are the ones that depend on it — they were not missing because the chain cannot do them, but because a public node would not spend the work on your behalf.

## The methods now covered on BSC

**Full history and receipts.** The pool answers archive-depth reads to genesis, and [`eth_getBlockReceipts`](https://triport.io/docs/bsc/json-rpc/eth_getBlockReceipts) returns every receipt of a block — logs, status and gas in one call. That pair is the backbone of any reconciliation job: receipts give you the logs without a range filter, and archive depth means a backfill never hits a pruned wall partway down.

**Transaction lookup by old hash.** [`eth_getTransactionByHash`](https://triport.io/docs/bsc/json-rpc/eth_getTransactionByHash) and [`eth_getTransactionReceipt`](https://triport.io/docs/bsc/json-rpc/eth_getTransactionReceipt) resolve against the full index, not just recent blocks, so a hash from a year ago still returns its transaction and its receipt rather than a null.

**Wide `eth_getLogs`.** This is the method that moves the most. The dedicated pool serves ranges up to **50,000 blocks and 50,000 logs per response**, against the previous 100-block ceiling. A 100,000-block backfill of one contract is 2 calls instead of 1,000. The ceiling still exists for a reason — a log query is a scan and a response has a size — so a correct indexer still pages and still treats a range error as a signal to split, which the [block-range-limits walkthrough](https://triport.io/blog/eth-getlogs-block-range-limits) covers in full. What changes is the size of the window you start from.

**Execution traces.** `debug_traceTransaction` and `debug_traceBlockByNumber` with `callTracer` return the internal call tree — the contract-to-contract calls, value transfers and reverts that no log or receipt records. That is the difference between knowing a transaction failed and knowing which internal call reverted it. These run through a deterministic trace router on a best-effort basis with no latency or throughput SLA: under load a trace can be declined rather than queued without end, so treat it as a diagnostic call, not a hot-path dependency.

**A `/ws/bsc` socket.** A single WebSocket carries `newHeads`, `logs` and `newPendingTransactions` subscriptions, and batches them on one connection. The `newPendingTransactions` channel is a stream of pending transaction *hashes*, not full transaction bodies — fetch the body with `eth_getTransactionByHash` when you need it — and the `logs` subscription requires a non-empty filter (an `address`, one or more `topics`, or both); an empty filter is refused the same way a chain-wide `eth_getLogs` is. For head tracking and event triggers the socket replaces a polling loop against `eth_getBlockByNumber` and [`eth_getLogs`](https://triport.io/docs/bsc/json-rpc/eth_getLogs), and for pending activity it is a live feed rather than the point-in-time sample that [`txpool_content`](https://triport.io/docs/bsc/json-rpc/txpool_content) returns from one node. The [BSC pending-transactions guide](https://triport.io/blog/bsc-pending-transactions) explains why the `txpool` view is a sample and a subscription is not.

**A pool sized so your load is not shed.** On the current load profile clients are not served `5xx` or `429` on BSC — the shared-gateway failure mode where a burst from someone else becomes your error. This is a statement about the current profile, not a guarantee: a seven-day baseline measurement did record `429`s on the deepest `eth_getLogs` scans, which is exactly why rate limits remain a published per-plan policy, documented in [BSC limits](https://triport.io/docs/bsc/limits), rather than an absence of limits. The point is that a dedicated pool makes those documented limits the only ceiling, instead of a shared one you cannot see.

## How this compares to other BSC providers

The honest comparison is not "who has the method" — most providers can trace a BSC block if you pay for the right node. It is which plan the method needs and how wide a range it will serve. The table below uses only figures each provider documents publicly, or its published pricing; where a number is not publicly documented it is left out rather than guessed.

| Method / capability | Triport BSC (dedicated pool) | What other providers document publicly |
|---|---|---|
| `eth_getLogs` block range | up to 50,000 blocks / 50,000 logs per response (Triport endpoint limit) | Alchemy documents a 10-block range on its Free plan, wider ranges on paid plans, and a 150 MB response cap on every plan (read 2026-10-31) |
| Full archive history | to genesis | archive access is typically a higher tier or a dedicated-node line item |
| `eth_getBlockReceipts` / tx by old hash | full index | available where archive is enabled |
| `debug_traceTransaction` / `debug_traceBlockByNumber` | served on the pool, best-effort, no SLA | a paid feature at most providers — QuickNode includes Trace & Debug from its Build plan ($49/mo, read 2026-10-31); others sell it as an upper tier or a separate add-on |
| WebSocket (`newHeads` / `logs` / pending hashes) | `/ws/bsc`, batched on one socket | commonly a paid-tier feature; some free plans do not serve a BSC WebSocket at all |
| Dedicated, non-shared pool | yes, on flat monthly plans | a single-tenant BSC node at other providers is typically a separately priced, dedicated line item |

Two cells deserve a note. The `eth_getLogs` row uses only Alchemy's published per-plan table — the same one the [block-range post](https://triport.io/blog/eth-getlogs-block-range-limits) cites — because it is the figure we can point at a public page for; the 50,000-block number on the Triport side is this endpoint's own limit, not a claim about anyone else's upstream. Figures for other BSC providers that we could not tie to a current public page were left out of this table rather than guessed. The trace and WebSocket rows are where the "who has the method" framing misleads — the method exists almost everywhere, but the plan it requires is the real cost, so compare plans, not checkmarks. For the full per-provider price breakdown see [the best BSC RPC providers comparison](https://triport.io/compare/best-bsc-rpc-providers).

## Reading wide log ranges without tripping a cap

A wider ceiling does not retire the pager; it changes its starting window. The rule is the same one that works on every chain: start at a window, shrink it on a range or too-many-results error, grow it after a run of successes, and keep three failures apart — a range that is too wide (shrink), a result set that is too large (split the same range), and a block below the node's history (no window helps). Filter by `address` whenever you can, because an address-less filter is a scan of every contract's [event logs](https://triport.io/learn/glossary/event-log), and store each page before you advance the cursor so a crash never skips a window.

With a 50,000-block ceiling the arithmetic changes in your favour. A one-million-block backfill of a single busy contract that would have been 10,000 calls at a 100-block window is 20 calls at the pool's ceiling — before the result-count cap forces any split. That is the difference between a backfill you schedule overnight and one you run inline.

## When this is the wrong approach

- **You broadcast transactions.** BSC on the pool is a read surface. There is no submission category, so `eth_sendRawTransaction` is not served here — sign and broadcast through your own node or a provider that sells submission.
- **You need every event on the chain.** A wider `eth_getLogs` window is still a filtered scan; an address-less, chain-wide filter is exactly what a node refuses. Read receipts block by block with `eth_getBlockReceipts`, or run a purpose-built indexer.
- **You treat `txpool` as the whole mempool.** `txpool_content` is one node's local pool, a sample, not the network. For a live pending feed use the `/ws/bsc` `newPendingTransactions` subscription — a stream of pending transaction hashes, not full transaction bodies — and still treat it as partial.
- **You need a throughput or latency guarantee.** None of this is an SLA. The limits are a published per-plan policy; size your traffic against the sustained rate in [BSC limits](https://triport.io/docs/bsc/limits).

## Sources

1. Triport, [eth_getLogs on BNB Smart Chain](https://triport.io/docs/bsc/json-rpc/eth_getLogs): this endpoint's block range (50,000 blocks / 50,000 logs per response), up from the previous 25/100-block per-node profile.
2. Triport, [eth_getBlockReceipts](https://triport.io/docs/bsc/json-rpc/eth_getBlockReceipts), [eth_getTransactionByHash](https://triport.io/docs/bsc/json-rpc/eth_getTransactionByHash) and [eth_getTransactionReceipt](https://triport.io/docs/bsc/json-rpc/eth_getTransactionReceipt) on BNB Smart Chain: whole-block receipts and full-index transaction lookup.
3. Triport, [BSC limits](https://triport.io/docs/bsc/limits): per-plan read and heavy-read RPS policy and burst behaviour.
4. Triport, [BSC RPC endpoint](https://triport.io/bsc-rpc) and [BNB Smart Chain API reference](https://triport.io/docs/bsc): the published BSC surface.
5. Triport, [eth_getLogs block range limits across EVM chains](https://triport.io/blog/eth-getlogs-block-range-limits): the adaptive pager and the per-chain failure taxonomy.
6. Alchemy, [eth_getLogs reference](https://www.alchemy.com/docs/reference/eth-getlogs) (read 2026-10-31): Free-plan 10-block range, wider ranges on paid plans, and a 150 MB response cap on every plan, for a chain set that includes BNB.
7. QuickNode, [pricing](https://www.quicknode.com/pricing) (read 2026-10-31): the Build plan ($49/mo) includes Trace & Debug methods.

> Block-range figures for NodeReal and Chainstack that earlier drafts carried were removed before publish: no current public page states a per-plan `eth_getLogs` ceiling for BSC that we could cite, so they are left out rather than guessed.

## Try it

- Reference: [eth_getLogs on BNB Smart Chain](https://triport.io/docs/bsc/json-rpc/eth_getLogs)
- Network: [BSC RPC — endpoints, limits and plans](https://triport.io/bsc-rpc)