Add the ability to update an existing order to provide more liquidity - #19
Add the ability to update an existing order to provide more liquidity#19kahuang wants to merge 1 commit into
Conversation
|
Fixes #16 |
| require(amountSats < 0 && uint256(int256(-(o.amountSats + amountSats))) <= MAX_SATS, "Must be adding a valid amount of liquidity"); | ||
|
|
||
| uint256 additionalValue = uint256(int256(-amountSats * int128(o.priceTokPerSat))); | ||
| o.amountSats += amountSats; |
|
|
||
| if (o.amountSats < 0) { | ||
| // This is an ask. Receive the ether to be sold and update the order. | ||
| require(amountSats < 0 && uint256(int256(-(o.amountSats + amountSats))) <= MAX_SATS, "Must be adding a valid amount of liquidity"); |
There was a problem hiding this comment.
I'd calculate the new amount o.amountSats + amountSats first.
Gotta check that it's still negative, otherwise this function lets a user convert a bid into an ask.
There was a problem hiding this comment.
If 0.amountSats and amountSats are the same sign, is that something we have to worry about?
Maybe in the overflow case, but since we're on solidity 0.8+ that's checked automatically AFAIK
There was a problem hiding this comment.
I see--so the goal is to only let people add liquidity?
Then, for an existing order, you can increase the size via updateOrder, but if you want to decrease the size or change the price, you have to cancel + place a new order.
LMK if I understood it right
|
|
||
| // Receive the additional stake | ||
| _transferFromSender(expectedStakeTok); | ||
| } |
There was a problem hiding this comment.
I wonder if this is worth the complexity.
The API, as it stands, is a big gnarly:
- For a bid, passing positive
amountSatsincreases the size of your bid - For an ask, passing positive
amountSatsdecreases the size of your ask
In either case, we'd have to add a check to ensure bids are not turning into asks or vice versa.
I'm down to revisit later once we have testnet MMs. If it turns out that modifying bid size is a common need, we ship this.
My guess is that at least initially, immutable orders (that can only be cancelled and recreated) might be good enough.
There was a problem hiding this comment.
Ah I should probably have added more clarity:
This only lets you add additional liquidity, not remove it. The removing liquidity case strikes me as less likely, and therefore ok to go through the: cancel order -> place order flow.
There was a problem hiding this comment.
The adding liquidity case I think will be common. Lets take a WBTC <-> BTC portal where the spreads are tight and non-volatile. MM can have large liquidity, and most orders won't take the whole order from the consumer side. Being able to in place update your order to add additional liquidity strikes me as easier to manage than needing to place a separate order, which would then also fragment liquidity and make it harder to match orders.
There was a problem hiding this comment.
That being said, I don't think it'd be too hard to add later so we can punt on this for now
2 participants
No description provided.