Skip to main content


Transaction Lifecycle

The following diagram explains the basic process from a Transaction to TxPoW unit to Block.

TransactionsCore Concepts


All transactions have the following structure:

  • Inputs
  • Outputs
  • State variables
  • Link hash
  • Transaction ID


Transaction inputs are coins (UTxOs) that will be spent in the transaction, identified by the Coin ID. One or more coins may be required depending on the value of the coins owned by the user and the amount they wish to spend.


If a user wishes to spend 100 Minima but they only have two coins worth 40 and 90 Minima, they must use both coins as inputs to the transaction and receive change of 30 as a new coin.

Each coin is identifiable with a unique CoinID has the following attributes:

Coin AttributeDescriptionType
CoinIDThe globally unique identifier for a coin. The coin id of a new UTxO is hash(first input coin in txn | output_num_in_txn)64 byte hash (MiniData)
AmountThe amount of 'Minima'. Even custom token transactions are just amounts of coloured Minima (see Coloured Coins)MiniNumber
AddressThe hash of a script. If no custom script is provided,the script will simply be RETURN(SIGNEDBY([PublicKey of coin owner]) i.e. the transaction must be signed by the coin owner before it can be spent. All addresses are P2SH (Pay to Script Hash).64 byte hash (MiniData)
Token IDThe Token ID. Minima is 0x00. Everything else has a full 64 byte hash. Tokens are created by colouring Minima.64 byte hash (MiniData)
TokenToken Details (see Coloured Coins)
FloatingTrue or False. Set when you create a transaction. If True, the Coin ID is ignored so that any valid coin that has the same amount, address and Token ID can be used.Boolean
Store StateTrue or False, depending on whether the state is stored for this coinBoolean
StateThe state variables (0-255) of the transaction this coin was created in. You can access this data from scripts.Integer
MMR EntryThe MMR database entry number for this coinMMREntryNumber
SpentTrue or False, depending on whether this coin has been spent or not.Boolean
CreatedThe block number this coin was created in.Integer

Example coin details:

coins relevant:true


Transaction outputs are new coins (UTxOs) created as a result of a transaction and include:

  1. Amount to send to recipients: One or more amounts with recipients' addresses specified.
  2. Change to the sender: When the amount being sent is less than the value of the coin inputs, change needs to be returned to the sender's address.

Any difference between inputs and outputs will be burned, reducing the circulating supply of Minima.

State Variables

Transactions include State Variables for storing public data and previous transaction states to retrieve information for scripts.

256 state variables are allowed per transaction, (see Scripting).

Each transaction has an associated Burn transaction, which may or may not have a value.

A burn transaction uses the transaction ID of the transaction it relates to, as its link hash.

This ensures the burn transaction can only be spent with the transaction it is linked to.

For main transactions, the link hash is set to 0x00.

Transaction ID

The transaction ID is initially set to 0x00 and is then calculated as the hash of the transaction object, including its inputs, outputs, state variables and linkhash.

Burn Transactions

Burn transactions are created automatically and have the following structure compared to a main transaction:

Main transaction structure

Transaction ID: Hash(Transaction object)
State Variables (0-255)
Linkhash (0x00)
Transaction ID

Burn transaction structure (automatically set)

Transaction ID: Hash(Transaction object)
Inputs (matching the main txn)
Output (amount to burn)
State Variables (matching the main txn)
Linkhash (main txn ID)
Transaction ID

Transaction Validity

For a transaction to be valid:

  1. The sum of inputs must be greater than or equal to the sum of the outputs for each Token ID
  2. All inputs and outputs must be valid Minima amounts (between 0-1 billion)
  3. All inputs must have unique coin IDs
  4. It must have no more than 256 state variables

When checking the validity of transactions, the monotonicity is checked to determine whether a transaction needs to be checked more than once.

Scripts of Monotonic transactions only need to be checked once i.e. they are either valid or not e.g. a simple RETURN(SIGNEDBY(..))

Scripts of Non Monotonic transactions need to be checked multiple times. Any script in a transaction that references global variables @BLKNUM, @BLKDIFF or @INBLKNUM is not monotonic as its validity will change depending on these variables.