Skip to main content

Important terms

This section provides high—level explanation of the most used terms in the documentation for the FT4 library.

Account​

An account is an on—chain entity. It can hold auth descriptors to allow one or more users to access it. It can hold assets.

While the most similar entity on an EVM chain would be an Externally Owned Account (EOA), an account has some key differences:

  • It's not needed to interact with the blockchain unless coded to do so. If a dapp doesn't use FT4, they might not even have accounts.
  • It's not tied to a keypair. While on EVMs only one keypair can access an EOA, here on Chromia, you can define auth descriptors to allow multiple keypairs. This doesn't mean the original owner can lose access to the account, though: look at the auth descriptor section to learn more.

This last point also means an account can't "sign" a transaction, as it has no associated keypair. Users can sign a transaction on its behalf through auth descriptors.

Asset​

An asset is an on—chain entity that can be used to represent many things, like tokens, shares of ownership, and tickets to an event.

FT4 only supports fungible assets: the most similar entity on an EVM chain would be an ERC20.

Auth descriptor​

An auth descriptor is permission to operate as an account. They must be bound to the account they're allowing access to, but one auth descriptor can also be bound to multiple accounts. It can be limited in different ways.

It has a few components:

  • Signers: the users that this descriptor represents.
  • Number of signers: If there is more than one signer, this parameter defines how many of those signers need to sign before the transaction is accepted.
  • Flags: they define what the signer can do with the account. There are two basic flag types, and dapp developers can define more:
    • Account (or A): allows to edit the account details, like adding or removing auth descriptors.
    • Transfer (or T): allows to transfer assets out of the account, including burning them.
  • Rules: they define when the auth descriptor can be used and when it'll expire. They're discussed in more depth in the expiration rules section.

Not to be confused with the auth handlers.

Auth handler​

An auth handler specifies what permissions are needed to call an operation.

Most operations in FT4 require an account to be called: the auth handler for that operation specifies whether specific auth descriptors have sufficient authorization to call that operation on the account's behalf successfully.

Not to be confused with the auth descriptors.

Balance​

The amount of a certain asset that is held by an account. It is an on-chain entity, separate from the account and the asset. This differs from EVM chains, where the balance is a map stored in the asset contract.

Expiration rules​

Expiration rules are a component of auth descriptors. They limit the signers' access to the account. They can limit:

  • The number of authorizations: the signers can only approve certain operations for this account. While one transaction can contain multiple operations, they'll be counted as different authorizations.
  • The block number: the signers can only approve transactions before or after a certain block number.
  • The block time: the signers can only approve transactions that happen before or after a block where the last block timestamp is specified in the rule. This can generally be used to specify a time expiration for the auth descriptor, but remember that the rule applies to the last block timestamp. If an auth descriptor expires after time X, and the last block timestamp is X - 1s, the signers can approve transactions in the next block even if it takes longer than one second to produce.

More rules'll be added in the future, and we're planning to allow dapp developers to implement custom rules somewhere down the road.

User​

Whenever the docs refer to a user, it should be understood as a key pair. Ideally, only one person can access any key pair, meaning a user should represent a physical person. When shared control is required, please use multi-signature schemes! Sharing a private key is neither safe nor should be required by dapp developers in the Chromia ecosystem.