Skip to main content

Native AA

With Native Account Abstraction, every account supports AA by default.

The team is currently studying different options for how to bring native AA to Fuse Ember. This would enable the introduction of features like multi-signature security, gasless transactions, smart contract wallets, and more complex account logic without relying on external contract deployment, keeping a robust, secure, MEV-free solution without the disadvantages of ERC-4337.

Why Native (vs 4337)?​

  • Native AA is implemented in the protocol. ERC-4337 provides easy integration with Ethereum, but having this as a second level-implementation brings restrictions and security risks, including more opportunities for MEV. A native implementation solves these issues.
  • First class citizen. Smart accounts are first class citizens, and are easy to use and leverage.
  • Gas stipends for everyone. All accounts can enjoy gas abstraction and pay gas fees with ERC20 tokens.

Native AA on Ember

With Fuse Ember’s Native AA, every account now is a smart contract account and all transactions go through the native transaction cycle, together with EOA transactions. 

Native account abstraction means:

  • All accounts implement an IAccount standard interface that defines the methods that each smart contract account must implement.
  • Native AA supports the accounts JSON RPC module, meaning all EOA wallets (like MetaMask) are supported by default.
  • By default, all contracts go through the DefaultAccount, which mimics EOA behavior. 
  • All accounts have native support for a paymaster, meaning any account can sponsor the gas fees for another account’s transactions, or pay gas fees in another ERC20 token.

With Native Account Abstraction, smart wallets and paymasters are first class primitives that are natively supported by the network. This uses EOA with Native AA as a default smart contract that can be extended with additional features. All accounts follow the same standard interface and go through the same transaction cycle.

EIP-7702 Overview​

EIP-7702 is a proposal in the upcoming Ethereum Pectra hardfork that introduces a new transaction type that allows EOAs (Externally Owned Accounts) to designate a smart contract as their "implementation." This innovation bridges the gap between EOAs and Smart Contract Accounts, supporting advanced functionalities at the protocol level. EIP-7702 will be implemented on Polygon when the hardfork is completed.

Key Features Enabled by EIP-7702:

  • Batch Calls: Combine multiple operations into a single transaction, reducing overhead and enhancing efficiency.
  • Transaction Sponsorship: Delegate gas fee payment and execution to third parties such as Sequencers or Wallet Servers, enabling gasless transactions.
  • Arbitrary Signing Keys: Support diverse key types, including WebAuthn, P256, and BLS, for added flexibility and security in verifying actions.
  • Session & Scoped Keys: Authorize temporary or permissioned signing keys for specific use cases, improving usability and security.

This proposal enhances Ethereum's capabilities by empowering EOAs with smart account features, while maintaining compatibility with existing wallets and tools. Its adoption will streamline workflows for developers and provide users with a richer and more versatile account experience.

RIP-7560 Overview​

RIP-7560 is a proposal that builds upon ERC-4337 and EIP-2938, introducing consensus-layer protocol changes to enable a truly native Account Abstraction implementation on Ethereum. Unlike ERC-4337, which relies on higher-layer infrastructure, RIP-7560 aims to integrate account abstraction directly into the Ethereum protocol, enhancing efficiency, compatibility, and functionality. There is no clear timeline for RIP-7560, but we will aim to support it on Fuse Ember as soon as it is implemented.

The core idea is to split the transaction life cycle into three distinct steps:

  1. Validation: Determines transaction validity, including authorization and gas fee payment.
  2. Execution: Processes the transaction logic.
  3. Post-Transaction Logic: Handles final operations post-execution.

Additionally, RIP-7560 enables advanced features like gas sponsorship, allowing one contract (B) to pay gas fees for a transaction executed from another contract (A).

EIP-2938 offers a robust approach but is not backward-compatible with the production-ready ERC-4337 ecosystem. RIP-7560 bridges these gaps, combining the strengths of both approaches.