Rate Limits

This section explains how operators, token issuers, and administrators manage rate limits on CCIP TokenPool v2.0 contracts (and v1.x pools, with differences noted inline). Rate limits are operator-level controls that bound the volume of tokens that can move across a specific CCIP lane over time, reducing blast radius during incidents and helping manage operational risk.

Changes are applied on-chain, take effect immediately, and directly affect transfer availability. Most integrators do not need to interact with rate limits.

Pages

Overview

How CCIP rate limits work as capacity buckets, why they exist, who should manage them, and the responsibility boundary.

Prerequisites and Permissions

Required roles (owner or rateLimitAdmin), how admin access is granted on v2.0 and v1.x pools, and the scope of admin authority.

Inspect Current Rate Limits

Read-only inspection of inbound and outbound rate limiter state, including the TokenBucket struct and fast-finality buckets.

Token Units and Decimals

How to convert human-readable token amounts into on-chain base units, with worked examples for 18-decimal and 6-decimal tokens.

Update Rate Limits

The setRateLimitConfig (v2.0) and setChainRateLimiterConfig (v1.x) functions, inbound/outbound guidance, and fast-finality bucket updates.

Emergency Actions

Incident-response lockdown patterns: throttle to zero, minimal non-zero values, owner-only lane removal, and restoring normal operation.

Common Scenarios

Worked configuration examples for 18-decimal and 6-decimal tokens, fast-finality buckets, batch updates, pausing a lane, and removing rate limits.

Executing with a Multisig

How to build and submit rate limit update transactions from a multisig wallet, including ABIs for transaction builders.

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.