TIP-20 Token Standard

What is TIP-20

TIP-20 is Tempo’s native token standard. It shares the same interface as ERC-20 (transfer, approve, balanceOf all work the same way) but uses role-based access control (for example issuer, admin, and pause roles) instead of a single Ownable owner. TIP-20 is built for controlled tokens like stablecoins, where minting and burning require strict permissions. On Tempo, tokens like pathUSD are TIP-20 tokens.

This page covers TIP-20 from a LayerZero integration perspective. For the full TIP-20 specification, see the Tempo documentation.

TIP-20 vs ERC-20

Aspect	ERC-20	TIP-20
Interface	standard ERC-20	ERC-20 compatible (same read/transfer API)
Admin model	`Ownable` or custom	role-based access control
Minting	owner or custom logic	requires `ISSUER_ROLE`
Burning	owner, self, or custom	requires `ISSUER_ROLE`
Fee payment	not built-in	built-in stablecoin fee payment on Tempo
Payment lanes	not available	dedicated blockspace for token transfers
Transfer memos	not built-in	32-byte memo field on transfers
Permit	EIP-2612 (optional extension)	TIP-1004 (optional extension)
Compliance	not built-in	TIP-403 policy registry integration

Role-based administration

TIP-20 tokens use ISSUER_ROLE to control mint and burn operations. This differs from the typical Ownable pattern:

ERC-20 with Ownable: a single owner address controls privileged operations
TIP-20 with ISSUER_ROLE: multiple addresses can hold the role, and role management follows a standard access control pattern

Any contract that needs to mint or burn a TIP-20 token, including OFTAlt adapters, must hold ISSUER_ROLE on that token.

Built-in features

TIP-20 extends the ERC-20 interface with Tempo-specific features:

Fee payment: TIP-20 stablecoins can pay Tempo transaction fees (no native gas token needed)
Payment lanes: dedicated blockspace for TIP-20 transfers, providing predictable throughput
Transfer memos: 32-byte memo field attached to transfers for payment references or metadata
Permit (TIP-1004): EIP-2612 permit functionality for gasless approvals via off-chain signatures
Burning: authorized contracts with ISSUER_ROLE can call burn

Compliance integration

Tempo provides the TIP-403 policy registry for whitelist/blacklist enforcement on token transfers. When a TIP-20 token registers a policy, the registry validates every transfer against the policy rules before execution.

Registry address: 0x403c... (on Tempo)
Supports compound policies with separate sender and recipient rules (TIP-1015)
Integrators should be aware that transfers may revert if either party is blacklisted by the token’s policy

For full TIP-403 details, see the Tempo documentation.

How TIP-20 and ERC-20 coexist on Tempo

Tempo supports both TIP-20 and ERC-20 tokens:

TIP-20 tokens are native to Tempo (e.g., pathUSD). They have built-in fee payment, payment lanes, and compliance features.
ERC-20 tokens can be deployed directly on Tempo or arrive via bridges. They follow standard ERC-20 semantics without TIP-20 extensions.

Standard EVM tooling works for both:

balanceOf, transfer, approve, and transferFrom behave the same way
Wallets, block explorers, and SDKs interact with both standards through the same ERC-20 interface
Role-gated operations (mint, burn) are only available on TIP-20 tokens and require ISSUER_ROLE

Integration with OFTAlt

When bridging a TIP-20 token cross-chain using LayerZero, the adapter on Tempo needs to mint tokens on receive and burn tokens on send. TIP-20 tokens only support burn(amount) (burning from msg.sender), not burn(from, amount), so the adapter uses a transfer-then-burn pattern: it transfers tokens to itself first, then burns from its own address. This requires ISSUER_ROLE:

Deploy a OFTBurnSelfMintAlt on Tempo pointing to the TIP-20 token
Grant ISSUER_ROLE to the adapter contract address on the TIP-20 token
The adapter can now mint on receive and burn on send

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.22;

import { OFTBurnSelfMintExtendedRBACAltUpgradeable } from "@layerzerolabs/oft-evm-upgradeable-impl/contracts/extended/alt/OFTBurnSelfMintExtendedRBACAltUpgradeable.sol";

/**
 * @title OFTBurnSelfMintAlt
 * @notice OFTBurnSelfMint variant that pays native fees using an ERC20 token instead of msg.value.
 * @dev For chains where gas/native fees are paid via an ERC20 token (e.g., Tempo using EndpointV2Alt).
 */
contract OFTBurnSelfMintAlt is OFTBurnSelfMintExtendedRBACAltUpgradeable {
    constructor(
        address _token,
        address _burnerMinter,
        address _endpoint,
        bytes4 _burnSelector,
        bytes4 _mintSelector,
        uint8 _rateLimiterScaleDecimals
    )
        OFTBurnSelfMintExtendedRBACAltUpgradeable(
            _token,
            _burnerMinter,
            _endpoint,
            _burnSelector,
            _mintSelector,
            _rateLimiterScaleDecimals
        )
    {}
}

Without ISSUER_ROLE, the adapter’s mint and burn calls will revert. Ensure the role is granted before configuring cross-chain pathways.

On other chains, the same token uses a standard OFT or OFTAdapter. No TIP-20 awareness is needed outside of Tempo.

Whitelisted fee tokens

LZEndpointDollar (LZD) accepts whitelisted 6-decimal TIP-20 stablecoins for fee wrapping:

Token	Type	Can pay LZ fees
pathUSD	TIP-20	yes
USDC.e	TIP-20	yes
USDT0	TIP-20	yes

To pay fees, wrap any whitelisted token into LZD using LZD.wrap(). See the LZD reference for the complete flow.

LayerZero for Tempo

How-To

Reference

TIP-20 Token Standard

What is TIP-20

TIP-20 vs ERC-20

Role-based administration

Built-in features

Compliance integration

How TIP-20 and ERC-20 coexist on Tempo

Integration with OFTAlt

Whitelisted fee tokens

​What is TIP-20

​TIP-20 vs ERC-20

​Role-based administration

​Built-in features

​Compliance integration

​How TIP-20 and ERC-20 coexist on Tempo

​Integration with OFTAlt

​Whitelisted fee tokens

What is TIP-20

TIP-20 vs ERC-20

Role-based administration

Built-in features

Compliance integration

How TIP-20 and ERC-20 coexist on Tempo

Integration with OFTAlt

Whitelisted fee tokens