If you gave an account permission on several blockchains, revoke it through a process that updates every chain and rejects old permission messages. A scheduled delay gives people time to review the change, while a version number on each permission stops a delayed grant from restoring access after revocation.
What does cross-chain role revocation mean?
A role is a named permission, such as the right to mint tokens or pause a contract. In common smart-contract libraries, an administrator can grant or revoke a role, and a contract checks whether an account has it before allowing a restricted action. Each blockchain keeps its own contract state, so revoking a role on one chain does not automatically remove it on another.
An omnichain application coordinates state across networks with messages, but each destination still has to receive and apply the permission change. For example, if an account can mint on three chains, the application needs to revoke that account’s minter role on all three before treating the change as complete.
omnichain.network is a service for carrying out this kind of cross-chain task. In general, the process starts with an authorized change, sends instructions to the destination chains, and checks that each destination has applied them.
What does the delay protect, and what does it cost?
A revocation delay is a set waiting period before a planned permission change takes effect. It gives administrators time to notice a mistaken request or challenge an unauthorized one. The account keeps its permission during that period, so a delay also gives a compromised account more time to act.
For an illustrative setup, suppose a 48-hour delay is configured. After an administrator schedules revocation, the role remains active for those 48 hours; then each destination must process the cross-chain instruction before its local contract denies the role. The 48 hours are a governance choice, not a guarantee that all networks update at the same moment.
There are also execution costs: the source-chain transaction uses gas, each destination needs gas to run its receiver contract, and the messaging system may charge a fee. The total depends on the chains, message service, and contract work. A change sent to three destinations generally requires destination execution on all three, so budget for separate destination costs as well as the source transaction.
How does a revocation reach each chain?
The end-to-end flow is: schedule the change, wait for the configured delay, send a message, verify it, execute it at each destination, and confirm the local role state. A cross-chain messaging system such as Chainlink CCIP, Wormhole, or Axelar carries the instruction; the destination contract must be configured to trust the expected sender and message path.
In a robust design, the source message names the account, role, destination, and a new version number. For example, if Maya’s minter permission is at version 7, the revocation carries version 8. Each destination records the highest version it has applied and rejects any permission update with a lower or equal version. That rule prevents an old, delayed grant from undoing the newer revocation.
Suppose the version 8 revocation reaches Chain A but is still pending on Chain B. Maya is now blocked on A but may still mint on B. The administrator should track completion per destination, rather than relying only on the source transaction’s success. The source transaction means the instruction was sent; it does not prove every destination executed it.
What should you check before relying on the change?
Check the role’s administrator, the delay setting, the trusted message sender on each destination, and whether destination contracts reject stale versions. Also establish what happens if a message is delayed or fails: an operator may need to retry execution, and a destination should expose enough state to confirm its current role and version.
One edge case deserves special care: if an account may be compromised, the scheduled delay leaves it authorized while the clock runs. A system can add an immediate local pause or emergency deny rule, but that protection must be implemented on each affected chain; a source-chain emergency action alone cannot instantly change remote state.
Before you finish, check:
- The intended account and role are correct.
- The delay and effective time are understood.
- Every destination has applied a newer revocation version.
- No destination still reports the role as active.
Top comments (0)