Smart Contract Wallets: A Wallet That Is a Program

An ordinary wallet is a keypair, and everything about how it behaves is fixed by the protocol. Whoever holds the private key can do anything the account can do, immediately, with no limits and no recourse if the key is lost or stolen.

A smart contract wallet replaces that with a program. The program holds the funds and decides what it will accept, which means the rules can be whatever the contract says.

What Becomes Possible

Recovery without a phrase. A set of guardians, chosen in advance, can together authorise replacing the signing key. Losing a device stops being terminal.

Spending limits. The contract can permit small transfers on one signature and require more for larger ones, or impose a delay above a threshold. A stolen key then has bounded reach.

Multiple signers. Requiring several approvals for some or all actions, in the same spirit as multisig but with rules per action rather than one global threshold.

Batching. Several operations authorised together in one step, so an approval and the action that uses it happen atomically rather than as two separate confirmations.

Delegated fee payment. Someone other than the wallet owner can pay the transaction fee, which removes the awkwardness of needing the native asset before anything can be done.

Session permissions. Narrow, time-limited authority granted to an application, rather than the all-or-nothing signature an ordinary account gives.

What It Costs

The last two rows deserve weight.

A keypair account’s behaviour is defined by the protocol, which is examined by everyone. A contract wallet’s behaviour is defined by its own code, and a defect in that code is a defect in your wallet. Choosing one is choosing to trust a specific implementation.

Application support is better than it was and still inconsistent. Signature verification works differently for a contract account, and software that assumed a keypair sometimes fails in ways that are confusing rather than explicit.

The Per-Chain Address Problem

A contract exists where it has been deployed. A wallet address that works on one chain may have nothing behind it on another.

Some designs produce the same address across chains when deployed with the same parameters, which helps, but the deployment still has to occur. Sending funds to a contract address on a chain where the contract has not been deployed puts them at an address nobody controls yet, and recovering them depends entirely on whether that deployment can still be performed.

Check that the wallet exists on the chain before receiving funds there.

Guardians

Social recovery replaces one failure mode with another, and the replacement is usually favourable but is not free.

Guardians have to be available when needed, which means years later. They have to be independent enough that one incident does not reach all of them at once, which rules out several devices in one house or several accounts under one provider. And they have to be people who will not collude, because a sufficient set of them can move the wallet’s authority.

Choosing them is the real work of setting up such a wallet, and reviewing the choice periodically matters, because relationships and circumstances change over the timescales holdings persist.

Where It Fits

For an account used actively, with meaningful value and a real chance of a device being lost, the recovery and limit features address genuine risks that a keypair account leaves entirely open.

For long-term storage that is rarely touched, a hardware wallet kept offline addresses the main risk more simply and with a smaller trust surface.

The combination is often the right answer: a hardware-held key as one signer on a contract wallet, with guardians for recovery. The device protects the key from a compromised computer, and the contract limits what a compromised key can do.

What People Get Wrong About This

The first mistake is assuming the address works everywhere. The contract has to be deployed on each chain.

The second is treating guardians as a formality. They are the recovery mechanism, and choosing people who cannot be reached or who are all compromised together defeats it.

A third is expecting the same fees as a plain account. More work is done, so more is paid.

A fourth is overlooking that the contract’s code is now part of the trust model. A well-reviewed, widely used implementation is materially different from a novel one.

And the last is assuming the recovery feature removes the need for any backup at all. What is being backed up changes; the need to plan for loss does not.

Related

Custodial against non-custodial frames the underlying question of who controls the funds, and choosing a wallet covers the decision this one sits inside.