Token Standard

A standard interface for tokens.

Abstract

This standard allows for the implementation of a standard API for tokens within smart contracts. It provides basic functionality to transfer tokens and allows tokens to be approved so they can be spent by an on-chain third party.

Motivation

A standard interface allows any tokens on Core to be reused by other applications, from wallets to decentralized exchanges.

Specification

Token

Methods

NOTES:

• The following specifications use syntax from Ylem 0.8.4 (or above).
• Callers MUST handle false from returns (bool success). They MUST NOT assume that false is never returned!

name

Returns the name of the token, e.g., "MyToken".

OPTIONAL: This method can improve usability, but interfaces and other contracts MUST NOT expect these values to be present.

function name() external view returns (string memory);

symbol

Returns the symbol of the token, e.g., "CTN".

OPTIONAL: This method can improve usability, but interfaces and other contracts MUST NOT expect these values to be present.

function symbol() external view returns (string memory);

decimals

Returns the number of decimals the token uses. For instance, 8 means dividing the token amount by 100000000 to get its user representation.

OPTIONAL: This method can improve usability, but interfaces and other contracts MUST NOT expect these values to be present.

function decimals() external view returns (uint8);

totalSupply

Returns the total token supply.

function totalSupply() external view returns (uint256);

balanceOf

Returns the account balance of an account with address _owner.

function balanceOf(address _owner) external view returns (uint256 balance);

transfer

Transfers _value amount of tokens to address _to and MUST fire the Transfer event. The function SHOULD revert if the caller's account balance does not have enough tokens to spend.

Note: Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.

function transfer(address _to, uint256 _value) external returns (bool success);

transferFrom

Transfers _value amount of tokens from address _from to address _to, and MUST fire the Transfer event.

The transferFrom method is used for a withdrawal workflow, allowing contracts to transfer tokens on your behalf. This can, for example, allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies. The function SHOULD revert unless the _from account has deliberately authorized the sender of the message via some mechanism.

Note: Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.

function transferFrom(address _from, address _to, uint256 _value) external returns (bool success);

approve

Allows _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.

NOTE: To prevent attack vectors like the one described here, clients SHOULD ensure they create user interfaces that set the allowance first to 0 before setting it to another value for the same spender. However, the contract itself shouldn't enforce this to maintain backward compatibility with contracts deployed earlier.

function approve(address _spender, uint256 _value) external returns (bool success);

allowance

Returns the amount that _spender is still allowed to withdraw from _owner.

function allowance(address _owner, address _spender) external view returns (uint256 remaining);

Events

Transfer

MUST trigger when tokens are transferred, including zero-value transfers.

A token contract that creates new tokens SHOULD trigger a Transfer event with the _from address set to address(0) when tokens are created.

event Transfer(address indexed _from, address indexed _to, uint256 _value);

Approval

MUST trigger on any successful call to approve(address _spender, uint256 _value).

event Approval(address indexed _owner, address indexed _spender, uint256 _value);

Implementation

There are already numerous CBC20-compliant tokens deployed on the Core network. Different implementations have been crafted by various teams, each with its unique trade-offs, ranging from energy efficiency to enhanced security.

Copyright

Copyright and related rights waived via CC0.