Skip to main content
This guide demonstrates access manager role changes by restricting relaying, rotating a relayer key, and transferring admin authority.

​
Before you begin

Complete Deploy IBC and send a token. Keep the tutorial’s relayer running. Both connection ends must use the tutorial’s relayer key alias to sign transactions. Run commands from cli, using the tutorial’s home and configuration. Install Foundry for the cast commands. The tutorial deploys one access manager on 41001 and another on 41002. The deployer key administers both. This guide uses RELAYER_ROLE and ADMIN_ROLE; see Permissions and upgrades for the other available roles.

​
Restrict relaying

​
1. Grant the relayer role

Read the values again if you opened a fresh terminal:
The last command reads the admin’s raw private key. Role 1 is RELAYER_ROLE. Use zero execution delay because the relayer cannot schedule delayed calls. The relayer calls IBCMulticall, which calls the router. The access manager checks the relayer’s signing address for multicall calls. It checks the multicall contract’s address for the resulting router calls. Grant the role to the current key and multicall contract on each chain:
Verify the grants before restricting relaying:
Every query must return true, then 0. Continue only after all checks pass, so relaying stays authorized.

​
2. Require the role for relaying

Compute the selectors that identify the four router functions and multicall:
Restrict multicall first, so unauthorized keys cannot use it to relay:
Then change the router functions’ required role from PUBLIC_ROLE to 1:
Check the router assignments:
Each loop must print four 1 values. Check both multicall assignments:
Both queries must return 1. Stop if any assignment returns another role. For permissioning only, run unset DEPLOYER_KEY and stop here. Continue below to replace the relayer key.

​
Rotate relayer keys

​
1. Authorize the replacement key

Create the replacement signer and read its address:
Fund it on both chains for transaction fees:
Check that each funding transaction succeeds. Grant the replacement key role 1 with zero execution delay:
Verify both grants:
Both queries must return true, then 0.

​
2. Switch to the replacement key

Update both connection ends in ~/.ibc/ibc.yml. If you customized the attestors, edit only the connection’s two signer fields to relayer-next and skip the command below. Otherwise, run:
The --yes flag skips confirmation. The command preserves the database settings. It renders attestors from deployment records. Validate before stopping the running relayer:
In its terminal, press Ctrl-C and wait for exit. Restart with the same home, configuration, and database:
Wait for the Readiness log.

​
Verify a transfer

Back in your working terminal, read the token address:
Send a transfer to test the selected signer on both chains:
Poll for PACKET_STATE_SUCCEEDED:

​
3. Revoke the old key’s role

Revoke role 1 from the old key on both chains.
Check the old membership:
Both queries must return false, then 0. Check the replacement’s permission:
Both queries must return true, then 0. Repeat the transfer checks after revocation. Then clear the admin key:

​
Transfer admin authority

Role 0 is ADMIN_ROLE. Multiple addresses can hold it. Grant it to the replacement before revoking the deployer’s admin role, so an admin remains available. Create a replacement admin key for this local example:
Fund the replacement on both chains:
Grant admin authority with zero execution delay:
Use the replacement key to revoke the deployer’s admin role:
Successful transactions establish that the replacement can administer both access managers. Check the old admin’s membership:
Both queries must return false, then 0.