One Full Algorand Block Holds About a Ninth as Many Post-Quantum Payments

On the morning of October 21, 2026, block 66,188,273¹² came within a rounding error of Algorand's block limit. Its header recorded a Load of 999,461³, where 1,000,000 means a completely full block. Load is a protocol field: the share of a block's 5,242,880⁴-byte transaction budget that it has spent. This one used all but a sliver of it. It held 1,590 transactions⁵, 1,565⁶ of them carrying a Falcon signature.

A Falcon account is a new kind of Algorand account, made to authorize payments with a post-quantum key instead of the classical one nearly all traffic still uses. A payment from one costs more than the protocol's minimum fee, Algorand's fee guidance says, because the type of signature now matters. What that difference costs in room inside a block is the question here, and one morning's blocks answer it.

At the roughly 3,340 bytes one of those payments occupies, the budget holds about 1,569⁷ of them. Algorand has recently kept block times near 2.76 seconds, which turns that budget into some 568 payments a second. An ordinary payment, at about 355⁸ bytes, would fit about 14,770 to the block, roughly 5,300 a second.

Three near-full blocks, and the quiet ones after

PXke bought badge-farming orders from AlgoRoll's Quantum NFT Farm⁹ for this test, including a 200¹⁰ ALGO order, and AlgoRoll shared its report on that order; the transactions those orders made are now part of the post-quantum count Algorand cites.

Two other blocks that morning came nearly as close, both dominated by Falcon signatures. One filled 98.7 percent of the cap; the other¹¹, 98.9.

The block after the full one read 155,360 on the same scale, about 16 percent; the one after that¹², 1,151. Other blocks from the same morning sat in the low thousands on that scale. Whether a sender could hold a full-block pace across several consecutive blocks is unknown, and on this morning the traffic fell away at once.

The pace was the sender's. Two 20 ALGO orders had reached the same farm wallet earlier, and seven seconds after the 200¹³ ALGO arrived the farm sent 159 ALGO on to the account that pays out Pera's badges. Around that, the rewards app behind those badges made small claim payments all morning, an inner payment of 0.1 ALGO leaving its account each time 0.1 ALGO came in.¹⁴

Where the bytes go

A Falcon-1024 public key alone runs to nearly two kilobytes, and the signature adds about 1,280 bytes more, all of it charged to the block. An Ed25519 key and its signature together come to under a hundred bytes. Algorand's roadmap table¹⁵ gives the same signature size. The key travels with every transaction because the address is a hash of the key rather than the key itself, so the signer presents the key at spend time. That extra material rides in every payment, and it is why a block filled with Falcon payments holds roughly a ninth as many as one filled with ordinary ones.

Falcon also cannot be batch verified. Algorand's protocol engineers¹⁶ state it plainly: Ed25519 signatures can be checked in aggregate, and no such trick is known for Falcon, so every signature is verified on its own. A thousand of them cannot be folded into one cheaper check.

Algorand has priced the space rather than hidden it. According to Algorand's protocol engineers, a post-quantum authorization adds 2,000,000¹⁷ of usage to an ordinary transaction's 1,000,000¹⁸, so it pays three minimum fees instead of one. The v5.0.0 explainer¹⁹²⁰ says quantum-resilient signatures 'take up significantly more space in a block, and that added block space is what the extra fee accounts for²¹'. The developer guidance²² is that the minimum fee is no longer enough for normal-size transactions 'because the type of signature now matters²³'.

The 3,340²⁴-byte figure is inferred rather than read off one transaction. It follows from block fullness, the two-extra-minimum-fee surcharge and a 355²⁵-byte ordinary baseline, and it agrees within a few bytes across three full blocks.

What the throughput figures assumed

Algorand's headline numbers were arithmetic on much smaller transactions. The 2022 article announcing the 5 MiB block²⁶²⁷ said it would allow roughly 26,000²⁸ transactions per block at peak, or 6,000 a second, and named 10,000 a second as a goal. Fitting 26,000²⁹ into 5,242,880³⁰ bytes implies about 202 bytes each; at 3,340 bytes the same block holds roughly a seventeenth as many.

A July 2026 post still described a network built to handle up to 10,000 transactions per second³¹³². At Algorand's roughly 2.8³³-second block time, 10,000 a second would need a block averaging under 200 bytes a transaction, below the 355³⁴ bytes an ordinary payment measures now.

The Foundation has been candid about the tension. Its Falcon explainer³⁵ says larger keys 'could make running a node less accessible if the block size is increased... or could reduce performance (TPS) if the block size is preserved'. On the blocks, each Falcon payment takes about nine times the room.

What it changes for a holder

Little, today, because Falcon accounts are optional and still rare. The Foundation counted³⁶ 1,800³⁷ quantum-resilient accounts and 1.24 million³⁸ quantum-resilient transactions between August 20 and September 7, against 32.9 million³⁹ transactions on the network in August. That is about 690 transactions per quantum account over nineteen days, which reads as a small number of busy accounts rather than a broad migration. How that count is assembled, and the printers behind it, is set out in our earlier article on the count.

What has not been published

No published Algorand document sets out a plan to raise the 5,242,880⁴⁰-byte cap, or a throughput figure for a network dominated by Falcon traffic. The cap itself, the protocol's own limit on how many bytes of transactions a block may carry, has stayed put in the consensus parameters from version 33 through the future version, according to the protocol's source code. Whether it rises, or whether Falcon aggregation ever makes it unnecessary, is unknown.