The Essential Guide to Account Abstraction on IoTeX: A Practical Guide to p256 Signatures

With our community voting in full favor on the IoTeX Improvement Proposal 14, Account Abstraction has finally hit the IoTeX Mainnet and Testnet, and its features are now available for all ecosystem devs. So, what is AA, how does it work, and how can you use it in your next application?

A Quick Refresher

Account Abstraction (AA) as defined by ERC-4337, "allows users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account." ERC-4337 introduces many user experience benefits, most notably enabling people to use Smart Contracts as their primary accounts.

ERC-4337 runs on top of the blockchain and does not require any changes to the blockchain itself. Currently, the IoTeX Account Abstraction code is based on ERC-4337 0.6.0 release version.

Components of the AA Infra

The components of the AA infrastructure are:

• Bundler Services: one endpoint for Mainnet (https://bundler.w3bstream.com) and one for Testnet (https://bundler.testnet.w3bstream.com). A bundler is an offchain node that aggregates multiple abstracted user operations into a single transaction that the underlying blockchain can process. This transaction is sent to the other fixed component, called the EntryPoint Contract.
• EntryPoint Contract: There are two EntryPoint contracts deployed on IoTeX, one for Mainnet (0xc3527348De07d591c9d567ce1998eFA2031B8675) and one for Testnet (0xc3527348De07d591c9d567ce1998eFA2031B8675). An EntryPoint contract is in charge of creating/deploying certain special contracts, called AccountFactory contracts, which in turn are in charge of creating certain accounts (wallet contracts) that can be used for specific purposes.

In order to use account abstraction to create a new custom account, there are certain components that the dApp developer will have to create based on the needs of their application:

• Account contract, which implements the validation logic in the validateUserOp method, and any execution logic that a user operation can require.
• AccountFactory contract, which is in charge, as said above, of creating/deploying new custom account contracts.
• Some client code that builds the user ops that are compatible with the verification rules implemented in the AccountFactory.
• A paymaster is an optional part of the AA architecture. IoTeX provides a paymaster service for Testnet only at https://paymaster.testnet.w3bstream.com. The role of the paymaster is to sponsor the gas needed to execute user operations, either sponsoring them completely or allowing users to pay for them in various tokens.

Example: The P256AccountFactory

As a first example, we have provided an official P256AccountFactory contract (Mainnet 0xD98d2B6cBca981c777037c5784721d8179D7030b and Testnet 0x508Db1A73FcBA98594679aD4f5d8D0B880BbdaFB) that allows developers to create account contracts that can verify user operations signed with the "p256" cryptography, rather than with Ethereum and IoTeX native "secp256k1" elliptic curve. This is incredibly useful, as it empowers developers to create applications where users can, for example, sign transactions with their biometrics, or move away from seed phrases, or even have superior security when their device supports a dedicated security chip (e.g. Android's Secure Element and Apple's Secure Enclave, etc.). The source code of the P256AccountFactorycan be found at https://github.com/iotexproject/account-abstraction-contracts/blob/main/contracts/accounts/secp256r1/P256AccountFactory.sol while the open source Account Abstraction contracts rely on the implementation by the original author of EIP-4337 for Ethereum here https://github.com/iotexproject/account-abstraction-contracts/tree/main.

The P256AccountFactory also supports the management of a paymaster service, which is made out of two components, a VerifyingPaymaster contract (https://github.com/iotexproject/account-abstraction-contracts/blob/main/contracts/paymaster/VerifyingPaymaster.sol) and an off-chain service endpoint to generate payment proof for the paymaster contract (https://paymaster.testnet.w3bstream.com, for Testnet only).

The code below shows you how to interact with the p256 account implementation from a javascript client in order to create an account:

1async function main() {
2    // load deployed contracts
3    const factory = (await ethers.getContract("P256AccountFactory")) as P256AccountFactory
4    const entryPoint = (await ethers.getContract("EntryPoint")) as EntryPoint
5,[object Object],
1}

While the following code will show you how to transfer IOTX using bundler service and paymaster:

1async function main() {
2const factory = (await ethers.getContract("P256AccountFactory")) as P256AccountFactory
3const accountTpl = await ethers.getContractFactory("P256Account")
4const entryPoint = (await ethers.getContract("EntryPoint")) as EntryPoint
5const paymaster = await ethers.getContract("VerifyingPaymaster")
6const bundler = new JsonRpcProvider(",[object Object],"),[object Object],
7,[object Object],
1}

The rest of the example on how to interact with the p256 account implementation from a javascript client, can be found at https://github.com/iotexproject/account-abstraction-contracts/tree/main/scripts/secp256r1