# Rate Limits - Overview
Source: https://docs.chain.link/ccip/evm/concepts/cross-chain-token/rate-limits/overview
Last Updated: 2025-06-09

> For the complete documentation index, see [llms.txt](/llms.txt).

> **NOTE: CCIP 2.0**

CCIP rate limits are an operator-level control on token pools. They limit how much of a token can move across a specific CCIP lane over time, reducing blast radius during incidents and helping manage operational risk.

This documentation is for operators, token issuers, and administrators who manage rate limits on token pool contracts. Most integrators do not need to interact with rate limits. Changes are applied onchain, take effect immediately, and directly affect transfer availability.

> **NOTE: Private/Permissioned Networks**
>
> It is strongly recommended to configure Token Pool Rate Limits (TPRLs) for CCTs on all lanes. Private/permissioned
> networks carry increased risk for token developers. Ensure you understand the implications before proceeding. [Learn
> More](/ccip/evm/service-limits).

## How rate limits work

Rate limits are **capacity buckets** that refill over time. Each bucket has three parameters:

- **isEnabled**: whether the limit is active
- **capacity**: maximum number of tokens the bucket can hold
- **rate**: refill speed in tokens per second

Transfers consume capacity; if enough is not available, the transfer is rejected until the bucket refills. A transfer larger than the capacity is rejected even when the bucket is full. All values use the token's **local smallest unit** on the chain where the pool is deployed. When enabled, rate must be ≤ capacity.

Each token pool maintains up to **four limiters per remote chain (v2.0)**:

| Bucket        | Direction          | Used for                    |
| ------------- | ------------------ | --------------------------- |
| Default       | Outbound / Inbound | Wait-for-finality transfers |
| Fast-finality | Outbound / Inbound | FTF transfers (optional)    |

Fast-finality buckets are optional. If one is not enabled, FTF transfers fall back to the default bucket for that direction. The pool owner uses `setAllowedFinalityConfig` to control whether the pool allows FTF on outbound transfers.

> **NOTE: v1.x pools**
>
> EVM v1 pools have **two limiters per remote chain**: one inbound and one outbound. There are no separate fast-finality
> buckets and no `setAllowedFinalityConfig`.

- Outbound limits apply to sends from the local chain.
- Inbound limits apply to receives on the local chain.

Outbound is configured on the source pool; inbound on the destination pool. Both sides of a lane must be configured for limits to behave as intended.

Because many chains finalize blocks in batches, several transfers can become executable at the same time, so destination inbound limits should be \~5–10% higher than source outbound limits (deployment tooling typically uses 10% headroom).

| State     | Config                                | Effect                                          |
| --------- | ------------------------------------- | ----------------------------------------------- |
| Active    | `isEnabled=true`, capacity > 0        | Transfers consume capacity and refill over time |
| Disabled  | `isEnabled=false`, capacity=0, rate=0 | No volume limit for that bucket                 |
| Throttled | `isEnabled=true`, capacity=0, rate=0  | All transfers blocked                           |

Rate limits are scoped per token pool, remote chain, bucket type, and direction. They do not pause CCIP globally.

> **NOTE: Config changes and bucket refill**

## Why rate limits exist

Rate limits are a defensive mechanism. They help:

- prevent large, single transfers from draining liquidity unexpectedly
- limit exposure during misconfiguration, incidents, or active investigations
- give operators time to react if abnormal activity is detected

## Who should manage rate limits

Interact with rate limits only if you:

- operate or administer a CCIP token pool (v2.0 or v1.x)
- hold the pool **owner** role or `rateLimitAdmin`
- understand token decimals on each chain you configure
- accept responsibility for the operational impact of changes

| Role               | Update limits | Add/remove lanes |
| ------------------ | ------------- | ---------------- |
| **Owner**          | Yes           | Yes              |
| **rateLimitAdmin** | Yes           | No               |

## Responsibility and risk

Managing rate limits directly affects the availability of cross-chain transfers for a token. Incorrect configuration can:

- unintentionally halt bridging
- allow more volume than intended
- create congestion or stuck transfers

Changes are applied onchain and take effect immediately. Always review parameters carefully, verify units, and use a multisig workflow where possible.

> **CAUTION: Disclaimer**
>
> Chainlink CCIP is an interoperability messaging protocol. Chainlink does not hold or transfer any assets. The
> performance and behaviour of applications using Chainlink CCIP may depend on coding, engineering, configuration, and
> other technical implementation choices made by developers, token issuers, Cross-Chain Verifiers, and other
> participants. Users remain responsible for evaluating, configuring, testing, deploying, operating, and maintaining
> their own applications and integrations, including assessing any applicable operational, security, technical, and
> legal or regulatory risks. Please review the [Chainlink Terms of Service](https://chain.link/terms) which provides
> important information and disclosures. By using Chainlink CCIP, you expressly acknowledge and agree to accept these
> terms. Cross-Chain Verifiers (CCVs) may be operated by third parties. The security, availability, governance, and
> operational profile of a CCV varies depending on the verifier selected. Users are solely responsible for evaluating
> any CCVs used in connection with their applications or integrations and determining whether they are appropriate for
> their intended use case. This code represents an example of using a Chainlink product or service. It is provided "AS
> IS" and "AS AVAILABLE" without warranties of any kind, has not been audited, and may omit checks or error handling.
> Each party intending to use this reference implementation must perform its own audits, security and code review, and
> testing before any production deployment and ensure the operation and performance of such code matches expectations.
> Neither Chainlink Labs, the Chainlink Foundation, nor Chainlink node operators are responsible for outcomes due to
> errors in this example or how it is deployed or operated. Use of the Chainlink Network is subject to the Chainlink
> Foundation Terms of Service, which provides important information and disclosures. By using this code, you acknowledge
> and agree to these terms.