Native Token Abstraction

The foundational standard enabling Native Token Abstraction. It introduces a UserOperation mempool and Bundlers to allow smart contract wallets to execute transactions where gas fees can be paid in any ERC-20 token, abstracting away the need for the native token (e.g., ETH) in the user's wallet.

• EntryPoint Contract: A singleton contract that validates and executes bundled UserOperations.
• Paymasters: Smart contracts that can sponsor transaction fees on behalf of users, often swapping the user's ERC-20 tokens for the native token to pay the network.

The core smart contract component that facilitates fee payment in non-native assets. A Paymaster can implement various sponsorship models:

• Token-Based: Spends the user's ERC-20 tokens, automatically swapping them for the native gas token via an on-chain DEX.
• Sponsored (Gasless): The dApp or a third-party pays the fees, creating a seamless user onboarding experience.
• Subscription-Based: Users pre-pay for a bundle of transactions using a stablecoin or other asset.

This removes the critical UX hurdle of requiring users to first acquire the chain's native token.

A decentralized network of nodes (Bundlers) that package UserOperations from the alt-mempool into standard blockchain transactions. They are essential infrastructure for Native Token Abstraction.

• Function: Listen for UserOperations, simulate them via the EntryPoint, bundle them, and submit them to the base layer.
• Incentive: Earn fees from the bundled transactions.
• Decentralization: A robust network of independent Bundlers (like Flashbots SUAVE, Stackup, Pimlico) is critical to prevent censorship and ensure system liveness.

The user-facing endpoint for Native Token Abstraction. Unlike Externally Owned Accounts (EOAs), smart contract wallets (e.g., Safe, Argent, Biconomy) can contain arbitrary logic, enabling them to:

• Initiate UserOperations that specify a Paymaster for fee payment.
• Implement social recovery and multi-signature security.
• Batch multiple actions (e.g., swap token A for token B, then provide liquidity) into a single gasless transaction.

This turns the wallet from a simple key holder into a programmable agent for the user.

A proposed upgrade that aims to simplify and enhance Native Token Abstraction by extending EOA capabilities. EIP-7702 allows an EOA to temporarily act as a smart contract for a single transaction.

• Key Difference from ERC-4337: No separate mempool or Bundler network is required; transactions flow through the existing infrastructure.
• Mechanism: An EOA signs a transaction that includes contract code and authorization. For that transaction, it operates with the logic of that code (e.g., using a Paymaster), then reverts to being a standard EOA.
• Benefit: Reduces complexity and could lead to faster, cheaper adoption of abstraction features.

Native Token Abstraction is a critical design pattern for Layer 2 rollups and application-specific blockchains (Appchains).

• L2 Adoption: Chains like Optimism, Arbitrum, and zkSync have integrated Paymaster support, allowing users to pay fees in USDC, ETH, or the rollup's own token.
• Appchain Design: New chains (e.g., built with OP Stack, Arbitrum Orbit) can launch with abstraction as a first-class feature, eliminating the 'gas token chicken-and-egg' problem for their ecosystem.
• Cross-Chain Abstraction: Advanced Paymasters can use cross-chain messaging (e.g., CCIP, LayerZero) to allow fee payment with assets held on a different chain entirely.

A paymaster is a smart contract that sponsors transaction fees on behalf of users. This creates a centralization point and a new trust model.

• Censorship: A malicious or compromised paymaster can selectively refuse to sponsor transactions for specific users or dApps.
• Rug Pulls: A paymaster can drain its deposited funds or change its sponsorship policy, causing user transactions to fail.
• Systemic Risk: A widely used paymaster becoming insolvent or exploited can disrupt a large segment of network activity.

Abstracting the payer introduces new signature schemes (e.g., EIP-4337's UserOperation) that are more complex than native transactions.

• Signature Malleability: Custom signature validation logic in paymasters or account abstraction wallets can have bugs, leading to forged approvals.
• Replay Attacks: Improperly implemented nonce or uniqueness handling across different EntryPoint contracts can allow transaction replay.
• Gas Estimation Errors: Mispriced validation or execution logic can cause transactions to run out of gas and revert, wasting sponsored funds.

Separating the fee payer from the transaction signer opens new Maximal Extractable Value (MEV) and economic attacks.

• Paymaster Exploitation: Attackers can craft transactions that are expensive for the paymaster to validate but cheap to execute, draining its balance (e.g., via computational loops).
• Bundler Incentives: Bundlers (nodes that package UserOperations) may reorder or censor transactions based on their own profit, similar to miner extractable value.
• Stake Slashing: In systems where paymasters or bundlers must stake (e.g., SFFL), faulty behavior can lead to slashing, creating new financial risks.

The core infrastructure—EntryPoint, Paymaster, Account Abstraction Wallet—are complex smart contracts that become critical system components.

• EntryPoint as a Single Point of Failure: A bug in the canonical EntryPoint contract could allow theft of all deposited stake or unauthorized transaction execution.
• Upgrade Risks: Immutable contracts reduce risk but hinder fixes; upgradeable contracts introduce admin key risks.
• Integration Bugs: DApps and wallets must correctly integrate new standards, increasing the chance of user error or loss.

When validators are paid in a token other than the native asset, it can distort network security economics.

• Fee Market Distortion: If fee payment is abstracted to a volatile or illiquid token, validators may face unpredictable revenue, potentially reducing participation.
• Staking Derivative Risks: Systems that wrap staked native tokens (e.g., LSTs) to pay fees introduce dependency on the security of that derivative's protocol.
• Long-Term Security Budget: A chain's native token often funds protocol development and security audits. Abstraction could divert value away from this ecosystem funding.

The user experience of "gasless" transactions can obscure true costs and create new social engineering risks.

• Hidden Costs: Fees may be baked into token exchange rates or dApp usage fees, making true transaction cost opaque.
• Spoofed Paymaster Interfaces: Users might be tricked into approving interactions with malicious paymaster contracts that drain their accounts.
• Approval Fatigue: Simplified onboarding may lead to users granting sweeping permissions to abstracted accounts or paymasters without understanding the risk.