Ledger & Tokenization Working Group Update

I’ve updated the spec; valid textual representations are unique now. I’ve also sketched a reference implementation in Motoko.

Could we make the special trailing byte 0x7f instead of 0xff?

In case the use of principals proliferates and more values of that byte get a meaning assigned to them then we don’t close off the option to expand the space via leb encoding of those values.

Dear community!

The next meeting of the Ledger & Tokenization Working Group is scheduled for tomorrow, September 20. Please note that it has been scheduled an hour earlier than the usual time slot due to various overlaps.

There are two topics on the agenda of tomorrow’s Working group meeting, as agreed in the most recent meeting:

We are looking forward to the discussions on those important aspects of the token standard!

Hi all, I want to raise an important security related issue, that the working group could include on the agenda for this week or for the next session.

Can we have a fixed size representation for the internal tokens. At the moment, I can see from the official reference implementation that:

public type Tokens = Nat;

rather than:

public type Tokens = Nat64; 

I believe this could lead to memory errors or attack vectors where attackers try to consume all the memory of a canister.

The benefit of this using a wrapper over using u64/nat64 directly is that we can define the behaviour for arithmetical overflow: in particular we can return an option rather than a panic on overflow. Other operations can also be defined. So, the internal use of the Tokens struct in the ledger made total sense from a safety perspective - we shouldn’t get rid of this imo. We can, however, make this more ergonomic by serialising from Nat.

Not sure how we would do all this in Motoko, but perhaps with a new type?

3 Likes

Hi @Maxfinity!
I don’t think there is an attack vector. To create a transaction with a huge amount, you need to own this amount first. So if the ledger author knows that there are no more than 2^64 tokens, the author is free to use u64/Nat64 internally.

For example, here is how the DFINITY implementation of the ICRC-1 ledger works: main.rs - dfinity/ic - Sourcegraph. All the externally visible balances are Nats, but internally all balances are u64. If the amount in the transfer arg doesn’t fit into u64, we report an InsufficientFunds error.

Dear Working Group!

The next meeting of the Ledger & Tokenization Working Group is scheduled for October 4. We propose to have the items agreed upon last time and one additional item requested by the community on the agenda for this meeting:

  • Working Group governance
  • ICRC-2 proposal by Psychedelic (ICRC-2)
  • Textual encoding for accounts (ICRC-1#55) (if time)

We are looking forward to the discussions in the upcoming meeting!

Do you mind reposting the zoom link ?

If anybody requires the Zoom link for the working group meeting, please send it to @nikhil.ranjan or @dieter.sommer via a private forum message so that we can add you to the email invitation. We do not want to post the link publicly as we have been experiencing severe Zoom bombing with a public link.

Sometimes useful to look how it’s been done, here’s a thread on “Rough Consensus” circa btc 2015:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011457.html

1 Like

Few notes from me:

From a scalping trade, arbitrage bot, or leverage trader perspective, the best solution is when the trader funds are in an account controlled by the DEX/DeFI canister. This way there is no need to do ledger calls, trading can be done without async calls. The faster they are, the more profit they will make.

From the end user’s perspective - the best solution is to use the Swapper pattern which I have published in forums (it lacks slippage, but that can be added). End-users make a few transfers a month and just want them to be successful. This pattern guarantees the user will get what they agreed for and no developer errors or malicious behavior can result in fund loss.

So we have 3 ways of doing it. fast(risk) - medium(risk) - slow (guaranteed). I am not sure the medium one (approve flow) is worth it since the other two will beat it at everything.

Both Swapper and the fastest approach can be done with the core we have right now.

To be more specific: I think approve in Ethereum was invented to make the fastest exchange with slippage possible. In IC the fastest exchange with slippage is just preloading an account = (dex_canister_principal, caller) and then trading (buying + selling) with a single call (or placing orders which get triggered). Once a trader is done, they withdraw funds. Now that Stable Memory got increased, there will be no need for a DEX to be multi-canister to be able to hold trader’s accounts.
I think we shouldn’t blindly copy Ethereum, instead work towards the most optimal solution.

Even if approve flow gets approved, DEXes which do what’s mentioned above will be better for traders and will make DEXes using approve obsolete. On the other hand, DEXes using swapping will be more secure so end users will prefer them.

Additionally, you can’t have loans or leverage with approve flow. You will need to lock the funds inside the DeFI contract. The reason swaps in Ethereum don’t work like Compound loans is the gas fee, which in IC is not a problem.

This means multi or single-canister ledgers :+1:
Single canister DeFi :+1:

And because a single canister DeFi at some point won’t have the throughput, there will be many such and arbitrage synchronizing them. An arbitrage bot won’t open an account in one DeFi canister, it will open accounts in all of them.

This is pretty far-fetched. I would like it if someone proves me wrong.

1 Like

Where can we find the info presented and proposed in yesterday’s working group?

I put notes and links to slides in the Charters.md file in the ICRC-1 repo:

Feel free to open a PR against this file if I misrepresented something or missed something important.

1 Like

Dear community!

The next meeting of the Ledger & Tokenization Working Group is scheduled for tomorrow, October 18, 2022.

We propose to discuss the following items in tomorrow’s meeting:

  • Working Group governance
    • Continuing the discussion from where we left off
  • ICRC-2 proposal by Psychedelic (ICRC-2)
    • Asking the WG once more for feedback on the most recent version of the proposal (Note: The agreed-upon PR from the most recent meeting is still outstanding)
  • Transaction log API (ICRC-3)
    • First overview of the proposal

We are looking forward to the discussions!

1 Like

Hi Dieter, how can I take part tomorrow?

Thanks :slight_smile:

Hi @Embark
Just saw this after the fact. If you want to take part in the future WG meetings, just send a private message with your email address to me. Then you will receive a Zoom invitation by mail.

Communications w.r.t. the Working Group

The minutes of each WG meeting are in GitHub:

This contains also the links to the slides presented.

The most recent minutes are in the below link and are still to be merged. Please comment on them if you think something that has been discussed is missing.

1 Like

Action required!

Defining our core team eligible for voting

In the most recent ledger and tokenization WG meeting we agreed that we need to think about how to define the eligibility for voting for our WG. We discussed that it would make sense that active members are eligible to vote. Now, what does active mean in the context of the WG? What about using the following “definition” for being an “active member”:

  • Has a strong interest in the topic, either personal or driven by their startup or employer;
  • Has a decent understanding of the technology being discussed and the implications of decisions;
  • Follows the discussion in the meetings, on the forum, and on GitHub;
  • Regularly makes contributions to discussions in meetings, on the forum, commenting on PRs on GitHub, or making PRs;

My suggestion is that we start with the below list of people who have been active so far in the WG and then ask the WG members to speak up if we have missed anyone. This way we can collect the list of voting members.

Initial list of core team members:

  • Oz Waldorf
  • Ossian Mapes
  • Alessandro Rietmann
  • Max Chamberlin
  • Austin Fatheree
  • Jordan Last
  • Daniel Steren
  • jxzchiang
  • Witter Lee
  • Roman Kashitsyn
  • Mario Partorelli

Please let us know (either here on the forum or a personal message to me, Mario, or Roman) if you are not on the list of voting members, but you think you should!
Note that I assembled the list quickly from my memories of WG discussions and skimming through the forum to see active participants, so it is likely that I did not catch everyone who should be on the list. So, don’t be shy and let us know if you should be on there!

Once we are done with this exercise, we have a list of core team members, who are eligible for voting in the name of the WG.

We think that constraining voting to one member per org (multiple may be part of the core group) would make sense.

Also, in the future, we want to try to be more inclusive of people in the goes that cannot participate in the meetings due to schedule (Asia here as the meeting would be after midnight for our Chinese teams). It would be great to get actively participating members from there, who would also be voting members. The idea is to reflect our discussions well on the forums and on GitHub, so that people not part of the meetings can also contribute and voice their opinions.

Opinions?

Thanks!

1 Like

I think you should probably remove me from the core team, given that I haven’t been active in the WG for a while. I’d definitely like to hear about any future updates with the WG though!

1 Like

Dear community!

The next meeting of the Ledger & Tokenization Working Group is scheduled for tomorrow, November 1, 2022.

Proposed agenda:

  • Working Group governance
  • ICRC-2 proposal by Psychedelic (ICRC-2)
  • Transaction API: ICRC-3 proposal (ICRC-3 PR)
  • NFT standard

Looking forward to the discussions!

Today’s meeting starts in half an hour at 18:00 UTC+1. Europe switched to winter time (UTC+1) from UTC+1 before this weekend and there seems to be some confusion with the invite as some people thought the meeting is over already…