Subsidizing Market Liquidity

Started by bytemaster, February 19, 2016, 09:04:16 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

abit

Quote from: xeroc on February 24, 2016, 08:00:08 AM
Quote from: tonyk on February 23, 2016, 07:25:07 PM
All numbers/percent are parameters adjustable by the committee (for the bitAssets).

To qualify for the reward (calculated and paid  every 7 days).
1.An account must have the best bid (or ask) for min 5% of the time.[combined for all qualified orders of his during those 7 days]
To qualify:
2.A sell order should be no more than 6% above the peg; a buy order should be no more than 1% from the peg price.
3. The order should be the best bid or ask. (1)
4.The order should be for min of 150 bitUSD [it can be bigger but if the order is  for bigger amount, credit is given for max of 150 biUSD] (2)

Every 7 day the script is run and the funds are divided between accounts having placed qualified MM orders:
- proportional to the time the orders were on the order book and met all other criteria above.
- for the full 150 bitUSD and/or following rule (2)

(1)Orders (say N=10 times) N times smaller than the market maker's order at better prices do not violate the best bid/ask condition.
(2.)The MM in regular stock market place both bid and ask orders to qualify; if we want to give the reward for just a single side we have to weight the order toward the other side of the order book, or some other way. Say MM1 places just a buy order - it is given credit only for the sum of sell orders falling within the max spread (5% spread max in the example above)


Quote

Nasdaq is incentivizing the display of orders for (a) 500 shares at the best bid and 500 shares at the best offer, 30% of the time, and (b) 2500 shares at no wider than 2% of the best bid and 2500 shares at no wider than 2% of the best offer, 90% of the time.  I don't think we need to specify a minimum number of shares or what % of the time they need to satisfy the above conditions, but perhaps we could simply make the reward proportional to the length of time MMs have orders on the books, the size of the orders, and the distance from the price feed.  And maybe we should require that orders be on the book for a minimum period of time, as some have already suggested. 



Thanks for the details explanation. Most of it makes very much sense and could certainly be implemented by the committe-account or committee-trade or any other BTS owned account.
The only thing that I do not fully agree with is that you have two different percentages for placed orders to qualify on the bid and ask side but do understand the reasons for it.
I'd rather combine this with a settlement offset of 2% (or half of whatever the spread has been over the last 2 months) and see orders be placed symmetrically arround the peg .. But I guess that makes things a little more complicated for many traders.

Also, the implementation is quite involved as a script needs to track every order creation time and termination (cancel or fill) time which is not easy to do currently.
We'd need some more development in the backend (specific API calls). Once we have that, we could do this relatively quickly I guess.
How could this be funded is a totally different thing though.
I think we need help from @roadscape , since the block explorer knows the data best.
The reason of my suggestion about off-chain analysis is that CNX has limited man power, we'd better do more by ourselves but not all rely on CNX (to add API etc).
BitShares committee member: abit
BitShares witness: in.abit

xeroc

Quote from: tonyk on February 23, 2016, 07:25:07 PM
All numbers/percent are parameters adjustable by the committee (for the bitAssets).

To qualify for the reward (calculated and paid  every 7 days).
1.An account must have the best bid (or ask) for min 5% of the time.[combined for all qualified orders of his during those 7 days]
To qualify:
2.A sell order should be no more than 6% above the peg; a buy order should be no more than 1% from the peg price.
3. The order should be the best bid or ask. (1)
4.The order should be for min of 150 bitUSD [it can be bigger but if the order is  for bigger amount, credit is given for max of 150 biUSD] (2)

Every 7 day the script is run and the funds are divided between accounts having placed qualified MM orders:
- proportional to the time the orders were on the order book and met all other criteria above.
- for the full 150 bitUSD and/or following rule (2)

(1)Orders (say N=10 times) N times smaller than the market maker's order at better prices do not violate the best bid/ask condition.
(2.)The MM in regular stock market place both bid and ask orders to qualify; if we want to give the reward for just a single side we have to weight the order toward the other side of the order book, or some other way. Say MM1 places just a buy order - it is given credit only for the sum of sell orders falling within the max spread (5% spread max in the example above)


Quote

Nasdaq is incentivizing the display of orders for (a) 500 shares at the best bid and 500 shares at the best offer, 30% of the time, and (b) 2500 shares at no wider than 2% of the best bid and 2500 shares at no wider than 2% of the best offer, 90% of the time.  I don't think we need to specify a minimum number of shares or what % of the time they need to satisfy the above conditions, but perhaps we could simply make the reward proportional to the length of time MMs have orders on the books, the size of the orders, and the distance from the price feed.  And maybe we should require that orders be on the book for a minimum period of time, as some have already suggested. 



Thanks for the details explanation. Most of it makes very much sense and could certainly be implemented by the committe-account or committee-trade or any other BTS owned account.
The only thing that I do not fully agree with is that you have two different percentages for placed orders to qualify on the bid and ask side but do understand the reasons for it.
I'd rather combine this with a settlement offset of 2% (or half of whatever the spread has been over the last 2 months) and see orders be placed symmetrically arround the peg .. But I guess that makes things a little more complicated for many traders.

Also, the implementation is quite involved as a script needs to track every order creation time and termination (cancel or fill) time which is not easy to do currently.
We'd need some more development in the backend (specific API calls). Once we have that, we could do this relatively quickly I guess.
How could this be funded is a totally different thing though.

tbone

Quote from: abit on February 23, 2016, 08:08:23 PM
Quote from: tbone on February 23, 2016, 01:03:05 PM
Quote from: abit on February 23, 2016, 12:36:56 PM
Quote from: tbone on February 23, 2016, 12:18:00 PM
Quote from: abit on February 22, 2016, 04:49:33 PM
I think the reward program doesn't have to be built INTO the system. Since all trading data is on the chain, any asset issuer is able to analysis the data, then make their own decisions on HOW to reward market makers on her markets. Off-chain data analysis is usually better than on-chain analysis, more flexible, easier to adjust, more cheating

That sounds fine for UIAs, but what about BitAssets?  Although there should be mechanisms in place for UIA issuers to incentivize liquidity in their own markets, the main thrust of this conversation has been about incentivizing BitAsset liquidity in particular.
Why quote only a part of my message and come to a question which I've already answered (in the text you haven't quoted)?

For brevity I quoted the part indicating you were referring to UIAs.  You did not refer to BitAssets in the part of the quote I left out.  What am I missing?
BitAssets.. can be done by the committee.

Ok, I see.  Thanks.

abit

Quote from: tbone on February 23, 2016, 01:03:05 PM
Quote from: abit on February 23, 2016, 12:36:56 PM
Quote from: tbone on February 23, 2016, 12:18:00 PM
Quote from: abit on February 22, 2016, 04:49:33 PM
I think the reward program doesn't have to be built INTO the system. Since all trading data is on the chain, any asset issuer is able to analysis the data, then make their own decisions on HOW to reward market makers on her markets. Off-chain data analysis is usually better than on-chain analysis, more flexible, easier to adjust, more cheating

That sounds fine for UIAs, but what about BitAssets?  Although there should be mechanisms in place for UIA issuers to incentivize liquidity in their own markets, the main thrust of this conversation has been about incentivizing BitAsset liquidity in particular.
Why quote only a part of my message and come to a question which I've already answered (in the text you haven't quoted)?

For brevity I quoted the part indicating you were referring to UIAs.  You did not refer to BitAssets in the part of the quote I left out.  What am I missing?
BitAssets.. can be done by the committee.
BitShares committee member: abit
BitShares witness: in.abit

tonyk

#116
Quote from: xeroc on February 23, 2016, 11:47:26 AM
Quote from: tonyk on February 22, 2016, 06:34:22 PM
How about the rules?
[]
I don't full understand these rules (haven't read the whole thread)1.I would maybe add - orders (say N=10 times) N times smaller than the market maker's order at better prices do not violate the best bid/ask condition.
2. The MM in those market place both bid and ask orders to qualify; if we want to give the reward for just a single side we have to weight the order toward the other side of the order book, or some other way. Say MM1 places just a buy order - it is given credit only for the sum of sell orders falling within the min spread (say 5% spread max)

So you propose that there are $X available to be distributed to liquidity providers for each market and I pay a fraction of them every 10minutes to those that have orders close to the "peg" if the orders have been open for more than 10 minutes ..
is that about correct?

All numbers/percent are parameters adjustable by the committee (for the bitAssets).

To qualify for the reward (calculated and paid  every 7 days).
1.An account must have the best bid (or ask) for min 5% of the time.[combined for all qualified orders of his during those 7 days]
To qualify:
2.A sell order should be no more than 6% above the peg; a buy order should be no more than 1% from the peg price.
3. The order should be the best bid or ask. (1)
4.The order should be for min of 150 bitUSD [it can be bigger but if the order is  for bigger amount, credit is given for max of 150 biUSD] (2)

Every 7 day the script is run and the funds are divided between accounts having placed qualified MM orders:
- proportional to the time the orders were on the order book and met all other criteria above.
- for the full 150 bitUSD and/or following rule (2)

(1)Orders (say N=10 times) N times smaller than the market maker's order at better prices do not violate the best bid/ask condition.
(2.)The MM in regular stock market place both bid and ask orders to qualify; if we want to give the reward for just a single side we have to weight the order toward the other side of the order book, or some other way. Say MM1 places just a buy order - it is given credit only for the sum of sell orders falling within the max spread (5% spread max in the example above)


Quote

Nasdaq is incentivizing the display of orders for (a) 500 shares at the best bid and 500 shares at the best offer, 30% of the time, and (b) 2500 shares at no wider than 2% of the best bid and 2500 shares at no wider than 2% of the best offer, 90% of the time.  I don't think we need to specify a minimum number of shares or what % of the time they need to satisfy the above conditions, but perhaps we could simply make the reward proportional to the length of time MMs have orders on the books, the size of the orders, and the distance from the price feed.  And maybe we should require that orders be on the book for a minimum period of time, as some have already suggested. 


Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

morpheus

This is an excellent idea.

This trend has been developing for quite some time in the industry now  - rewarding network resource providers in a P2P fashion.  Auger REP holders will be rewarded by reporting results.  Maidsafe will reward those who provide storage space.  Now, bitshares will reward those who provide liquidity.  This should increase demand for bts as more MM will want to take advantage of the subsidy.

puppies

To me a large part of our liquidity issue seems to be caused by a lack of incentives for shorters. 

Wouldn't adding yield to bitassets just increase the premium that they sell for?

I'd rather add yield to short positions.  I don't think it would work if you applied yield to all borrow positions.  The yield should only kick in after you sell the bitasset on the market and are actually short.  Then the yield should end when you purchase back the asset.  Transferring the asset would provide no yield.  There would be the risk that people would be able to sell the bitasset to another account they control, but even with this risk I think it would increase the amount of bitassets for sale, thus reducing the price, and helping the peg. 

Is there something I am missing?
[url="https://metaexchange.info"]https://metaexchange.info[/url] | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

tbone

Quote from: abit on February 23, 2016, 12:36:56 PM
Quote from: tbone on February 23, 2016, 12:18:00 PM
Quote from: abit on February 22, 2016, 04:49:33 PM
I think the reward program doesn't have to be built INTO the system. Since all trading data is on the chain, any asset issuer is able to analysis the data, then make their own decisions on HOW to reward market makers on her markets. Off-chain data analysis is usually better than on-chain analysis, more flexible, easier to adjust, more cheating

That sounds fine for UIAs, but what about BitAssets?  Although there should be mechanisms in place for UIA issuers to incentivize liquidity in their own markets, the main thrust of this conversation has been about incentivizing BitAsset liquidity in particular.
Why quote only a part of my message and come to a question which I've already answered (in the text you haven't quoted)?

For brevity I quoted the part indicating you were referring to UIAs.  You did not refer to BitAssets in the part of the quote I left out.  What am I missing?

abit

Quote from: tbone on February 23, 2016, 12:18:00 PM
Quote from: abit on February 22, 2016, 04:49:33 PM
I think the reward program doesn't have to be built INTO the system. Since all trading data is on the chain, any asset issuer is able to analysis the data, then make their own decisions on HOW to reward market makers on her markets. Off-chain data analysis is usually better than on-chain analysis, more flexible, easier to adjust, more cheating

That sounds fine for UIAs, but what about BitAssets?  Although there should be mechanisms in place for UIA issuers to incentivize liquidity in their own markets, the main thrust of this conversation has been about incentivizing BitAsset liquidity in particular.
Why quote only a part of my message and come to a question which I've already answered (in the text you haven't quoted)?
BitShares committee member: abit
BitShares witness: in.abit

tbone

Quote from: abit on February 22, 2016, 04:49:33 PM
I think the reward program doesn't have to be built INTO the system. Since all trading data is on the chain, any asset issuer is able to analysis the data, then make their own decisions on HOW to reward market makers on her markets. Off-chain data analysis is usually better than on-chain analysis, more flexible, easier to adjust, more cheating

That sounds fine for UIAs, but what about BitAssets?  Although there should be mechanisms in place for UIA issuers to incentivize liquidity in their own markets, the main thrust of this conversation has been about incentivizing BitAsset liquidity in particular. 

xeroc

Quote from: tonyk on February 22, 2016, 06:34:22 PM
How about the rules?
[1.I would maybe add - orders (say N=10 times) N times smaller than the market maker's order at better prices do not violate the best bid/ask condition.
2. The MM in those market place both bid and ask orders to qualify; if we want to give the reward for just a single side we have to weight the order toward the other side of the order book, or some other way. Say MM1 places just a buy order - it is given credit only for the sum of sell orders falling within the min spread (say 5% spread max)
]
I don't full understand these rules (haven't read the whole thread)
So you propose that there are $X available to be distributed to liquidity providers for each market and I pay a fraction of them every 10minutes to those that have orders close to the "peg" if the orders have been open for more than 10 minutes ..
is that about correct?

chono

Quote from: tonyk on February 22, 2016, 06:34:22 PM
Quote from: bytemaster on February 22, 2016, 06:22:35 PM
I agree that off-chain distribution makes a lot of sense.

How about the rules?
[1.I would maybe add - orders (say N=10 times) N times smaller than the market maker's order at better prices do not violate the best bid/ask condition.
2. The MM in those market place both bid and ask orders to qualify; if we want to give the reward for just a single side we have to weight the order toward the other side of the order book, or some other way. Say MM1 places just a buy order - it is given credit only for the sum of sell orders falling within the min spread (say 5% spread max)
]

If yes, Xeroc can write the script in no time, I believe.
wow,if the rules touch ground,can be implemented in no time.Bravo
Weibo:Will_BTS

tonyk

#108
Quote from: bytemaster on February 22, 2016, 06:22:35 PM
I agree that off-chain distribution makes a lot of sense.

How about the rules?
[1.I would maybe add - orders (say N=10 times) N times smaller than the market maker's order at better prices do not violate the best bid/ask condition.
2. The MM in those market place both bid and ask orders to qualify; if we want to give the reward for just a single side we have to weight the order toward the other side of the order book, or some other way. Say MM1 places just a buy order - it is given credit only for the sum of sell orders falling within the min spread (say 5% spread max)
]

If yes, Xeroc can write the script in no time, I believe.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

bytemaster

I agree that off-chain distribution makes a lot of sense.
For the latest updates checkout my blog: [url="http://bytemaster.bitshares.org"]http://bytemaster.bitshares.org[/url]
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

chono

Quote from: abit on February 22, 2016, 04:49:33 PM
Quote from: tonyk on February 22, 2016, 01:13:01 AM
Quote

Nasdaq is incentivizing the display of orders for (a) 500 shares at the best bid and 500 shares at the best offer, 30% of the time, and (b) 2500 shares at no wider than 2% of the best bid and 2500 shares at no wider than 2% of the best offer, 90% of the time.  I don't think we need to specify a minimum number of shares or what % of the time they need to satisfy the above conditions, but perhaps we could simply make the reward proportional to the length of time MMs have orders on the books, the size of the orders, and the distance from the price feed.  And maybe we should require that orders be on the book for a minimum period of time, as some have already suggested. 


1.Min percent of the time, 2.having the best bid (or ask) 3.For reasonable amount of shares[ probably as % of average volume in our case]. 4. With max spread [or distance from the feed for our case]

Is a very good rule imho.
Points 1 and 2 are very key elements here. It eliminates my the main issue with volume only based distribution of reward. The aim is good prices most of the time not just 10-15 min a day.

@abit and BM - how computationally doable is the above rule for a blockchain?  Keep in mind that ".Min percent of the time" may (and usually will) include  multiple orders and their sum must > Min.
I think the reward program doesn't have to be built INTO the system. Since all trading data is on the chain, any asset issuer is able to analysis the data, then make their own decisions on HOW to reward market makers on her markets. Off-chain data analysis is usually better than on-chain analysis, more flexible, easier to adjust, more cheating resistant, more people are able to help, will never affect the stability of the network. Apply a worker, distribute the funds according to pre-defined rules (better if special scripts are made already), all these can be done by the committee.
+5%
Weibo:Will_BTS