Fungible tokens for Multi-L1 Interoperability

[cardene777]

Abstract

When fungible token (FT) contracts are deployed across multiple L1 blockchains, users typically need to be aware of their FT balances scattered across each L1.
Additionally, a secure mechanism is required to enable interoperability between FTs deployed on different L1s.
This standard proposes a system that allows users to interact with FTs as if they existed on a single blockchain—without needing to be aware of balances across multiple L1s—providing a seamless experience similar to interacting with a standard ERC20 token.

Motivation

There is currently no unified standard for handling ERC20-compliant FTs across multiple L1 blockchains.
To make a FT usable across multiple L1s, it must first be deployed on each of those L1s.
Additionally, when transferring a FT from one L1 to another, it is necessary to use ICM (Interchain Messaging) to bridge the tokens between L1s.

In such a setup, users need to keep track of how much FT they hold on each individual L1.
To check their total balance, users must access each L1’s FT contract, retrieve their balance, and sum them up manually.
When sending FTs across L1s, users may find that the L1 they want to send from does not hold a sufficient balance, since the total balance is scattered across multiple chains.
In this case, the user must first transfer the missing amount from a third L1 to the source L1, and only then can they proceed with sending the FT to the target L1.

As the number of participating L1s increases, the following drawbacks emerge:

• Higher gas costs
• Longer processing times
• Increased operational complexity

These issues result in a poor user experience when FTs are fragmented across multiple L1s.
For users unfamiliar with blockchain or DApps, the complexity becomes a significant usability barrier.

This proposal outlines a system that allows users to send their FTs as if they were operating entirely within a single L1.
When a user initiates a transfer, the system automatically gathers the required amount from their scattered FT balances across different L1s.
It also determines which L1s to source the funds from automatically.

This mechanism can be executed from any L1 that has deployed a FT contract compliant with this proposal.
As a result, users can easily send FTs with a user experience similar to interacting with a single blockchain.
Moreover, the system is designed to be scalable, ensuring that performance does not degrade even as the number of supported L1s grows.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

This specification proposes two main components: the architecture of the L1s and the interfaces of the smart contracts.

Terminology

• Main L1

  • The L1 that provides a contract responsible for managing the FT balances held by each address and serving as the hub when sending FTs.

• FT Manager

  • A contract that manages each address’s FT balance and approval information, and determines which L1’s FT contract to use when executing a transfer.

• App L1

  • An L1 that provides a FT contract.

• FT

  • A contract deployed on each L1 that handles the issuance, transfer, and management of FTs.

• Router L1

  • An L1 that provides a contract for managing the mapping between addresses and the Main L1 responsible for their balances.

• Router

  • A contract that manages the mapping of each address to the Main L1 that holds its FT balance.

L1

The L1 architecture consists of three types of L1s: multiple App L1s that host individual FT contracts, multiple Main L1s that manage and execute FT transfers, and a Router L1 that handles routing to the appropriate Main L1.

Figure 1: L1 Configuration

Main L1

Main L1s (e.g., "Main L1 X" and "Main L1 Y" in Figure 1) have the following primary responsibilities:

• Managing the aggregate FT balances for each address across all L1s.
• Determining, during FT transfers, how much should be moved from which App L1s, and executing the transfer using ICM.

Figure 2: FT Transfer

In Figure 1, the user holds “3 ETH” on App L1 A and “5 ETH” on App L1 B. The total balance of “8 ETH” is managed and recorded by Main L1 X.
When a user initiates a transfer from an App L1, the Main L1 receives the request and determines how much to pull from each App L1, then executes the operation accordingly.

Initially, there MAY be only one Main L1. However, as the number of L1s with deployed FT contracts increases, the number of Main L1s SHOULD also increase.
This is because all transfers are processed through Main L1s, and a growing number of users leads to higher transaction volume, which in turn increases latency.
By introducing multiple Main L1s, transaction processing can be distributed.

Each address MUST be associated with exactly one Main L1 that manages its balance.
As more Main L1s are introduced, different addresses MAY be managed by different Main L1s.
When a FT transfer is initiated, the request MUST be sent to the Main L1 managing the sender’s address.
This allows the system to distribute processing load efficiently.

As shown in Figure 2, since User A’s balance is managed by Main L1 X, the transfer request is sent only to Main L1 X. Other Main L1s do not receive the request.

App L1

An App L1 refers to an L1 where a FT contract is deployed. Examples of App L1s include:

• L1s that support the issuance and trading of NFTs
• L1s that host blockchain games
• L1s that offer security tokens

App L1s have the following key responsibilities:

• Hosting a FT contract, allowing FT usage on that L1
• Enabling various actions (e.g., NFT purchases, DeFi operations) via DApps that utilize the FT
• Maintaining information about the associated Main L1 and Router L1 that manage balances for each address

Figure 3: Balance Retrieval API

DApps on an App L1 MAY use a Balance Retrieval API to obtain the user's FT balances.
This API MUST be provided by the administrator of the corresponding Main L1, and MUST return both the total balance and per-L1 breakdown for a specified address. The API MAY be implemented using either of the following approaches:

• Querying the Main L1 on-chain to retrieve the specified address’s total and per-L1 FT balances
• Querying an off-chain database that maintains up-to-date balance information for the specified address

This enables DApps on App L1s to access FT balance data from frontend or backend applications via API, enhancing user experience and integration flexibility.

Router L1

Each App L1’s FT contract maintains data about which Main L1 is managing the balance for a given address—but only if that address has previously interacted with the FT on that App L1.
For an address that has not yet interacted with the FT on a particular App L1, the contract lacks the information needed to determine whether the balance is:

1. Not yet managed by any Main L1, or
2. Already managed by a Main L1 due to prior usage on another App L1

Furthermore, if no Main L1 currently manages the balance, it is straightforward to assign one when there is only a single Main L1.
However, if there are multiple Main L1s, it becomes unclear which one SHOULD manage the balance for the new address.

To address this, a dedicated Router L1 is introduced. This L1 hosts a Router contract that maintains mappings between each address and the Main L1 responsible for managing its balance.
With this mechanism, FT contracts on App L1s can determine whether an address is using the FT for the first time or already has its balance managed on a specific Main L1.

Router L1 has the following responsibilities:

• Maintaining information about all Main L1s
• Managing the mapping of each address to its designated Main L1

Figure 4: Initial Transfer Flow

Figure 4 illustrates the flow for an initial transfer using the Router L1.
The process proceeds as follows:

1. A DApp on App L1 B sends a FT transfer request to the FT contract.

2. The FT contract uses ICM to send transfer information to the Router contract on the Router L1.

3. The Router contract retrieves the Main L1s managing the sender and recipient addresses and forwards the transfer request to the sender’s Main L1 (Main L1 X).

4. The FT Manager contract on Main L1 X performs the following actions:

   • Verifies that the sender has enough FT to cover the transfer
   • Determines which App L1s should reduce the balance, and sends ICM requests to the relevant FT contracts to deduct the appropriate amounts
   • Updates the sender’s balance and increases the recipient’s balance within the FT Manager contract
   • If the recipient’s balance is managed by a different Main L1, it sends an ICM request to that Main L1 to increase the recipient’s balance accordingly

This system ensures that FT balance management and transfers remain scalable and well-coordinated, even as the number of participating L1s grows.

sequenceDiagram
    participant DApp as DApp (App L1 B)
    participant FT as FT Contract (App L1 B)
    participant Router as Router Contract (Router L1)
    participant ManagerX as FT Manager (Main L1 X)
    participant AppL1A as FT Contract (App L1 A)
    participant AppL1B as FT Contract (App L1 B)
    participant MainY as FT Manager (Main L1 Y)

    DApp->>FT: Send Transfer Request

    FT->>Router: ICM: Transfer Info

    Router->>ManagerX: ICM: Forward Transfer Info

    ManagerX->>ManagerX: Check sender has enough balance
    ManagerX->>ManagerX: Decide which App L1 to reduce balance

    alt Reduce from App L1 A
        ManagerX->>AppL1A: ICM: Decrease sender balance
    else Reduce from App L1 B
        ManagerX->>AppL1B: ICM: Decrease sender balance
    end

    ManagerX->>ManagerX: Decrease sender balance
    ManagerX->>ManagerX: Increase recipient balance

    alt Recipient is on Main L1 Y
        ManagerX->>MainY: ICM: Increase recipient balance
    end

Loading

Contract

Smart contracts are categorized into three groups based on the L1 they are deployed on: Main L1, App L1, and Router L1.

Utils

This section describes contracts that are commonly used across the system.

IAddressRegistry

An interface for a contract that manages the chain ID of the FT Manager contract on the Main L1 responsible for tracking the balance of each address.
This interface is used by the FT contracts deployed on App L1s and the Router contract deployed on the Router L1.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

// interfaces
import {L1Info} from "./interfaces/Structs.sol";

/**
 * @title IAddressRegistry
 * @notice Interface for the Address Registry.
 */
interface IAddressRegistry {
    // **************************************************
    // *                    EVENTS                     *
    // **************************************************

    /**
     * @notice Emitted when the account registry info is set.
     * @param account The address of the account.
     * @param chainId The chainId of the FT manager.
     */
    event AccountRegistryInfoSet(
        address indexed account,
        bytes32 indexed chainId
    );

    // **************************************************
    // *           EXTERNAL READ FUNCTIONS              *
    // **************************************************

    /**
     * @notice Get the account registry info.
     * @param account The address of the account.
     * @return The account registry info.
     */
    function getAccountRegistryInfo(
        address account
    ) external view returns (L1Info memory);
}

• AccountRegistryInfoSet
   Emitted when information about an address and the corresponding Main L1 and FT Manager contract responsible for managing its balance is registered.

• getAccountRegistryInfo
   A function that takes an address and returns the Main L1 and FT Manager contract responsible for managing the balance of that address.

A mapping definition is required to manage the chain ID of the FT Manager contract on the Main L1 for each address.

/**
 * @dev account => FT manager L1
 */
mapping(address => bytes32) internal _accountRegistryInfo;

IApproveManager

IApproveManager is an interface for a contract that manages the approval information allowing FT transfer rights to be delegated to another address.

It is used in the FT Manager contract on the Main L1.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

/**
 * @title IApproveManager
 * @notice Interface for the Approve Manager.
 */
interface IApproveManager {
    // **************************************************
    // *                    EVENTS                      *
    // **************************************************

    /**
     * @notice Emitted when the allowance is set.
     * @param owner The address of the owner.
     * @param spender The address of the spender.
     * @param amount The amount of allowance.
     */
    event SetAllowance(address indexed owner, address indexed spender, uint256 amount);

    // **************************************************
    // *                    ERRORS                      *
    // **************************************************

    /**
     * @notice Thrown when the allowance is insufficient.
     * @param owner The address of the owner.
     * @param spender The address of the spender.
     * @param amount The amount of allowance.
     */
    error InsufficientAllowance(address owner, address spender, uint256 amount);

    // **************************************************
    // *            EXTERNAL READ FUNCTIONS             *
    // **************************************************

    /**
     * @notice Get the allowance of an owner for a spender.
     * @param owner The address of the owner.
     * @param spender The address of the spender.
     * @return The allowance of the owner for the spender.
     */
    function getAllowance(address owner, address spender) external view returns (uint256);
}

• SetAllowance
   An event emitted when a specific address approves another address to spend its FT.

• InsufficientAllowance
   An error returned when a transfer is attempted by a spender, but the approved FT amount is insufficient.

• getAllowance
   A function that returns the amount of FT the owner address has approved for the specified spender address.
   This function MUST emit the SetAllowance event.

The following mapping definition is required to manage approval information for each address:

/**
 * @dev owner => spender => allowance
 */
mapping(address => mapping(address => uint256)) private _allowances;

The function responsible for approving FT transfers MUST NOT be externally executable within the FT Manager contract on the Main L1.
This is because, by design, users are not allowed to send requests directly to the Main L1’s FT Manager contract.
All such requests MUST always be sent from the FT contract deployed on an App L1.

IBalanceManager

An interface for a contract that manages the FT balances held by addresses.
It is used in the FT Manager contract on the Main L1.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

/**
 * @title IBalanceManager
 * @notice Interface for the Balance Manager.
 */
interface IBalanceManager {
    // **************************************************
    // *                   STRUCTURES                   *
    // **************************************************

    /**
     * @notice user has balances on multiple L1s
     * @param chainId chain id
     * @param balance balance
     */
    struct L1Balance {
        bytes32 chainId;
        uint256 balance;
    }

    // **************************************************
    // *                    EVENTS                      *
    // **************************************************

    /**
     * @notice Emitted when a Balance Manager info is set.
     * @param account The address of the account.
     * @param amount The amount of FT.
     */
    event UpdateAllFTBalance(address indexed account, uint256 amount);

    /**
     * @notice Emitted when a FT Balance is updated.
     * @param account The address of the account.
     * @param chainId The Chain ID of the App L1 where the FT contract is deployed.
     * @param amount The amount of FT.
     */
    event UpdateFTBalance(
        address indexed account,
        bytes32 chainId,
        uint256 amount
    );

    // **************************************************
    // *            EXTERNAL READ FUNCTIONS             *
    // **************************************************

    /**
     * @notice get FT balances
     * @param account user address
     * @return FT balances
     */
    function getAllFTBalance(
        address account
    ) external returns (uint256);

    /**
     * @notice get FT balance
     * @param account user address
     * @param chainId chain id
     * @return FT balance
     */
    function getFTBalance(
        address account,
        bytes32 chainId
    ) external returns (uint256);

    /**
     * @notice get FT balances
     * @param account user address
     * @return FT balances
     */
    function getFTBalances(
        address account
    ) external returns (L1Balance[] memory);
}

• L1Balance
   A struct that stores the FT balance of a given address for each App L1.

• UpdateAllFTBalance
   An event emitted when the total FT balance across all App L1s managed by the Main L1 is updated.

• UpdateFTBalance
   An event emitted when the FT balance of a specific App L1 managed by the Main L1 is updated.

• getAllFTBalance
   A function that returns the total FT balance held by a specific address across all App L1s.

• getFTBalance
   A function that returns the FT balance held by a specific address on a specific App L1.

• getFTBalances
   A function that returns an array of FT balances across all App L1s for a specific address.
   The returned array MUST be sorted in descending order by balance.

A mapping definition like the following is required to manage balance information for each address:

/**
 * @dev Address => All FT Balances
 */
mapping(address => uint256) private _allFTBalances;

/**
 * @dev Address => L1 ChainId Id => Balance
 */
mapping(address => mapping(bytes32 => uint256)) private _ftBalances;

IBlocklist

An interface for a contract that manages addresses prohibited from using the FT.
It is used in the FT Manager contract on the Main L1, the FT contract on the App L1, and the Router contract on the Router L1.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

/**
 * @title IBlocklist
 * @notice Interface for the Blocklist.
 */
interface IBlocklist {

    // **************************************************
    // *                    EVENTS                      *
    // **************************************************

    /**
     * @notice Emitted when a user is blocked.
     * @param user The address of the user that is blocked.
     */
    event UserLocalBlocked(address indexed user);

    /**
     * @notice Emitted when a user is blocked in the global L1.
     * @param user The address of the user that is blocked.
     */
    event UserGlobalBlocked(address indexed user);

    /**
     * @notice Emitted when a user is unblocked.
     * @param user The address of the user that is unblocked.
     */
    event UserLocalUnblocked(address indexed user);

    /**
     * @notice Emitted when a user is unblocked in the global L1.
     * @param user The address of the user that is unblocked.
     */
    event UserGlobalUnblocked(address indexed user);

    // **************************************************
    // *                    ERRORS                      *
    // **************************************************

    /**
     * @notice Thrown when a user is blocked.
     * @param user The address of the user that is blocked.
     */
    error LocalBlockedUser(address user);

    /**
     * @notice Thrown when a user is blocked.
     * @param user The address of the user that is blocked.
     */
    error GlobalBlockedUser(address user);

    // **************************************************
    // *            EXTERNAL READ FUNCTIONS             *
    // **************************************************

    /**
     * @notice Check if a user is blocked in the local L1.
     * @param account The address of the user to check.
     * @return True if the user is blocked, false otherwise.
     */
    function isLocalBlocked(address account) external view returns (bool);

    /**
     * @notice Check if a user is blocked in all L1s.
     * @param account The address of the user to check.
     * @return True if the user is blocked, false otherwise.
     */
    function isGlobalBlocked(address account) external view returns (bool);
}

• UserLocalBlocked
   An event emitted when a specific address is added to the blocklist on the App L1 only.

• UserGlobalBlocked
   An event emitted when a specific address is added to the blocklist across the entire system (all Main L1s, App L1s, and the Router L1).

• UserLocalUnblocked
   An event emitted when a specific address previously blocklisted only on the App L1 is removed from the blocklist.

• UserGlobalUnblocked
   An event emitted when a specific address previously blocklisted across the entire system (all Main L1s, App L1s, and the Router L1) is removed from the blocklist.

• LocalBlockedUser
   An error returned when an address blocklisted on the App L1 attempts to transfer FTs.

• GlobalBlockedUser
   An error returned when an address blocklisted across the entire system (all Main L1s, App L1s, and the Router L1) attempts to transfer FTs.

• isLocalBlocked
   A function that checks whether a given address is blocklisted only on the App L1.

• isGlobalBlocked
   A function that checks whether a given address is blocklisted across the entire system (all Main L1s, App L1s, and the Router L1).

The following mappings are required to manage blocklist status for each address:

• _localBlocked
   Stores information for addresses blocklisted specifically on the FT contract deployed on an App L1.

• _globalBlocked
   Stores information for addresses blocklisted across the entire system, including the FT Manager on the Main L1, the FT contract on the App L1, and the Router on the Router L1.

/**
 * @dev Address => Only App L1 Blocked
 */
mapping(address => bool) internal _localBlocked;

/**
 * @dev Address => All L1 Blocked
 */
mapping(address => bool) internal _globalBlocked;

ILock

An interface for a contract that manages FTs locked on the App L1’s FT contract.
It is used within the FT contract deployed on the App L1.

This lock mechanism can be restricted for use only on the App L1.
Locked balances are not utilized by the FT processing logic within the FT Manager contract on the Main L1.
Requests are sent from the FT contract on the App L1 to the FT Manager contract on the Main L1.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

/**
 * @title ILock
 * @notice Interface for the Lock contract
 */
interface ILock {
    // **************************************************
    // *                   EVENTS                       *
    // **************************************************

    /**
     * @notice Emitted when a user locks their tokens
     * @param account The address of the user who locked their tokens
     * @param amount The amount of tokens locked
     */
    event Lock(address indexed account, uint256 amount);

    /**
     * @notice Emitted when a user unlocks their tokens
     * @param account The address of the user who unlocked their tokens
     * @param amount The amount of tokens unlocked
     */
    event Unlock(address indexed account, uint256 amount);

    // **************************************************
    // *           EXTERNAL WRITE FUNCTIONS             *
    // **************************************************

    /**
     * @notice Sets the amount of tokens locked for a user
     * @param account The address of the user who locked their tokens
     * @param amount The amount of tokens locked
     */
    function setLock(address account, uint256 amount) external;

    // **************************************************
    // *           EXTERNAL READ FUNCTIONS              *
    // **************************************************

    /**
     * @notice Returns the amount of tokens locked for a user
     * @param account The address of the user
     * @return The amount of tokens locked
     */
    function lockedAmount(address account) external view returns (uint256);
}

• Lock
   An event emitted when the FT held by a specific address is locked.

• Unlock
   An event emitted when the lock on the FT held by a specific address is released.

• setLock
   A function that locks the FT held by a specific address.

• lockedAmount
   A function that retrieves the amount of FT locked for a specific address.

A mapping definition is required to manage the locked FT balance held by each address.

/**
* @notice address => FT amount
*/
mapping(address => uint256) internal _lockedAmount;

ILockManager

An interface for a contract that manages the locked FT balances on the FT contract deployed on the App L1.
It is used in the FT Manager contract.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

/**
 * @title ILockManager
 * @notice Interface for the LockManager contract
 */
interface ILockManager {
    // **************************************************
    // *                   EVENTS                       *
    // **************************************************

    /**
     * @notice Emitted when a user locks their tokens
     * @param account The address of the user who locked their tokens
     * @param chainId The chain id of the chain where the tokens are locked
     * @param amount The amount of tokens locked
     */
    event Lock(address indexed account, bytes32 chainId, uint256 amount);

    /**
     * @notice Emitted when a user unlocks their tokens
     * @param account The address of the user who unlocked their tokens
     * @param chainId The chain id of the chain where the tokens are unlocked
     * @param amount The amount of tokens unlocked
     */
    event Unlock(address indexed account, bytes32 chainId, uint256 amount);

    // **************************************************
    // *           EXTERNAL READ FUNCTIONS              *
    // **************************************************

    /**
     * @notice Returns the amount of tokens locked for a user
     * @param account The address of the user
     * @param chainId The chain id of the chain where the tokens are locked
     * @return The amount of tokens locked
     */
    function lockedAmount(address account, bytes32 chainId) external view returns (uint256);
}

• Lock
   An event emitted when the FT held by a specific address is locked.

• Unlock
   An event emitted when the lock on the FT held by a specific address is released.

• lockedAmount
   A function that retrieves the amount of FT locked for a specific address.

A mapping definition is required to manage the locked FT balances for specific addresses on specific App L1s.

/**
* @notice address => chain id => FT amount
*/
mapping(address => mapping(bytes32 => uint256)) internal _lockedAmount;

IL1RegistryBase

An interface for a contract that manages references to contracts deployed on other L1s, used by the FT Manager contract on the Main L1, the FT contract on the App L1, and the Router contract on the Router L1.
It is used across all three: the FT Manager on the Main L1, the FT contract on the App L1, and the Router contract on the Router L1.

Since all L1s MUST maintain the same set of information, any registration or update of a chain ID and corresponding contract address MUST always be initiated from the Router contract on the Router L1.
The Router contract then sends the update requests via ICM to the FT Manager contract on the Main L1 and the FT contracts on each App L1.

For this reason, the functions responsible for registering or updating the chain ID and contract address MUST be defined as internal functions, and MUST only be called when triggered through ICM requests.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

/**
 * @title IL1Registry
 * @notice The IL1Registry interface is used to manage the L1 contracts.
 */
interface IL1Registry {
    // **************************************************
    // *                   EVENTS                       *
    // **************************************************

    /**
     * @notice Emitted when the L1 info is set.
     * @param chainId The chain id.
     * @param contractAddress The contract address.
     */
    event L1InfoSet(bytes32 indexed chainId, address indexed contractAddress);
}

• L1InfoSet
   An event emitted when a new L1 chain ID and its corresponding contract address are registered.

A mapping definition is required to manage the association between L1 chain IDs and contract addresses.

/**
 * @notice l1 chain id => l1 contract address
 */
mapping(bytes32 => address) internal _l1Info;

IRouterRegistry

An interface for a contract that manages the chain ID of the Router L1 and the address of the Router contract deployed on it.
It is used in the FT Manager contract on the Main L1 and the FT contract on the App L1.

Since all Main L1s and App L1s MUST maintain the same information, any registration or update of the Router L1's chain ID and Router contract address MUST always be executed from the Router contract on the Router L1.
The Router contract then sends requests via ICM to update the corresponding data in the FT Manager contract on the Main L1 and the FT contract on the App L1.

Therefore, the functions responsible for setting or updating the chain ID and contract address MUST be defined as internal functions and MUST only be invoked in response to ICM requests.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

// interfaces
import {L1Info} from "./Structs.sol";

/**
 * @title IRouterManager
 * @notice The interface for the Router Manager.
 */
interface IRouterRegistry {
    // **************************************************
    // *                   EVENTS                       *
    // **************************************************

    /**
     * @notice Emitted when the router info is set.
     * @param chainId The chainId of the router.
     * @param routerInfo The router info.
     */
    event RouterInfoSet(bytes32 indexed chainId, address routerInfo);

    // **************************************************
    // *           EXTERNAL READ FUNCTIONS              *
    // **************************************************

    /**
     * @notice Get the router info.
     * @return The router info.
     */
    function getRouterInfo() external view returns (L1Info memory);
}

• RouterInfoSet
   An event emitted when the Router L1’s chain ID and the Router contract address are newly registered.

• getRouterInfo
   A function that retrieves the currently registered Router L1 chain ID and Router contract address.

IFTManagerRegistry

An interface for a contract that manages information about the Main L1s responsible for FT balance management and their corresponding FT Manager contract addresses.
It is used in the FT Manager contract on the Main L1, the FT contract on the App L1, and the Router contract on the Router L1.

This interface MUST inherit from the following:

• IL1RegistryBase

Since all Main L1s and App L1s MUST maintain the same set of information, any registration or update of a Main L1’s chain ID and FT Manager contract address MUST always be executed from the Router contract on the Router L1.
The Router contract then sends requests via ICM to the FT Manager contract on the Main L1 and the FT contract on the App L1 to apply the update.

Therefore, functions for setting or updating the chain ID and contract address MUST be defined as internal and invoked only when triggered via ICM.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

import {L1Info} from "./Structs.sol";

/**
 * @title IFTManagerRegistry
 * @notice Interface for the FT Manager Registry.
 */
interface IFTManagerRegistry {
    // **************************************************
    // *                    EVENTS                      *
    // **************************************************
    /**
     * @notice Emitted when the FT manager info is set.
     * @param chainId The chainId of the FT manager.
     * @param FTManagerAddress The address of the FT manager.
     */
    event FTManagerInfoSet(
        bytes32 indexed chainId,
        address FTManagerAddress
    );

    // **************************************************
    // *            EXTERNAL READ FUNCTIONS              *
    // **************************************************

    /**
     * @notice Get the FT manager info.
     * @param chainId The chain id.
     * @return The FT manager info.
     */
    function getFTManagerAddress(
        bytes32 chainId
    ) external view returns (address);

    /**
     * @notice Get the FT manager infos.
     * @return The FT manager infos.
     */
    function getFTManagerInfos()
        external
        view
        returns (L1Info[] memory);
}

• FTManagerInfoSet
   An event emitted when information about a Main L1 and its corresponding FT Manager contract is added.

• getFTManagerAddress
   A function that retrieves the registered information for a specific Main L1 and its FT Manager contract.

• getFTManagerInfos
   A function that retrieves the registered information for all Main L1s and their associated FT Manager contracts.

IFTRegistry

An interface for a contract that manages the chain IDs of App L1s and the addresses of FT contracts deployed on them.
It is used in the FT Manager contract on the Main L1 and the Router contract on the Router L1.

This interface MUST inherit from the following:

• IL1RegistryBase

Since all Main L1s and the Router L1 MUST maintain the same set of information, any registration or update of an App L1’s chain ID and FT contract address MUST always be executed from the Router contract on the Router L1.
The Router contract then sends update requests via ICM to the FT Manager contract on the Main L1 and to the FT contracts on the App L1s.

Therefore, functions for setting or updating chain IDs and contract addresses MUST be defined as internal functions and invoked only when triggered via ICM.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

import {L1Info} from "./Structs.sol";

/**
 * @title IFTRegistry
 * @notice Interface for the FT Registry.
 */
interface IFTRegistry {
    // **************************************************
    // *                    EVENTS                      *
    // **************************************************
    /**
     * @notice Emitted when the FT info is set.
     * @param chainId The chainId of the FT.
     * @param FTAddress The address of the FT.
     */
    event FTInfoSet(bytes32 indexed chainId, address FTAddress);

    // **************************************************
    // *            EXTERNAL READ FUNCTIONS              *
    // **************************************************

    /**
     * @notice Get the FT info.
     * @param chainId The chain id.
     * @return The FT info.
     */
    function getFTAddress(
        bytes32 chainId
    ) external view returns (address);

    /**
     * @notice Get the FT infos.
     * @return The FT infos.
     */
    function getFTInfos() external view returns (L1Info[] memory);
}

• FTInfoSet
   An event emitted when information about a FT contract on an App L1 is added.

• getFTAddress
   A function that retrieves the registered information of the FT contract on a specific App L1.

• getFTInfos
   A function that retrieves the registered information of all FT contracts across all App L1s.

ITeleporterManager

An interface for a contract that manages information about the Teleporter contract and other necessary data used when communicating with other L1s via ICM.
It is used in the FT contract on the App L1, the FT Manager contract on the Main L1, and the Router contract on the Router L1.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

import {ITeleporterMessenger} from "icm-contracts/contracts/teleporter/ITeleporterMessenger.sol";

/**
 * @title ITeleporter
 * @notice The ITeleporter interface.
 */
interface ITeleporter {
    // **************************************************
    // *                   STRUCTS                      *
    // **************************************************

    /**
     * @notice Execution policy.
     * @param feeTokenAddress The fee token address.
     * @param amount The amount.
     * @param requiredGasLimit The required gas limit.
     * @param allowedRelayerAddresses The allowed relayer addresses.
     */
    struct ExecutionPolicy {
        address feeTokenAddress;
        uint256 amount;
        uint256 requiredGasLimit;
        address[] allowedRelayerAddresses;
    }

    // **************************************************
    // *                   EVENTS                       *
    // **************************************************

    /**
     * @notice Emitted when the teleporter is set.
     * @param chainId The chain id.
     * @param teleporter The teleporter.
     */
    event TeleporterSet(bytes32 chainId, address teleporter);

    /**
     * @notice Emitted when the execution policy is set.
     * @param chainId The chain id.
     * @param executionPolicy The execution policy.
     */
    event ExecutionPolicySet(bytes32 chainId, ExecutionPolicy executionPolicy);

    // **************************************************
    // *                    ERRORS                      *
    // **************************************************

    /**
     * @notice Invalid teleporter.
     * @param sender The sender.
     */
    error InvalidTeleporter(address sender);

    // **************************************************
    // *           EXTERNAL WRITE FUNCTIONS             *
    // **************************************************

    /**
     * @notice Receive a message.
     * @param sourceBlockchainID The source blockchain ID.
     * @param originSenderAddress The origin sender address.
     * @param message The message to receive.
     */
    function receiveTeleporterMessage(
        bytes32 sourceBlockchainID,
        address originSenderAddress,
        bytes calldata message
    ) external;

    /**
     * @notice Set the teleporter.
     * @param chainId The chain ID.
     * @param teleporter The teleporter.
     */
    function setTeleporter(bytes32 chainId, address teleporter) external;

    /**
     * @notice Set the execution policy.
     * @param chainId The chain ID.
     * @param executionPolicy The execution policy.
     */
    function setExecutionPolicy(bytes32 chainId, ExecutionPolicy memory executionPolicy) external;

    // **************************************************
    // *           EXTERNAL READ FUNCTIONS              *
    // **************************************************

    /**
     * @notice Get the teleporter messenger.
     * @return The teleporter messenger.
     */
    function getTeleporterMessenger() external view returns (ITeleporterMessenger);

    /**
     * @notice Get the chain ID.
     * @return The chain ID.
     */
    function getChainId() external view returns (bytes32);

    /**
     * @notice Get the teleporter.
     * @param chainId The chain ID.
     * @return The teleporter.
     */
    function getTeleporter(bytes32 chainId) external view returns (address);

    /**
     * @notice Get the execution policy.
     * @param chainId The chain ID.
     * @return The execution policy.
     */
    function getExecutionPolicy(bytes32 chainId) external view returns (ExecutionPolicy memory);

    /**
     * @notice Get the current L1 info.
     * @return The current L1 info.
     */
    function getCurrentL1Info() external view returns (L1Info memory);
}

• ExecutionPolicy
   A struct that defines default values required when sending a request to another L1 via ICM.
   A mapping must be defined to manage default values per destination L1:

/**
 * @notice l1 chain id => execution policy
 */
mapping(bytes32 => ExecutionPolicy) internal _executionPolicies;

 The structure includes the following fields:

• feeTokenAddress
    The contract address of the token (either native or ERC20) used for fees.

• amount
    The amount of tokens used as the fee.

• requiredGasLimit
    The gas limit required for execution.

• allowedRelayerAddresses
    A whitelist of relayer addresses authorized to forward requests.

• TeleporterSet
   An event emitted when the chain ID and Teleporter contract address for an L1 are added or updated.

• ExecutionPolicySet
   An event emitted when a new or updated ExecutionPolicy is set.

• InvalidTeleporter
   An error returned when data is received from an unknown chain ID or from an unauthorized Teleporter contract.

• receiveTeleporterMessage
   A function for receiving data sent from another L1.

• setTeleporter
   A function for adding or updating the chain ID and Teleporter contract information for an L1.

• setExecutionPolicy
   A function for adding or updating an ExecutionPolicy.

• getTeleporterMessenger
   A function that retrieves the Teleporter contract information associated with the contract implementing this interface.

• getChainId
   A function that retrieves the chain ID of the L1 on which the contract implementing this interface is deployed.

• getTeleporter
   A function that retrieves the Teleporter contract address associated with a specific L1 chain ID.

• getExecutionPolicy
   A function that retrieves the ExecutionPolicy associated with a specific L1 chain ID.

• getCurrentL1Info
   A function that retrieves the chain ID and Teleporter contract information for the L1 on which the contract implementing this interface is deployed.

Each contract implementing this interface MUST define the chain ID of the L1 it is deployed on, as well as the corresponding Teleporter contract address.
Additionally, the interface MUST manage the information of Teleporter contracts on all connected L1s.

/**
 * @notice The teleporter messenger.
 */
ITeleporterMessenger internal _teleporterMessenger;

/**
 * @notice The chain ID.
 */
bytes32 internal _chainId;

/**
 * @notice l1 chain id => l1 teleporter contract address
 */
mapping(bytes32 => address) internal _teleporters;

Struct

This section summarizes the enum and struct types used across the contracts.
They are used in the FT contract on the App L1, the FT Manager contract on the Main L1, and the Router contract on the Router L1.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

// **************************************************
// *                     ENUMS                      *
// **************************************************

/**
 * @notice Action.
 * @notice mint: Mint action.
 *      burn: Burn action.
 *      unblock: Unblock action.
 *      transfer: Token transfer action.
 *      transferFrom: Token transfer from action.
 *      approve: Token approve action.
 *      burn: Token burn action.
 *      burnFrom: Token burn from action.
 *      updateTokenBalance: Update token balance action.
 *      updateTokenAllowance: Update token allowance action.
 *      block: Block action.
 *      lock: Lock action.
 *      multiCall: Multi call action.
 *      setLatestMainL1Info: Update latest main subnet chain id action.
 *      setTeleporter: Set teleporter action.
 *      setRouterInfo: Set router info action.
 *      setFTManagerInfo: Set FT manager info action.
 *      setFTInfo: Set FT info action.
 */
enum Action {
    mint,
    transfer,
    transferFrom,
    localTransfer,
    approve,
    burn,
    burnFrom,
    updateTokenBalance,
    updateTokenAllowance,
    block,
    unblock,
    lock,
    multiCall,
    setLatestMainL1Info,
    setTeleporter,
    setRouterInfo,
    setFTManagerInfo,
    setFTInfo,
}

// **************************************************
// *                   STRUCTS                      *
// **************************************************

/**
 * @notice L1 info.
 * @param chainId The chain id.
 * @param contractAddress The contract address.
 */
struct L1Info {
    bytes32 chainId;
    address contractAddress;
}

/**
 * @notice Send message params.
 * @param destinationBlockchainID The chain id of the destination blockchain.
 * @param message The message to send.
 * @param destinationAddress The address of the destination.
 * @param feeInfo The fee info.
 * @param requiredGasLimit The required gas limit.
 * @param allowedRelayerAddresses The allowed relayer addresses.
 */
struct SendMessageParams {
    bytes32 destinationBlockchainID;
    address destinationAddress;
    TeleporterFeeInfo feeInfo;
    uint256 requiredGasLimit;
    address[] allowedRelayerAddresses;
    bytes message;
}

• Action
   An enum used to identify the type of operation requested when receiving a message from an App L1 FT contract on the Router L1 or Main L1.
   The system executes a process based on the specified action type.

  • mint
      Issues new FTs.
      Triggered by the FT Manager on the Main L1 and sent to the FT contract on the App L1.

  • transfer
      Transfers FTs.
      Triggered by the FT contract on the App L1 and sent to the FT Manager on the Main L1.

  • transferFrom
      Transfers FTs from an address other than the token holder.
      Triggered by the App L1 FT contract and sent to the Main L1.

  • localTransfer
      Transfers FTs between addresses on the same App L1.
      Triggered by the App L1 FT contract and sent to the Main L1.

  • approve
      Grants permission to another address to operate the FTs.
      Triggered by the App L1 FT contract and sent to the Main L1.

  • burn
      Burns FTs.
      Triggered either from the Main L1 to the App L1 or vice versa.

  • burnFrom
      Burns FTs from an address other than the token holder.
      Triggered either from the Main L1 to the App L1 or vice versa.

  • updateTokenBalance
      Updates balance information.
      Triggered either from the Main L1 to the App L1 or from the App L1 to the Main L1.

  • updateTokenAllowance
      Updates the allowance for a spender address.
      Triggered by the App L1 FT contract and sent to the Main L1.

  • block
      Adds an address to the blocklist.
      Triggered by the Router on the Router L1 and sent to the Main L1 and App L1.

  • unblock
      Removes an address from the blocklist.
      Triggered by the Router on the Router L1 and sent to the Main L1 and App L1.

  • lock
      Locks FTs held by an address on the App L1.
      Triggered by the App L1 FT contract and sent to the Main L1.

  • multiCall
      Executes multiple actions in a batch.

  • setLatestMainL1Info
      Updates the latest Main L1 and FT Manager contract info.
      Triggered by the Router L1 and sent to the Main L1 and App L1.

  • setTeleporter
      Adds a new L1 and its Teleporter contract info.
      Triggered by the Router L1 and sent to the Main L1 and App L1.

  • setRouterInfo
      Sets or updates the Router L1 and Router contract info.
      Triggered by the Router L1 and sent to the Main L1 and App L1.

  • setFTManagerInfo
      Sets or updates the Main L1 and FT Manager contract info.
      Triggered by the Router L1 and sent to the Main L1 and App L1.

  • setFTInfo
      Sets or updates the App L1 and FT contract info.
      Triggered by the Router L1 and sent to the Main L1.

• L1Info
   A struct that holds L1-related information.
   Includes the L1 chain ID (bytes32) and the associated contract address.

• SendMessageParams
   A struct that contains parameters required to send a request to another L1 via ICM.
   Fields include:

  • destinationBlockchainID
      The chain ID of the destination L1.

  • destinationAddress
      The contract address on the destination L1.

  • feeInfo
      Information about the fee token and amount.

  • requiredGasLimit
      The gas limit required to execute the process.

  • allowedRelayerAddresses
      A list of relayer addresses permitted to forward the request.

  • message
      The content of the request to be executed.

Main L1

The following interfaces and contracts MUST be implemented and deployed on the Main L1:

• IApproveManager
   Manages information about addresses whose balances are tracked by this FT Manager contract and who have granted spending approval to other addresses.

• IBalanceManager
   Manages the balances of specific addresses within this FT Manager contract.

• IBlocklist
   Manages the blocklist of addresses whose balances are tracked by this FT Manager contract.

• ILockManager
   Manages the balances of FTs locked in FT contracts deployed on specific App L1s.

• IRouterRegistry
   Manages the chain ID and contract address information of the Router L1.

• IFTRegistry
   Manages FT contracts deployed on App L1s and restricts usage to only those that are registered.

• IFTManagerRegistry
   Manages other FT Manager contracts deployed on different Main L1s and restricts usage to only those that are registered.

• ITeleporterManager
   Implements functionality for sending and receiving requests to and from contracts on other L1s via ICM.

To receive requests via ICM, the contract MUST also conform to the ITeleporterReceiver interface.

// (c) 2022-2023, Ava Labs, Inc. All rights reserved.
// See the file LICENSE for licensing terms.

// SPDX-License-Identifier: LicenseRef-Ecosystem

pragma solidity ^0.8.25;

/**
 * @dev Interface that cross-chain applications must implement to receive messages from Teleporter.
 *
 * @custom:security-contact https://github.com/ava-labs/icm-contracts/blob/main/SECURITY.md
 */
interface ITeleporterReceiver {
    /**
     * @dev Called by TeleporterMessenger on the receiving chain.
     *
     * @param sourceBlockchainID is provided by the TeleporterMessenger contract.
     * @param originSenderAddress is provided by the TeleporterMessenger contract.
     * @param message is the TeleporterMessage payload set by the sender.
     */
    function receiveTeleporterMessage(
        bytes32 sourceBlockchainID,
        address originSenderAddress,
        bytes calldata message
    ) external;
}

• receiveTeleporterMessage
   A function called when a request is received from a FT contract on an App L1 or from a FT Manager contract on another Main L1.
   This function executes the requested FT operation.

The contract MUST conform to the IFTManager interface.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

/**
 * @title IFTManager
 * @notice Interface for the FTManager contract.
 */
interface IFTManager {
    // **************************************************
    // *            EXTERNAL WRITE FUNCTIONS            *
    // **************************************************

    /**
     * @notice Transfer token.
     * @param to The address to transfer to.
     * @param amount The amount to transfer.
     */
    function transfer(address to, uint256 amount) external;

    /**
     * @notice Transfer token from.
     * @param from The address to transfer from.
     * @param to The address to transfer to.
     * @param amount The amount to transfer.
     */
    function transferFrom(
        address from,
        address to,
        uint256 amount
    ) external;

    /**
     * @notice Approve.
     * @param spender The address to approve.
     * @param amount The amount to approve.
     */
    function approve(address spender, uint256 amount) external;

    /**
     * @notice Burn.
     * @param amount The amount to burn.
     */
    function burn(uint256 amount) external;

    /**
     * @notice Burn from.
     * @param from The address to burn from.
     * @param amount The amount to burn.
     */
    function burnFrom(address from, uint256 amount) external;
}

• transfer
   A function that transfers FTs held by a specific address.
   The following validations MUST be performed:
   - Ensure that neither the sender nor the recipient address is blocklisted.
   - Ensure that the sender’s balance is sufficient to cover the transfer amount.

• transferFrom
   A function that transfers FTs from an address other than the token holder.
   The following validations MUST be performed:
   - Ensure that the caller, sender, and recipient addresses are not blocklisted.
   - Ensure that the sender’s balance is sufficient to cover the transfer amount.
   - Ensure that the caller has sufficient allowance from the sender to cover the transfer amount.

• approve
   A function that grants another address permission to spend FTs.
   The following validations MUST be performed:
   - Ensure that neither the caller nor the spender address is blocklisted.

• burn
   A function that burns (i.e., sends to the zero address) FTs held by a specific address.
   The following validation MUST be performed:
   - Ensure that the caller is not blocklisted.

• burnFrom
   A function that burns (i.e., sends to the zero address) FTs from an address other than the token holder.
   The following validations MUST be performed:
   - Ensure that both the caller and the token holder are not blocklisted.

App L1

The following interfaces and contracts MUST be implemented and deployed on the App L1:

• AddressManager
   Manages the information of the FT Manager contract on the Main L1 and tracks which Main L1 manages the balance of each address.

• IBlocklist
   Manages the blocklist of addresses for this FT contract.
   It contains both addresses blocked only on this App L1 and addresses blocked system-wide (across all Main L1s, App L1s, and the Router L1).

• ILock
   Manages the FTs locked by specific addresses.

• IRouterRegistry
   Manages the chain ID and contract information of the Router L1.

• IFTRegistry
   Manages other FT contracts deployed on App L1s and restricts usage to only those that are registered.

• IFTManagerRegistry
   Manages the FT Manager contracts on Main L1s and restricts usage to only those that are registered.

• ITeleporterManager
   Implements the functionality for sending and receiving requests to and from other L1s via ICM.

In addition, the contract MUST inherit from the ERC-20 standard.

• transfer
   Transfers FTs held by a specific address.
   The following validation MUST be performed:
   - Ensure that neither the sender nor the recipient address is blocklisted.
   The default values defined in the ExecutionPolicy for each chain ID are used.

• transferFrom
   Transfers FTs from an address other than the token holder.
   The following validation MUST be performed:
   - Ensure that the caller, sender, and recipient addresses are not blocklisted.
   If the FT balance on the App L1 is sufficient, the transfer is processed locally and only the result is sent to the Main L1.
   The default values defined in the ExecutionPolicy for each chain ID are used.

• approve
   Grants another address permission to spend FTs.
   The following validation MUST be performed:
   - Ensure that neither the caller nor the spender address is blocklisted.
   The default values defined in the ExecutionPolicy for each chain ID are used.

The contract MUST also conform to ERC20BurnableUpgradeable.

• burn
   Burns FTs (sends to the zero address) held by a specific address.
   The following validation MUST be performed:
   - Ensure that the caller is not blocklisted.
   The default values defined in the ExecutionPolicy for each chain ID are used.

• burnFrom
   Burns FTs from an address other than the token holder.
   The following validation MUST be performed:
   - Ensure that both the caller and the token holder are not blocklisted.
   The default values defined in the ExecutionPolicy for each chain ID are used.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

import {L1Info} from "../../utils/interfaces/Structs.sol";
import {ITeleporterManager} from "../../utils/TeleporterManager.sol";

/**
 * @title IFT
 * @notice The IFT interface.
 */
interface IFT {
    // **************************************************
    // *                   ERRORS                       *
    // **************************************************

    /**
     * @notice Self transfer
     * @param from from address
     * @param to to address
     */
    error SelfTransfer(address from, address to);

    // **************************************************
    // *           EXTERNAL WRITE FUNCTIONS             *
    // **************************************************

    /**
     * @notice Local transfer
     * @param chainId target chainId
     * @param value value
     */
    function localTransfer(bytes32 chainId, uint256 value) external;

    // **************************************************
    // *                  BLOCKLIST                     *
    // **************************************************

    /**
     * @notice Block a user in the local subnet.
     * @param user The address of the user to block.
     */
    function localBlockUser(address user) public;

    /**
     * @notice Unblock a user in the local subnet.
     * @param user The address of the user to unblock.
     */
    function localUnblockUser(address user) public;
}

• SelfTransfer
   An error returned when the sender and recipient of a FT transfer are the same address.
   To avoid unnecessary requests that could impact L1 processing performance, transfers where the sender and recipient are the same MUST be rejected.

• localTransfer
   A function that sends FTs held on the source App L1 to a FT contract deployed on another App L1 via ICM.

• localBlockUser
   A function that adds a specific address to the blocklist only on the L1 where this contract is deployed.
   This function MUST be restricted to authorized addresses only.

• localUnblockUser
   A function that removes a specific address from the blocklist on the L1 where this contract is deployed.
   This function MUST be restricted to authorized addresses only.

In cases where the FT contract on the App L1 already knows which Main L1 manages the address balance, requests MUST be sent directly to the FT Manager contract on that Main L1 without routing through the Router contract on the Router L1.
This helps reduce unnecessary requests.

The contract MUST conform to the ITeleporterReceiver interface to be able to receive requests via ICM.

// (c) 2022-2023, Ava Labs, Inc. All rights reserved.
// See the file LICENSE for licensing terms.

// SPDX-License-Identifier: LicenseRef-Ecosystem

pragma solidity ^0.8.25;

/**
 * @dev Interface that cross-chain applications must implement to receive messages from Teleporter.
 *
 * @custom:security-contact https://github.com/ava-labs/icm-contracts/blob/main/SECURITY.md
 */
interface ITeleporterReceiver {
    /**
     * @dev Called by TeleporterMessenger on the receiving chain.
     *
     * @param sourceBlockchainID is provided by the TeleporterMessenger contract.
     * @param originSenderAddress is provided by the TeleporterMessenger contract.
     * @param message is the TeleporterMessage payload set by the sender.
     */
    function receiveTeleporterMessage(
        bytes32 sourceBlockchainID,
        address originSenderAddress,
        bytes calldata message
    ) external;
}

• receiveTeleporterMessage
   A function invoked when a request is received from a FT Manager contract on another Main L1 or from the Router contract on the Router L1.
   This function executes the requested FT operation.
   If any post-processing is required after sending the request, it is RECOMMENDED to include that logic within this function for improved security.

Router L1

The following interfaces and contracts MUST be implemented and deployed on the Router L1:

• IAddressRegistry
   Manages information about FT Manager contracts on Main L1s and tracks which Main L1 is responsible for managing the balance of each address.

• IBlocklist
   Manages the blocklist of addresses tracked by this Router contract.
   Addresses managed by the Router contract MUST be blocklisted across the entire system (all Main L1s, App L1s, and the Router L1).

• IRouterRegistry
   Manages the chain ID and contract address of the Router L1.

• IFTRegistry
   Manages FT contracts on App L1s and restricts usage to only those that are registered.

• IFTManagerRegistry
   Manages FT Manager contracts on Main L1s and restricts usage to only those that are registered.

• ITeleporterManager
   Implements functionality for sending and receiving requests to and from other L1s via ICM.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

/**
 * @title IRouter
 * @notice The interface for the Router contract.
 */
interface IRouter {
    // **************************************************
    // *           EXTERNAL WRITE FUNCTIONS             *
    // **************************************************

    /**
     * @notice Block a user.
     * @param user The user to block.
     */
    function blockUser(address user) external;

    /**
     * @notice Unblock a user.
     * @param user The user to unblock.
     */
    function unblockUser(address user) external;

    /**
     * @notice Set the latest main subnet chain id.
     * @param chainId The chain id of the latest main subnet.
     */
    function setLatestMainL1Info(bytes32 chainId) external;

    /**
     * @notice Set the FT info.
     * @param chainId The chain id of the FT.
     * @param FTAddress The address of the FT.
     */
    function setFTInfo(
        bytes32 chainId,
        address FTAddress
    ) external;

    /**
     * @notice Set the FT manager info.
     * @param chainId The chain id of the FT manager.
     * @param FTManagerAddress The address of the FT manager.
     */
    function setFTManagerInfo(
        bytes32 chainId,
        address FTManagerAddress
    ) external;

    /**
     * @notice Set the router info.
     * @param chainId The chain id of the router.
     * @param routerAddress The address of the router.
     */
    function setRouterInfo(bytes32 chainId, address routerAddress) external;
}

• blockUser
   A function that adds a specific address to the blocklist.
   Sends requests to the FT Manager contracts on the Main L1 and the FT contracts on the App L1.

• unblockUser
   A function that removes a specific address from the blocklist.
   Sends requests to the FT Manager contracts on the Main L1 and the FT contracts on the App L1.

• setLatestMainL1Info
   A function that adds or updates the latest Main L1 chain ID and FT Manager contract information.
   Sends requests to the FT Manager contracts on the Main L1 and the FT contracts on the App L1.

• setFTInfo
   A function that adds or updates the chain ID and contract information of an App L1 FT contract.
   Sends a request to the FT Manager contract on the Main L1.

• setFTManagerInfo
   A function that adds or updates the chain ID and contract information of a Main L1 FT Manager.
   Sends requests to the FT Manager contracts on the Main L1 and the FT contracts on the App L1.

• setRouterInfo
   A function that adds or updates the chain ID and contract address of the Router L1.
   Sends requests to the FT Manager contracts on the Main L1 and the FT contracts on the App L1.

Flow

Requests from App L1

The flow that occurs when a request involving FT usage is initiated from a DApp on an App L1.

sequenceDiagram
    autonumber
    participant DApp as DApp (App L1)
    participant SC1 as FT (App L1)
    participant SC2 as FT (Other App L1)
    participant Router as Router
    participant SCM1 as FT Manager (Main L1)
    participant SCM2 as FT Manager (Other Main L1)

    %% Initial request
    DApp ->> SC1: FT transfer request

    Note over DApp, SCM2: If the Main L1s managing the balances of the sender and recipient addresses are already known,<br>the FT contract retrieves the FT Manager’s chain info and forwards the request.
    alt The Main L1s managing the balances of the sender and recipient<br>are already registered in the App L1 FT contract (*①)
        SC1 ->> SCM1: forward transfer request
        SCM1 ->> SCM1: validate
        alt validation fails
            SCM1 ->> SCM1: revert with error
        end

        SCM1 ->> SCM1: execute transfer logic

        alt Request must be sent back to the originating App L1 FT
            SCM1 ->> SC1: send follow-up request
        end

        alt Request must be sent to another App L1 FT
            SCM1 ->> SC2: send follow-up request
        end

        SCM1 ->> SCM1: update sender balance

        alt recipient’s balance is managed by a different Main L1
            SCM1 ->> SCM2: send balance update request
        else
            SCM1 ->> SCM1: update recipient balance
        end
    else The Main L1s managing the sender and recipient balances<br>are not registered in the App L1 FT contract
        SC1 ->> Router: forward transfer request
        Router ->> Router: determine Main L1s managing sender and recipient balances
        alt sender’s balance is managed by SCM1
            Router ->> SCM1: forward transfer request
        else
            Router ->> SCM2: forward transfer request
        end
        Note over DApp, SCM2: Follow-up processing is the same as in step ①
    end

Loading

Blocklist

A mechanism is REQUIRED to prevent specific addresses from using the FT in cases where they attempt to acquire it fraudulently or engage in malicious behavior (e.g., improperly acquiring other ERC20 tokens and converting them into FT).
This functionality MUST be implemented in the FT Manager contract on the Main L1, the FT contract on the App L1, and the Router contract on the Router L1.

The reason this function MUST also be available on the App L1 FT contract is that, in cases where the sending amount is fully covered by the balance on the App L1, the FT contract sends only the result to the FT Manager contract on the Main L1.

Figure 5: Blocklist management on Main L1 and App L1

There are two possible routes for registering an address to the blocklist, as illustrated in Figure 5:

1. The first route is initiated by an authorized address on the Router L1, which calls the function on the Router contract to register or remove an address from the blocklist.
   During this process, the Router contract MUST send requests to both the FT Manager contracts on the Main L1 and the FT contracts on the App L1 to add the specified address to their respective blocklists.
   This ensures that the address is prevented from using FT system-wide.
   Additionally, the system MUST manage data in a way that clearly indicates the address is globally blocklisted.

2. The second route allows an administrator of the App L1 FT contract to register or remove an address from the blocklist locally.
   This restricts the address from using FT only on that specific App L1.

The first method enables a global block across the system but requires evaluation and execution by the administrator of the Router contract.
As such, even if an administrator on an App L1 submits a request to add an address to the blocklist, the action MAY not be processed immediately.

Therefore, the second method provides a way to quickly block FT usage at the App L1 level, helping to mitigate potential damage swiftly.

Lock

Typically, a request to the FT Manager contract on the Main L1 requires a minimum processing time of 6 seconds.
Example: App L1 (2s) → Main L1 (2s) → App L1 (2s)

However, there are cases where faster processing is REQUIRED on specific App L1 chains when using FT, such as:

• Purchasing NFTs with a specified sale start time
• DeFi trading
• Token sales

To support such use cases, the system provides a mechanism called Lock, which enables faster FT usage by locking a portion of the user's balance, making it usable only on a specific App L1.

Lock Flow

Figure 6: Locking FT

In Figure 6, User A locks 5 ETH worth of FT on an App L1 FT contract.

Precondition: User A owns 4 ETH on App L1 A, 5 ETH on App L1 B, and 3 ETH on App L1 C.

1. User A sends a request to lock 5 ETH worth of FT via a Dapp on App L1 B.
2. If the FT contract manages User A’s balance, it sends the lock request to the FT Manager contract on Main L1 A (assuming User A’s balance is managed there).
   If the managing Main L1 is unknown, the request is instead sent to the Router contract on the Router L1.
3. User A sends a transfer request of 6 ETH from App L1 A to User B.
4. The FT contract on App L1 A sends the transfer request to the FT Manager contract on Main L1 A.
5. The transfer request is processed using the unlocked portion of User A’s balance (7 ETH), excluding the 5 ETH that is locked, and forwarded to the relevant App L1 contracts.

This ensures that locked FT is NOT used in requests relayed through Main L1.

Using Locked FT

Figure 7: Transferring Locked FT

To use locked FT, the system provides a dedicated function called lockTransfer.
When this function is called, the FT contract on the current App L1 first processes the transfer using the locked balance.
It then sends a request to the FT Manager contract on the Main L1 to reflect the deduction.

The transfer flow in Figure 7 is as follows:

1. User A sends a transfer request via a Dapp on App L1 B to the FT contract on App L1 A.
2. The FT contract on App L1 B transfers the locked FT owned by User A.
3. After the transfer is complete, the contract sends a request to the FT Manager contract on Main L1 A to update the locked balance.

As a result, the minimum processing time becomes 4 seconds.
Example: App L1 (2s) → Main L1 (2s)

Furthermore, since the App L1 contract executes the transfer first and only sends the result to the Main L1, follow-up Dapp operations MAY proceed immediately, making the effective latency as low as 2 seconds.

Integration with the transfer Function

In addition to using the lockTransfer function, the functionality MAY also be integrated into the transfer function. This allows the following behavior:

• If the locked FT balance is sufficient for the transfer amount, the lockTransfer logic is invoked internally.
• If the locked balance is insufficient, the transfer is processed via a request to the Main L1 FT Manager contract.

To ensure compatibility with ERC-20 Dapps, it is RECOMMENDED to integrate this behavior into the transfer function.
However, in cases where users require full control over when locked funds are used, it MAY be PREFERRED to invoke the lockTransfer function explicitly rather than integrating it into transfer.

Balance Transfers Between App L1 Chains

When FT is locked, the amount that can be locked is limited to the balance held on the current App L1 chain.
Therefore, to increase the amount of assets that can be locked, it is NECESSARY to enable balance transfers between App L1 chains.
To achieve this, a function called localTransfer MUST be implemented.

When the localTransfer function is executed, a request is sent to the FT Manager contract on the Main L1 that manages the caller’s balance.
This contract determines how much FT should be transferred from each App L1 chain to the requesting App L1’s FT contract.
At this time, both the locked FT and the FT balance already held on the requesting App L1 MUST be excluded from the transfer calculation.

After this determination, requests are sent to the FT contracts on each relevant App L1.
This mechanism enables seamless FT balance transfers across App L1 chains.

Restrictions on Teleporter Contracts

On each L1 chain, the deployed Teleporter contract MUST be configured to only accept requests from the following contracts deployed on the same L1:

• FT Manager contract
• FT contract
• Router contract

This restriction ensures that even if another contract on the same L1 attempts to send a request via ICM to a different L1, the request will FAIL unless it originates from an authorized contract.
By enforcing this restriction, unauthorized requests via ICM can be effectively prevented.

Execution Policy

When sending a request using ICM from contracts within the system (including all Main L1s, App L1s, and the Router L1), it is often difficult to determine the precise execution path of the request at the time of submission. As a result, specifying the following parameters becomes challenging:

• feeTokenAddress: The token contract used for relayer fees.
• amount: The amount of tokens used for relayer fees.
• requiredGasLimit: The gas limit for transaction execution.
• allowedRelayerAddresses: An array of permitted relayer addresses.

Therefore, it is RECOMMENDED that each L1 contract implements a mechanism to manage default execution information (Execution Policy) for each destination L1, as shown below:

struct ExecutionPolicy {
    address feeTokenAddress;
    uint256 amount;
    uint256 requiredGasLimit;
    address[] allowedRelayerAddresses;
}

mapping(bytes32 => ExecutionPolicy) internal executionPolicies;

This allows contracts to independently restrict relayers and fee tokens per destination L1, enabling custom execution control per L1.

However, note that if the fee is insufficient, the transaction will fail. Thus, it is RECOMMENDED not to set default values for fee-related fields, allowing more flexibility for fee adjustments.

Only in the case of requests sent from FT contracts on App L1s, these parameters MAY be specified directly during the request. In such cases, the requiredGasLimit field SHALL always use the default value.

This is necessary because gas costs differ by App L1. For example, an App L1 with zero gas fees could overload the system by submitting excessive transactions, potentially causing congestion on the Main L1. Setting a default requiredGasLimit value ensures consistent limits across App L1s and helps control resource usage.

FT contracts' external and public functions MAY accept execution policy parameters as input arguments. However, additional validations SHOULD be performed—for example, disallowing relayer addresses not included in the default policy, or enforcing array length restrictions.

An alternative implementation MAY ignore any values provided outside the default configuration and enforce the default execution policy rigidly.

Managing totalSupply

There are two main approaches to tracking the total supply of the FT:

1. On-chain, inside the contracts
2. Off-chain, via an API

1. On-chain tracking

• The Router contract on the Router L1 can record the total supply and expose it on-chain.
• Whenever a mint or burn occurs, the initiating contract (e.g., a FT Manager on a Main L1 or a FT contract on an App L1) must send a request to the Router contract so it can update the figure.
• If contracts on Main L1s or App L1s also need to read the total supply directly, they can keep their own local copy. In that case, the Router contract would push updates to them after each mint or burn.
• Because mint and burn events are relatively infrequent, the extra ICM calls are acceptable.

2. Off-chain tracking (RECOMMENDED)

• Run an off-chain indexer that listens to mint and burn events from all L1 contracts.
• Store the running total in a database and expose it through an API for DApps or other off-chain clients.
• This avoids extra on-chain calls and keeps the contracts simpler, but on-chain contracts cannot query the total supply directly.

While the off-chain approach is preferred for efficiency, implementing the on-chain method as well can be useful when contracts themselves need to reference the total supply.

Rationale

Why FT Balances Are Managed on Main L1

FT balances held on App L1s are managed on a Main L1 to enable a unified source of truth for balance queries. Although it is possible to manage balances across App L1s off-chain, this would make it difficult to retrieve the full balance on-chain. By consolidating balance management on the Main L1, it becomes possible to perform balance validation at the time of transfer operations.

Why Multiple Main L1s Are Needed

Having a single Main L1 would simplify processing and eliminate the need for a Router L1. However, this can lead to congestion on the Main L1 as the volume of requests increases, resulting in slower transaction processing. To address this, the system SHOULD utilize multiple Main L1s to distribute processing load and prevent bottlenecks. This proposal does not define how many addresses each FT Manager on a Main L1 SHOULD manage—that is left for future decisions.

Is It Necessary to Have Multiple Main L1s?

In the initial stages, a single Main L1 MAY be sufficient. However, as the number of App L1s and users increases, transaction volume will also increase, potentially degrading user experience (UX) due to longer confirmation times. To maintain performance, deploying multiple Main L1s is RECOMMENDED. The criteria for how many addresses a single Main L1 SHOULD manage is not defined in this proposal and will need to be determined later.

Why Transfers Are Not Executed Directly from App L1

In this proposal, the FT Manager contract on the Main L1 determines how much FT to transfer from each App L1 and executes the transfer. While it is technically possible to initiate the transfer directly from an App L1, doing so would require fetching the user's total balance from the Main L1, resulting in additional cross-chain transactions. Furthermore, not all App L1s are interconnected via ICM. Since the Main L1 acts as the central hub for all App L1s, all cross-App L1 FT transfers SHOULD be executed from the Main L1.

When FT Balance on App L1 Is Sufficient

If a transfer request is made and the transfer amount is fully covered by the sender’s FT balance on the App L1, and both the sender’s and recipient’s Main L1 and corresponding FT Manager contract are known, the App L1 MAY execute the transfer locally and send only the result to the FT Manager on the Main L1. This helps AVOID unnecessary requests to the FT Manager contract.

When a FT Contract Is Arbitrarily Deployed

It is possible for unauthorized FT contracts to be deployed on various App L1s. However, actual FT transfer logic is executed on the FT Manager contract on the Main L1, which MAINTAINS a registry of authorized FT contracts deployed on App L1s. Any request from a contract not listed in this registry WILL FAIL.

Router L1 May Be Cost-Prohibitive

Operating an L1 incurs significant annual costs. Minimizing the number of L1s DEPLOYED is RECOMMENDED for both cost and manageability. Since Router L1 is responsible for maintaining a mapping of which Main L1 manages a given address, it MAY be consolidated into the first Main L1. In that case, FT contracts on each App L1 CAN forward requests to the first Main L1 if they cannot determine which Main L1 manages a particular address. Additional Main L1s beyond the first DO NOT NEED to deploy a Router contract and MUST only reference the Router's deployed location.

Handling Consecutive Transactions

It is possible that multiple transfer requests are sent simultaneously from FT contracts on different App L1s. Because transfer and burn operations are ALWAYS processed by the FT Manager on the Main L1 that manages the sender’s balance, requests WILL BE handled in sequence. This ENSURES that no more FT is consumed than is available in the sender’s balance.

Transfer Optimization Logic

When executing a transfer, the FT Manager contract on the Main L1 MUST determine from which App L1s and in what proportions the sender’s FT should be sourced. Although this is beyond the scope of this proposal, the following allocation strategy is RECOMMENDED: it attempts to use the minimum number of App L1s and avoids leaving small residual balances ("dust"). The process is composed of three stages:

1. Single-Chain Exact Match

   • If an App L1 has a balance that EXACTLY matches the transfer amount, that balance is used.

2. Two-Chain Exact Match (Two-Pointer Technique)

   • Sort balances in descending order and use two pointers to find a pair that sums to the transfer amount.
     Example:

     • Sorted balances: [8, 4, 3, 2, 1, 1], Target: 6
     • Start with left = 0 (8), right = 5 (1)
     • 8+1=9 → too much → left = 1
     • 4+1=5 → too little → right = 4
     • 4+1=5 → still too little → right = 3
     • 4+2=6 → exact match → use balances from those two chains

3. Suffix Accumulation Fallback

   • Starting from the smallest balances, accumulate up to a MAXIMUM of K App L1s until the transfer amount is met.
   • If still insufficient, pick the App L1 with the smallest balance that meets or exceeds the remaining required amount.

This method maintains an O(N log N) complexity due to sorting, and it helps reduce gas usage and leftover balances efficiently.

Monitoring and Automatic Retry

In this proposal, it is RECOMMENDED to monitor events emitted by the Teleporter contract (TeleporterMessenger) and perform automatic retries or alerts in case messages sent via ICM get stuck and are not processed on the destination L1.

Events to Monitor

Event	Role
ReceiveCrossChainMessage	Detect receipt of a request.
MessageExecuted	Indicates successful execution after receiving the request.
MessageExecutionFailed	Indicates failure of execution (e.g., due to revert) after receiving the request.

Monitoring Flow

1. Monitoring
   Monitor all events emitted by TeleporterMessenger from contracts within the system (FT Manager on Main L1, FT on App L1, Router on Router L1).

2. Status Management
   Track the status and information of each message by its messageId.

3. Failure Detection
   If ReceiveCrossChainMessage is emitted but MessageExecuted is not, or if MessageExecutionFailed is emitted, classify it as "incomplete".

4. Automatic Retry
   Retry execution of the request.

5. Alerts / Final Judgment
   If retries fail N times, notify the operations team.
   (The number of allowed retries is outside the scope of this proposal.)
   Take manual action if necessary.

Contract Upgrade

All contracts SHOULD be upgradeable. Making contracts upgradeable allows the logic to be modified without changing the contract address used for calls. This also makes it easier to patch vulnerabilities.
Upgrade functions MUST be restricted to authorized addresses, which are RECOMMENDED to be controlled by the Main L1 operator.

Initial Mint on Contract Deployment

Figure 8: Initial Mint of FT

When deploying the FT contract on App L1, initial minting MAY be required.

When deploying the FT contract on App L1, it is deployed by the administrator of Router L1, and the initial FT minting is performed in the initialization function (constructor or initialize).

At this time, the FT contract does not store information about which Main L1 and FT Manager contract manages each address’s balance.
Therefore, the initialization function MUST accept the mapping of already managed addresses to their Main L1 and FT Manager contract as arguments.

For addresses with known Main L1 and FT Manager, requests MUST be sent directly to the corresponding Main L1.
For addresses not yet associated with a manager, requests MUST be sent to Router L1.

This enables efficient initial minting.

When to Scale Main L1

There is a limit to the number of transactions that can be processed on a single Main L1. If the volume of transactions becomes too high, processing times will increase. Therefore, this proposal takes an approach that distributes processing load by increasing the number of Main L1s responsible for managing balances per address. In such cases, it is necessary to establish indicators for when to scale Main L1. While outside the scope of this proposal, relevant indicators are summarized below:

• TPS
• Number of addresses
• Transaction execution time

The first indicator is TPS (transactions per second). If the number of incoming requests exceeds the TPS that can be handled by the Main L1, additional Main L1s SHOULD be introduced. Rather than waiting until the TPS threshold is reached, it is RECOMMENDED to add a new Main L1 when about 80% of the TPS capacity is utilized to allow for a buffer.

The second indicator is the number of addresses. As the number of addresses with managed balances increases, the likelihood of a higher transaction volume also increases. Even if TPS is not currently a problem, a sudden spike in transaction count may occur at some point, making this a valuable metric when considering whether to add a new Main L1.

The third indicator is transaction execution time. If transactions take a long time to execute, this may indicate an accumulation of pending transactions, suggesting the need for more Main L1s. While execution time is generally influenced by TPS, it is still a useful reference metric.

These indicators can only be validated through actual measurement during implementation. In addition, if other metrics prove useful, they SHOULD also be tracked.

Backwards Compatibility

This proposal maintains backwards compatibility between the FT contract and ERC-20.

Reference Implementation

Security Considerations

Main L1 and Router L1 Providers

The providers of the Main L1 and the Router L1 MUST be the same. If they differ, the Main L1 would have to trust the Router L1, and any malicious logic within the Router L1 could be executed as is. It is also possible to integrate the Router L1 into the Main L1. For more details, refer to the section "High Costs of Deploying a Router L1".

Unauthorized Requests from Arbitrary L1s or Contracts

L1s or contracts using the FT MAY attempt to send requests—such as FT transfers—to system contracts (i.e., the FT Manager contract on the Main L1, the FT contract on App L1s, and the Router contract on the Router L1). However, in this proposal, each contract maintains a whitelist of allowed requests received via ICM. Any request from an unapproved L1 or contract will fail execution.

Operation as a Unified System

This system is composed of the following three categories of L1s and contracts:

• The FT Manager contract on the Main L1
• The FT contract on the App L1
• The Router contract on the Router L1

Each L1 deploys a Teleporter contract that restricts which contracts can receive requests. Each contract validates the origin L1 and the sender Teleporter contract when receiving a request via ICM. As a result, only authorized L1s and Teleporter contracts, as well as the designated system contracts (FT Manager, FT, and Router), are permitted to send requests, preventing unauthorized L1s or contracts from injecting invalid requests.

Double Updating of totalSupply

When updating totalSupply, events MUST be monitored to update the database that supports the off-chain API. These events SHOULD be emitted from the App L1’s FT contract. If the system instead monitors events from the FT Manager contract on the Main L1, there is a risk: if a request from the FT Manager to the App L1’s FT contract fails, the FT Manager would have already updated totalSupply, creating a mismatch between on-chain and off-chain states.

Copyright

Copyright and related rights waived via CC0.

[cam-schultz]

Thanks for starting this discussion @cardene777 . I appreciate the high level of detail you've included, especially regarding the data flow. The protocol relies heavily on ICM messaging, with multiple messages sent between the App, Router, and Main L1s to execute a transfer, for example. At present, ICM verification costs ~500,000 gas (though future optimizations may reduce this by an order of magnitude or so). Requiring multiple ICM verifications per transfer may be prohibitively expensive for many use cases.

What use cases would this standard enable that isn't already achieveable (with perhaps some tradeoffs) by ICTT? Discovery and sourcing of fragmented assets can be done off chain, requiring at most two ICM messages to link a liquidity source to a destination. Doing so on-chain, however, would require ICM messages to the Router, Main chain for the recipient, Main chain for the sender, and the two App chains involved in the transaction (correct me if my count is off here). Regardless of the approach, transfers that involve pulling in liquidity from an external chain cannot be done in a single transaction, since ICM is not atomic across chains.

[cardene777]

@cam-schultz
Thank you for the confirmation and feedback.

At present, ICM verification costs ~500,000 gas (though future optimizations may reduce this by an order of magnitude or so). Requiring multiple ICM verifications per transfer may be prohibitively expensive for many use cases.

Regarding gas costs, it’s true that users currently bear the cost only on the App L1 side. However, it’s also possible to build a system where the App L1 operator covers the gas fees on behalf of users.

What use cases would this standard enable that isn't already achievable (with perhaps some tradeoffs) by ICTT?

It’s true that similar functionality could be achieved by combining ICTT with off-chain applications.
However, the strength of this proposal lies in the ability to execute FT transfers directly from smart contracts.
Of course, the result can’t be confirmed within the same transaction, but unlike the ICTT + off-chain application setup—where contract-based execution is not possible and off-chain interaction is always required—this approach enables smart contracts themselves to initiate transfers.
As a result, FT transfers and burns spread across multiple L1s can be triggered as if they were operating on a single L1.

Doing so on-chain, however, would require ICM messages to the Router, Main chain for the recipient, Main chain for the sender, and the two App chains involved in the transaction (correct me if my count is off here).

That maximum count is correct.
The minimum number of chains involved is three: one Main L1 and two App L1s.
For reference, I’ll also share the processing time:
The minimum time required to complete a transfer from the sender’s side is 6 seconds.
Example: App L1 (2s) → Main L1 (2s) → App L1 (2s)

However, by using the lock feature, this can effectively be reduced to just 2 seconds.
For details, please refer to the Lock section in the Specification.

Regardless of the approach, transfers that involve pulling in liquidity from an external chain cannot be done in a single transaction, since ICM is not atomic across chains.

We’re aligned on this point.
Achieving cross-chain transactions in a single atomic execution remains a difficult challenge, and one that many are actively trying to solve.

[cardene777]

What use cases would this standard enable that isn't already achievable (with perhaps some tradeoffs) by ICTT?

I don’t believe there are any use cases that cannot be achieved with ICTT and can only be realized with the proposed mechanism.
However, I do think there are use cases where the proposed approach offers a better solution.

For example, consider a scenario where companies or projects each create their own L1 chain but want to use a common token across all of them.
Various smart contracts would likely be deployed on each L1, and one advantage of the proposed mechanism is that these contracts can directly receive requests involving the shared token.

Discovery and sourcing of fragmented assets can be done off chain, requiring at most two ICM messages to link a liquidity source to a destination.

In addition to the benefit of allowing direct calls from individual smart contracts, the proposed approach offers the following advantages:

When managed off-chain, a single website typically needs to handle balance aggregation, manage user interfaces, and select which chain to use for processing.
As the number of supported chains grows, this site may become a performance bottleneck and a single point of failure.

In contrast, while the proposed mechanism may introduce a potential single point of failure in the form of a Main L1, we have also proposed a decentralized architecture to mitigate this risk.