We refreshed our doc site!
Bookmarked links may have changed
Read release notesIn this guide, you’ll learn about the transaction limits imposed by supported blockchains and programmable wallets (PW). You’ll also get client-side optimization tips to ensure smooth transaction processing within your applications.
EVM-compatible blockchains typically use a Mempool system. The Mempool queues transactions sent from a wallet up to a certain limit defined by the full node. If you exceed this limit, you receive an error from the full node. All queued transactions in the Mempool can potentially be included in a single block. Therefore, you can estimate the theoretical transaction throughput as queueLimit
/ blockTime
. However, various factors can influence whether your transaction gets included in a block, such as priority fees, network congestion, and network liveness. In contrast, the Solana blockchain does not use a Mempool system and, thus, does not have a queue limit. This contributes to its transaction throughput being significantly higher.
Blockchain | EOA wallet | SCA wallet |
---|---|---|
Ethereum | 32 transactions | 1 transaction |
Polygon | 16 transactions | 1 transaction |
Avax | 32 transactions | 1 transaction |
Solana (no Mempool) | Unlimited | Currently not supported by PW |
The overall transaction throughput is fundamentally constrained by the blockchain account queue limit and the blockchain's inherent throughput. To mitigate the impact of these limitations, programmable wallets provide a queuing mechanism for transactions that exceed the blockchain limit for a certain duration. There is a limit on the number of transactions your wallet can queue in the programmable wallet service to prevent resource wastage and false expectations. This limit affects the user experience when too many transaction requests are made. When you reach this limit, you receive an error message:
"Wait for pending transactions to be included on the blockchain before submitting new requests. EVM chains restrict the number of queued transactions per sender address." (Error code 155264)
More detailed error descriptions and suggestions can be found in the Transaction error codes section.
To check the number of pending transactions and their status, use the listTransaction
API endpoint. The transaction state should be one of the following: INITIATED
, PENDING_RISK_SCREENING
, QUEUED
, SENT
.
While transaction queuing provides a convenient feature, fee fluctuations and network congestion can still impact transaction processing times. Below are some tips to ensure a smooth experience, especially when dealing with a high volume of transaction requests.
Consider setting the fee_level
parameter to at least MEDIUM or HIGH. This ensures that your transactions are processed with higher priority in a reasonable timeframe, reducing delays for subsequent transactions.
Using multiple sender wallets can help bypass the per-wallet queue limit and increase the level of parallel processing. This strategy is generally effective across various blockchains.
Leveraging smart contracts for batch transactions can significantly reduce the number of transactions needed for repetitive tasks. For instance, instead of sending 1,000,000 transfer transactions individually, you can deploy an airdrop contract that processes transfers to 500 wallets in a single execution call, requiring only 2,000 transactions in total. Although a single contract execution call may incur higher gas costs than a simple transfer, it is often more gas and time-efficient for batch transactions.
For more details, please refer to our Airdrop template on the smart contract platform .
By understanding the transaction queue limits and exploiting the above optimization tips, you can improve the transaction throughput of your applications, thereby increasing their overall efficiency when interacting with blockchain networks.