How zkSync's Native Account Abstraction Works
zkSync builds account abstraction directly into its protocol instead of layering it on with ERC-4337. Here's how native AA changes wallet design.
Native account abstraction is zkSync's approach to making every account on its chain behave like a smart contract by default, rather than adding smart-contract-like features on top of standard externally-owned accounts through a separate, add-on standard like ERC-4337. The result is that features such as custom transaction validation, gas sponsorship, and social recovery are protocol-native rather than bolted on.
Two accounts, two philosophies
Ethereum has always had two account types: externally-owned accounts (EOAs), controlled by a private key, and contract accounts, controlled by code. For years, only contract accounts could have programmable logic — EOAs were locked into a single signature scheme and couldn't sponsor their own gas or batch transactions natively.
ERC-4337 solved this on Ethereum and most EVM chains without changing the protocol itself. It introduced a parallel system — a separate mempool, "bundlers," and "smart contract wallets" — that simulates account abstraction on top of the existing account model.
zkSync took a different route. Because it's a rollup with its own execution environment, it could redesign the account model from the ground up. On zkSync, every account — including what looks like a simple wallet — is technically a smart contract account, and features like custom signature validation are handled as part of standard transaction processing rather than through a bolted-on parallel system.
What this changes in practice
- Gas sponsorship: Applications can pay gas fees on behalf of users directly, without needing a separate paymaster infrastructure layered outside the protocol.
- Batched transactions: Users can approve and execute multiple actions in a single transaction natively, improving UX for multi-step DeFi interactions like approve-then-swap.
- Custom signature schemes: Wallets can support alternative authentication methods (like multi-factor signing or session keys) without needing a separate smart contract wallet deployed and managed outside the base account.
- Social recovery: Because every account can have custom logic, recovery mechanisms that don't rely solely on a single seed phrase are easier to implement at the account level.
The trade-off: less portability
Building account abstraction into the protocol makes it simpler and more consistent within zkSync, but it also means zkSync's account model isn't identical to standard Ethereum accounts or to ERC-4337 accounts on other chains. Wallet software, infrastructure, and tooling built for Ethereum-style accounts sometimes needs zkSync-specific adaptations, and vice versa. This is a genuine cost of the native approach — standardization across chains becomes harder when each chain solves account abstraction its own way.
Native AA vs. ERC-4337
| Aspect | zkSync native account abstraction | ERC-4337 (EVM standard) |
|---|---|---|
| Implementation | Built into protocol/execution layer | Layered on top via bundlers and paymasters |
| Chain compatibility | zkSync-specific | Works across most EVM chains |
| Complexity for developers | Lower once learned, chain-specific | Higher, but portable across chains |
| Gas sponsorship | Native support | Requires paymaster infrastructure |
What this means for wallet security
Account abstraction, regardless of implementation, changes how you should think about wallet risk. Because logic can be customized, the usual advice around DeFi wallet security still applies, but with an added dimension: you're also trusting the specific smart contract logic controlling your account, not just a private key. Before relying on advanced features like social recovery or session keys, understand exactly what conditions can move your funds and who, if anyone, has an emergency override.
Session keys and paymasters in practice
Two of the most user-visible benefits of native account abstraction are session keys and paymaster-sponsored transactions. A session key lets a user grant a limited, time-boxed, and scope-restricted signing permission to an application — for example, allowing a game to submit certain in-game transactions on your behalf for the next hour without requiring a wallet popup for every single action, while still preventing that key from doing anything outside its narrow, pre-approved scope. Paymaster-sponsored transactions let an application pay gas fees on a user's behalf, sometimes in a token other than ETH, removing a common onboarding friction point where new users need to acquire the network's gas token before they can do anything at all.
Both of these are technically possible on other EVM chains through ERC-4337, but zkSync's native implementation generally makes them simpler for developers to build and for wallets to support consistently, since the logic doesn't depend on a separate bundler infrastructure operating correctly alongside the base protocol.
What to watch as the ecosystem matures
Account abstraction, whether native or via ERC-4337, is still a relatively young area of wallet design, and best practices around session key scoping, spending limits, and recovery mechanisms are still evolving. Malicious or poorly designed smart contract wallet logic could, in principle, introduce new attack surfaces that don't exist for a simple key-controlled account — for instance, a poorly scoped session key could be exploited beyond its intended purpose. As with any new wallet technology, look for audited, widely used implementations rather than adopting the newest, least-reviewed account abstraction wallet software for anything holding significant value.
Bottom line
zkSync's native account abstraction folds smart-contract-like features directly into the protocol's account model, giving users gas sponsorship, batched transactions, and flexible authentication without needing ERC-4337's separate bundler infrastructure. The cost is reduced portability with the broader EVM ecosystem, since zkSync's account model diverges from the ERC-4337 standard most other chains use. For users, the security fundamentals don't change: understand what logic actually controls your account before trusting new convenience features with meaningful funds.
Related articles
This article is for educational purposes only and is not financial advice. DeFi involves significant risk, including total loss of funds. Always do your own research.