forked from ethereum/ERCs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
3 changed files
with
207 additions
and
35 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,173 @@ | ||
| --- | ||
| eip: 7204 | ||
| title: Contract wallet management token | ||
| description: Focuses on fungible token management within smart contract wallets, offering enhanced transaction flexibility and security | ||
| author: Xiang (@wenzhenxiang), Ben77 (@ben2077), Mingshi S. (@newnewsms) | ||
| discussions-to: https://ethereum-magicians.org/t/token-asset-management-interface-with-smart-contract-wallet/14759 | ||
| status: Draft | ||
| type: Standards Track | ||
| category: ERC | ||
| created: 2023-06-21 | ||
| requires: 165 | ||
| --- | ||
|
|
||
| ## Abstract | ||
|
|
||
| This proposal introduces a smart contract wallet-based approach for managing tokens, focusing on utilizing the programmable features of smart contract wallets for asset management. | ||
| Additionally, it introduces functions such as `tokenTransfer`, `tokenApprove`, `tokenApproveForAll`, `tokenIsApproveForAll` and `tokenAllowance`, which provide enhanced control over token transactions. This approach seeks to enhance token management by utilizing the built-in features of smart contract wallets, thus offering a more adaptable, secure, and efficient method for managing token transactions. | ||
|
|
||
|
|
||
| ## Motivation | ||
|
|
||
| An externally-owned account (EOA) wallet has no state and code storage, while the smart contract wallet does. | ||
|
|
||
| Account abstraction (AA) is a direction of the smart contract wallet, which works around abstract accounts. This ERC can also be an extension based on [ERC-4337](./eip-4337.md) or as a plug-in for wallets. | ||
|
|
||
| The smart contract wallet allows the user's own account to have state and code, bringing programmability to the wallet. We think there are more directions to expand. For example, token asset management, functional expansion of token transactions, etc. | ||
|
|
||
| The smart contract wallet interface of this ERC is for asset management and asset approval. It supports the simpletoken <!-- TODO --> ERC-X, and [ERC-20](./eip-20.md) is backward compatible with <!-- TODO --> ERC-X, so it can be compatible with the management of all fungible tokens in the existing market. | ||
|
|
||
| The proposal aims to achieve the following goals: | ||
|
|
||
| 1. Assets are allocated and managed by the wallet itself, such as `approve` and `allowance`, which are configured by the user’s contract wallet, rather than controlled by the token asset contract, to avoid some existing ERC-20 contract risks. | ||
| 2. Add the `tokenTransfer` function, the transaction initiated by the non-smart wallet itself or will verify the allowance amount. | ||
| 3. Add `tokenApprove`, `tokenAllowance`, `tokenApproveForAll`, `tokenIsApproveForAll` functions. The user wallet itself supports approve and provides approve. | ||
| for single token assets and all token assets. | ||
| 4. user wallet can choose batch approve and batch transfer. | ||
| 5. Users can choose to add hook function before and after their `tokenTransfer` to increase the user's more playability. | ||
| 6. The user can choose to implement the `tokenReceive` function. | ||
|
|
||
|
|
||
| ## 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. | ||
|
|
||
| ** Compliant contract must implement the [ERC-165](./eip-165.md) interfaces** | ||
|
|
||
| ```solidity | ||
| /// @title ERC-7204 | ||
| /// @dev See https://eips.ethereum.org/EIPS/eip-7204 | ||
| /// @dev Note: the ERC-165 identifier for this interface is 0xf73edcda | ||
| pragma solidity ^0.8.20; | ||
| interface IERC7204 /* is ERC165 */ { | ||
| /** | ||
| * @notice Used to notify listeners that owner has granted approval to the user to manage assets tokens. | ||
| * @param asset Address of the token | ||
| * @param owner Address of the account that has granted the approval for token‘s assets | ||
| * @param spender Address of the spender | ||
| * @param value The amount allowed to spend | ||
| */ | ||
| event TokenApproval( | ||
| address indexed asset, | ||
| address indexed owner, | ||
| address indexed spender, | ||
| uint256 value | ||
| ); | ||
| /** | ||
| * @notice Used to notify listeners that owner has granted approval to the spender to manage all token . | ||
| * @param asset Address of the token | ||
| * @param owner Address of the account that has granted the approval for token‘s assets | ||
| * @param approved approve all token | ||
| */ | ||
| event TokenApprovalForAll( | ||
| address indexed owner, | ||
| address indexed spender, | ||
| bool approved | ||
| ); | ||
| /** | ||
| * @notice Approve token | ||
| * @dev Allows spender address to withdraw from your account multiple times, up to the value amount. | ||
| * @dev If this function is called again it overwrites the current allowance with value. | ||
| * @dev Emits an {TokenApproval} event. | ||
| * @param asset Address of the token | ||
| * @param spender Address of the spender | ||
| * @param value The amount allowed to spend | ||
| * @return success The bool value returns whether the approve is successful | ||
| */ | ||
| function tokenApprove(address asset, address spender, uint256 value) | ||
| external | ||
| returns (bool success); | ||
| /** | ||
| * @notice read token allowance value | ||
| * @param asset Address of the token | ||
| * @param spender Address of the spender | ||
| * @return remaining The asset amount which spender is still allowed to withdraw from owner. | ||
| */ | ||
| function tokenAllowance(address asset, address spender) | ||
| external | ||
| view | ||
| returns (uint256 remaining); | ||
| /** | ||
| * @notice Approve all token | ||
| * @dev Allows spender address to withdraw from your wallet all token. | ||
| * @dev Emits an {TokenApprovalForAll} event. | ||
| * @param spender Address of the spender | ||
| * @param approved Approved all tokens | ||
| * @return success The bool value returns whether the approve is successful | ||
| */ | ||
| function tokenApproveForAll(address spender, bool approved) | ||
| external | ||
| returns (bool success); | ||
| /** | ||
| * @notice read spender approved value | ||
| * @param spender Address of the spender | ||
| * @return approved Whether to approved spender all tokens | ||
| */ | ||
| function tokenIsApproveForAll(address spender) | ||
| external | ||
| view | ||
| returns (bool approved); | ||
| /** | ||
| * @notice Transfer token | ||
| * @dev must call asset.transfer() inside the function | ||
| * @dev If the caller is not wallet self, must verify the allowance and update the allowance value | ||
| * @param asset Address of the token | ||
| * @param to Address of the receive | ||
| * @param value The transaction amount | ||
| * @return success The bool value returns whether the transfer is successful | ||
| */ | ||
| function tokenTransfer(address asset, address to, uint256 value) | ||
| external | ||
| returns (bool success); | ||
| } | ||
| ``` | ||
|
|
||
|
|
||
| ## Rationale | ||
|
|
||
| the key technical decisions in this proposal are: | ||
|
|
||
| **Improved Approve Mechanism** | ||
| - **Current vs. Proposed**: In the existing ERC-20 system, an externally-owned account (EOA) directly interacts with token contracts to `approve`. The new `tokenApprove` and `tokenApproveForAll` functions in this proposed enable more precise control over token usage within a wallet contract, a significant improvement over the traditional method. | ||
| - **Enhanced Security**: This mechanism mitigates risks like token over-approval by shifting approval control to the user's smart contract wallet. | ||
| - **Programmability**: Users gain the ability to set advanced approval strategies, such as conditional or time-limited approvals, the `tokenApproveForAll` function specifically allows for a universal setting all tokens. these were not possible with traditional ERC-20 tokens. | ||
|
|
||
| **Optimized Transfer Process** | ||
| - **Efficiency and Security**: The `tokenTransfer` function streamlines the token transfer process, making transactions both more efficient and secure. | ||
| - **Flexibility**: Allows the integration of custom logic (hooks) before and after transfers, enabling additional security checks or specific actions tailored to the user’s needs. | ||
|
|
||
| **Support for Batch Operations** | ||
| - **Increased Efficiency**: Users can simultaneously handle multiple `approve` or `transfer` operations, significantly boosting transaction efficiency. | ||
| - **Enhanced User Experience**: Simplifies the management of numerous assets, improving the overall experience for users with large portfolios. | ||
|
|
||
|
|
||
|
|
||
| ## Backwards Compatibility | ||
|
|
||
| This ERC can be used as an extension of [ERC-4337](./eip-4337.md) and is backward compatible with ERC-4337. | ||
|
|
||
| ## Security Considerations | ||
|
|
||
| No security considerations were found. | ||
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via [CC0](../LICENSE.md). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters