Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

• Auto
• Light
• Dark

Algorand Specifications

A transaction defines a state transition of Accounts.

Algorand has 88 transaction types.

Transactions consist of:

• A header (common to any type),
• A body (type-specific).

Important

IMPLEMENTATION:

Transaction package.

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.

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.

Important

IMPLEMENTATION:

The reference implementation also defines the unknown transaction type.

Transaction types definition.

Important

IMPLEMENTATION:

Transaction types reference implementation.

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 00) within a transaction Group.
• FirstValidRound\rF\rF and LastValidRound\rL\rL The difference (rL−rF)(rL−rF) cannot be greater than 10001000 rounds.
• Note (Optional) Contains up to 11 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 LastValidRoundrLrL 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 (10001000 μ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 (10001000 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.