Transactions

A transaction defines a state transition of Accounts.

Algorand has \( 8 \) transaction types.

Transactions consist of:

• A header (common to any type),

• A body (type-specific).

⚙️ IMPLEMENTATION

Transaction package.

Transaction Levels

Algorand transactions have two execution levels:

• Top Level: transactions are signed and cannot be duplicated in the Ledger,

• Inner Level: transactions are not signed and may be duplicated in the Ledger.

Transaction Types

The transaction type is identified with a short string of at most 7 characters:

For a formal definition of all transaction fields, refer to the normative section.

⚙️ IMPLEMENTATION

The reference implementation also defines the unknown transaction type.

Transaction types definition.

⚙️ IMPLEMENTATION

Transaction types reference implementation.

Transaction Header

The transaction header, equal for all transaction types, consists of:

• TransactionType Identifies the transaction type and the related body required fields.

• Sender
  That signs the transaction.

• Fee
  The amount paid by the sender to execute the transaction. Fees can be delegated (set to \( 0 \)) within a transaction Group.

• FirstValidRound \( \r_F \) and LastValidRound \( \r_L \)
  The difference \( (r_L - r_F) \) cannot be greater than \( 1000 \) rounds.

• Note (Optional)
  Contains up to \( 1 \) kB of arbitrary data.

• GenesisHash
  Ensures the transaction targets a specific Ledger (e.g., wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8= for MainNet).

• GenesisID (Optional)
  Like the Genesis Hash, it ensures that the transaction targets a specific Ledger (e.g., mainnet-v1.0 for MainNet).

• Group (Optional)
  A cryptographic commitment to the group this transaction is part of.

• Lease (Optional)
  32-byte array that enforces mutual exclusion of transactions. If this field is set, it acquires a Lease(Sender, Lease), valid until the LastValidRound \( r_L \) expires. While the transaction maintains the Lease, no other transaction with the same Lease can be committed.

A typical use case of the Lease is a batch of signed transactions, with the same Lease, sent to the network to ensure only one is executed.

• RekeyTo
  An Algorand address (32-byte). If non-zero, the transaction will set the Sender account’s spending key to this address as last transaction effect. Therefore, future transactions sent by the Sender account must now be signed with the secret key of the address.

The transaction header verification ensures that a transaction:

• Is signed adequately by the Sender (either SingleSig, MultiSig, or LogicSig),

• It is submitted to the right Ledger (GenesisHash);

• Pays the MinFee (\( 1000 \) μALGO) or PerByteFee (if network is congested);

  • Fee act as an anti-spam mechanism (grows exponentially if the network is congested or decays if there is spare block capacity);
  • Fee prioritization is not enforced by consensus (although a node does that);
  • Inner Transaction costs always the MinFee (regardless of network congestion);
  • Fee are pooled in Group transactions;
  • Fee is independent of the TransactionType or usage (i.e., no local fee market);

• Round’s validity is not expired (\( 1000 \) rounds at most);

• FirstValidRound can be delayed in the future;

• Round’s validity handles transactions’ idempotency, letting Non-Archival nodes participate in consensus;

• It is not leased (combination of Sender and Lease) in its validity range.