Engineering
EVM, Solana and Move-based chains solve "programmable account" in three fundamentally different ways. Here's what account abstraction actually means on each, and what it takes to give an agent one identity that behaves consistently across all three.
"Account abstraction" gets used as if it's one idea with slightly different flavors per chain, but the three major architecture families (EVM, Solana, and Move-based chains like Sui and Aptos) start from fundamentally different assumptions about what an account even is. Those assumptions shape what's easy, what's hard, and what an agent-facing wallet actually has to do to feel the same everywhere.
Ethereum's original account model has exactly two kinds of accounts: externally-owned accounts, controlled by a private key with no custom logic, and contract accounts, which have logic but can't initiate transactions on their own. Account abstraction, as ERC-4337 and later ERC-7579 define it, is an elaborate, clever way to make a contract account behave like it can initiate its own transactions: via a UserOperation object, a mempool of alt-mempool bundlers, and a validation phase that runs before the real execution.
The payoff is real: programmable permissions, session keys, gas sponsorship, social recovery, all without changing the base protocol. The cost is architectural complexity most other ecosystems don't have to carry: a second transaction type, a separate mempool, and a strict separation between "can this be included" (validation) and "what does it actually do" (execution) that has real consequences for what you can and can't observe on-chain when something is rejected.
Solana's account model looks different from the start: every account is just a slot of data plus an owning program, and a transaction is a list of instructions, each one addressed to a program with an explicit list of accounts it's allowed to touch. There's no separate "abstracted" account type to bolt on, because ordinary accounts already look like structured, program-owned state.
That makes certain policy patterns more natural on Solana than on EVM: a program-owned vault with spend-limit state baked directly into an account is a first-class citizen of the model, not a workaround. The trade-off is Solana's transaction-level atomicity: an entire transaction succeeds or fails as one unit, which has real implications for any design that wants to record a rejected instruction independently of everything else bundled into the same transaction.
| Model | Native unit | What's "free" vs. engineered |
|---|---|---|
| EVM (ERC-4337/7579) | UserOperation + bundler | Programmability is engineered on top of a simple account model |
| Solana | Instruction within a transaction | Program-owned structured state is native; atomicity is transaction-wide |
| Move (Sui / Aptos) | Typed, resource-owned object | Ownership and transfer rules are enforced by the type system itself |
Sui and Aptos both use Move, a language built around linear resource types: an asset is a typed object that can only be moved, never implicitly copied or silently duplicated, and ownership rules are checked by the language and the bytecode verifier, not just by application logic. That changes what "policy enforcement" even means at the base layer: certain classes of bugs that require careful defensive coding on EVM (reentrancy, double-spend-style logic errors) are much harder to express at all in Move's type system.
The practical effect for account abstraction: object ownership and capability-based access control are closer to a first-class primitive than a pattern layered on top, which makes some agent-authority designs more naturally expressible, at the cost of a smaller developer ecosystem and less tooling maturity than EVM's.
The interesting engineering problem is building one authority layer that behaves identically to the human using it, regardless of which of these three different models is underneath, not picking the "best" account model.
Giving an agent a consistent identity and a consistent policy across EVM, Solana and Move chains means the enforcement logic can't just be ported. It has to be re-expressed natively in each environment's own primitives: a guard contract or executor module on EVM, a program-owned account with instruction-level checks on Solana, a capability object on Move chains. The policy the human defines should be one thing. How it's enforced has to be three different implementations underneath, each idiomatic to its own chain, or you end up with the weakest chain's guarantees setting the ceiling for all of them.
This piece describes general, publicly documented architecture differences across account-abstraction standards and chain runtimes, for engineering audiences evaluating multi-chain designs.
We've had to solve this exact problem for our own infrastructure. Happy to compare notes.
Get in touch