Emergency Actions (Incident Response Only)

This page describes emergency actions that can be taken to contain or halt cross-chain transfers on a specific CCIP lane using rate limit configuration.

These actions are intended for incident response, maintenance, or risk containment scenarios. They should not be used for routine configuration.

When to use emergency actions

You may need to take emergency action if:

abnormal or unexpected transfer activity is detected
a misconfiguration or incident is under investigation
maintenance requires temporarily stopping transfers on a lane

Emergency actions are scoped to a specific token pool and lane. They do not pause CCIP globally.

Locking down a lane with minimal values

To stop bridging activity on a lane, configure rate limits with the smallest values your deployed pool version accepts.

Confirm your deployed TokenPool version

Rate limit validation changed between TokenPool releases. Call typeAndVersion() on each deployed pool before you apply any configuration described on this page.

Pools reporting 1.6.1 or later (including development stamps such as 1.6.x-dev) — an enabled bucket is rejected only when rate > capacity, so an enabled capacity: 0, rate: 0 is accepted and pauses the lane.
Pools reporting versions before 1.6.1 — an enabled bucket is rejected when rate >= capacity or when rate == 0. A configuration of capacity: 1, rate: 1 reverts. Use at least capacity: 2, rate: 1 on these releases. (Version strings here are 1.5.1 or lower — a pool built from the 1.6.0 contracts release reports 1.5.1.)
All releases from 1.4.0 onward — a disabled bucket must have capacity: 0 and rate: 0, otherwise the call reverts.

Pools reporting 1.6.1 or later: pause the lane

Pause the lane by keeping the rate limit enabled and setting both values to zero on the affected direction via setChainRateLimiterConfig (or setChainRateLimiterConfigs for several lanes at once):

outboundConfig = [true, 0, 0];
inboundConfig  = [true, 0, 0];

This blocks all transfers in that direction — an inbound pause intentionally holds in-flight transfers — until you restore normal values.

Pools reporting versions before 1.6.1: use minimal values

A full stop through rate limits is not possible on these pools: an enabled bucket is rejected when rate >= capacity or when rate == 0. Use the smallest accepted configuration, capacity: 2, rate: 1:

outboundConfig = [true, 2, 1];
inboundConfig  = [true, 2, 1];

This allows only a negligible trickle before the bucket is depleted, causing subsequent transfers to fail. The trickle that remains possible can be material for tokens with few decimals.

In both cases, apply the configuration to both inbound and outbound limits so transfers are blocked in both directions.

Important considerations

When locking down a lane:

on pools reporting versions before 1.6.1, transfers may still succeed for a minimal amount, and behavior depends on the token's smallest unit
the change takes effect immediately after the transaction is confirmed

This approach is intended to contain activity, not to permanently disable rate limits.

Restoring normal operation

To resume normal transfers, update the inbound and outbound rate limit configuration with appropriate capacity and refill values.

Always revalidate token units and existing configuration before restoring service.

What this page does not cover

This page does not cover:

routine rate limit tuning
worked examples for different token decimals
fully removing rate limits

Those topics are covered in the common scenarios section.