Band Protocol · Rate Limits

Band Protocol Rate Limits

BandChain's public REST and gRPC endpoints do not publish explicit rate limits for read-only queries. Throttling is governed by individual node operators and public endpoint infrastructure. For production workloads with high query volume, Band Protocol recommends running a dedicated full node or using a third-party node provider. On-chain write operations (transactions) are rate-limited by block throughput and BAND gas fees which serve as an economic rate-limiting mechanism.

Band Protocol Rate Limits is the machine-readable rate-limit profile for Band Protocol on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring requests_per_second, transactions_per_block, and requests_per_period.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled and serverError.

Tagged areas include Rate Limiting, Blockchain, and Oracle.

4 Limits Throttle: 429
Rate LimitingBlockchainOracle

Limits

REST read queries (public mainnet node) endpoint
requests_per_second · second
Not formally published; subject to node operator discretion. Run a dedicated node for high-volume needs.
gRPC read queries (public mainnet node) endpoint
requests_per_second · second
Not formally published; subject to node operator discretion.
Block throughput (on-chain writes) network
transactions_per_block · block
BandChain targets ~3 second block times. Transaction throughput is shared across all network participants. Gas fees serve as economic throttling for write operations.
Testnet faucet account
requests_per_period · day
1
Testnet faucet limits one BAND dispense per address per day.

Policies

Public node fair use
Public endpoints at laozi1.bandchain.org are provided as a community service. Heavy automated querying is discouraged; production applications should run their own node or use a node-as-a-service provider.
Gas fee economic throttling
On-chain data requests require BAND token gas fees, providing an economic deterrent to spam and effectively rate-limiting high-frequency write operations.
Retry with backoff
On receiving HTTP 429 or connection errors from a public node, implement exponential backoff before retrying.
Dedicated node for production
For latency-sensitive or high-throughput production workloads, Band Protocol recommends running a dedicated full node (4+ CPU, 16 GB RAM, 150 GB+ SSD).

Sources