---
rip: 7953
title: System Events for Native Account Abstraction
description: Events emitted automatically for Native Account Abstraction transactions to simplify transaction data access
author: Yoav Weiss (@yoavw), Alex Forshtat (@forshtat), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn)
discussions-to:
status: Draft
type: Standards Track
category: Core
created: 2025-04-01
requires: 7560
---

## Abstract

This proposal describes how system events injected by the virtual machine directly without calls to the `LOG` opcodes
while executing the RIP-7560 transactions

## Motivation

The [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) defines an `EntryPoint` contract that accepts
an array structs named `UserOperation` and executes them as a part of an Account Abstraction protocol.

The `EntryPoint` contract emits events during the execution of a `UserOperation` in order to expose
some of the details of the on-chain state that would not be available otherwise.

Additionally, the API for Ethereum events provides support for unique and useful features,
such as event subscriptions or indexed parameters.

A set of similar proposals exists for the Ethereum L1 as well,
notably [EIP-7708](https://eips.ethereum.org/EIPS/eip-7708) and [EIP-7889](https://eips.ethereum.org/EIPS/eip-7889).

## Specification

### System Transaction Events

We define the following system-level events that are emitted as part of an RIP-7560 transaction:

```solidity
    event RIP7560TransactionEvent(
        address indexed sender,
        address indexed paymaster,
        address indexed deployer,
        uint256 nonce,
        uint256 executionStatus
    );

    event RIP7560TransactionRevertReason(
        address indexed sender,
        uint256 nonce,
        bytes revertReason
    );

    event RIP7560TransactionPostOpRevertReason(
        address indexed sender,
        address indexed paymaster,
        uint256 nonce,
        bytes revertReason
    );
```

* `RIP7560TransactionEvent` event is emitted in the end of each RIP-7560 transaction.

* `RIP7560TransactionRevertReason` event is emitted if the RIP-7560 transaction's execution frame
  has reverted with a non-zero length return data.

* `RIP7560TransactionPostOpRevertReason` event is emitted if the RIP-7560 transaction Paymaster's "postOp" call
  has reverted with a non-zero length return data.

The bytes array returned as the `revertReason` parameter is truncated to its maximum length of `MAX_REVERT_REASON_SIZE`.
Any data returned above that length will not be observable in a transaction receipt.

The gas cost of System Transaction Events is not charged separately and is covered by the `AA_BASE_GAS_COST`
of a transaction.

The values for the `executionStatus` are the following:

* `success` = 0
* `executionFailure` = 1
* `postOpFailure` = 2
* `executionAndPostOpFailure` = 3

All events are emitted at the `AA_ENTRY_POINT` address.

## Rationale

### Not using transaction receipt

Some of the data exposed as part of the system events can be exposed as part of the transaction receipt as well.

There are a few reasons to expose this data as a system event:

* Backwards-compatibility with ERC-4337 for existing Account Abstraction tooling.

As the entire technological stack that exists around Account Abstraction so far has evolved around the
ERC-4337 protocol, abandoning event-based approach may make some existing tools infeasible.
This loss in functionality is unnecessary and is easily avoidable.

* Events provide search, filtering and subscription API that does not exist for the Transaction Receipts.

For example, with system events we are able to search for all transactions using a certain `Account` or `Paymaster`.
This functionality may be crucial for any reputation-based systems like ERC-7562 mempools.

* Modifications to Transaction Receipts may pose more challenges than to emitted events.

As the fields of Account Abstraction continues to evolve, it is possible there will be additional RIPs
defining additional system events in the future.
It is also possible that system events will be adopted by L2s for tasks other than Account Abstraction.
If each of these proposals needed to introduce a modification to the Transaction Receipt schema,
it would result in an unmanageable complexity.

## Backwards Compatibility

This proposal is meant to introduce a certain form of backwards compatibility between RIP-7560 and ERC-4337.

However, the event signatures are not equivalent and users will have to explicitly add support for these system events.

## Security Considerations

As system events are created by the execution environment directly,
there is no added risk in accepting the data exposed by these events.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).