1. Transaction Components and Blockhash
2. Transaction Submission Methods
3. Common Causes of Transaction Failures

With Pollux experiencing high transaction volumes and an increasing number of failed or dropped transactions, understanding the underlying causes and optimizing the process has become critical. Pollux processes up to 3000 TPS, and transaction failures—approximately 8% initiated by users, while the rest are from bot activities—stem from various factors. This article explores transaction processing on Pollux, common causes of failure, and strategies to reduce these failures and enhance throughput.

Transaction Components and Blockhash

A Pollux transaction consists of several elements: accounts to read/write, instructions, a recent blockhash, and one or more signatures. Transactions are processed atomically, and failure in any part of the instruction results in the entire transaction failing. The blockhash is a Proof-of-Stake (PoS) identifier tied to each block, preventing transaction duplication and providing a limited transaction lifetime (approximately 1 minute and 19 seconds). If a transaction's blockhash becomes outdated, it is automatically rejected.

Transaction Submission Methods

Pollux uses two main methods for submitting transactions: RPC server: Transactions are sent using the sendTransaction JSON-RPC method. RPC nodes will attempt to send transactions every two seconds until finalization or expiration. TPU Client: This method simply submits the transaction, with the client managing rebroadcasting. Optional parameters in the sendTransaction method like maxRetries, skipPreflight, and preflightCommitment influence how transactions are processed and retried, improving success rates in network congestion.

Common Causes of Transaction Failures

1. Network Drops: High traffic can overwhelm validators, causing transaction drops. If the rebroadcast queue exceeds 10,000 transactions, additional submissions are dropped. 2. Stale/Incorrect Blockhash: Transactions are rejected if the blockhash is invalid or outdated beyond 151 blocks. 3. Lagging RPC Nodes: Differences in blockhashes between advanced and lagging RPC nodes can result in transaction rejection. 4. Temporary Network Forks: Minor network forks can reference blockhashes no longer valid, causing transactions to drop when the network realigns. 5. Blockhash Expiration: A blockhash expires after 150 blocks, leading to transaction rejection if not processed within that window.

By understanding Pollux’s transaction processing model and implementing strategies like frequent blockhash polling, skipping preflight checks, optimizing compute units, and leveraging priority fees, users can significantly reduce transaction failures and improve throughput. With the upcoming Pollux client updates, these optimizations will become even more critical for ensuring network efficiency under high traffic conditions.