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
transfer
andcashCheque
. Would we changeunapprove
totearCheque
? 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
approveOnce
each time (if we replace the currentapprove
method with it) than the actual fee in subcurrency. For that reason I think we should keep bothapprove
andapproveOnce
, but we could add the_maxValue
argument 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 describeapprove
andapproveOnce
than somecreateMultiCheque
andcreateCheque
. RegardingisApprovedFor
, it would have to return the approved amount if we do add_maxValue
, just asisApprovedOnceFor
does.@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.