Token Standards Working Group: Merging "Ledger and Token" and "NFT" Working Groups

Developers
1

Token Standard Working Group

DFINITY lead: @dieter.sommer
Coordinator: vacant position

Discord: Ledger & Tokenization Channel
Forum: Main thread with updates
GitHub: ICRC repo, Token Standards Working Group repo
Slides and Recordings: Link to Google Drive
Cadence: Tuesday 17:00 or 18:00, see WG calendars (Google Calendar)

Dear colleagues!

We are planning to merge the two ICRC standards Working Groups related to tokens and NFTs:

The new working group is called “Token Standards Working Group”. The main rationale behind this merger is the strong overlap we have recently observed in the Token and NFT working groups.

We currently still have videos and notes on two separate Google Drives:

We plan to use the Ledger and Token WG Google Drive for the new WG.

The calendar invites will be consolidated in due time.

Recently, mainly @skilesare, @sea-snake, @bogwar, and @dieter.sommer have been the main contributors to these WGs. We are looking for volunteers in the community to help drive the Token Standards WG forward. Please contact me or any of the other key contributors in case you want to participate. Or simply join one of the upcoming WG calls.

At this point I would also like to thank all the people who have recently done a tremendous amount of work in those WGs, particularly @skilesare, @sea-snake, and @bogwar!

2 Likes
2

Let us next present a list of currenly ongoing work that we want to take up again shortly:

NFT-related standards

CAIP compatibility standards

References:

Payment, namespacing, and other token-related standards

1 Like
3

For the meeting on 2025-01-28, we propose to discuss a standard for ICRC ledger fee collection. The slides to be presented can be found here (courtesy of @bogwar).

A brief introduction:

  • The collection of fees for ICRC ledgers is not specified.
    • It may be desirable to collect fees to e.g., pay for the cycles that the ledger consumes.
  • The current state of the DFINITY ICRC ledger implementation is as follows:
    • Its blocks may contain fee_col and fee_col_block fields, but the semantics are not specified.
    • It is possible to set a fee collector, but it only affects transfer and transfer_from transactions, not e.g, approve.
3 Likes
4

Hey @mathiasb,

thanks for sharing this. I was wondering in general about the ledger fee when I digged a little bit deeper into ICRC-1.

Personally I would like to know the reason for having a fee at all in case of token transactions. Is the main reason for that to prevent cycle drain attacks by spamming the network with low-value token transfers?

Is it possible in the reference implementation to remove the fee? According to the following posts it is not:

It was also not 100% clear to me where the fee is going and what it is used for. According to the standard, there is a Minting Account that can create new tokens and also receives the fees of tx’s which are then considered as burned. Also, transfers of tokens to the minting account seem to be considered as burned and not included in the icrc1_total_supply.

What’s interesting and a little bit confusing here, is that the ckBTC (also an ICRC-1 token) documentation mentiones that the 0xfee subaccount of the ckBTCminter collects the fees which will then eventually be used to cover cycles costs in the future. While that makes sense, those tokens are not really burned then, are they?! :sweat_smile:

This subaccount has already collected roughly 0.19 ckBTC and I assume that those 0.19 ckBTC are not included in the response of icrc1_total_supply on the ckBTC ledger canister. So are they burned or not? According to the docs of ckBTC they are not and can/will be used in the future, e.g. to cover cycles costs.

Do we generally have an overview on how ICRC-1 tokens can be configured using the reference implementation? I assume it is also possible to deactivate minting which would lead to a deflationary supply in case the fees can really be considered “burned” :thinking:

IMO it would be awesome if we could remove the ledger fee completely if desired. E.g. for each transfer of ckUSDC, the user currently “loses” 0.01 ckUSDC because of the fee. While this isn’t much, it is still less than before. For a stablecoin this might be ok, but for tokens which have huge price fluctuations, these fees might need to be updated on a regular basis.

Also, for ckBTC we currently have a fee of 0.0000001 ckBTC per transfer. It would be great in terms of marketing being able to promote that BTC could be transferred with zero fees on ICP.

Happy to get some feedback on that topic :slight_smile:

1 Like
5

Hey @marc0olo, thanks for the questions! I’ll try my best to answer, and if I get something wrong, hopefully someone will correct me!

Personally I would like to know the reason for having a fee at all in case of token transactions. Is the main reason for that to prevent cycle drain attacks by spamming the network with low-value token transfers?

This is definitely one reason. Another, as you also reference below, is to cover costs. One reason for trying to get this resolved now, is so that SNSs could collect transfer fees to cover the ledger suite cost.

Is it possible in the reference implementation to remove the fee?

Re-reading the posts a few times, I believe what they say is that it is not possible to have a variable fee that e.g., depends on the transaction parameters. It is possible to change the fee from one fixed value to another, even to 0.

According to the standard, there is a Minting Account that can create new tokens and also receives the fees of tx’s which are then considered as burned.

Internally, mints are simply transfers from the minting account, and burns are transfers to the minting account. The ledger does not maintain a balance for the minting account, and it is therefore also not included in the total supply.

ckBTC (also an ICRC-1 token) documentation mentiones that the 0xfee subaccount of the ckBTCminter collects the fees which will then eventually be used to cover cycles costs in the future. While that makes sense, those tokens are not really burned then, are they?! :sweat_smile:

No, these tokens are not burned. Whoever manages the fee collector account can e.g., sell the tokens on a DEX in exchange for ICP, and convert those to cycles to pay for running the ledger. I’m not an expert on the BTC-specific parts, e.g., the minting and burning of BTC ↔ ckBTC, but in case your have further questions, @THLO would probably be a good person to answer!

Do we generally have an overview on how ICRC-1 tokens can be configured using the reference implementation?

I’m only aware of the documentation, e.g., this page on creating a token.

I assume it is also possible to deactivate minting which would lead to a deflationary supply in case the fees can really be considered “burned” :thinking:

Currently, it seems the minting account cannot be changed, but maybe you could initially set it to e.g., a blackholed canister which would then effectively disable minting?

IMO it would be awesome if we could remove the ledger fee completely if desired.

That should be possible. For ckUSDC and ckBTC in particular, I suppose anyone could make an NNS proposal to upgrade the ledger, specifying a zero fee in the upgrade arguments.

2 Likes
6

This is correct. Currently, the collected fees for ckBTC transfers sit in the 0xfee subaccount of the ckBTC minter.
The ckBTC minter will eventually exchange the collected fees (in ckBTC) to ICP or cycles directly so that it can sustain its own operation. However, work on this mechanism has not started yet.

1 Like
7

thanks for the detailed response! :slight_smile:

is the fee collector account part of the ICRC-1 standard? I am struggling to find documentation about this.

how can a 3rd party currently check who is the fee collector of an ICRC-1 compliant ledger? I assume this is or can be a different account than the minting account.

I am actually considering to attempt this in the near future :thinking:

thanks for covering and confirming this again. but I am more trying to understand ICRC-1 in general as some parts may require more explanation documentation. as far as I can see the fee collector is not specified there. so this is a detail of the reference implementation which is not well documented as of now.

for ckBTC I think everything is explained well if you find the right docs :+1:

8

is the fee collector account part of the ICRC-1 standard?

No, nothing about fee collection is in any ICRC standard. The meeting on Tuesday was to discuss standardizing this as part of ICRC-107.

how can a 3rd party currently check who is the fee collector of an ICRC-1 compliant ledger?

For a generic ICRC-1 compliant ledger, it is not possible - this will change with ICRC-107. For the DFINITY reference implementation, you would need to look at the ledger blocks, and look for the fee_col field. E.g., for ckETH, this is set in the first block (since it was set in the ledger initialization arguments), whereas for e.g., ckBTC, it is set in block 39_493, since the fee collector was only configured later, using a ledger upgrade argument. Subsequent blocks contain a fee_col_block which contains the block index of the block where the fee collector account is specified. Note that this implementation-specific behavior may change with ICRC-107.

I assume this is or can be a different account than the minting account.

In the DFINITY reference implementation, we explicitly forbid setting the fee collector account to the minting account (since burns are basically just transfers to the minting account, and mints transfers from the minting account).

1 Like
9

thanks for the explainer. looking forward to see ICRC-107 coming to life :+1:

this is urgently needed :pray:

that totally makes sense :+1:

without digging into implementation details all of my questions above are quite hard to answer given the status quo of the docs around the standards. I would specifically be interested in the implemented features and configuration options that the DFINITY reference implementation provides. we covered the token settings a little bit, but it could benefit from more explanation. (cc @Jessie)

10

The recording and slides of the meeting of 2025-01-14 are now available.

11

The recording of the meeting of 2025-01-28 on a ledger fee collector standard is now available.

12

Please find the resources of the WG, particularly slides, meeting recordings, and meeting chats in the following location: WG shared drive.

13

After liaising with the colleagues in the WG, we propose to tackle the following topics in the Token WG tomorrow:

We will proceed in the order of the items in the above list as time permits. We probably will not get to the namespace item in this meeting, but the slides already provide a proposal.

Further materials:

  • Slides for the namespace discussion

Looking forward to a fruitful discussion tomorrow!

2 Likes
14

The recording of the meeting of 2025-02-11 is now available.

15

In today’s meeting (25.02.2025) we aim to discuss:

  • final touches to ICRC-107, a standard for fee collection in ICRC ledgers
  • kickstart discussions for APIs required by RWA assets ledgers like those for stable coins and CMTAT compliant ones
16

The recording of the meeting of 2025-02-25 is now available. Zoom has only recorded audit and cut it off during discussions.

17

In today’s meeting (11.03.2025) we aim to discuss:

  • ICRC-21 changes and example consent message templates.
  • ICRC-107 (fee collector) quick sync

We have a draft for a fee collector standard. Are there any open items that have not been addressed?

  • Modus operandi for minor changes to ICRC standards

This point in particular can benefit from community opinions. The question is if and how can we make changes to standards at different degrees of maturity (draft, approved by WG, approved by the NNS) if the changes in question are minimal, do not introduce any breaking changes/alter the semantics of what has been already approved and do not alter the essence of the standard

1 Like
18

also posting here for visibility, feedback appreciated! :slight_smile: