Skip to main content
Replace the tutorial’s attestor for chain 41002 by migrating to a replacement client.

​
Before you begin

Complete Deploy IBC and send a token. Keep its relayer running, including the local attestor for 41002. Run every command from the cli directory of your IBC clone. You need Foundry, Bun, and the tutorial’s deployer admin key. This guide replaces only the client on 41001 that verifies chain 41002. The replacement client accepts only the replacement attestor, with a threshold of one signature.

​
1. Create the replacement attestor key

Read the tutorial’s values in your working terminal:
Create a distinct replacement key:

​
2. Deploy the replacement client

Clone the contracts and check out the commit pinned by the target CLI version:
Read chain 41002’s latest block height:
Read chain 41002’s block timestamp at HEIGHT:
Deploy a client that accepts only the replacement attestor:
The constructor binds the client to ROUTER_A, the only caller it accepts.

​
3. Migrate to the replacement client

The router’s migrateClient function replaces the contract address registered under an existing client ID. It also overwrites the counterparty information, so reuse COUNTERPARTY from step 1. Migration does not copy the old client’s stored timestamps. Stop the relayer with Ctrl-C in its terminal. Wait for it to exit. Submit the migration:

​
4. Switch the relayer to the replacement attestor

In ~/.ibc/ibc.yml, replace the attestors section with:
Validate the configuration against the migrated client:
Restart the relayer in its terminal:

​
5. Verify the rotation

In your working terminal, read the active client’s address:
Check its attestor set:
The set must contain only NEW_ATTESTOR, with threshold 1. Send one token from 41002 to 41001:
Poll for PACKET_STATE_SUCCEEDED:

​
Additional considerations

​
Minimize downtime

To minimize downtime, first migrate to an intermediate attestation light client that accepts both old and new attestors with a threshold of one signature. This preserves compatibility with the old and new attestor while you update the relayer configuration and restart it with the new attestor. Verify a transfer. Then migrate to the client that accepts only the replacement. For larger sets, keep enough eligible signers to meet each active threshold.

​
Manifest drift

The CLI does not currently have first-class support for attestor set migration. This guide migrates the client directly on chain, leaving the manifest with the original client address and attestor set. As a result, ibc deploy status reports a client-address mismatch. Rerunning ibc deploy client attestation does not refresh the recorded set. The ibc deploy render-config command still derives attestors from those stale records.