Account Abstraction Explained for Builders

Most crypto users today hold funds in externally owned accounts: wallets controlled by a single private key. Lose the key and the funds are gone. Every transaction needs the network's gas token. Every action requires a separate signature. Account abstraction changes these rules by letting wallets be smart contracts with programmable behaviour.

Regular accounts and smart accounts

Feature	Externally owned account	Smart account
Controlled by	One private key	Contract logic, possibly several keys or methods
Recovery	Seed phrase only	Can include guardians, social recovery or backup keys
Gas payment	Native token required	Can be sponsored or paid in other tokens
Batch actions	One action per transaction	Several actions in one operation
Spending rules	None built in	Limits, allowlists and session permissions possible
Deployment	None needed	Contract must be deployed on each network

Smart accounts trade simplicity for flexibility.

How it works at a high level

With the widely adopted account abstraction approach on Ethereum-compatible networks, users sign operations rather than traditional transactions. Specialised infrastructure collects these operations and submits them to the network. A central contract validates each operation using the rules of the user's smart account, then executes it.

Additional components can pay gas on behalf of users. These sponsors can be the app itself, a service or a token-based payment arrangement.

Features builders can offer

Account abstraction enables user experiences that are hard with regular wallets:

1. Sponsored gas. New users interact without first buying the gas token.
2. Batched transactions. Approve and swap in one step.
3. Session keys. Games and apps perform limited actions without prompting for every move.
4. Social recovery. Trusted guardians help restore access.
5. Spending limits. Daily caps or allowlisted recipients add protection.
6. Passkey sign-in. Device-based authentication instead of seed phrases.

These features can make crypto apps feel much closer to familiar web and mobile apps.

Trade-offs and risks

Smart accounts introduce new considerations:

• Contract risk. The account itself is code that can contain bugs.
• Network deployment. An account address may not exist on other networks until deployed, which can cause problems if funds are sent there first.
• Infrastructure dependence. Operations rely on bundlers and paymasters, and outages affect users.
• Compatibility. Some apps and contracts assume regular accounts, such as those checking signatures in older ways.
• Sponsorship costs. Paying gas for users costs the app money and invites abuse without limits.

Design sponsorship policies carefully, such as limiting sponsored actions per user or per day.

When to use it

Account abstraction fits apps that:

• Target mainstream users new to crypto
• Involve frequent small actions, such as games or social apps
• Need onboarding without seed phrases
• Benefit from spending controls, such as business or family wallets

For apps whose users already have regular wallets and occasional transactions, supporting standard wallets may be enough, with smart accounts as an option.

Payments and smart accounts

Payments to merchants work with both account types, since a smart account can send token transfers just like a regular wallet. Merchants receiving payments should be aware that the paying address may be a contract, and refunds should go back through verified channels. Merchants should also receive on addresses that exist on every network they support. Proud Globe accepts tile payments from any wallet type, including smart accounts, as long as the exact token amount arrives on the chosen network.