Author Topic: Efficient Internal Market Making, System Order Routing [ Idea ]  (Read 2983 times)

0 Members and 1 Guest are viewing this topic.

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
Auto routing isn't even going to be really relevant until we have more liquidity and tighter spreads, I think.  At that point we could have either auto routing, or people will probably write arb bots.

Assuming we have blockchain based autorouting, how could an arb bot beat that? Surely an atomic operation is the most efficient way to go across 2 markets?

Once autorouting BitUSD:BTS -> BitBTC:BTS adds to the orderbook of BitUSD:BitBTC, the spreads should tighten when people start to use that market directly.

An arb bot could not beat autorouting, what I meant is that the auto-routing is unlikely to actually happen even if it was in place unless liquidity is high, and spreads are low.  If liquidity gets that high while autorouting support has not been added, the incentive will be there to operate arb bots which could perform almost (though not quite) as well as auto-routing.

Offline speedy

  • Hero Member
  • *****
  • Posts: 1160
    • View Profile
  • BitShares: speedy
Auto routing isn't even going to be really relevant until we have more liquidity and tighter spreads, I think.  At that point we could have either auto routing, or people will probably write arb bots.

Assuming we have blockchain based autorouting, how could an arb bot beat that? Surely an atomic operation is the most efficient way to go across 2 markets?

Once autorouting BitUSD:BTS -> BitBTC:BTS adds to the orderbook of BitUSD:BitBTC, the spreads should tighten when people start to use that market directly.

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
Auto routing isn't even going to be really relevant until we have more liquidity and tighter spreads, I think.  At that point we could have either auto routing, or people will probably write arb bots.

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
No, this is not a client side feature, because you are not guaranteed both orders will execute as an atomic operation at the same time, and on top of that you will create more overhead on the blockchain, than is needed.
it is possible to get multiple buy/sell orders into one block though ..
I don't see an additional transaction for auto bridging coming any time soon ..

Given that right now the engine doesn't even match regular buys and sells correctly, I would be nervous building a client side tool, which relies on the engine being right. You will end up with a split order, guaranteed.

Even if you include the two orders in the same block, someone else may have beaten you to ONE of the orders, so it will get dropped. Like I said - it's not an atomic operation.

Offline speedy

  • Hero Member
  • *****
  • Posts: 1160
    • View Profile
  • BitShares: speedy
Whether this has to be done client-side or built into the blockchain, autobridging would add so much liquidity to the exchange. +5%

Are the devs thinking about doing it?

Offline sudo

  • Hero Member
  • *****
  • Posts: 2255
    • View Profile
  • BitShares: ags

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
No, this is not a client side feature, because you are not guaranteed both orders will execute as an atomic operation at the same time, and on top of that you will create more overhead on the blockchain, than is needed.
it is possible to get multiple buy/sell orders into one block though ..
I don't see an additional transaction for auto bridging coming any time soon ..

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
No, this is not a client side feature, because you are not guaranteed both orders will execute as an atomic operation at the same time, and on top of that you will create more overhead on the blockchain, than is needed.

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Isn't this a "client-side feature'? with 10 secs transaction confirmation you can do triangle trading within 20 secs helping with arbitrage ..

+1 We shouldn't make the internal market engine more complicated than necessary.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Isn't this a "client-side feature'? with 10 secs transaction confirmation you can do triangle trading within 20 secs helping with arbitrage ..
maybe this should be a feature of the web/qt client .. (with some support from the core client)

@jcalfee: would this be possible if the client had a call to get liquid markets sorted by volume?

Offline mf-tzo

  • Hero Member
  • *****
  • Posts: 1725
    • View Profile
Autobridging like ripple obviously is a great idea. I am not sure though how this plays when you have to consider shorting the bitasset with BTS collateral. My brain doesn't go that far but if something like that was to be implemented please consider well if this will affect short orders. We don't want to create more unfavorable situations for shorts than already existing.

Xeldal

  • Guest
If I understood your post correctly, it sounds like you want something similar to Ripple's Offer Autobridging.

Yes, from what I've read so far that seems to be spot on what I was suggesting.  Thanks for the link.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
If I understood your post correctly, it sounds like you want something similar to Ripple's Offer Autobridging.

Xeldal

  • Guest
Rather than making every market separately, what I would like to see is an internal market mechanism that intelligently routes and issues system bids and asks representing these routes in every relevant market. 

If I were, as a market maker, to make the bBTC:bUSD market, my order to buy bBTC and sell bUSD, should also show up in all other bBTC and bUSD pairs.  Internally it would know all other routes and an exact cost for that route and would list these routes as bids and asks in every related market. 

The bid wants to buy bBTC it doesn't care where it comes from
The bid wants to sell bUSD, it doesn't care where it goes

If internally there is at least 1 bid or ask in other relevant markets the price to route it through these markets could be displayed.

For example,  the MARKET would list the above bid in normal form on the bBTC:bUSD market, in addition it lists a linked system bid on the bBTC:bBTS w/ a linked system bid on bBTS:bUSD based on what it would cost from those markets to use this alternate route.  If a market doesn't have any existing bids or asks then the system route would not exist and would not be listed.

so bBTC:bUSD market might look like this:
Bids-----------------|--------------Asks
250                      |                  260
249 <routeBTS>|                  261<routeCNY>
245<routeCNY>|                  262<routeGold>

The routes are just taking orders from the two respective markets into account. 
For <routeBTS> its taking from bBTS:bBTC and bBTS:bUSD
For <routeCNY> its taking from bCNY:bBTC and bCNY:bUSD
For <routeGold> its taking from bGold:bBTC and bGold:bUSD
etc.

The benefit of this is that every effort to make an internal market is magnified across every market.  The routed bids and asks wouldn't always offer the best prices in an active market but it would greatly benefit liquidity in lower volume markets.  I don't think it would be necessary to go beyond 1 hop as the spread would quickly add up as would the processing time and possible routes.

This would be difficult and very expensive to do as a user to replicate this function from the outside.  I would guess that the MARKET could do it for free.

Obviously this adds a lot of overhead to an already sluggish market response time.

It may not be feasible either, just thought I'd throw it out there.