> For the complete documentation index, see [llms.txt](https://docs.triton.one/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.triton.one/solana/real-time-streaming/preconfirmations-grpc/coverage-billing-and-limits.md).

# Coverage, billing and limits

Preconfirmations gRPC coverage share per region, the RESOURCE\_EXHAUSTED cooloff, what Harmonic and BAM count for billing, and limits on filters and streams.

## Coverage

Each subscription may receive up to a share of a feed's traffic in each region. This is a condition agreed with the feed operators: the share is what keeps anyone from rebuilding the full firehose through Triton. It is not a rate limit on the server; a narrow filter never hits it.

How it is measured:

* The default share is **33%** of what a feed publishes in the region you subscribe, counted over a sliding **60 second** window. It counts transactions delivered to you, after all your filters including `execution_results`. Harmonic and BAM are counted separately. The percentage is agreed with the feed operators and can change; this page states the current default.
* It belongs to the **subscription and the region**: every token, connection and stream of your subscription on one region draws on that region's share. Opening more streams on a region or rotating filters does not widen it, and each region you subscribe has a share of its own, so streams on `ams` and `fra` do not eat into each other.
* A **burst cap** holds instantaneous delivery to half the feed's current rate, so a spike cannot take the whole window's share in a second.
* Each point of presence measures on its own.

What happens over the share:

{% stepper %}
{% step %}

### Matching transactions are withheld

The count arrives as a `Clip` event, at most once a second on a timer and, on Harmonic, always before the affected slot's `SlotEnd`, so a completed slot is never silently short.
{% endstep %}

{% step %}

### The stream ends after 30 seconds over the share

If your subscription stays over the share for **30 seconds** without recovering, the stream ends with `RESOURCE_EXHAUSTED` and the message `account exceeded its coverage limit for this region, cooling off`. Every other open stream of the subscription on that region ends the same way at its next matching transaction during the cooloff.
{% endstep %}

{% step %}

### Subscribing again is refused for 60 seconds

Subscribing again to that region is refused for **60 seconds** with `account is cooling off after exceeding its coverage limit for this region, retry in <N>s`. With reconnect on, a stream that was ended this way keeps retrying on its own and resumes after the cooloff; a new subscribe call during the cooloff returns the error. Your other regions are not affected.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
Staying under it: subscribe to what you act on rather than to whole programs. A filter on a busy program such as the SPL token program can reach the share quickly; the same program narrowed to one instruction with `instructions`, to your pools or wallets with `account_required` or `signer_include`, or with the spam removed by `account_exclude`, does not. If your use needs a larger share, ask through support; the share can be set per subscription and feed.
{% endhint %}

## Billing

Two quantities are counted per subscription and per feed:

| quantity   | counts                                                                                                                                    |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `messages` | transactions delivered on your streams                                                                                                    |
| `slots`    | Harmonic: every slot whose `SlotEnd` reaches your streams, matched or not. BAM: only slots with at least one transaction delivered to you |

Pay-as-you-go prices are on the [pricing page](https://triton.one/pricing). Your daily usage is in the customer panel. For how billing works across Triton services, see [Plans and billing](/account-and-billing/plans-and-billing.md).

Not counted as messages: `SlotStart`, `SlotEnd`, pings, `Clip` notices, transactions your filters did not match, and transactions withheld by coverage.

Messages add up across streams: two streams whose filters overlap receive, and are counted for, the same transactions twice. A transaction matching several filters on one stream is delivered and counted once.

Slots are counted once per subscription and feed on each point of presence. More streams on a region, or a reconnect to the same point of presence, don't count a slot again. Regions carry different slots, so each region you add counts the slots it carries. Streams that land on different points of presence each count it.

## Limits

| limit                                            | value             |
| ------------------------------------------------ | ----------------- |
| filters per stream                               | 64                |
| accounts per account or signer list              | 10000             |
| signatures per filter (`signature`)              | 1000              |
| filter name                                      | 64 bytes          |
| instruction filters per stream, over all filters | 32                |
| memcmps per instruction filter                   | 4                 |
| bytes per memcmp                                 | 1 to 128          |
| memcmp end and `data_size`                       | within 4096 bytes |
| concurrent streams per account                   | 1000              |

The client checks every limit but the last before sending, so a request over a limit fails locally with a `FilterError`; the server refuses the same request with `INVALID_ARGUMENT`. Clients before 0.4.1 check 16 instruction filters per stream; upgrade to use up to 32. A memcmp that ends past its own `data_size` could never match and is refused the same way. The stream limit is counted per point of presence across both feeds. How each condition matches is described in [Filters](/solana/real-time-streaming/preconfirmations-grpc/filters.md).

***

<i class="fa-life-ring">:life-ring:</i> Contact support by clicking the chat icon in your [customer dashboard](https://customers.triton.one)\ <i class="fa-briefcase">:briefcase:</i> Sales questions? [Contact us](https://triton.one/contact)\ <i class="fa-sparkles">:sparkles:</i> AI agent? Read [llms.txt](https://docs.triton.one/llms.txt)\ <i class="fa-rss">:rss:</i> Follow updates: [Blog](https://blog.triton.one) · [X](https://x.com/triton_one) · [YouTube](https://www.youtube.com/@triton_one_ltd) · [Telegram](https://t.me/tritonone) · [GitHub](https://github.com/rpcpool)