Evaluate the IXO bonding curve model as a AMM for the Hub

[zmanian]

https://github.com/ixofoundation/cosmic

SDK module it here

[zmanian]

Updated module
https://github.com/ixofoundation/ixo-blockchain/tree/master/x/bonds

[Hyung-bharvest]

Questions, opinions, and discussion topics about ixo bonds

1. front-running prevention

• does the implementation completely prevent front-running from block producers as now?
• if not, what is the plan? what additional feature is needed for complete prevention? will it be updated by ixo?

2. sorting the orders in one block

• does the block proposer has 100% authority to sort the orders by their incentives?
• are the swap prices impacted by its order of commitment on blockchain?
• don't we have to make it as fair as possible for any sorting of the orders? is it applied in current implementation?
• the current implementation has quite significant disadvantage for later-executed-orders in a block. i think this should be minimized to reduce the power of block proposer by manipulating sortings of the orders
• batch algorithm seems to reduce this concern, but I still think the last block of the batch can be manipulated to get incentivized sorting by block proposer right?

3. extension of swap order type

• i think there should be a swap order type called "passive-swap-order"
• "passive-swap-order" is executed only if there exists enough counterparty swap orders in the block to match the order
• if there exists no residual counterparty swap orders to be matched, the "passive-swap-order" will just be canceled
• matching step : available normal swap orders matched -> available passive swap orders matched -> rest unmatched normal swap orders consumed by liquidity pool -> rest unmatched passive swap orders canceled
• "passive-swap-order" will pay no(or much less) swap fee to the liquidity pool because it temporarily works as a instant liquidity provider to absorb residual swap orders which would consume the liquidity pool if "passive-swap-order" does not exist.
• existence of "passive-swap-order" will make each batch much better balanced without causing unnecessary swap price volatility and liquidity pool consumption
• it also provides users alternative swap type to save fee by willingness to wait for available counterparty orders so that it greatly increase the usability of swap consumers

4. insights on swapper function

• there exists only swapper function with "constant product system".
• do you have any insight which alternative swpper function is better for liquidity pool incentive design?
• which are good candidates?

[migueldingli1997]

Hi @dlguddus

1. front-running prevention

• The implementation makes use of batched order in order to reduce (but not eliminate completely) the front-running potential. The buy (a.k.a bond-to-mint) and sell (a.k.a burn-to-withdraw) prices in a batch of orders are (i) averaged out amongst all buyers and sellers respectively and (ii) matched between buyers and sellers.
• The contents of the batch is of course public and so this can still be used to buyers' and sellers' advantage.
• Front-running can also still take place at a batch-by-batch level (rather than transaction-by-transaction). The number of blocks that a batch is open for however is customisable, so a good measure of prevention is to set this to a higher number, so as to ensure that as many orders as possible make it into the batch, so that there is a reduced chance of front-running.

2. sorting the orders in one block

• Disclaimer: I'm not fully familiar with the level of control that a proposer has when it comes to transaction ordering
• At the application level, the order of orders in batches is based on the order in which the transactions are processed
• General note: in contrast with buys and sells, swaps specifically are (also) included in order batches but no front-running prevention, matching, or extra processing is performed. And so:
  • Buy and sell prices of orders within a single batch are averaged out and thus not impacted by order
  • Swap prices are not averaged out and are in fact impacted by order
• Note that orders at the moment cannot be cancelled once added to a batch.

3. extension of swap order type

• I really like this idea and reasoning.

4. insights on swapper function

• We had selected the constant product system mostly due to its prevalence and relevance
• Another candidate could be something inspired from Kyber

[Hyung-bharvest]

Hi @dlguddus

1. front-running prevention

• The implementation makes use of batched order in order to reduce (but not eliminate completely) the front-running potential. The buy (a.k.a bond-to-mint) and sell (a.k.a burn-to-withdraw) prices in a batch of orders are (i) averaged out amongst all buyers and sellers respectively and (ii) matched between buyers and sellers.
• The contents of the batch is of course public and so this can still be used to buyers' and sellers' advantage.
• Front-running can also still take place at a batch-by-batch level (rather than transaction-by-transaction). The number of blocks that a batch is open for however is customisable, so a good measure of prevention is to set this to a higher number, so as to ensure that as many orders as possible make it into the batch, so that there is a reduced chance of front-running.

1. sorting the orders in one block

• Disclaimer: I'm not fully familiar with the level of control that a proposer has when it comes to transaction ordering

• At the application level, the order of orders in batches is based on the order in which the transactions are processed

• General note: in contrast with buys and sells, swaps specifically are (also) included in order batches but no front-running prevention, matching, or extra processing is performed. And so:

  • Buy and sell prices of orders within a single batch are averaged out and thus not impacted by order
  • Swap prices are not averaged out and are in fact impacted by order

• Note that orders at the moment cannot be cancelled once added to a batch.

1. extension of swap order type

• I really like this idea and reasoning.

1. insights on swapper function

• We had selected the constant product system mostly due to its prevalence and relevance
• Another candidate could be something inspired from Kyber

Thank you so much for your answers! It gives us good general ideas on the implementation.

I hope to ask why the implementation does not assume universal swap price per each batch. The difference of swap prices are caused by transaction ordering which is under complete authority of block proposer so it enhances sorting manipulation risk from proposer.

Another suggestion is that liquidity consumption cost should be only invoiced to "net swap amount" of total swap orders in a block. If we have 5 A token swap to B, and 10 B token swap to A, and if swap rate is 1:1, approximately 5A and 5B can just be swapped each other, hence not consuming any liquidity from the pool. So no reason to punish those with slippage. So the constant product will only be applied to net swap orders which are 5B tokens to A.