The BNB Smart Chain methods the Triport dedicated pool now covers

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 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 and 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 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, and for pending activity it is a live feed rather than the point-in-time sample that txpool_content returns from one node. The BSC pending-transactions guide 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 429s on the deepest eth_getLogs scans, which is exactly why rate limits remain a published per-plan policy, documented in 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.

Two cells deserve a note. The eth_getLogs row uses only Alchemy's published per-plan table — the same one the block-range post 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.

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, 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.

Sources

1. Triport, eth_getLogs on BNB Smart Chain: 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, eth_getTransactionByHash and eth_getTransactionReceipt on BNB Smart Chain: whole-block receipts and full-index transaction lookup.
3. Triport, BSC limits: per-plan read and heavy-read RPS policy and burst behaviour.
4. Triport, BSC RPC endpoint and BNB Smart Chain API reference: the published BSC surface.
5. Triport, eth_getLogs block range limits across EVM chains: the adaptive pager and the per-chain failure taxonomy.
6. Alchemy, eth_getLogs reference (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 (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.