Subsidizing Market Liquidity

[CoinHoarder]

I assume the algorithm can take into account a 4th factor - buy/sell order imbalances - to reward market makers more for placing orders on the weak side of the book.  So 4 factors now include:

1. order size
2. time on book
3. proximity to best bid/ask
4. strong/weak side of book

Thoughts about coding this @abit, @xeroc?

The fourth factor seems "gameable". Someone could place a large amount on the opposite position that their order is on, for a small cost (just a cancel order fee,) effectively boosting their portion of the liquidity pool for fairly cheap. To combat this and other issues consider adding the following restrictions:

A. There should be a maximum percentage away from the price feed that someone can qualify for these awards. This ensures that the funds they put on the books will be at risk of market making (which can be profitable and unprofitable). This makes sure they are providing useful liquidity to shareholders. After all, shareholders are paying for the liquidity fund.
B. A minimum amount of time for each user to have orders on the books in each trading pair separately is also necessary to combat this. Requirement A makes sure they are providing useful liquidity, and subject to market making risks.  Requirement B makes sure that they are providing that useful liquidity and subject to market making risks for a reasonable amount of time. It makes sure they are not "farming" the liquidity fund using the method I described above right before the "snapshots" for rewards are taken.

This would need to start with strict restrictions, which shareholders loosen up until a good compromise as to liquidity, spread, and costs is found. All parameters should be able to be easily tweaked.

[xeroc]

Very good analysis. Best if we have some paper describing detailed rules before coding. We need to connect the dots.

Agreed ..

Just put something down in a structured document ..
e.g. the bsip template: https://raw.githubusercontent.com/bitshares/bsips/master/BSIPs-Template.md

[abit]

i would suggest paying these kickbacks on a sliding scale based on length of time on the order books so if someone had a real safe hedge on the books for months that saved us from having a black swan event then he would deserve more than someone who put an order up for 10 min then sold to himself

i like a sliding scale concept, but actually think it should work in the reverse. open orders deep in the order book don't add real liquidity IMO, the action happens on the margin and closing the bid-ask spread is key. if there's going to be any subsidy for liquidity, it would best be spent narrowing spreads. that said, i'm more a fan of fee discounts than kickbacks; rewarding higher frequency trading and/or open orders near the highest bid and lowest ask.

I'm not sure I agree with any rewards based on filled orders (HFT or otherwise) since that's where there's an incentive to do self-trading.  Whereas if we reward based only on placing orders on the books, then there's no incentive to self-trade, only to provide liquidity. 

Beyond that, I agree with larger rewards for open orders closer to best bid and ask.  So we can factor in size of orders placed, time on order book, and proximity to best bid/ask.  We should probably also factor in balance between buy side and sell side, although I imagine at any given time we can skew this more toward either the buy side or the sell side depending on market direction.

good point re: varying incentives on buy/sell sides. from my experience, when prices move quickly being a market maker is a terrible business to be in! when there's skewed demand on either the buy or sell side, it hurts liquidity providers who get stuck with inventory that's rapidly losing value. it'd be interesting to consider subsidization models that support market makers when conditions skew.

I assume the algorithm can take into account a 4th factor - buy/sell order imbalances - to reward market makers more for placing orders on the weak side of the book.  So 4 factors now include:

1. order size
2. time on book
3. proximity to best bid/ask
4. strong/weak side of book

Thoughts about coding this @abit, @xeroc?

Very good analysis. Best if we have some paper describing detailed rules before coding. We need to connect the dots.

[cylonmaker2053]

I assume the algorithm can take into account a 4th factor - buy/sell order imbalances - to reward market makers more for placing orders on the weak side of the book.  So 4 factors now include:

1. order size
2. time on book
3. proximity to best bid/ask
4. strong/weak side of book

Thoughts about coding this @abit, @xeroc?

very well said, i like the four variables.

[tbone]

i would suggest paying these kickbacks on a sliding scale based on length of time on the order books so if someone had a real safe hedge on the books for months that saved us from having a black swan event then he would deserve more than someone who put an order up for 10 min then sold to himself

i like a sliding scale concept, but actually think it should work in the reverse. open orders deep in the order book don't add real liquidity IMO, the action happens on the margin and closing the bid-ask spread is key. if there's going to be any subsidy for liquidity, it would best be spent narrowing spreads. that said, i'm more a fan of fee discounts than kickbacks; rewarding higher frequency trading and/or open orders near the highest bid and lowest ask.

I'm not sure I agree with any rewards based on filled orders (HFT or otherwise) since that's where there's an incentive to do self-trading.  Whereas if we reward based only on placing orders on the books, then there's no incentive to self-trade, only to provide liquidity. 

Beyond that, I agree with larger rewards for open orders closer to best bid and ask.  So we can factor in size of orders placed, time on order book, and proximity to best bid/ask.  We should probably also factor in balance between buy side and sell side, although I imagine at any given time we can skew this more toward either the buy side or the sell side depending on market direction.

good point re: varying incentives on buy/sell sides. from my experience, when prices move quickly being a market maker is a terrible business to be in! when there's skewed demand on either the buy or sell side, it hurts liquidity providers who get stuck with inventory that's rapidly losing value. it'd be interesting to consider subsidization models that support market makers when conditions skew.

I assume the algorithm can take into account a 4th factor - buy/sell order imbalances - to reward market makers more for placing orders on the weak side of the book.  So 4 factors now include:

1. order size
2. time on book
3. proximity to best bid/ask
4. strong/weak side of book

Thoughts about coding this @abit, @xeroc?

[tbone]

@tbone

what about this?

Has anyone worried about "self trading" sat down and attempted to strategize how they would do this in a market with at least two market makers competing for the reward?

Assume a market with a price of 1:1 and a spread of 5% on both sides.

Alice places an order at .95 and must wait 10 minutes before she qualifies for a reward.
After 9 minutes, Bob places his order at .95001. 
Alice is now unable to match herself without buying out Bob first.
Not wanting to let Bob grab the liquidity reward, Alice moves her order to .95002 and the clock resets for 10 more minutes.

This back and forth will continue until the spread is greatly reduced. The narrower the spread, the riskier the market making becomes. Who is going to place a huge wall at the top off the book?

Any rewards paid do not cover 100% of market risks which means market makers will still have to maintain a reasonable spread and there will be MANY orders in front of them.

Go ahead and attempt to name a strategy that works to abuse the rewards in light of market competition.

Lastly assume a 3rd actor, someone who knows market makers are attempting to pump fake volume just to get a reward. This actor will place their orders just in front of the market maker just to collect the spread on the market makers "back and forth" selling.

One problem is that in the early days there very well might only be 1 market maker in a given market, so that's a problem.  Also, multiple market makers may collude rather than competing, so they might stay out of each other's way, hit each other's bids and asks, etc.  So that's another problem.  But we can turn these into non-issues by NOT rewarding people for trading, and instead only rewarding them for providing liquidity i.e. placing orders on the book.   

Obviously we do want trades to occur...but beyond getting orders onto the books to begin with, that means incentivizing takers, NOT makers.  When it comes to incentivizing takers, just having liquidity is a start by itself (no one wants to trade an illiquid market).  But we need to further incentivize takers by giving them more good reasons to be on the DEX to begin with.  @Empirical1.2's yield harvesting idea will help with this by attracting attention and new users and giving current shareholders a very good reason to be on the DEX.   

Being first or early to offer trading of high interest currencies such as LISK will also attract users and attention.   Offering lower trading fees for a trial period could help.  Having stealth (coming soon) will help.  Having a hosted web wallet (coming soon) will help.  Having 2FA (coming soon) will help.  Having real BTC on the DEX (i.e. Bitcoin sidechain) would be a big help.   And marketing our features/benefits would help a lot, too, of course. 

We just need to get going with these things. 

[cylonmaker2053]

i would suggest paying these kickbacks on a sliding scale based on length of time on the order books so if someone had a real safe hedge on the books for months that saved us from having a black swan event then he would deserve more than someone who put an order up for 10 min then sold to himself

i like a sliding scale concept, but actually think it should work in the reverse. open orders deep in the order book don't add real liquidity IMO, the action happens on the margin and closing the bid-ask spread is key. if there's going to be any subsidy for liquidity, it would best be spent narrowing spreads. that said, i'm more a fan of fee discounts than kickbacks; rewarding higher frequency trading and/or open orders near the highest bid and lowest ask.

I'm not sure I agree with any rewards based on filled orders (HFT or otherwise) since that's where there's an incentive to do self-trading.  Whereas if we reward based only on placing orders on the books, then there's no incentive to self-trade, only to provide liquidity. 

Beyond that, I agree with larger rewards for open orders closer to best bid and ask.  So we can factor in size of orders placed, time on order book, and proximity to best bid/ask.  We should probably also factor in balance between buy side and sell side, although I imagine at any given time we can skew this more toward either the buy side or the sell side depending on market direction.

good point re: varying incentives on buy/sell sides. from my experience, when prices move quickly being a market maker is a terrible business to be in! when there's skewed demand on either the buy or sell side, it hurts liquidity providers who get stuck with inventory that's rapidly losing value. it'd be interesting to consider subsidization models that support market makers when conditions skew.

[chryspano]

@tbone

what about this?

Has anyone worried about "self trading" sat down and attempted to strategize how they would do this in a market with at least two market makers competing for the reward?

Assume a market with a price of 1:1 and a spread of 5% on both sides.

Alice places an order at .95 and must wait 10 minutes before she qualifies for a reward.
After 9 minutes, Bob places his order at .95001. 
Alice is now unable to match herself without buying out Bob first.
Not wanting to let Bob grab the liquidity reward, Alice moves her order to .95002 and the clock resets for 10 more minutes.

This back and forth will continue until the spread is greatly reduced. The narrower the spread, the riskier the market making becomes. Who is going to place a huge wall at the top off the book?

Any rewards paid do not cover 100% of market risks which means market makers will still have to maintain a reasonable spread and there will be MANY orders in front of them.

Go ahead and attempt to name a strategy that works to abuse the rewards in light of market competition.

Lastly assume a 3rd actor, someone who knows market makers are attempting to pump fake volume just to get a reward. This actor will place their orders just in front of the market maker just to collect the spread on the market makers "back and forth" selling.

[tbone]

i would suggest paying these kickbacks on a sliding scale based on length of time on the order books so if someone had a real safe hedge on the books for months that saved us from having a black swan event then he would deserve more than someone who put an order up for 10 min then sold to himself

i like a sliding scale concept, but actually think it should work in the reverse. open orders deep in the order book don't add real liquidity IMO, the action happens on the margin and closing the bid-ask spread is key. if there's going to be any subsidy for liquidity, it would best be spent narrowing spreads. that said, i'm more a fan of fee discounts than kickbacks; rewarding higher frequency trading and/or open orders near the highest bid and lowest ask.

I'm not sure I agree with any rewards based on filled orders (HFT or otherwise) since that's where there's an incentive to do self-trading.  Whereas if we reward based only on placing orders on the books, then there's no incentive to self-trade, only to provide liquidity. 

Beyond that, I agree with larger rewards for open orders closer to best bid and ask.  So we can factor in size of orders placed, time on order book, and proximity to best bid/ask.  We should probably also factor in balance between buy side and sell side, although I imagine at any given time we can skew this more toward either the buy side or the sell side depending on market direction. 

[tbone]

We just need to boost bitUSD first, THEN boost OTHER_ASSET:bitUSD pairs, but not make all kinds of xyz:bts pairs as these are much less attractive for non-crypto users. Just like what tonyk has proposed. If we don't already have a stable currency, trading on other commodities is nightmare.

I still disagree that bitUSD is Bitshare's savior. Bitshares could easily go after currently untapped markets of an unlimited amount of derivatives. Whether it be gold, silver, oil, GOOG, AAPL, NASDAQ, etc... That market is untapped in the cryptosphere right now. A year from now this market will be competitive due to all of the blockchain's with scripting capabilities. This market is Bitshares' for the taking right now, but a year or so from now who knows. Bitshares needs to be known by its primary original innovation... Bitassets.

bitUSD is important, but the actual innovation is BitAssets as a whole. I understand that by subsidizing liquidity on bitUSD, the liquidity somewhat trickles down to other bitAssets. However, I think you overestimate just how much it will effect those markets. Bitshares should be securing markets that are easily secured, and the bitUSD market already has several competitors.

If dilution was ever necessary, it is for a proposal such as this. It greatly improves already existing features... one of Bitshare's core features. Adding hundreds of features will not make Bitshares automatically succeed. Look at NXT and Bitshares as-is for this proof. The features need to be implemented sufficiently. Smartcoins are not sufficient as they currently exist. The market has been telling Bitshares that for two years now.

This proposal is perfect in that worker proposals need to keep being approved to continue liquidity efforts. The dilution to fund this feature is not forced on shareholders for the rest of eternity. Try it out- shareholders have little to lose as a whole, but so much more to gain. If it doesn't work then shareholders can stop approving workers for these purposes. Alternatively, if it does work, as markets gain a sufficient amount of liquidity we can cut back on the liquidity incentives market-by-market.

Either way, the dilution for trying this proposal is not permanent... whether shareholder decide to stop dilution for incentive to those who provide liquidity or the proposal is successful and dilution is stopped anyways. It is truly a win-win for a small price to pay for 1 worker. If it doesn't work then we never have to try it again and a lesson would have been learned.

Sidechains are not the answer. Prediction Markets are not the answer. A Bond Market is not the answer. Liquidity on our already existing DEX is the answer. Bitshares' original killer app Bitassets finally approaching the countdown to blast off is the answer.

You make some good points.  I agree that we should not limit the pairs and that BitAssets are our primary differentiator (along with the DEX itself, of course).  I think ultimately we should subsidize liquidity for many BitAssets.  But since our funds are limited, I'm sure you'll agree that we need to be systematic about it.  What do you think about starting with subsidizing liquidity for BitUSD, BitCNY, and BitEUR?  As the markets for these primary fiat BitAssets become more robust and can stand on their own, we can start moving the liquidity incentives to other BitAssets, perhaps starting with GOLD, SILVER and OIL.  Then maybe GOOG, AAPL, NASDAQ, or whatever people are most interested in. 

To be clear, I'm not talking about limiting these pairs initially and then bringing them on as we go.  They exist now and should continue to exist for people to trade as they please.  I'm just talking about prioritizing our liquidity subsidies to have a real impact rather than spreading the efforts too thinly and ultimately having little/no impact at all. 

I also agree that right now bootstrapping liquidity on the DEX should be a HUGE priority over adding features like the bond and prediction markets.  However, I think sidechains are a different story.  I don't see sidechains as a feature per se, but more structural in nature, facilitating liquidity by opening the bitcoin floodgates.  Just imagine the vast number of bitcoin holders being able to transfer their BTC onto the DEX and then trade in and out of our various fiat, commodity, and stock market BitAssets.  The liquidity will be incredible and I believe that will seal the deal for us as THE financial blockchain.

[CoinHoarder]

We just need to boost bitUSD first, THEN boost OTHER_ASSET:bitUSD pairs, but not make all kinds of xyz:bts pairs as these are much less attractive for non-crypto users. Just like what tonyk has proposed. If we don't already have a stable currency, trading on other commodities is nightmare.

I still disagree that bitUSD is Bitshare's savior. Bitshares could easily go after currently untapped markets of an unlimited amount of derivatives. Whether it be gold, silver, oil, GOOG, AAPL, NASDAQ, etc... That market is untapped in the cryptosphere right now. A year from now this market will be competitive due to all of the blockchain's with scripting capabilities. This market is Bitshares' for the taking right now, but a year or so from now who knows. Bitshares needs to be known by its primary original innovation... Bitassets.

bitUSD is important, but the actual innovation is BitAssets as a whole. I understand that by subsidizing liquidity on bitUSD, the liquidity somewhat trickles down to other bitAssets. However, I think you overestimate just how much it will effect those markets. Bitshares should be securing markets that are easily secured, and the bitUSD market already has several competitors.

If dilution was ever necessary, it is for a proposal such as this. It greatly improves already existing features... one of Bitshare's core features. Adding hundreds of features will not make Bitshares automatically succeed. Look at NXT and Bitshares as-is for this proof. The features need to be implemented sufficiently. Smartcoins are not sufficient as they currently exist. The market has been telling Bitshares that for two years now.

This proposal is perfect in that worker proposals need to keep being approved to continue liquidity efforts. The dilution to fund this feature is not forced on shareholders for the rest of eternity. Try it out- shareholders have little to lose as a whole, but so much more to gain. If it doesn't work then shareholders can stop approving workers for these purposes. Alternatively, if it does work, as markets gain a sufficient amount of liquidity we can cut back on the liquidity incentives market-by-market.

Either way, the dilution for trying this proposal is not permanent... whether shareholder decide to stop dilution for incentive to those who provide liquidity or the proposal is successful and dilution is stopped anyways. It is truly a win-win for a small price to pay for 1 worker. If it doesn't work then we never have to try it again and a lesson would have been learned.

Sidechains are not the answer. Prediction Markets are not the answer. A Bond Market is not the answer. Liquidity on our already existing DEX is the answer. Bitshares' original killer app Bitassets finally approaching the countdown to blast off is the answer.

[abit]

I think I've underestimated the difficulty and/or workload of off-chain data analysis. Current data fetching APIs are not friendly enough to do the analysis work. If it's me to implement this, I may write a plugin of witness_node first to output more data.

I have always thought the process of implementing this off-chain would be the same as on-chain.  The only difference is a single loop that iterates over those that need a payout and pays them. All other tracking would have to be implemented in a way that could be used by the consensus process directly.

The primary benefit to doing it off chain is not forcing everyone to upgrade.

@bytemaster will CNX provide a set of new APIs (for tracking required data) free of charge? It doesn't need a hard fork imo.

[giant middle finger]

Are you kidding us?!

This is BitShares!

We look forward to upgrades!

[bytemaster]

I think I've underestimated the difficulty and/or workload of off-chain data analysis. Current data fetching APIs are not friendly enough to do the analysis work. If it's me to implement this, I may write a plugin of witness_node first to output more data.

I have always thought the process of implementing this off-chain would be the same as on-chain.  The only difference is a single loop that iterates over those that need a payout and pays them. All other tracking would have to be implemented in a way that could be used by the consensus process directly.

The primary benefit to doing it off chain is not forcing everyone to upgrade. 

[chono]

I think I've underestimated the difficulty and/or workload of off-chain data analysis. Current data fetching APIs are not friendly enough to do the analysis work. If it's me to implement this, I may write a plugin of witness_node first to output more data.