Transaction Pool

Origin: composes, "mempool" is Bitcoin-era terminology for a decades-older pattern; the specific DAG design Solidus is building toward comes from a 2021 academic paper. Solidus status: shipped: a simple pool is live on the public testnet; a more advanced DAG-based pool runs on a separate, single-box public devnet.

A transaction pool, often shortened to "mempool", is the holding area for transactions a node has received and checked but that haven't made it into a block yet. Every full node keeps its own copy: when a wallet or app submits a transaction, it lands in the pool first, gets validated (correct signature, sufficient balance, right nonce), and waits there until whichever validator is proposing the next block picks it up and includes it. A transaction pool matters for two reasons: it decouples "receiving a transaction" from "finalizing a transaction" (a node can validate immediately without waiting for consensus), and its design affects how fair, fast, and resistant to censorship or spam a network is. A naive first-in-first-out queue is simple but easy to game; more sophisticated designs try to make it harder for any single leader to selectively exclude or reorder transactions.

Where it comes from

The term traces to Bitcoin's early client software, where "memory pool" described exactly this holding area. Solidus's more advanced design borrows from newer academic work: "Narwhal and Tusk," published in 2021 by George Danezis, Eleftherios Kokoris Kogias, Alberto Sonnino, and Alexander Spiegelman, proposed splitting mempool work into "workers" (which batch and disseminate transaction data) and a "primary" (which only orders small certificates referencing those batches, not the transactions themselves), a structure that lets transaction throughput scale mostly independently of consensus throughput. Solidus did not design this scheme; a from-scratch Rust crate adapts it.

Two pools, two networks, don't blur them

This is the point where precision matters most. The public testnet at rpc.solidus.network, four validators, team-run, live since the network's earliest testnet milestone, runs the simple version: an in-memory VecDeque, first-in-first-out, deduplicated by transaction hash, capped at 10,000 pending transactions. That's real, running code, and it's what has processed every transaction the testnet has ever committed.

Separately, a newer consensus engine wires in the Narwhal-style DAG mempool, worker/primary split, BLS-signed availability certificates so the primary only needs to order small certificates rather than full transaction batches, and that engine is genuinely live, not just benchmarked, on a public single-box devnet at devnet-v2.solidus.network (chain-id 50002). "Public" and "live" are true; "geographically distributed" or "production-scale" are not, all four of that devnet's validators run co-located on one server, and it has not been tested against real network latency between independent operators.

Check it yourself

Pool contents aren't exposed as a public RPC query on either network, so there's no live pending-transaction count to pull. Both implementations are visible in source, in the public solidusnetwork/protocol repository, the FIFO pool in solidus-consensus::mempool, the DAG-based one in the standalone solidus-mempool-dag crate.

Related terms: Nonce · Fork Choice · HotStuff · State Root · libp2p