<p>Bitcoin-ABC (the reference implementation of Bitcoin Cash) is a fork of bitcoin core, there are no big changes to the settings.</p>

<p>so bitcoin cash dust limit is exactly the same as Bitcoin which is 546 Satoshi.</p>

<p>To make sure you can review Bitcoin-cash-ABC/transactions_test/ file code on <a href="https://github.com/Bitcoin-ABC/bitcoin-abc/blob/9bbaacc1e0d86a7a18352068b93ca0ccab45f2ea/src/test/transaction_tests.cpp#L546" rel="nofollow noreferrer">GitHub</a> line 546</p>

<p>And on transactions file <a href="https://github.com/Bitcoin-ABC/bitcoin-abc/blob/9bbaacc1e0d86a7a18352068b93ca0ccab45f2ea/src/primitives/transaction.h#L177" rel="nofollow noreferrer">here</a> </p>

<pre><code>/**
 * "Dust" is defined in terms of CTransaction::minRelayTxFee, which has
 * units satoshis-per-kilobyte. If you'd pay more than 1/3 in fees to
 * spend something, then we consider it dust. A typical spendable
 * non-segwit txout is 34 bytes big, and will need a CTxIn of at least
 * 148 bytes to spend: so dust is a spendable txout less than
 * 546*minRelayTxFee/1000 (in satoshis). A typical spendable segwit
 * txout is 31 bytes big, and will need a CTxIn of at least 67 bytes to
 * spend: so dust is a spendable txout less than 294*minRelayTxFee/1000
 * (in satoshis).
 */
</code></pre>

CC BY-SA 3.0
2018-03-05T09:41:09.653Z
Can you provide some sources for this answer somehow?
Thorkil Værge
CC BY-SA 3.0
2018-03-05T10:01:49.910Z
Yeah, I've edited the answer!
Tailer
CC BY-SA 4.0
2018-12-10T09:31:56.290Z
I didn't know the dust limit was different on segwit transactions but it makes sense based on the comments from the code.
Thorkil Værge
CC BY-SA 4.0
2019-07-29T20:23:21.037Z
How weird is it that this information was on line 546?
Thorkil Værge
CC BY-SA 3.0
2018-03-05T08:52:56.057Z
2018-04-28T11:13:04.187Z
2018-04-28T11:13:04.187Z
Tailer
<p>I understand from <a href="https://bitcoin.stackexchange.com/a/57793/38458">another question</a> here on Stack Exchange that the dust limit for Bitcoin transactions is 546 satoshi, meaning that no transaction output may be on an amount less than that. What is the equivalent dust limit for Bitcoin Cash transactions?</p>

CC BY-SA 3.0
2018-03-05T10:20:46.267Z
I usually think about the dust level in units of sat/Kb.
Willtech
<bitcoin-cash><dust>
What is the dust limit on Bitcoin Cash transactions?
Thorkil Værge
# What is the dust limit on Bitcoin Cash transactions?

(Asked by: username_0 on 2018-03-01)

I understand from [another question](https://bitcoin.stackexchange.com/a/57793/38458) here on Stack Exchange that the dust limit for Bitcoin transactions is 546 satoshi, meaning that no transaction output may be on an amount less than that. What is the equivalent dust limit for Bitcoin Cash transactions?

**Tags:** bitcoin-cash, dust

> **Comments:**
> **username_1**: I usually think about the dust level in units of sat/Kb.  

---

## 1 answers

### Answer by username_2 on 2018-03-05. Score: 7 | Accepted answer

Bitcoin-ABC (the reference implementation of Bitcoin Cash) is a fork of bitcoin core, there are no big changes to the settings.
so bitcoin cash dust limit is exactly the same as Bitcoin which is 546 Satoshi.
To make sure you can review Bitcoin-cash-ABC/transactions_test/ file code on GitHub line 546
And on transactions file here 
/**
 * "Dust" is defined in terms of CTransaction::minRelayTxFee, which has
 * units satoshis-per-kilobyte. If you'd pay more than 1/3 in fees to
 * spend something, then we consider it dust. A typical spendable
 * non-segwit txout is 34 bytes big, and will need a CTxIn of at least
 * 148 bytes to spend: so dust is a spendable txout less than
 * 546*minRelayTxFee/1000 (in satoshis). A typical spendable segwit
 * txout is 31 bytes big, and will need a CTxIn of at least 67 bytes to
 * spend: so dust is a spendable txout less than 294*minRelayTxFee/1000
 * (in satoshis).
 */

> **Comments:**
> **username_0**: Can you provide some sources for this answer somehow?  
> **username_2**: Yeah, I've edited the answer!  
> **username_0**: I didn't know the dust limit was different on segwit transactions but it makes sense based on the comments from the code.  
> **username_0**: How weird is it that this information was on line 546?  

---

