First-Seen-Safe Rule

The first-seen rule, sometimes called first-seen-safe, is the default mempool policy in Bitcoin Core: when a node receives two transactions that spend the same coins, it keeps the one it saw first and refuses to relay or accept the conflicting later one. This policy is the foundation that makes zero-confirmation acceptance even plausible, because honest nodes will not propagate a competing double-spend once they have committed to the original they already hold.

The comforting name does a surprising amount of quiet damage, because the word "safe" invites merchants to treat an unconfirmed payment as settled when the rule itself offers no such promise. It is worth stating plainly: first-seen is a default that some node software chooses to follow, not a property the Bitcoin network guarantees to anyone. Every node is free to run different relay policy, and the one participant whose choice ultimately decides a transaction's fate — the miner who does or does not include it in a block — is under no obligation to have seen your version first at all. Holding both ideas at once, that the rule usually helps and never guarantees, is the entire key to using zero-confirmation acceptance without eventually being burned by it.

A policy, not a consensus rule

It is essential to understand that first-seen is a node-relay policy, not a Bitcoin consensus rule. Nothing in the protocol forces a miner to honor the order in which transactions happened to arrive. A miner is free to mine whichever conflicting transaction pays more, and Replace-by-Fee deliberately relaxes first-seen so that flagged transactions can be superseded by higher-fee versions — a feature, not an attack, that lets a stuck payment be bumped out of congestion. Different nodes can also legitimately see different transactions first simply because of propagation timing across the network's topology, so there is no single global "first" that everyone agrees on.

Why the network defaults to it

First-seen exists mostly to protect the network from denial-of-service, not to guarantee payments. Without it, an attacker could flood the network with endless streams of conflicting versions of a transaction, forcing every node to churn through re-validating and re-relaying spends that will never confirm. By committing to the first version it sees and ignoring later conflicts, a node bounds that work. The zero-confirmation "safety" that merchants sometimes lean on is really a side effect of this anti-spam behaviour, not a designed guarantee — a distinction that matters enormously the moment real value is at stake.

Implications for security

Because the rule is voluntary, the safety of an unconfirmed payment rests entirely on an assumption: that most relaying nodes and, crucially, the next miner will behave honestly and stick with what they saw first. That assumption is reasonable for low-value, in-person sales where an attacker has little to gain and the merchant can watch the network — a coffee, a face-to-face trade. It is a poor assumption for anything material, anything remote, or anything where the counterparty controls their own node and could broadcast a conflicting spend directly to a miner, bypassing the honest relay path entirely.

The practical takeaway

Treat first-seen as a courtesy the network extends, not a lock it enforces. For meaningful value, waiting for confirmations is the only guarantee that does not depend on strangers' cooperation, because a confirmed transaction is buried under proof-of-work that an attacker would have to out-mine to reverse. The number of confirmations you require should scale with the amount at stake and with how much you trust the person across the table. First-seen explains why an unconfirmed payment usually goes through, but it never explains why one is guaranteed to. See our related entries on the zero-confirmation transaction and double-spend relay policy for the behaviour that sits on top of this rule.