WG meeting

June 11, 2024

Agenda

• ICRC-2 issue
• Recap
• API proposals

​

ICRC-2 approve

icrc2_approve : (ApproveArgs) -> (variant { Ok : nat; Err : ApproveError });

​

type ApproveArgs = record {

from_subaccount : opt blob;

spender : Account;

amount : nat;

expected_allowance : opt nat;

expires_at : opt nat64;

fee : opt nat;

memo : opt blob;

created_at_time : opt nat64;

};

​

• Approval information is written in blocks (from_account, to_account, amount, expiry)�
• The ledger keeps track of allowances, (from_account, to_account) → (amount, expiry) which is used to validate icrc2_transfer_from calls (and is updated)

The issue

• You’re controlling the principal; how do you get outstanding allowances?�
• On ICRC-3 ledgers
• All approval & transfer information is recorded in the blocks ⇒ scan all blocks (but not the best experience)�
• On the ICP ledger
• Infeasible: in blocks we record (from_account_id, to_account_id, amount, expiry) where

hash(principal, subaccount_id)

Proposal

list_icrc2_allowances : (ListAllowancesArgs) -> (ListAllowancesResult) query;

​

​

type ListAllowancesArgs = record {

last_seen_allowance: opt Allowance;

};

​

type ListAllowancesResult = record {

allowances: vec Allowance;

};

type Allowance = record {

from : Account;

spender : Account;

amount : nat;

expires_at : opt nat64;

};

type Account = record {

owner: Principal;

subaccount : SubAccount;

};

Semantics

• If last_seen_allowance not provided: return the first 100 allowances of the caller principal, in lexicographic order on (from,spender) �
• If last_seen_allowance provided: if the caller principal is from.owner �then return the next 100 allowances, in lexicographic order

Proposal

• Allows a principal to efficiently recover all of their outstanding allowances�
• Maintains a degree of privacy for the ICP ledger accounts�
• The API can be later extended to drop this privacy if need be (by eliminating that “if the caller principal is from.owner” precondition

Deployment

• Ledgers maintain outstanding allowances �(account1, account2) → (amount, expiry)�
• For ICRC ledgers accounts are structured. �⇒ The information can be used directly to implement the endpoint�
• For the ICP ledger accounts are not structured�⇒ Replace the allowances datastructure to use structured account�⇒ Existing allowances cannot be parsed; our preferred option is to reset all of the outstanding allowances and start from scratch

Relation between the proposal and the ICRC-2 standard

• Amend the ICRC-2 standard
• Pros: keep things that are conceptually related confined to the same standard
• Cons: “sync” period for already deployed canisters with ICRC-2�
• New standard
• Pros: no “sync” period
• Cons: process

The Issue