20. Mempool

The Mempool (Memory Pool) is the high-performance transaction staging and ordering engine within kortanad. It buffers, authenticates, and prioritizes pending transactions before they are selected by block proposers.

20.1 Fee-Priority Ordering

Transactions residing in the Kortana mempool are organized in a multi-index priority queue designed to maximize validator fee revenue while giving users deterministic control over execution latency.

The queue is ordered primarily by the transaction's declared EIP-1559 priority fee (max_priority_fee_per_gas), representing the direct tip paid to the block proposer. If two competing transactions declare identical priority tips, the queue breaks ties by evaluating max_fee_per_gas (the maximum total fee cap) and arrival timestamp. When a leader node is scheduled to construct a block, the block builder extracts transactions from the top of the priority queue, ensuring that the highest-bidding transactions receive priority block inclusion.

20.2 Nonce Ordering

For any individual sender address, the mempool enforces absolute, unbroken Nonce Sequentiality. Transactions from the same account must execute in strict numerical order (0, 1, 2, ...) to prevent replay attacks and state desynchronization.

If an account submits a transaction with nonce 10 when its on-chain state nonce is 8, the mempool places nonce 10 into a dedicated "future/orphaned" pool. The transaction is retained in memory but marked as non-schedulable. The moment transactions for nonce 8 and nonce 9 are submitted and validated, nonce 10 is automatically promoted to the "ready" pool and becomes eligible for immediate block inclusion.

20.3 Authenticated Senders

To prevent denial-of-service attacks involving invalid signatures or forged sender identities, the mempool authenticates every transaction upon entry.

As soon as a raw transaction is deserialized, the node performs cryptographic signature recovery: secp256k1 ECDSA recovery (ecrecover) for standard Ethereum transactions or Ed25519 signature verification for native ktn: addresses. The recovered 20-byte sender address is stored directly within an immutable SenderContext structure attached to the transaction. This guarantees that expensive elliptic curve arithmetic is executed exactly once during transaction ingestion and cached for the remainder of the block assembly pipeline.

20.4 Admission Rules

Before any transaction is admitted into the mempool, it must pass a battery of strict, non-negotiable admission filters codified in mempool.cpp:

1. Cryptographic Validation: The signature must be authentic, valid, and strictly adhere to EIP-2 low-S malleability constraints (s <= secp256k1_n / 2).
2. Payload Size Limit: The serialized transaction length must not exceed 128 KiB (131,072 bytes).
3. Economic Floor: The declared max_fee_per_gas or legacy gasPrice must equal or exceed the network minimum gas price of 1 gwei (1,000,000,000 wei).
4. Balance Solvency: The sender's current liquid DNR balance in the state trie must satisfy balance >= (gas_limit * max_fee) + value.
5. Nonce Bounds: The transaction nonce must be greater than or equal to the account's committed on-chain nonce and within the allowable forward nonce window (maximum 64 pending nonces per sender).

20.5 Replacement Bump

When an account wishes to speed up or cancel a pending transaction by submitting a replacement transaction with the same nonce, the mempool enforces a mandatory Replacement Fee Bump to prevent mempool spam.

Under the replacement rule, the new transaction must specify a max_priority_fee_per_gas and a max_fee_per_gas that are both at least 10% higher (1000 basis points) than the existing pending transaction. Any replacement transaction that attempts to replace an existing pending transaction with a marginal or zero fee increase is rejected immediately with ErrorCode::ReplacementUnderpriced.

20.6 Eviction

To protect the host operating system against memory exhaustion, the mempool enforces strict memory and entry capacity limits (configured by default to 64,000 transactions or 256 MB of heap allocation).

When the mempool reaches capacity and a new valid transaction arrives, the eviction engine activates. The engine scans the lowest-fee transactions across all senders and identifies the transaction offering the lowest effective priority tip. If the newly arrived transaction offers a higher tip than the lowest-ranked transaction, the lowest transaction is evicted and dropped, ensuring that higher-value network traffic is never starved by pool saturation.

20.7 Deterministic Selection

Block proposals in Kortana are constructed through a deterministic, reproducible transaction selection algorithm executed by the scheduled leader node.

The block builder queries the mempool's "ready" queue, drawing transactions in strict fee-priority order while maintaining per-account nonce continuity. As each transaction is selected, its declared gas_limit is accumulated against the block ceiling of 30,000,000 gas. If a candidate transaction exceeds the remaining block gas space, the builder skips it and tests subsequent smaller transactions until the block is packed to maximum capacity or the mempool is exhausted.

---