Smart-contract wallets: programmable custody, explained

A smart-contract wallet is an account whose rules live in code rather than in a single private key. Because the contract decides what counts as a valid instruction, it can support features an ordinary account cannot: social recovery, daily spending limits, batched transactions, session permissions, and fees paid by someone else or in a token that is not the network's own. The trade-off is that your custody now depends on a contract, and contracts have bugs.

How does an ordinary account work?

In the standard model, an account is nothing but a key pair. The address is derived from the public key, and a transaction is valid if it carries a signature from the matching private key. There is no logic, no configuration and no recovery: the key is the account. That simplicity is robust — there is very little to go wrong — and it is also why one lost key ends everything. That is the model assumed throughout our self-custody explainer.

What does the contract model change?

If the account is a contract, validity becomes a question the contract answers. It might require two signatures, or one signature plus a limit check, or a signature from a temporary key that expires tomorrow. Wallet features that previously required trusting a company can be expressed as rules the network enforces.

• Recovery: a set of guardians — other devices, friends, or a service — can rotate the signing key if you lose it, usually after a delay you can cancel.
• Limits: daily caps, allowlisted destinations, or larger amounts requiring a second approval.
• Batching: several actions in one atomic transaction, so an approval and a swap either both happen or neither does.
• Session keys: a limited key for a specific app or period, so a game or trading interface does not need your main signer.
• Sponsorship: a paymaster pays the network fee, letting a new user transact without first buying the native token.

What are the real trade-offs?

The features are genuine, and so are the costs. Be clear-eyed about both before moving significant value. Deployment and execution both cost gas, so our guide to how gas fees work is worth reading alongside this one.

Contract risk is the one to weigh most carefully. A widely used, heavily audited wallet contract that has held large balances for years is a different proposition from a new implementation with a novel feature set. Audits reduce risk; they do not eliminate it.

Who should use one?

Teams managing shared funds get the most obvious benefit: thresholds, roles and spending policies replace informal trust. Users who want a recovery path without a custodian are the second group — losing a phone stops being catastrophic. Newcomers benefit indirectly, because sponsored fees remove the awkward requirement to acquire a native token before doing anything.

If you hold a modest amount, transact rarely and have your seed phrase properly backed up, an ordinary account plus a hardware wallet remains a perfectly sound answer. The contract model buys flexibility, and flexibility is only worth paying for when you need it.

How does recovery actually work?

Recovery is the feature most people adopt these wallets for, so it is worth understanding the mechanics rather than the marketing. You nominate a set of guardians — other devices you own, people you trust, or a service — and define how many must agree to rotate the signing key. If you lose your phone, the guardians approve a change, a delay period begins, and at the end of it the new key controls the wallet.

The delay is the important part: it gives the original key a window to cancel a recovery it did not request, which is what stops guardians from quietly taking over. The design questions to ask are how many guardians are required, how long the delay is, whether you can veto during it, and whether the guardian set can be changed without their cooperation.

What should you check before choosing one?

• How long the contract has been live and how much value it has held without incident.
• Who audited it, when, and whether the audited version is the deployed one.
• Whether the contract is upgradeable, and if so, who can trigger an upgrade.
• Whether you can exit to an ordinary account if the project stops being maintained.
• Which chains it is deployed on, and whether your address is identical across them.