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.
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.
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.