Configurable minimum transaction amount

Based on:

  • Bounded block backlog
  • Anti-Bloat Proposal: Age-Based Dust Removal
  • Minimum account balance to prevent ledger size spam


Nodes can configure a minimum transaction amount they will accept.
Transactions below this minimum will be discaded by the node.
An exception to this would be change transactions with amount exactly equal to zero.

Why a minimum amount?

Nano was designed to be very divisible, which is great because:

  • You can send small test transactions
  • Faucets are relatively cheap because the min amount they can send is very small
  • It is future-proof, even if a candy costs 100 RAW in a few years

But currently, many node operators would agree that using their resources for processing thousand of transactions with amount 1000 RAW do not make much sense.

Just to get an idea, most wallets and faucets send values greater than 10^24 RAW.

Advantages of being configurable

It is difficult to reach a consensus on what the minimum value should be.
Some nodes can choose to ignore all transactions with less than 10^22 RAW. Some will ignore transactions with amount below 10^10 RAW. Some nodes can even choose to not ignore any amount at all.

In the end, dust value transactions will have less chance for being confirmed, because some nodes won't rebroadcast it, and will have less impact in the network in general.

Legit transactions should be confirmed at normal speed or even faster because the network can perform better.

But isn't V22 a solution for that?

Even with V22, a spam attack can still slow down confirmation times, because of high resource usage, as some tests in beta showed us.

And since spam transactions are only delayed, and not dropped (yet), these tranasctions will soon or later bloat the ledger with dust value transactions.

Bounded Block Backlog (BBB)

BBB is somewhat similar to what I am proposing, but one does not exclude the other.

While BBB can limit the backlog size and drop less prioritized transactions, a minimum amount can avoid a prioritized 1 RAW transaction of being send, if nodes agree so.

If you combine them:

  • Nodes will have less problem syncing
  • Transactions can be confirmed faster
  • Less resources (costs) for running a node
1 Like

problem: if 33%+ of the network decides on a high limit, you basically lose the ability to confirm blocks

1 Like

I think that only happens with 33% of voting weight.
33% of regular nodes will only make the processing slower...

Now, I am not sure if PRs would want to use a high minimum value.
They seem to be ok with no minimum at all, currently.

Maybe the rule could be like "minimum amount can't be greater than 10^20 RAW (0,0000000001 nano)".

So you are proposing a maximum minimum amount... then a minimum maximum minimum amount would be a hardcoded limit.

I'm playing devil's advocate here


The "max min" could be hard-coded each release.