Market: Adding liquidity should be free

[mdyring]

Is your feature request related to a problem? Please describe.
To incentivise market makers, net adding liquidity over time should be free. This can be unpacked as:

• Adding liquidity should be free, e.g. MsgAddLimitOrder and potentially MsgAddMarketOrder.
• Removing liquidity should never be free, e.g. MsgCancelOrder.
• Replacing liquidity should be free, but only if not done too often (to avoid spamming the chain).

Describe the solution you'd like

1. Make the gas associated with all market messages identical, so that MsgCancelOrder potentially carries same cost as MsgCancelReplaceLimitOrder.
2. New orders that add liquidity should receive a gas rebate proportional to how much of the order was filled already (0% fill means 100% rebate):
   

   em-ledger/x/market/keeper/keeper.go

   Line 334 in 12b0302

   if addToBook {

3. Canceled orders always pay full gas.
4. Replaced orders are only eligible for the gas rebate in 2. if they are replacing an order older than, say, 5 minutes. This requires Add creation timestamp to orders #34 to work.

Additional considerations
It must not be possible to exploit the rebate mechanism in a way where it becomes cheaper (or even free) to remove liquidity, i.e. crafting an order to get almost filled but adding a small amount to the book should not result in a rebate.

It must not be possible to spam the chain with useless transactions. Only behaviour that is net adding liquidity

Describe alternatives you've considered
Further investigation needed here.

[blewater]

potentially MsgAddMarketOrder
@mdyring Could you provide an example when a MsgAddMarketOrder does not add liquidity and should cost gas?

[mdyring]

potentially MsgAddMarketOrder
@mdyring Could you provide an example when a MsgAddMarketOrder does not add liquidity and should cost gas?

Most Market orders will not be adding liquidity as they cross the spread (they trade above the last traded price with a slippage % added)

[blewater]

Due to fixing my incorrect FOK handling (thx @haasted 👍 ), I realized this spec ramification:

• FOK orders always cost the full Gas
• IOC orders never receive the full rebate. May receive partial credit.

[mdyring]

Both FOK and IOC orders are “taker” orders, they never add liquidity. So if IOC with current impl/logic receives rebate something is wrong 🙂

…

Sent from my iPhone On 20 May 2021, at 16.12, Mario Karagiorgas ***@***.***> wrote:  Due to fixing my incorrect FOK handling (thx @haasted 👍 ), I realized this spec ramification: * FOK orders always cost the full Gas * IOC orders never receive the full rebate. May receive partial credit. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#51 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEJSY5NJ3MER2L5QNPATWO3TOUKEXANCNFSM4YYWBTQA> . <https://github.com/notifications/beacon/AEJSY5PNGATWGI7LLTOKVW3TOUKEXA5CNFSM4YYWBTQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGJQB2AY.gif>

[blewater]

ACK

[blewater]

The SDK is still solidifying around related Gas proposals dealing with enhanced centralized gas management.
There's a meaningful mini thread (read the replies) around introducing middleware for post-transaction Gas management: cosmos/cosmos-sdk#9348 (reply in thread).
A GasMeter Refund Api ctx.GasMeter().RefundGas(amount, "") is likely being tested and backported to a future 0.42.x release: cosmos/cosmos-sdk#9403.
Let's allow time and chime-in in the ongoing discussion to bring awareness to our Gas management needs.