Feedback on latest fee change

[sschiessl-bcp]

In light of recent discussion I want to create an issue to actually collect constructive feedback. This discussion must take place in the USD denominated fee realm and assume regular update to keep the peg.

No FUD, no complaints about existing fees without providing a solution.

[sschiessl-bcp]

This is a head-play, but I want to show how you can constructively tackle the situation.

In the following tables we show the old fee set in 2016, the new fee with the currently pending proposal and the factor of the increase compared to the old fee and a suggestion incorporating current feedback

Reduce end user charge

Type	Old fee (2016)	New fee #2 / Factor	Suggestion / Factor
transfer	0.018	0.08 / 4.44x	0.036 / 2x
limit_order_create	0.001	0.01 / 10x	0.003 / 3x
limit_order_cancel	0.0001	0.001 / 10x	0.0002 / 2x
vesting_balance_create	1	2 / 2x	1 / 1x

Increase business charge

Type	Old fee (2016)	New fee #2 / Factor	Suggestion / Factor
asset_issue	0.018	0.05 / 2.77x	0.10 / 5.55
asset_claim_fees	1	1 / 1x	2 / 2x
asset_create 4	2000	3000 / 1.5x	5000 / 2.5x
asset_create >4	50	100 / 2x	500 / 10x

Roll out smoothly

Update over a period of 3 months, with one update each month, scale linearly.

[crypto-1]

While we agree that Gateways should burden the majority of the blockchain's costs, I think that the proposed asset_issue fee is too high. Would suggest a USD value of 0.065 which is an increase of 3.61x of the Old fee (2016) and an increase of 1.3x of the New fee #2.

I think the other fees, especially the asset create fees are reasonable and fine.

[litepresence]

limit_order_cancel pricing is the greatest issue dex faces

Why?

0. liquidity is the blood of the market, liquidity at the margins is its heart beat

1. our competitor is CEX, which provides this service for free and CEX books are happy dancing animations as a result.

2. every cancel op takes up space on blockchain; by orders of magnitude, there are more cancel ops than anything else this poses a technical issue and the only attempted solution is to tax

3. what we tax we get less of, what we subsidize we get more of

4. unlike other operations in which "flat fee" constructs pose little harm to end user because they are flat fees on a few operations... the nature of providing liquidity at profit requires tens if not hundreds of thousands of ops annually to bootstrap a market. A shift in flat fee times 100,000 is much more pertinent than a shift in flat fee to create a single 4 letter asset.

5. the vast majority of transactions that occur in most healthy markets; cex dex forex whatever are primarily liquidity providers providing liquidity at the margins to random individuals who seek urgent entry/exit

6. when bootstrapping a market which mirrors a cex market... it does not matter that the market has the 24 hour volume of $1 daily or $100000 daily in gross trades... the strategy involved in scalping such a market remains the same; the total number of operations annually for a liquidity provider does not change significantly; to maintain margins and provide liquidity requires algorithm to move buy/sell scalp ops dynamically as prices shift in the greater CEX markets. Obviously low 24 hour volume markets will have low returns, yet the flat cost of doing business is the same.

I propose that effective bootstrapping of a market requires absolutely no less than 100k annual operations.

86400/300 = 288 five minute candles daily; *365 = 105120

This gives liquidity provider option to move one order every 5 minutes. Anything less than this... it becomes challenging to provide dynamic liquidity in fast paced crypto markets.

I would like to note here... in CEX markets... the algorithms which I experienced building for client to promote their wares over past 8 years or so would keep 10 orders on each side of book and move and randomize their size independently every minute to give the "sense" that there many market participants urgently seeking to jockey for best position.

20*5*105120 = 10 million operations annually per market

This is what creates those happy dancing orderbooks you always see in CEX land... it is not individuals doing this... I can assure you it is liquidity providers using algo to pose as individuals to keep these books alive; all day every day.

So lets rewind... these numbers are not easy to grok:

limit_order_cancel 0.0001 0.001 / 10x 0.0002 / 2x

so lets speak in annual fee on 100k operations. previously we were

$10 per 100k cancel ops
$100 per 100k create ops

the "new fee #2"

$100 per 100k cancel ops
$1000 per 100k create ops

So right here... I see that a choice to bootstrap a low volume market - mind you there is a degree to which this is "speculative activism" not "profit motive" now base flat fee cost to provider is between $100 and $1000; and this is not happy dancing CEX style orderbooks... it is 5 minute updates of 1 order. "Happy Dancing" orderbooks would cost up to $10k just for cancellation and up to $100k if all orders filled. So happy dancing is immediately out of the question.

so these are my concerns and I stop here with regard to "what fee should be"; do as you will... keep in mind if you like to see happy dancing books in low cap markets it must be cost effective

No FUD, no complaints about existing fees without providing a solution.

I agree and I do not wish to FUD anything; I seek solutions outside of the current fee structure paradigm, hopefully this discussion is in place and not out of context of this "issue"

1. subsidy. It should be seen that there is no DEX without liquidity, there is no liquidity without liquidity providers running algo. There must be a degree to which the space taken up by liquidity providers cancel operations on chain is subsidized by fees earned through other activity. What we subsidize we get more of and if we wish to have happy dancing books we need to subsidize this activity.

2. as liquidity providers we need to accept the fact that we are causing congestion and concede to find means to move less often while remaining profitable. My recommendation here is not to decrease algo tick frequency but instead to move towards only moving one's orders upon them being touched. In practice, this should reduce cancel operations tenfold. Unfortunately, this will invariably come at the expense of happy dancing orderbooks...which are already barely/not affordable. Nonetheless, this is the path I will be taking with my platform. When the sum of my buy/sell ops on the books decreases from one tick to the next: I move; else the orders stay where they are.

3. percent from center. Perhaps a technical solution to segregate "spam" from non-spam small orders is scale fee based on the distance the order is from the top of the book. So... I propose 100k cancel ops for sell orders placed 2X market price should be much more expensive than 100k cancel ops for sell orders placed 1% from top of the book. How this is implemented, what it costs in processing power... these things are beyond me, what I do know is that 100k orders near the margins provide utility and 100k orders far from margins do not. We should not tax both market participants equally when one provides near margin liquidity service and the other is what everyone would agree to call spam.

4. maker/taker. The liquidity provider is "usually" the one making the market; placing a limit order on the books. The takers are the ones placing market orders, spreading the margins and reducing the orderbook depth. In CEX land it has been long understood that takers should subsidize makers to effectively bootstrap markets.

5. order size. currently if you place an order for less than 0 amount_to_sell, the backend will throw error and the order will not go through. I think this should be scaled to 1 Bitshare; ie graphene integer amount 100000/10^5 bitshares precision. Then likewise for other cryptos we useasset precision to scale the minimum order size for the asset in question.

So minimum amount_to_sell Bitshares is 1

BTS precision = 5
100000/10^5 = 1

but minimum amount_to_sell OPEN.BTC is:

OPEN.BTC precision = 8
100000/10^8 = 0.001

In this way the backend can automatically reject orders for "spam size" amounts. This same utility will be found at ANY centralized exchange to prevent spam. Bitshares DEX woefully neglects this principle.

just because the "precision" of OPEN.BTC is 0.00000001 does NOT mean we should have the option to place order sizes of 1 satoshi, and pay the same fee, and cause the same chain bloat, as a serious market participant.

6. with the rejection of dust size orders per previous subject... I believe it would become very reasonable to move towards a percent fee paradigm. This already occurs in the "market fee" for doing business on a UIA. So I cannot imagine there would be too much technical difficulty in shifting from the current flat fee create/cancel model to instead percent fee on filled orders only.

7. satoshi chapter 7. I think this is by far where most meditation should REALLY be occurring. DEX on chain is a whole different ballgame than what Bitcoin is in terms of rate of growth of chain. Bitcoin is transactions. Bitshares is transactions plus DEX market operations * number of markets. The notion of "pruning the merkle tree" immediately becomes much more pertinent as we outpace moores law. Ultimately, if we are to have "happy dancing orderbooks" just like cex then taxing cancel ops to prevent "spam" is not the solution. We are already approaching point of 100k ops being noteworthy in cost... and happy dancing books is 10m ops annually. The solution must be to brainstorm and implement means to prune unrealized dead operations from the chain. The more intellectual force we can apply to the realization of this key ingredient the more healthy our long term DEX markets will be and the less burdensome the size of the chain will become 20+ years into the future. Healthy markets - as implemented by liquidity providers - require that canceling orders MUST BE FREE or nearly free. The only way this can be realized is through purging.

Conclusion is we can find technical ways to use market forces - aside from increasing flat fees - to encourage users to place only orders that matter:

stage 1)
do not increase cancel/create fees significantly because we already approach point that liquidity providers can't make books dance. Accept that until technical solutions arise this must be subisidized.

stage 2)
prevent dust size orders by rejection using asset precision
implement maker taker paradigm
tax on flat fee basis ONLY for placing orders too far from market center
use percent based fees on FILLED orders just like UIA market fees.

stage 3)
Satoshi predicted this issue and proposed a solution a decade ago:

It is time to realize the dream.

[CryptoKong]

@litepresence fantastic contribution thankyou.