Quote from: junkonator on January 14, 2016, 10:44:17 PM

I think it's time to introduce some changes to the BDD fee attribution for the new round. BDD is working because of its excellent management - 2070 can't be thanked enough! Does anyone here even remember deprived? - and because there is the possibility to always buy and sell on the market at a reasonable price and in reasonable volume. Big parts of this liquidity are provided daily by market makers and arbitrageurs.
To make BDD more dynamic I propose a simple change:

Accounts with huge volume should get a discount on the management fees of B.EXCH.

For everybody who isn't a market maker or arbitrageur this has the benefit of more liquidity because market prices will be closer to their actual valuation. Because the market makers will pass along their reduced fees, tighter valuations can then also be traded. Looking at the past few months I think there is a huge amount of trades that didn't happen because the bid and ask gap was too far apart. A 3% markup is a big variable for a valuation as tight as the one we're looking at. The higher traded volume in turn means higher profits for 2070, too.

The proposal in detail
Half of the management fees (1.5% of NAV/U - the current management fee is 3% of NAV/U) will be waived for trades done by accounts/traders with a volume of 10 BTC+ within a period of 1 month.
This way the amount of extra work for 2070 increases only by one check of account volumes per month (or other period) and it's completely transparent to outsiders.

The technical details
How and when to determine the volume and how to give a discount?

Look at the trade volume of each account over a certain period of time and give a discount on the fee for the following period for high volume accounts - this is most probably difficult/impossible to do if havelock doesn't implement that technically.
Look at the trade volume of each account over a certain period of time and reimburse parts of the management fee if the volume was high afterwards - probably the easiest way to handle this
Depending on the data provided by havlock to the issuers a rolling average model could also be possible - this would most probably mean more work for 2070 though and therefore is not a preferable option

I'm looking forward to discussions and hope to also hear from parties who are not 2070 or market makers

Thanks 2070 for your unique-in-BTC management!

Hey junkonator, thanks for the message and the kind words. I haven't been ignoring you; have just been sick for the past four days or so.

I do recall you pitching this to me a number of months ago. I'm inclined to deny this change request (again) for the following reasons:

It's true that, by lowering the fees for some or all of the market, the spread will be smaller. However, this gives an advantage to whoever is getting the fee discount - small market players will not be able to perform any arbitrage if the larger players can trade at NAV/U + 1.5% (with their bots) while everyone else can trade at NAV/U + 3%.

I don't really think that this will really increase the trade volume by very much. In addition, the market makers in this market are performing arbitrage 90%+ of the time; normally market makers are putting up big orders on the market. If this were the case, I would be more inclined to accept this suggestion. Also, I don't have a reporting function that can tell me who traded X amount of MINE/EXCH/SELL - that's all on Havelock's side. I just get the excel databases with the unitholder lists.

Overall, from my point of view, the trade volume stays about the same; I have to request custom monthly reports from Havelock (which I'm not sure they would agree to provide); a handful of large traders monopolize the arbitrage opportunity; and I lose ~50% of my management fee. While I might benefit (slightly) from increased trade volume, I'm not sure that this would increase trade volume at all and, also, I make 90% of my earnings from the management fee versus ~10% from the volume share with Havelock.

I'm open to other opinions but, save a rousing argument to the contrary, I'm going to stick to the current structure.

Best,
2070