Skip to content
Financial Context Wiki

Multisig signer rotation

A verification-first procedure for replacing multisig signers while preserving quorum, checking the exact on-chain owner set and threshold, and responding safely to a compromised key.

Updated

For educational purposes only; not investment, legal, or security advice. A signer-rotation error can transfer control, invalidate pending approvals, or permanently lock a multisig account.

Direct answer

Multisig signer rotation changes the accounts authorized to approve transactions. It normally does not require a new wallet address or an asset transfer: the account’s owner set, and sometimes its approval threshold, changes through a privileged transaction. Implementations differ, so verify the deployed contract and current on-chain state instead of assuming that interface labels describe the authority correctly.

A safe rotation proves control of every new signer first, preserves an executable but non-concentrated quorum throughout the change, removes the old signer, and verifies the final state on-chain. Losing the required quorum before execution can make ordinary owner rotation impossible; lowering the threshold for convenience can create a takeover window.

The person, signing device, private key, and on-chain owner address are separate records. Document the exact address, custodian, independent control domain, backup status, and reason for rotation. No legitimate rotation requires anyone to reveal a seed phrase or private key.

How it works

  1. Inventory the current authority. From an independently verified chain and account address, read the deployed implementation, owner list, threshold, nonce, enabled modules, guards, fallback handler, recovery path, and any timelock. A module or recovery mechanism may execute outside the ordinary owner threshold, while a restrictive guard may block an otherwise valid rotation.
  2. Define the target state before signing. Record the exact owner set and threshold after the change. Confirm that the threshold does not exceed the owner count and that at least that many independent signers will remain operational. Geographic separation is not independence if one person, password vault, cloud account, or administrator controls every device.
  3. Enroll and authenticate the new signer. Generate or restore the new key in its intended custody environment, verify the address on a trusted device, and prove control through an agreed challenge or test signature. Confirm the address over a second authenticated channel; do not rely on copied chat text or a wallet interface alone.
  4. Choose an order with safe intermediate states. Some contracts can replace one owner atomically. Safe, for example, exposes swapOwner; it also exposes addOwnerWithThreshold, removeOwner, and changeThreshold. If an implementation needs multiple transactions, analyze the owner set and threshold after every step. Add and verify capacity before removing it unless an active compromise makes that ordering unsafe.
  5. Decode and simulate the exact transaction. Independently check chain ID, account address, target, function selector, old and new owner addresses, resulting threshold, nonce, value, and operation type. Treat delegatecall, batching, module changes, and guard changes as separate high-risk effects. Every signer should approve the same decoded payload and transaction hash.
  6. Execute with existing authority. The current valid quorum authorizes the rotation unless a documented recovery path says otherwise. For an emergency, coordinate only through authenticated contacts and use uncompromised signers. If neither the normal quorum nor a preconfigured recovery authority remains available, a standard owner-management call cannot restore access.
  7. Verify and close the change. After confirmation, query the owner set and threshold directly, inspect emitted events or traces as appropriate, and confirm that the old address is no longer authorized. Have the new signer participate in an approved low-risk or zero-value transaction requiring the intended threshold. Review pending transactions, revoke off-chain access and backups belonging to the former signer, and archive the proposal, signatures, transaction hash, block, and final state.

Worked example

Assume a 3-of-5 account has owners A, B, C, D, and E, and B must be replaced by F. The team first verifies that F controls the exact proposed address and remains independent of the other owners. For a compatible Safe deployment, it prepares swapOwner(prevOwner, B, F). The call is itself a Safe transaction and therefore needs 3 valid confirmations from the current owner set. Its decoded result should preserve an owner count of 5 and a threshold of 3.

After the transaction confirms, the team reads getOwners and getThreshold, verifies that B is absent and F is present, and has F plus two other owners execute an approved 0-value test. It also reviews pending transactions: a signature or preapproval from B may no longer satisfy owner checks after removal, so affected proposals must be cancelled or rebuilt rather than assumed executable.

If B may be compromised, the team does not ask it to approve the removal. Three other uncompromised owners execute the replacement, then inspect modules, recovery permissions, allowances, session keys, and already executed transactions because removing B does not reverse earlier actions or revoke authority granted through another path. If fewer than 3 uncompromised owners are available, only a previously configured recovery or administrative path may help; sharing seed phrases or trusting an unsolicited “recovery” service is not a substitute for quorum.

Risks and controls

  • Wrong account or address. Verify the chain ID, multisig address, implementation, and new owner address on independent devices and sources. Address poisoning and copy errors can grant control to an attacker.
  • Quorum loss. Model every intermediate state. Removing an owner too early, raising the threshold beyond available signers, or rotating several correlated devices together can make the account unusable.
  • Temporary concentration. A lower threshold or newly added signer can create a period in which fewer parties control the account. Prefer an atomic replacement when supported and do not lower the threshold merely to simplify the ceremony.
  • Correlated custody. Different addresses are not independent when their seeds, devices, backups, communications, or administrators share one failure domain. Test recovery without centralizing secrets.
  • Hidden authority. Modules, guards, fallback handlers, session keys, timelocks, and recovery contracts can bypass or block the owner path. Inventory and verify them before and after rotation.
  • Compromised-signer race. A suspected signer may front-run, drain assets, change configuration, or approve another transaction before removal confirms. Use incident procedures, private transaction delivery where appropriate, and continuous state monitoring; do not assume a submitted transaction has won the race.
  • Stale pending approvals. Owner and threshold changes can invalidate collected signatures or alter which approvals are sufficient. Re-evaluate every queued transaction against the final state and cancel obsolete proposals.
  • False completion. A successful interface notification does not prove the intended state. Wait for the required confirmation policy, then read contract state and verify the transaction payload, events, and execution result.
  • Incomplete offboarding. Removing an on-chain owner does not erase copied keys, organizational access, relayer credentials, password-vault entries, or authority in other contracts and chains. Revoke each separately and retain an audit trail.

Common misconceptions

  • “Rotation means moving all assets to a new wallet.” Many smart-account multisigs update owners at the same account address. Migration is a different operation and may be required only by a particular implementation or incident plan.
  • “Adding the new signer first is always safe.” It protects availability, but it can temporarily increase the authorized set. During an active compromise, an atomic swap or a different emergency sequence may be safer.
  • “A 3-of-5 threshold means any three named people are available.” The contract counts valid owner accounts, not people, departments, or devices. Shared custody and inaccessible keys reduce effective independence and availability.
  • “Removing a compromised owner undoes the damage.” Removal prevents future use of that owner path after confirmation; it does not reverse executed transactions or revoke permissions created elsewhere.
  • “The wallet interface is enough evidence.” Interfaces and indexing services can be stale, misconfigured, or malicious. Decode the transaction and read final contract state from an independently verified endpoint.
  • “No quorum means support can reset the wallet.” A self-custodial multisig has only the authority paths encoded or previously configured on-chain. Without a valid quorum or recovery path, access may be permanently lost.

Sources

Navigation

Search the wiki...