Standardness

Standardness is the set of relay-policy checks a transaction must pass for a Bitcoin Core node to accept it into the mempool and forward it to peers. These rules are deliberately stricter than the consensus rules that govern whether a transaction is valid in a mined block. A transaction can be perfectly valid by consensus yet "non-standard," meaning ordinary nodes will neither relay it nor mine it from their own mempool — though a miner who receives it out of band may still include it in a block, and the network will accept that block without complaint.

What the rules check

Standardness covers many conditions: recognized script templates (P2PKH, P2SH, P2WPKH, P2WSH, P2TR, and bounded bare multisig), a maximum standard transaction weight, the dust limit on outputs, the sigops ceiling, limits on OP_RETURN data outputs (historically a single output capped in size), and minimum-fee thresholds. Transactions using unknown scriptPubKey forms, non-canonical encodings, or oversized scripts are rejected as non-standard. The theme across all of them is resource defense: each rule caps some way a transaction could consume disproportionate validation time, memory, or permanent UTXO-set space relative to the fee it pays.

Why policy and consensus differ

Keeping policy stricter than consensus lets node operators defend against denial-of-service and UTXO-bloat vectors without requiring a soft fork or risking a chain split. Consensus rules are nearly immovable — loosening one is a hard fork, and even tightening one requires network-wide coordination — while policy is just a default in software that each operator can adjust. This asymmetry is also how new transaction types are deployed safely: outputs to not-yet-defined witness versions were non-standard before Taproot activated, which kept users from sending to them prematurely, and became standard once the rules were live. Policy acts as a buffer where the network can be conservative without freezing.

The gap between policy and consensus

Because standardness is local policy, it is not a guarantee about what gets mined. Miners and large pools can accept non-standard transactions submitted to them directly, and periodically do — which is a useful reminder that policy shapes the default path to a block, not the only path. This gap has real consequences: fee-bumping behavior, pinning attacks, and debates about relay of various data-carrying transactions all live in it. For wallet authors the practical rule is simple: build only standard transactions, or accept that confirmation depends on a side door. For node runners, policy knobs exist but loosening them mostly volunteers your node's resources.

Why it matters for sovereignty

There is a practical tool for exactly this boundary: Bitcoin Core's testmempoolaccept RPC evaluates a raw transaction against the node's full policy — standardness included — and reports precisely why it fails, without broadcasting anything. For anyone building wallet software, coordinating multisig, or hand-crafting transactions, running candidates through your own node's policy check first is basic hygiene: it converts a mysterious "transaction not relayed" into a named rule you can fix, and it exercises the very reason to run a node — asking your own validator, not a stranger's, what the network will accept. The same check is worth running when experimenting with unusual script types, timelocks, or large batch payments, all of which brush against policy edges long before they brush against consensus.

Standardness is where individual node operators exercise judgment collectively: thousands of independently run nodes enforcing sane defaults is what makes the relay network hard to spam and expensive to abuse. Running a policy-enforcing node is thus a small act of network defense. See Mempool Policy for the broader framework, Ancestor and Descendant Limits for how chains of unconfirmed transactions are bounded, and Replace-by-Fee for the replacement rules layered on top.