Skip to main content
The rate limiting middleware moved from the standalone ibc-apps repository into ibc-go. Migrating is a code change across app.go. The import paths, the package name, the keeper constructor, and both middleware constructors all change. This guide moves an integration from ibc-apps v10 to ibc-go v11.2. For the full current wiring, see integrate the rate limiting middleware.

Update the imports

The module path changes, and the root package is renamed from ratelimit to ratelimiting.

Update the keeper

The keeper field becomes a pointer. The constructor drops the parameter subspace and the trailing ICS4 wrapper argument, adds an address codec, and moves the authority to the end. It returns a pointer, so drop the dereference.

Update the v1 wiring

The v1 middleware no longer takes the wrapped app as an argument. Build the stack with NewIBCStackBuilder, which injects the underlying app and sets the ICS4 wrapper, replacing the ICS4 argument the old keeper constructor took.
This example shows a minimal stack. If the chain already runs other transfer middleware, such as packet forward, keep those layers as additional .Next(...) calls; only the rate-limiting layer changes.

Update the v2 wiring

The v2 constructor gains two required arguments, a write-acknowledgement wrapper and the v2 channel keeper, and takes the keeper by value.

Update the app module

NewAppModule no longer takes the codec.

Add store upgrades

If rate limiting is being added to a chain for the first time, you must manually add store upgrades for the new module and configure the store loader to apply them in app.go:
This ensures the new module’s stores are added to the multistore before the migrations begin.

Verify the migration

After the app compiles, confirm the module is active by querying the existing limits.

Next steps