From d99d8501a3febc500dba46f00619b53d68cc44ef Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Iv=C3=A1n=20M=2EM?= <32136734+ivanmmurciaua@users.noreply.github.com> Date: Sun, 7 Jan 2024 17:51:52 +0100 Subject: [PATCH 1/2] Update ERC-5216: ERC-5216 global update Merged by EIP-Bot. --- ERCS/erc-5216.md | 36 +++++++++---------- ...RC1155ApprovalByAmount.sol => ERC5216.sol} | 33 +++++++++-------- 2 files changed, 34 insertions(+), 35 deletions(-) rename assets/erc-5216/{ERC1155ApprovalByAmount.sol => ERC5216.sol} (79%) diff --git a/ERCS/erc-5216.md b/ERCS/erc-5216.md index 1e16fd4ce5..d34e1f60c8 100644 --- a/ERCS/erc-5216.md +++ b/ERCS/erc-5216.md @@ -1,7 +1,7 @@ --- eip: 5216 -title: EIP-1155 Approval By Amount Extension -description: Extension for EIP-1155 secure approvals +title: ERC-1155 Allowance Extension +description: Extension for ERC-1155 secure approvals author: Iván Mañús (@ivanmmurciaua), Juan Carlos Cantó (@EscuelaCryptoES) discussions-to: https://ethereum-magicians.org/t/eip-erc1155-approval-by-amount/9898 status: Last Call @@ -14,38 +14,38 @@ requires: 20, 165, 1155 ## Abstract -This EIP defines standard functions for granular approval of [EIP-1155](./eip-1155.md) tokens by both `id` and `amount`. This EIP extends [EIP-1155](./eip-1155.md). +This ERC defines standard functions for granular approval of [ERC-1155](./eip-1155.md) tokens by both `id` and `amount`. This ERC extends [ERC-1155](./eip-1155.md). ## Motivation -[EIP-1155](./eip-1155.md)'s popularity means that multi-token management transactions occur on a daily basis. Although it can be used as a more comprehensive alternative to [EIP-721](./eip-721.md), EIP-1155 is most commonly used as intended: creating multiple `id`s, each with multiple tokens. While many projects interface with these semi-fungible tokens, by far the most common interactions are with NFT marketplaces. +[ERC-1155](./eip-1155.md)'s popularity means that multi-token management transactions occur on a daily basis. Although it can be used as a more comprehensive alternative to [ERC-721](./eip-721.md), ERC-1155 is most commonly used as intended: creating multiple `id`s, each with multiple tokens. While many projects interface with these semi-fungible tokens, by far the most common interactions are with NFT marketplaces. -Due to the nature of the blockchain, programming errors or malicious operators can cause permanent loss of funds. It is therefore essential that transactions are as trustless as possible. EIP-1155 uses the `setApprovalForAll` function, which approves ALL tokens with a specific `id`. This system has obvious minimum required trust flaws. This EIP combines ideas from [EIP-20](./eip-20.md) and [EIP-721](./eip-721.md) in order to create a trust mechanism where an owner can allow a third party, such as a marketplace, to approve a limited (instead of unlimited) number of tokens of one `id`. +Due to the nature of the blockchain, programming errors or malicious operators can cause permanent loss of funds. It is therefore essential that transactions are as trustless as possible. ERC-1155 uses the `setApprovalForAll` function, which approves ALL tokens with a specific `id`. This system has obvious minimum required trust flaws. This ERC combines ideas from [ERC-20](./eip-20.md) and [ERC-721](./eip-721.md) in order to create a trust mechanism where an owner can allow a third party, such as a marketplace, to approve a limited (instead of unlimited) number of tokens of one `id`. ## Specification The keywords “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. -Contracts using this EIP MUST implement the `IERC1155ApprovalByAmount` interface. +Contracts using this ERC MUST implement the `IERC5216` interface. ### Interface implementation ```solidity /** - * @title ERC-1155 Approval By Amount Extension + * @title ERC-1155 Allowance Extension * Note: the ERC-165 identifier for this interface is 0x1be07d74 */ -interface IERC1155ApprovalByAmount is IERC1155 { +interface IERC5216 is IERC1155 { /** * @notice Emitted when `account` grants or revokes permission to `operator` to transfer their tokens, according to * `id` and with an amount: `amount`. */ - event ApprovalByAmount(address indexed account, address indexed operator, uint256 id, uint256 amount); + event Approval(address indexed account, address indexed operator, uint256 id, uint256 amount); /** * @notice Grants permission to `operator` to transfer the caller's tokens, according to `id`, and an amount: `amount`. - * Emits an {ApprovalByAmount} event. + * Emits an {Approval} event. * * Requirements: * - `operator` cannot be the caller. @@ -63,7 +63,7 @@ The `approve(address operator, uint256 id, uint256 amount)` function MUST be eit The `allowance(address account, address operator, uint256 id)` function MUST be either `public` or `external` and MUST be `view`. -The `safeTrasferFrom` function (as defined by EIP-1155) MUST: +The `safeTrasferFrom` function (as defined by ERC-1155) MUST: - Not revert if the user has approved `msg.sender` with a sufficient `amount` - Subtract the transferred amount of tokens from the approved amount if `msg.sender` is not approved with `setApprovalForAll` @@ -72,32 +72,32 @@ In addition, the `safeBatchTransferFrom` MUST: - Add an extra condition that checks if the `allowance` of all `ids` have the approved `amounts` (See `_checkApprovalForBatch` function reference implementation) -The `ApprovalByAmount` event MUST be emitted when a certain number of tokens are approved. +The `Approval` event MUST be emitted when a certain number of tokens are approved. The `supportsInterface` method MUST return `true` when called with `0x1be07d74`. ## Rationale -The name "EIP-1155 Approval By Amount Extension" was chosen because it is a succinct description of this EIP. Users can approve their tokens by `id` and `amount` to `operator`s. +The name "ERC-1155 Allowance Extension" was chosen because it is a succinct description of this ERC. Users can approve their tokens by `id` and `amount` to `operator`s. -By having a way to approve and revoke in a manner similar to [EIP-20](./eip-20.md), the trust level can be more directly managed by users: +By having a way to approve and revoke in a manner similar to [ERC-20](./eip-20.md), the trust level can be more directly managed by users: - Using the `approve` function, users can approve an operator to spend an `amount` of tokens for each `id`. - Using the `allowance` function, users can see the approval that an operator has for each `id`. -The [EIP-20](./eip-20.md) name patterns were used due to similarities with [EIP-20](./eip-20.md) approvals. +The [ERC-20](./eip-20.md) name patterns were used due to similarities with [ERC-20](./eip-20.md) approvals. ## Backwards Compatibility -This standard is compatible with [EIP-1155](./eip-1155.md). +This standard is compatible with [ERC-1155](./eip-1155.md). ## Reference Implementation -The reference implementation can be found [here](../assets/eip-5216/ERC1155ApprovalByAmount.sol). +The reference implementation can be found [here](../assets/eip-5216/ERC5216.sol). ## Security Considerations -Users of this EIP must thoroughly consider the amount of tokens they give permission to `operators`, and should revoke unused authorizations. +Users of this ERC must thoroughly consider the amount of tokens they give permission to `operators`, and should revoke unused authorizations. ## Copyright diff --git a/assets/erc-5216/ERC1155ApprovalByAmount.sol b/assets/erc-5216/ERC5216.sol similarity index 79% rename from assets/erc-5216/ERC1155ApprovalByAmount.sol rename to assets/erc-5216/ERC5216.sol index ee94e35458..83ddc2395b 100644 --- a/assets/erc-5216/ERC1155ApprovalByAmount.sol +++ b/assets/erc-5216/ERC5216.sol @@ -1,24 +1,24 @@ // SPDX-License-Identifier: CC0-1.0 -pragma solidity ^0.8.15; +pragma solidity ^0.8.21; import "IERC1155.sol"; import "ERC1155.sol"; /** - * @title ERC-1155 Approval By Amount Extension + * @title ERC-1155 Allowance Extension * Note: the ERC-165 identifier for this interface is 0x1be07d74 */ -interface IERC1155ApprovalByAmount is IERC1155 { +interface IERC5216 is IERC1155 { /** * @notice Emitted when `account` grants or revokes permission to `operator` to transfer their tokens, according to * `id` and with an amount: `amount`. */ - event ApprovalByAmount(address indexed account, address indexed operator, uint256 id, uint256 amount); + event Approval(address indexed account, address indexed operator, uint256 id, uint256 amount); /** * @notice Grants permission to `operator` to transfer the caller's tokens, according to `id`, and an amount: `amount`. - * Emits an {ApprovalByAmount} event. + * Emits an {Approval} event. * * Requirements: * - `operator` cannot be the caller. @@ -29,33 +29,32 @@ interface IERC1155ApprovalByAmount is IERC1155 { * @notice Returns the amount allocated to `operator` approved to transfer `account`'s tokens, according to `id`. */ function allowance(address account, address operator, uint256 id) external view returns (uint256); - } /** * @dev Extension of {ERC1155} that allows you to approve your tokens by amount and id. */ -abstract contract ERC1155ApprovalByAmount is ERC1155, IERC1155ApprovalByAmount { +abstract contract ERC5216 is ERC1155, IERC5216 { // Mapping from account to operator approvals by id and amount. mapping(address => mapping(address => mapping(uint256 => uint256))) internal _allowances; /** - * @dev See {IERC1155ApprovalByAmount} + * @dev See {IERC5216} */ function approve(address operator, uint256 id, uint256 amount) public virtual { _approve(msg.sender, operator, id, amount); } /** - * @dev See {IERC1155ApprovalByAmount} + * @dev See {IERC5216} */ function allowance(address account, address operator, uint256 id) public view virtual returns (uint256) { return _allowances[account][operator][id]; } /** - * @dev safeTransferFrom implementation for using ApprovalByAmount extension + * @dev safeTransferFrom implementation for using allowance extension */ function safeTransferFrom( address from, @@ -75,7 +74,7 @@ abstract contract ERC1155ApprovalByAmount is ERC1155, IERC1155ApprovalByAmount { } /** - * @dev safeBatchTransferFrom implementation for using ApprovalByAmount extension + * @dev safeBatchTransferFrom implementation for using allowance extension */ function safeBatchTransferFrom( address from, @@ -106,9 +105,9 @@ abstract contract ERC1155ApprovalByAmount is ERC1155, IERC1155ApprovalByAmount { uint256 idsLength = ids.length; uint256 amountsLength = amounts.length; - require(idsLength == amountsLength, "ERC1155ApprovalByAmount: ids and amounts length mismatch"); + require(idsLength == amountsLength, "ERC5216: ids and amounts length mismatch"); for (uint256 i = 0; i < idsLength;) { - require(allowance(from, to, ids[i]) >= amounts[i], "ERC1155ApprovalByAmount: operator is not approved for that id or amount"); + require(allowance(from, to, ids[i]) >= amounts[i], "ERC5216: operator is not approved for that id or amount"); unchecked { _allowances[from][to][ids[i]] -= amounts[i]; ++i; @@ -119,7 +118,7 @@ abstract contract ERC1155ApprovalByAmount is ERC1155, IERC1155ApprovalByAmount { /** * @dev Approve `operator` to operate on all of `owner` tokens by id and amount. - * Emits a {ApprovalByAmount} event. + * Emits a {Approval} event. */ function _approve( address owner, @@ -127,13 +126,13 @@ abstract contract ERC1155ApprovalByAmount is ERC1155, IERC1155ApprovalByAmount { uint256 id, uint256 amount ) internal virtual { - require(owner != operator, "ERC1155ApprovalByAmount: setting approval status for self"); + require(owner != operator, "ERC5216: setting approval status for self"); _allowances[owner][operator][id] = amount; - emit ApprovalByAmount(owner, operator, id, amount); + emit Approval(owner, operator, id, amount); } } -contract ExampleToken is ERC1155ApprovalByAmount { +contract ExampleToken is ERC5216 { constructor() ERC1155("") {} function mint(address account, uint256 id, uint256 amount, bytes memory data) public { From 69d621def1e14575854f6397d711dac4d36b212b Mon Sep 17 00:00:00 2001 From: xiang <308260887@qq.com> Date: Tue, 9 Jan 2024 00:25:35 +0800 Subject: [PATCH 2/2] Add ERC: Contract wallet management token Merged by EIP-Bot. --- ERCS/erc-7204.md | 173 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 173 insertions(+) create mode 100644 ERCS/erc-7204.md diff --git a/ERCS/erc-7204.md b/ERCS/erc-7204.md new file mode 100644 index 0000000000..08ed038ff4 --- /dev/null +++ b/ERCS/erc-7204.md @@ -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 ERC-X, and [ERC-20](./eip-20.md) is backward compatible with 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).