|
1 | 1 | --- |
2 | | -title: Account Abstraction |
3 | | -description: "Account Abstraction | Documentation - Web3Auth" |
| 2 | +title: Web3Auth's Native Account Abstraction |
| 3 | +sidebar_label: Account Abstraction |
| 4 | +description: "Native Account Abstraction | Documentation - Web3Auth" |
4 | 5 | --- |
5 | 6 |
|
6 | | -Account abstraction is a term commonly used to address the use of smart contract wallets. These |
7 | | -smart contract wallets are based on the [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) which |
8 | | -aims at improving the user onboarding journey and enabling more sophisticated transaction patterns |
9 | | -by abstracting details like validation, gas payment, and execution from the user. |
| 7 | +Create and manage smart accounts for your users with just a few lines of code, using Web3Auth’s |
| 8 | +native account abstraction. With smart accounts, you can offer enhanced control and programmability, |
| 9 | +such as these listed below: |
10 | 10 |
|
11 | | -## Web3Auth's Native Account Abstraction |
12 | | - |
13 | | -Effortlessly create and manage smart accounts for your users with just a few lines of code, using |
14 | | -our native account abstraction. Additionally, SCWs offer enhanced control and programmability, |
15 | | -enabling features like those listed below. |
16 | | - |
17 | | -- Gas Abstraction: Cover transaction fees for users, or allow users to pay for their own |
| 11 | +- **Gas Sponsorship:** Cover transaction fees for users, or allow users to pay for their own |
18 | 12 | transactions using ERC-20 tokens. |
19 | | -- Batch Transactions: Perform multiple transactions in a single call. |
20 | | -- Automated Transactions: Allow users to automate actions, like swapping ETH to USDT when ETH hits |
21 | | - $4,000. |
22 | | -- Set Spending Limits: Allow users to set tailored spending limits. |
23 | | - |
24 | | -Our native AA integration streamlines your setup, allowing you to create and manage smart accounts |
25 | | -using your favorite libraries like Viem, Ethers, and Web3.js. With this, you don't need to rely on |
26 | | -third party packages to effortlessly create ERC-4337 compatible Smart Contract Wallets (SCWs), and |
27 | | -give users the ability to perform batch transactions and efficiently manage gas sponsorship. |
28 | | - |
29 | | -Web3Auth's native account abstraction gives you the flexibility to choose your preferred account |
30 | | -abstraction provider, configure your bundler client, and integrate your paymaster. Please checkout |
31 | | -our documentation on how [ERC-4337 components](#components-of-erc-4337) work for more information. |
32 | | - |
33 | | -## Getting Started |
34 | | - |
35 | | -Web3Auth's native account abstraction gives you the flexibility to choose your preferred account |
36 | | -abstraction provider, configure your bundler client, and integrate your paymaster. Learn how to use |
37 | | -[Web3Auth with Account Abstraction](/docs/sdk/pnp/web/providers/aa-provider). |
38 | | - |
39 | | -## Components of ERC 4337 |
40 | | - |
41 | | -Smart contract wallets did exist before ERC 4337 but lacked a standardization across the ecosystem |
42 | | -which reduced the interoperability. ERC 4337 helps to standardize account abstraction across all the |
43 | | -Ethereum compatible chains. ERC 4337 consists of a few main components which help us achieve account |
44 | | -abstraction. |
45 | | - |
46 | | -### UserOperation |
47 | | - |
48 | | -A UserOperation is the transaction object for the smart contract wallets, and was introduced to |
49 | | -avoid the changes on the EVM. Unlike EOA wallets, where the user signs the transaction, in smart |
50 | | -contract wallets, the user signs a UserOperation. |
51 | 13 |
|
52 | | -<details> |
53 | | -<summary> UserOperation Structure </summary> |
| 14 | +- **Batch Transactions:** Perform multiple transactions in a single call. |
54 | 15 |
|
55 | | -| Field | Type | Description | |
56 | | -| ------------------------------- | --------- | ---------------------------------------------------------------------------------------- | |
57 | | -| `sender` | `address` | The address of the sender smart account | |
58 | | -| `nonce` | `uint256` | Anti-replay parameter | |
59 | | -| `factory` | `address` | Contract address for the Factory contract used to deploy new account, if not deployed. | |
60 | | -| `factoryData` | `bytes` | Data to be used during deploying the new account through Factory. | |
61 | | -| `callData` | `bytes` | The data to pass to the smart account during the main execution phase | |
62 | | -| `callGasLimit` | `uint256` | The amount of gas to allocate the main execution call | |
63 | | -| `verificationGasLimit` | `uint256` | The amount of gas to allocate for the verification step | |
64 | | -| `preVerificationGas` | `uint256` | Extra gas to pay the bundler | |
65 | | -| `maxFeePerGas` | `uint256` | Maximum fee per gas (see [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)) | |
66 | | -| `maxPriorityFeePerGas` | `uint256` | Maximum priority fee per gas (see EIP-1559) | |
67 | | -| `paymaster` | `address` | Address of paymaster contract. Should be empty if account is paying for the fees itself. | |
68 | | -| `paymasterVerificationGasLimit` | `uint256` | The amount of gas to allocate for the paymaster validation code. | |
69 | | -| `paymasterPostOpGasLimit` | `uint256` | The amount of gas to allocate for the paymaster post-operation code. | |
70 | | -| `paymasterData` | `bytes` | Data for paymaster, only if the paymaster is used | |
71 | | -| `signature` | `bytes` | Data passed into the account to verify authorization | |
| 16 | +- **Automated Transactions:** Allow users to automate actions, like swapping ETH to USDT when ETH |
| 17 | + hits $4,000. |
72 | 18 |
|
73 | | -</details> |
| 19 | +- **Set Spending Limits:** Allow users to set tailored spending limits. |
74 | 20 |
|
75 | | -### UserOp Mempool |
| 21 | +:::note |
76 | 22 |
|
77 | | -Mempools for User Operation are separate from the regular blockchain transaction mempool.ERC 4337 |
78 | | -introduces an alternative to the mempool, called UserOp Mempool, which helps to keep track of |
79 | | -pending UserOperations. It acts as a waiting room and helps bundlers to keep track of |
80 | | -UserOperations. |
| 23 | +Find out more about |
| 24 | +[Account Abstraction (ERC 4337)](https://blog.web3auth.io/an-ultimate-guide-to-web3-wallets-externally-owned-account-and-smart-contract-wallet/#introduction-to-eip-4337) |
| 25 | +and how it works. |
81 | 26 |
|
82 | | -### Bundler |
| 27 | +::: |
83 | 28 |
|
84 | | -Unlike the RPC nodes responsible for validating the transactions and submitting them to the |
85 | | -blockchain, bundlers are third party nodes that bundles the UserOperations, perform the validation, |
86 | | -and runs the simulations before submitting them on-chain. |
87 | | - |
88 | | -The bundler is also responsible to validate that the Paymaster has enough balance to sponsor the gas |
89 | | -fees for the batch transactions. For aggregated UserOperations, the bundler also ensures that the |
90 | | -aggregated signature is created, and the UserOperations are updated with the same. The aggregated |
91 | | -signatures are used to improve the efficiency and scalability of transaction processing by bundler. |
92 | | - |
93 | | -### EntryPoint |
94 | | - |
95 | | -The EntryPoint contract, as its name suggests, serves as the global singleton that manages |
96 | | -UserOperations by validating and executing them. When a UserOperation is submitted, the EntryPoint |
97 | | -performs the following key tasks: |
98 | | - |
99 | | - |
100 | | - |
101 | | -- If the UserOperations are bundled into a single transaction, the EntryPoint validates the |
102 | | - aggregated signature to ensure its validity. |
103 | | - |
104 | | -- The EntryPoint checks if the user's account is already deployed. If it isn't, the contract deploys |
105 | | - the account using the CREATE2Factory. Afterwards, the EntryPoint uses the Account contract to |
106 | | - validate the UserOperation. |
107 | | - |
108 | | -- If a Paymaster is involved in the UserOperation, the EntryPoint verifies that the Paymaster has |
109 | | - agreed to cover the transaction fees by validating its signature. If no Paymaster is used, the |
110 | | - EntryPoint ensures that the user has sufficient balance to pay for the gas fees. |
111 | | - |
112 | | -- After successfully validating the UserOperation and Paymaster details, the EntryPoint proceeds to |
113 | | - execute the transaction. |
114 | | - |
115 | | -### Smart Account |
| 29 | +## Getting Started |
116 | 30 |
|
117 | | -Smart accounts are user facing accounts deployed through the CREATE2Factory. Each smart account |
118 | | -contains a key function called `validateUserOp`, which validates the UserOperation. This function is |
119 | | -triggered by the EntryPoint contract during the operation validation phase. |
| 31 | +Our native Account Abstraction (AA) integration simplifies setup, enabling you to create and manage |
| 32 | +smart accounts effortlessly with popular libraries like Viem, Ethers, and Web3.js—no need for |
| 33 | +third-party packages to achieve ERC-4337 compatibility. We are working closely with different |
| 34 | +partners in the account abstraction ecosystem and will provide support for evolving standards like |
| 35 | +EIP-7702, ERC-7579 (Modular Accounts), and ERC-7555 (account discovery) as they get finalized. |
120 | 36 |
|
121 | | -Beyond basic functionality, smart accounts can incorporate advanced features like account recovery, |
122 | | -autopilot execution, spend limits, and other customizable, programmable capabilities. |
| 37 | +:::note |
123 | 38 |
|
124 | | -### Paymaster |
| 39 | +Getting started is easy; you just have to select your preferred smart account provider, configure |
| 40 | +your bundler client, and integrate your paymaster. |
| 41 | +[See this link for the steps.](/sdk/pnp/web/providers/aa-provider) |
125 | 42 |
|
126 | | -The paymaster component of the ERC 4337 is responsible for sponsoring the gas fees for the |
127 | | -UserOperations. The paymaster contract also allows the user to pay the gas fees with the supported |
128 | | -ERC-20 tokens. |
| 43 | +::: |
129 | 44 |
|
130 | | -The paymaster contract must implement the `validatePaymasterUserOp` function which is called by the |
131 | | -EntryPoint contract during the validation phase. The paymaster also has additional `postOp` function |
132 | | -which is called by the EntryPoint contract after the transaction is executed. This function handles |
133 | | -the additional logic required by the paymaster. For instance, withdraw the ERC-20 token from the |
134 | | -user's account after the transaction is executed. |
| 45 | +:::tip |
135 | 46 |
|
136 | | -### Aggregator |
| 47 | +For a quick configuration tailored to your needs, explore our detailed guides: |
137 | 48 |
|
138 | | -As the name suggests, the aggregator contract is responsible for aggregating the signatures of the |
139 | | -UserOperations. The aggregator contract must implement the `aggregateSignatures` function which |
140 | | -takes in a list of signatures and returns the aggregated signature. The signatues are usually |
141 | | -aggregated by the bundler to improve the efficiency and scalability of transaction processing, as it |
142 | | -allows bundler to submit multiple UserOperations in a single transaction. |
| 49 | +- [Guide to Sending Gasless Transactions](/guides/sending-gasless-transaction) |
| 50 | +- [Guide to Sending Transactions with an ERC-20 Paymaster](/guides/erc20-paymaster) |
143 | 51 |
|
144 | | -For validating the aggregated signature, the Aggregator also has the `validateSignatures` function |
145 | | -used by the EntryPoint contract during the validation phase. |
| 52 | +::: |
0 commit comments