Skip to main content


Dfinity Fungible Token Standard

DFT means Dfinity Fungible Token.


Token standard will help Dfinity developers to adopt the same standard and promote the prosperity of the Dfinity ecosystem

Rules of Token Standard Design

ERC20 is the first fungible token standard in the blockchain world, and it has been fully verified and recognized. It is necessary to refer to the existing ERC20 standard when designing the [Dfinity Fungible Token Standard].

The design of [Dfinity Fungible Token Standard] will follow the following rules:

  1. Improving the ERC20 standard

  2. Suitable for Dfinity

Improve ERC20 standard

How to improve ERC20

ERC20 was created in the early days of Ethereum. During the development of the Eth ecosystem, the developer found that ERC20 was not perfect, so the developer designed the ERC223\ERC667\ERC777 standards to improve ERC20. We will design a better standard that combines all the advantages of these standards.

  1. ERC223

    • tries to solve the problem that the ERC20 transfer recipient (contract) does not support the transfer of tokens, and the transferred tokens will get lost (similar to sending tokens to a black hole address)
  2. ERC667

    • adds transferAndCall which combines transfer function and call function, and solve the problems that is already solved by ERC223
  3. ERC777

    • use send function to replace transfer function
    • use the hook function to control whether to accept transfer or not
    • use the operator authorization function to replace the approve function as a proxy transfer solution

Improved standards

service: {
name: () -> (text) query;
symbol: () -> (text) query;
decimals: () -> (nat8) query;
totalSupply: () -> (nat) query;

balanceOf: (owner: principal) -> (nat) query;
allowance: (owner: principal, spender: principal) -> (nat) query;
approve: (spender: principal, value: nat) -> (bool);
transferFrom: (sender: principal, receiver: principal, value: nat) -> (bool);
transfer: (receiver: principal, value: nat, args:opt vec nat8) -> (bool);

Suitable for Dfinity

Problems to be solved

The design of Token Standard will fully consider the difference between Dfinity and Ethereum, and clarify the problems with solutions:

  1. No atomicity that's similar to EVM cross-contract calls
  • Solution: sagas is a good solution
  1. No built-in event-emit support that's similar to EVM
  • Question:

    • How do others know the transaction happened?
    • How to check transaction history?
  • Considerations: There are two ideas (Pubsub/Notify) for question 1 on the forum

    • When the Token is transferred, Notification informs the recipient, which can fill the missing EVENT. But When the Token recipient is not a canister, which means they can not be notify, it is necessary to support query transaction history.

    • Token does not have sufficient reason to implement Pub/Sub to release transaction information to a third party that is not the recipient

  • Solution:

    • Notify is a better way;
    • It's necessary to support query transaction history;
  1. Built-in storage support
  • Question: The current storage has increased to 8G, but the memory storage is still 4G

  • Considerations:

    • Tx history should support query

    • Built-in storage can support Token to store more self-describing information

  • Solution:

    • Auto-scaling storage solution
    • Token implements self-description
  1. Reverse gas model
  • Question: How to prevent ddos attacks

  • Consideration: The call of the canister does not require the caller to pay gas fees(canister pay the gas fees)

  • Solution: Any update call to canister should be charged to the caller

  1. There are two different identities in Dfinity, Internet Identity (II for short) and Principal ID
  • Question: Which identity should a token standard user adopt?

  • Consideration: Dfinity's II is an implementation of DID, and II is based on Principal ID

  • Solution: It is necessary for the Token standard to be compatible with both identity, in order to meet the needs of different identity scenarios

  1. No black hole address
  • Question: If there is a need to destroy Token, how to deal with it?

  • Consideration: Whether to implement the burn interface in the Token standard

  • Solution: The burn interface does not need to be put in the standard, it can be designed in the extension interface

  1. approve/transferFrom (Approve is a pairing function for TransferFrom)
  • Question: There was a disagreement about whether the approval/transfer should be removed in the discussion on the forum

  • Considerations:

    approve/transferFrom appears in ERC20 mainly because:

    Using Ethereum's native ETH token, you can call the smart contract function and send ETH to the contract at the same time. This is done using payable. But because the ERC20 token itself is a smart contract, it is not possible to directly send the token to the smart contract while calling one of its functions; therefore, the ERC20 standard allows smart contracts to transfer tokens on behalf of the user who is using the transferFrom() function. For this, users need to allow smart contracts to transfer these tokens on their behalf

    However, in the Dex and lending scenarios of Ethereum, Approve is often accompanied by the possibility of simultaneous operation of two tokens. Approve can avoid the repeated payment problem which transaction brought in, and it also has a good supplementary applicable scenario for transfer.

  • Solution: Approve/transferFrom should be retained

  1. TransferAndCall vs Receiver Notify
  • Question: which option is more plasusible
  • Considerations:
    • Notify can meet the basic notification needs. Although it cannot support better flexibility, it is sufficient to meet the transfer scenario
    • TransferAndCall provides a better flexibility, but it depends on the transfer caller whether or not fully understand the method and parameters corresponding to the call, which is not needed for most transfer scenarios
    • For security reasons, do not call the canister of the location inside the canister,why?Inter-canister calls
  • Solution:
    • Notify is supported (cdk0.5.1, one-way notify)
  1. ApproveAndCall VS TransferAndCall
  • Question: We compare ApproveAndCall and TransferAndCall. ApproveAndCall and TransferAndCall are two sets of non-atomic operations, there are no differences essentially. Which one should be retained?

  • Consideration: In some scenarios, when multiple Tokens need to be transferred at the same time, TransferAndCall can not meet such requirement. After approval, execute transferFrom in the final call to pay multiple tokens at once

  • For security reasons like Q8

  • Solution: call is not supported

  1. Nonce
  • Question: What Is Nonce In Ethereum? Every transaction has a nonce. The nonce is the number of transactions sent from a given address. Each time you send a transaction, the nonce increases by 1. There are rules about what transactions are valid, and the nonce is used to enforce some of these rules. Does Dfinity's token standard need to incorporate a nonce mechanism?

  • Consideration:If the nonce mechanism is supported, it can prevent users from repeatedly submitting transactions

  • Solution: use created time to implement a simple nonce mechanism

What other functions does the Dfinity Fungible Token standard need to implement?

Information self-describing

Etherscan, MyEthereumWallet, Imtoken, TokenPocket, Dapps all have more information requirements for ERC20, such as Logo, introduction, white paper, social media, official website, contact information, etc. Due to the need that each of them requires independently maintained information, which caused the inconsistent information. Therefore, it is necessary to solve this problem through the design of [Dfinity Fungible Token Standard]

The following draft standards are formulated based on the problems and requirements above:


DFT standard