IIP-14 Account Abstraction via EntryPoint Contract


The EVM-based blockchain account model is based on the concept of Externally Owned Accounts(EOAs) and Contract Accounts. The former is controlled by a private key and is responsible for initiating transactions while the latter represents smart contracts that execute code on the blockchain. Currently, contract accounts depend on EOAs for executing transactions, creating a security vulnerability. The account abstraction proposal completely avoids the need for consensus-layer protocol changes. Instead of adding new protocol features and changing the bottom-layer transaction type, this proposal instead introduces a higher-layer pseudo-transaction object called a UserOperation. Users send UserOperation objects into a separate mempool. A special class of actors called bundlers (either block builders, or users that can send transactions to block builders through a bundle marketplace) packages up a set of these objects into a transaction, making a handleOps call to a special contract (EntryPoint), and that transaction then gets included in a block.


Account abstraction aims to abstract as many of the account properties as possible, including authentication, authorization, replay protection, gas payment, batching & atomicity, etc. All of these aspects are controlled by the EVM code rather than rigid consensus rules.

This proposal takes a different approach, avoiding any adjustments to the consensus layer. It seeks to achieve the following goals:

  • Achieve the key goal of account abstraction

allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs

  • Decentralization

    • Allow any bundler (think: block builder) to participate in the process of including account-abstracted user operations

    • Work with all activity happening over a public mempool; users do not need to know the direct communication addresses (eg. IP, onion) of any specific actors

    • Avoid trust assumptions on bundlers

  • Do not require any consensus changes

Consensus layer changes are harder to implement, require more comprehensive testing, and bear higher risk of deploying. Hence, to increase the chance of faster adoption, this proposal avoids consensus layer changes.

  • Try to support other use cases

    • Privacy-preserving applications

    • Atomic multi-operations

    • Pay tx fees with XRC20 tokens, allow developers to pay fees for their users, and sponsored transaction use cases more generally

    • Support aggregated signature (e.g. BLS, Secp256r1)

More details could be found here: iip-14: Account Abstraction via EntryPoint Contract by ququzone · Pull Request #19 · iotexproject/iips · GitHub


Please read this proposal carefully and offer your comments and suggestions, should you have any. We think this will be a significant improvement when it’s in place.

The essence of this proposal or So what?

When implemented, builders will be able to create dApps that offer a much simpler and safer user experience.

In brief, a better experience.

That, in turn, means a platform that can more easily onboard people who are later adopters. The result will be broader adoption of the IoTeX chain.

Think: driving a car with an automatic transmission vs. stick shifting and using the clutch pedal. Some people swear by the control and feel of a stick shift. The rest of us… “I just want to start the car, point it in the right direction, and go.” Most people fall into the two majority segments above.

For the lay person, that would be me, I like to have a high level understanding of the changes/benefits described. Account abstraction is clearly an important feature. It’s worth exploring this topic. What is Account Abstraction? | Stackup Docs

Some of the supported use cases for these changes are:

  • Privacy-preserving applications

  • Atomic multi-operations - That is, changing multi-step operations into a single step for people to perform. Simplification!

  • Pay tx fees with XRC20 tokens, allow developers to pay fees for their users, and sponsored transaction use cases more generally. When we see more developers taking care of the fees for transactions, people will appreciate how much less trouble it is to use a dApp. Amazon discovered this when they introduced free shipping in 2002.

  • Support aggregated signature (e.g. BLS, Secp256r1) - Signature aggregation is a process that joins two or more digital signatures into a new and unique signature. This new aggregate signature can be used to validate multiple inputs on the blockchain.

What do you think? Let us know!


Ease of use sounds good to me


I’m all in for account abstraction (esp as it relates to W3bstream)

  • Paymaster: I’ve often wondered how to handle situations where a w3bstream account runs out of gas and is unable to continue interacting with dapps, while the developer remains unaware of this situation. Having your dapps pay for the gas fees in with such interaction could eliminate this concern altogether.

  • Signature: Supporting new signature schemes for blockchain transactions would enable a broad range of Internet-connected devices (such as Arduino) to execute valid IoTeX transactions, Hence broadening the IoT device ecosystem

  • A system allowing the recovery of lost accounts could benefit both users and machines that adopt the IoTeX network.

If you are interested in DePIN you can learn more about the latest developments in the sector and compare projects by visiting DePINscan. DePINscan powered by W3bstream and IoTeX is designed to empower intelligent investors in the DePIN sector.


I’m still a bit in the unclear about how it works. I understand that it will facilitate but how.

Can we get an example of any dApps that will be made easier with this?

1 Like

So far it’s easy and affordable to build decentralized applications, while also providing greater flexibility and privacy to users, sounds good to me.


Question from the community



I’ll have to ask the developers about this specifically but it looks like it would. It might full under this part of the proposal:
“Support aggregated signature (e.g. BLS, Secp256r1)”

What I found on Account Abstraction describes this as one of the functions that would be enabled. In particular, Social Recovery. This is where you would assign multi-signature permissions to a few trusted people (don’t piss them off) to help you recover a password. See this link What is Account Abstraction? | Stackup Docs - the bullet point Account Security. Moving this discussion to the Community Forum so everyone can benefit from what we learn and any thoughts, concerns, suggestions people have on this proposal.

Great question - that’s one we all want to know the answer to. @leo_io can you address this question on password recovery?


Qevan Guo answered this (a resounding Yes) on Twitter: See his post that covers the highlights of this IoTeX Improvement Proposal.


No brainer yes from me.

We’re likely to vote on this proposal this week so as a reminder and to get more opinions we have a little survey for you.

If we approve Account Abstraction, what will you find most valuable?

  • Social password recovery
  • Setting spending limits
  • Autopay bills
  • Pre-funded game sessions
  • 3rd parties ability to pay gas fees

0 voters

Auto pay bills would be awesome once iopay is more integrated with such types of services

1 Like

Voting begins on April 2nd and continues through April 9th. This promises to deliver truly impactful benefits for a broad range of users, from crypto-sophisticates (my term) to the newbies. We’re making it more broadly accessible and that’s a good thing. You’ll be able to vote at gov.iotex.io.


It’s a yes for me. LFG🚀