Policy vs Consensus Rules

Policy vs consensus rules describes the two distinct layers of rules Bitcoin enforces, and conflating them is one of the most common sources of confusion in protocol debates. Consensus rules determine whether a block and its transactions are valid for the entire network. Policy rules — also called standardness or relay policy — are local preferences each node applies when deciding which unconfirmed transactions to accept into its mempool and relay to peers. The difference is fundamental: breaking a consensus rule forks you off the network, while differing on policy does not. A transaction can be perfectly valid by consensus yet refused by most mempools, and a transaction every mempool loves is still worthless if it violates consensus.

Consensus Rules: Mandatory and Global

Consensus rules are non-negotiable. Signatures must be valid, inputs must exist in the UTXO set and not be double-spent, outputs cannot exceed inputs, the coinbase subsidy schedule must be respected, and the block must fit within the 4-million weight unit ceiling. Every full node checks these independently against its own copy of the chain, and any block that violates them is rejected by everyone, no matter how much hashrate mined it. That universality is the point: consensus rules are what make a bitcoin a bitcoin. Changing one is exactly what a soft fork or hard fork does, which is why such changes require careful, ecosystem-wide activation via mechanisms like a miner-activated or user-activated soft fork rather than a software update pushed on a Tuesday.

Policy Rules: Local and Adjustable

Policy rules are stricter filters a node applies before consensus even comes into play, and they govern only what the node will hold and relay. Bitcoin Core ships defaults such as a minimum relay feerate, a dust threshold below which outputs are considered uneconomical, limits on transaction size and signature-operation counts, standardness requirements on script templates, and caps on unconfirmed transaction chains. None of these are consensus. If a miner includes a "non-standard" transaction in a block anyway, the very same node that refused to relay it accepts the block without complaint, because no consensus rule was broken. Operators can tune their own policy freely — raise or lower relay fees, accept larger OP_RETURN payloads, filter what they consider spam — and doing so never risks a chain split. That safety valve is precisely why the loudest filtering debates play out at the policy layer.

Why the Distinction Matters to Miners

Miners live at the boundary between the two layers. Block templates are normally assembled from the local mempool, so policy shapes which fee-paying transactions a miner ever sees; a node with unusual policy may miss revenue or, conversely, capture fees its competitors filtered out. Direct-submission services that bypass public relay exist for exactly this reason. Protocols like Stratum V2 push template construction to the individual miner, which makes each operator's policy choices — not just the pool's — part of what actually gets confirmed. Meanwhile fee estimation, which every miner and user relies on, is built entirely on mempool observation, so policy differences between nodes explain why two well-connected nodes can disagree about the "going rate."

The Sovereignty Angle

Running your own node means you choose your own policy, and nobody can choose it for you. You decide what your machine stores, relays, and ignores — that is local sovereignty working exactly as designed. What you cannot do unilaterally is change consensus, and that is equally by design: the hard limits protect every participant from every other participant, including miners and developers. Understanding this split clarifies why mempools differ between nodes yet the blockchain stays unified, and why "my node won't relay it" and "the network won't accept it" are two very different statements. When you hear a proposal debated, the first question to ask is always the same: is this policy, or is this consensus?