aitbc
816e258d4c
Development Artifact Cleanup: ✅ BROTHER_NODE REORGANIZATION: Moved development test node to appropriate location - dev/test-nodes/brother_node/: Moved from root directory for better organization - Contains development configuration, test logs, and test chain data - No impact on production systems - purely development/testing artifact ✅ DEVELOPMENT ARTIFACTS IDENTIFIED: - Chain ID: aitbc-brother-chain (test/development chain) - Ports: 8010 (P2P) and 8011 (RPC) - different from production - Environment: .env file with test configuration - Logs: rpc.log and node.log from development testing session (March 15, 2026) ✅ ROOT DIRECTORY CLEANUP: Removed development clutter from production directory - brother_node/ moved to dev/test-nodes/brother_node/ - Root directory now contains only production-ready components - Development artifacts properly organized in dev/ subdirectory DIRECTORY STRUCTURE IMPROVEMENT: 📁 dev/test-nodes/: Development and testing node configurations 🏗️ Root Directory: Clean production structure with only essential components 🧪 Development Isolation: Test environments separated from production BENEFITS: ✅ Clean Production Directory: No development artifacts in root ✅ Better Organization: Development nodes grouped in dev/ subdirectory ✅ Clear Separation: Production vs development environments clearly distinguished ✅ Maintainability: Easier to identify and manage development components RESULT: Successfully moved brother_node development artifact to dev/test-nodes/ subdirectory, cleaning up the root directory while preserving development testing environment for future use.
45 lines
1.7 KiB
Solidity
Executable File
45 lines
1.7 KiB
Solidity
Executable File
// SPDX-License-Identifier: MIT
|
|
// OpenZeppelin Contracts (last updated v5.4.0) (interfaces/draft-IERC7821.sol)
|
|
|
|
pragma solidity >=0.5.0;
|
|
|
|
/**
|
|
* @dev Interface for minimal batch executor.
|
|
*/
|
|
interface IERC7821 {
|
|
/**
|
|
* @dev Executes the calls in `executionData`.
|
|
* Reverts and bubbles up error if any call fails.
|
|
*
|
|
* `executionData` encoding:
|
|
* - If `opData` is empty, `executionData` is simply `abi.encode(calls)`.
|
|
* - Else, `executionData` is `abi.encode(calls, opData)`.
|
|
* See: https://eips.ethereum.org/EIPS/eip-7579
|
|
*
|
|
* Supported modes:
|
|
* - `bytes32(0x01000000000000000000...)`: does not support optional `opData`.
|
|
* - `bytes32(0x01000000000078210001...)`: supports optional `opData`.
|
|
*
|
|
* Authorization checks:
|
|
* - If `opData` is empty, the implementation SHOULD require that
|
|
* `msg.sender == address(this)`.
|
|
* - If `opData` is not empty, the implementation SHOULD use the signature
|
|
* encoded in `opData` to determine if the caller can perform the execution.
|
|
*
|
|
* `opData` may be used to store additional data for authentication,
|
|
* paymaster data, gas limits, etc.
|
|
*
|
|
* For calldata compression efficiency, if a Call.to is `address(0)`,
|
|
* it will be replaced with `address(this)`.
|
|
*/
|
|
function execute(bytes32 mode, bytes calldata executionData) external payable;
|
|
|
|
/**
|
|
* @dev This function is provided for frontends to detect support.
|
|
* Only returns true for:
|
|
* - `bytes32(0x01000000000000000000...)`: does not support optional `opData`.
|
|
* - `bytes32(0x01000000000078210001...)`: supports optional `opData`.
|
|
*/
|
|
function supportsExecutionMode(bytes32 mode) external view returns (bool);
|
|
}
|