DFINITY Foundation

ICDevs.org

CryptoIsGood

Anvil

ICPL.app

ysyms

The Accumulators’ Neuron

RawTech Venture

Paul Young

ICPMANUAL

8yeargangDAO

Isaac Valadez

Krzysztof Żelazko

Nicolas.ic

Smaug’s Neuron for Retail Investors

ICLight.io

Internet Computer Association

Synapse.vote (formerly ICP Maximalist Network)

Arthur’s Neuron (used to be cycle_dao)

Inactive (Request Removal) - The Fools' Court

Always Rejects

John Wiegley


## Introduction
The [ICRC-2](https://github.com/dfinity/ICRC-1/tree/main/standards/ICRC-2) Fungible Token Standard is an extension of the base
[ICRC-1](https://github.com/dfinity/ICRC-1/tree/main/standards/ICRC-1) standard. ICRC-2 specifies a way for an account owner to delegate token transfers to a third party on the owner's behalf.

The ICRC-2 Fungible Token Standard is the product of the collaborative effort of the [Ledger & Tokenization working group](https://forum.dfinity.org/t/announcing-token-standard-as-topic-of-the-first-meeting-of-the-ledger-tokenization-working-group/11925/1).

This proposal describes the proposed extension to the core Standard.

## Motivation
The approve-transfer-from pattern became popular in the Ethereum ecosystem thanks to the [ERC-20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) Token Standard. This interface enables new application capabilities, including but not limited to:

1. **Safer off-chain payments**. ICRC-1 requires to notify the recipient after the payment happened. The pattern pay-and-notify can be tricky to implement. ICRC-2 allows the recipient to transfer the tokens themselves and therefore simplifies payment flows significantly.

2. **Recurring payments**. Alice can approve a large amount to Bob in advance, allowing Bob to make periodic transfers in smaller installments. Real-world examples include subscription services and rents.

3. **Uncertain transfer amounts**. In some applications, such as automatic trading services, the exact price of goods is unknown in advance. With approve-transfer-from flow, Alice can allow Bob to trade securities on Alice's behalf, buying/selling at yet-unknown price up to a specified limit.

4. **Simplify two-step transfers**. In applications where payments are made to canisters, the typical pattern under ICRC-1 is using a two-step transfer. With ICRC-2 this could be simplified into a one-step transfer initiated by the canister itself.

## Relation to the ERC-20 standard

ICRC-2 draws inspiration from the ERC-20's approve/transferFrom methods. The working group introduced a few notable differences to accommodate the asynchronous nature of the ICP protocol and integrate the new standard more closely with ICRC-1:
The  method caller can specify the expected current allowance. This features enables applications to implement the compare-and-swap protocol for atomic allowance updates as suggested in the [SWC-114 remediation section](https://swcregistry.io/docs/SWC-114#remediation).
Approvals have optional expiration time to make undesired use of approvals less likely.
Approvals apply to pairs of accounts (not pairs of principals), allowing smart contracts to have multiple independent approvals from the same user. This feature provides a mechanism for concurrent payment flows between two parties and increases transparency for DAO-like smart contracts.
 and  methods inherit the support for memos and [transaction deduplication](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md#transaction-deduplication-) from ICRC-1.

## API

{ is a shell keyword
            

The ICRC-2 Fungible Token Standard