Add ERC: Minimal Batch Executor Interface

ERCS/erc-9999.md

@@ -0,0 +1,195 @@
+---
+eip: 9999
+title: Minimal Batch Executor Interface
+description: A minimal batch executor interface for delegations
+author: Vectorized (@Vectorized), Jake Moxey (@jxom)
+discussions-to: https://ethereum-magicians.org/t/minimal-batch-executor-interface-for-delegations/21776
+status: Draft
+type: Standards Track
+category: ERC
+created: 2024-11-21
+requires: 7702
+---
+
+## Abstract
+
+This proposal defines a minimal batch executor interface for delegations. A delegation is a smart contract that implements logic which other smart contracts can delegate to. This allows batched executions to be prepared in a standardized way.
+
+## Motivation
+
+With the advent of [EIP-7702](./eip-7702), it is possible for Externally Owned Account (EOA) to perform atomic batched executions.
+
+We anticipate that there will be multiple EIP-7702 delegations from multiple major vendors. To enable frontends to be able to detect and prepare a batched transaction that works across multiple vendors, we will need a standardized interface for batched executions.
+
+In the absence of such a standard, the vendors may choose to create their own proprietary implementations, causing ecosystem fragmentation. Imagine visiting your favorite decentralized exchange and realizing that your EOA delegation is not compatible with their frontend. Which ecosystem fragmentation, the infamous approve and swap workflow will not be fixed.
+
+Thus the motivation for this standard, which proposes a minimal batch execution interface that is easily implementable, extensible, and performant.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+### Overview
+
+The minimal batch executor interface is defined as follows:
+
+```solidity
+/// @dev Interface for minimal batch executor.
+interface IMinimalBatchExecutor {
+    /// @dev Call struct for the `execute` function.
+    struct Call {
+        //
+        address target;
+        uint256 value;
+        bytes data;
+    }
+
+    /// @dev Executes the `calls` and returns the results.
+    /// The `results` are the returned data from each call.
+    /// Reverts and bubbles up error if any call fails.
+    ///
+    /// If `authData` is empty, the implementation SHOULD require that
+    /// `msg.sender == address(this)`.
+    ///
+    /// If `authData` is not empty, the implementation SHOULD use the signature
+    /// encoded in `authData` to determine if the caller can perform the execution.
+    ///
+    /// `authData` may be used to store additional data for authentication.
+    function execute(Call[] calldata calls, bytes calldata authData)
+        external
+        payable
+        returns (bytes[] memory results);
+
+    /// @dev This function is provided for frontends to detect support.
+    /// Currently, it returns 1.
+    function minimalBatchExecutorVersion() external pure returns (uint256);
+}
+```
+
+## Rationale
+
+### `minimalBatchExecutorVersion` for detection
+
+[ERC-165](./eip-165.md) is a very difficult standard to work with in due to inheritance issues (e.g. diamond inheritance).
+
+Additionally, we opt not to make the behavior of `execute` to return a magic number for a magic input for ease of implementation.
+
+### Only a single `execute` function
+
+There is no need to define a variant for the single call case. 
+
+Having only a single `execute` function greatly simplifies implementation and integration.
+
+It also reduces bytecode size and lessens the Solidity function dispatch load.
+
+### Use of `Call` struct instead of custom byte encoding decoding
+
+Most layer 2s already include calldata compression and forward the calldata savings to users.
+
+As such, we opt for simplicity to enable maximum compatibility and ease of implementation.
+
+Using a standard struct also helps with auditability, block explorer integrations, browser wallet integrations, and [EIP-712](./eip-712) signature generations.
+
+### Usage of a single `authData` bytes argument
+
+The single `authData` bytes argument also provides all the flexibility that is needed.
+
+## Backwards Compatibility
+
+No backwards compatibility issues.
+
+## Reference Implementation
+
+```solidity
+// SPDX-License-Identifier: CC0-1.0
+pragma solidity ^0.8.4;
+
+/// @notice Minimal batch executor mixin.
+/// @author Solady (https://github.com/vectorized/solady/blob/main/src/accounts/MinimalBatchExecutor.sol)
+abstract contract MinimalBatchExecutor {
+    /*´:°•.°+.*•´.*:˚.°*.˚•´.°:°•.°•.*•´.*:˚.°*.˚•´.°:°•.°+.*•´.*:*/
+    /*                          STRUCTS                           */
+    /*.•°:°.´+˚.*°.˚:*.´•*.+°.•°:´*.´•*.•°.•°:°.´:•˚°.*°.˚:*.´+°.•*/
+
+    /// @dev Call struct for the `execute` function.
+    struct Call {
+        address target;
+        uint256 value;
+        bytes data;
+    }
+
+    /*´:°•.°+.*•´.*:˚.°*.˚•´.°:°•.°•.*•´.*:˚.°*.˚•´.°:°•.°+.*•´.*:*/
+    /*                   FUNCTIONS TO OVERRIDE                    */
+    /*.•°:°.´+˚.*°.˚:*.´•*.+°.•°:´*.´•*.•°.•°:°.´:•˚°.*°.˚:*.´+°.•*/
+
+    /// @dev Ensures that `execute` can only be called by the correct caller or `authData`.
+    function _authorizeExecute(Call[] calldata calls, bytes calldata authData) internal virtual;
+
+    /*´:°•.°+.*•´.*:˚.°*.˚•´.°:°•.°•.*•´.*:˚.°*.˚•´.°:°•.°+.*•´.*:*/
+    /*                          EXECUTE                           */
+    /*.•°:°.´+˚.*°.˚:*.´•*.+°.•°:´*.´•*.•°.•°:°.´:•˚°.*°.˚:*.´+°.•*/
+
+    /// @dev Executes the `calls` and returns the results.
+    /// Reverts and bubbles up error if any call fails.
+    function execute(Call[] calldata calls, bytes calldata authData)
+        public
+        payable
+        virtual
+        returns (bytes[] memory results)
+    {
+        _authorizeExecute(calls, authData);
+        return _execute(calls);
+    }
+
+    /*´:°•.°+.*•´.*:˚.°*.˚•´.°:°•.°•.*•´.*:˚.°*.˚•´.°:°•.°+.*•´.*:*/
+    /*                         SIGNALING                          */
+    /*.•°:°.´+˚.*°.˚:*.´•*.+°.•°:´*.´•*.•°.•°:°.´:•˚°.*°.˚:*.´+°.•*/
+
+    /// @dev This function is provided for frontends to detect support.
+    function minimalBatchExecutorVersion() public pure virtual returns (uint256) {
+        return 1; // This number may change.
+    }
+
+    /*´:°•.°+.*•´.*:˚.°*.˚•´.°:°•.°•.*•´.*:˚.°*.˚•´.°:°•.°+.*•´.*:*/
+    /*                      INTERNAL HELPERS                      */
+    /*.•°:°.´+˚.*°.˚:*.´•*.+°.•°:´*.´•*.•°.•°:°.´:•˚°.*°.˚:*.´+°.•*/
+
+    /// @dev Executes the `calls` and returns the results.
+    /// Reverts and bubbles up error if any call fails.
+    function _execute(Call[] calldata calls) internal virtual returns (bytes[] memory results) {
+        results = new bytes[](calls.length);
+        for (uint256 i; i < calls.length; ++i) {
+            Call calldata c = calls[i];
+            results[i] = _execute(c.target, c.value, c.data);
+        }
+    }
+
+    /// @dev Executes the `calls` and returns the result.
+    /// Reverts and bubbles up error if any call fails.
+    function _execute(address target, uint256 value, bytes calldata data)
+        internal
+        virtual
+        returns (bytes memory result)
+    {
+        bool success;
+        (success, result) = target.call{value: value}(data);
+        if (!success) {
+            /// @solidity memory-safe-assembly
+            assembly {
+                // Bubble up the revert if the call reverts.
+                revert(add(result, 0x20), mload(result))
+            }
+        }
+    }
+}
+```
+
+## Security Considerations
+
+### Access controls for `execute`
+
+Implementations should ensure that `execute` have the proper access controls.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).