Closed Dexaran closed 7 years ago
This proporsal has a new mechanism to protect token tranfers to dead or incorrect contacts, but not fully compatible with original EIP20. I think we have to back compatible with EIP20 at any costs.
ERC23 token is compatible with every contract that uses ERC20 token interface. In fact the only difference in transfer
is if the address-receiver is a contract then call transferToContract
otherwise call basic transferToAddress
that works similar to transfer
in ERC20. Every contract working with ERC20 assumes you should use approval
then transferFrom
but not a directly transfer
to contract address. approval
and transferFrom
is fully supported at ERC23 so there is no difference between ERC20 and ERC23 deposits handled by old contracts. The only limitation is you cant transfer
ERC23 in old contract while you can transfer
ERC20 and it will cause a loss of your ERC20 tokens. For example you are unable to transfer any ERC23 to dao-refund contract while you can transfer BEC in dao-refund and BEC will not be accessible any more for anyone inside dao-refund.
I think we have to make 'transferToContract' public and leave the old semantics of the method 'transfer'.
It will cause division of transactions to basic transfer
(for addresses) and transferToContract
(for contracts) as I suggested earlier. It will allow to call transfer
function and send your tokens anywhere you want again. It was the main reason I decided to modify basic transfer
as far as your suggestion will not add any more backward compatibility.
At the other hand your suggestion to divide transferring functions assumes that UI dev will filter receiver address and decide which function to call. It means you are depending on UI dev and should trust him. I cant see any reason for doing so while there is a way to avoid it.
I decided that token transaction must contain bytes data
.
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. I don't care how exactly this will be used to attach HEX messages to token transactions or to encode inner functions execution but the way to attach data to the transaction (token or Ether) must exist.
I need more feedback to be sure what is the most important thing right now: backwards compatibility or future usability of accepted token standard.
Now ERC23 is 100% backwards compatible with ERC20 and will work with every old contract designed to work with ERC20 tokens.
You can send token transaction via MEW or even using ERC20 ABI and there will be no problems with it as ERC23 is now supporting both versions of transfer(address, uint, bytes)
and transfer(address, uint)
I support this ECIP. I think it should be bumped for wider review.
There is a vulnurability in approve
function so I'm thinking on removing it from ERC23 standard as it will never be needed any more because of tokenFallback
implementation.
vulnerability is described here
I'm asking for more feedback about is approve
needed and in what cases. I'm about to remove approve
and transferFrom
at all with break of backwards compatibility.
@Dexaran if it's ready for Draft, let's merge it
This is ready for draft.
lgtm
@Dexaran could you rename it to ECIP_1021.md
-> ECIP-1021.md
?
Approved review required: https://github.com/Dexaran/ECIPs/pull/1
Only reviews by reviewers with write access count towards mergeability. BTW, which person decides who should have write access, and who should not?
@Dexaran could you rename ECIP_1021.md to ECIP-1021.md before merge?
I can't. It is a protected branch and I have no write access (?). I can't change anything even in my forked branch without an "approved review".
@Dexaran could you try again?
There is too much discussion on nonsense details. Let someone with write access merge it as-is and then rename into ECIP-1021.md
. I don't see any problems here.
ERC: 223 Title: Token standard Author: Dexaran, dexaran820@gmail.com Status: Draft Type: ERC Created: 5-03.2017 Resolution: https://github.com/Dexaran/ERC23-tokens ERC20 compatible example: https://github.com/Dexaran/ERC23-tokens/blob/ERC20_compatible/ERC23_token.sol
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
Problems of ERC20 that ERC223 will solve:
transfer
. Doesn't matter is user depositing in 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. For example decentralized exchange will no more need to force users to call
approve
at token contract then calldeposit
that is callingtransferFrom
taking allowed tokens. Token transaction will automatically be handled inside the exchange contract.The most important here is a call of
tokenFallback
when performing a transaction to a contract.Specification
Token Contracts that work 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, 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.IMPORTANT: Token fallback function that will be called at receiver contract must be named
tokenFallback
and take parametersaddress
,uint256
,bytes
. This function must have0xc0ee0b8a
signature.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.IMPORTANT: Token fallback function that will be called at receiver contract must be named
tokenFallback
and take parametersaddress
,uint256
,bytes
. This function must have0xc0ee0b8a
signature.Events
Transfer
Triggered when tokens are transferred.
Contract to work with tokens
A function to handle token transfers that is called from token contract when token holder is sending tokens.
_from
is a token sender,_value
is amount of incoming tokens and_data
is attached data similar to data in Ether transactions. Works like fallback function for 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