From b32a8a2283b295b001d598a9b85bdf3efcd33248 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 01:50:36 +0400 Subject: [PATCH 01/61] Add EIP 223: Token standard with event handling implementation --- EIPS/eip-223.md | 153 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+) create mode 100644 EIPS/eip-223.md diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md new file mode 100644 index 00000000000000..699009169accf6 --- /dev/null +++ b/EIPS/eip-223.md @@ -0,0 +1,153 @@ +--- +eip: 223 +title: Token Standard +author: Dexaran +type: Standards Track +category: ERC +status: Review +created: 2017-5-03 +--- + +## Simple Summary + +A standard interface for tokens with definition of `communication model` logic. + +## Abstract + +The following describes standard functions a token contract and contract working with specified token can implement. This standard introduces a communication model which allows for the implementation of [event handling](https://en.wikipedia.org/wiki/Event_(computing)) on the receiver's side. + +## Motivation + +This standard introduces a communication model by enforcing the `transfer` to execute a handler function in the destination address. This is an important security consideration as it is required that the receiver explicitly implements the token handling function. In cases where the receiver does not implements such function the transfer MUST be reverted. + +This standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, ERC223 transfers are more gas-efficient while dealing with depositing to contracts as ERC223 tokens can be deposited with just one transaction while ERC20 tokens require at least two calls (one for `approve` and the second that will invoke `transferFrom`). + +- ERC20 deposit: `approve` ~53K gas, `transferFrom` ~80K gas + +- ERC223 deposit: `transfer` and handling on the receivers side ~46K gas + +This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipient side and reject incorrect or improper transactions. This tokens utilize ONE transferring method for both types of interactions with tokens and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes. + +One downside of the commonly used ERC20 standard that ERC223 is intended to solve is that ERC20 implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of ERC20 standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. + +ERC223 standard is intended to simplify the interaction with contracts that are intended to work with tokens. ERC223 utilizes "deposit" pattern similar to plain Ether depositing patterns - in case of ERC223 deposit to the contract a user or a UI must simply send the tokens with the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. + +This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an Ether transaction, or allow for public loggin on chain should it be necessary for financial transactions. + +## Specification + +Token +Contracts that works with tokens + +## Methods + +NOTE: An important point is that contract developers must implement `tokenReceived` if they want their contracts to work with the specified tokens. + +If the receiver does not implement the `tokenReceived` function, consider the contract is not designed to work with tokens, then the transaction must fail and no tokens will be transferred. An analogy with an Ether transaction that is failing when trying to send Ether to a contract that did not implement `function() payable`. + + +#### totalSupply + +```js +function totalSupply() constant returns (uint256 totalSupply) +``` +Get the total token supply + +#### name + +```js +function name() constant returns (string _name) +``` +Get the name of token + +#### symbol + +```js +function symbol() constant returns (bytes32 _symbol) +``` +Get the symbol of token + +#### decimals + +```js +function decimals() constant returns (uint8 _decimals) +``` +Get decimals of token + +#### standard + +```js +function standard() constant returns (string _standard) +``` +Get the standard of token contract. For some services it is important to know how to treat this particular token. If token supports ERC223 standard then it must explicitly tell that it does. + +This function **MUST** return "erc223" for this token standard. If no "standard()" function is implemented in the contract then the contract must be considered to be ERC20. + +#### balanceOf + +```js +function balanceOf(address _owner) constant returns (uint256 balance) +``` +Get the account balance of another account with address _owner + + +#### transfer(address, uint) + +```js +function transfer(address _to, uint _value) returns (bool) +``` + +Needed due to backwards compatibility reasons because of ERC20 transfer function doesn't have `bytes` parameter. This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in ` _to` (receiver contract), then the transaction must fail and the transfer of tokens should be reverted. + +#### transfer(address, uint, bytes) + +```js +function transfer(address _to, uint _value, bytes calldata _data) returns (bool) +``` +function that is always called when someone wants to transfer tokens. +This function must transfer tokens and invoke the function `tokenReceived (address, uint256, bytes)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in ` _to` (receiver contract), then the transaction must fail and the transfer of tokens should not occur. +If `_to` is an externally owned address, then the transaction must be sent without trying to execute ` tokenReceived` in `_to`. + `_data` can be attached to this token transaction and it will stay in blockchain forever (requires more gas). `_data` can be empty. + +NOTE: The recommended way to check whether the `_to` is a contract or an address is to assemble the code of ` _to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. + +## Events + +#### Transfer + +```js +event Transfer(address indexed _from, address indexed _to, uint256 _value) +``` + +Triggered when tokens are transferred. Compatible with ERC20 `Transfer` event. + +#### TransferData + +```js +event TransferData(bytes _data) +``` + +Triggered when tokens are transferred and logs transaction metadata. This is implemented as a separate event to keep `Transfer(address, address, uint256)` ERC20-compatible. + +## Contract that is intended to receive ERC223 tokens + +```js +function tokenReceived(address _from, uint _value, bytes calldata _data) +``` +A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token,` _value` is the amount of incoming tokens, and `_data` is attached data similar to` msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. + +NOTE: since solidity version 0.6.0+ there is a new `reveive()` function to handle plain Ether transfers - therefore the function `tokenFallback` was renamed to `tokenReceived` to keep the token behavior more intuitive and compatible with Ether behavior. + +NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the` tokenReceived` function. + +IMPORTANT: This function must be named `tokenReceived` and take parameters` address`, `uint256`,` bytes` to match the [function signature](https://www.4byte.directory/signatures/?bytes4_signature=0xc0ee0b8a) `0xc0ee0b8a`. + +## Reference implementation +This is highly recommended implementation of ERC 223 token: https://github.com/Dexaran/ERC223-token-standard/tree/development/token/ERC223 + +## History + +- original issue: https://github.com/ethereum/EIPs/issues/223 + +## Copyright +Copyright and related rights waived via [CC0](../LICENSE.md). From 09f387991ac6847539a5423e2a32ee795e0b40a6 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 02:37:31 +0400 Subject: [PATCH 02/61] Update eip-223.md --- EIPS/eip-223.md | 68 ++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 56 insertions(+), 12 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 699009169accf6..1b22fa0a36b8f9 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -1,11 +1,13 @@ --- eip: 223 -title: Token Standard -author: Dexaran +title: ERC-223 Token +description: Token with event handling and communication model +author: Dexaran (@Dexaran) +discussions-to: https://github.com/ethereum/EIPs/issues/223 +status: Review type: Standards Track category: ERC -status: Review -created: 2017-5-03 +created: 2017-05-03 --- ## Simple Summary @@ -18,19 +20,25 @@ The following describes standard functions a token contract and contract working ## Motivation +1. This token introduces a communication model for contracts that can be utilized to straighten the behavior of contracts that interact with tokens as opposed to ERC-20 where a token transfer could be ignored by the receiving contract. +2. This token is more gas-efficient when depositing tokens to contracts. +3. This token allows for `_data` recording for financial transfers. + +## Rationale + This standard introduces a communication model by enforcing the `transfer` to execute a handler function in the destination address. This is an important security consideration as it is required that the receiver explicitly implements the token handling function. In cases where the receiver does not implements such function the transfer MUST be reverted. This standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, ERC223 transfers are more gas-efficient while dealing with depositing to contracts as ERC223 tokens can be deposited with just one transaction while ERC20 tokens require at least two calls (one for `approve` and the second that will invoke `transferFrom`). -- ERC20 deposit: `approve` ~53K gas, `transferFrom` ~80K gas +- ERC-20 deposit: `approve` ~53K gas, `transferFrom` ~80K gas -- ERC223 deposit: `transfer` and handling on the receivers side ~46K gas +- ERC-223 deposit: `transfer` and handling on the receivers side ~46K gas This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipient side and reject incorrect or improper transactions. This tokens utilize ONE transferring method for both types of interactions with tokens and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes. -One downside of the commonly used ERC20 standard that ERC223 is intended to solve is that ERC20 implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of ERC20 standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. +One downside of the commonly used ERC-20 standard that ERC-223 is intended to solve is that ERC-20 implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of ERC20 standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. -ERC223 standard is intended to simplify the interaction with contracts that are intended to work with tokens. ERC223 utilizes "deposit" pattern similar to plain Ether depositing patterns - in case of ERC223 deposit to the contract a user or a UI must simply send the tokens with the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. +ERC223 standard is intended to simplify the interaction with contracts that are intended to work with tokens. ERC-223 utilizes "deposit" pattern similar to plain Ether depositing patterns - in case of ERC-223 deposit to the contract a user or a UI must simply send the tokens with the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an Ether transaction, or allow for public loggin on chain should it be necessary for financial transactions. @@ -39,7 +47,7 @@ This standard allows payloads to be attached to transactions using the `bytes ca Token Contracts that works with tokens -## Methods +### Methods NOTE: An important point is that contract developers must implement `tokenReceived` if they want their contracts to work with the specified tokens. @@ -49,36 +57,51 @@ If the receiver does not implement the `tokenReceived` function, consider the co #### totalSupply ```js + function totalSupply() constant returns (uint256 totalSupply) + ``` + Get the total token supply #### name ```js + function name() constant returns (string _name) + ``` + Get the name of token #### symbol ```js + function symbol() constant returns (bytes32 _symbol) + ``` + Get the symbol of token #### decimals ```js + function decimals() constant returns (uint8 _decimals) + ``` + Get decimals of token #### standard ```js + function standard() constant returns (string _standard) + ``` + Get the standard of token contract. For some services it is important to know how to treat this particular token. If token supports ERC223 standard then it must explicitly tell that it does. This function **MUST** return "erc223" for this token standard. If no "standard()" function is implemented in the contract then the contract must be considered to be ERC20. @@ -86,15 +109,20 @@ This function **MUST** return "erc223" for this token standard. If no "standard( #### balanceOf ```js + function balanceOf(address _owner) constant returns (uint256 balance) + ``` + Get the account balance of another account with address _owner #### transfer(address, uint) ```js + function transfer(address _to, uint _value) returns (bool) + ``` Needed due to backwards compatibility reasons because of ERC20 transfer function doesn't have `bytes` parameter. This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in ` _to` (receiver contract), then the transaction must fail and the transfer of tokens should be reverted. @@ -102,8 +130,11 @@ Needed due to backwards compatibility reasons because of ERC20 transfer function #### transfer(address, uint, bytes) ```js + function transfer(address _to, uint _value, bytes calldata _data) returns (bool) + ``` + function that is always called when someone wants to transfer tokens. This function must transfer tokens and invoke the function `tokenReceived (address, uint256, bytes)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in ` _to` (receiver contract), then the transaction must fail and the transfer of tokens should not occur. If `_to` is an externally owned address, then the transaction must be sent without trying to execute ` tokenReceived` in `_to`. @@ -111,12 +142,14 @@ If `_to` is an externally owned address, then the transaction must be sent witho NOTE: The recommended way to check whether the `_to` is a contract or an address is to assemble the code of ` _to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. -## Events +### Events #### Transfer ```js + event Transfer(address indexed _from, address indexed _to, uint256 _value) + ``` Triggered when tokens are transferred. Compatible with ERC20 `Transfer` event. @@ -124,7 +157,9 @@ Triggered when tokens are transferred. Compatible with ERC20 `Transfer` event. #### TransferData ```js + event TransferData(bytes _data) + ``` Triggered when tokens are transferred and logs transaction metadata. This is implemented as a separate event to keep `Transfer(address, address, uint256)` ERC20-compatible. @@ -132,19 +167,28 @@ Triggered when tokens are transferred and logs transaction metadata. This is imp ## Contract that is intended to receive ERC223 tokens ```js + function tokenReceived(address _from, uint _value, bytes calldata _data) + ``` -A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token,` _value` is the amount of incoming tokens, and `_data` is attached data similar to` msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. -NOTE: since solidity version 0.6.0+ there is a new `reveive()` function to handle plain Ether transfers - therefore the function `tokenFallback` was renamed to `tokenReceived` to keep the token behavior more intuitive and compatible with Ether behavior. +A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token,` _value` is the amount of incoming tokens, and `_data` is attached data similar to` msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the` tokenReceived` function. IMPORTANT: This function must be named `tokenReceived` and take parameters` address`, `uint256`,` bytes` to match the [function signature](https://www.4byte.directory/signatures/?bytes4_signature=0xc0ee0b8a) `0xc0ee0b8a`. + +## Security Considerations + +This token utilizes the model similar to plain Ether behavior. Therefore replay issues must be taken into account. + + ## Reference implementation + This is highly recommended implementation of ERC 223 token: https://github.com/Dexaran/ERC223-token-standard/tree/development/token/ERC223 + ## History - original issue: https://github.com/ethereum/EIPs/issues/223 From 4c6e49dd24f4c5126888972702f297836e8598ef Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 02:48:09 +0400 Subject: [PATCH 03/61] Update eip-223.md --- EIPS/eip-223.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 1b22fa0a36b8f9..b175ce0727922c 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -1,9 +1,9 @@ --- eip: 223 -title: ERC-223 Token +title: 223 Token with communication model description: Token with event handling and communication model -author: Dexaran (@Dexaran) -discussions-to: https://github.com/ethereum/EIPs/issues/223 +author: Dexaran (@Dexaran), +discussions-to: https://ethereum-magicians.org/t/erc-223-token-standard/12894 status: Review type: Standards Track category: ERC @@ -176,7 +176,7 @@ A function for handling token transfers, which is called from the token contract NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the` tokenReceived` function. -IMPORTANT: This function must be named `tokenReceived` and take parameters` address`, `uint256`,` bytes` to match the [function signature](https://www.4byte.directory/signatures/?bytes4_signature=0xc0ee0b8a) `0xc0ee0b8a`. +IMPORTANT: This function must be named `tokenReceived` and take parameters` address`, `uint256`,` bytes` to match the function signature `0xc0ee0b8a`. ## Security Considerations @@ -194,4 +194,4 @@ This is highly recommended implementation of ERC 223 token: https://github.com/D - original issue: https://github.com/ethereum/EIPs/issues/223 ## Copyright -Copyright and related rights waived via [CC0](../LICENSE.md). +Copyright and related rights waived via CC0. From 337c7a029c11504f32136339d4acf6b352413957 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 02:53:39 +0400 Subject: [PATCH 04/61] Update eip-223.md --- EIPS/eip-223.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index b175ce0727922c..85646349988dec 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -2,7 +2,7 @@ eip: 223 title: 223 Token with communication model description: Token with event handling and communication model -author: Dexaran (@Dexaran), +author: Dexaran (@Dexaran) discussions-to: https://ethereum-magicians.org/t/erc-223-token-standard/12894 status: Review type: Standards Track @@ -16,7 +16,7 @@ A standard interface for tokens with definition of `communication model` logic. ## Abstract -The following describes standard functions a token contract and contract working with specified token can implement. This standard introduces a communication model which allows for the implementation of [event handling](https://en.wikipedia.org/wiki/Event_(computing)) on the receiver's side. +The following describes standard functions a token contract and contract working with specified token can implement. This standard introduces a communication model which allows for the implementation of **event handling** on the receiver's side. ## Motivation @@ -36,9 +36,9 @@ This standard sticks to the push transaction model where the transfer of assets This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipient side and reject incorrect or improper transactions. This tokens utilize ONE transferring method for both types of interactions with tokens and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes. -One downside of the commonly used ERC-20 standard that ERC-223 is intended to solve is that ERC-20 implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of ERC20 standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. +One downside of the commonly used [ERC-20](https://github.com/ethereum/EIPs/issues/20) standard that [ERC-223](https://github.com/ethereum/EIPs/issues/223) is intended to solve is that [ERC-20](https://github.com/ethereum/EIPs/issues/20) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](https://github.com/ethereum/EIPs/issues/20) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. -ERC223 standard is intended to simplify the interaction with contracts that are intended to work with tokens. ERC-223 utilizes "deposit" pattern similar to plain Ether depositing patterns - in case of ERC-223 deposit to the contract a user or a UI must simply send the tokens with the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. +ERC223 standard is intended to simplify the interaction with contracts that are intended to work with tokens. [ERC-223](https://github.com/ethereum/EIPs/issues/223) utilizes "deposit" pattern similar to plain Ether depositing patterns - in case of [ERC-223](https://github.com/ethereum/EIPs/issues/223) deposit to the contract a user or a UI must simply send the tokens with the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an Ether transaction, or allow for public loggin on chain should it be necessary for financial transactions. From f3563ba15ee01007864cc9a70dd2e43461c2cf1c Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 02:59:51 +0400 Subject: [PATCH 05/61] Update eip-223.md --- EIPS/eip-223.md | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 85646349988dec..15986da5a625fc 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -24,23 +24,6 @@ The following describes standard functions a token contract and contract working 2. This token is more gas-efficient when depositing tokens to contracts. 3. This token allows for `_data` recording for financial transfers. -## Rationale - -This standard introduces a communication model by enforcing the `transfer` to execute a handler function in the destination address. This is an important security consideration as it is required that the receiver explicitly implements the token handling function. In cases where the receiver does not implements such function the transfer MUST be reverted. - -This standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, ERC223 transfers are more gas-efficient while dealing with depositing to contracts as ERC223 tokens can be deposited with just one transaction while ERC20 tokens require at least two calls (one for `approve` and the second that will invoke `transferFrom`). - -- ERC-20 deposit: `approve` ~53K gas, `transferFrom` ~80K gas - -- ERC-223 deposit: `transfer` and handling on the receivers side ~46K gas - -This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipient side and reject incorrect or improper transactions. This tokens utilize ONE transferring method for both types of interactions with tokens and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes. - -One downside of the commonly used [ERC-20](https://github.com/ethereum/EIPs/issues/20) standard that [ERC-223](https://github.com/ethereum/EIPs/issues/223) is intended to solve is that [ERC-20](https://github.com/ethereum/EIPs/issues/20) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](https://github.com/ethereum/EIPs/issues/20) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. - -ERC223 standard is intended to simplify the interaction with contracts that are intended to work with tokens. [ERC-223](https://github.com/ethereum/EIPs/issues/223) utilizes "deposit" pattern similar to plain Ether depositing patterns - in case of [ERC-223](https://github.com/ethereum/EIPs/issues/223) deposit to the contract a user or a UI must simply send the tokens with the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. - -This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an Ether transaction, or allow for public loggin on chain should it be necessary for financial transactions. ## Specification @@ -179,6 +162,25 @@ NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. IMPORTANT: This function must be named `tokenReceived` and take parameters` address`, `uint256`,` bytes` to match the function signature `0xc0ee0b8a`. +## Rationale + +This standard introduces a communication model by enforcing the `transfer` to execute a handler function in the destination address. This is an important security consideration as it is required that the receiver explicitly implements the token handling function. In cases where the receiver does not implements such function the transfer MUST be reverted. + +This standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-223.md) transfers are more gas-efficient while dealing with depositing to contracts as [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-223.md) tokens can be deposited with just one transaction while ERC20 tokens require at least two calls (one for `approve` and the second that will invoke `transferFrom`). + +- [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) deposit: `approve` ~53K gas, `transferFrom` ~80K gas + +- [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) deposit: `transfer` and handling on the receivers side ~46K gas + +This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipient side and reject incorrect or improper transactions. This tokens utilize ONE transferring method for both types of interactions with tokens and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes. + +One downside of the commonly used [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) standard that [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-223.md) is intended to solve is that [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. + +ERC-223 standard is intended to simplify the interaction with contracts that are intended to work with tokens. [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-223.md) utilizes "deposit" pattern similar to plain Ether depositing patterns - in case of [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-223.md) deposit to the contract a user or a UI must simply send the tokens with the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. + +This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an Ether transaction, or allow for public loggin on chain should it be necessary for financial transactions. + + ## Security Considerations This token utilizes the model similar to plain Ether behavior. Therefore replay issues must be taken into account. From 74493a427bb77bd070853e358166ec9fc33c4cf0 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 03:02:09 +0400 Subject: [PATCH 06/61] Update eip-223.md --- EIPS/eip-223.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 15986da5a625fc..a3013871f835f2 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -166,17 +166,17 @@ IMPORTANT: This function must be named `tokenReceived` and take parameters` addr This standard introduces a communication model by enforcing the `transfer` to execute a handler function in the destination address. This is an important security consideration as it is required that the receiver explicitly implements the token handling function. In cases where the receiver does not implements such function the transfer MUST be reverted. -This standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-223.md) transfers are more gas-efficient while dealing with depositing to contracts as [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-223.md) tokens can be deposited with just one transaction while ERC20 tokens require at least two calls (one for `approve` and the second that will invoke `transferFrom`). +This standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, ERC-223 transfers are more gas-efficient while dealing with depositing to contracts as ERC-223 tokens can be deposited with just one transaction while ERC20 tokens require at least two calls (one for `approve` and the second that will invoke `transferFrom`). - [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) deposit: `approve` ~53K gas, `transferFrom` ~80K gas -- [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) deposit: `transfer` and handling on the receivers side ~46K gas +- ERC-223 deposit: `transfer` and handling on the receivers side ~46K gas This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipient side and reject incorrect or improper transactions. This tokens utilize ONE transferring method for both types of interactions with tokens and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes. -One downside of the commonly used [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) standard that [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-223.md) is intended to solve is that [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. +One downside of the commonly used [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) standard that ERC-223 is intended to solve is that [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. -ERC-223 standard is intended to simplify the interaction with contracts that are intended to work with tokens. [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-223.md) utilizes "deposit" pattern similar to plain Ether depositing patterns - in case of [ERC-223](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-223.md) deposit to the contract a user or a UI must simply send the tokens with the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. +ERC-223 standard is intended to simplify the interaction with contracts that are intended to work with tokens. ERC-223 utilizes "deposit" pattern similar to plain Ether depositing patterns - in case of ERC-223 deposit to the contract a user or a UI must simply send the tokens with the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an Ether transaction, or allow for public loggin on chain should it be necessary for financial transactions. From b305a79dfba9be5fe08cd0b48f59c6323b5570aa Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 03:05:15 +0400 Subject: [PATCH 07/61] Update eip-223.md --- EIPS/eip-223.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index a3013871f835f2..c50a7086241026 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -34,7 +34,7 @@ Contracts that works with tokens NOTE: An important point is that contract developers must implement `tokenReceived` if they want their contracts to work with the specified tokens. -If the receiver does not implement the `tokenReceived` function, consider the contract is not designed to work with tokens, then the transaction must fail and no tokens will be transferred. An analogy with an Ether transaction that is failing when trying to send Ether to a contract that did not implement `function() payable`. +If the receiver does not implement the `tokenReceived` function, consider the contract is not designed to work with tokens, then the transaction must fail and no tokens will be transferred. An analogy with an Ether transaction that is failing when trying to send Ether to a contract that did not implement `receive() payable`. #### totalSupply @@ -108,7 +108,7 @@ function transfer(address _to, uint _value) returns (bool) ``` -Needed due to backwards compatibility reasons because of ERC20 transfer function doesn't have `bytes` parameter. This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in ` _to` (receiver contract), then the transaction must fail and the transfer of tokens should be reverted. +Needed due to backwards compatibility reasons because of ERC20 transfer function doesn't have `bytes` parameter. This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in `_to` (receiver contract), then the transaction must fail and the transfer of tokens should be reverted. #### transfer(address, uint, bytes) @@ -119,11 +119,11 @@ function transfer(address _to, uint _value, bytes calldata _data) returns (bool) ``` function that is always called when someone wants to transfer tokens. -This function must transfer tokens and invoke the function `tokenReceived (address, uint256, bytes)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in ` _to` (receiver contract), then the transaction must fail and the transfer of tokens should not occur. -If `_to` is an externally owned address, then the transaction must be sent without trying to execute ` tokenReceived` in `_to`. +This function must transfer tokens and invoke the function `tokenReceived (address, uint256, bytes)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in `_to` (receiver contract), then the transaction must fail and the transfer of tokens should not occur. +If `_to` is an externally owned address, then the transaction must be sent without trying to execute `tokenReceived` in `_to`. `_data` can be attached to this token transaction and it will stay in blockchain forever (requires more gas). `_data` can be empty. -NOTE: The recommended way to check whether the `_to` is a contract or an address is to assemble the code of ` _to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. +NOTE: The recommended way to check whether the `_to` is a contract or an address is to assemble the code of `_to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. ### Events @@ -155,11 +155,11 @@ function tokenReceived(address _from, uint _value, bytes calldata _data) ``` -A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token,` _value` is the amount of incoming tokens, and `_data` is attached data similar to` msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. +A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token, `_value` is the amount of incoming tokens, and `_data` is attached data similar to` msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. -NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the` tokenReceived` function. +NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the `tokenReceived` function. -IMPORTANT: This function must be named `tokenReceived` and take parameters` address`, `uint256`,` bytes` to match the function signature `0xc0ee0b8a`. +IMPORTANT: This function must be named `tokenReceived` and take parameters `address`, `uint256`, `bytes` to match the function signature `0xc0ee0b8a`. ## Rationale From 45236685ed267d32dedae6d521ac91cc7c7bff29 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 03:07:10 +0400 Subject: [PATCH 08/61] Update eip-223.md --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index c50a7086241026..df146456d1433c 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -20,7 +20,7 @@ The following describes standard functions a token contract and contract working ## Motivation -1. This token introduces a communication model for contracts that can be utilized to straighten the behavior of contracts that interact with tokens as opposed to ERC-20 where a token transfer could be ignored by the receiving contract. +1. This token introduces a communication model for contracts that can be utilized to straighten the behavior of contracts that interact with tokens as opposed to [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) where a token transfer could be ignored by the receiving contract. 2. This token is more gas-efficient when depositing tokens to contracts. 3. This token allows for `_data` recording for financial transfers. From 537c9c65416d4b899dbc2a85b25c0674080d1008 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 03:10:51 +0400 Subject: [PATCH 09/61] Update eip-223.md --- EIPS/eip-223.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index df146456d1433c..6de3a9b26bc350 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -20,7 +20,7 @@ The following describes standard functions a token contract and contract working ## Motivation -1. This token introduces a communication model for contracts that can be utilized to straighten the behavior of contracts that interact with tokens as opposed to [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) where a token transfer could be ignored by the receiving contract. +1. This token introduces a communication model for contracts that can be utilized to straighten the behavior of contracts that interact with tokens as opposed to [ERC-20](./eip-20.md) where a token transfer could be ignored by the receiving contract. 2. This token is more gas-efficient when depositing tokens to contracts. 3. This token allows for `_data` recording for financial transfers. @@ -85,9 +85,9 @@ function standard() constant returns (string _standard) ``` -Get the standard of token contract. For some services it is important to know how to treat this particular token. If token supports ERC223 standard then it must explicitly tell that it does. +Get the standard of token contract. For some services it is important to know how to treat this particular token. If token supports ERC-223 standard then it must explicitly tell that it does. -This function **MUST** return "erc223" for this token standard. If no "standard()" function is implemented in the contract then the contract must be considered to be ERC20. +This function **MUST** return "ERC-223" for this token standard. If no "standard()" function is implemented in the contract then the contract must be considered to be ERC-20. #### balanceOf @@ -108,7 +108,7 @@ function transfer(address _to, uint _value) returns (bool) ``` -Needed due to backwards compatibility reasons because of ERC20 transfer function doesn't have `bytes` parameter. This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in `_to` (receiver contract), then the transaction must fail and the transfer of tokens should be reverted. +Needed due to backwards compatibility reasons because of ERC-20 transfer function doesn't have `bytes` parameter. This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in `_to` (receiver contract), then the transaction must fail and the transfer of tokens should be reverted. #### transfer(address, uint, bytes) @@ -135,7 +135,7 @@ event Transfer(address indexed _from, address indexed _to, uint256 _value) ``` -Triggered when tokens are transferred. Compatible with ERC20 `Transfer` event. +Triggered when tokens are transferred. Compatible with ERC-20 `Transfer` event. #### TransferData @@ -145,9 +145,9 @@ event TransferData(bytes _data) ``` -Triggered when tokens are transferred and logs transaction metadata. This is implemented as a separate event to keep `Transfer(address, address, uint256)` ERC20-compatible. +Triggered when tokens are transferred and logs transaction metadata. This is implemented as a separate event to keep `Transfer(address, address, uint256)` ERC-20-compatible. -## Contract that is intended to receive ERC223 tokens +## Contract that is intended to receive ERC-223 tokens ```js @@ -166,15 +166,15 @@ IMPORTANT: This function must be named `tokenReceived` and take parameters `addr This standard introduces a communication model by enforcing the `transfer` to execute a handler function in the destination address. This is an important security consideration as it is required that the receiver explicitly implements the token handling function. In cases where the receiver does not implements such function the transfer MUST be reverted. -This standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, ERC-223 transfers are more gas-efficient while dealing with depositing to contracts as ERC-223 tokens can be deposited with just one transaction while ERC20 tokens require at least two calls (one for `approve` and the second that will invoke `transferFrom`). +This standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, ERC-223 transfers are more gas-efficient while dealing with depositing to contracts as ERC-223 tokens can be deposited with just one transaction while ERC-20 tokens require at least two calls (one for `approve` and the second that will invoke `transferFrom`). -- [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) deposit: `approve` ~53K gas, `transferFrom` ~80K gas +- [ERC-20](./eip-20.md) deposit: `approve` ~53K gas, `transferFrom` ~80K gas - ERC-223 deposit: `transfer` and handling on the receivers side ~46K gas This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipient side and reject incorrect or improper transactions. This tokens utilize ONE transferring method for both types of interactions with tokens and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes. -One downside of the commonly used [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) standard that ERC-223 is intended to solve is that [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. +One downside of the commonly used [ERC-20](./eip-20.md) standard that ERC-223 is intended to solve is that [ERC-20](./eip-20.md) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](./eip-20.md) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. ERC-223 standard is intended to simplify the interaction with contracts that are intended to work with tokens. ERC-223 utilizes "deposit" pattern similar to plain Ether depositing patterns - in case of ERC-223 deposit to the contract a user or a UI must simply send the tokens with the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. @@ -188,7 +188,7 @@ This token utilizes the model similar to plain Ether behavior. Therefore replay ## Reference implementation -This is highly recommended implementation of ERC 223 token: https://github.com/Dexaran/ERC223-token-standard/tree/development/token/ERC223 +This is highly recommended implementation of ERC 223 token: https://github.com/Dexaran/ERC-223-token-standard/tree/development/token/ERC-223 ## History From 2f4595f46a38f3d4fc8d8780f6ec98802be44d44 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 03:14:18 +0400 Subject: [PATCH 10/61] Update eip-223.md --- EIPS/eip-223.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 6de3a9b26bc350..f1a07ec464ea58 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -85,7 +85,7 @@ function standard() constant returns (string _standard) ``` -Get the standard of token contract. For some services it is important to know how to treat this particular token. If token supports ERC-223 standard then it must explicitly tell that it does. +Get the standard of token contract. For some services it is important to know how to treat this particular token. If token supports [ERC-223](./eip-223.md) standard then it must explicitly tell that it does. This function **MUST** return "ERC-223" for this token standard. If no "standard()" function is implemented in the contract then the contract must be considered to be ERC-20. @@ -188,7 +188,7 @@ This token utilizes the model similar to plain Ether behavior. Therefore replay ## Reference implementation -This is highly recommended implementation of ERC 223 token: https://github.com/Dexaran/ERC-223-token-standard/tree/development/token/ERC-223 +This is highly recommended implementation of ERC-223 token: https://github.com/Dexaran/ERC-223-token-standard/tree/development/token/ERC-223 ## History @@ -196,4 +196,5 @@ This is highly recommended implementation of ERC 223 token: https://github.com/D - original issue: https://github.com/ethereum/EIPs/issues/223 ## Copyright -Copyright and related rights waived via CC0. + +Copyright and related rights waived via [CC0](../LICENSE.md). From 0bad3d8c787659caf6d98697152c830a94bcfca1 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 03:17:26 +0400 Subject: [PATCH 11/61] Update eip-223.md --- EIPS/eip-223.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index f1a07ec464ea58..6b065ef8df2289 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -10,13 +10,9 @@ category: ERC created: 2017-05-03 --- -## Simple Summary - -A standard interface for tokens with definition of `communication model` logic. - ## Abstract -The following describes standard functions a token contract and contract working with specified token can implement. This standard introduces a communication model which allows for the implementation of **event handling** on the receiver's side. +The following describes standard functions a token contract and contract which is intended to work with specified token can implement. This standard introduces a communication model which allows for the implementation of **event handling** on the receiver's side. ## Motivation @@ -147,7 +143,7 @@ event TransferData(bytes _data) Triggered when tokens are transferred and logs transaction metadata. This is implemented as a separate event to keep `Transfer(address, address, uint256)` ERC-20-compatible. -## Contract that is intended to receive ERC-223 tokens +### Contract that is intended to receive ERC-223 tokens ```js @@ -186,7 +182,7 @@ This standard allows payloads to be attached to transactions using the `bytes ca This token utilizes the model similar to plain Ether behavior. Therefore replay issues must be taken into account. -## Reference implementation +### Reference implementation This is highly recommended implementation of ERC-223 token: https://github.com/Dexaran/ERC-223-token-standard/tree/development/token/ERC-223 @@ -197,4 +193,4 @@ This is highly recommended implementation of ERC-223 token: https://github.com/D ## Copyright -Copyright and related rights waived via [CC0](../LICENSE.md). +Copyright and related rights waived via [CC0](./LICENSE.md). From f13c6993dbebac49ce368646f711bc5ae7f938a7 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 03:18:03 +0400 Subject: [PATCH 12/61] Update eip-223.md --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 6b065ef8df2289..dace18596dc092 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -151,7 +151,7 @@ function tokenReceived(address _from, uint _value, bytes calldata _data) ``` -A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token, `_value` is the amount of incoming tokens, and `_data` is attached data similar to` msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. +A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token, `_value` is the amount of incoming tokens, and `_data` is attached data similar to `msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the `tokenReceived` function. From a3d05a55e478fd5f4950b669fd0737c4ef6dd6ce Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 03:20:48 +0400 Subject: [PATCH 13/61] Update eip-223.md --- EIPS/eip-223.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index dace18596dc092..6faea4bf99286d 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -184,7 +184,7 @@ This token utilizes the model similar to plain Ether behavior. Therefore replay ### Reference implementation -This is highly recommended implementation of ERC-223 token: https://github.com/Dexaran/ERC-223-token-standard/tree/development/token/ERC-223 +This is highly recommended implementation of ERC-223 token: https://github.com/Dexaran/ERC223-token-standard/tree/development/token/ERC223 ## History @@ -193,4 +193,4 @@ This is highly recommended implementation of ERC-223 token: https://github.com/D ## Copyright -Copyright and related rights waived via [CC0](./LICENSE.md). +Copyright and related rights waived via [CC0](../LICENSE.md). From 0c8db1bd0b1bd89592c9075cf30185d9d89e4468 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 03:22:49 +0400 Subject: [PATCH 14/61] Update eip-223.md --- EIPS/eip-223.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 6faea4bf99286d..b054eeefdeef27 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -186,11 +186,6 @@ This token utilizes the model similar to plain Ether behavior. Therefore replay This is highly recommended implementation of ERC-223 token: https://github.com/Dexaran/ERC223-token-standard/tree/development/token/ERC223 - -## History - -- original issue: https://github.com/ethereum/EIPs/issues/223 - ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). From 4ef16310fd1177f003e552679437b29f11ff4710 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 03:28:54 +0400 Subject: [PATCH 15/61] Update eip-223.md --- EIPS/eip-223.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index b054eeefdeef27..d16b81107774a3 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -184,8 +184,4 @@ This token utilizes the model similar to plain Ether behavior. Therefore replay ### Reference implementation -This is highly recommended implementation of ERC-223 token: https://github.com/Dexaran/ERC223-token-standard/tree/development/token/ERC223 - -## Copyright - -Copyright and related rights waived via [CC0](../LICENSE.md). +This is highly recommended implementation of ERC-223 token: https://github.com/Dexaran/ERC-223 From b3f6e3caffd372df8f0a1def546801291188b2b3 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 03:35:25 +0400 Subject: [PATCH 16/61] Update eip-223.md --- EIPS/eip-223.md | 204 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 203 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index d16b81107774a3..b81eddd4b364f6 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -184,4 +184,206 @@ This token utilizes the model similar to plain Ether behavior. Therefore replay ### Reference implementation -This is highly recommended implementation of ERC-223 token: https://github.com/Dexaran/ERC-223 +```js + +pragma solidity ^0.8.0; + +// Source: https://github.com/Dexaran/ERC-223 + +library Address { + /** + * @dev Returns true if `account` is a contract. + * + * This test is non-exhaustive, and there may be false-negatives: during the + * execution of a contract's constructor, its address will be reported as + * not containing a contract. + * + * > It is unsafe to assume that an address for which this function returns + * false is an externally-owned account (EOA) and not a contract. + */ + function isContract(address account) internal view returns (bool) { + // This method relies in extcodesize, which returns 0 for contracts in + // construction, since the code is only stored at the end of the + // constructor execution. + + uint256 size; + // solhint-disable-next-line no-inline-assembly + assembly { size := extcodesize(account) } + return size > 0; + } + + /** + * @dev Converts an `address` into `address payable`. Note that this is + * simply a type cast: the actual underlying value is not changed. + */ + function toPayable(address account) internal pure returns (address payable) { + return payable(account); + } +} + +abstract contract IERC223Recipient { +/** + * @dev Standard ERC223 function that will handle incoming token transfers. + * + * @param _from Token sender address. + * @param _value Amount of tokens. + * @param _data Transaction metadata. + */ + function tokenReceived(address _from, uint _value, bytes memory _data) public virtual; +} + +/** + * @title Reference implementation of the ERC223 standard token. + */ +contract ERC223Token { + + /** + * @dev Event that is fired on successful transfer. + */ + event Transfer(address indexed from, address indexed to, uint value); + + /** + * @dev Additional event that is fired on successful transfer and logs transfer metadata, + * this event is implemented to keep Transfer event compatible with ERC20. + */ + event TransferData(bytes data); + + string private _name; + string private _symbol; + uint8 private _decimals; + uint256 private _totalSupply; + + mapping(address => uint256) public balances; // List of user balances. + + /** + * @dev Sets the values for {name} and {symbol}, initializes {decimals} with + * a default value of 18. + * + * To select a different value for {decimals}, use {_setupDecimals}. + * + * All three of these values are immutable: they can only be set once during + * construction. + */ + + constructor(string memory new_name, string memory new_symbol, uint8 new_decimals) + { + _name = new_name; + _symbol = new_symbol; + _decimals = new_decimals; + } + + /** + * @dev ERC223 tokens must explicitly return "erc223" on standard() function call. + */ + function standard() public pure returns (string memory) + { + return "ERC-223"; + } + + /** + * @dev Returns the name of the token. + */ + function name() public view returns (string memory) + { + return _name; + } + + /** + * @dev Returns the symbol of the token, usually a shorter version of the + * name. + */ + function symbol() public view returns (string memory) + { + return _symbol; + } + + /** + * @dev Returns the number of decimals used to get its user representation. + * For example, if `decimals` equals `2`, a balance of `505` tokens should + * be displayed to a user as `5,05` (`505 / 10 ** 2`). + * + * Tokens usually opt for a value of 18, imitating the relationship between + * Ether and Wei. This is the value {ERC223} uses, unless {_setupDecimals} is + * called. + * + * NOTE: This information is only used for _display_ purposes: it in + * no way affects any of the arithmetic of the contract, including + * {IERC223-balanceOf} and {IERC223-transfer}. + */ + function decimals() public view returns (uint8) + { + return _decimals; + } + + /** + * @dev See {IERC223-totalSupply}. + */ + function totalSupply() public view returns (uint256) + { + return _totalSupply; + } + + + /** + * @dev Returns balance of the `_owner`. + * + * @param _owner The address whose balance will be returned. + * @return balance Balance of the `_owner`. + */ + function balanceOf(address _owner) public view returns (uint256) + { + return balances[_owner]; + } + + /** + * @dev Transfer the specified amount of tokens to the specified address. + * Invokes the `tokenFallback` function if the recipient is a contract. + * The token transfer fails if the recipient is a contract + * but does not implement the `tokenFallback` function + * or the fallback function to receive funds. + * + * @param _to Receiver address. + * @param _value Amount of tokens that will be transferred. + * @param _data Transaction metadata. + */ + function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success) + { + // Standard function transfer similar to ERC20 transfer with no _data . + // Added due to backwards compatibility reasons . + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(Address.isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data); + } + emit Transfer(msg.sender, _to, _value); + emit TransferData(_data); + return true; + } + + /** + * @dev Transfer the specified amount of tokens to the specified address. + * This function works the same with the previous one + * but doesn't contain `_data` param. + * Added due to backwards compatibility reasons. + * + * @param _to Receiver address. + * @param _value Amount of tokens that will be transferred. + */ + function transfer(address _to, uint _value) public returns (bool success) + { + bytes memory _empty = hex"00000000"; + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(Address.isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty); + } + emit Transfer(msg.sender, _to, _value); + emit TransferData(_empty); + return true; + } +} + +``` + + +## Copyright From f265fed324823b3ce4fedf78189192dcf0e1f32e Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 19:22:21 +0400 Subject: [PATCH 17/61] Update EIPS/eip-223.md Commited readability improvements as suggested by the EIP editor Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index b81eddd4b364f6..7fc890eb6c0a33 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -12,7 +12,7 @@ created: 2017-05-03 ## Abstract -The following describes standard functions a token contract and contract which is intended to work with specified token can implement. This standard introduces a communication model which allows for the implementation of **event handling** on the receiver's side. +The following describes an interface for fungible tokens that supports a `tokenReceived` callback to notify contract recipients when tokens are received. ## Motivation From 8e87c999d2fd883825c56db8543cbceb98c0a538 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 19:24:34 +0400 Subject: [PATCH 18/61] Update EIPS/eip-223.md Commited readability improvements as suggested by the EIP editor Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 7fc890eb6c0a33..ea45ed02605086 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -16,9 +16,11 @@ The following describes an interface for fungible tokens that supports a `tokenR ## Motivation -1. This token introduces a communication model for contracts that can be utilized to straighten the behavior of contracts that interact with tokens as opposed to [ERC-20](./eip-20.md) where a token transfer could be ignored by the receiving contract. -2. This token is more gas-efficient when depositing tokens to contracts. -3. This token allows for `_data` recording for financial transfers. +This token introduces a communication model for contracts that can be utilized to straighten the behavior of contracts that interact with such tokens. Specifically, this proposal: + +1. Informs receiving contracts of tokens, as opposed to [ERC-20](./eip-20.md) where the recipient of a token transfer gets no notification. +2. Is more gas-efficient when depositing tokens to contracts. +3. Allows for `_data` recording for financial transfers. ## Specification From 10502bcc8f15f65d7341fb3223179be73103f9e4 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 19:28:11 +0400 Subject: [PATCH 19/61] Update EIPS/eip-223.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index ea45ed02605086..8b51204fd82996 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -25,8 +25,6 @@ This token introduces a communication model for contracts that can be utilized t ## Specification -Token -Contracts that works with tokens ### Methods From 489a021316ca95ced5c000c3c88cc868b47af185 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 19:29:27 +0400 Subject: [PATCH 20/61] Update EIPS/eip-223.md Readability improvements as suggested by the EIP editor Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 8b51204fd82996..c30d7eb7a98b61 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -28,9 +28,9 @@ This token introduces a communication model for contracts that can be utilized t ### Methods -NOTE: An important point is that contract developers must implement `tokenReceived` if they want their contracts to work with the specified tokens. +Contracts intending to receive these tokens MUST implement `tokenReceived`. -If the receiver does not implement the `tokenReceived` function, consider the contract is not designed to work with tokens, then the transaction must fail and no tokens will be transferred. An analogy with an Ether transaction that is failing when trying to send Ether to a contract that did not implement `receive() payable`. +Tokens transferred to contracts not implementing `tokenReceived` as described below MUST revert. #### totalSupply From e691b310dc6dc7a80a21326f0f7b70cd4d505aec Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 19:30:08 +0400 Subject: [PATCH 21/61] Update EIPS/eip-223.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index c30d7eb7a98b61..7014ccc8efffef 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -33,7 +33,7 @@ Contracts intending to receive these tokens MUST implement `tokenReceived`. Tokens transferred to contracts not implementing `tokenReceived` as described below MUST revert. -#### totalSupply +#### `totalSupply` ```js From 8b8ebfbaef5d87e3403c54f15b76e01af99e837e Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 19:34:41 +0400 Subject: [PATCH 22/61] Replaced `constant` function definitions with `view` to match modern Solidity --- EIPS/eip-223.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 7014ccc8efffef..603c1790312df2 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -37,7 +37,7 @@ Tokens transferred to contracts not implementing `tokenReceived` as described be ```js -function totalSupply() constant returns (uint256 totalSupply) +function totalSupply() view returns (uint256 totalSupply) ``` @@ -47,7 +47,7 @@ Get the total token supply ```js -function name() constant returns (string _name) +function name() view returns (string _name) ``` @@ -57,7 +57,7 @@ Get the name of token ```js -function symbol() constant returns (bytes32 _symbol) +function symbol() view returns (bytes32 _symbol) ``` @@ -67,7 +67,7 @@ Get the symbol of token ```js -function decimals() constant returns (uint8 _decimals) +function decimals() view returns (uint8 _decimals) ``` @@ -77,7 +77,7 @@ Get decimals of token ```js -function standard() constant returns (string _standard) +function standard() view returns (string _standard) ``` @@ -89,7 +89,7 @@ This function **MUST** return "ERC-223" for this token standard. If no "standard ```js -function balanceOf(address _owner) constant returns (uint256 balance) +function balanceOf(address _owner) view returns (uint256 balance) ``` From fda8c4c5e09d610853791bd898bc08ef707c2007 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 19:43:19 +0400 Subject: [PATCH 23/61] Update EIPS/eip-223.md Commited readability improvements as suggested by the EIPs editor Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 603c1790312df2..010e5e842691b3 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -104,7 +104,7 @@ function transfer(address _to, uint _value) returns (bool) ``` -Needed due to backwards compatibility reasons because of ERC-20 transfer function doesn't have `bytes` parameter. This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in `_to` (receiver contract), then the transaction must fail and the transfer of tokens should be reverted. +This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if `_to` is a contract. If the `tokenReceived` function is not implemented in `_to` (receiver contract), then the transaction must fail and the transfer of tokens should be reverted. #### transfer(address, uint, bytes) From 5eb2b7c8dbaf3b6ba018ee78fa763f8025e81d9f Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 19:43:59 +0400 Subject: [PATCH 24/61] Update EIPS/eip-223.md Commited changes as suggested by the EIPs editor Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 010e5e842691b3..1ddc80dd2f57b1 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -141,7 +141,7 @@ event TransferData(bytes _data) ``` -Triggered when tokens are transferred and logs transaction metadata. This is implemented as a separate event to keep `Transfer(address, address, uint256)` ERC-20-compatible. +Triggered when tokens are transferred and logs transaction metadata. ### Contract that is intended to receive ERC-223 tokens From 8076fc26f63c1b4ba96452c089a78526512bedbd Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 19:51:12 +0400 Subject: [PATCH 25/61] Update EIPS/eip-223.md Adding a license. Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 1ddc80dd2f57b1..e7793233cff43b 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -387,3 +387,5 @@ contract ERC223Token { ## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From db8bdb4489556f5815d3152121dbc0fb5e52fa10 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 19:51:26 +0400 Subject: [PATCH 26/61] Update EIPS/eip-223.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index e7793233cff43b..69c2e26caf9c21 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -182,7 +182,7 @@ This standard allows payloads to be attached to transactions using the `bytes ca This token utilizes the model similar to plain Ether behavior. Therefore replay issues must be taken into account. -### Reference implementation +### Reference Implementation ```js From 797dfef031b37cb95bd36cd3eeae8c6e45adcb06 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Feb 2023 20:07:26 +0400 Subject: [PATCH 27/61] re-added email --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 69c2e26caf9c21..b5609d6ed8dbb4 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -2,7 +2,7 @@ eip: 223 title: 223 Token with communication model description: Token with event handling and communication model -author: Dexaran (@Dexaran) +author: Dexaran (@Dexaran) discussions-to: https://ethereum-magicians.org/t/erc-223-token-standard/12894 status: Review type: Standards Track From 7c3387af97c6eeb3894d7b1df603eab894271d4c Mon Sep 17 00:00:00 2001 From: Dexaran Date: Sat, 11 Feb 2023 17:37:06 +0400 Subject: [PATCH 28/61] Update EIPS/eip-223.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index b5609d6ed8dbb4..e46e05ffaebebd 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -184,7 +184,7 @@ This token utilizes the model similar to plain Ether behavior. Therefore replay ### Reference Implementation -```js +```solidity pragma solidity ^0.8.0; From c8887591472da242e4883378cb48678665a2dec2 Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Sun, 12 Feb 2023 13:23:42 -0500 Subject: [PATCH 29/61] Manually committing formatting change Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index e46e05ffaebebd..03bdcd11982b9b 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -145,10 +145,8 @@ Triggered when tokens are transferred and logs transaction metadata. ### Contract that is intended to receive ERC-223 tokens -```js - +```solidity function tokenReceived(address _from, uint _value, bytes calldata _data) - ``` A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token, `_value` is the amount of incoming tokens, and `_data` is attached data similar to `msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. From 2b387f7ce1cd489de8b35187d4f214afced18d76 Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Sun, 12 Feb 2023 13:27:04 -0500 Subject: [PATCH 30/61] Fix formatting stuff Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-223.md | 36 ++++++++++++++---------------------- 1 file changed, 14 insertions(+), 22 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 03bdcd11982b9b..2c9839fcc4a646 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -43,7 +43,7 @@ function totalSupply() view returns (uint256 totalSupply) Get the total token supply -#### name +#### `name` ```js @@ -53,7 +53,7 @@ function name() view returns (string _name) Get the name of token -#### symbol +#### `symbol` ```js @@ -63,7 +63,7 @@ function symbol() view returns (bytes32 _symbol) Get the symbol of token -#### decimals +#### `decimals` ```js @@ -73,7 +73,7 @@ function decimals() view returns (uint8 _decimals) Get decimals of token -#### standard +#### `standard` ```js @@ -85,7 +85,7 @@ Get the standard of token contract. For some services it is important to know ho This function **MUST** return "ERC-223" for this token standard. If no "standard()" function is implemented in the contract then the contract must be considered to be ERC-20. -#### balanceOf +#### `balanceOf` ```js @@ -93,25 +93,21 @@ function balanceOf(address _owner) view returns (uint256 balance) ``` -Get the account balance of another account with address _owner +Get the account balance of another account with address `_owner` -#### transfer(address, uint) - -```js +#### `transfer(address, uint)` +```solidity function transfer(address _to, uint _value) returns (bool) - ``` This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if `_to` is a contract. If the `tokenReceived` function is not implemented in `_to` (receiver contract), then the transaction must fail and the transfer of tokens should be reverted. -#### transfer(address, uint, bytes) - -```js +#### `transfer(address, uint, bytes)` +```solidity function transfer(address _to, uint _value, bytes calldata _data) returns (bool) - ``` function that is always called when someone wants to transfer tokens. @@ -123,22 +119,18 @@ NOTE: The recommended way to check whether the `_to` is a contract or an address ### Events -#### Transfer - -```js +#### `Transfer` +```solidity event Transfer(address indexed _from, address indexed _to, uint256 _value) - ``` Triggered when tokens are transferred. Compatible with ERC-20 `Transfer` event. -#### TransferData - -```js +#### `TransferData` +```solidity event TransferData(bytes _data) - ``` Triggered when tokens are transferred and logs transaction metadata. From 73bbb95090223e8f2ae00a90c5c9ff2c0ffaf3a9 Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Sun, 12 Feb 2023 13:27:25 -0500 Subject: [PATCH 31/61] Fix author list --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 2c9839fcc4a646..88df0471d80c6e 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -2,7 +2,7 @@ eip: 223 title: 223 Token with communication model description: Token with event handling and communication model -author: Dexaran (@Dexaran) +author: Dexaran (@Dexaran) discussions-to: https://ethereum-magicians.org/t/erc-223-token-standard/12894 status: Review type: Standards Track From 8afcba5bf15687f639f9b4282d3206b9166b8de7 Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Sun, 12 Feb 2023 13:29:07 -0500 Subject: [PATCH 32/61] Fix more formatting that Sam missed --- EIPS/eip-223.md | 24 ++++++------------------ 1 file changed, 6 insertions(+), 18 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 88df0471d80c6e..dfad387484c1af 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -35,50 +35,40 @@ Tokens transferred to contracts not implementing `tokenReceived` as described be #### `totalSupply` -```js - +```solidity function totalSupply() view returns (uint256 totalSupply) - ``` Get the total token supply #### `name` -```js - +```solidity function name() view returns (string _name) - ``` Get the name of token #### `symbol` -```js - +```solidity function symbol() view returns (bytes32 _symbol) - ``` Get the symbol of token #### `decimals` -```js - +```solidity function decimals() view returns (uint8 _decimals) - ``` Get decimals of token #### `standard` -```js - +```solidity function standard() view returns (string _standard) - ``` Get the standard of token contract. For some services it is important to know how to treat this particular token. If token supports [ERC-223](./eip-223.md) standard then it must explicitly tell that it does. @@ -87,10 +77,8 @@ This function **MUST** return "ERC-223" for this token standard. If no "standard #### `balanceOf` -```js - +```solidity function balanceOf(address _owner) view returns (uint256 balance) - ``` Get the account balance of another account with address `_owner` From f51655b1a6aed56f0a028f48bd54ecb87eb96fc2 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Mon, 13 Feb 2023 02:07:37 +0400 Subject: [PATCH 33/61] Update EIPS/eip-223.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> --- EIPS/eip-223.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index dfad387484c1af..1cfdfed6d7639c 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -166,7 +166,6 @@ This token utilizes the model similar to plain Ether behavior. Therefore replay pragma solidity ^0.8.0; -// Source: https://github.com/Dexaran/ERC-223 library Address { /** From e61458a743656b6fd5034558d0ab7bb2ec555940 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 3 Mar 2023 22:22:37 +0400 Subject: [PATCH 34/61] Update EIPS/eip-223.md Co-authored-by: Gavin John --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 1cfdfed6d7639c..5526c85ca6afe3 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -30,7 +30,7 @@ This token introduces a communication model for contracts that can be utilized t Contracts intending to receive these tokens MUST implement `tokenReceived`. -Tokens transferred to contracts not implementing `tokenReceived` as described below MUST revert. +Token transfers to contracts not implementing `tokenReceived` as described below MUST revert. #### `totalSupply` From 1857d8365f1ab0823b7ee7d984cf3962eb345310 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 3 Mar 2023 22:24:01 +0400 Subject: [PATCH 35/61] Update EIPS/eip-223.md Co-authored-by: Gavin John --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 5526c85ca6afe3..c6bd23ed2bad2b 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -150,7 +150,7 @@ This standard introduces the ability to correct user errors by allowing to handl One downside of the commonly used [ERC-20](./eip-20.md) standard that ERC-223 is intended to solve is that [ERC-20](./eip-20.md) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](./eip-20.md) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. -ERC-223 standard is intended to simplify the interaction with contracts that are intended to work with tokens. ERC-223 utilizes "deposit" pattern similar to plain Ether depositing patterns - in case of ERC-223 deposit to the contract a user or a UI must simply send the tokens with the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. +ERC-223 is intended to simplify the interaction with contracts that are intended to work with tokens. ERC-223 utilizes a "deposit" pattern, similar to that of plain Ether. An ERC-223 deposit to a contract is a simple call of the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an Ether transaction, or allow for public loggin on chain should it be necessary for financial transactions. From c7a4cd98717ee0d524990861328673bb3d913d34 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 3 Mar 2023 22:29:32 +0400 Subject: [PATCH 36/61] Update eip-223.md --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index c6bd23ed2bad2b..53ad1865e7001d 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -152,7 +152,7 @@ One downside of the commonly used [ERC-20](./eip-20.md) standard that ERC-223 is ERC-223 is intended to simplify the interaction with contracts that are intended to work with tokens. ERC-223 utilizes a "deposit" pattern, similar to that of plain Ether. An ERC-223 deposit to a contract is a simple call of the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing. -This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an Ether transaction, or allow for public loggin on chain should it be necessary for financial transactions. +This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an Ether transaction, or allow for public logging on chain should it be necessary for financial transactions. ## Security Considerations From 0628cef8dc0a8e3253f6d845b4cee5d2105caf3c Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 3 Mar 2023 22:30:30 +0400 Subject: [PATCH 37/61] Update eip-223.md --- EIPS/eip-223.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 53ad1865e7001d..bc2446c20af58a 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -65,16 +65,6 @@ function decimals() view returns (uint8 _decimals) Get decimals of token -#### `standard` - -```solidity -function standard() view returns (string _standard) -``` - -Get the standard of token contract. For some services it is important to know how to treat this particular token. If token supports [ERC-223](./eip-223.md) standard then it must explicitly tell that it does. - -This function **MUST** return "ERC-223" for this token standard. If no "standard()" function is implemented in the contract then the contract must be considered to be ERC-20. - #### `balanceOf` ```solidity From 6f64550703179771fa854f4550354464059fadf4 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 3 Mar 2023 22:32:30 +0400 Subject: [PATCH 38/61] Update eip-223.md --- EIPS/eip-223.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index bc2446c20af58a..000d5f6bf85ec0 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -39,7 +39,7 @@ Token transfers to contracts not implementing `tokenReceived` as described below function totalSupply() view returns (uint256 totalSupply) ``` -Get the total token supply +Get the total token supply. #### `name` @@ -47,7 +47,9 @@ Get the total token supply function name() view returns (string _name) ``` -Get the name of token +Get the name of token. + +OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. #### `symbol` @@ -55,7 +57,9 @@ Get the name of token function symbol() view returns (bytes32 _symbol) ``` -Get the symbol of token +Get the symbol of token. + +OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. #### `decimals` @@ -63,7 +67,9 @@ Get the symbol of token function decimals() view returns (uint8 _decimals) ``` -Get decimals of token +Get decimals of token. + +OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. #### `balanceOf` @@ -71,7 +77,7 @@ Get decimals of token function balanceOf(address _owner) view returns (uint256 balance) ``` -Get the account balance of another account with address `_owner` +Get the account balance of another account with address `_owner`. #### `transfer(address, uint)` From 402461974b673ac806d7d0bfdf915d959b42db5d Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 3 Mar 2023 22:35:53 +0400 Subject: [PATCH 39/61] Update eip-223.md --- EIPS/eip-223.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 000d5f6bf85ec0..c55db229ba6398 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -86,7 +86,9 @@ Get the account balance of another account with address `_owner`. function transfer(address _to, uint _value) returns (bool) ``` -This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if `_to` is a contract. If the `tokenReceived` function is not implemented in `_to` (receiver contract), then the transaction must fail and the transfer of tokens should be reverted. +This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if `_to` is a contract. If the `tokenReceived` function is not implemented in `_to` (recipient contract), then the transaction must fail and the transfer of tokens must be reverted. +If `_to` is an externally owned address, then the transaction must be sent without executing `tokenReceived` in `_to`. + `_data` can be attached to this token transaction and it will stay in blockchain forever (requires more gas). `_data` can be empty. #### `transfer(address, uint, bytes)` @@ -94,12 +96,11 @@ This function must transfer tokens and invoke the function `tokenReceived(addres function transfer(address _to, uint _value, bytes calldata _data) returns (bool) ``` -function that is always called when someone wants to transfer tokens. -This function must transfer tokens and invoke the function `tokenReceived (address, uint256, bytes)` in `_to`, if _to is a contract. If the `tokenReceived` function is not implemented in `_to` (receiver contract), then the transaction must fail and the transfer of tokens should not occur. -If `_to` is an externally owned address, then the transaction must be sent without trying to execute `tokenReceived` in `_to`. +This function must transfer tokens and invoke the function `tokenReceived (address, uint256, bytes)` in `_to`, if `_to` is a contract. If the `tokenReceived` function is not implemented in `_to` (recipient contract), then the transaction must fail and the transfer of tokens must not occur. +If `_to` is an externally owned address, then the transaction must be sent without executing `tokenReceived` in `_to`. `_data` can be attached to this token transaction and it will stay in blockchain forever (requires more gas). `_data` can be empty. -NOTE: The recommended way to check whether the `_to` is a contract or an address is to assemble the code of `_to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. +NOTE: A possible way to check whether the `_to` is a contract or an address is to assemble the code of `_to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. ### Events From 88aff68f4b59ebe52156464bcc8a8d1333395466 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 3 Mar 2023 22:42:31 +0400 Subject: [PATCH 40/61] Update eip-223.md --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index c55db229ba6398..970158c0ea6c11 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -120,7 +120,7 @@ event TransferData(bytes _data) Triggered when tokens are transferred and logs transaction metadata. -### Contract that is intended to receive ERC-223 tokens +### Contract that is intended to receive [ERC-223](https://ethereum-magicians.org/t/erc-223-token-standard/12894) tokens ```solidity function tokenReceived(address _from, uint _value, bytes calldata _data) From 0b54c090ac82734c5b4e7674583540ad9a8515e4 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 3 Mar 2023 22:44:28 +0400 Subject: [PATCH 41/61] Update eip-223.md --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 970158c0ea6c11..6e95f724d9afeb 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -120,7 +120,7 @@ event TransferData(bytes _data) Triggered when tokens are transferred and logs transaction metadata. -### Contract that is intended to receive [ERC-223](https://ethereum-magicians.org/t/erc-223-token-standard/12894) tokens +### Contract that is intended to receive [ERC-223](./eip-223.md) tokens ```solidity function tokenReceived(address _from, uint _value, bytes calldata _data) From 3090cc6c3facc35d65ab67844d35e3c78f5a3aa3 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 3 Mar 2023 22:51:25 +0400 Subject: [PATCH 42/61] Update the code of Transfer(...) event --- EIPS/eip-223.md | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 6e95f724d9afeb..2ec1b26c04d75c 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -161,7 +161,7 @@ This token utilizes the model similar to plain Ether behavior. Therefore replay ```solidity -pragma solidity ^0.8.0; +pragma solidity ^0.8.19; library Address { @@ -214,13 +214,7 @@ contract ERC223Token { /** * @dev Event that is fired on successful transfer. */ - event Transfer(address indexed from, address indexed to, uint value); - - /** - * @dev Additional event that is fired on successful transfer and logs transfer metadata, - * this event is implemented to keep Transfer event compatible with ERC20. - */ - event TransferData(bytes data); + event Transfer(address indexed from, address indexed to, uint value, bytes data); string private _name; string private _symbol; @@ -329,8 +323,7 @@ contract ERC223Token { if(Address.isContract(_to)) { IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data); } - emit Transfer(msg.sender, _to, _value); - emit TransferData(_data); + emit Transfer(msg.sender, _to, _value, _data); return true; } @@ -351,8 +344,7 @@ contract ERC223Token { if(Address.isContract(_to)) { IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty); } - emit Transfer(msg.sender, _to, _value); - emit TransferData(_empty); + emit Transfer(msg.sender, _to, _value, _empty); return true; } } From 5f7b6ace71a49e4886fbf23da74950341c39efb5 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Sat, 4 Mar 2023 04:09:23 +0400 Subject: [PATCH 43/61] Fix function signature --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 2ec1b26c04d75c..bed0a850e4193f 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -130,7 +130,7 @@ A function for handling token transfers, which is called from the token contract NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the `tokenReceived` function. -IMPORTANT: This function must be named `tokenReceived` and take parameters `address`, `uint256`, `bytes` to match the function signature `0xc0ee0b8a`. +IMPORTANT: This function must be named `tokenReceived` and take parameters `address`, `uint256`, `bytes` to match the function signature `0x8943ec02`. ## Rationale From 7b67c2ecfcc110c6589f1c627df65f44f9e76aeb Mon Sep 17 00:00:00 2001 From: Dexaran Date: Sat, 4 Mar 2023 04:11:57 +0400 Subject: [PATCH 44/61] Moved the tokenReceived() paragraph directly below transfer() deifnition --- EIPS/eip-223.md | 28 ++++++++++------------------ 1 file changed, 10 insertions(+), 18 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index bed0a850e4193f..35ee4b849f7f67 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -25,13 +25,13 @@ This token introduces a communication model for contracts that can be utilized t ## Specification - ### Methods Contracts intending to receive these tokens MUST implement `tokenReceived`. Token transfers to contracts not implementing `tokenReceived` as described below MUST revert. +### Token contract #### `totalSupply` @@ -102,35 +102,27 @@ If `_to` is an externally owned address, then the transaction must be sent witho NOTE: A possible way to check whether the `_to` is a contract or an address is to assemble the code of `_to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. -### Events - -#### `Transfer` +### Contract that is intended to receive [ERC-223](./eip-223.md) tokens ```solidity -event Transfer(address indexed _from, address indexed _to, uint256 _value) +function tokenReceived(address _from, uint _value, bytes calldata _data) ``` -Triggered when tokens are transferred. Compatible with ERC-20 `Transfer` event. +A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token, `_value` is the amount of incoming tokens, and `_data` is attached data similar to `msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. -#### `TransferData` +NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the `tokenReceived` function. -```solidity -event TransferData(bytes _data) -``` +IMPORTANT: This function must be named `tokenReceived` and take parameters `address`, `uint256`, `bytes` to match the function signature `0x8943ec02`. -Triggered when tokens are transferred and logs transaction metadata. +### Events -### Contract that is intended to receive [ERC-223](./eip-223.md) tokens +#### `Transfer` ```solidity -function tokenReceived(address _from, uint _value, bytes calldata _data) +event Transfer(address indexed _from, address indexed _to, uint256 _value) ``` -A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token, `_value` is the amount of incoming tokens, and `_data` is attached data similar to `msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. - -NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the `tokenReceived` function. - -IMPORTANT: This function must be named `tokenReceived` and take parameters `address`, `uint256`, `bytes` to match the function signature `0x8943ec02`. +Triggered when tokens are transferred. Compatible with ERC-20 `Transfer` event. ## Rationale From 6093c8f32b4a33acd700757776023602e02e0da3 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Sat, 4 Mar 2023 04:34:05 +0400 Subject: [PATCH 45/61] Backwards compatibility considerations --- EIPS/eip-223.md | 51 +++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 45 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 35ee4b849f7f67..9cc20399cb4d4f 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -39,7 +39,7 @@ Token transfers to contracts not implementing `tokenReceived` as described below function totalSupply() view returns (uint256 totalSupply) ``` -Get the total token supply. +Get the total supply of the token. The functionality of the method is similar to `totalSupply()` of ERC-20. #### `name` @@ -47,7 +47,7 @@ Get the total token supply. function name() view returns (string _name) ``` -Get the name of token. +Get the name of the token. The functionality of the method is similar to `name()` of ERC-20. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. @@ -57,7 +57,7 @@ OPTIONAL - This method can be used to improve usability, but interfaces and othe function symbol() view returns (bytes32 _symbol) ``` -Get the symbol of token. +Get the symbol of token. The functionality of the method is similar to `symbol()` of ERC-20. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. @@ -67,7 +67,7 @@ OPTIONAL - This method can be used to improve usability, but interfaces and othe function decimals() view returns (uint8 _decimals) ``` -Get decimals of token. +Get decimals of token. The functionality of the method is similar to `decimals()` of ERC-20. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. @@ -77,7 +77,7 @@ OPTIONAL - This method can be used to improve usability, but interfaces and othe function balanceOf(address _owner) view returns (uint256 balance) ``` -Get the account balance of another account with address `_owner`. +Get the account balance of another account with address `_owner`. The functionality of the method is similar to `balanceOf(address)` of ERC-20. #### `transfer(address, uint)` @@ -122,7 +122,7 @@ IMPORTANT: This function must be named `tokenReceived` and take parameters `addr event Transfer(address indexed _from, address indexed _to, uint256 _value) ``` -Triggered when tokens are transferred. Compatible with ERC-20 `Transfer` event. +Triggered when tokens are transferred. Compatible with ERC-20 `Transfer` event. The functionality of the event is similar to `Transfer` event of ERC-20. ## Rationale @@ -343,6 +343,45 @@ contract ERC223Token { ``` +## Backwards compatibility + +The interface of this token is similar to that of ERC-20 and most functions serve the same purpose as their analogues in ERC-20. +`transfer(address, uint256, bytes calldata)` function is not backwards compatible with ERC-20 interface. + +ERC-20 tokens can be delivered to a non-contract address with `transfer` function. ERC-20 tokens can be deposited to a contract address with `approve` + `transferFrom` pattern. Depositing ERC-20 tokens to the contract address with `transfer` function will always result in token deposit not being recognized by the recipient contract. + +Here is an example of the contract code that handles ERC-20 token deposit. The following contract can accepts `tokenA` deposits. It is impossible to prevent deposits of tokenA or any other ERC-20 token to this contract that are made with `transfer` function. + +```solidity +contract ERC20Receiver +{ + event Deposit(); + address tokenA; + function deposit(uint _value, address _token) public + { + require(_token == tokenA); + IERC20(_token).transferFrom(msg.sender, address(this), _value); + emit Deposit(); + } +} +``` + +ERC-223 tokens must be delivered to non-contract address or contract address in the same way with `transfer` function. + +Here is an example of the contract code that handles ERC-223 token deposit. The following contract can filter tokens and only accepts `tokenA`. Other ERC-223 tokens would be rejected. + +```solidity +contract ERC223Receiver +{ + event Deposit(); + address tokenA; + function tokenReceived(address _from, uint _value, bytes memory _data) public + { + require(msg.sender == tokenA); + emit Deposit(); + } +} +``` ## Copyright From bf71b97bf2e7b8bb6af7d6dc8db6e68fe2223edc Mon Sep 17 00:00:00 2001 From: Dexaran Date: Sat, 4 Mar 2023 07:02:54 +0400 Subject: [PATCH 46/61] Update eip-223.md --- EIPS/eip-223.md | 81 ++++++++++++++++++++++++------------------------- 1 file changed, 39 insertions(+), 42 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 9cc20399cb4d4f..2c976b9025e172 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -143,19 +143,56 @@ ERC-223 is intended to simplify the interaction with contracts that are intended This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an Ether transaction, or allow for public logging on chain should it be necessary for financial transactions. +## Backwards Compatibility + +The interface of this token is similar to that of ERC-20 and most functions serve the same purpose as their analogues in ERC-20. +`transfer(address, uint256, bytes calldata)` function is not backwards compatible with ERC-20 interface. + +ERC-20 tokens can be delivered to a non-contract address with `transfer` function. ERC-20 tokens can be deposited to a contract address with `approve` + `transferFrom` pattern. Depositing ERC-20 tokens to the contract address with `transfer` function will always result in token deposit not being recognized by the recipient contract. + +Here is an example of the contract code that handles ERC-20 token deposit. The following contract can accepts `tokenA` deposits. It is impossible to prevent deposits of tokenA or any other ERC-20 token to this contract that are made with `transfer` function. + +```solidity +contract ERC20Receiver +{ + event Deposit(); + address tokenA; + function deposit(uint _value, address _token) public + { + require(_token == tokenA); + IERC20(_token).transferFrom(msg.sender, address(this), _value); + emit Deposit(); + } +} +``` + +ERC-223 tokens must be delivered to non-contract address or contract address in the same way with `transfer` function. + +Here is an example of the contract code that handles ERC-223 token deposit. The following contract can filter tokens and only accepts `tokenA`. Other ERC-223 tokens would be rejected. + +```solidity +contract ERC223Receiver +{ + event Deposit(); + address tokenA; + function tokenReceived(address _from, uint _value, bytes memory _data) public + { + require(msg.sender == tokenA); + emit Deposit(); + } +} +``` ## Security Considerations This token utilizes the model similar to plain Ether behavior. Therefore replay issues must be taken into account. - ### Reference Implementation ```solidity pragma solidity ^0.8.19; - library Address { /** * @dev Returns true if `account` is a contract. @@ -343,46 +380,6 @@ contract ERC223Token { ``` -## Backwards compatibility - -The interface of this token is similar to that of ERC-20 and most functions serve the same purpose as their analogues in ERC-20. -`transfer(address, uint256, bytes calldata)` function is not backwards compatible with ERC-20 interface. - -ERC-20 tokens can be delivered to a non-contract address with `transfer` function. ERC-20 tokens can be deposited to a contract address with `approve` + `transferFrom` pattern. Depositing ERC-20 tokens to the contract address with `transfer` function will always result in token deposit not being recognized by the recipient contract. - -Here is an example of the contract code that handles ERC-20 token deposit. The following contract can accepts `tokenA` deposits. It is impossible to prevent deposits of tokenA or any other ERC-20 token to this contract that are made with `transfer` function. - -```solidity -contract ERC20Receiver -{ - event Deposit(); - address tokenA; - function deposit(uint _value, address _token) public - { - require(_token == tokenA); - IERC20(_token).transferFrom(msg.sender, address(this), _value); - emit Deposit(); - } -} -``` - -ERC-223 tokens must be delivered to non-contract address or contract address in the same way with `transfer` function. - -Here is an example of the contract code that handles ERC-223 token deposit. The following contract can filter tokens and only accepts `tokenA`. Other ERC-223 tokens would be rejected. - -```solidity -contract ERC223Receiver -{ - event Deposit(); - address tokenA; - function tokenReceived(address _from, uint _value, bytes memory _data) public - { - require(msg.sender == tokenA); - emit Deposit(); - } -} -``` - ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). From b8463c0fbb6d4e616a5b9353895d89f98dd3fe1a Mon Sep 17 00:00:00 2001 From: Dexaran Date: Sat, 4 Mar 2023 07:04:01 +0400 Subject: [PATCH 47/61] Update EIPS/eip-223.md Co-authored-by: Gavin John --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 2c976b9025e172..d7efaa6efb2651 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -4,7 +4,7 @@ title: 223 Token with communication model description: Token with event handling and communication model author: Dexaran (@Dexaran) discussions-to: https://ethereum-magicians.org/t/erc-223-token-standard/12894 -status: Review +status: Draft type: Standards Track category: ERC created: 2017-05-03 From 52da79f749b8d31a5b5b42cca6101cce4fedfc07 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Mon, 6 Mar 2023 03:19:34 +0400 Subject: [PATCH 48/61] Update EIPS/eip-223.md Co-authored-by: Gavin John --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index d7efaa6efb2651..8919c7c260ef27 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -39,7 +39,7 @@ Token transfers to contracts not implementing `tokenReceived` as described below function totalSupply() view returns (uint256 totalSupply) ``` -Get the total supply of the token. The functionality of the method is similar to `totalSupply()` of ERC-20. +Gets the total supply of the token. The functionality of this method is identical to that of ERC-20. #### `name` From 71ef9532b1b12d4b8b382a3a9d63c49544d32d07 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Mon, 6 Mar 2023 03:19:47 +0400 Subject: [PATCH 49/61] Update EIPS/eip-223.md Co-authored-by: Gavin John --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 8919c7c260ef27..3c97178353fd12 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -47,7 +47,7 @@ Gets the total supply of the token. The functionality of this method is identica function name() view returns (string _name) ``` -Get the name of the token. The functionality of the method is similar to `name()` of ERC-20. +Gets the name of the token. The functionality of this method is identical to that of ERC-20. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. From 936eca6a8c2a67b257631b4fa97ed81c743d8683 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Mon, 6 Mar 2023 03:19:57 +0400 Subject: [PATCH 50/61] Update EIPS/eip-223.md Co-authored-by: Gavin John --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 3c97178353fd12..e5c02f3be656f4 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -57,7 +57,7 @@ OPTIONAL - This method can be used to improve usability, but interfaces and othe function symbol() view returns (bytes32 _symbol) ``` -Get the symbol of token. The functionality of the method is similar to `symbol()` of ERC-20. +Gets the symbol of the token. The functionality of this method is identical to that of ERC-20. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. From bbba42b8da69acefc22945d918f25fd80aeb2807 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Mon, 6 Mar 2023 03:20:07 +0400 Subject: [PATCH 51/61] Update EIPS/eip-223.md Co-authored-by: Gavin John --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index e5c02f3be656f4..07d4d451d0c1ff 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -67,7 +67,7 @@ OPTIONAL - This method can be used to improve usability, but interfaces and othe function decimals() view returns (uint8 _decimals) ``` -Get decimals of token. The functionality of the method is similar to `decimals()` of ERC-20. +Gets the number of decimals of the token. The functionality of this method is identical to that of ERC-20. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. From bd965a393cfb63b4920dbf8dd5cda88dcd7697ca Mon Sep 17 00:00:00 2001 From: Dexaran Date: Mon, 6 Mar 2023 03:20:33 +0400 Subject: [PATCH 52/61] Update EIPS/eip-223.md Co-authored-by: Gavin John --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 07d4d451d0c1ff..0b9f03b418d2c1 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -86,7 +86,7 @@ Get the account balance of another account with address `_owner`. The functional function transfer(address _to, uint _value) returns (bool) ``` -This function must transfer tokens and invoke the function `tokenReceived(address, uint256, bytes calldata)` in `_to`, if `_to` is a contract. If the `tokenReceived` function is not implemented in `_to` (recipient contract), then the transaction must fail and the transfer of tokens must be reverted. +This function must transfer tokens, and if `_to` is a contract, it must call the `tokenReceived(address, uint256, bytes calldata)` function of `_to`. If the `tokenReceived` function is not implemented in `_to` (recipient contract), then the transaction must fail and the transfer of tokens must be reverted. If `_to` is an externally owned address, then the transaction must be sent without executing `tokenReceived` in `_to`. `_data` can be attached to this token transaction and it will stay in blockchain forever (requires more gas). `_data` can be empty. From 5bf8c06240918722fa19638a3abd297375c9b99d Mon Sep 17 00:00:00 2001 From: Dexaran Date: Mon, 6 Mar 2023 03:20:44 +0400 Subject: [PATCH 53/61] Update EIPS/eip-223.md Co-authored-by: Gavin John --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 0b9f03b418d2c1..97521666fd1a76 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -122,7 +122,7 @@ IMPORTANT: This function must be named `tokenReceived` and take parameters `addr event Transfer(address indexed _from, address indexed _to, uint256 _value) ``` -Triggered when tokens are transferred. Compatible with ERC-20 `Transfer` event. The functionality of the event is similar to `Transfer` event of ERC-20. +Triggered when tokens are transferred. Compatible with and similar to the ERC-20 `Transfer` event. ## Rationale From 5735aaa041fddd607f1ace69676f756c4762e7c8 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Mon, 6 Mar 2023 03:21:43 +0400 Subject: [PATCH 54/61] Update EIPS/eip-223.md Co-authored-by: Gavin John --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 97521666fd1a76..2b0010be66744b 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -88,7 +88,7 @@ function transfer(address _to, uint _value) returns (bool) This function must transfer tokens, and if `_to` is a contract, it must call the `tokenReceived(address, uint256, bytes calldata)` function of `_to`. If the `tokenReceived` function is not implemented in `_to` (recipient contract), then the transaction must fail and the transfer of tokens must be reverted. If `_to` is an externally owned address, then the transaction must be sent without executing `tokenReceived` in `_to`. - `_data` can be attached to this token transaction and it will stay in blockchain forever (requires more gas). `_data` can be empty. + `_data` can be attached to this token transaction, but it requires more gas. `_data` can be empty. #### `transfer(address, uint, bytes)` From ab5818b6ae01f4c18bf733f2e62e3326a1f922e7 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Mon, 6 Mar 2023 03:22:01 +0400 Subject: [PATCH 55/61] Update EIPS/eip-223.md Co-authored-by: Gavin John --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 2b0010be66744b..e255af4bd4bdf8 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -98,7 +98,7 @@ function transfer(address _to, uint _value, bytes calldata _data) returns (bool) This function must transfer tokens and invoke the function `tokenReceived (address, uint256, bytes)` in `_to`, if `_to` is a contract. If the `tokenReceived` function is not implemented in `_to` (recipient contract), then the transaction must fail and the transfer of tokens must not occur. If `_to` is an externally owned address, then the transaction must be sent without executing `tokenReceived` in `_to`. - `_data` can be attached to this token transaction and it will stay in blockchain forever (requires more gas). `_data` can be empty. + `_data` can be attached to this token transaction, but it requires more gas. `_data` can be empty. NOTE: A possible way to check whether the `_to` is a contract or an address is to assemble the code of `_to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. From ba4b2d17831ce33e2120d840ce88d8924ae555df Mon Sep 17 00:00:00 2001 From: Dexaran Date: Mon, 6 Mar 2023 03:55:55 +0400 Subject: [PATCH 56/61] update GAS tested values --- EIPS/eip-223.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index e255af4bd4bdf8..b17247b6857965 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -131,9 +131,9 @@ This standard introduces a communication model by enforcing the `transfer` to ex This standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, ERC-223 transfers are more gas-efficient while dealing with depositing to contracts as ERC-223 tokens can be deposited with just one transaction while ERC-20 tokens require at least two calls (one for `approve` and the second that will invoke `transferFrom`). -- [ERC-20](./eip-20.md) deposit: `approve` ~53K gas, `transferFrom` ~80K gas +- [ERC-20](./eip-20.md) deposit: `approve` ~46 gas, `transferFrom` ~80K gas -- ERC-223 deposit: `transfer` and handling on the receivers side ~46K gas +- ERC-223 deposit: `transfer` and handling on the receivers side ~54K gas This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipient side and reject incorrect or improper transactions. This tokens utilize ONE transferring method for both types of interactions with tokens and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes. From 98e74ca41b73fefa9077a6d444b61a60da00ee80 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Mon, 6 Mar 2023 03:58:20 +0400 Subject: [PATCH 57/61] updated the value of transferFrom GAS cost --- EIPS/eip-223.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index b17247b6857965..222be5288b6651 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -131,7 +131,7 @@ This standard introduces a communication model by enforcing the `transfer` to ex This standard sticks to the push transaction model where the transfer of assets is initiated on the senders side and handled on the receivers side. As the result, ERC-223 transfers are more gas-efficient while dealing with depositing to contracts as ERC-223 tokens can be deposited with just one transaction while ERC-20 tokens require at least two calls (one for `approve` and the second that will invoke `transferFrom`). -- [ERC-20](./eip-20.md) deposit: `approve` ~46 gas, `transferFrom` ~80K gas +- [ERC-20](./eip-20.md) deposit: `approve` ~46 gas, `transferFrom` ~75K gas - ERC-223 deposit: `transfer` and handling on the receivers side ~54K gas From 218324b3a5ea80a3c244008bd03e38f26377a469 Mon Sep 17 00:00:00 2001 From: Gavin John Date: Sun, 5 Mar 2023 19:45:42 -0500 Subject: [PATCH 58/61] Apply suggestions from code review --- EIPS/eip-223.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 222be5288b6651..0d29b439629938 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -77,7 +77,7 @@ OPTIONAL - This method can be used to improve usability, but interfaces and othe function balanceOf(address _owner) view returns (uint256 balance) ``` -Get the account balance of another account with address `_owner`. The functionality of the method is similar to `balanceOf(address)` of ERC-20. +Gets the account balance of another account with address `_owner`. The functionality of this method is identical to that of ERC-20. #### `transfer(address, uint)` @@ -97,7 +97,7 @@ function transfer(address _to, uint _value, bytes calldata _data) returns (bool) ``` This function must transfer tokens and invoke the function `tokenReceived (address, uint256, bytes)` in `_to`, if `_to` is a contract. If the `tokenReceived` function is not implemented in `_to` (recipient contract), then the transaction must fail and the transfer of tokens must not occur. -If `_to` is an externally owned address, then the transaction must be sent without executing `tokenReceived` in `_to`. +If `_to` is an externally owned address (determined by the code size being zero), then the transaction must be sent without executing `tokenReceived` in `_to`. `_data` can be attached to this token transaction, but it requires more gas. `_data` can be empty. NOTE: A possible way to check whether the `_to` is a contract or an address is to assemble the code of `_to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. From 5b09164bac7e6be87b8e78fdeb1d99ae57cb8b0e Mon Sep 17 00:00:00 2001 From: Gavin John Date: Mon, 6 Mar 2023 08:08:14 -0500 Subject: [PATCH 59/61] Move receiver to bottom --- EIPS/eip-223.md | 45 ++++++++++++++++++++++----------------------- 1 file changed, 22 insertions(+), 23 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index 0d29b439629938..fd4e56e5bdfba9 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -24,16 +24,15 @@ This token introduces a communication model for contracts that can be utilized t ## Specification - -### Methods - Contracts intending to receive these tokens MUST implement `tokenReceived`. Token transfers to contracts not implementing `tokenReceived` as described below MUST revert. ### Token contract -#### `totalSupply` +#### Token Methods + +##### `totalSupply` ```solidity function totalSupply() view returns (uint256 totalSupply) @@ -41,7 +40,7 @@ function totalSupply() view returns (uint256 totalSupply) Gets the total supply of the token. The functionality of this method is identical to that of ERC-20. -#### `name` +##### `name` ```solidity function name() view returns (string _name) @@ -51,7 +50,7 @@ Gets the name of the token. The functionality of this method is identical to th OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. -#### `symbol` +##### `symbol` ```solidity function symbol() view returns (bytes32 _symbol) @@ -61,7 +60,7 @@ Gets the symbol of the token. The functionality of this method is identical to t OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. -#### `decimals` +##### `decimals` ```solidity function decimals() view returns (uint8 _decimals) @@ -71,7 +70,7 @@ Gets the number of decimals of the token. The functionality of this method is id OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. -#### `balanceOf` +##### `balanceOf` ```solidity function balanceOf(address _owner) view returns (uint256 balance) @@ -79,8 +78,7 @@ function balanceOf(address _owner) view returns (uint256 balance) Gets the account balance of another account with address `_owner`. The functionality of this method is identical to that of ERC-20. - -#### `transfer(address, uint)` +##### `transfer(address, uint)` ```solidity function transfer(address _to, uint _value) returns (bool) @@ -90,7 +88,7 @@ This function must transfer tokens, and if `_to` is a contract, it must call the If `_to` is an externally owned address, then the transaction must be sent without executing `tokenReceived` in `_to`. `_data` can be attached to this token transaction, but it requires more gas. `_data` can be empty. -#### `transfer(address, uint, bytes)` +##### `transfer(address, uint, bytes)` ```solidity function transfer(address _to, uint _value, bytes calldata _data) returns (bool) @@ -100,30 +98,31 @@ This function must transfer tokens and invoke the function `tokenReceived (addre If `_to` is an externally owned address (determined by the code size being zero), then the transaction must be sent without executing `tokenReceived` in `_to`. `_data` can be attached to this token transaction, but it requires more gas. `_data` can be empty. -NOTE: A possible way to check whether the `_to` is a contract or an address is to assemble the code of `_to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. +NOTE: A possible way to check whether the `_to` is a contract or an address is to assemble the code of `_to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract.116 + +#### Events -### Contract that is intended to receive [ERC-223](./eip-223.md) tokens +##### `Transfer` ```solidity -function tokenReceived(address _from, uint _value, bytes calldata _data) +event Transfer(address indexed _from, address indexed _to, uint256 _value) ``` -A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token, `_value` is the amount of incoming tokens, and `_data` is attached data similar to `msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. - -NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the `tokenReceived` function. - -IMPORTANT: This function must be named `tokenReceived` and take parameters `address`, `uint256`, `bytes` to match the function signature `0x8943ec02`. +Triggered when tokens are transferred. Compatible with and similar to the ERC-20 `Transfer` event. -### Events +### [ERC-223](./eip-223.md) Token Receiver -#### `Transfer` +#### Receiver Methods ```solidity -event Transfer(address indexed _from, address indexed _to, uint256 _value) +function tokenReceived(address _from, uint _value, bytes calldata _data) ``` -Triggered when tokens are transferred. Compatible with and similar to the ERC-20 `Transfer` event. +A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token, `_value` is the amount of incoming tokens, and `_data` is attached data similar to `msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing. +NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the `tokenReceived` function. + +IMPORTANT: This function must be named `tokenReceived` and take parameters `address`, `uint256`, `bytes` to match the function signature `0x8943ec02`. ## Rationale From 419550a7027d675a056eecc67c2beaeb1527c41d Mon Sep 17 00:00:00 2001 From: Gavin John Date: Mon, 6 Mar 2023 08:09:57 -0500 Subject: [PATCH 60/61] Remove old function --- EIPS/eip-223.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index fd4e56e5bdfba9..b799f4a2308d81 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -268,14 +268,6 @@ contract ERC223Token { _decimals = new_decimals; } - /** - * @dev ERC223 tokens must explicitly return "erc223" on standard() function call. - */ - function standard() public pure returns (string memory) - { - return "ERC-223"; - } - /** * @dev Returns the name of the token. */ From 1a74ba04ff3ab969ffe94a5f3f0926732148e04c Mon Sep 17 00:00:00 2001 From: Gavin John Date: Mon, 6 Mar 2023 08:10:37 -0500 Subject: [PATCH 61/61] Lint --- EIPS/eip-223.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/EIPS/eip-223.md b/EIPS/eip-223.md index b799f4a2308d81..d2f282d61546f6 100644 --- a/EIPS/eip-223.md +++ b/EIPS/eip-223.md @@ -22,8 +22,8 @@ This token introduces a communication model for contracts that can be utilized t 2. Is more gas-efficient when depositing tokens to contracts. 3. Allows for `_data` recording for financial transfers. - ## Specification + Contracts intending to receive these tokens MUST implement `tokenReceived`. Token transfers to contracts not implementing `tokenReceived` as described below MUST revert. @@ -189,7 +189,6 @@ This token utilizes the model similar to plain Ether behavior. Therefore replay ### Reference Implementation ```solidity - pragma solidity ^0.8.19; library Address { @@ -368,7 +367,6 @@ contract ERC223Token { return true; } } - ``` ## Copyright