Smart-account owner and recovery risk

Audit who can control a smart account, how recovery changes the owner, which delays and cancellation rights apply, and whether modules or upgrades create hidden takeover paths.

For educational purposes only; not investment, legal, or security advice. A recovery or configuration error can transfer control of a smart account or permanently lock it.

Direct answer

A smart account is controlled by the authorization logic deployed for that account, not necessarily by one private key. An owner or validator may approve ordinary operations, while a guardian, recovery module, executor, or upgrade administrator may have a separate path that can replace the owner or execute transactions.

Recovery reduces the chance that one lost key makes the account unusable, but it adds another takeover surface. Audit every path that can authorize execution, change validators or owners, install modules, upgrade code, or cancel and finalize recovery. Interface labels such as “owner” and “guardian” are not proof of the contract’s actual authority.

Record the result as a permission table: exact on-chain address, role, callable action, threshold, delay, cancellation authority, expiry, spending scope, upgrade authority, and independent control domain. Recheck the table after every configuration change and on every chain where the account exists.

How it works

Identify the account and code. Verify the chain ID and account address, then determine the implementation, proxy or beacon, factory and version. For an ERC-1967 proxy, read the implementation, beacon and admin slots instead of trusting an interface badge.
Enumerate authorization paths. Read owners and thresholds, ERC-4337 validators, ERC-7579 validators, executors, hooks and fallback handlers, Safe-style modules and guards, session keys, recovery contracts, and any emergency or upgrade administrator. An executor or Safe module may execute without the normal owner threshold.
Decode the recovery state machine. Establish who can nominate a replacement owner, how guardian approval is counted, whether approvals expire, when the delay starts, who can cancel, who can finalize, and what happens when a recovery is replaced or repeated. Do not assume all “social recovery” contracts use the same sequence.
Test independence and availability. Different addresses are not independent if one device, person, cloud account, password vault, custodian, or administrator controls them. Confirm that the threshold can still be met after one expected failure without giving one control domain enough power to take over.
Review configuration authority. Determine who can add or remove a guardian, validator, executor, hook, module, or fallback handler; change the threshold or delay; pause cancellation; or upgrade the account and recovery code. A timelock is useful only if its delay and cancellation path cannot be bypassed by another role.
Monitor and verify. Subscribe to or independently poll recovery, owner, module, threshold, implementation and admin changes. After any operation, decode the transaction and verify receipts, events, storage and the final owner set on the correct chain; a successful interface notification is insufficient.

Worked example

Assume an account has owner O and three guardians G1, G2 and G3. Any 2-of-3 guardians can propose new owner N; a 24-hour delay then begins; O can cancel during the delay; and anyone can finalize after it expires. The recovery module can call the account’s owner-change function without O approving that final transaction.

The labels suggest distributed recovery, but G1 and G2 are applications backed up to the same cloud account. Compromise of that cloud credential gives one attacker the effective 2-of-3 threshold. The attacker proposes N; if monitoring or cancellation fails for 24 hours, finalization transfers control even though O’s private key was never stolen.

The audit therefore marks G1 and G2 as one control domain, verifies the recovery module address and code, tests cancellation from an uncompromised device, confirms what event starts the delay, and checks whether an upgrade administrator can replace the module immediately. It does not perform a live recovery on the asset-holding account unless the implementation provides a documented, safely reversible test process.

Risks and controls

Correlated guardians: use genuinely independent devices, credentials, people or custodians; test contact and recovery procedures without pooling seed phrases.
Overpowered module or executor: inspect installed code and exact callable scope. Remove unused modules through the documented path and verify removal on-chain.
Weak threshold: assess both takeover resistance and availability. A higher nominal threshold does not help when signers share one control domain, and an unreachable threshold can lock the account.
Missing or bypassable delay: verify the delay on-chain, the event that starts it, who can shorten it, and every path that can change the owner immediately.
Ineffective cancellation: rehearse detection and cancellation, maintain native gas and an independent submission route where required, and verify whether cancellation itself needs the old owner, a quorum, or another role.
Upgrade takeover: monitor implementation, beacon and admin changes. Treat an administrator able to upgrade without delay as capable of changing every documented recovery rule.
Malicious or stale interface: independently verify chain, account, module, proposed owner, threshold, delay and transaction calldata. Never reveal a seed phrase or private key to a “recovery” service.
False completion: after cancellation or finalization, confirm the receipt and final storage state. Check that the intended owner and modules are active and the unwanted proposal cannot still be executed.

If an unauthorized recovery appears, stop signing unrelated requests and preserve the proposal ID, transaction hash, calldata, block, module address and current state. From an uncompromised device, verify the alert through an independent RPC, use the contract’s documented cancellation path if still available, and monitor for finalization, upgrades, module changes and asset transfers. If control may already be lost, follow a prewritten incident plan and use only authenticated project or custody contacts; an improvised transfer can be front-run or can expose the destination.

Common misconceptions

“The owner is the only account that can move assets.” Validators, executors, modules, recovery contracts or upgraded code may provide additional execution paths.
“Three guardians means three independent parties.” The contract counts valid approvals from addresses; it does not detect shared devices, backups or administrators.
“A 24-hour delay guarantees time to react.” Monitoring, a usable cancellation authority, gas and transaction inclusion are all required, and another privileged path may bypass the delay.
“Removing a guardian ends its access.” Confirm final on-chain configuration and check other roles, modules, session keys and pending recoveries tied to that party.
“Support can restore any smart account.” Only authority encoded or previously configured on-chain can change a self-custodial account. Without a valid owner or recovery path, loss of access may be permanent.