Ledger & Tokenization Working Group Update

Developers
29

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
30

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
31

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

32

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
33

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
34

Hi Dieter, how can I take part tomorrow?

Thanks :slight_smile:

35

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.

36

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
37

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
38

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
39

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!

40

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…

41

Dear WG Members!

Vote open on textual encoding of ICRC-1 addresses

Who can vote? Core WG members

Voting period: 7 days

As discussed in our recent WG meeting, we want to finalize the item textual encoding of ICRC-1 addresses. As we think that, based on the previous discussions on the item and the lack of further comments, we already have rough consensus, and thus we skip a hum and immediately proceed with a vote. If you think there is a need for further discussion, please speak up in the GitHub voting issue.

The voting mechanism uses GitHub issues, so you can vote and comment easily, just using your web browser. The voting period is 7 days from the date of this forum post. After the voting period, we will inform you about the outcome. You can comment on the issue and are kindly asked to do so in case you object the proposal.

Core team members, please vote here: Vote for the textual encoding of ICRC-1 addresses · Issue #70 · dfinity/ICRC-1 · GitHub

1 Like
42

Dear WG members!

We just created a PR with a proposal for the working group governance.

This will be one of the items up for discussion in the next meeting. Please put any comments you have into the PR.

Have a nice weekend!

43

Dear working group!

For the upcoming meeting on November 15, 2022, we propose the following agenda:

Reminder: The vote for the textual encoding of ICRC-1 addresses has been opened!

1 Like
44

Dear community!

As discussed in the recent WG meeting, Oz (Psychedelic) and Roman (DFINITY) will present the current stable draft of the ICRC-2 standard in a community conversation later this week to make the proposal known to a broad audience beyond the working group.

Date and time:

Thu, 24 Nov, 18:00-19:00 CET (UTC+1).

Title:

ICRC-2: Bringing “Approve” and “Transfer From” Functionality to the IC Token Standard

Abstract:

The Ledger and Tokenization technical working group has worked on an extension to the IC’s token standard that brings the “approve” and “transfer from” functionality of Ethereum’s ERC-20 token standard to the IC’s token standard. The working group has reached a stable draft now and wants to present it to the wider community, with the goals of presenting the results to and soliciting feedback from the wider community before finalizing the extension. This talk explains the current stable draft of the ICRC-2 extension and motivates important design choices.

4 Likes
45

please sign up here for today’s talk: community conversation

1 Like
46

As we are currently using multiple discussion topics for the WG, let’s defragment and move over to the other one for the future.

47

Dear colleagues, what are your thoughts about adding a restricted transfer function where the token minter can define conditions for transfers in a future version of ICRC?

Use-Cases include transfer-level conditions such as lock-up periods, identities to be known or accepted by Internet Identity personhood check as well as token-level conditions i.e. the token contract enforces a maximum number of investors or a cap on the percentage held by any single investor.

function canTransfer(address _to, uint256 _value, bytes _data) external view returns (byte, bytes32);
function canTransferFrom(address _from, address _to, uint256 _value, bytes _data) external view returns (byte, bytes32);
48

@Embark
This topic is abandoned (see above), can you please post your thoughts on the main working group topic?