diff --git a/ERCS/erc-7838.md b/ERCS/erc-7838.md new file mode 100644 index 0000000000..6eb8cc146b --- /dev/null +++ b/ERCS/erc-7838.md @@ -0,0 +1,454 @@ +--- +eip: 7838 +title: Instruction Specific Address +description: An interface for approval-less contract interactions, detaching wallets from DApps and enabling seamless CEX integration. +author: Shubham Singh (@ss-sonic) +discussions-to: https://ethereum-magicians.org/t/erc-7838-instruction-specific-address-isa/22156 +status: Draft +type: Standards Track +category: ERC +created: 2024-12-11 +--- + +## Abstract + +This EIP introduces the Instruction Specific Address (ISA) mechanism, which allows for approval-less interactions with decentralized applications (DApps) through the use of dynamically generated single-use addresses. By enabling transactions without wallet connections or approvals, ISA enhances user security, simplifies interactions, and aligns Web3 interfaces with familiar Web 2.0 paradigms. + +The ISA mechanism supports compatibility with centralized exchange (CEX) wallets and existing wallet infrastructures while ensuring a unified, blockchain-agnostic experience. It limits user risk by isolating wallets from DApps and ensures that the maximum capital at risk is only the amount transferred. This standard aims to bridge the usability gap between centralized and decentralized applications, fostering wider adoption of Web3 technologies. + +## Motivation + +The current Web3 interaction paradigm often involves complex wallet connections, approvals, and transaction signing, which introduces several challenges: + +1. **Usability Friction:** The need to connect wallets, approve transactions, and handle prompts deters mainstream users accustomed to seamless Web 2.0 experiences. +2. **Security Risks:** Wallet-DApp integration exposes users to phishing, signing hacks, and malicious contract interactions. +3. **Limited Access:** The reliance on browser wallet plugins or extensions creates barriers for users on platforms without wallet integrations. + +The Instruction Specific Address (ISA) mechanism addresses these challenges by: + +- **Approval-Less Interactions:** Allowing users to interact with DApps directly, eliminating the need for wallet approvals. +- **Wallet Isolation:** Detaching wallets from DApps to prevent phishing and tunneling attacks. +- **Centralized Exchange Integration:** Enabling transactions using wallets from centralized exchanges (CEXs). +- **Broad Accessibility:** Supporting interactions on platforms where no wallet is installed, enhancing multi-platform usability. +- **Unified Experience:** Offering a seamless, blockchain-agnostic approach that translates to Web 2.0-like product philosophies. + +By adopting ISA, the Web3 ecosystem can enhance security, improve user experience, and pave the way for broader adoption of decentralized technologies. + +## Specification + +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). + +### Glossary of Terms + +- **Instruction Specific Address (ISA):** A dynamically generated, single-use contract address designed to facilitate approval-less contract interactions. +- **CallOps:** A standardized structure defining the parameters for an ISA interaction, enabling seamless interoperability. +- **Relayer:** A participant responsible for executing ISA operations and collecting fees. +- **RefundRecipient:** An address specified by the user to receive refunds in case of failed interactions. +- **TargetAddress:** The destination contract address for the ISA operation. +- **ApprovalAddress:** The address responsible for approving token transfers, if necessary. + +### CallOps Structure + +ISA interactions MUST adhere to the standardized `CallOps` structure for compatibility and interoperability across platforms: + +```solidity +/// @title CallOps Structure +/// @notice Defines the parameters for executing an ISA operation +struct CallOps { + /// @dev The target contract address for the operation + address targetAddress; + + /// @dev Address responsible for approving token transfers, if applicable + address approvalAddress; + + /// @dev Encoded data for the transaction to execute + bytes executionData; + + /// @dev The token being transferred (use address(0) for native assets) + address sourceToken; + + /// @dev Address to receive refunds in case of failed interaction + address refundRecipient; + + /// @dev Address of the relayer responsible for execution + address relayerAddress; + + /// @dev Fee paid to the relayer for execution + uint256 relayerFee; +} +``` + +The `CallOps` structure enables consistent and interoperable ISA interactions, simplifying integration for developers. + +### Address Generation + +ISA relies on deterministic address generation using the `CREATE2` opcode. The `ISAFactory` contract MUST implement a `generateAddress` function to compute the ISA address: + +```solidity +/// @title ISAFactory Contract +/// @notice Generates deterministic ISA addresses using CREATE2 +contract ISAFactory { + function generateAddress( + bytes32 salt, + bytes memory initializationCode + ) public view returns (address) { + return address(uint160(uint256( + keccak256( + abi.encodePacked( + hex"ff", + address(this), + salt, + keccak256(initializationCode) + ) + ) + ))); + } +} +``` + +This deterministic approach ensures compatibility across applications and ecosystems. + +### Relevant Events + +ISA MUST emit the following events to signal state transitions and enhance observability: + +```solidity +/// @notice Emitted upon successful execution of the ISA +/// @param targetAddress The target contract address +/// @param amountTransferred The amount of tokens or assets transferred +event ExecutionSucceeded(address indexed relayerAddress, address indexed targetAddress, uint256 amountTransferred); + +/// @notice Emitted when an ISA execution fails +/// @param targetAddress The target contract address +/// @param reason The reason for failure +event ExecutionFailed(address indexed relayerAddress, address indexed targetAddress, string reason); + +/// @notice Emitted when a refund is issued to the specified recipient +/// @param refundRecipient The address receiving the refund +/// @param amount The amount refunded +event RefundIssued(address indexed refundRecipient, uint256 amount); +``` + +These events ensure transparency for users and developers while providing critical operational feedback. + +### Lifecycle of an ISA Interaction + +1. **Address Creation:** + + - A user requests an ISA for a specific interaction by providing necessary parameters. + - The ISAFactory generates a deterministic address using `CREATE2`. + +2. **Asset Transfer:** + + - The user sends assets (e.g., [ERC-20](./eip-20.md) tokens or native currency) to the generated ISA address. + +3. **Execution:** + + - The ISA executes the transaction using the `CallOps` parameters. + - If successful, the target contract receives the assets and executes the specified logic. + +4. **Refund Mechanism:** + + - If the transaction fails, the ISA refunds remaining assets to the specified `refundRecipient`. + +5. **Self-Destruction:** + - After execution or refund, the ISA self-destructs to free resources and ensure it cannot be reused. + +### Compliance and Integration + +- **Wallet Support:** ISA MUST support all existing wallets and enable interactions using centralized exchange (CEX) wallets. +- **Blockchain Agnosticism:** ISA MUST NOT rely on protocol-specific features, ensuring compatibility across EVM and non-EVM chains. +- **Relayer Standards:** Relayers MUST adhere to the `CallOps` structure and follow standardized execution practices. + +## Rationale + +### Approval-less Contract Interactions + +Current DApp interactions require users to connect wallets, approve transactions, and grant permissions, which introduces complexity and security vulnerabilities. ISA eliminates these steps by enabling direct, approval-less interactions, mitigating the following risks: + +- **Phishing Attacks:** ISAs isolate wallet credentials from DApps, preventing unauthorized access and signature-based exploits. +- **Wallet Tunneling:** Without wallet connections, DApps cannot tunnel into user wallets to execute unintended actions. +- **Approval-based Risks:** By removing the need for token approvals, ISA eliminates scenarios where excessive allowances are exploited. + +### Security Enhancements + +ISAs are designed with the principle of minimizing risk exposure: + +- **Limited Capital at Risk:** The maximum funds at risk in any ISA interaction are the amount transferred to the ISA. +- **Refund Mechanisms:** ISA ensures users receive refunds for any unspent or unused assets in case of transaction failure. + +### Familiar and Seamless UX + +ISA provides a Web2-like experience for Web3 interactions: + +- **Scan-and-Pay Simplicity:** Users can interact with DApps by scanning a QR code and transferring funds without wallet connections. +- **No Wallet Plugins Required:** ISA enables interactions in browsers or platforms where wallets are not installed, broadening accessibility. +- **Centralized Exchange (CEX) Compatibility:** Users can execute DApp transactions directly using CEX wallets, making the system accessible to a broader user base. + +### Interoperability and Extensibility + +- **Blockchain Agnosticism:** ISA is designed to be compatible across multiple blockchain ecosystems, ensuring no dependency on a specific protocol or network. +- **Relayer Flexibility:** The standardized `CallOps` structure ensures that ISAs are compatible with multiple relayer networks, fostering competition and innovation. +- **Protocol-Neutral Implementation:** ISA focuses on universal interaction standards and does not depend on Router Protocol or any specific bridging system. + +### Enhanced Developer Experience + +ISA simplifies DApp integration: + +- **Unified Interaction Model:** Developers can build applications that interact seamlessly with ISAs across chains and wallets. +- **Simplified State Management:** By isolating state changes to ISA contracts, DApps can reduce complexity in managing user interactions. + +### Resilience to Edge Cases + +ISAs address potential failure scenarios: + +- **Data Availability Layers:** To mitigate the risk of lost data used for address generation, ISAs can leverage data availability (DA) layers to persist and retrieve the required data. +- **Refund Fallbacks:** In case of incorrect or unreachable `refundRecipient` addresses, ISA reverts the refund to the sender, ensuring user funds are not lost. + +### Alignment with Payment and Product Philosophies + +ISA embodies a payment-first approach: + +- **First CTA is Action, Not Wallet Connection:** Users are encouraged to engage with the DApp's functionality first, removing the "connect wallet" barrier. +- **Unified Chain Experience:** By decoupling wallet requirements, ISA creates a consistent and seamless experience across platforms and ecosystems. + +### Compatibility with Existing Standards + +ISA is designed to align with and complement existing Ethereum standards: + +- **[EIP-7683](./eip-7683.md) (Cross-Chain Intents):** ISA supports interaction paradigms that abstract user intent across chains. +- **Broad Compatibility:** ISA ensures that its features are generic and protocol-agnostic, allowing integration with future standards. + +Let me know if this meets your expectations or if further elaboration is needed! If all is good, we can proceed to the next section. + +## Backwards Compatibility + +The Instruction Specific Address (ISA) mechanism is designed to be compatible with existing Ethereum infrastructure while introducing novel interaction paradigms. Below are the considerations for backward compatibility: + +### Wallet Compatibility + +- **Existing Wallets:** ISA supports all existing wallets that comply with ERC-20 and native token standards. Users can utilize their current wallets to interact with ISAs without requiring additional configuration or updates. +- **Centralized Exchange (CEX) Wallets:** ISA enables seamless interaction using CEX wallets, expanding the scope of wallet compatibility beyond traditional self-custodial solutions. + +### Contract Interactions + +- **Target Contracts:** ISAs can interact with any existing smart contracts. However, target contracts SHOULD NOT rely on `msg.sender` for critical state ownership, as the ISA contract will be the `msg.sender` during execution. +- **Standard Token Contracts:** ISA supports all ERC-20 tokens and native assets. Token approval mechanisms are replaced with direct transfers managed within the ISA lifecycle. + +### Deterministic Address Generation + +The `CREATE2` opcode ensures deterministic address generation for ISAs, providing compatibility with any system that supports this opcode. This approach maintains consistency across deployments and eliminates conflicts with existing address schemes. + +### Event Logging and Observability + +ISA introduces new events to enhance transparency and enable developers to track interactions efficiently. These events are additive and do not interfere with existing event structures used by other standards. + +### Cross-Chain Compatibility + +While primarily focused on EVM-based chains, ISA’s protocol-neutral implementation ensures that it can be extended to non-EVM ecosystems. Its reliance on generic terms and abstraction layers allows for interoperability across diverse blockchain environments. + +### Non-Disruptive Integration + +ISA is an opt-in mechanism that does not impose changes on existing systems. DApps and developers can integrate ISA without modifying their existing contract logic, ensuring a smooth transition and adoption process. + +## Reference Implementation + +This section provides a reference implementation of the Instruction Specific Address (ISA) mechanism. The implementation includes key contracts to demonstrate the address generation, transaction processing, and event emission capabilities of ISAs. + +### ISAFactory Contract + +The `ISAFactory` contract generates deterministic ISA addresses using the `CREATE2` opcode and emits events for transparency. + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.0; + +/// @title ISAFactory +/// @notice Generates deterministic ISA addresses using CREATE2 +contract ISAFactory { + + /// @notice Generates a deterministic ISA address + /// @param salt A unique value to differentiate addresses + /// @param initializationCode The bytecode of the ISA + /// @return address The generated ISA address + function generateAddress( + bytes32 salt, + bytes memory initializationCode + ) public view returns (address) { + address generatedAddress = address(uint160(uint256( + keccak256( + abi.encodePacked( + hex"ff", + address(this), + salt, + keccak256(initializationCode) + ) + ) + ))); + + return generatedAddress; + } +} +``` + +### DepositReceiver Contract + +The `DepositReceiver` contract handles transactions for ISAs, processes user-defined logic, and emits events for transaction completion or failure. + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.0; + +/// @title DepositReceiver +/// @notice A temporary contract for processing ISA transactions +contract DepositReceiver { + + constructor(bytes memory executionData, address refundRecipient) payable { + bool success; + (success, ) = msg.sender.delegatecall(executionData); + + if (!success) { + // Emit event for failed transaction + + // Revert with the original error data + assembly { + let ptr := mload(0x40) + let size := returndatasize() + returndatacopy(ptr, 0, size) + revert(ptr, size) + } + } + + + if (refundRecipient == address(0)) { + refundRecipient = msg.sender; + } + selfdestruct(payable(refundRecipient)); + } + + /// @dev This function allows the contract to accept Ether + receive() external payable {} +} +``` + +### Execution Contract + +The `ExecutionContract` processes and forwards ISA transactions, ensuring transparency by emitting events for all state changes. + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.0; + +import 'lib/openzeppelin-contracts/contracts/token/ERC20/IERC20.sol'; + +/// @title ExecutionContract +/// @notice Handles transaction processing and asset forwarding for ISAs +contract ExecutionContract { + struct CallOps { + address targetAddress; + address approvalAddress; + bytes executionData; + address sourceToken; + address refundRecipient; + address relayerAddress; + uint256 relayerFee; + } + + /// @notice Emitted upon successful execution of the ISA + /// @param relayerAddress The relayer's address handling the transaction + /// @param targetAddress The target contract address + /// @param amountTransferred The amount of tokens or assets transferred + event ExecutionSucceeded(address indexed relayerAddress, address indexed targetAddress, uint256 amountTransferred); + + /// @notice Emitted when an ISA execution fails + /// @param relayerAddress The relayer's address handling the transaction + /// @param targetAddress The target contract address + /// @param reason The reason for failure + event ExecutionFailed(address indexed relayerAddress, address indexed targetAddress, string reason); + + /// @notice Emitted when a refund is issued to the specified recipient + /// @param refundRecipient The address receiving the refund + /// @param amount The amount refunded + event RefundIssued(address indexed refundRecipient, uint256 amount); + + /// @notice Processes ISA transactions + /// @param callOps Encoded call operation parameters + function processCallOps(CallOps calldata callOps) external payable { + uint256 amount = msg.value; + + // Check if the token is ERC20 or native asset + if (callOps.sourceToken != address(0)) { + amount = IERC20(callOps.sourceToken).balanceOf(address(this)); + IERC20(callOps.sourceToken).approve(callOps.approvalAddress, amount); + } + + // Try executing the call + (bool success, bytes memory returnData) = callOps.targetAddress.call{ value: amount }(callOps.executionData); + + if (success) { + // Emit event for successful execution + emit ExecutionSucceeded(callOps.relayerAddress, callOps.targetAddress, amount); + } else { + // Emit event for execution failure + string memory reason = _getRevertReason(returnData); + emit ExecutionFailed(callOps.relayerAddress, callOps.targetAddress, reason); + + // Handle refunds on failure + if (callOps.refundRecipient != address(0)) { + if (callOps.sourceToken != address(0)) { + IERC20(callOps.sourceToken).transfer(callOps.refundRecipient, amount); + } else { + payable(callOps.refundRecipient).transfer(amount); + } + emit RefundIssued(callOps.refundRecipient, amount); + } + } + } + + /// @dev Decodes the revert reason from the returned data + /// @param returnData The data returned from the failed call + /// @return reason The decoded revert reason string + function _getRevertReason(bytes memory returnData) internal pure returns (string memory reason) { + if (returnData.length < 68) return "Transaction failed without a reason"; + + assembly { + returnData := add(returnData, 0x04) + reason := mload(returnData) + } + } + + /// @dev This function allows the contract to accept Ether + receive() external payable {} +} +``` + +## Security Considerations + +#### Evaluating ISA Contract Security + +This ERC is agnostic of how the Instruction Specific Address (ISA) mechanism validates and processes interactions, including refunds and transaction execution. The security of the ISA contract's lifecycle, from creation to execution and self-destruction, is delegated to developers implementing the standard and the applications utilizing it. + +This design decision allows flexibility in implementation, accommodating diverse use cases while ensuring ISA remains adaptable across ecosystems. However, it also places the responsibility of contract auditing, relayer integrity, and event observability on developers and integrators. + +#### Leveraging Deterministic Address Generation + +- The use of `CREATE2` ensures deterministic address generation, allowing for predictable and verifiable ISA deployment. +- Developers are responsible for ensuring that initialization parameters (e.g., salts and bytecode) are unique and immutable to avoid address collisions. + +#### Safeguards Against Misuse + +- The maximum capital exposed is limited to the assets explicitly transferred to the ISA, significantly reducing user risk. +- Refund logic ensures unspent funds are returned to the specified `refundRecipient`. + +#### Dependency on Relayers + +- Developers and relayers must adhere to the `CallOps` structure to maintain transaction integrity and prevent misuse of execution parameters. +- Transparency is ensured through event emission, enabling continuous monitoring of relayer activities and transaction states. + +#### Compatibility with Target Contracts + +- ISAs rely on target contracts being agnostic to `msg.sender` for critical state changes. Developers of target contracts must ensure compatibility with this interaction model. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md).