Account Abstraction (AA) on EVM was standardized with the introduction of ERC-4337. It is a key initiative for facilitating greater adoption of blockchain, and providing increased security for many retail users.

It also comes with additional challenges for data processing and reporting.

Every AA transaction looks fundamentally the same: it's a call to the function handleOps() in the ERC-4337 entrypoint contract of the chain.

handleOps() receives an array of userOps, each of which represents an atomic transaction for a particular user.

Understanding the user intent behind each AA transaction requires looking through the bytes-formatted instructions in the userOp, and determining what contract is being called underneath, and for what purpose.

We're proud to be the first solution in the market for decoding and translating ERC-4337 transactions to human-readable form.

When classifying AA transactions, we have two different outputs depending on the perspective:

From the perspective of the `sender` address (the user)

Here, we will simply classify to one of our standard types, thereby removing all the technical complexity associated with ERC-4337.

For example, if the user (which would be the sender address in the userOp) requested to perform a swap on Balancer, we'll decode that and simply return a swap classified object, when classifying the AA transaction from the perspective of that particular sender address.

In technical terms, the "user" here really means the address of the smart contract wallet that has been deployed for a particular user. And that is the same address that gets listed as sender in the userOp.

From the perspective of the `bundler` address (the raw transaction executor)

In an ERC-4337 transaction, the raw from of the transaction will be the bundler.

The bundler will pay for gas to execute the list of userOps, and will typically receive an internal transaction representing a gas refund + fee for doing the work.

When querying an AA transaction from the perspective of the bundler address, we will return a special transaction type: submitTransactionBatch.

That transaction type only applies to the perspective of the bundler, and will include asset transfer events relevant to the bundler (the gas that was paid, and any refund / fees received by the bundler)