Create RIP: System Events for Native Account Abstraction

RIPS/rip-0001.md

@@ -0,0 +1,125 @@
+---
+rip: 0000
+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).