Receipt

Conditional state changes in the background enable complex transactions. For example, a HashLockTransaction concludes as soon as the AggregateBondedTransaction is confirmed. When the locked funds are automatically returned to the account, there is no additional transaction recorded. This might appear as a hidden change that increases the account balance.

Receipts provide proof for every hidden change. The collection of receipts are hashed into a merkle tree and linked to a block. The block header stores the root hash, which is different from zero when the block has receipts.

Transaction statement

A transaction statement is a collection of receipts linked to a transaction in a particular block. Statements can include receipts with the following basic types:

  • Balance Transfer: An invisible state change triggered a token transfer.

  • Balance Change: An invisible state change altered an account’s balance.

  • Token Expiry: A token expired.

  • Namespace Expiry: A namespace expired.

  • Inflation: Network currency tokens were created due to inflation.

Resolution statement

When a transaction includes an alias, a so called Resolution Statement reflects the resolved value for that block:

The alias receipts record the first occurrence of an (unresolved, resolved) alias pair used in a block.

It is technically possible to get more than one resolution for the same namespace id and block. This situation is common when a namespace creator changes the alias link to another asset, leading to two different resolutions in the same block.

The receipt source primaryId references the transaction where the alias first appears within the block. The secondaryId is not 0 when the transaction is part of an AggregateTransaction, and it will indicate the index position within the aggregate.

Recorded receipts

Bitxor records invisible state changes for the following entities.