Kaspa Mempool Expiry: What Happens to Unmined Transactions

A transaction that leaves your wallet is not a payment yet. It is a proposal: a signed message saying "spend these UTXOs, produce these new ones." Somewhere between that proposal and a confirmed payment sits a staging area every full node maintains — the mempool — and the mempool has its own rules about what it keeps, what it gossips, and what it quietly throws away.

Most "my transaction is stuck" reports on Kaspa are really mempool stories. The rules behind them are simple and, once you see them, quite predictable.

The problem: broadcast is not delivery

Two assumptions cause most of the confusion:

• "I sent it, so every node has it." In reality, propagation is gossip: nodes announce transaction hashes to their peers and serve the full data on request. Not every node holds your transaction, and none of them owe it a permanent place.
• "If it's in the mempool, it will get mined eventually." Miners choose transactions by policy — in practice the highest-paying ones first. Nothing in consensus obliges anyone to include your transaction at all.

So there must be a garbage collection rule, and Kaspa has one.

How the mechanism works, step by step

1. Entry. A transaction reaches a node in one of two ways: over RPC, submitted by a wallet or an application talking to its own node, or over the P2P network, relayed by a peer. This distinction matters more than any other detail here.

2. Admission. The node checks the transaction against its current view of the UTXO set and its own policy — including a minimum fee threshold. That threshold exists to stop spam, and it is configurable per node (the node software exposes it as a command-line setting).

3. Gossip. Once accepted, the node announces the transaction hash to its active peers, just as it announces block hashes. The transport is TCP-based, and peers are maintained continuously by the connection manager. Full transaction bodies follow on request, which keeps gossip cheap.

4. Waiting. The transaction sits in the mempool until a miner picks it up. Selection is economic: when a block has room, the miner takes the top-paying transactions that fit. Clearing the relay minimum only gets you *into* the queue, not *out* of it.

5. Inclusion or eviction. Either the transaction is included in a block and merged into the DAG — at which point it is out of the mempool's hands and into consensus — or it isn't, and the expiry clock runs.

6. Expiry. A transaction that arrived from a peer and has not been included after 60 blocks is dropped from the mempool. A transaction that was submitted over RPC never expires; the node rebroadcasts it from time to time, and the only way to remove it is to restart the node.

A sketch of the two paths:

signed tx
  ├─ path A: submitted via RPC (own wallet / app)
  │     -> mempool entry, node rebroadcasts periodically
  │     -> no expiry; cleared only by node restart
  │
  └─ path B: relayed from a peer (P2P)
        -> mempool entry
        -> if not included within 60 blocks -> dropped

Note that 60 blocks is counted in blocks, not wall-clock minutes. That is deliberate: the protocol's clock is blocks and DAA score, not a timestamp, so the retention rule does not drift when block rate changes.

7. Fees are policy, not consensus. This is the second part of the puzzle. Nodes reject low-fee transactions from their mempools, but they accept such transactions without complaint if they arrive inside a block. A miner who chooses to mine zero-fee transactions is not breaking anything — in theory it is possible, and the network will not fork over it. The practical consequence: a fee that one node refuses to relay may still confirm if a miner takes it, and a fee hike that most users adopt will work without a network split.

What this means in practice

Three operational takeaways fall out of the rules.

A vanishing transaction is not a lost payment. Until a transaction is included and merged, the coins it spends are still unspent UTXOs. Dropping it from a mempool moves nothing. The fix is mechanical: rebroadcast it, or rebuild it with a fee nodes will relay.

Tools that submit over RPC get an immortal entry. That is convenient for a wallet retrying on your behalf and inconvenient for anything that wants a clean slate — which is why node restarts show up so often in operational runbooks.

Confirmation is the only state that counts. Mempool presence is a hint about the future. Inclusion in a block, followed by the DAG's ordering of that block, is the event that changes the ledger. Everything downstream — balances, contract states, deal outcomes — should be read from the UTXO set and block data, never from "my node still lists it."

How Kaspa Forge builds on top of this

The short version of our design: we treat the mempool as a transport, and the chain as the truth.

Transactions are built and signed on the user's device — Desk keeps keys in an encrypted browser profile and never moves them anywhere — and broadcast to a node like any other transaction. What follows is a waiting-and-watching discipline rather than an assumption of delivery. Our products monitor UTXO state and block data, so a dropped or rebroadcast transaction is handled as a retry, not as a bug.

The on-chain contracts are where this pays off. Kaspa Safe is a covenant vault whose withdrawal delay, alarm key and inheritance paths are enforced by the contract's own spending rules, not by mempool patience. Kaspa Escrow holds deal funds in a contract with explicit claim, refund and dispute paths. Deposit locks collateral the same way. In all three, "who can spend what, and when" is decided by the covenant when a transaction is evaluated against the UTXO being spent — the mempool only ever decides *whether the request travels*.

The same logic applies to the more social surfaces. Boards posts and tips are anchored on the BlockDAG, and the index can be rebuilt from chain data; the Marketplace never holds a buyer's funds, it hands the two sides into a separate escrow deal. In Arena, the mainnet-beta blackjack table keeps money in Room/Game UTXOs and the player signs locally, so a round's outcome is a chain event, not a message in someone's queue. Even our payment flows follow the same principle: watch for the output to appear, then read confirmations from the DAG rather than from a mempool listing.

Trade-offs and honest boundaries

The design is not free of costs, and it is worth naming them.

• Per-node policy is genuinely per-node. Two nodes can disagree about your transaction's fee adequacy and hold different mempools. That is not a malfunction; it is the price of keeping relay policy out of consensus.
• Expiry can surprise integrators. A peer-relayed transaction that vanishes after 60 blocks will make naive "send and forget" logic report success and then deliver nothing. Anything serious needs its own retry and monitoring loop.
• Immortal RPC entries have an operational cost. "Restart the node to clear it" is a blunt instrument. It is harmless to the ledger — mempool state is disposable — but it means node operations should plan for it.
• A fee is not a guarantee. Paying the minimum gets you relayed; paying more improves your odds. Only inclusion decides.
• Covenants do not bypass any of this. Contract-carrying transactions are ordinary transactions with respect to relay, expiry and miner selection. Their logic — spending paths, fee budgets, keyless branches — executes at validation time, which is exactly why contracts can be trusted while mempools cannot.

On the product side, the status line is worth repeating plainly: Arena Blackjack is a public mainnet beta of a verifiable game; Dice is engineering work with its permanent production arm off pending independent review; Permissionless Tokens, duel and baccarat are planned ideas, not live services. Nothing here should be read as an invitation to those. Everything linked above is live today: Safe, Escrow, Deposit, Marketplace, Desk, Boards and the Arena beta.

One footnote on sourcing: the concrete numbers in this article — the 60-block expiry, the RPC no-expiry rule, the relay-fee-versus-consensus distinction — come from the public protocol documentation, and the historical 0.0001 KAS-per-UTXO fee figure is dated May 2022. For the full picture of node behaviour, transaction handling and the surrounding terminology, the Kaspa wiki is the reference of record.