-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERC: Token standard #20
Comments
recent discussion from https://gist.github.com/frozeman/090ae32041bcfe120824 @vbuterin said: We probably also want function createCheque(address _for, uint256 _maxValue)
function cashCheque(address _from)
function getChequeValue(address _from, address _for) Question: does running createCheque twice add the value of the two cheques together? Are there legitimate use cases for creating a cheque multiple times and then cashing either once or multiple times? @nmushegian said: @niran said: @caktux In the use case described by Vitalik of contracts charging fees in subcurrencies, it could easily cost more to have to call approveOnce each time (if we replace the current approve method with it) than the actual fee in subcurrency. For that reason I think we should keep both |
|
In all method descriptions, let's also remove "coin", eg "Get the total coin supply" -> "Get the total token supply" |
I disagree, as the token is the currency or whatever and to represent it properly in any kind of dapp you need to know what is the proper way to represent that token. Ideally the user has to add only one contract address and the dapp can derive everything from there. Otherwise you make every dapp implement the low level token, plus some high level currency contract API. And not knowing the decimal points can be dangerous, otherwise one user sends 100.00 and another 100 (equals 1.00) |
I'm neither here not there about the terminology. I think "approve" OR "cheque" terminology is good enough. At the end of the day, it seems we need both blanket approvals & once-offs. Or rather, it seems it would be useful to specify 3 things: 1) Total value that can be withdrawn, 2) How many times they can do that, & 3) How much at a time. Spitballing another option: Just one method, called approve (or setCustodian) that takes 2 parameters. How many times they are allowed to withdraw & how much each time? approve(address _for, uint256 _withdraws, uint256 _max) ? @frozeman Regarding names & other information. I agree with @ethers here. There will be tokens minted that don't have any requirement for names, symbols or decimals. Like prediction market outcomes or energy meter kwh tokens for example. This should not be at the token layer. All tokens are not automatically a sub-currency or coin (that uses additional information). |
@frozeman @alexvandesande I think another EIP is needed for "TF Registries" https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs#tf-registries |
Created it here #22 |
( EDIT: add address |
You mean |
@frozeman wrt decimals. Neither really here nor there about it. You can have multiple thresholds as is the case with Ether. The base token is still wei at the end of the day. You can't have decimal wei. You can write the wei in Ether, Finney, Shannon, etc. Each with their own decimal position. Should multiple thresholds be specified? Or only one? If so, is the token name specified to the base unit, or where the decimal point starts? ie Ether or Wei? It's a naming/usability convention, not a specification on how the token actually works. Personally, for most new tokens that will be created, it doesn't really make sense to have them anymore. I do however see scenarios where it can be used. Thus, I'm neutral on this point. Don't mind. Perhaps it should be optional. |
I should be optional sure, but for tokens which will be used in the wallet or user facing stuff, its quite necessary, except you don't want them to be divisible. Concerning multiple steps, i think only one basic step is necessary from there on you can go in But it surely makes a difference if a user accidentally sends 10000 vs 100.00 token units ;) |
No one wants many informational EIPs, but from a design perspective is it better to consider EIPs as composable and keep them modular and lean? For example, an informational EIP for Wallet Tokens could be composed of EIP20, EIP22, EIPX? Let's not forget https://gist.github.com/frozeman/090ae32041bcfe120824#gistcomment-1623513 |
I think its best, when somebody makes a change proposal he list nicely formatted exactly what he would change. In the same as above in the first comment, then these changes are easier to understand, and later move into the actual proposal. Simply:
etc. |
Agreed @frozeman. wrt to this method.
It's still slightly clunky as opposed to true or false (as you mentioned previously @niran). ie having to specify 2**100. We could add a helper function that replicates this internally? ie
it internally calls Any other comments from others on this method? |
Is there a use case for specifying the number of withdrawals? If we're sticking with the approval language, I think the function signatures we started with were fine. You're always granting access to a certain amount of funds, and I don't see a case for caring about the increments those funds are withdrawn in. Display information about tokens, like where to put the decimal point when displaying the native integer value, belongs in a registry. Changing a token contract is hard. Changing a registry entry is easy. |
@ethers decimals, name and symbol are important for displaying to the end user. If Ether was a token then the name would be "ether" with 8 decimal cases, and internally everything would be wei. Just like we do currently. Regarding the approve/cheque discussion, I feel that we should always use focus on paving cow paths: implement what everyone is on absolute consensus as the basic "standard" and then allow real world usage dictate how to better define more advanced use cases. |
@niran true... If you have a subscription, then you someone can anyway withdraw all 12 months in 12 transactions (for example). A future layer could perhaps limit based on timestamps when new withdraws can be made. But let's leave that for later. I agree with @alexvandesande. Let's keep it simple. So we thus we only have 1 approve function?
address _for can withdraw any amount up to _value. If approve is called again, it is not reset, it is simply added to that amount. The transfer is difficult in this scenario, since it doesn't follow the cheque tango. Would it simple mean transferring ALL outstanding value to another custodian? Perhaps we should leave that out for now & "pave the cowpaths" (love this saying). Find the "desire paths". :) I understand why decimals are useful. It just won't matter in a substantial subset of tokens (you won't see them in wallet really). Thus it should be optional. |
Just struck me, it would be great to have some kind of standardized system to pay miners with tokens. You could imagine an user who holds a wallet of various coins, but doesn't know what Ether is. Rather than having to purchase Ether to make a transfer, there could be a |
@simondlr I like this minimal viable approval function and also agree we should see what people build with it before making too broad a standard API |
I think tokens created from the wallets (like what @frozeman demo-ed at Devcon) can include decimals. Because it will be needed in that context (for example), which "paves the cowpaths". :) |
Agree. Are we going to add them to EIP20, or leave them in EIP22? |
I would add them to 20, but mark as optional |
@simondlr i add your suggestion and also changed the order and names for function isApprovedFor(address _allowed, address _for) constant returns (bool success) e.g. And this should probably return the still allowed value, e.g. if you already used up a part. |
^^ it's still ambiguous:
or
Maybe |
Yes, I would say isApprovedFor should return uint256 value, not bool anymore. I like @nmushegian's suggestion of holder & spender. |
For Gnosis it would make sense to add an optional identifier, to handle multiple tokens within one contract. In our use case each outcome for each event represents one type of token. Without an identifier, one contract has to be created for each outcome. A lot of token contracts replicating the same functionality would be written on chain. We think there are many use cases for contracts controlling multiple tokens. E.g. also Weifund has to create a new contract for each campaign. Knowing that there are many use cases for both, we should define a standard for both. Since Solidity allows method overloading we can still use the same function names:
What do you think? |
Proposed improvement to erc20 protocol: The need for this emerges in our case of decentralised token exchange where only token owner is able to change the token's metadata like name of the company, web link etc (subject to decentralised token exchange implementation). There is no other way for such exchange to learn if the information provided is correct without sacrificing decentralisation. |
is this closed? |
Yes: The final standard can be found here: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md |
Yes this is closed as @frozeman says. |
@frozeman @Souptacular It could then be beneficial to lock this thread as no further discussion should happen here. HOWTO: https://help.github.com/articles/locking-conversations/ |
There is a lot of problems caused by ERC20, specifically the bad usage of transfer to contracts supporting usage of approval. |
Thanks @LefterisJP I'll lock it. |
The final standard can be found here: https://eips.ethereum.org/EIPS/eip-20
Abstract
The following describes standard functions a token contract can implement.
Motivation
Those will allow dapps and wallets to handle tokens across multiple interfaces/dapps.
The most important here are,
transfer
,balanceOf
and theTransfer
event.Specification
Token
Methods
NOTE: An important point is that callers should handle
false
fromreturns (bool success)
. Callers should not assume thatfalse
is never returned!totalSupply
Get the total token supply
balanceOf
Get the account balance of another account with address
_owner
transfer
Send
_value
amount of tokens to address_to
transferFrom
Send
_value
amount of tokens from address_from
to address_to
The
transferFrom
method is used for a withdraw workflow, allowing contracts to send tokens on your behalf, for example to "deposit" to a contract address and/or to charge fees in sub-currencies; the command should fail unless the_from
account has deliberately authorized the sender of the message via some mechanism; we propose these standardized APIs for approval:approve
Allow _spender to withdraw from your account, multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value.
allowance
Returns the amount which
_spender
is still allowed to withdraw from_owner
Events
Transfer
Triggered when tokens are transferred.
Approval
Triggered whenever
approve(address _spender, uint256 _value)
is called.History
Historical links related to this standard:
The text was updated successfully, but these errors were encountered: