KeyChanged

Event v101 → v150, v151 → current #1

Emitted when the sudo key is changed to a new account.

Useful for: validatorsdevelopersanalyticsstakers

The Big Picture

KeyChanged is a significant governance event - it means administrative control of the network has moved to a new entity. This could be routine key rotation, transition to a multisig, or preparation for decentralization. Anyone invested in the network should pay attention to these events.

Why This Matters

The sudo key is the most powerful account on the network. Knowing when it changes - and to whom - is critical for trust. A KeyChanged event should match a governance decision; unexpected changes are a red flag.

Example Scenario

Network governance votes to transfer sudo from single-signer to a 3-of-5 multisig. The current sudo key calls set_key(new=multisig_address). KeyChanged fires showing old=single_signer_address, new=multisig_address. Control has transferred.

Common Questions

Should I be worried about KeyChanged events?: Only if unexpected. Legitimate key changes should be announced through governance beforehand. Unexpected changes warrant investigation.
Can the old key reclaim sudo?: Only if the new key cooperates. Once changed, only the new key can call set_key. The old key has no special recovery rights.

Use Cases

Track governance transitions
Monitor administrative control changes
Alert on sudo key rotation for security awareness
Audit control transfers for compliance

How to Use This Event

→ Alert immediately on KeyChanged events
→ Track history of sudo key changes
→ Verify new key is expected (governance proposal)

From Chain Metadata

The sudo key has been updated.

Migration Notes

v150 v151 Breaking

removed field old_sudoer (was Option); added field old (Option); added field new (AccountId)

Update decoders: SCALE encoding is positional, so any signature change (added, removed, or type-changed fields, or storage shape changes) shifts byte offsets and existing decoders will misparse this item. Re-derive types from the new metadata.

Triggers

Emitted by

set_key

Preconditions

Previous sudo key executed set_key
New key is a valid account

Effects

Storage Modified

Key

Postconditions

Sudo.Key storage updated to new account
Old key no longer has sudo access

Side Effects

Administrative control transferred immediately
Old key's pending sudo calls may fail

Event Data

#	Name	Type	Description
0	old → old_key	Option Option<T::AccountId>	Previous sudo key (None if sudo was just enabled)
1	new → new_key	AccountId	New sudo key account address (hex -> SS58)

Code Examples

import { createClient, Binary } from "polkadot-api";
import { getWsProvider } from "polkadot-api/ws";
import { sub } from "@polkadot-api/descriptors"; // generated by: npx papi add sub -w wss://entrypoint-finney.opentensor.ai:443

const client = createClient(getWsProvider("wss://entrypoint-finney.opentensor.ai:443"));
const api = client.getTypedApi(sub);

// Subscribe to KeyChanged events
client.finalizedBlock$.subscribe(async (block) => {
  const events = await api.event.Sudo.KeyChanged.get(block.hash);
  for (const evt of events) {
    console.log("KeyChanged:", evt.payload);
  }
});

Version History

Version:

v101 block 1 1 args

v151 block 3,157,274 2 args Current

Runtime Info

Pallet Index: 12
Event Index: 1
First Version: v101
Current Version: v411

Back to Sudo Events