Rate Limits - Overview

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 on-chain, take effect immediately, and directly affect transfer availability.

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 tokens before the bucket is depleted
rate — refill speed in tokens per second

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

Rate limit bucket

Available now

100,000 tokens

Full

Rate limit settings

Max capacity 100,000 tokens

Largest possible single transfer.

Refill rate 1,000 tokens/s

Tokens added back every second.

Transfer

Transfer amount 30,000 tokens

Fits in the bucket right now.

Try a transfer

Set an amount and send it. Used capacity refills every second, up to the max capacity.

Contract error:

Illustrative values in whole tokens. On-chain, rate limits are set in the token's smallest unit.

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	Fast-finality transfers (optional)

Fast-finality buckets are optional. If one is not enabled, fast-finality traffic falls back to the default bucket. Whether fast-finality is permitted at all is controlled by the pool owner via 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 CCIP commits messages in batches and chains finalize in epochs, 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.

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 on-chain and take effect immediately. Always review parameters carefully, verify units, and use a multisig workflow where possible.

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