Account abstraction and intents

Who this is for: developers deciding whether to build wallet flows on top of smart accounts instead of raw externally-owned accounts (EOAs). You should already know: Architecture.

What account abstraction enables

Ordinarily, using a chain means holding a private key directly and paying gas in the chain's native token for every action. That's a real barrier for anyone who isn't already comfortable with a seed phrase and a funded wallet. Account abstraction, standardized as ERC-4337, replaces the raw externally-owned account with a smart contract account: a contract that defines its own rules for how a transaction gets authorized and paid for, instead of a single private key always being required.

Smart accounts also open up more flexible custody than a single private key: signature schemes and key-derivation approaches (including threshold/multi-party signing) can sit behind the same account interface, so "losing a seed phrase" doesn't have to mean losing the account.

Why it matters on Lumia

For an RWA chain specifically, account abstraction matters because the users interacting with a tokenized asset are not necessarily crypto-native: institutional counterparties and retail holders both benefit from not needing to manage gas and raw keys as a prerequisite to any interaction. It's also what makes sponsored, permissioned flows possible: a paymaster can gate sponsorship by the same kind of allowlist an issuer already uses for compliance.

For the developer integration guide (wiring a smart-account SDK into an app), see /build/account-abstraction/particle-connect.