BSIP 61: Operation to update limit orders

[abitmore]

We need business specialists to join the discussion.

[pmconrad]

Since limit_order_create_operation fees do not depend on lifetime either I think this should be discussed / changed separately.

However, in this document, the logic about order creation fee refunding is not mentioned, thus readers would be misled (see BSIP 26).

In my understanding the fees of the update operation are collected immediately and the deferred fee of the limit order is not touched. Perhaps this should be mentioned in a "Discussion" section.

[abitmore]

However, in this document, the logic about order creation fee refunding is not mentioned, thus readers would be misled (see BSIP 26).

In my understanding the fees of the update operation are collected immediately and the deferred fee of the limit order is not touched. Perhaps this should be mentioned in a "Discussion" section.

In order to encourage users to use the order updating feature rather than cancelling + recreating, the order updating fee need to be even smaller than the order cancellation fee even when balance is changed. However, it means a user would be able to "roll" a partially filled order by paying a smaller order updating fee each time, rather than paying a bigger order creation fee, which would significantly impact network income. I think this should be addressed in this BSIP, but not only mention it in a Discussion section.

[pmconrad]

it means a user would be able to "roll" a partially filled order by paying a smaller order updating fee each time, rather than paying a bigger order creation fee, which would significantly impact network income

This is debatable (and has been, see #150 ), hence belongs in a Discussion section. Sometimes lower prices mean more income due to higher volume. That's what we hope to achieve here.

this should be addressed in this BSIP, but not only mention it in a Discussion section

One idea could be to have two fees - one for "fresh" limit orders and one (higher) for limit orders that have been partially filled. If the order has already been partially filled, the fee (or 90% of it) will be moved to the order's deferred_fee. Downside is it's much more complicated for clients, and comes with the danger that transactions are invalidated when a "fresh" order is filled between tx creation and tx inclusion.

Other opinions what's better? @MichelSantos perhaps?

[abitmore]

lower prices mean more income due to higher volume.

The price of order cancellation is 10x lower than order creation according to current fee schedule. To gain the same fee we need 10x volume aka 10 times the operations added to the chain, which would bloat the chain much harder than what we have now, so I think it's against this BSIP's purpose.

[pmconrad]

To gain the same fee we need 10x volume aka 10 times the operations added to the chain

If you look at only the update operations that's true. However, the goal is to boost liquidity, which means more trade volume. Volume results from orders being filled. For each fill at least one open order is consumed, which generates 10 times as many fees as an unfilled cancel+place alone.

encourages traders to move their partially-filled orders away from the top of the order book when the market is moving against their desired direction, and move them back when the market is moving in their desired direction

That doesn't make sense. If the market moves away from a sitting order, there is no need to move it away even further. If the market moves towards a sitting order, it will eventually be consumed, which is what the trader wanted in the first place.

[abitmore]

For each fill at least one open order is consumed, which generates 10 times as many fees as an unfilled cancel+place alone.

OK, I'm almost convinced. Better get some data from the chain. How many orders are cancelled manually after partially filled (with no refund), how many orders are cancelled with a refund.

If the market moves towards a sitting order, it will eventually be consumed, which is what the trader wanted in the first place.

Although it's wanted in the first place, it doesn't mean it's wanted forever. It's common practice for MM bots to cancel orders which would lead to a loss or lead to difficulties in order management.

By the way, I still think having 2 fees differentiating whether balance is updated is unnecessarily complex. KISS, one flat fee is the best.

[MichelSantos]

Short Version

I appreciate the cost factors raised by @abitmore, and the two-tiered fee structure raised by @pmconrad. I think the proposed fee structure is good as an initial rough cut.

My longer reply organizes your ideas a little differently in an attempt to provide the beginning of a more thorough reply. It comes down to asking "What expenses are we attempting to pay for?" and "Who do we want to pay for it, and when?". The answers to those questions will then involve a proper business plan with a fee schedule that is more realistic than the existing fee schedule and which is probably outside the scope of this BSIP.

Long Version

Are we truly attempting to have operation fees pay for a substantive portion of the blockchain expenses?

If the answer is "no" then the fee schedule doesn't really matter. The current fees pay only a small fraction of the blockchain expenses. And the limit order create and cancel operations are only a small fraction of that. Therefore if the limit order update pays a little more or a little less than the current fees from cancel-create combinations, we're just pretending to balance the books of the blockchain.

If the answer is "yes" then we need to discuss which expenses are we trying to cover? Is it to cover the expense of witness pay? Is it to cover up to the maximum daily amount of worker proposals? Both?

Who do we want to pay for those expenses and when?

Assumptions

I'll assume for the rest of this discussion that we are attempting to have limit order create, cancel, and update operations to pay at least the expenses that are incurred by witnesses running a single block producer node. I realize that witnesses run multiple block producer nodes but let's get some idea of the expenses related to limit orders on a single node.

I also realize that there are possible alternatives for getting other activities and other users to pay for the expense of limit orders but this is as good a place as any to start an analysis.

Costs Related to Limit Orders

Before Adding Limit Order Update Operation

Type of Node	Lifecycle Phase of Limit Order	RAM	CPU	Disk Space
Any node	On the books	Order uses RAM	Adds some computation when orders are added and removed to indices, and during order matching	Limit order create and cancel operations use disk space. Limit order object uses storage for persisted object database.
Any node	After removal from books due to matching, cancellation, or expiration	None	None	Limit order create and cancel operations use disk space.
ES node	On the books and afterwards	?	?	Limit order operation and limit order cancel operation use disk space

After Adding Limit Order Update Operation

Assuming the limit order update operations are used

Type of Node	Lifecycle Phase of Limit Order	RAM	CPU	Disk Space
Any node	On the books	Order uses RAM	Adds some computation when orders are added and removed to indices, and during order matching	Limit order create, cancel, and update operations use disk space. Limit order object uses storage for persisted object database.
Any node	After removal from books due to matching, cancellation, or expiration	None	None	Limit order create, cancel, and update operations use disk space.
ES node	On the books and afterwards	?	?	Limit order operation, limit order cancel operation, and limit order update operation use disk space.

Comparison

The introduction of a limit order update could reduce CPU usage while the order is on the books.

The introduction of a limit order update could reduce the overall disk space used on any node if it is used instead of cancel and create operations.

The introduction of a limit order update could reduce the overall disk space used ES nodes at any time.

Estimates of Financial Expense

To estimate the cost of limit orders on block producers we'll need to estimate:

• Amount of RAM consumed by a limit order object in a regular node
• Amount of disk space consumed by a limit order object when persisted on a regular node
• Amount of disk space consumed by a limit order create, cancel, and update operation when persisted on a regular node
• Amount of RAM consumed by a limit order create, cancel, and update operation in an ES node
• Amount of disk space consumed by a limit order create, cancel, and update operation in an ES node

There may be other nuances or expenses that we need to consider. And we might ignore the cost of ES nodes if we expect that the costs of ES nodes will be paid for by some other revenue stream.

We can then estimate financial expenses per limit order under various assumptions.

Pricing / Fee Schedule to Cover Those Expenses

We'll need to estimate

• the number of witnesses
• the duration that an "average witness" will run a node
• the duration that an "average API" will run an ES node

We'll need to estimate whether this fee schedule will dissuade users from using the existing cancel-create combination versus the update operation.

And after we make these estimates we'll probably be wrong. But at least we'll be able to make some justification for the fee schedule.

Summary

It does not matter what the fee schedule is if we are not attempting to pay for specific expenses.

[pmconrad]

It's common practice for MM bots to cancel orders which would lead to a loss

Yes. MM's move their orders with the market. Simplifying things for market makers is the idea here.

KISS, one flat fee is the best.

Agree.

And after we make these estimates we'll probably be wrong.

Lol, agree. Thanks for your insights @MichelSantos . This discussion is out of scope of this ticket, but interesting and necessary in a different context nonetheless.