Overview

Transactions are cryptographically signed instructions that modify the Algorand blockchain’s state. The transaction lifecycle follows these steps: creation, signing with private keys, submission to the Algorand network, selection by block proposers for inclusion in blocks, and execution when the block is validated and added to the blockchain. The most basic transaction type is a payment transaction, which transfers Algo between accounts.

Transaction Types

There are eight different transaction types in the Algorand Protocol:

• Payment
• Key Registration
• Asset Configuration
• Asset Freeze
• Asset Transfer
• Application Call
• State Proof
• Heartbeat

These eight transaction types can be configured in specific ways to produce more distinct functional transaction types. For example, both asset creation and asset destruction use the same underlying AssetConfigTx type, which allows for the creation or deletion of Algorand Standard Assets (ASAs). Distinguishing between these two operations requires examining the specific combination of the AssetConfigTx fields and values that determine whether an asset is being created or destroyed.

Fortunately, the AlgoKit Utils libraries provide intuitive methods to create these more granular transaction types without having to necessarily worry about the underlying structure. However, if you are signing a pre-made transaction, correctly interpreting the underlying structure is critical.

For detailed information about each transaction type, its structure, and how to create and send them using the AlgoKit Utils Library, refer to the Transaction Types page:

Transaction Types Detailed information about transaction types

Transaction Fees

Every transaction on Algorand requires a fee to be included in a block and executed.

When the network is not congested, transactions have a fixed minimum fee of 1000 microAlgo ( 0.001 Algo).

For detailed information about transaction fees on Algorand, refer to the Transaction Fees page:

Transaction Fees Detailed information about transaction fees

Signing Transactions

Before a transaction can be included in the blockchain, it must be signed by either the sender or an authorized rekeyed account. The signed transaction is wrapped in a SignedTxn object that contains both the original transaction and its signature.

There are three types of signatures:

• Single Signatures
• Multisignatures
• Logic Signatures

For detailed information about signing transactions on Algorand, refer to the Signing Transactions page:

Signing Transactions Detailed information about signing transactions

Atomic Transaction Groups

Algorand’s protocol includes a feature called Atomic Transfers, which allows you to group up to 16 transactions for simultaneous execution. These transactions either all succeed or all fail, eliminating the need for complex solutions like hashed timelock contracts used on other blockchains. Any Algorand transaction type can be included in an atomic group for simultaneous execution.

Use Cases

Atomic transfers enable use cases such as:

• Circular Trades - Alice pays Bob if and only if Bob pays Claire if and only if Claire pays Alice.
• Group Payments - Everyone pays or no one pays.
• Decentralized Exchanges - Trade one asset for another without going through a centralized exchange.
• Distributed Payments - Payments to multiple recipients.
• Pooled Transaction Fees - One transaction pays the fees of others. Learn more about fee pooling here.
• Op Up Transactions - Group multiple transactions to cover higher opcode budget

For detailed information about atomic transactions, refer to the Atomic Transaction Groups page:

Atomic Transaction Groups Detailed information about atomic transaction groups

Leases

A lease prevents multiple transactions with the same (Sender, Lease) pair from executing during the same validity period. When a transaction with a lease is confirmed, no other transaction using that same lease can be executed until after the LastValid round.

A lease can be used to prevent replay attacks in Algorand Smart Contracts or to safeguard against unintended duplicate spending. For example, if a user sends a transaction to the network and later realizes their fee was too low, they could send another transaction with a higher fee, but the same lease value. This would ensure that only one of those transactions ends up getting confirmed during the validity period.

For detailed information about the lease field on Algorand, refer to the Lease page:

Lease Detailed information about the lease field

Blocks

Blocks form the foundation of the Algorand blockchain, storing all confirmed transactions and state changes. Each block represents a batch of transactions that advances the ledger from one round to the next, updating the state of the blockchain.

Each block contains:

• Essential metadata like round number and timestamps.
• Transaction data
• Links to previous blocks in the chain

Blocks are added to the chain through Algorand’s Pure Proof of Stake consensus protocol, which is Algorand’s unique proof of stake consensus protocol that ensures security and instant finality through randomness.

For detailed information about blocks on Algorand, refer to the Blocks page:

Blocks Detailed information about blocks

URI Scheme

Algorand’s URI specification provides a standardized format for deeplinks and QR codes, allowing applications and websites to exchange transaction information. The specification is based on Bitcoin’s BIP-0021 to maximize compatibility with existing applications.

For detailed information about the URI scheme on Algorand, refer to the URI Scheme page:

URI Scheme Detailed information about the URI scheme

Transaction Reference

Learn more on the Transaction Reference page:

Transaction Reference Detailed information about the transaction reference