Tokens on delta

Overview

Tokens are built into delta's core protocol design. Rather than requiring smart contracts or external standards, token primitives are native to the base layer, keeping the system simple and predictable.

delta’s token design includes only two token kinds: fungible, and non-fungible (NFTs). All assets on delta are represented by one of these two primitives.

Each fungible token or NFT collection:

• Exists on delta as a Token Mint, controlled by the issuing party and located on a domain
• Is identified by a Token ID (fungible) or Collection ID (NFTs), equivalent to the address of the mint vault

Fungible Tokens

A token is considered fungible if each unit is identical and interchangeable with any other unit of the same token, similar to how one dollar bill has the same value as any other dollar bill. The most basic fungible token on the delta network is the delta native token, which is used for transactions to the delta base layer.

Non-native fungible token balances on delta are stored in Token Holdings vaults, while all their metadata (such as token name and issuer) is stored in the Token Mint vault.

Fungible tokens are represented in token holdings vaults or in transaction messages simply by the Token ID (the address of the NFT mint vault) and a balance in plancks, the lowest denomination of a token on delta.

Non-Fungible Tokens (NFTs)

A non-fungible token (NFT) is a unique digital asset that cannot be replicated or exchanged on a one-to-one basis with another token, as each NFT contains distinct metadata and properties that differentiate it from all others.

On delta, a NFT is identified by its Collection ID (the address of the NFT mint vault) and the ID of that specific token.

Token Operations

Token operations are beautifully simple on delta. Creating a new token or issuing additional supply can be handled in a single transaction.

Minting

Issuing a new token on delta involves defining a new Token Mint. The signer used to authorize the mint operation will become the owner of the token mint vault.

The token mint vault will live on the shard of the domain where the mint operation occurs, but initial minted supply can be credited to recipient vaults on any domain.

Create Fungible Token Mint

A fungible token mint requires two pieces of information: the token's metadata (name and symbol) and the initial supply distribution.

The metadata defines how the token will be identified:

• name: The full name of the token (e.g., "US Dollar Coin")
• symbol: The ticker or abbreviation (e.g., "USDC")

The initial supply is defined by specifying which vault addresses should receive tokens and how much each should receive. The total supply is calculated as the sum of all credited amounts.

fungible::Create {
    metadata: Metadata {
        name: "My Token".to_string(),
        symbol: "MYT".to_string(),
    },
    credited: vec![
        (vault_address_1, 500_000),
        (vault_address_2, 500_000),
    ],
}

Once created, the token mint vault stores the total supply and metadata. The actual token balances are held in token holding vaults.

Create NFT Mint

An NFT mint creates a collection of non-fungible tokens. Unlike fungible tokens, each NFT has its own unique ID and metadata within the collection.

The mint operation requires:

• collection metadata: Name, description, and attributes for the entire collection
• credited NFTs: A list of vault addresses and the specific NFTs each should receive

Each NFT in the collection has:

• A unique ID within the collection
• Individual metadata (name, description, and custom attributes like URIs)

nft::Create {
    collection: Metadata {
        name: "My NFT Collection".to_string(),
        description: "A collection of unique items".to_string(),
        attributes: BTreeMap::from([
            ("uri".to_string(), "https://example.com".to_string())
        ]),
    },
    credited: vec![
        (vault_address_1, vec![nft_1, nft_2]),
        (vault_address_2, vec![nft_3]),
    ],
}

The token mint vault for an NFT collection maintains the collection metadata and tracks all minted NFTs in its supply map.

Increasing Supply

Both fungible and non-fungible tokens support supply increases after creation. Only the owner of the token mint vault can authorize additional minting.

For fungible tokens, the vault addresses and amounts to credit must be specified:

fungible::IncreaseSupply {
    credited: vec![
        (vault_address_3, 1_000_000),
    ],
}

For NFTs, the vault addresses and new NFTs to mint must be defined:

nft::IncreaseSupply {
    credited: vec![
        (vault_address_4, vec![nft_4, nft_5]),
    ],
}

The total supply in the token mint vault automatically updates to reflect the new tokens.

Transferring

Transferring tokens between vaults uses the debit allowance operation. This operation debits tokens from the signer's vault and credits them to a specified destination vault.

A debit allowance specifies:

• credited address: The vault receiving the tokens
  • Always defined explicitly
  • Can be located on any shard
• allowances: A map of token kinds to amounts (the maximum that can be debited)
  • For fungible tokens, the allowance will be an amount in plancks
  • For NFTs, the allowance will specify specific NFTs (by ID)
• debited shard: The shard where the debiting vault is located
  • The debitAllowance must be processed by the domain which controls this shard
  • The debited vault address is determined from the signer's owner ID and the debited shard

The debit allowance defines the maximum amounts that can be moved. The actual amounts debited are determined by the domain's business logic and must not exceed the specified allowances.

Burning

Token burns are not currently an explicit operation on the delta protocol. In order to reduce a token's usable supply, balance can be transferred to a chosen burn address.

Token Laws

note

Token Laws are planned functionality, and some details may change during implementation.

delta supports native token-level controls which cover the vast amount of compliance use cases. For each token, issuers will be able to define

• Allow/block-listed user addresses: Control which accounts can mint/transfer/receive the token.
• Allow/block-listed domains: Control which domains the token can travel to.
• Required credential: Only accounts with the required credential (such as a KYC NFT) can mint/transfer/receive the token.