Fungible Token Standard [Community Consideration]


The Internet Computer does not have an official Token standard. It is up to the Internet Computer community to discuss and propose a preferred Token standard.

Community Consideration

What you can do to help

  • Ask questions
  • Propose ideas

Key people involved


Relevant Background


I think this is also a very important matter


That’s great! It’s finally time to talk about it!
Please speed up the process!
:grinning: :grinning: :grinning:

1 Like

Hey folks,

I wanted to let folks know (specially @senior.joinu who definitely put time and effort) that Igor Lilic (@ililic ) will be the person who manages this thread from the Foundation side. This project is clearly very early compared to other much more baked ones (see Increased Canister Storage), but I wanted to let people that I am working to get every thread spinning, engaged, and with the same clarity as the more baked ones.

In the meantime… please feel free to discuss, tell the community what you agree/disagree on from prioritization to implementatoin.

1 Like

I implemented a token standard (Rust & Motoko) and did a lot of my own thinking.

Of course, before implementing this token standard, I referred to a lot of existing codes, especially some discussions thoughts-on-the-token-standard, which gave me a lot of help. Thanks @senior.joinu very much.


-[1] Dfinity Developer Center: Canister interface

-[2] Dfinity Forum: thoughts-on-the-token-standard

-[3] Toniq-Labs: ic-fungible-token

-[4] SuddenlyHazel: Token-Standard

-[5] Dfinance-tech: ic-token

-[6] Plug: Token-Standard

-[7] Ethereum: EIPS-EIP20 & EIP667 & EIP777 & EIP1820

-[8] Candid

-[9] Why are ERC20 allowances necessary?

-[10] sudograph

-[11] Dfinity Self Describing Standard


Great job, @witter !


Before the Fungible Token standard, I think this is more important. The Identity system needs to add an option to choose whether to use the same(unified) address(Principal ID) or a different address(Principal ID). The Identity system needs to add an option to choose whether to use the same(unified) address(Principal ID) or a different address(Principal ID)


I agree this seems like a major issue that needs to be solved.

1 Like

We wrote a spec regarding fungible token standard together with Daniel from fleek:, it preserves the core interfaces of ERC20, we also added fee logic for update calls, storage for history txs, and corresponding query interfaces. Review suggestions are welcomed. :slight_smile:


Dfinity Fungible Token Standard updates:

  1. Transaction ID: u128→String,Unique Transaction ID
  2. Add support for auto-scaling storage (with a fallback strategy) for transaction history
    Leave your comments & advices to make it better.
1 Like

Auto-Scaling Storage (ATSS) for Dfinity Fungible Token Standard(DFT) details:

  1. When will the ATSS be created?

    • Create the first ATSS when the DFT’s transactions (txs) > 2000. It means that no ATSS will be created before the DFT’s txs > 2000 to save cycles . (for example : you deploy a DFT for test)

    • Create the next ATSS when the current ATSS’s storage size is not enough to store 1000 txs.

  2. What’s the fallback strategy?
    If the creation of the ATSS fails, the txs will be stored in the DFT, txs will be moved to ATSS when the creation is successful.
    Possible reasons for failure:

    • Not enough cycles balance to create ATSS.
    • Other unknown reason.

Leave your comments & advices to make it better.

updates summary:

Questions about the account

1)Unify the Account system, somewhat resembling the Ethereum Account Model, where users can use Account IDs to store ICP tokens, other fungible tokens, and NFTs.

2)Unify the generation rules or settings of the third-party wallets.

3)Build more functions for Internet Identity and NNS, such as a) The canisters can get the Account ID information of a user’s ICP with the authorization by the user; b) NNS can act as a third-party and render the authorization of the transfer of ICP, thereby supporting more token standards.

The document is released :

It is recommended to understand auto-scaling storage:

1 Like

Dfinity Fungible Token Standard v0.1.3 Released

Dfinity Fungible Token Standard v0.2.1 Released


1 Like

Not sure if this thread is still live but if it is, what still needs to happen to arrive at fungible token standards? And is there a better place to get a big picture understanding of the various suggestions?

Things have definitely evolved since then.

For one, the Sonic DEX launched last month, and they use the DIP20 standard.

Other DEXs like InfinitySwap are planning to launch soon, and I believe many of them are developing their own independent token standards.

At the same time, the SNS project (being developed by DFINITY) also requires a ledger canister, and the design of that should be coming out soon, as it’s slated for a Q1 2022 release. Needless to say, a ledger canister design is essentially a token standard.

So yeah, a lot of work on this front, but no clear “winning standard” that the community has coalesced around.


Dfinity Fungible Token Standard v0.4.0 is released
this release contains a large number of automated integration test cases to verify the reliability of the code. As the infrastructure of DEFI, reliability and security are the most important things

The name has been changed to fungible-token-standard :slight_smile:
v0.5.0 is released
Major Updates.

  1. Blockchain support for Token, integration of the ledger design, interface optimization design
  2. TokenHolder type changed to AccountIdentifier to ensure that Principal receipts and default AccountIdentifier are consistent
  3. Use bincode serialization to optimize the size of stored data
  4. Auto-scaling failure and archiving failure of the fallback policy optimization
  5. Remove nonce, use transaction hash to do better anti-duplication
  6. Auto-scaling storage optimization
1 Like