Skip to main content

Features

FT4 supports the following features:

  • Account management
  • Asset management and transaction history

Account management​

The central entity of the FT4 module is the account. An account is uniquely identified by an id:

entity account {
  key id: byte_array;
}

Multiple users can control an account with different levels of access rights. The authentication descriptors define who can control an account and what he can do with it:

entity account_auth_descriptor {
   id: byte_array;
   key account, id;
   index id;
   auth_type;
   args: byte_array;
   rules: byte_array;
   mutable ctr: integer;
}

Auth descriptors and access control​

In FT4, accounts can be accessed using multiple key pairs, enabling various possibilities. Auth descriptors determine who can access an account and specify their access level. There are two types of auth descriptors: single—signature and multi—signature.

  • Single—signature auth descriptor: This auth descriptor specifies only one participant, typically identified by a public key when using native postchain signatures or an EVM account address when using EVM signatures.

  • Multi—signature auth descriptor: This auth descriptor involves two or more participants, with the number of required signatures specified. Similarly, participants are identified by public keys or EVM account addresses. Only one type of signer is allowed on each auth descriptor.

Auth flags and operation authorization​

Auth flags define what actions an auth descriptor is authorized to perform on an account. When authenticating users for operations, the necessary auth flags must be specified; else, the transaction'll be rejected.

FT4 defines the following built—in auth flags:

  • T (Transfer) flag: This flag is required for transfer operations. If an auth descriptor lacks this flag, transfer operations'll be rejected.

  • A (Account) flag: This flag is required for FT4 account operations, such as adding or deleting auth descriptors.

In addition to the built—in auth flags, Dapps can define custom auth flags to support their specific authorization requirements.

Expiration rules for auth descriptors​

Auth descriptors can have expiration rules defined, determining their validity over time. The following expiration rules are supported:

  • Block height: An auth descriptor can be set to expire after a certain block height.

  • Block time: An auth descriptor can be set to expire after a specific block time.

  • Number of authorizations: An auth descriptor can be set to expire after being used a certain number of times to authorize a user.

It's important to note that auth descriptors added during account creation cannot have expiration rules set. It prevents users from accidentally losing access to their accounts.

Asset management​

FT4 provides support for multiple assets. The asset table contains a list of registered assets:

entity asset {
   key id: byte_array;
   name;
   key symbol: text;
   decimals: integer;
   issuing_brid: byte_array;
   icon_url: text;
   mutable total_supply: big_integer;
}
note

Although the transfer is only possible within the same chain for now, issuing_chain_rid is available in preparation for the forthcoming release when FT4'll support cross—chain asset transfer.

The balance table keeps track of an account's assets:

entity balance {
   key acc.account, asset;
   mutable amount: big_integer = 0L;
}