This is outdated: The ERC-20 is here: ethereum/EIPs#20
function totalSupply() constant returns (uint256 supply)Get the total coin supply
function balanceOf(address _address) constant returns (uint256 balance)Get the account balance of another account with address _address
function transfer(address _to, uint256 _value) returns (bool _success)Send _value amount of coins to address _to
function transferFrom(address _from, address _to, uint256 _value) returns (bool success)Send _value amount of coins from address _from to address _to
The transferFrom method is used for a "direct debit" workflow, allowing contracts to send coins 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:
function approve(address _address) returns (bool success)Allow _address to direct debit from your account with full custody. Only implement if absolutely required and use carefully. See approveOnce below for a more limited method.
function unapprove(address _address) returns (bool success)Unapprove address _address to direct debit from your account if it was previously approved. Must reset both one-time and full custody approvals.
function isApprovedFor(address _target, address _proxy) constant returns (bool success)Returns 1 if _proxy is allowed to direct debit from _target
function approveOnce(address _address, uint256 _maxValue) returns (bool success)Makes a one-time approval for _address to send a maximum amount of currency equal to _maxValue
function isApprovedOnceFor(address _target, address _proxy) returns (uint256 maxValue)Returns _maxValue if _proxy is allowed to direct debit the returned maxValue from address _target only once. The approval must be reset on any transfer by _proxy of _maxValue or less.
event Transfer(address indexed _from, address indexed _to, uint256 _value)Triggered when tokens are transferred.
event AddressApproval(address indexed _address, address indexed _proxy, bool _result)Triggered when an _address approves _proxy to direct debit from their account.
event AddressApprovalOnce(address indexed _address, address indexed _proxy, uint256 _value)Triggered when an _address approves _proxy to direct debit from their account only once for a maximum of _value
I also think there is a problem with the terminology of cheques since they imply one-offs. Cheques are also unique, and here cheques wouldn't return unique IDs or anything; those are merely approval methods for transfers using internal bookkeeping. I think the current approve/transfer terminology is accurate and simple enough, instead of ending up with a mix of
transferandcashCheque. Would we changeunapprovetotearCheque? There's also that ambiguity of cheques adding up, where approvals more clearly override a previous one.In the use case described by Vitalik of contracts charging fees in subcurrencies, it could easily cost more to have to call
approveOnceeach time (if we replace the currentapprovemethod with it) than the actual fee in subcurrency. For that reason I think we should keep bothapproveandapproveOnce, but we could add the_maxValueargument to the former, that way subscriptions or fees could be taken in multiple calls but only up to a certain amount. Another reason to keep the approval terminology, as I think it's much simpler to describeapproveandapproveOncethan somecreateMultiChequeandcreateCheque. RegardingisApprovedFor, it would have to return the approved amount if we do add_maxValue, just asisApprovedOnceFordoes.@frozeman I'd also like to discuss the addition of decimals, token name and symbol sooner than later. It could really simplify the task of getting a token's basic information into wallets and other dApps, and I think it does belong in a token's contract before a registry.