Refund Create Order Fees on Cancel (Worker Proposal)

[bytemaster]

To make graphene exchanges more similar to other exchanges there should be no fee for creating orders that do not get filled. Unfortunately, to prevent abuse, a minimum fee is still necessary.

This proposal will charge the minimum order fee at the time the order is created. It will be refunded if the order is canceled before any part of the order is filled. A small fee will be charged to cancel orders. This order cancellation fee will be just enough to prevent spam (a fraction of a cent).

If the fee is paid in something other than BTS, it will be converted to BTS via the fee pool at the time the order is placed. If the order is canceled, BTS will be refunded to the user's account.

Recommended Order Creation Fee: $0.20 for normal users $0.04 for LTM
Recommended Order Cancelation Fee: $0.01 for normal users, $0.002 for LTM

Result: minimum market fees for normal users will be less than centralized exchanges for orders greater than $100. For lifetime members, orders above $20 will be cheaper than the 0.2% fee charged by normal exchanges.

Cost: $4000
Escrow: Bunkerchain Labs
Escrow Cost: $400
Worker: 1.14.7
Worker Terms: 2M BTS paid over 40 days at 50,000 BTS per day. Bunkerchain Labs will sell the BTS to raise $4400 and refund any remaining BTS to the blockchain.

[bytemaster]

Paying fees in BTS is the cheapest way to pay fees because the core-exchange-rate for UIA usually charge a slight premium to handle market risk. This means that the next order you place will use the BTS to pay the fee rather than the user asset. Think about it as getting a refund in "store credit". If you place an order, cancel an order and then decide you don't want to do any more business with BitShares then you will have to sell the BTS (which will require placing an order) or "transferring".

Stated another way, for bots it doesn't matter that the refund is in a different asset. For users it doesn't matter either. It will only impact those who attempt to flood with a lot of orders, then cancel all of them. They will end up converting their UIA to BTS at poor exchange rates and then having to sell the BTS.

Bottom line, we presume someone placing an order will eventually want it filled. By refunding them in BTS they can eventually get it filled and end up with 0 BTS.

[bitcrab]

my concern is that the rule may encourage taker but discourage maker, as if an order is partly filled, the creation fee will not be refunded, and obviously taker can be more easily to make sure his order is fully, not partly filled.

how about to make the rule as "only when the order has been filled as taker, canceling the order will not lead to creation fee refund, otherwise canceling order will always lead to creation fee refund"?

[NaturalCoder]

Bytemaster, why not charge the fee only on the taker and use this time to work in something useful? I'm very disappointed with this issue, this is not like BitShares.

[NaturalCoder]

If the problem is perception we can show the fee to the maker on the UI but then post the order a bit cheaper on the book to discount the fee that the taker pays alone. (i don't think this is necessary btw, IMO the taker can pay up to 0.3% without problem because the price on the book is going to be cheap for him).

Charging only the taker simplify the system avoiding the necessity of refund and convert refunds using the fee poll.

Please can you explain why the simplest solution are not been taken in consideration?

[theoreticalbts]

why not charge the fee only on the taker

We need to charge everybody a fee for anti-spam, orders create order objects which must be kept in memory which imposes a resource cost on every node on the network (plus more cost for storage / bandwidth for the transaction). Cancelling an order frees up memory, which can be viewed as a negative resource cost, represented by the refunded fee.

Ultimately I think this reflects a tension between the economic value of liquidity (market makers should be encouraged because a bigger book is better) and its cost (every order consumes memory). If we make the fee equal to cost, someone deciding whether to place an order can determine whether the cost exceeds the value, and the tension is resolved in a decentralized market-based way.

I guess there are two problems here:

• Perception. Maybe users' perceptions quantize fees upward (user views a fee of 1 cent, 0.1 cent or 0.01 cent the same way, but 0 cent differently). Or maybe there is some cognitive/processing cost to the user, because user must now decide whether the fee is worth it. Basically users decide based on their utility function, which is usually smooth (locally linear) function of cost, but the user's utility function has a discontinuity at 0 (formally, U(fee=0) = 0, but U(fee=epsilon) < k < 0 for some k < 0 and arbitrarily small epsilon).
• Incentive alignment. Maybe the system derives additional value from the liquidity created from a user order, above and beyond the user's personal value in placing that order. I.e. the system should invest resources in subsidizing, paying, or otherwise encouraging users to create liquidity, because the system expects this investment to be profitable.

Maybe we can set aside a small number of orders per block (likely burstable via a leaky bucket) for orders which pay with something scarce, but which is free or nearly free to non-spammy users, like coin-days destroyed (or maybe account-days destroyed?), or proof-of-work. This seems pretty far from "simplest solution" territory though.

[NaturalCoder]

I was talking about % fee not anti-spam fee, I think we should charge only an small anti-spam BTS fee for order creation and nothing for order cancel and % 0.3 fee for order match. (If every new account have been previously funded with some small BTS quantity, the perception is that this anti-spam fee is free)

[NaturalCoder]

It is stupid for us charge fees on any operation that locks up money on the system like borrow, vesting or making our order book

[NaturalCoder]

We can create a system token, something like "try BTS fees discount" that have equal value of BTS for only anti-spam fees payment and cannot be traded or transferred then pre-fund every new account with it, that way users can try our system and we prevent spam as well. (the amount to be pre-funded has to be less than the create account fee)

[theoreticalbts]

@bitcrab @NaturalCoder Let's move discussion about only charging taker fees to #468

[theoreticalbts]

Unit test finished, branch now awaiting review.

[bytemaster]

After closer review it appears to do the proper thing. (at least the referenced commit).