[Draft] Volume-dependent Transaction Fees

Very cool. I noticed you are doing:
Max( 0.01 , pfunction)
Rather than:
Max( 0.1 , function)

Which do you think is a better formula?

Also, end users often see a % fee when transferring fiat.

Without anything other than a hunch, a low-end transaction fee of $0.01 seems sensible and explainable. I can’t see cases of charging people $0.10 for a transaction fee for a cup of coffee being well-received, nor do I think explaining “fractions of a penny” to the mass market is an easy effort.

As such, I think using ‘p’ to scale the log function portion has merit. I may have read the formula wrong, but there may be some upside.

Nu for sure can have many uses – currency transfer, store of wealth, and transaction settlement.

The way I see it is that consumer adoption for “day to day” activities is the larger barrier for global adoption. Merchants have shown it to be relatively straightforward to integrate blockchain-like at the POS; it’s the consumers who are not showing up with crypto in-hand.

I see 4 use cases for Nu, probably 3 of which we want:

1- day-to-day transactions (consumer goods and services, including the cup of coffee analogy)
2- larger transactions – mostly business, but some consumer: buying a vacation, a car, a house, a company, paying salaries **
3- microtransactions – buying digital property (in-game purchases, music)
4- dust / spam transactions

Transaction sizes by consumers for credit cards and debit cards are approximately $75 and $40, based on data from 2012, so I’d put a line between ‘day-to-day’ and ‘large-scale’ somewhere in that range.

With the p=0.1 model, the transaction fee increases beyond $0.01 somewhere in that ‘average transaction’ range, at probably somewhere around $50 or so. From a consumer standpoint I think this is easy to understand: your average day-to-day transactions are essentially flat rate at or near $0.01, and anything beyond that will have additional fee.

Large-scale transactions would likely be viewed thru the lens of percentage-of-transaction fee, and benefit from “volume discounts”.

Or, in other words: consumers are probably looking at the $ value of the transaction fee (like tax on a dinner), whereas businesses and large-scale transactors looking at the percent.

Microtransactions may be something to ignore / avoid for the time being. With a 1-minute block-time, at-scale, Nu will already have to store and manage 10x the design volume of Bitcoin, which would easily push the project into yet another plane of uncharted territory.

And of course dust and spam transactions have generally been controlled with the $0.01 threshold.

** footnote: product idea: some sort of mixing / splitting service would probably be of benefit (if not required) if Nu is used to pay salaries.


There can be mixing services, wallet migration, and some possible blockchain mechanisms that bounce money back and forth (such as a satoshidice-type operations). It is unwise to penalize those transactions.

Banks offer fixed inter-bank transfer fees and free intra-bank transfers in many cases, and we don’t want to look more expensive than a bank.

I guess it is very important in discriminating different use cases, possibly using a good overall mechanism that is simple enough for the user. Again we can consider how park rates could help mitigating the perceived drawbacks of this transaction fee for users.

If we combine some ideas with demurrage/wallet fees, perhaps it is reasonable to charge a transaction fee that scales with the average coinage in a wallet. Say we let p to be proportional to the average coinage and capped at 0.1.

Or we can do it backwards where the transaction fee is reduced for higher coinage. We can even offer a choice of “deferred transfers” that is just parking in disguise - the NBT is sent to a parking address and then “returned” to the intended destination, and the parking interest would incidentally offset the fee (which prompts me a question: does parking circumvent this fee?)


Great questions, love the discussion.
Yah, we can really do this however we want. We can exclude certain addresses, parking or burns or coinbase tx, we can exclude tx within an account and only charge the .01 nbt exclusion fee to avoid dust txns.
I like the coinage concept. I think going up for coinage rather than volume is a good idea. If we use log(coinage)=log(volume)+log(time) we can just add the volume part and the time part to get the total fee. The time part can be the number of blocks since moved and we can normalize it with q. The voters could then vote separately on the volume and the time part of the fee. We would have to impose the block chain cutoff as you explained because people will end up with bits that cost more to move than the balance of the address.
If the time part is negative, we would end up subsidizing hording, which is super similar to parking, perhaps even more elegant than parking. I think it’s very interesting to consider.

1 Like

I have attempted to make the motion as general as possible to allow shareholders room to implement a function as they see fit. Good choices seem to be:

@woodstockmerkle’s charts:
f(V) = V / (100 * [log(V) + 1])

f(V) = {0.01 NBT for V < 10 NBT, 0.1 NBT for V < 500 NBT, 5 NBT for V >= 500 NBT}

If no additional function motion is voted in, it will default to:
f(V) = V * 0.01 NBT

Is 10,000 NBT appropriate payment for this implementation?

Edit: I added a paragraph about the chunking software. I hope I didn’t go too technical for it to appeal to shareholders, but as far as I understand a large portion of the community supports a volume-dependent fee. I’m hoping we can settle on something and pass it, despite the developers not having time currently. If a motion is needed to secure priority, we can do that, but I think just offering the standing reward should be enough to get the NuTeam on it eventually.

Also, note that the standard micro Txn gets double charged for having two different types of outputs (the send Txn and the change). An attacker ends up paying p * 0.02 NBT for a simple Txn. A microTxn sendmany rpc command when done in avatar mode (like our pools) would end up paying 0.01 NBT / smallOutput + 0.01 NBT / KB scaled by p.


Would it be preferable for me to simplify the motion to just say “Shareholders will pay 10,000 NBT for protocol and wallet enhancements necessary to securely implement a volume dependent fee. The volume dependence will be 1% unless specified further in another motion.” or would the devs prefer I spell it out?

I would prefer seeing the motion split into two parts - one to declare volume-dependent transaction fees as a priority for development, and then a second to negotiate compensation with the developers. I don’t see how you came up with 10,000 NBT and that number could be very inaccurate.

You might consider adding “exhibits” to your motion, such as “Exhibit A - Sample of volume-dependent transaction fees as proposed by woodstockmerkle”, that are a link to an image like this one. This will help shareholders understand what is being proposed without having to interpret math equations.

Do you mean in the hash itself? I’ve never seen anyone use an image in a hash. Or do you just mean reference the images outside of the hash in the OP?

Can you explain how I would go about writing a motion to negotiate compensation? Are you just proposing that I pass the first and let the NuTeam pass the second? I can do that, no problem.

I’m confused how to refer to development priority. Nubot and marketing have roadmaps, but NuDev doesn’t really have an explicit roadmap does it?

The text of a link to the image (like “https://discuss.nubits.com/uploads/default/original/1X/a56aef3b7f40419bc811f52f69b1ddd28265bd03.PNG”) could be added to the motion text itself and then hashed as usual afterwards. I think having that sample table of transaction fees makes your case much more compelling to ordinary shareholders versus only providing a formula.

I think the first motion will pass much easier without compensation attached, as we are only declaring it to be a development priority. As far as the second motion goes, you could take two approaches. You could either put up a draft motion regarding compensation with no estimate, and instead ask for public comment from a developer, or else you could privately PM sigmike, Giannis or Jordan to figure out a rough estimate of cost before proposing it publicly.

That’s a good question. I think an absolute statement like “Volume-dependent transaction fees should be the Nu development team’s highest priority” would make clear that it should be prioritized above all else, but I’m not sure how you would slate it in between other priorities without a concrete roadmap. Others might have to answer that one.

That’s intense, I’m not sure I want to go that far. I definitely think it’s important, can I just say “Volume-dependent transaction fees should a high priority for the Nu Development team”?

How much extra revenue Volume-dependent fee will bring to Nu at current rate? How long will it take to break even with $10k ?

1 Like

So we should be able to make between 10 and 30 kNBT/year without even weighing down too heavily on the network (p=1). So I would expect we could break even on $10k within a year using relatively conservative parameters.

Thanks for reminding. By default f(V), p=1 basically means charging a 1% fee, right?

So, it depends on how we end up doing things. The estimations I made were months ago and were based on the log fee (woodstock’s chart). The 1% default fee would only be if the shareholders fail to converge on a volume-based function. I’m currently struggling to write this motion in an acceptable manner to shareholders and devs alike, so it’s still somewhat in flux.

In all cases, p is a multiplier. It is simultaneously a multiplier for the Size based fee as well as the volume based fee. Therefore, any gains at p=2 are always exactly double that made at p=1 assuming the userbase is unnaffected.

Motion RIPEMD160 hash: tbc

=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=
Volume dependent transaction fees, being a clear and long term source of profit for the network, are a high development priority.
=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=

Sorry for buzzing an old topic but the Coinage dependant fees sounds so great!

It may be the solution to the situation when 99% of transactions are off the chain, Coinage dependant Fee will reward Shareholders reasonably once the money moves through the chain no matter how long we waited, no?

But if the future of Nubits is mostly off the chain and most of the users never touch the client, would either parking Or negative Coinage fee Be able to decrease the supply at all? Or would it benefit the off chain services more than helping Nu?

Coinage dependent will make it so that we can make it cost money to hold your bits for too long. However, a somewhat unfortunate side effect is that the money is not paid until a txn happens. So shareholders will naively lower the time component in an attempt to get people to hold nbt, and it will actually have the opposite effect, causing long time hoarders to finally move their coins who have been waiting a long time for shareholders to lower the time component.

There are a lot of things to talk about here. I’m very happy to keep spit balling.

Quick answer:
The Code could use the time factor (not of the last block) but instead in the block which the output was created in, this will make it just like parking except that user would have the ability to dynamicly choose their unpark date, which means the discouraging fear of not having liquidity when they really need it will be eliminated.

May be the mean of values of q through the blocks hiegher than the output block could be useful.
But this is a quick thought, I will investigate it later.

1 Like

I didn’t realise this coinage dependent fee idea is such an old idea, how come we didn’t make it real, there seemed to be good support for it.


B&C development became a higher priority.