ERC-4337 introduced smart accounts; EIP-7702 lets an existing account behave like one. What gas sponsorship, batching and recovery mean for teams shipping crypto products to non-crypto users.
The single largest drop-off in onboarding a non-crypto user is not the private key. It is the moment they are told that before doing the thing they came to do, they must acquire a second asset, in a specific network, to pay for the privilege of doing it. Nothing in mainstream software prepares anyone for this.
Account abstraction exists to remove that requirement, and the landscape changed meaningfully once delegation arrived alongside smart accounts.
ERC-4337 introduced smart contract accounts without changing the protocol. Users express actions as UserOperations rather than transactions; bundlers collect these and submit them; paymasters can agree to cover gas. Because the account is a contract, it can implement arbitrary validation — multisig, session keys, spending limits, social recovery.
The practical constraint was migration. Adopting a smart account meant deploying a new contract and moving to a new address, which is straightforward for a new user and awkward for anyone with an existing position, history or reputation attached to their address.
EIP-7702 lets an existing externally owned account temporarily delegate its behaviour to contract code. The address stays the same; within the scope of the delegation it can behave like a smart account.
That removes the migration step. A wallet a user has held for years can be given batching, sponsorship and recovery for a session, without redeploying or moving funds. For product teams this collapses a class of onboarding work that previously had no good answer.
The application pays, and the user never learns the gas token exists. This is the change that makes a crypto product feel like software. It also introduces an abuse surface: a paymaster covering unbounded gas is a faucet, so sponsorship needs policy — per-user limits, allowlisted operations, rate limiting.
Approve-then-swap is two transactions and two confirmations for what the user experiences as one action. Batching makes it atomic. Beyond the UX gain, atomicity removes a genuine failure state where the approval lands and the action does not, leaving a standing allowance the user did not intend to keep.
Seed phrases fail as a consumer mechanism because they push an irreversible, unfamiliar responsibility onto someone at the least convenient moment. Social or guardian recovery replaces it with a model people already understand from ordinary account recovery.
Delegation is powerful and therefore worth treating carefully. Signing a delegation is not the same as signing a transfer, and interfaces that present them identically are training users badly. Session keys should be scoped and time-bounded rather than broad. Paymaster policy is an application security concern, not a billing setting.
The honest summary is that account abstraction moves complexity from the user to the engineering team. That is the correct place for it, but it is a transfer rather than a deletion.
On-chain order book, off-chain matching with on-chain settlement, or a pooled counterparty. Three designs behind perpetual DEXs, and what each costs in latency, trust and liquidation risk.
9 min readSampleUsers state an outcome and solvers compete to deliver it. How intent-based DEX design moves execution risk off the user, and what it demands of settlement, MEV protection and solver incentives.
8 min readSampleMatching latency and custody are the real dividing lines between centralised and decentralised exchanges, not ideology. How each choice propagates through architecture, risk and compliance.
8 min readSampleBring the problem, the constraints and the deadline. We will come back with an architecture and an honest view of effort.