From 8c09d952a11e4c7165b6ac06b393a97d436c42a5 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 00:49:57 +0400 Subject: [PATCH 01/16] Create eip-disclosure-of-a-security-flaw-in-erc20-workflow.md --- ...re-of-a-security-flaw-in-erc20-workflow.md | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md diff --git a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md new file mode 100644 index 00000000000000..dff60e5feab787 --- /dev/null +++ b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md @@ -0,0 +1,37 @@ +--- +eip: ? +title: Disclosure of a security flaw in ERC-20 transferring workflow +status: Draft +type: Informational +author: Dexaran (@Dexaran) , Vladimir Vencálek , Yuriy Kharytoshin (@yuriy77k) , Laurent Riche (@spatialiste) +discussions-to: https://ethereum-magicians.org/t/erc-223-token-standard/12894 +created: 2023-10-24 +--- + +## Abstract + +The following describes a security flaw in the transferring workflow of [ERC-20](./eip-20.md) token standard. It must be taken into account that all token standards that declare full backwards compatibility with [ERC-20](./eip-20.md) also inherit this security flaw, for example [ERC-1363](./eip-1363.md]. + +## Motivation + +Security flaw disclosures are an important part of software development. Increasing awareness of the problem helps the development community to implement solutions and minimize the damage that a particular flaw can deal to the users. + +## Specification + +### [ERC-20](./eip-20.md) design overview + +[ERC-20](./eip-20.md) standard declares two methods of transferring tokens: (1) `transfer` function and (2) `approve` & `transferFrom` pattern. `approve` & `transferFrom` is supposed to be used to deposit tokens to contracts. The `transfer` function is supposed to be used for transfers between externally owned addresses however this is not directly written in the specification. If the tokens are sent to a contract address via the `transfer` function then the recipient contract will not recognize the depoist. + +### Security flaw + +**The `transfer` function does not notify the recipient of an incoming transaction which makes error handling impossible.** Error handling is an essential part of secure software development. If tokens are sent to any contract via the `transfer` function and the recipient contract does not support extraction of tokens (i.e. it doesn't implement any functions which would allow to send tokens out) then it is a clear case of user error that must be reverted. For example if a user would send plain ether to a contract that does not explicitly declare that it is intended to accept ether deposits then such transaction would be reverted automatically. In case of [ERC-20](./eip-20.md) tokens a user can push the token contract into incorrect state where a user no longer controls the tokens by picking a wrong function when performing a transaction. + +**A burden of determining the method of transferring tokens is placed on the user in a situation where one option is obviously wrong and will result in a loss of funds.** Prompting a user to make a decision on the internal logic of the contract combined with the lack of an implementation of error handling for users actions is another security failure that can result in incorrect token contract behavior and a loss of funds for the end user. + +### Token losses + +As of 17.08.2023 $201,690,741 worth of [ERC-20](./eip-20.md) tokens were lost in top 50 (measured by transactions count) token contracts due to the described problem of the standard. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 42c9a78cdfffdfae9a4132226d871026f340204b Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 01:06:03 +0400 Subject: [PATCH 02/16] Update eip-disclosure-of-a-security-flaw-in-erc20-workflow.md --- EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md index dff60e5feab787..823e836ee80d72 100644 --- a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md +++ b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md @@ -4,13 +4,13 @@ title: Disclosure of a security flaw in ERC-20 transferring workflow status: Draft type: Informational author: Dexaran (@Dexaran) , Vladimir Vencálek , Yuriy Kharytoshin (@yuriy77k) , Laurent Riche (@spatialiste) -discussions-to: https://ethereum-magicians.org/t/erc-223-token-standard/12894 +discussions-to: https://ethereum-magicians.org/t/disclosure-of-a-security-flaw-in-erc-20-transferring-workflow/16249 created: 2023-10-24 --- ## Abstract -The following describes a security flaw in the transferring workflow of [ERC-20](./eip-20.md) token standard. It must be taken into account that all token standards that declare full backwards compatibility with [ERC-20](./eip-20.md) also inherit this security flaw, for example [ERC-1363](./eip-1363.md]. +The following describes a security flaw in the transferring workflow of [ERC-20](./eip-20.md) token standard. It must be taken into account that all token standards that declare full backwards compatibility with [ERC-20](./eip-20.md) also inherit this security flaw, for example [ERC-1363](./eip-1363.md). ## Motivation From 0aca7531b04f3f51921b9da23822fea8903f6533 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 01:13:25 +0400 Subject: [PATCH 03/16] Update eip-disclosure-of-a-security-flaw-in-erc20-workflow.md --- EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md index 823e836ee80d72..e08ed4cfb9248d 100644 --- a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md +++ b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md @@ -1,10 +1,11 @@ --- eip: ? title: Disclosure of a security flaw in ERC-20 transferring workflow -status: Draft +description: Disclosure of a security flaw in ERC-20 transferring method that caused a loss of $201,690,741 as of 17.08.2023. type: Informational author: Dexaran (@Dexaran) , Vladimir Vencálek , Yuriy Kharytoshin (@yuriy77k) , Laurent Riche (@spatialiste) discussions-to: https://ethereum-magicians.org/t/disclosure-of-a-security-flaw-in-erc-20-transferring-workflow/16249 +status: Draft created: 2023-10-24 --- From f1558c41764df4c1d04595ab65318b43ad46d6a9 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 01:37:48 +0400 Subject: [PATCH 04/16] Update eip-disclosure-of-a-security-flaw-in-erc20-workflow.md --- ...re-of-a-security-flaw-in-erc20-workflow.md | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md index e08ed4cfb9248d..f27f112669a3fe 100644 --- a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md +++ b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md @@ -2,10 +2,10 @@ eip: ? title: Disclosure of a security flaw in ERC-20 transferring workflow description: Disclosure of a security flaw in ERC-20 transferring method that caused a loss of $201,690,741 as of 17.08.2023. -type: Informational author: Dexaran (@Dexaran) , Vladimir Vencálek , Yuriy Kharytoshin (@yuriy77k) , Laurent Riche (@spatialiste) discussions-to: https://ethereum-magicians.org/t/disclosure-of-a-security-flaw-in-erc-20-transferring-workflow/16249 status: Draft +type: Informational created: 2023-10-24 --- @@ -13,7 +13,7 @@ created: 2023-10-24 The following describes a security flaw in the transferring workflow of [ERC-20](./eip-20.md) token standard. It must be taken into account that all token standards that declare full backwards compatibility with [ERC-20](./eip-20.md) also inherit this security flaw, for example [ERC-1363](./eip-1363.md). -## Motivation +## Rationale Security flaw disclosures are an important part of software development. Increasing awareness of the problem helps the development community to implement solutions and minimize the damage that a particular flaw can deal to the users. @@ -31,7 +31,23 @@ Security flaw disclosures are an important part of software development. Increas ### Token losses -As of 17.08.2023 $201,690,741 worth of [ERC-20](./eip-20.md) tokens were lost in top 50 (measured by transactions count) token contracts due to the described problem of the standard. +As of 17.08.2023 $201,690,741 worth of [ERC-20](./eip-20.md) tokens were lost in top 50 (measured by transactions count) token contracts due to the described problem of the standard. + +## Security Considerations + +- The best option is to avoid using [ERC-20](./eip-20.md) tokens and to upgrade the ecosystem to a more secure token standard that (1) **properly supports error handling and notifies recipients** of incoming transfers, (2) **automatically determines the transferring method** if token transfers to externally owned accounts and to contracts are performed differently without prompring a user to make any decisions that can potentially push the contract in incorrect state or result in any errors, (3) **abstracts the user from the internal logic of the contract**. +- It could be possible to apply a patch on [ERC-20](./eip-20.md) standard by disallowing the use of `transfer` function to deposit tokens to contracts. This would introduce a breaking change to the "final" [EIP-20](./eip-20.md) and therefore is not possible according to EIP process. +- Any implementor of a [ERC-20](./eip-20.md) token must be aware of the issue and describe it in the most visible form. Developers and users MUST be notified of an issue. +- Any developer of a UI that operates with tokens MUST perform additional checks when a user is transferring tokens via `transfer` function. If the recipient is a contract then the user must receive a wraning message stating that he/she is transferring tokens to a contract directly and it can result in tokens being stuck there without an option to recover them. It is a common user mistake that (for some reason) can't be prevented on the contract level. Ideally the UI must also check if the recipient is a contract that is known to not be intended to receive tokens such as a contract of another token, ENS contract or most other contracts except multisigs. +- Any contract deployed on Ethereum mainnet MUST expect that there would be "stuck" ERC-20 tokens accidentally deposited to the contract address. A special function to withdraw tokens MUST be implemented. + +``` +function rescueERC20(address _token) onlyOwner external +{ + amount = IERC20(_token).balanceOf(address(this)); + IERC20(_token).transfer(msg.sender, amount); +} +``` ## Copyright From 898b2d2e636257373f7ac0e114375cd5bfeecb64 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 01:40:13 +0400 Subject: [PATCH 05/16] Update eip-disclosure-of-a-security-flaw-in-erc20-workflow.md --- EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md index f27f112669a3fe..287ee2564bc229 100644 --- a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md +++ b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md @@ -7,6 +7,7 @@ discussions-to: https://ethereum-magicians.org/t/disclosure-of-a-security-flaw-i status: Draft type: Informational created: 2023-10-24 +requires: [ERC-20](./eip-20.md), [ERC-1363](./eip-1363.md) --- ## Abstract From dd3d79e1a370ea2c970c540df2137ab12b6010d7 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 01:41:20 +0400 Subject: [PATCH 06/16] Update eip-disclosure-of-a-security-flaw-in-erc20-workflow.md --- EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md index 287ee2564bc229..d452d3d23d24d2 100644 --- a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md +++ b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md @@ -7,7 +7,7 @@ discussions-to: https://ethereum-magicians.org/t/disclosure-of-a-security-flaw-i status: Draft type: Informational created: 2023-10-24 -requires: [ERC-20](./eip-20.md), [ERC-1363](./eip-1363.md) +requires: 20, 1363 --- ## Abstract From 008feca1d44966469faa2023cb60e3bd9245d399 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 01:43:13 +0400 Subject: [PATCH 07/16] Update eip-disclosure-of-a-security-flaw-in-erc20-workflow.md --- EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md index d452d3d23d24d2..6bdea5b029fb33 100644 --- a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md +++ b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md @@ -1,6 +1,6 @@ --- eip: ? -title: Disclosure of a security flaw in ERC-20 transferring workflow +title: Security flaw disclosure in ERC-20 workflow description: Disclosure of a security flaw in ERC-20 transferring method that caused a loss of $201,690,741 as of 17.08.2023. author: Dexaran (@Dexaran) , Vladimir Vencálek , Yuriy Kharytoshin (@yuriy77k) , Laurent Riche (@spatialiste) discussions-to: https://ethereum-magicians.org/t/disclosure-of-a-security-flaw-in-erc-20-transferring-workflow/16249 From 97300ed11aaa681750252398eb902055a1ff5cd3 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 01:43:39 +0400 Subject: [PATCH 08/16] Update eip-disclosure-of-a-security-flaw-in-erc20-workflow.md --- EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md index 6bdea5b029fb33..d47a14467c21e2 100644 --- a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md +++ b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md @@ -1,5 +1,5 @@ --- -eip: ? +eip: 7915 title: Security flaw disclosure in ERC-20 workflow description: Disclosure of a security flaw in ERC-20 transferring method that caused a loss of $201,690,741 as of 17.08.2023. author: Dexaran (@Dexaran) , Vladimir Vencálek , Yuriy Kharytoshin (@yuriy77k) , Laurent Riche (@spatialiste) From a1d9e2fad0c85e7b00c06ffb127895bd8c3e2b1a Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 01:45:52 +0400 Subject: [PATCH 09/16] Update eip-disclosure-of-a-security-flaw-in-erc20-workflow.md --- ...-disclosure-of-a-security-flaw-in-erc20-workflow.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md index d47a14467c21e2..a5402ed1984c24 100644 --- a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md +++ b/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md @@ -14,10 +14,6 @@ requires: 20, 1363 The following describes a security flaw in the transferring workflow of [ERC-20](./eip-20.md) token standard. It must be taken into account that all token standards that declare full backwards compatibility with [ERC-20](./eip-20.md) also inherit this security flaw, for example [ERC-1363](./eip-1363.md). -## Rationale - -Security flaw disclosures are an important part of software development. Increasing awareness of the problem helps the development community to implement solutions and minimize the damage that a particular flaw can deal to the users. - ## Specification ### [ERC-20](./eip-20.md) design overview @@ -34,10 +30,14 @@ Security flaw disclosures are an important part of software development. Increas As of 17.08.2023 $201,690,741 worth of [ERC-20](./eip-20.md) tokens were lost in top 50 (measured by transactions count) token contracts due to the described problem of the standard. +## Rationale + +Security flaw disclosures are an important part of software development. Increasing awareness of the problem helps the development community to implement solutions and minimize the damage that a particular flaw can deal to the users. + ## Security Considerations - The best option is to avoid using [ERC-20](./eip-20.md) tokens and to upgrade the ecosystem to a more secure token standard that (1) **properly supports error handling and notifies recipients** of incoming transfers, (2) **automatically determines the transferring method** if token transfers to externally owned accounts and to contracts are performed differently without prompring a user to make any decisions that can potentially push the contract in incorrect state or result in any errors, (3) **abstracts the user from the internal logic of the contract**. -- It could be possible to apply a patch on [ERC-20](./eip-20.md) standard by disallowing the use of `transfer` function to deposit tokens to contracts. This would introduce a breaking change to the "final" [EIP-20](./eip-20.md) and therefore is not possible according to EIP process. +- It could be possible to apply a patch on [ERC-20](./eip-20.md) standard by disallowing the use of `transfer` function to deposit tokens to contracts. This would introduce a breaking change to the "final" standard and therefore is not possible according to EIP process. - Any implementor of a [ERC-20](./eip-20.md) token must be aware of the issue and describe it in the most visible form. Developers and users MUST be notified of an issue. - Any developer of a UI that operates with tokens MUST perform additional checks when a user is transferring tokens via `transfer` function. If the recipient is a contract then the user must receive a wraning message stating that he/she is transferring tokens to a contract directly and it can result in tokens being stuck there without an option to recover them. It is a common user mistake that (for some reason) can't be prevented on the contract level. Ideally the UI must also check if the recipient is a contract that is known to not be intended to receive tokens such as a contract of another token, ENS contract or most other contracts except multisigs. - Any contract deployed on Ethereum mainnet MUST expect that there would be "stuck" ERC-20 tokens accidentally deposited to the contract address. A special function to withdraw tokens MUST be implemented. From bd68232f71f106cdd096efb45e8e0846c6e9f6f2 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 01:47:10 +0400 Subject: [PATCH 10/16] Rename eip-disclosure-of-a-security-flaw-in-erc20-workflow.md to eip-7915.md --- ...losure-of-a-security-flaw-in-erc20-workflow.md => eip-7915.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-disclosure-of-a-security-flaw-in-erc20-workflow.md => eip-7915.md} (100%) diff --git a/EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md b/EIPS/eip-7915.md similarity index 100% rename from EIPS/eip-disclosure-of-a-security-flaw-in-erc20-workflow.md rename to EIPS/eip-7915.md From d775b1c93d1ae038cf9ffd595b797765494f721a Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 17:11:21 +0400 Subject: [PATCH 11/16] Update EIPS/eip-7915.md Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com> --- EIPS/eip-7915.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7915.md b/EIPS/eip-7915.md index a5402ed1984c24..682bb3784f0257 100644 --- a/EIPS/eip-7915.md +++ b/EIPS/eip-7915.md @@ -1,5 +1,5 @@ --- -eip: 7915 +eip: 7544 title: Security flaw disclosure in ERC-20 workflow description: Disclosure of a security flaw in ERC-20 transferring method that caused a loss of $201,690,741 as of 17.08.2023. author: Dexaran (@Dexaran) , Vladimir Vencálek , Yuriy Kharytoshin (@yuriy77k) , Laurent Riche (@spatialiste) From f065ea17884c4932882696d2b7df1cb6bef65782 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 17:11:30 +0400 Subject: [PATCH 12/16] Update EIPS/eip-7915.md Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com> --- EIPS/eip-7915.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7915.md b/EIPS/eip-7915.md index 682bb3784f0257..94ad7e412aef06 100644 --- a/EIPS/eip-7915.md +++ b/EIPS/eip-7915.md @@ -18,7 +18,7 @@ The following describes a security flaw in the transferring workflow of [ERC-20] ### [ERC-20](./eip-20.md) design overview -[ERC-20](./eip-20.md) standard declares two methods of transferring tokens: (1) `transfer` function and (2) `approve` & `transferFrom` pattern. `approve` & `transferFrom` is supposed to be used to deposit tokens to contracts. The `transfer` function is supposed to be used for transfers between externally owned addresses however this is not directly written in the specification. If the tokens are sent to a contract address via the `transfer` function then the recipient contract will not recognize the depoist. +[ERC-20](./eip-20.md) standard declares two methods of transferring tokens: (1) `transfer` function and (2) `approve` & `transferFrom` pattern. `approve` & `transferFrom` is supposed to be used to deposit tokens to contracts. The `transfer` function is supposed to be used for transfers between externally owned addresses however this is not directly written in the specification. If the tokens are sent to a contract address via the `transfer` function then the recipient contract will not recognize the deposit. ### Security flaw From 58bd593b3f9abff6df1708bcb1e94ac741fabf02 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Wed, 25 Oct 2023 17:16:02 +0400 Subject: [PATCH 13/16] Update and rename eip-7915.md to eip-7544.md --- EIPS/{eip-7915.md => eip-7544.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename EIPS/{eip-7915.md => eip-7544.md} (96%) diff --git a/EIPS/eip-7915.md b/EIPS/eip-7544.md similarity index 96% rename from EIPS/eip-7915.md rename to EIPS/eip-7544.md index 94ad7e412aef06..240535b411f241 100644 --- a/EIPS/eip-7915.md +++ b/EIPS/eip-7544.md @@ -1,7 +1,7 @@ --- eip: 7544 -title: Security flaw disclosure in ERC-20 workflow -description: Disclosure of a security flaw in ERC-20 transferring method that caused a loss of $201,690,741 as of 17.08.2023. +title: Security Flaws in ERC-20 Transfer Patterns +description: Desctiption of a security flaw in ERC-20 transferring workflow that caused a loss of $201,690,741 as of 17.08.2023. author: Dexaran (@Dexaran) , Vladimir Vencálek , Yuriy Kharytoshin (@yuriy77k) , Laurent Riche (@spatialiste) discussions-to: https://ethereum-magicians.org/t/disclosure-of-a-security-flaw-in-erc-20-transferring-workflow/16249 status: Draft From 8364b0ebd899a1439c08bfe6bb054e8286fd14d7 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Nov 2023 06:22:45 +0400 Subject: [PATCH 14/16] Update EIPS/eip-7544.md Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com> --- EIPS/eip-7544.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7544.md b/EIPS/eip-7544.md index 240535b411f241..ad6e26f0edbc16 100644 --- a/EIPS/eip-7544.md +++ b/EIPS/eip-7544.md @@ -1,7 +1,7 @@ --- eip: 7544 title: Security Flaws in ERC-20 Transfer Patterns -description: Desctiption of a security flaw in ERC-20 transferring workflow that caused a loss of $201,690,741 as of 17.08.2023. +description: Description of a security flaw in ERC-20 transferring workflow that caused a loss of $201,690,741 as of 17.08.2023. author: Dexaran (@Dexaran) , Vladimir Vencálek , Yuriy Kharytoshin (@yuriy77k) , Laurent Riche (@spatialiste) discussions-to: https://ethereum-magicians.org/t/disclosure-of-a-security-flaw-in-erc-20-transferring-workflow/16249 status: Draft From 06b4ad2d4b2ad1b90f2d293d6d0652012cbd3df7 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Nov 2023 06:57:53 +0400 Subject: [PATCH 15/16] Update EIPS/eip-7544.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-7544.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7544.md b/EIPS/eip-7544.md index ad6e26f0edbc16..65424fac7fa928 100644 --- a/EIPS/eip-7544.md +++ b/EIPS/eip-7544.md @@ -16,7 +16,7 @@ The following describes a security flaw in the transferring workflow of [ERC-20] ## Specification -### [ERC-20](./eip-20.md) design overview +### [ERC-20](./eip-20.md) Design Overview [ERC-20](./eip-20.md) standard declares two methods of transferring tokens: (1) `transfer` function and (2) `approve` & `transferFrom` pattern. `approve` & `transferFrom` is supposed to be used to deposit tokens to contracts. The `transfer` function is supposed to be used for transfers between externally owned addresses however this is not directly written in the specification. If the tokens are sent to a contract address via the `transfer` function then the recipient contract will not recognize the deposit. From 2d81662eebb3983e91ecc7927eed86fd8c2441e6 Mon Sep 17 00:00:00 2001 From: Dexaran Date: Fri, 10 Nov 2023 07:30:27 +0400 Subject: [PATCH 16/16] Update EIPS/eip-7544.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-7544.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7544.md b/EIPS/eip-7544.md index 65424fac7fa928..2c60fb4cd40800 100644 --- a/EIPS/eip-7544.md +++ b/EIPS/eip-7544.md @@ -18,7 +18,7 @@ The following describes a security flaw in the transferring workflow of [ERC-20] ### [ERC-20](./eip-20.md) Design Overview -[ERC-20](./eip-20.md) standard declares two methods of transferring tokens: (1) `transfer` function and (2) `approve` & `transferFrom` pattern. `approve` & `transferFrom` is supposed to be used to deposit tokens to contracts. The `transfer` function is supposed to be used for transfers between externally owned addresses however this is not directly written in the specification. If the tokens are sent to a contract address via the `transfer` function then the recipient contract will not recognize the deposit. +[ERC-20](./eip-20.md) standard declares two methods of transferring tokens: (1) `transfer` function and (2) `approve` & `transferFrom` pattern. `approve` & `transferFrom` are supposed to be used to deposit tokens to contracts. The `transfer` function is supposed to be used for transfers between externally owned addresses however this is not directly written in the specification. If the tokens are sent to a contract address via the `transfer` function then the recipient contract will not recognize the deposit. ### Security flaw