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

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

> **NOTE: CCIP 2.0**
>
> This page covers read-only inspection of token pool contracts. Differences for v1.x pools are noted inline.

Before updating any rate limit configuration, inspect the current inbound and outbound settings for the token pool and lane you are managing.

On v2.0 pools, also inspect the **fast-finality bucket** if FTF transfers are in use on the lane.

## What you can inspect

Each token pool exposes read-only functions that return rate limiter state for a given remote chain. These values describe:

- whether the inbound or outbound rate limit is enabled
- the configured capacity and refill rate
- the current tokens available in the bucket (with time-based refill applied)
- the refill timestamp, which the getters set to the time of your call

You can also read the current rate limit admin:

| Pool Version | Function                                                            |
| ------------ | ------------------------------------------------------------------- |
| v2.0         | `getDynamicConfig()` → returns `(router, rateLimitAdmin, feeAdmin)` |
| v1.x         | `getRateLimitAdmin()` → returns `rateLimitAdmin`                    |

## Identify the token pool contract

To inspect rate limits, you first need the token pool contract address for the token you are managing.

You can find token pool addresses using:

- the Token Manager
- `TokenAdminRegistry` lookups for your token
- the CCIP Directory

## Select the remote chain

Rate limits are configured per remote chain. When querying a rate limiter, you must provide the remote chain selector that identifies the cross-chain lane you want to inspect.

Chain selectors are `uint64` values. You can find the correct selector for each supported network in the [CCIP Directory](https://docs.chain.link/ccip/directory).

## Query rate limiter state

### v2.0

One function returns the outbound and inbound state for a bucket type:

```solidity
function getCurrentRateLimiterState(
  uint64 remoteChainSelector,
  bool fastFinality
) external view returns (
  RateLimiter.TokenBucket memory outboundRateLimiterState,
  RateLimiter.TokenBucket memory inboundRateLimiterState
);
```

| `fastFinality` | Returns                                          |
| -------------- | ------------------------------------------------ |
| `false`        | Default (wait-for-finality) outbound and inbound |
| `true`         | Fast-finality outbound and inbound               |

Call it twice per remote chain, with `fastFinality = false` and `fastFinality = true`, to inspect both bucket pairs.

### v1.x pools

v1.x pools expose separate getters for each direction:

```solidity
function getCurrentOutboundRateLimiterState(
  uint64 remoteChainSelector
) external view returns (RateLimiter.TokenBucket memory);

function getCurrentInboundRateLimiterState(
  uint64 remoteChainSelector
) external view returns (RateLimiter.TokenBucket memory);
```

There is no `fastFinality` parameter. One inbound and one outbound query per remote chain is sufficient.

You can call these functions via a block explorer, web3 client, or deployment state tooling.

## Interpreting the TokenBucket state

The v2.0 and v1.x getters both return `RateLimiter.TokenBucket` structs with these fields:

```solidity
struct TokenBucket {
  uint128 tokens;
  uint32 lastUpdated;
  bool isEnabled;
  uint128 capacity;
  uint128 rate;
}
```

Where:

- **tokens** (`uint128`): the current number of tokens available in the bucket (after time-based refill)
- **lastUpdated** (`uint32`): the timestamp of the last refill, in seconds (the getters apply the refill at call time, so they return the current block timestamp)
- **isEnabled** (`bool`): whether the rate limit is active
- **capacity** (`uint128`): the maximum bucket size
- **rate** (`uint128`): the refill rate in tokens per second

`tokens`, `capacity`, and `rate` are in the token's **local smallest unit** on the chain where the pool is deployed, not in whole tokens.

### Reading disabled or unconfigured fast-finality buckets

> **NOTE: v2.0 pools only**
>
> A fast-finality bucket with `isEnabled = false` doesn't enforce limits, so FTF transfers in that direction fall back
> to the default bucket.

## Inbound vs outbound inspection

- **Outbound** (source chain pool): transfers leaving the current chain
- **Inbound** (destination chain pool): transfers entering the current chain

For a complete lane picture, inspect outbound on the source and inbound on the destination.

> **NOTE: v2.0 pools only**
>
> Also inspect the fast-finality buckets on both chains if FTF transfers are in use.

## Before proceeding

- record existing values for all relevant buckets
- confirm token decimals on each chain
- identify which direction, lane, and bucket type you intend to modify
- verify your wallet is the pool owner or its `rateLimitAdmin`

Only proceed to updates once you fully understand the current state. Next, review [token units and decimals](/ccip/evm/concepts/cross-chain-token/rate-limits/token-units-and-decimals) before submitting any update transaction.

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