~/notes / node operation
Account Abstraction: What Changes When a Wallet Is a Contract
Smart contract accounts allow recovery, spending limits and gas paid in other tokens. The trade-offs are worth understanding before switching.
Most wallets are externally owned accounts: a private key, and transactions signed by it. A smart contract account replaces that with programmable logic.
What becomes possible
Social recovery. Designated parties can collectively authorise a new key if you lose access. No single seed phrase whose loss is terminal.
Spending limits. Rules enforced by the account itself: maximum per transaction, per day, or per destination.
Batched operations. Multiple actions in a single transaction, including an approval and the operation it enables.
Gas paid by someone else, or in another token. A paymaster arrangement covers the fee and is reimbursed.
Session keys. Limited authority granted to an application for a period, without granting full control.
Multiple signers with rules. Thresholds, roles, and time-based conditions.
What it costs
Higher gas. A contract account executes code for every operation. Deployment costs and per-transaction costs are both higher than for a plain account.
Smart contract risk. Your account is now code, and code can have bugs. A flaw in the account implementation is a flaw in your wallet.
Complexity. More configuration, more ways to get it wrong.
Portability. A contract account exists on a specific chain. The same address does not automatically work everywhere.
Dependency. Some designs rely on infrastructure that bundles and relays operations. Where that infrastructure is limited, you depend on it.
The recovery trade
Social recovery removes the single catastrophic failure mode of self-custody and introduces a new one: guardians who become unreachable, or who collude.
Guardian sets need maintenance as relationships change. A set assembled today and never reviewed is a recovery method that quietly stops working.
Whether this is an improvement depends on which failure you consider more likely for yourself, and most people have never assessed that honestly.
Where it is genuinely better
For users who would otherwise lose access. The seed phrase failure mode is the largest cause of permanent loss, and this addresses it directly.
For spending accounts with limits, where the rules bound the damage from a compromise.
For organisations, where threshold signing and roles map to how decisions are actually made.
Where a plain account remains simpler
Long-term holdings moved rarely, held on a hardware wallet, with a tested paper backup. There is less to go wrong and the failure modes are well understood.
The practical position
Both models are reasonable and they suit different tiers. A contract account with limits for daily use, a hardware wallet for long-term holdings, and a working balance at exchanges that let you specify the network where recovery is a support process rather than a cryptographic one.
Three tiers with three different recovery models is more robust than one model applied everywhere.
# Corrections and technical nitpicks are welcome. Send them over. They get published with the fix.