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
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!
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!
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).
ICRC-2: Bringing “Approve” and “Transfer From” Functionality to the IC Token Standard
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.
please sign up here for today’s talk: community conversation
As we are currently using multiple discussion topics for the WG, let’s defragment and move over to the other one for the future.
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);
This topic is abandoned (see above), can you please post your thoughts on the main working group topic?