Comments/issues from a market maker (Linq)

[mfinestone]

Hi team. The below is from Linq, a professional MM on our exchange, and builder of our hummingbot connector. They have started deploying liquidity and trading on Loopring via API, and had the following to say. Please let me know your thoughts and what I should tell them.

Here is the written version of the technical issues we've found while deploying our market making against loopring:

• We receive a "Cancel order returned code 100001 (order in status SUBMIT_WAIT_ACCEPT can't be in canceling progress)", with status code 100001, when attempting to cancel orders that have not yet been accepted. This makes our risk more difficult, and ideally the cancel should be executed against the given order in all cases, unless the order has been filled.

• The requirement for the user to manage the orderId field when submitting an order makes running multiple independent strategies that have any shared asset difficult. This is because there are restrictions on what the orderId must be to be valid (within a tight range from the last id of the last submitted order). For race-condition reasons, this can be difficult to manage on the users end, and requiring a second api round trip request to /api/v2/orderId before submitting an order would slow order placement significantly (and might still fail for race-condition reasons with multiple independent bots on one account). Considering that the api returns the next valid id /api/v2/orderId, it seems that this responsibility could be handled by the loopring backend, where the id would be set to the next available id at the point of submission. Unsure if there are other reasons for this(protocol based or other backend technical reasons), but there seems to be a check on the orderId to check its validity at the time of order submission, so it seems that the backend should have that id number at the moment it would need to insert it if the user wasn't required to send it.

• Looser rate limits for partners like us would be very helpful. We'll need to split our bots that are on different markets across different accounts to try and avoid these limits, as we may be placing 10+ levels worth of order per market, that would potentially need to be re-priced quickly as the overall markets move.

[dong77]

2, the order ID must be signed by users, it cannot be assigned on the backend.

@hosschao can you address #1 and #2?

[mfinestone]

Comment in response to Daniel's statement on # 2:

I see, thanks for getting back to us with that. I can imagine that that's because the user has to sign that sequence number for protocol reasons so that his orders are guaranteed to be placed in the order he agreed for them to be issued.. That's unfortunate, but I can understand the reasoning and we can work around that.

Perhaps one possible improvement that would make working with that much easier is if the check on order submission was only that the orderId is greater than any previously submitted orderId for that token. Right now, I believe it's quite strict that the orderId must be the very next number in the sequence (or perhaps there was a little leeway there, but it didn't seem like much). That might not be allowed for other protocol reasons I'm not aware of though (perhaps it's kept strict to guarantee that there are no missed orders in between submissions, etc.), but if it was possible, that would make multiple independent bots more manageable.

[mfinestone]

Ok Brecht had a good answer for them 👍

The orderID is used as the slot the protocol uses to store how much the order is filled. So it's important this is some fixed value approved by the user himself, otherwise someone could just let the order use a different slot and fill the order multiple times.

The strict increase in orderID is done for efficiency reasons and to also allow sequential orders (though I guess not really that useful in most cases).

It should be possible I think to divide the number of parallel orderIDs you can use between the different bots. In total there are 2^14 slots you can use at a time. If you divide those slots between your different bots would that make your life easier? So for example, bot 0 only uses slots [0, 1000] and bot 1 only uses slots [1000, 2000] or something like that. And you then overwrite those slots with bigger values as necessary, but this won't affect any of your other bots.

They said: Thanks for the insight Brecht. Yep, that would solve the problem for sure

[lyddream]

@mfinestone

1 We have developed an optimized plan for this situation, and this situation will almost never happen again.

3 please provide us with their ip address, we will config looser rate limits

[mfinestone]

@lyddream

IP address: 95.216.72.15

They may give us one more soon. Thanks.