# Relay policy and standardness

Nodes apply extra rules about which transactions they relay and keep in their mempool. Learn how policy differs from consensus and why it matters.

Canonical page: https://mybitcoinexplorer.com/learn/relay-policy-and-standardness
Topic: Nodes and the network
Published: 2026-10-29
Updated: 2026-10-30


## A second layer of rules
> Diagram: A transaction passes consensus checks, then the node's own policy, before it's relayed — New transaction → Consensus: valid? → Policy: standard? → *Relay: and keep in mempool

On top of [Consensus rules](https://mybitcoinexplorer.com/learn/consensus-rules), each node applies **policy**: its own choices about what to relay and keep in its [mempool](https://mybitcoinexplorer.com/learn/what-is-the-mempool). Policy protects nodes from spam and denial-of-service, and makes upgrades safer.

| Common policy | Purpose |
|---|---|
| Minimum relay fee rate | Avoid relaying free spam |
| [Dust limit](https://mybitcoinexplorer.com/learn/dust-and-consolidation) | Avoid creating uneconomical outputs |
| Standard script types only | Keep unusual scripts out until they're reviewed |
| Maximum standard transaction size | Limit expensive validation |
| Replacement rules | Govern [Replace-by-fee (RBF)](https://mybitcoinexplorer.com/learn/replace-by-fee-rbf) |
| OP_RETURN data limits | Limit data relay (see [OP_RETURN data outputs](https://mybitcoinexplorer.com/learn/op-return)) |

## Non-standard but valid
A transaction that breaks policy is "non-standard". Most nodes won't relay it, but if a miner includes it in a block, every node still accepts the block, because consensus rules allow it.

## Why policy helps upgrades
Unknown future script versions are non-standard to spend today. That stops people accidentally using new features before a [soft fork](https://mybitcoinexplorer.com/learn/soft-forks-and-hard-forks) defines their rules.

## Policy changes
Policy can change between software versions without a fork. For example, recent Bitcoin Core versions lowered the default minimum relay fee rate and relaxed OP_RETURN limits. Different node operators may run different settings.


## Policy vs consensus at a glance
| | Consensus | Policy |
|---|---|---|
| Decides | What is valid in a block | What a node relays and keeps |
| Changed by | Soft forks | Node settings and releases |
| Different between nodes? | Must not be | Can be |
| Breaking it means | Block rejected by everyone | Transaction not relayed by some nodes |

## Getting a non-standard transaction mined
Some mining pools accept transactions submitted directly to them, outside normal relay. That's how valid but non-standard transactions still end up in blocks.


## Key takeaways

- Policy decides what a node relays; consensus decides what's valid.
- Non-standard transactions can still be valid in blocks.
- Policy changes don't need a fork.

## Common questions

### Why won't my transaction propagate?

It may break a node policy, such as a fee rate below the minimum, dust outputs, or an unusual script.

### Can I change my node's policy?

Yes, many policy settings are configurable in Bitcoin Core.

### What makes a transaction non-standard?

Things like unusual script types, outputs below the dust limit, oversized data or fee rates below the minimum relay rate.

### Is a non-standard transaction invalid?

No. It's valid if a miner includes it; most nodes just won't relay it.

## Related lessons

- [Consensus rules](https://mybitcoinexplorer.com/learn/consensus-rules)
- [What is the Bitcoin mempool?](https://mybitcoinexplorer.com/learn/what-is-the-mempool)
- [OP_RETURN data outputs](https://mybitcoinexplorer.com/learn/op-return)
- [Dust and UTXO consolidation](https://mybitcoinexplorer.com/learn/dust-and-consolidation)