Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upERC223 token standard #223
Comments
This comment has been minimized.
This comment has been minimized.
nmushegian
commented
Mar 5, 2017
•
Have you considered allowing this feature set by extending ERC20 with |
This comment has been minimized.
This comment has been minimized.
The main goals of my proposal were:
|
Dexaran
closed this
Mar 8, 2017
Dexaran
reopened this
Mar 8, 2017
This comment has been minimized.
This comment has been minimized.
Updated my ERC23 token code with a function assembling receiver address to ensure token contract if the receiver is a contract or an address. |
This comment has been minimized.
This comment has been minimized.
nmushegian
commented
Mar 8, 2017
•
Ok I think I see where you are coming from... What about, devs generally seem to want to replace the "execute on transfer" for ETH with a hard coded token interface with no execute on transfer, potentially just ERC20? Is this a bad side effect or a naturally good thing? Doesn't exec-on-transfer make the simplest use cases more complex and maybe more dangerous, while not allowing anything really new? |
This comment has been minimized.
This comment has been minimized.
for contract developers you mean. From users point of view we just need to call 'transfer token' on MEW or |
This comment has been minimized.
This comment has been minimized.
nmushegian
commented
Mar 8, 2017
Contract devs are not being unsympathetic to user experience by nitpicking the semantics of contract code... I understand that (personally I think the real base abstraction is a binary per-address |
This comment has been minimized.
This comment has been minimized.
Well designed token contract assumes you need to trust only contract and ethereum EVM. UI level abstraction assumes you need to trust UI developers. It also requires some things to be done by UI devs. I dont see any abstraction that is required already done. So what reason is to make a lot of requirements and dependencies between contract developers,UI developers and users when there is a way to avoid it. |
This comment has been minimized.
This comment has been minimized.
We were thinking about doing a similar proposal from Aragon while working on economic abstraction for companies. We finally decided approve and transferFrom was a simpler interface and more secure. |
This comment has been minimized.
This comment has been minimized.
Simpler and more secure? What reasons do you have thinking so? I named my reasons. |
This comment has been minimized.
This comment has been minimized.
In the current implementation, if a contract doesn't implement the receiver protocol, the transfer of tokens to an address that happens to be a contract will throw https://github.com/Dexaran/ERC23-tokens/blob/master/ERC23_token.sol#L56 Also I see the problem that the receiver needs to keep a list of what tokens it supports. |
This comment has been minimized.
This comment has been minimized.
Also I didn't know about approveAndCall, but it seems the way to go for me. My two cents, I would be happy to see approveAndCall be part of the standard, but your current solution, while cool, I think it would bring too much overhead to an already very simple and versatile protocol. |
This comment has been minimized.
This comment has been minimized.
There could be a standard to approveAndCall data payload that calls the similar to your so called fallback in your proposal, and the this fallback doing some delegatecall magic could actually call a function in the contract passing the sender and the value as function params. In the fallback function you could do your token accounting and then call whatever function the caller wanted. Sorry for the ramblings, I think I will actually come up with a parallel proposal for this. |
This comment has been minimized.
This comment has been minimized.
As I said earlier it's done to prevent accidentally transactions of tokens to contract address where tokens will not be accessible any more.
My proposal solves a number of problems:
If you found my proposal too complex to accept, then I found this increase in complexity a reasonable price, which should be paid for preventing accidental loss of tokens in the entire future.
I don't see it is a problem but if this is the only thing that prevents the token standard from being accepted I designed a light version of contract-receiver. It will accept every incoming ERC23 token and do nothing with it. It can be called "token-trap" contract. |
This comment has been minimized.
This comment has been minimized.
I do like it, in fact i would also suggest for wallet contracts that the fallback func fires an standard event on the receiving contract called |
frozeman
added
the
ERC
label
Mar 10, 2017
This comment has been minimized.
This comment has been minimized.
@Dexaran those are all good points indeed. Sorry if the feedback seemed harsh, I'm indeed really interested in getting closer to economic abstraction so contracts can operate with tokens in a similar way the can with ether. What do you think about the fallback function being something like |
This comment has been minimized.
This comment has been minimized.
How you mean simulate a payable function? Btw i don't fully understand why a contract should add supported tokens? As long as a contract fires the fallback function, it will be ERC 20 + 23 |
This comment has been minimized.
This comment has been minimized.
Contract that is working with a specified tokens may contrain a mapping of supported tokens.For example if we are working with only |
This comment has been minimized.
This comment has been minimized.
Im not sure if i would make that into the standard, i find the fallback function useful, but as long as they are ERC 20 the contract should be able to deal with it. If he wants to reject certain tokens, than thats something they can do, but it doesn't need to be part of this standard. |
This comment has been minimized.
This comment has been minimized.
By simulate a payable function I mean that after the token fallback is called, a specific function in the contract is called. A rough, pseudo-Solidity implementation would be:
So you could do The only thing that would need to be included in the standard is the case in which transfer has a Also regarding supported tokens, I think if a specific contract wants to only support a set of tokens or blacklist a specific one they can do it as part of their implementation, but I support the idea @that it shouldn't be included in the standard. |
This comment has been minimized.
This comment has been minimized.
@frozeman I would recommend to "reject everything that is not marked as supported" but not "accept everything that is not marked to be rejected" because of when contract like the dao-refund is written it shouldn't accept any of incoming token except DAO. If DAO-token is not ERC23 so there is no way to accept anything ERC23 and we should place |
This comment has been minimized.
This comment has been minimized.
@izqui as I understand it you are recommending to make token transactions behaving one step more similar to Ether transactions. |
This comment has been minimized.
This comment has been minimized.
Exactly. And the actual So extending your comparison you would have:
|
This comment has been minimized.
This comment has been minimized.
Of course. |
This comment has been minimized.
This comment has been minimized.
Something to keep in mind regarding |
This comment has been minimized.
This comment has been minimized.
I see we are 1 step away from creating Token-based Ethereum inside Ether-based Ethereum. function tokenFallback(address _from, uint _value, bytes payload){
if(_data){
delegatecall(this, payload);
} else {
//tokenFallback code here
}
} Because of Ether fallback function handles only transactions of value (ETH). |
Dexaran
changed the title
ERC token standard
ERC23 token standard
Mar 10, 2017
This comment has been minimized.
This comment has been minimized.
I decided that token transaction must contain It's not a solution of any of the problems I'm aiming to solve but it may be needed for future use. As long as there is a way to attach data to Ether transactions I think there should be a way to do the same with token transactions too. |
This comment has been minimized.
This comment has been minimized.
KorbenDallasPewPewPuf
commented
Jul 20, 2018
•
You are talking using |
This comment has been minimized.
This comment has been minimized.
hskang9
commented
Jul 20, 2018
•
References are: |
This comment has been minimized.
This comment has been minimized.
Remi-Burgel
commented
Jul 25, 2018
The more I work with ERC223 the more I doubt about it's current implementation. I'm currently working on a proxy wallet. Same logic as multisig wallets : You CAN transfer ERC223 with this wallet but it's a smart contract and must answer to the interface 'tokenFallback" and it's useless. I can't implement each interface of each proposition just to be sure it will be compatible with each safety implementation like this. We were in a state where a smart contract could do everything that a normal user can do and by restricting their possibilites we are cutting some usecases. |
This comment has been minimized.
This comment has been minimized.
chencho777
commented
Aug 16, 2018
ERC777 has been built to solve some of the shortcomings of ERC223. Please have a look at it: |
This comment has been minimized.
This comment has been minimized.
wuya666
commented
Aug 21, 2018
I'm not sure but why do you remove the approve method? From what I understand approve is not just for contracts, it's also designed to work for people, where you can approve a fellow a certain amount of your token and then increase or decrease the allowance any time you want, instead of sending the token to him/her directly. Also the lost token doesn't look like a real issue anyway, I think one thing about cryptocurrency is that if you send it to the wrong address then you lost it forever. Same goes for the ethers you sent to the wrong address or some wrong contract that does not implement ether withdrawal/self-destruct method, then the ethers are lost forever. |
This comment has been minimized.
This comment has been minimized.
wturyn-cf
commented
Aug 23, 2018
Is |
This comment has been minimized.
This comment has been minimized.
bitsanity
commented
Aug 24, 2018
@wturyn-cf - Ethereum does not allow to overload events, so one has to pick one Transfer definition or the other. In order to claim ERC223-compliance one should use the ERC223 definition. But most popular services, tools and exchanges expect the ERC20 version. |
This comment has been minimized.
This comment has been minimized.
SergioDemianLerner
commented
Aug 28, 2018
I think this standard lacks one more method to token receivers: function isERC223Compatible() pure returns (bool) The reason is that many contracts allow other contracts to register in order to receive tokens later (for example, a syndicated investment contract). This contract must detect if the registered address is able to accept future deposits in ERC223 tokens, but it cannot know this in advance. The only way to know this is to call the tokenFallback manually, and expect the contract will:
However the tokenFallback may interpret the caller is an ERC20 token and call back (e.g. to obtain totalSupply) to the syndicate contract. So syndicate contract must itself implement a fake ERC223 interface just be be able to call tokenFallback for testing purposes. Also the ERC223 interface itself doesn't have any means to show it's ERC223. It also should have a method: Sadly:
So I guess a new standard would be required. |
This comment has been minimized.
This comment has been minimized.
GriffGreen
commented
Sep 17, 2018
@SergioDemianLerner i would check https://eips.ethereum.org/EIPS/eip-777 it's backwards compatible with ERC20 and is pretty much finalized |
This comment has been minimized.
This comment has been minimized.
yoshikazzz
commented
Sep 24, 2018
•
I utilized @Dexaran 's ERC223 implementation, and the logic to check if an address is EOA or contract looks perfect:
but, I found that transferring ERC223 token to the following code of a contract will not revert. It's successfully sent.
It obviously doesn't have tokenFallback function on it, and I debugged that the extcodesize is 396 (>0). I wonder why it got through. |
This comment has been minimized.
This comment has been minimized.
bitsanity
commented
Sep 24, 2018
@yoshikazzz the reason your call succeeded is due to a "feature" of ethereum and it not being a typesafe system. You called tokenFallback() function on BlackHole, but Ethereum could not find that function, so it scanned your contract and found the anonymous function instead. This function is always the default when Ethereum can't find an exact match. |
This comment has been minimized.
This comment has been minimized.
yoshikazzz
commented
Sep 24, 2018
•
@bitsanity Thanks for the explanation. I see how it worked.
If a contract that is not intended to work with ERC20 tokens, but having no name function to take care of incoming ETH, it will accidentally receive ERC20 tokens, and the tokens will get stuck. |
ongrid
referenced this issue
Oct 19, 2018
Open
Etherscan and Metamask don't treat ERC-223 events as transfers #25
This comment has been minimized.
This comment has been minimized.
buhrmi
commented
Oct 26, 2018
•
I just came to the same conclusion as @yoshikazzz I think in order to achieve the initial motivation of this EIP, a contract MUST revert the transaction if the receiver is a contract but I propose to update the spec to
and in order to be ERC223-compliant, all calls to
|
This comment has been minimized.
This comment has been minimized.
friko16
commented
Oct 29, 2018
is ERC-223 standard official for Ethereum ? I don't see it in https://eips.ethereum.org/all in drafts |
This comment has been minimized.
This comment has been minimized.
buhrmi
commented
Oct 30, 2018
Somebody should make a PR. Ill do it by tomorrow unless @Dexaran or somebody else beats me to it. |
This comment has been minimized.
This comment has been minimized.
buhrmi
commented
Oct 30, 2018
•
Hey guys before I open a PR could somebody check if there are any issues with this example implementation? |
This comment has been minimized.
This comment has been minimized.
catageek
commented
Oct 30, 2018
As already said sometimes ago in this thread, ERC777 is more achieved to fix the ERC20 standard. Please have a look at https://github.com/ethereum/EIPs/blob/master/EIPS/eip-777.md |
This comment has been minimized.
This comment has been minimized.
jpthor
commented
Nov 28, 2018
•
Hi @Dexaran can you add the updates to make the ERC223 Standard Solidity v0.5.0 compatible. (https://solidity.readthedocs.io/en/v0.5.0/050-breaking-changes.html) In particular:
Breaks
Also:
Breaks ERC223
Thanks! |
This comment has been minimized.
This comment has been minimized.
Enelar
commented
Dec 3, 2018
@Dexaran I've been reading for hours whole thread, your repo, everything. |
This comment has been minimized.
This comment has been minimized.
buhrmi
commented
Dec 3, 2018
Inside the tokenFallback function, you'd obviously need to check if |
This comment has been minimized.
This comment has been minimized.
FaysalM
commented
Dec 4, 2018
@jpthor is there an audit report you guys had done on the contract? Reading into this, I can't see a valid enough reason to adopt this without more peer review. |
This comment has been minimized.
This comment has been minimized.
MrMabulous
commented
Dec 10, 2018
I think
should emit a different event with the signature
otherwise the info which function was called cannot be recovered from the emitted event. |
This comment has been minimized.
This comment has been minimized.
binary-adam
commented
Dec 13, 2018
•
@Enelar You have to check msg.sender to find out what kind of token you have received anyway, msg.sender is authoritative on how many of that kind of token you own, so trusting it to tell you how many you've received is no increase in trust. |
Dexaran commentedMar 5, 2017
•
edited
Abstract
The following describes standard functions a token contract and contract working with specified token can implement to prevent accidentally sends of tokens to contracts and make token transactions behave like ether transactions.
Motivation
Here is a description of the ERC20 token standard problem that is solved by ERC223:
ERC20 token standard is leading to money losses for end users. The main problem is lack of possibility to handle incoming ERC20 transactions, that were performed via
transfer
function of ERC20 token.If you send 100 ETH to a contract that is not intended to work with Ether, then it will reject a transaction and nothing bad will happen. If you will send 100 ERC20 tokens to a contract that is not intended to work with ERC20 tokens, then it will not reject tokens because it cant recognize an incoming transaction. As the result, your tokens will get stuck at the contracts balance.
How much ERC20 tokens are currently lost (27 Dec, 2017):
QTUM, $1,204,273 lost. watch on Etherscan
EOS, $1,015,131 lost. watch on Etherscan
GNT, $249,627 lost. watch on Etherscan
STORJ, $217,477 lost. watch on Etherscan
Tronix , $201,232 lost. watch on Etherscan
DGD, $151,826 lost. watch on Etherscan
OMG, $149,941 lost. watch on Etherscan
NOTE: These are only 8 token contracts that I know. Each Ethereum contract is a potential token trap for ERC20 tokens, thus, there are much more losses than I showed at this example.
Another disadvantages of ERC20 that ERC223 will solve:
transfer
handling possibility.transfer
. It doesn't matter if the user is depositing to a contract or sending to an externally owned account.Those will allow contracts to handle incoming token transactions and prevent accidentally sent tokens from being accepted by contracts (and stuck at contract's balance).
For example decentralized exchange will no more need to require users to call
approve
then calldeposit
(which is internally callingtransferFrom
to withdraw approved tokens). Token transaction will automatically be handled at the exchange contract.The most important here is a call of
tokenFallback
when performing a transaction to a contract.Specification
Token
Contracts that works with tokens
Methods
NOTE: An important point is that contract developers must implement
tokenFallback
if they want their contracts to work with the specified tokens.If the receiver does not implement the
tokenFallback
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 implementfunction() payable
.totalSupply
Get the total token supply
name
Get the name of token
symbol
Get the symbol of token
decimals
Get decimals of token
balanceOf
Get the account balance of another account with address _owner
transfer(address, uint)
Needed due to backwards compatibility reasons because of ERC20 transfer function doesn't have
bytes
parameter. This function must transfer tokens and invoke the functiontokenFallback(address, uint256, bytes)
in_to
, if _to is a contract. If thetokenFallback
function is not implemented in_to
(receiver contract), then the transaction must fail and the transfer of tokens should not occur.transfer(address, uint, bytes)
function that is always called when someone wants to transfer tokens.
This function must transfer tokens and invoke the function
tokenFallback (address, uint256, bytes)
in_to
, if _to is a contract. If thetokenFallback
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 executetokenFallback
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
Triggered when tokens are transferred.
Contract to work with tokens
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 tomsg.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 thetokenFallback
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 thetokenFallback
function.IMPORTANT: This function must be named
tokenFallback
and take parametersaddress
,uint256
,bytes
to match the function signature0xc0ee0b8a
.Recommended implementation
This is highly recommended implementation of ERC 223 token: https://github.com/Dexaran/ERC23-tokens/tree/Recommended