<p>Standardness refers to a stricter set of rules enforced by full nodes on a transaction in addition to the consensus rules. Policy is an even broader set of rules or processes followed by a node. Contrary to standardness it is not local to a single transaction nor is it specific to validation rules.</p>
<p>Taken broadly, policy is everything that is not consensus. The set of rules dictating whether a block is valid is consensus. All the rest: how the block is relayed, whether a cache of unconfirmed transactions was used to speed up its transmission and validation or how unconfirmed transactions are propagated through the network is policy. For example:</p>
<ul>
<li>A transaction is invalid by <strong>Bitcoin consensus</strong> if the sum of the value of its outputs is larger than the sum of the value of its inputs. (In other words, its fee is less than 0.)</li>
<li>A transaction is invalid by <strong>Bitcoin Core standardness</strong> rules if it has a fee lower than 1sat/vbyte.</li>
<li>Sending an unconfirmed transaction which has 25 or more unconfirmed ancestors violates <strong>Bitcoin Core policy</strong> rules.</li>
</ul>
<p>Mempool policy is the set of rules describing the validity of a transaction from the point of view of a node's mempool. Probably the biggest difference with standardness is that it is contextual. An unconfirmed transaction may well be valid according to standardness (and therefore consensus) but still be refused by a node's mempool. The ancestor rule from above is one such example.</p>
<p>The mempool isn't however the only area where policy rules apply. For instance, transaction relay is another. For instance, the maximum number of transactions a node will request or announce per peer is often referred to as policy.</p>
<p>Finally, while policy may vary from a node to each other not all rules are equally important. A node for instance may choose to not store and relay unconfirmed transactions which store data in <code>OP_RETURN</code> outputs, or not store and relay unconfirmed transactions at all, and still be part of the network. But you can think of any stupid policy a node may have (for instance only finding peers and/or relaying blocks through its own custom protocol), in which case it would hardly even keep up with the network although it does implement all consensus rules. And there is every degree in-between, with the corresponding <a href="https://bitcoinops.org/en/blog/waiting-for-confirmation/#policy-consistency" rel="nofollow noreferrer">expectations one may have about the network</a>.</p>
<hr />
<p>Note this is an attempt at an answer; terminology is notoriously confusing in Bitcoin and people may have a different view of what &quot;policy&quot; represents. It's just the definition i've been using (without ever spelling it out, so thanks for the question) and found useful when discussing related matters with other Bitcoin developers.</p>

CC BY-SA 4.0
2023-10-30T17:29:30.760Z
2023-12-16T00:49:33.210Z
2023-12-16T00:49:33.210Z
Antoine Poinsot
<p>How about a partial answer?  It appears the answer I was looking for is in the code! :-)</p>
<p><a href="https://github.com/bitcoin/bitcoin/blob/master/src/consensus/" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/consensus/</a>
<a href="https://github.com/bitcoin/bitcoin/blob/master/src/consensus/amount.h" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/consensus/amount.h</a>
<a href="https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h</a>
<a href="https://github.com/bitcoin/bitcoin/blob/master/src/consensus/validation.h" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/consensus/validation.h</a></p>
<p>I'm still confused as to how policy is not consensus when there are policy checks in the consensus validation checks, tho...</p>
<pre><code>TX_INPUTS_NOT_STANDARD,   //!&lt; inputs (covered by txid) failed policy rules
TX_NOT_STANDARD,          //!&lt; otherwise didn't meet our local policy rules
TX_MEMPOOL_POLICY,        //!&lt; violated mempool's fee/size/descendant/RBF/etc limits
TX_RECONSIDERABLE,        //!&lt; fails some policy, but might be acceptable if submitted in a (different) package
</code></pre>
<p>But I won't ask anymore questions until I ponder more.  :)</p>

CC BY-SA 4.0
2024-01-10T02:41:55.590Z
2024-01-10T02:41:55.590Z
DoctorBuzz1
<p>In answers concerning validity or propagation of transactions as well as topics surrounding consensus, people frequently mention &quot;policy&quot; or sometimes &quot;mempool policy&quot;.</p>
<ul>
<li>What do people mean when they mention &quot;policy&quot; or &quot;mempool policy&quot;?</li>
<li>How is that related to (non-)standard transactions and transaction validity?</li>
</ul>

<mempool><terminology><non-standard-transaction>
What is "(mempool) policy"?
Murch
# What is "(mempool) policy"?

(Asked by: username_0 on 2023-10-30)

In answers concerning validity or propagation of transactions as well as topics surrounding consensus, people frequently mention "policy" or sometimes "mempool policy".

* What do people mean when they mention "policy" or "mempool policy"?
* How is that related to (non-)standard transactions and transaction validity?

**Tags:** mempool, terminology, non-standard-transaction


---

## 2 answers

### Answer by username_1 on 2023-10-30. Score: 5

Standardness refers to a stricter set of rules enforced by full nodes on a transaction in addition to the consensus rules. Policy is an even broader set of rules or processes followed by a node. Contrary to standardness it is not local to a single transaction nor is it specific to validation rules.

Taken broadly, policy is everything that is not consensus. The set of rules dictating whether a block is valid is consensus. All the rest: how the block is relayed, whether a cache of unconfirmed transactions was used to speed up its transmission and validation or how unconfirmed transactions are propagated through the network is policy. For example:

* A transaction is invalid by **Bitcoin consensus** if the sum of the value of its outputs is larger than the sum of the value of its inputs. (In other words, its fee is less than 0.)
* A transaction is invalid by **Bitcoin Core standardness** rules if it has a fee lower than 1sat/vbyte.
* Sending an unconfirmed transaction which has 25 or more unconfirmed ancestors violates **Bitcoin Core policy** rules.

Mempool policy is the set of rules describing the validity of a transaction from the point of view of a node's mempool. Probably the biggest difference with standardness is that it is contextual. An unconfirmed transaction may well be valid according to standardness (and therefore consensus) but still be refused by a node's mempool. The ancestor rule from above is one such example.

The mempool isn't however the only area where policy rules apply. For instance, transaction relay is another. For instance, the maximum number of transactions a node will request or announce per peer is often referred to as policy.

Finally, while policy may vary from a node to each other not all rules are equally important. A node for instance may choose to not store and relay unconfirmed transactions which store data in `OP_RETURN` outputs, or not store and relay unconfirmed transactions at all, and still be part of the network. But you can think of any stupid policy a node may have (for instance only finding peers and/or relaying blocks through its own custom protocol), in which case it would hardly even keep up with the network although it does implement all consensus rules. And there is every degree in-between, with the corresponding [expectations one may have about the network](https://bitcoinops.org/en/blog/waiting-for-confirmation/#policy-consistency).

---

Note this is an attempt at an answer; terminology is notoriously confusing in Bitcoin and people may have a different view of what "policy" represents. It's just the definition i've been using (without ever spelling it out, so thanks for the question) and found useful when discussing related matters with other Bitcoin developers.


---

### Answer by username_2 on 2024-01-10. Score: -2

How about a partial answer? It appears the answer I was looking for is in the code! :-)

<https://github.com/bitcoin/bitcoin/blob/master/src/consensus/>
<https://github.com/bitcoin/bitcoin/blob/master/src/consensus/amount.h>
<https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h>
<https://github.com/bitcoin/bitcoin/blob/master/src/consensus/validation.h>

I'm still confused as to how policy is not consensus when there are policy checks in the consensus validation checks, tho...

```
TX_INPUTS_NOT_STANDARD,   //!< inputs (covered by txid) failed policy rules
TX_NOT_STANDARD,          //!< otherwise didn't meet our local policy rules
TX_MEMPOOL_POLICY,        //!< violated mempool's fee/size/descendant/RBF/etc limits
TX_RECONSIDERABLE,        //!< fails some policy, but might be acceptable if submitted in a (different) package

```

But I won't ask anymore questions until I ponder more. :)


---

