ARC-0020: Token Standard

[d0cd]

---

arc: 20
title: ARC-20 Fungible Token Standard
authors: The Aleo Team hello@aleo.org
discussion: #124
topic: Application
status: Draft
created: 2026-03-23

Abstract

ARC-20 defines a fungible token standard for Aleo, supporting both public and private balances. Programs declare conformance to the ARC20 interface, and any other program can call them at runtime via dynamic dispatch -- without compile-time knowledge of the specific token implementation.

The standard defines ARC20, a minimal interface for public transfers, private transfers, shielding/unshielding, and approvals. An optional MintableToken extension adds mint and burn operations. Reference implementations: wrapped_credits.aleo, wrapped_token_registry.aleo.

For regulated tokens requiring freeze lists and compliance records, see ARC-22.

Motivation

Without a standard interface, every DeFi program must import each token at compile time, making it impossible to build token-agnostic protocols. ARC-20 solves this through Leo's dynamic dispatch: a single AMM, lending protocol, or exchange can interact with any conforming token by name at runtime, with no recompilation or redeployment required.

ARC-20 supersedes the previous ARC-20 draft (2023), which was written in Aleo instructions without interface support.

Specification

Interfaces

ARC20

The minimal fungible token interface. Every ARC-20 token must implement these functions:

interface ARC20 {
    record Token;
    record Metadata {
        owner: address,
        ..
    }

    fn transfer_public(public recipient: address, public amount: u128) -> Final;
    fn transfer_private(input: Token, to: address, amount: u128) -> (Token, Token);
    fn transfer_private_to_public(input: Token, to: address, amount: u128) -> (Token, Metadata, Final);
    fn transfer_public_to_private(recipient: address, public amount: u128) -> (Token, Final);
    fn shield(public amount: u128) -> (Token, Final);
    fn unshield(input: Token, amount: u128) -> (Token, Token, Final);

    fn approve_public(public spender: address, public amount: u128) -> Final;
    fn unapprove_public(public spender: address, public amount: u128) -> Final;
    fn transfer_from_public(public owner: address, public recipient: address, public amount: u128) -> Final;
    fn transfer_from_public_to_private(public owner: address, public amount: u128) -> (Token, Final);
}

MintableToken

Optional extension for tokens backed by deposits (e.g. wrapped credits, wrapped registry tokens):

interface MintableToken: ARC20 {
    fn mint_public(public recipient: address, public amount: u128) -> Final;
    fn mint_private(public recipient: address, public amount: u128) -> (Token, Final);
    fn burn_public(public amount: u128) -> Final;
    fn burn_private(input: Token) -> Final;
}

Record Types

Token -- Represents a private token balance:

record Token {
    owner: address,
    amount: u128,
}

Metadata -- Emitted by transfer_private_to_public. The recipient and amount are already visible as public inputs, but the sender's identity is hidden. The Metadata record is owned by the sender, giving them a private receipt of the transfer that only they can decrypt:

record Metadata {
    owner: address,     // set to the sender's address
}

Programs

Program	Description
token_registry.aleo	Multi-token registry supporting token registration, role-based access, and authorized balances. Manages public and private balances for arbitrary token IDs.
wrapped_credits.aleo	ARC20 + MintableToken wrapper around credits.aleo. Deposits Aleo credits and issues 1:1 wrapped tokens implementing the standard interface.
wrapped_token_registry.aleo	ARC20 + MintableToken wrapper around a specific token_registry.aleo token ID. Demonstrates wrapping registry tokens behind the standard interface.
dummy_exchange.aleo	Dynamic dispatch example -- demonstrates transfer_from_public and swap to interact with any ARC20 token by program identifier at runtime.

Dynamic Dispatch

ARC-20 tokens are called via dynamic dispatch, which resolves the target program at runtime. This allows a single program (e.g. an AMM or lending protocol) to interact with any ARC20-implementing token without importing it at compile time.

Leo provides two ways to make dynamic calls:

1. Interface-enforced syntax (leo#29201) -- the compiler validates function names, argument types, and return types against the interface definition at compile time. This is the recommended approach.
2. _dynamic_call intrinsic -- a low-level escape hatch that bypasses interface checking. The caller manually encodes function selectors as field constants and is responsible for passing correct arguments. Useful when working below the interface abstraction or with programs that don't declare interface conformance.

Interface-Enforced Syntax

Interface@(target)/function(args)

The target is an identifier variable, an identifier literal (single-quoted program name), or a field value:

// Call by identifier variable (passed as a function parameter)
ARC20@(token_id)/transfer_public(recipient, amount);

// Call by program name literal
ARC20@('my_token')/transfer_public(recipient, amount);

// Specify both program name and network
ARC20@('my_token', 'aleo')/transfer_public(recipient, amount);

The compiler resolves function names and validates argument types against the interface definition. No manual function selector encoding is needed.

Example: Swap

A DeFi program that accepts any ARC20 token by program identifier:

program my_exchange.aleo {
    fn swap(
        public token_in: identifier,   // program name of any ARC20 token
        public token_out: identifier,   // program name of another ARC20 token
        public amount_in: u128,
        public amount_out: u128,
    ) -> Final {
        // Pull tokens from the user (requires prior approve_public)
        let transfer_in: Final = ARC20@(token_in)/transfer_from_public(
            self.signer, self.address, amount_in
        );
        // Send tokens to the user
        let transfer_out: Final = ARC20@(token_out)/transfer_public(
            self.signer, amount_out
        );
        return final {
            transfer_in.run();
            transfer_out.run();
        };
    }
}

Example: Private Transfer with dyn record

For private token operations, dyn record provides dynamic records that work with any ARC20 token:

fn deposit_private(
    private token_record: dyn record,    // any ARC20 Token record
    public token_id: identifier,         // which ARC20 program
    public amount: u128,
) -> (dyn record, Final) {
    let (change, transfer_future): (dyn record, Final) =
        ARC20@(token_id)/transfer_private_to_public(
            token_record, self.address, amount
        );
    return (change, final { transfer_future.run(); });
}

See dummy_exchange.aleo for a working dynamic dispatch example, and the AMM reference implementation for a full example.

Example: Implementing an ARC20 Token

A program declares interface conformance with : InterfaceName:

interface ARC20 {
    record Token;
    record Metadata { owner: address, .. }
    fn transfer_public(public recipient: address, public amount: u128) -> Final;
    // ... other required functions
}

interface MintableToken: ARC20 {
    fn mint_public(public recipient: address, public amount: u128) -> Final;
    // ... mint/burn functions
}

program my_token.aleo: MintableToken {
    record Token {
        owner: address,
        amount: u128,
    }
    // Must implement all functions from ARC20 + MintableToken
    fn transfer_public(public recipient: address, public amount: u128) -> Final {
        // ...
    }
}

See wrapped_credits.aleo and wrapped_token_registry.aleo for complete implementations.

Test Cases

Tests use Jest with a local devnode and Leo CLI execution.

ARC20 shared interface tests (arc20-wrapper-tests.js), run for both wrapped_credits and wrapped_token_registry:

• All transfer variants (public, private, private-to-public, public-to-private)
• Shield/unshield round-trips
• Approve/unapprove/transfer_from/transfer_from_public_to_private allowance management
• Mint/burn (public and private) via MintableToken extension
• Negative tests: insufficient balance, wrong owner, exceeded allowance

Rationale

Additive approvals: approve_public increases the existing allowance rather than replacing it. This avoids race conditions -- two approve_public calls in the same block will both succeed and add to the allowance, rather than one silently overwriting the other.

u128 amounts: Future-proofs the standard for high-supply tokens and avoids truncation issues. u64 would limit maximum supply to ~18.4 quintillion base units, which is insufficient for some token designs.

shield/unshield naming: shield converts the signer's public balance to a private Token record. unshield converts a private Token back. The interface also includes transfer_private_to_public, which differs from unshield in that it allows specifying a recipient and emits a Metadata record linking the private sender to the public transfer.

[Roee-87]

For public transfers, it may be desirable to include the option to require that a sender's funds originate with the transaction signer via a transfer_public_as_signer transition function. Similar methods currently exist in credits.aleo and token_registry.aleo.

[AleoAlexander]

I agree with this

[Roee-87]

Regarding the burn_public method for the Mintable extension interface, the current function signature does not include an owner input argument. The implementation would require the developer to choose either self.caller or self.signer as the owner. Adding an owner field to the function signature would preserve optionality for the developer. This would align with the current implementation of burn_public in token_registry.aleo.

[AleoAlexander]

I also agree with this

[AleoAlexander]

Comments

1. The sample programs table needs to include links to each of those programs. The In addition, the AMM reference implementation link leads to a nonexistent/private repository
2. I don't really understand the need for the Metadata record. The sender will trivially be able to have a receipt of their transaction via scanning for their spent records (sk_tag). Knowing the sender of a transfer_private_to_public call is really only useful for the recipient
3. I don't think it makes sense to have MintableToken be a separate interface. I think it's fair game to include mint/burn in the base ARC-20
4. I think we should have mapping balances: address => u128; included in the ARC-20 interface as well. It doesn't make sense to me to enforce the structure of a private balance without enforcing the structure of a public balance
5. I propose an additional interface: ARC20Metadata:

interface ARC20Metadata {
    fn decimals() -> u8;
    fn totalSupply() -> u128;
    fn name() -> identifier;
    fn symbol() -> identifier;
}

[AleoAlexander]

Also the examples above still use the / syntax instead of the new :: syntax

[vicsn]

And balanceOf

[AleoAlexander]

Another nit: the receiving address input name is inconsistent in the transfer function (recipient vs. to).

[AleoAlexander]

I think it's a good idea to include join() and split() as function in the base ARC20 interface as well. This follows all of our other tokens.

[AleoAlexander]

transfer_from_public_to_private is missing the recipient in the function signature.

[AleoAlexander]

Why do mint_private and burn_private have a Final component? Also, the recipient and amount inputs need to be private

[AleoAlexander]

To check/enforce total supply limits?

[AleoAlexander]

Nvm Final makes sense

[AleoAlexander]

Here's my updated proposal:

lib.leo (IARC20)

// The 'IARC20' library.

interface ARC20 {
    mapping balances: address => u128;

    mapping allowances: field => u128;

    storage total_supply: u128;

    storage max_supply: u128;

    record Token {
        owner: address,
        amount: u128,
        ..
    }
    //=============================================================
    //               APPROVAL FUNCTIONS
    //=============================================================
    fn approve_public(public spender: address, public amount: u128) -> Final;
    fn unapprove_public(public spender: address, public amount: u128) -> Final;
    //=============================================================
    //               TRANSFER FUNCTIONS
    //=============================================================
    fn transfer_public(public recipient: address, public amount: u128) -> Final;
    fn transfer_private(input: Token, recipient: address, amount: u128) -> (Token, Token);
    fn transfer_private_to_public(input: Token, recipient: address, amount: u128) -> (Token, Final);
    fn transfer_public_to_private(recipient: address, public amount: u128) -> (Token, Final);
    fn transfer_public_as_signer(public recipient: address, public amount: u128) -> Final;
    fn transfer_from_public(public owner: address, public recipient: address, public amount: u128) -> Final;
    fn transfer_from_public_to_private(
        public owner: address,
        public recipient: address,
        public amount: u128,
    ) -> (Token, Final);
    //=============================================================
    //             SHIELD/UNSHIELD FUNCTIONS
    //=============================================================
    fn shield(public amount: u128) -> (Token, Final);
    fn unshield(input: Token, amount: u128) -> (Token, Final);
    //=============================================================
    //               JOIN/SPLIT FUNCTIONS
    //=============================================================
    fn join(input_1: Token, input_2: Token) -> Token;
    fn split(input: Token, amount: u128) -> (Token, Token);
    //=============================================================
    //                MINT/BURN FUNCTIONS
    //=============================================================
    fn mint_public(public recipient: address, public amount: u128) -> Final;
    fn mint_private(recipient: address, amount: u128) -> (Token, Final);
    fn burn_public(public owner: address, public amount: u128) -> Final;
    fn burn_private(input: Token, amount: u128) -> (Token, Final);
}

interface ARC20Metadata: ARC20 {
    fn decimals() -> u8;
    fn name() -> identifier;
    fn symbol() -> identifier;
}

[AleoAlexander]

Note that interfaces are not currently allowed in a library as of Leo v4.0.0 (will be added in next update)

[AleoAlexander]

UPDATE: interfaces are now available in libraries. The above post is now up-to-date as of 4/20/26

[vicsn]

Some minor findings from @Antonio95 to sharpen the example implementation:

• unshield logic doesn't make any sense, and as Alexander noted it outputs an unnecessary record
• it would be nice if the constructors of the example programs initialized the token_info mapping, if just for illustrative purposes.
• transfer_private and burn_private and transfer_private_to_public don't need to check if the owner equals the signer
• deposit_credits_private (amount) and transfer_private_to_public (address, amount) can be public
• transfer_from_public, transfer_from_public_to_private and unshield don't need to assert against underflow.
• burn* should eliminate
• consider appending _caller and _signer to more functions... Or more consistently.

[Antonio95]

(expanding on the first point: unshield calls credits.aleo/transfer_public_to_private sourcing the funds from credits_wrapper's credits balance and immediately after consumes the resulting record by calling transfer_private_to_public and transferring them to the record owner (which is the signer); this flow could be replaced by a single call to credits.aleo/transfer_public)

[vicsn]

One nit: all these wrappers examples should update the token_info when minting and burning just like we do for the deployed stablecoins

[AleoTimes]

Discussions about this proposal have been ongoing for nearly two months. I want to remind everyone that this feature is crucial for the market. The official documentation advises against applying the current token registry to new projects, but the new standard has yet to be fully rolled out!

PS: Regarding the issue of the official documentation being updated far slower than the actual update schedule and the multi-language support, it's very important to consider assigning a dedicated person to handle the documentation! For beginners, the only way to understand aleo is through the documentation. Don't mention Discord; you know how infrequent the development meetings are—it's not suitable for most people!

[vicsn]

Thank you for pushing @AleoTimes ! We're confident we've received all commentary and aim to finalize next week

[mwyatt896]

This ARC20 standard doesn't give the easiest ways to work around for multisig situations but as previously discussed here, it's better to keep this simple.

As such, ZKPuzzle has 3 ways to get multisig on private balances under this standard

Records are signer-addressed (only the transaction signer can consume one it owns; programs have no keys, so they can't hold records or veto their spending — wrapping transfer_private is bypassable by calling it directly). Public balances are caller-addressed (transfer_public debits self.caller, so programs custody them natively). Below are three ways we are handling this at zkpuzzle and we think this can live outside of ARC20:

1. Split the key — FROST threshold signatures behind one address. The multisig is a normal account; t-of-n parties co-produce its signatures. Verification never sees the difference, so no protocol change. Works for every token including credits.aleo, invisible on-chain; buys only flat t-of-n, and signer rotation is a key ceremony. More work for users for key security + tooling to monitor multisig sessions but is fine.

2. Put policy in the token program like a vault extension. A program-scoped Vault record held by a liveness-only executor; spends/rotations need k-of-n signature::verify over typed intents binding (op, token, vault_id, nonce, recipient, amount). Arbitrary policy (limits, timelocks, weights), rotation is just a transaction; only works for tokens that adopt it — no retrofit onto deployed assets like USAD/USDCx. Could work for a vault asset though based on deployer.

3. Custody the asset in your own program — for tokens you don't control. Hold the pooled asset as a program-owned public balance, keep entitlements as private records in your program, gate releases on in-circuit user signatures (operator can refuse, never steal or redirect), and disburse privately by consuming an operator-held treasury record inside your transition. Works today on third-party tokens; costs a public aggregate balance acting similar to zcash's turnstile mechanism + trusting the pool operator which can be in charge of things such as a loan management system.

Just as a heads up and helpfulness to the community -- number 3 & number 1 can apply to be used on arc22 assets like USDCx and USAD