Parameters - Algorand Specifications

Algorand Specifications

In the context of this section, the phrase “giving up” refers to finalizing the current block under assembly; this includes completing the payset and calculating all associated metadata that depends on it.

This section presents a list of some relevant parameters that govern the behavior of the TxPool.

In the case that there are leftover transactions in the TxPool, the TxPool saves them for the next block assembly.

A consensus parameter that defines the maximum number of transactions the transaction pool queue can hold. When this limit is reached, any new incoming transactions, even if valid, are not enqueued and are instead dropped.

Important
IMPLEMENTATION:
In the go-algorand reference implementation, this limit is set to 75,000 transactions.

This dynamic parameter is updated each time a new block is observed. Under normal conditions, when the TxPool is not congested, its value is 0. However, if the queues become congested, this parameter increases. As it grows, it raises the minimum fee threshold required for transactions to be accepted into the TxPool.

For more details, see the update and fee prioritization sections.

A consensus parameter, denoted as TxPoolExponentialIncreaseFactor, which determines how sharply the required transaction fee increases based on the number of full blocks pending (an indicator of TxPool congestion). This factor amplifies the fee threshold in congested conditions. The default value in go-algorand consensus parameters is currently set to 22.

A dynamically computed parameter that defines the current minimum number of μALGO per byte that a transaction must pay to be accepted into the TxPool. When the TxPool is not heavily congested, this parameter remains well below the minTxnFee, meaning the base fee requirement still controls the admission threshold. Under normal conditions (no congestion), this value is set to 0.

A consensus parameter that sets a strict deadline for the BlockAssembly process to stop constructing a payset. This ensures block assembly completes within the required time frame.

Important
IMPLEMENTATION:
In the go-algorand reference implementation, δassemblyDeadline=ProposalAssemblyTime=0.5 seconds.

An additional time buffer that the BlockAssembly algorithm waits after the official deadline before “giving up”. This grace period allows slightly delayed transactions to be included if possible.

Important
IMPLEMENTATION:
In the go-algorand reference implementation, ϵassemblyWait=150 milliseconds.

A multiplier that determines how many rounds of historical data on expired transactions are retained. Specifically, the node keeps (expiredHistory×maxTxnLife) rounds of history. Maintaining this history helps dynamically adjust transaction prioritization based on fee structures, as it provides insight into network congestion (e.g., if many transactions are expiring without being included in a block).

Important
IMPLEMENTATION:
In the go-algorand reference implementation, expiredHistory is set to 10, therefore, the node keeps 10×1000=10,000 rounds of history.

A time constant that defines how long the system should wait when processing a new block that appears to be committed to the Ledger. This timeout is used within the Ingestion function to ensure timely handling of new blocks.

Important
IMPLEMENTATION:
In the go-algorand reference implementation, this limit is set to 1 second.

The following two time constants are used to estimate how long it would take to properly complete a block after the system has “given up” on assembling the payset.

These estimates work together with δassemblyDeadline and ϵassemblyWait to ensure that block finalization occurs within the required timeframe for proposal generation.