BitShares Forum

Main => General Discussion => Topic started by: bytemaster on February 19, 2016, 09:04:16 pm

Title: Subsidizing Market Liquidity
Post by: bytemaster on February 19, 2016, 09:04:16 pm
I would like to propose a new feature for BTS that CNX will provide free of charge if a hard fork is approved.

We would like to allow any market pair to reward users who provide liquidity in that market. The feature would work as follows:

Every order that is filled after being open on the books for at least 10 minutes earns shares a reward pool. The shares earned are proportional to the size of the order filled.

Any user *or* worker can contribute funds to the reward pool. These funds can be denominated in any asset specified by the issuer.

At most once per day users may convert their shares in the reward pool to a pro-rata share of the rewards.

The asset issuer has the ability to enable this feature for any market their asset trades in and to specify the asset used to fund the reward pool.

With this feature Open Ledger *could* pay out OBITS to those who provide liquidity in the OPEN.BTC / BTS market.
BTS can vote for a worker to provide liquidity in the BTS / USD and BTS / CNY markets.

It is possible that trades in the BTS / OPEN.BTC market could earn rewards from both BTS and OBITS *if* shareholders voted to subsidize this market.

Assuming we implement this feature in the BTS / USD market and voters approve workers funding this at a rate of 2.5 BTS / sec (50% of allowed dilution) and the internal exchange had $100,000 of daily volume then users trading on the internal exchange would see a 1% more than they would get by trading off chain. If daily volume was $50,000 then they would see a 2% profit over doing the same trades off-chain.

The impact of this should be a major influx of new traders who can make more money trading on the internal exchange than the external exchange. This added liquidity will dramatically tighten the USD / BTS peg and give shorters much more confidence.

This implementation will require 3 new operations on the blockchain:

1. create_liquidity_reward_pool issuer ASSET FUND_ASSET MARKET_ASSET    ie: openledger OBIT OPEN.BTC OPEN.USD
2. fund_liquidity_reward_pool funding_account AMOUNT FUND_ASSET ASSET MARKET_ASSET
3. claim_liquidity_rewards username AMOUNT FUND_ASSET  ASSET MARKET_ASSET

It will also create a new worker type that can direct BTS to any fund where FUND_ASSET is BTS.



Note: CNX reserves the right to retract this offer or request payment for adding this feature. This proposal does not commit CNX to develop the feature if we decide to pursue other options.
Title: Re: Subsidizing Market Liquidity
Post by: BunkerChainLabs-DataSecurityNode on February 19, 2016, 09:24:32 pm
How long would it be until this hardfork would be ready?
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 19, 2016, 09:25:23 pm
As a regular wanna-be market maker trader on the DEX, i heart this idea. Anything we can do to encourage liquidity is a step in the right direction.
Title: Re: Subsidizing Market Liquidity
Post by: chono on February 19, 2016, 09:25:25 pm
How long would it be until this hardfork would be ready?
+5%
Title: Re: Subsidizing Market Liquidity
Post by: Akado on February 19, 2016, 09:45:58 pm
What's the reasoning behind the 10 minutes restriction? During the mumble it was mentioned 24h to prevent abuse. The lower the volume, the higher the time limit one should wait before earning the reward. The more volume, the less chance one has to cheat and so, the time limit should be less.
Title: Re: Subsidizing Market Liquidity
Post by: Empirical1.2 on February 19, 2016, 10:02:37 pm
Assuming we implement this feature in the BTS / USD market and voters approve workers funding this at a rate of 2.5 BTS / sec (50% of allowed dilution) and the internal exchange had $100,000 of daily volume then users trading on the internal exchange would see a 1% more than they would get by trading off chain. If daily volume was $50,000 then they would see a 2% profit over doing the same trades off-chain. The impact of this should be a major influx of new traders who can make more money trading on the internal exchange than the external exchange. This added liquidity will dramatically tighten the USD / BTS peg and give shorters much more confidence.

That's $365 000 a year of dilution.  That could be  +5% on $7 500 000 worth of BitUSD.

Even with a lot of yield harvesting that would rapidly make BTS the undisputed Crypto USD market leader.

Uphold: $2 Million
Tether: $1.4 Million
Nubits: $0.76 Million
BitUSD: $0.098 Million

Liquidity is already guaranteed for the longs via forced settlement & with that much in circulation, shorts should have confidence there will be sufficient amounts for sale when they need them.

What about at least putting 1/2 of the proposed dilution towards BitUSD yield? That way you would rapidly increase the BitUSD CAP to >$3.5 million dollars while significantly increasing volume at the same time?

(I would also decrease forced settlement to 98/99%.)
Title: Re: Subsidizing Market Liquidity
Post by: Akado on February 19, 2016, 10:18:41 pm

What about at least putting 1/2 of the proposed dilution towards BitUSD yield? That way you would rapidly increase the BitUSD CAP to >$3.5 million dollars while significantly increasing volume at the same time?

(I would also decrease forced settlement to 98/99%.)

Wouldn't that incentive hoarding instead of trading? I would love yield but if we did that we would be sacrificing potential funds that could be used for liquidity. Didn't Tonyk's method give us yield?

Btw, I don't understand "hat could be  +5% on $7 500 000 worth of BitUSD. " sorry. Could you explain?
Title: Re: Subsidizing Market Liquidity
Post by: chryspano on February 19, 2016, 10:23:57 pm
imo one thing at a time, first we need good liquidity, we should do no compromises here, If only we could make clear that bitUSD is the true and only King.... 
Title: Re: Subsidizing Market Liquidity
Post by: Akado on February 19, 2016, 10:25:08 pm
imo one thing at a time, first we need good liquidity, we should do no compromises here, If only we could make clear that bitUSD is the true and only King....

This is specifically to achieve liquidity
Title: Re: Subsidizing Market Liquidity
Post by: Empirical1.2 on February 19, 2016, 10:31:45 pm

What about at least putting 1/2 of the proposed dilution towards BitUSD yield? That way you would rapidly increase the BitUSD CAP to >$3.5 million dollars while significantly increasing volume at the same time?

(I would also decrease forced settlement to 98/99%.)

Wouldn't that incentive hoarding instead of trading? I would love yield but if we did that we would be sacrificing potential funds that could be used for liquidity. Didn't Tonyk's method give us yield?

Yeah the exploit for BitUSD yield, is yield-harvesting and hoarding, however the potential exploit for negative fees is 'self-trading'.

I would hate to spend $100 000 over 3 months on negative fees only to find perceived liquidity increases but BitUSD total doesn't increase much.

Whereas 1/2 that, $50 000 over 3 months on yield would at least practically guarantee we'd become the Crypto USD market leader in terms of total BitUSD.

Yield is also a big deal now considering the big thing on the horizon is a cashless economy and negative interest rates well below -1%.
http://www.zerohedge.com/news/2016-02-10/something-very-disturbing-spotted-morgan-stanley-presentation-slide
Title: Re: Subsidizing Market Liquidity
Post by: chryspano on February 19, 2016, 10:32:45 pm
imo one thing at a time, first we need good liquidity, we should do no compromises here, If only we could make clear that bitUSD is the true and only King....

This is specifically to achieve liquidity

I'm just not sure if giving funds intented for liquidity at this point as bitUSD yield would help, imo this can help(bitUSD yield) AFTER we have good liquidity and peg, we need first the world to know that bitUSD works.
Title: Re: Subsidizing Market Liquidity
Post by: Pheonike on February 19, 2016, 10:34:04 pm

Shouldn't there be another rule that the ask/bid be placed with 5% of the feed?
Title: Re: Subsidizing Market Liquidity
Post by: bytemaster on February 19, 2016, 10:36:33 pm
Assuming we implement this feature in the BTS / USD market and voters approve workers funding this at a rate of 2.5 BTS / sec (50% of allowed dilution) and the internal exchange had $100,000 of daily volume then users trading on the internal exchange would see a 1% more than they would get by trading off chain. If daily volume was $50,000 then they would see a 2% profit over doing the same trades off-chain. The impact of this should be a major influx of new traders who can make more money trading on the internal exchange than the external exchange. This added liquidity will dramatically tighten the USD / BTS peg and give shorters much more confidence.

That's $365 000 a year of dilution.  That could be  +5% on $7 500 000 worth of BitUSD.

Even with a lot of yield harvesting that would rapidly make BTS the undisputed Crypto USD market leader.

Uphold: $2 Million
Tether: $1.4 Million
Nubits: $0.76 Million
BitUSD: $0.098 Million

Liquidity is already guaranteed for the longs via forced settlement & with that much in circulation, shorts should have confidence there will be sufficient amounts for sale when they need them.

What about at least putting 1/2 of the proposed dilution towards BitUSD yield? That way you would rapidly increase the BitUSD CAP to >$3.5 million dollars while significantly increasing volume at the same time?

(I would also decrease forced settlement to 98/99%.)

Providing yield on USD doesn't work because of yield harvesting, people would create USD and sit on it until the rate of return approached 0.
Title: Re: Subsidizing Market Liquidity
Post by: Empirical1.2 on February 19, 2016, 10:36:57 pm
Btw, I don't understand "that could be  +5% on $7 500 000 worth of BitUSD. " sorry. Could you explain?

The above proposal is suggesting diluting BTS at 2.5BTS/Sec. I think that equates to $365 000 worth of dilution a year.

If that dilution went instead to yield for holders of BitUSD then it would mean we could offer BitUSD +5% yield/interest on up to $7 300 000 worth of BitUSD. ($365 000 is 5% of $7 300 000) 
Title: Re: Subsidizing Market Liquidity
Post by: bytemaster on February 19, 2016, 10:37:07 pm

Shouldn't there be another rule that the ask/bid be placed with 5% of the feed?

They only get paid of the order is filled, placed too far from the trading price and they wouldn't get paid.
Title: Re: Subsidizing Market Liquidity
Post by: monsterer on February 19, 2016, 10:41:25 pm
Providing yield on USD doesn't work because of yield harvesting, people would create USD and sit on it until the rate of return approached 0.

I forget why the short couldn't pay the long directly, thereby negating the yield harvesting problem?
Title: Re: Subsidizing Market Liquidity
Post by: Empirical1.2 on February 19, 2016, 10:44:42 pm
Assuming we implement this feature in the BTS / USD market and voters approve workers funding this at a rate of 2.5 BTS / sec (50% of allowed dilution) and the internal exchange had $100,000 of daily volume then users trading on the internal exchange would see a 1% more than they would get by trading off chain. If daily volume was $50,000 then they would see a 2% profit over doing the same trades off-chain. The impact of this should be a major influx of new traders who can make more money trading on the internal exchange than the external exchange. This added liquidity will dramatically tighten the USD / BTS peg and give shorters much more confidence.

That's $365 000 a year of dilution.  That could be  +5% on $7 500 000 worth of BitUSD.

Even with a lot of yield harvesting that would rapidly make BTS the undisputed Crypto USD market leader.

What about at least putting 1/2 of the proposed dilution towards BitUSD yield? That way you would rapidly increase the BitUSD CAP to >$3.5 million dollars while significantly increasing volume at the same time?

Providing yield on USD doesn't work because of yield harvesting, people would create USD and sit on it until the rate of return approached 0.

Yes but it at least creates USD which would make BitUSD the perceived market leader.

There also isn't enough BTS to create $7 300 000 BitUSD, so the rate of return couldn't approach zero or even less than  +5% unless this move also significantly increased the value of BTS?

Edit: Hmm, doesn't diluting BTS at 2.5% to pay yield mathematically guarantee a BitUSD yield of > +5% if 100% collateral is required from the short side as well?
Title: Re: Subsidizing Market Liquidity
Post by: Akado on February 19, 2016, 10:58:02 pm
Providing yield on USD doesn't work because of yield harvesting, people would create USD and sit on it until the rate of return approached 0.

I forget why the short couldn't pay the long directly, thereby negating the yield harvesting problem?

Monsterer has been insisting on this for a while but I believe it never got much attention. @bytemaster could you give your input on this?


What about at least putting 1/2 of the proposed dilution towards BitUSD yield? That way you would rapidly increase the BitUSD CAP to >$3.5 million dollars while significantly increasing volume at the same time?

(I would also decrease forced settlement to 98/99%.)

Wouldn't that incentive hoarding instead of trading? I would love yield but if we did that we would be sacrificing potential funds that could be used for liquidity. Didn't Tonyk's method give us yield?

Yeah the exploit for BitUSD yield, is yield-harvesting and hoarding, however the potential exploit for negative fees is 'self-trading'.

I would hate to spend $100 000 over 3 months on negative fees only to find perceived liquidity increases but BitUSD total doesn't increase much.

Whereas 1/2 that, $50 000 over 3 months on yield would at least practically guarantee we'd become the Crypto USD market leader in terms of total BitUSD.

Yield is also a big deal now considering the big thing on the horizon is a cashless economy and negative interest rates well below -1%.
http://www.zerohedge.com/news/2016-02-10/something-very-disturbing-spotted-morgan-stanley-presentation-slide

Well as long as there is liquidity and USD changes hands which is what this idea seems to do, everyone gets access to USD, plus it gives shorts a bit of incentive too? Which could this way incentive USD creation?
Title: Re: Subsidizing Market Liquidity
Post by: Empirical1.2 on February 19, 2016, 11:10:55 pm

What about at least putting 1/2 of the proposed dilution towards BitUSD yield? That way you would rapidly increase the BitUSD CAP to >$3.5 million dollars while significantly increasing volume at the same time?

(I would also decrease forced settlement to 98/99%.)

Wouldn't that incentive hoarding instead of trading? I would love yield but if we did that we would be sacrificing potential funds that could be used for liquidity. Didn't Tonyk's method give us yield?

Yeah the exploit for BitUSD yield, is yield-harvesting and hoarding, however the potential exploit for negative fees is 'self-trading'.

I would hate to spend $100 000 over 3 months on negative fees only to find perceived liquidity increases but BitUSD total doesn't increase much.

Whereas 1/2 that, $50 000 over 3 months on yield would at least practically guarantee we'd become the Crypto USD market leader in terms of total BitUSD.

Yield is also a big deal now considering the big thing on the horizon is a cashless economy and negative interest rates well below -1%.
http://www.zerohedge.com/news/2016-02-10/something-very-disturbing-spotted-morgan-stanley-presentation-slide

Well as long as there is liquidity and USD changes hands which is what this idea seems to do, everyone gets access to USD, plus it gives shorts a bit of incentive too? Which could this way incentive USD creation?

It would incentivize USD creation because there would be a lot of demand from longs above the peg.

However yes I also think the main problem with the current way BitUSD is created, in the current market, is actually incentivizing the shorts.

I'm just pointing out with that level of dilution we could create insatiable demand for BitUSD & easily become the market leader, even if it was often in the form of yield harvesting (the yield also wouldn't approach 0 as BM suggests if it was funded by a set percentage of dilution) It's a huge amount of dilution BM is suggesting so by combining the two we get the best of both world's.
Title: Re: Subsidizing Market Liquidity
Post by: Akado on February 19, 2016, 11:21:45 pm
I see. My doubt remains in these two options:

1. Using dilution like you mentioned as a mean to provide yield. Issue with harvesting. However it provides a bigger chance of USD creation and all advantages that come from that. Dilution, higher chance of succeeding.
2. Not using dilution for that since there are periods of increased demand for USD and periods of stagnation. USD is created more "organically" so to speak, however we would first need for one of those periods (probably summer with the BTC halving) and has lower chances of people creating more USD. However doesn't dilute. No dilution, higher risk of failure.

It's just a matter of seeing which one brings more benefits. I personally think yield is very attractive for other people. It would certainly bring older pre-merger members back. But at the same time I think with enough liquidity, demand will grow naturally so there is really no need to try and force it.

What we could do is one step at the time. Do provide the negative fees first. If demand increases we stick with this. If we want better results, we can discuss yield at that time. Doing everything at the same time might not be a good idea. One thing at the time optimized our chances and also our fund management abilities! We don't waste as many resources that way, we save them and optimize them.
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on February 19, 2016, 11:48:25 pm
Are MAKER's counter-cheating measures and  fair-distribution algoes gone? Reading the OP this seems to be the case.

If all that is left is matched order size (after 10 min wait), I can get 50% to 80% of this dilution with a stake of 1% of BTS.

And the worst is not that I will get all this dilution, the worst is:
- it will be fake volume, exiting for just a few minutes every day;
- it will be about as far from the peg as it is now
- because of that, shorts will be willing to short as much as now.
Title: Re: Subsidizing Market Liquidity
Post by: yvv on February 19, 2016, 11:52:49 pm
If you want to boost liquidity, it is much more transparent and easy to organize pooled market making through crowd funding. Issue a market making token, sell it, and give the funds to experienced market maker. Let market maker to keep 50% of profit, and distribute another 50% among token holders. No need in hard fork.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 20, 2016, 12:01:26 am
If you want to boost liquidity, it is much more transparent and easy to organize pooled market making through crowd funding. Issue a market making token, sell it, and give the funds to experienced market maker. Let market maker to keep 50% of profit, and distribute another 50% among token holders. No need in hard fork.

TRANSPARENT and SIMPLE are big pluses. Who would voluntarily crowdfund a market making pool? I can maybe see something like this taking places as a big hoorah lets-support-the-community one-off measure, but we'd be better off structuring a for-profit sustainable approach. Some sort of fee diversion into a market making pool that rewards the right incentives, limits cheating, etc.
Title: Re: Subsidizing Market Liquidity
Post by: Akado on February 20, 2016, 12:02:16 am
Are MAKER's counter-cheating measures and  fair-distribution algoes gone? Reading the OP this seems to be the case.

If all that is left is matched order size (after 10 min wait), I can get 50% to 80% of this dilution with a stake of 1% of BTS.

And the worst is not that I will get all this dilution, the worst is:
- it will be fake volume, exiting for just a few minutes every day;
- it will be about as far from the peg as it is now
- because of that, shorts will be willing to short as much as now.

I agree that 10 minutes is too low. The lower the volume the more time the limit should be. During the mumble the period of time that was mentioned was 24h, dunno the origin of these 10 min now.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 20, 2016, 12:09:38 am
it'd be nice to incorporate a "distance to last executed trade price" in the weighting scheme for claiming fees. Someone throwing up generally useless open orders that happen to get executed somewhere way in the future probably shouldn't get a disproportionate claim to fees for that trade simply bc the order was open for a long time. i know this adds maybe a big layer of complexity, but an issue that should maybe be considered (and rejected if too complex compared to its value).
Title: Re: Subsidizing Market Liquidity
Post by: yvv on February 20, 2016, 12:09:51 am

TRANSPARENT and SIMPLE are big pluses. Who would voluntarily crowdfund a market making pool?

I would, if it is done the right way.
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on February 20, 2016, 12:11:16 am
I agree that 10 minutes is too low. The lower the volume the more time the limit should be. During the mumble the period of time that was mentioned was 24h, dunno the origin of these 10 min now.
24h is the max limit.The idea is - you do not get a reward for placing an order way from the price and it gets filled after 1week because the market moved.
10min is the min it must stay on the books - this is to prevent* self filling the order just to get the reward.

*This is the hope at least. With whale size orders the theory fails though.
Title: Re: Subsidizing Market Liquidity
Post by: clayop on February 20, 2016, 12:45:03 am
I found an irony.

BM created the DEX and want to improve its liquidity. But he doesn't use the DEX.

http://cryptofresh.com/b/3577692
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on February 20, 2016, 01:34:35 am
I found an irony.

BM created the DEX and want to improve its liquidity. But he doesn't use the DEX.

http://cryptofresh.com/b/3577692

There is no irony. You just have to be in the 'right' mindset. The mindset of truly believing 'Dilution is Good'. Very Good indeed.
Repeat to your self: Dilution is Good', 'Dilution is Good', 'Dilution is Good'...check your self and see if you believe it (if not keep repeating)...'Dilution is Good'...

You believe it now? Good!
It is easy to see how you can pay your way into liquidity [no need to do it yourself, mind you]; by diluting the shares of an entity that has negative fees.
Where can this possibly go wrong in this house of cards and self-chained multiplication effects: Liquidity providers are happy to provide liquidity, after being paid; Shareholders are double happy - new found liquidity plus ALL the benefits of dilution!

The point is 'using it yourself' is they old way to do stuff,the old way where 2+2 equals 4 (5 the most); when you do not do it yourself but use the power of dilution and other multiplication tricks  2+0 equals at least 7 (often way more)!
Title: Re: Subsidizing Market Liquidity
Post by: Zapply on February 20, 2016, 01:35:42 am

Providing yield on USD doesn't work because of yield harvesting, people would create USD and sit on it until the rate of return approached 0.
+5% +5% +5%
Title: Re: Subsidizing Market Liquidity
Post by: Tuck Fheman on February 20, 2016, 02:18:48 am
There is no irony. You just have to be in the 'right' mindset. The mindset of truly believing 'Dilution is Good'. Very Good indeed.
Repeat to your self: Dilution is Good', 'Dilution is Good', 'Dilution is Good'...check your self and see if you believe it (if not keep repeating)...'Dilution is Good'...

(http://gifsoup.com/view/48045/the-wizard-of-oz-o.gif)
Disclaimer : Just to make tonyk laugh.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 20, 2016, 04:56:14 am
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.
Title: Re: Subsidizing Market Liquidity
Post by: Musewhale on February 20, 2016, 05:50:00 am
crazy idea  +5% +5% +5%
do it
Title: Re: Subsidizing Market Liquidity
Post by: chryspano on February 20, 2016, 07:58:41 am
Are MAKER's counter-cheating measures and  fair-distribution algoes gone? Reading the OP this seems to be the case.

If all that is left is matched order size (after 10 min wait), I can get 50% to 80% of this dilution with a stake of 1% of BTS.

And the worst is not that I will get all this dilution, the worst is:
- it will be fake volume, exiting for just a few minutes every day;
- it will be about as far from the peg as it is now
- because of that, shorts will be willing to short as much as now.

Really? How can you do that? How can we avoid this?
Title: Re: Subsidizing Market Liquidity
Post by: chryspano on February 20, 2016, 07:58:53 am
I agree that 10 minutes is too low. The lower the volume the more time the limit should be. During the mumble the period of time that was mentioned was 24h, dunno the origin of these 10 min now.
24h is the max limit.The idea is - you do not get a reward for placing an order way from the price and it gets filled after 1week because the market moved.
10min is the min it must stay on the books - this is to prevent* self filling the order just to get the reward.

*This is the hope at least. With whale size orders the theory fails though.

Why? How?
Title: Re: Subsidizing Market Liquidity
Post by: chryspano on February 20, 2016, 07:59:05 am
I found an irony.

BM created the DEX and want to improve its liquidity. But he doesn't use the DEX.

http://cryptofresh.com/b/3577692

There is no irony. You just have to be in the 'right' mindset. The mindset of truly believing 'Dilution is Good'. Very Good indeed.
Repeat to your self: Dilution is Good', 'Dilution is Good', 'Dilution is Good'...check your self and see if you believe it (if not keep repeating)...'Dilution is Good'...

You believe it now? Good!
It is easy to see how you can pay your way into liquidity [no need to do it yourself, mind you]; by diluting the shares of an entity that has negative fees.
Where can this possibly go wrong in this house of cards and self-chained multiplication effects: Liquidity providers are happy to provide liquidity, after being paid; Shareholders are double happy - new found liquidity plus ALL the benefits of dilution!

The point is 'using it yourself' is they old way to do stuff,the old way where 2+2 equals 4 (5 the most); when you do not do it yourself but use the power of dilution and other multiplication tricks  2+0 equals at least 7 (often way more)!

Such Whining!
Very Buthurt!
Much Trolling
WOW

Do you have anything usefull to say or your aim is to see this thread filled with useless posts? (my post included)
Title: Re: Subsidizing Market Liquidity
Post by: lil_jay890 on February 20, 2016, 08:38:36 am
Another question to ask is why CNX, who charges market rates for even minor bug fixes, is doing this for free?

It would be better to discover the motive now, instead of 3 months after the hardfork while everyone is pissed.
Title: Re: Subsidizing Market Liquidity
Post by: btswildpig on February 20, 2016, 09:31:32 am
Another question to ask is why CNX, who charges market rates for even minor bug fixes, is doing this for free?

It would be better to discover the motive now, instead of 3 months after the hardfork while everyone is pissed.

if any bug is introduced by this new function , it needs xxx man hours to fix it , then there is income .....
Title: Re: Subsidizing Market Liquidity
Post by: chryspano on February 20, 2016, 09:52:43 am
Another question to ask is why CNX, who charges market rates for even minor bug fixes, is doing this for free?

It would be better to discover the motive now, instead of 3 months after the hardfork while everyone is pissed.

if any bug is introduced by this new function , it needs xxx man hours to fix it , then there is income .....

Are you accusing cnx that they deliberately are trying to introduce buggy code in BTS or you are just competing with Tonyk for the "Whiner of The Week" prize? (Hint: You stand no chance against Tonyk!)
Title: Re: Subsidizing Market Liquidity
Post by: btswildpig on February 20, 2016, 09:58:58 am
Another question to ask is why CNX, who charges market rates for even minor bug fixes, is doing this for free?

It would be better to discover the motive now, instead of 3 months after the hardfork while everyone is pissed.

if any bug is introduced by this new function , it needs xxx man hours to fix it , then there is income .....

Are you accusing cnx that they deliberately are trying to introduce buggy code in BTS or you are just competing with Tonyk for the "Whiner of The Week" prize? (Hint: You stand no chance against Tonyk!)

i'm merely pointing out that work needs to be paid , no work is really free or cost nothing . The more complicated the function is , the most cost it will be . That's about what Sunny King said about not adding Cold Mining to PPC .
Title: Re: Subsidizing Market Liquidity
Post by: chryspano on February 20, 2016, 10:08:15 am
Another question to ask is why CNX, who charges market rates for even minor bug fixes, is doing this for free?

It would be better to discover the motive now, instead of 3 months after the hardfork while everyone is pissed.

if any bug is introduced by this new function , it needs xxx man hours to fix it , then there is income .....

Are you accusing cnx that they deliberately are trying to introduce buggy code in BTS or you are just competing with Tonyk for the "Whiner of The Week" prize? (Hint: You stand no chance against Tonyk!)

i'm merely pointing out that work needs to be paid , no work is really free or cost nothing . The more complicated the function is , the most cost it will be . That's about what Sunny King said about not adding Cold Mining to PPC .

I'm sure we can find some Chinese coders that will fix any future bugs for "free!"
Maybe some Chinese traders/marketmakers will offer us liquitidy for "free!" too!

No worries there!
Title: Re: Subsidizing Market Liquidity
Post by: Erlich Bachman on February 20, 2016, 10:09:21 am
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 see your point now. it still seems like this might lead to gaming of the system but my game theory sucks.

i trust you guys on the math and if there is one thing worth spending our fee pool on its liquidity, so im on board
Title: Re: Subsidizing Market Liquidity
Post by: BTSdac on February 20, 2016, 12:04:12 pm
Assuming we implement this feature in the BTS / USD market and voters approve workers funding this at a rate of 2.5 BTS / sec (50% of allowed dilution) and the internal exchange had $100,000 of daily volume then users trading on the internal exchange would see a 1% more than they would get by trading off chain. If daily volume was $50,000 then they would see a 2% profit over doing the same trades off-chain.
are you crazy?
I don`t understand  why you have this idea, you change the rule of bts2.0, 
BM do you forget the merge that hurt bts so badly?
maybe you want to improve bts using you way , but don`t change the rule first , I also think btser would not agree this idea ?
there are many operation can been done to improve bts
like margin trade
but I think many of btser would reject to force fork !
Title: Re: Subsidizing Market Liquidity
Post by: Samupaha on February 20, 2016, 12:29:20 pm
Assuming we implement this feature in the BTS / USD market and voters approve workers funding this at a rate of 2.5 BTS / sec (50% of allowed dilution) and the internal exchange had $100,000 of daily volume then users trading on the internal exchange would see a 1% more than they would get by trading off chain. If daily volume was $50,000 then they would see a 2% profit over doing the same trades off-chain.
are you crazy?
I don`t understand  why you have this idea, you change the rule of bts2.0, 
BM do you forget the merge that hurt bts so badly?
maybe you want to improve bts using you way , but don`t change the rule first , I also think btser would not agree this idea ?
there are many operation can been done to improve bts
like margin trade
but I think many of btser would reject to force fork !

Take a deep breath and read the original post again. You have misunderstood it. This is just an optional feature that shareholders can use if they choose to. If this feature is implemented, nothing is forcing Bitshares to use it. It will be used only if shareholders decide to use it.

It can be also used only by businesses that want to increase liquidity of their own assets, isn't this at least very good tool to have?

Your fearmongering is hurting BTS badly right now. Please stop it. Analyze proposed features and workers properly before you judge them.
Title: Re: Subsidizing Market Liquidity
Post by: sudo on February 20, 2016, 12:50:37 pm
Because there is no capacity of bitAsset
 so there is no attractive
Not because interest!!!!!!!!!!!!!!!!!!!!!!!!!!
Title: Re: Subsidizing Market Liquidity
Post by: sudo on February 20, 2016, 12:52:01 pm
boost the bitasset moving fast  Improve circulation
make the volume large!!!!!!!!!!
Title: Re: Subsidizing Market Liquidity
Post by: Akado on February 20, 2016, 01:24:26 pm
boost the bitasset moving fast  Improve circulation
make the volume large!!!!!!!!!!

Which is exactly what this is aiming for...
Title: Re: Subsidizing Market Liquidity
Post by: sudo on February 20, 2016, 01:30:31 pm
Diluting  at low price   bts die
bts die   bitAsset die
all die
Title: Re: Subsidizing Market Liquidity
Post by: Akado on February 20, 2016, 01:48:45 pm
Diluting  at low price   bts die
bts die   bitAsset die
all die

I'm not saying we must do this, but then what other options do we have? Let's all pray and hope for the best? Maybe that way people will start using BitShares. Sounds like a plan.
Title: Re: Subsidizing Market Liquidity
Post by: sudo on February 20, 2016, 02:29:09 pm
Diluting  at low price   bts die
bts die   bitAsset die
all die

I'm not saying we must do this, but then what other options do we have? Let's all pray and hope for the best? Maybe that way people will start using BitShares. Sounds like a plan.

base on bitshares   make app
use bitshares RNG 
vote game……
Title: Re: Subsidizing Market Liquidity
Post by: Akado on February 20, 2016, 02:36:51 pm
Diluting  at low price   bts die
bts die   bitAsset die
all die

I'm not saying we must do this, but then what other options do we have? Let's all pray and hope for the best? Maybe that way people will start using BitShares. Sounds like a plan.

base on bitshares   make app
use bitshares RNG 
vote game……

Making apps for BitShares will probably need dilution too, since no one will do them for free unless you find a business who is very interested in BitShares.

The games who could bring more attention are most likely Dice but that seems to have a bad reputation on China so we shouldn't really go that route it seems.

We want volume and liquidity but that isn't free. We can't just snap our fingers and have all we want right. It requires some sacrifice. It might work or it might not work, but sitting and not doing nothing is 100% guaranteed it won't have any positive effect.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 20, 2016, 03:17:34 pm
i see your point now. it still seems like this might lead to gaming of the system but my game theory sucks.

i trust you guys on the math so im on board, however, Empirical brings up a great point being that we could basically bring forward the success of our bond market tomorrow to today simply by using all or half of the proposed funds for this project to pay yield on bitassets

it is a different strategy that would put us more directly in competition with banks and many community.members have left over the years and have experienced disappointment that we have dropped this strategy. We would win them back and more.

here, check out the poll I started and see what the communtiy thinks:

https://bitsharestalk.org/index.php/topic,21549.0.html

anytime we propose spending revenue on projects it is a contentious issue. the fork we are at here is do we want to bring in traders next and incentivise our DEX ?

or do we want to bring in savers and in entivize yield (as an incentive to buy and hold in a market with big spreads)

Just voted in that poll and it looks like i'm the only one in favor of supporting yield on bitassets! One caveat to that poll is that i would remove the word "forever" in the interest payments. i'm all for a bond market with contractual yields in rates and maturity. to keep things simple, however, i think the biggest bang for the buck is in a Bitshares Treasury bond that pays out some % of fees as interest. we could start with a fixed rate product, a variable rate one depending on fees, or whatever. The key, though, is to create something that can reward investors for holding bitassets.

Best to test a prototype, maybe a bitUSD Treasury that pays interest from fees earned in the bitUSD market; the bond should only be available for purchase with bitUSD, as well, which creates circular, and hopefully growing, demand for the market over time. If that works, roll out similar bonds for the other relatively liquid markets. Imagine the PR we could get when we eventually have a Gold Bond that pays bitGOLD investors? There aren't many other places in the world you can go to simultaneously adopt gold price exposure and earn interest!

re: maturity, i'd recommend the prototype bitUSD-denominated debt instrument should be a 30-day bill instead of a longer dated bond. Those can, and should, come later. Right now we want a good mix between offering assets with yield that utilize our underlying bitassets and turnover to keep things as liquid as possible.
Title: Re: Subsidizing Market Liquidity
Post by: Shentist on February 20, 2016, 05:34:23 pm
many people don't understand that all numbers are assumptions from bytemaster and the committee will have
the autority to change them.

so if 10 minutes is good etc. can be discusssed and change, how much we spend on something like this is decided via workers who are voted in.

that's leave us to the point

"is this a good idea?"

i think yes, because

- it will attract more "traders" aka users.
- with more traders more "holders" aka users will come etc.

i would just like to have some feature added like "is x% away from peg" as a set we can change. with this we can make it possible that the order has to stay x minutes on the order book but has to be at least x % near the peg. with more minutes on the ordersbooks there is not such a thing then fake liquidity, because some other guy can buy your order up for you, so you have some risks if you trade always against yourself.
Title: Re: Subsidizing Market Liquidity
Post by: Akado on February 20, 2016, 05:52:11 pm
I think Shentist's right. We can start with a more conservative approach and if everything goes well, the committee could always change the parameters as long as it feels comfortable and we get the expected results.

Would like to see the committee's opinion on this @alt @bitcrab @Bhuz @abit @cube
Title: Re: Subsidizing Market Liquidity
Post by: bytemaster on February 20, 2016, 06:08:19 pm
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.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 20, 2016, 06:08:44 pm
maybe we're over complicating this and we should just be thinking in terms of fee discounts for trade frequency. There's no gaming something like that since there'd always be a non-zero transaction fee, and we can reserve fees for creating a kick a$$ bond market.
Title: Re: Subsidizing Market Liquidity
Post by: Shentist on February 20, 2016, 06:22:39 pm
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.

some people are worried that whales can abuse it like

Alice place a sell order of 20.000 bitUSD 8% away from the market. The bitshares exchange has not so many traders yet, so in 10 minutes only 1000 bitUSD is before her. so she will just buy 21.000 bitUSD and get most of the reward today.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 20, 2016, 06:31:05 pm
maybe we're over complicating this and we should just be thinking in terms of fee discounts for trade frequency. There's no gaming something like that since there'd always be a non-zero transaction fee, and we can reserve fees for creating a kick a$$ bond market.

In that case we could also simply do maker/taker where maker pays zero.  But the point is to further incentivize placing orders on the books by offering a negative fee.  To that end, I think @bytemaster has made some good points about the risk of self-trading perhaps being overblown.  Although I'd like to hear what others think.

I would also like to hear what @bytemaster thinks about the case @Empirical1.2 has been making for splitting the dilution between incentivizing market makers and paying yield to BitUSD holders.  Personally, I find this hybrid approach very compelling and haven't seen any particularly good arguments against it.
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 20, 2016, 06:35:46 pm
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.
Basically I think it's a good idea. If there are fair competitions.
But what will happen when one of the competor has unfair advantage? As tonyk said, If a whale put a wall there, she can easily harvest most of the rewards. Worst assumption is that CNX is such a whale, so no payment for development, but earn much from future rewards via dilution.
//update: Shentist made a good example.
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on February 20, 2016, 07:11:32 pm
What Shentist and abit said.
You do not have to be  first on the orderbook if you are a whale and the reward is anywhere meaningful. You buy the few small orders before yours (say 200-500USD total) and self-fill your 15-20K USD. The daily reward is mostly yours. You can even replace the orders that you bought at the same prices.

If the reward is not meaningful... well it will not have the impact you want, at all.

Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 20, 2016, 07:23:20 pm
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.

i agree that the ability to game fees declines rapidly with the number of market participants, so i don't view as a serious concern at this point. i understand the concept of a time-on-order-book (like the 10 minute idea) is to dissuade gaming the system, but it also cuts higher frequency traders out of the reward mix, especially those providing useful liquidity on the margin. Any timed open order requirement may work fine now to alleviate the gaming risk, but when these markets mature and we have serious global trading competition on the DEX, we'd only be subsidizing people adding low value liquidity at extreme prices from highest bid / lowest ask; those doing the brunt of trading on the margin would be excluded.
Title: Re: Subsidizing Market Liquidity
Post by: jtme on February 20, 2016, 07:31:54 pm
What Shentist and abit said.
You do not have to be  first on the orderbook if you are a whale and the reward is anywhere meaningful. You buy the few small orders before yours (say 200-500USD total) and self-fill your 15-20K USD. The daily reward is mostly yours. You can even replace the orders that you bought at the same prices.

If the reward is not meaningful... well it will not have the impact you want, at all.

If this strategy would be profitable for a whale, it is reasonable to expect another whale will
come to compete with this whale.

if CNX wants to implemet it for free, there is no harm to test it on one asset first ... bitUSD
and see if/how it works.
Title: Re: Subsidizing Market Liquidity
Post by: chryspano on February 20, 2016, 07:39:58 pm
What Shentist and abit said.
You do not have to be  first on the orderbook if you are a whale and the reward is anywhere meaningful. You buy the few small orders before yours (say 200-500USD total) and self-fill your 15-20K USD. The daily reward is mostly yours. You can even replace the orders that you bought at the same prices.

If the reward is not meaningful... well it will not have the impact you want, at all.

You asume that there will be only one whale in town, have you read BM's post?
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on February 20, 2016, 07:43:02 pm
What Shentist and abit said.
You do not have to be  first on the orderbook if you are a whale and the reward is anywhere meaningful. You buy the few small orders before yours (say 200-500USD total) and self-fill your 15-20K USD. The daily reward is mostly yours. You can even replace the orders that you bought at the same prices.

If the reward is not meaningful... well it will not have the impact you want, at all.

If this strategy would be profitable for a whale, it is reasonable to expect another whale will
come to compete with this whale.

if CNX wants to implemet it for free, there is no harm to test it on one asset first ... bitUSD
and see if/how it works.
True but I thought we wanted to stimulate meaningful liquidity and not just give some money to the whales. My bad than - mission accomplished:
Grand Plan:
1. feed the whales by dilution - DONE!
2. ?
Title: Re: Subsidizing Market Liquidity
Post by: jtme on February 20, 2016, 07:55:32 pm
What Shentist and abit said.
You do not have to be  first on the orderbook if you are a whale and the reward is anywhere meaningful. You buy the few small orders before yours (say 200-500USD total) and self-fill your 15-20K USD. The daily reward is mostly yours. You can even replace the orders that you bought at the same prices.

If the reward is not meaningful... well it will not have the impact you want, at all.

If this strategy would be profitable for a whale, it is reasonable to expect another whale will
come to compete with this whale.

if CNX wants to implemet it for free, there is no harm to test it on one asset first ... bitUSD
and see if/how it works.
True but I thought we wanted to stimulate meaningful liquidity and not just give some money to the whales. My bad than - mission accomplished:
Grand Plan:
1. feed the whales by dilution - DONE!
2. ?

If two or more whales compete for the reward, they will probably create meaningful liquidity.
Is it better to dilute on this or on development of more features that nobody will eventually use ?
If this works and creates liquidity, it is what everyone here wanted in the first place - liquid bitAssets.

Title: Re: Subsidizing Market Liquidity
Post by: abit on February 20, 2016, 07:58:10 pm
It's not too good if one winner wins all prizes.
Some improvements:
* to be qualify for reward, the price should be within say 3% of feed price
* when distributing the reward, weight by for example duration*quantity but not by quantity only (what if a whale places orders every block? so a minimum duration is needed? if 10 minutes is too long, how about 1 minute?)
* weight by log(quantity) instead of quantity so smaller participants will earn relatively more rewards than whales (decreasing edge effect). (but what if a whale places thousands of orders?)

Thoughts?

//update: edited the 2nd rule
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 20, 2016, 08:14:51 pm
It's not too good if one winner wins all prizes.
Some improvements:
* to be qualify for reward, the price should be within say 3% of feed price
* when distributing the reward, weight by for example duration*quantity but not by quantity only (what if a whale places orders every block? so a minimum duration is needed? if 10 minutes is too long, how about 1 minute?)
* weight by log(quantity) instead of quantity so smaller participants will earn relatively more rewards than whales (decreasing edge effect). (but what if a whale places thousands of orders?)

Thoughts?

//update: edited the 2nd rule

very good ideas. i like the log weighting, not too excited about any time duration requirement since we could have far more active markets in the future (which we should all plan for now), and i def like the radius from feed price concept to encourage higher value liquidity on the margin.  +5%
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 20, 2016, 08:26:28 pm
It's not too good if one winner wins all prizes.
Some improvements:
* to be qualify for reward, the price should be within say 3% of feed price
* when distributing the reward, weight by for example duration*quantity but not by quantity only (what if a whale places orders every block? so a minimum duration is needed? if 10 minutes is too long, how about 1 minute?)
* weight by log(quantity) instead of quantity so smaller participants will earn relatively more rewards than whales (decreasing edge effect). (but what if a whale places thousands of orders?)

Thoughts?

//update: edited the 2nd rule

very good ideas. i like the log weighting, not too excited about any time duration requirement since we could have far more active markets in the future (which we should all plan for now), and i def like the radius from feed price concept to encourage higher value liquidity on the margin.  +5%
I also think time duration requirement is not so important. Longer duration means more risks, shorter duration + higher frequency would be more acceptable by market makers.

//update:
In regards to " radius from feed price concept", how about change my first rule to: the closer to feed price, the higher weight of reward?
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 20, 2016, 08:39:18 pm
It's not too good if one winner wins all prizes.
Some improvements:
* to be qualify for reward, the price should be within say 3% of feed price
* when distributing the reward, weight by for example duration*quantity but not by quantity only (what if a whale places orders every block? so a minimum duration is needed? if 10 minutes is too long, how about 1 minute?)
* weight by log(quantity) instead of quantity so smaller participants will earn relatively more rewards than whales (decreasing edge effect). (but what if a whale places thousands of orders?)

Thoughts?

//update: edited the 2nd rule

very good ideas. i like the log weighting, not too excited about any time duration requirement since we could have far more active markets in the future (which we should all plan for now), and i def like the radius from feed price concept to encourage higher value liquidity on the margin.  +5%
I also think time duration requirement is not so important. Longer duration means more risks, shorter duration + higher frequency would be more acceptable by market makers.

//update:
In regards to " radius from feed price concept", how about change my first rule to: the closer to feed price, the higher weight of reward?

yes, definitely think there should be higher weighting for reward the closer the orders are to being useful, but i think useful is often divergent from price feed; i'd say weighting should be based on radius to bid/ask midpoint.
Title: Re: Subsidizing Market Liquidity
Post by: jtme on February 20, 2016, 08:41:40 pm
It's not too good if one winner wins all prizes.
Some improvements:
* to be qualify for reward, the price should be within say 3% of feed price
* when distributing the reward, weight by for example duration*quantity but not by quantity only (what if a whale places orders every block? so a minimum duration is needed? if 10 minutes is too long, how about 1 minute?)
* weight by log(quantity) instead of quantity so smaller participants will earn relatively more rewards than whales (decreasing edge effect). (but what if a whale places thousands of orders?)

Thoughts?

//update: edited the 2nd rule

3% of feed price  - it should be set by market forces, not by comitee. too small and it wont work,
too big and it is useless.

why small participants should earn more ? give more to the poor ?
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 20, 2016, 09:01:05 pm
It's not too good if one winner wins all prizes.
Some improvements:
* to be qualify for reward, the price should be within say 3% of feed price
* when distributing the reward, weight by for example duration*quantity but not by quantity only (what if a whale places orders every block? so a minimum duration is needed? if 10 minutes is too long, how about 1 minute?)
* weight by log(quantity) instead of quantity so smaller participants will earn relatively more rewards than whales (decreasing edge effect). (but what if a whale places thousands of orders?)

Thoughts?

//update: edited the 2nd rule

3% of feed price  - it should be set by market forces, not by comitee. too small and it wont work,
too big and it is useless.

why small participants should earn more ? give more to the poor ?
It's a double-edged sword.
If we are not sure whether it will benefit the system, we need to limit the possibility of harming the system to lowest.
We need to encourage whales to do good things, discourage whales to do bad things, although it's free to do anything in a free market.
Last time when the committee placed more than 5K$ of bitusd onto the market with 8% premium, the orders were eaten in minutes. Some whales don't want the system has liquidity.
Title: Re: Subsidizing Market Liquidity
Post by: bitcrab on February 21, 2016, 02:42:54 am
found no reason to support this.
users trade because they need to trade, because the need to get something by selling something else.
so the key point is to creat the real demand.
to reward the trading activity will distorte the encouragement,and make the system more complex with no necessity.
Title: Re: Subsidizing Market Liquidity
Post by: sudo on February 21, 2016, 03:17:42 am
found no reason to support this.
users trade because they need to trade, because the need to get something by selling something else.
so they key point is to creat the real demand.
to reward the trading activity will distorte the encouragement,and make the system more complex with no necessity.
+5% +5% +5% +5%
Title: Re: Subsidizing Market Liquidity
Post by: Zapply on February 21, 2016, 04:41:47 am
found no reason to support this.
users trade because they need to trade, because the need to get something by selling something else.
so the key point is to creat the real demand.
to reward the trading activity will distorte the encouragement,and make the system more complex with no necessity.
(http://3.bp.blogspot.com/-MjU5VtLXgx0/VK-c1uz7cAI/AAAAAAAAEgg/X6NCElIJsb0/s1600/good.gif)
Title: Re: Subsidizing Market Liquidity
Post by: Empirical1.2 on February 21, 2016, 06:11:19 am

* to be qualify for reward, the price should be within say 3% of feed price

Thoughts?

 +5% I agree. This liquidity measure would cost a lot of money everyday, so it has to bring in outside new money everyday.

Therefore the question is what spread will entice new outside users to use BitUSD? Anything outside that range isn't useful anyway.

Also the potential to game the system should be significantly reduced by this as well.




Title: Re: Subsidizing Market Liquidity
Post by: CoinHoarder on February 21, 2016, 07:25:27 am
This is a tried and true (proven) way to create liquidity for market pegged cryptocurrencies (a la Nubits.) Dilution to subsidize (or provide) liquidity is the only certain way to achieve it. Tonyk's proposal is a gamble. It might work but it might not, as it is uncharted territory. Assuming you can work out all the kinks, and I am assuming that you can (a la Smartcoins), then I think this proposal is the best way forward as far as liquidity on the DEX is concerned.

IF Tonyk continues with his plan to fork Bitshares, then I propose that the original Bitshares chain implement this idea (or something similar). At that point the main chain is competing with Tonyk's chain, and I think it would be smart (for main chain Bitshares supporters) to implement a feature that nullifies one of the few potential benefits of Tonyk's fork.

All (or most) of the people that disagree with this proposal seem to support Tonyk's fork. I say you implement your idea BM, assuming you have the votes to support it, and let the rest of the community that disagrees with it go off and support Tonyk's fork. Then, the original Bitshares chain can go on to teach them a lesson in the strength of a network effects, and the main Bitshares chain's community would be more on the same wavelength (for other things too such as MAS). ;)
Title: Re: Subsidizing Market Liquidity
Post by: jtme on February 21, 2016, 08:54:35 am
found no reason to support this.
users trade because they need to trade, because the need to get something by selling something else.
so the key point is to creat the real demand.
to reward the trading activity will distorte the encouragement,and make the system more complex with no necessity.

Its not to reward market activity but to reward market makers.

https://en.wikipedia.org/wiki/Market_maker
Title: Re: Subsidizing Market Liquidity
Post by: Erlich Bachman on February 21, 2016, 11:40:11 am
This is a tried and true (proven) way to create liquidity for market pegged cryptocurrencies (a la Nubits.) Dilution to subsidize (or provide) liquidity is the only certain way to achieve it.

ah i get it now.  I'm sick of getting my ass kicked by Nubits. Let's capitulate already so we can get this show on the road


* to be qualify for reward, the price should be within say 3% of feed price

Thoughts?

 +5% I agree. This liquidity measure would cost a lot of money everyday, so it has to bring in outside new money everyday.

Therefore the question is what spread will entice new outside users to use BitUSD? Anything outside that range isn't useful anyway.

Also the potential to game the system should be significantly reduced by this as well.





Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 21, 2016, 11:42:59 am
All (or most) of the people that disagree with this proposal seem to support Tonyk's fork. I say you implement your idea BM, assuming you have the votes to support it, and let the rest of the community that disagrees with it go off and support Tonyk's fork. Then, the original Bitshares chain can go on to teach them a lesson in the strength of a network effects, and the main Bitshares chain's community would be more on the same wavelength (for other things too such as MAS). ;)

^This.  BTS is currently and historically one of the world's top cryptocurrencies by market cap and by volume traded.  Indeed, many people are aware of BTS and it is in demand.  With the proper incentives, a growing number of those people will trade BTS on the DEX instead of on centralized exchanges. 

As that happens, and along with other measures taken, the liquidity of BitUSD (and BitAssets in general) will grow, the peg will tighten, more people will hold and use it, even more people will trade on the DEX, and so on through the virtuous cycle.  At some point the dominant market for BTS will be on the DEX, which will be great for the peg.  Keep in mind, it is NOT necessary for trading of BTS to be ONLY on the DEX.  It would simply be very helpful if the DEX was the dominant marketplace for BTS.  And again, other measures will also help the peg.

So now let's think about tony's idea to create a new chain.  How many false assumptions must tony make in order to convince himself and a small handful of others that this is actually a good idea?  First, he assumes that it is necessary for the shares to trade exclusively on the DEX.  Wrong.  He assumes it is necessary to FORCE people to trade the shares on the DEX, rather than INCENTIVIZING them to do so.  Wrong.  He assumes that getting the shares to trade on the DEX will automatically create the perfect peg.  Wrong.  And finally, he assumes that more than 5 people are going to have the faintest desire to trade unknown shares of an unknown DAC on an unknown DEX.  Wrong, wrong, and wrong. 

I knew from the start that tony's idea to create doaShares (and his reasoning to do so) lacked logic.  But thank you @CoinHoarder for sparking me to think more more specifically about why his idea is so idiotic misguided and may even be a pure attempt to sabotage Bitshares by dividing attention and resources.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 21, 2016, 11:56:30 am
found no reason to support this.
users trade because they need to trade, because the need to get something by selling something else.
so the key point is to creat the real demand.
to reward the trading activity will distorte the encouragement,and make the system more complex with no necessity.

Its not to reward market activity but to reward market makers.

https://en.wikipedia.org/wiki/Market_maker

^This.  And rewarding market makers is not a new concept.  Nasdaq does it and I assure you (@bitcrab) they are not alone in doing so.  There is good reason for it, and we should be doing it too.

http://www.nasdaqtrader.com/Trader.aspx?id=MQP

"The Market Quality Program (MQP) is a groundbreaking proprietary market structure and incentive program developed to help enhance liquidity in the Exchange Traded Fund (ETF) marketplace. It is an optional listing program that provides ETF issuers the opportunity to incentivize Market Makers to improve the quality of the market and increase the liquidity in their products. Market makers will benefit from the program’s quarterly rebate payments in exchange for a commitment to enhance the quality of the markets in registered ETFs."
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 21, 2016, 12:20:35 pm
More from Nasdaq's Market Quality Program FAQ:

Q: Why is Nasdaq creating the MQP?
A: Nasdaq believes the Market Quality Program will help increase liquidity and enhance the quality of the markets being made in the Exchange Traded Fund marketplace by decreasing the quoted spread and increasing the shares quoted at the NBBO. Additionally, Nasdaq believes that the MQP will increase competition and broaden the pool of liquidity providing firms engaged in market making in ETFs.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 21, 2016, 12:52:43 pm
Here's the most interesting thing of all from Nasdaq.  They reward liquidity providers based on average time and average size at NBBO.  NBBO (national best bid & offer) sounds a lot like our price feed (see below).  Not to mention, they are rewarding for how long an order is on the book i.e. the longer it's on the book, the greater the reward.  If you think about it, that's how they avoid self trading.  Because why would a liquidity provider match their own order if they are getting paid to have it on the books?  And by the way, if we're paying for liquidity right at the feed, doesn't that help tighten the peg?  Hmmm. 



Q: How do Market Makers get compensated?
A: Trade and Quote Payments will be distributed pro-rata to qualified Market Makers. Trade Payment distribution will be based upon liquidity-adding executions. Quote Payment distribution will be based equally upon average time at NBBO and average size at NBBO. Trade and Quote Payments will only be made if a Market Maker(s) meets the qualifications above. Trade and Quote Payments will be calculated monthly and distributed quarterly.



What is a 'National Best Bid and Offer - NBBO'
The best (lowest) available ask price and the best (highest) available bid price to investors when they buy and sell securities. National Best Bid and Offer is the bid and ask price the average person will see. The Securities and Exchange Commission’s Regulation NMS requires that brokers must guarantee customers this price.
Title: Re: Subsidizing Market Liquidity
Post by: monsterer on February 21, 2016, 01:07:18 pm
Why can't the taker just pay the maker directly some portion of the fees? That pretty much prevents the system being gamble, while incentivising liquidity.
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 21, 2016, 01:35:46 pm
Why can't the taker just pay the maker directly some portion of the fees? That pretty much prevents the system being gamble, while incentivising liquidity.
BM ever said in a post that "taker pay maker" will actually add an invisible but existed spread to the market, if the payment is high, everybody will try to be the maker, result in high and tight bid/ask walls but little volume. What is said in this thread is to encourage maker but not punish taker, so better liquidity.
Title: Re: Subsidizing Market Liquidity
Post by: valtr on February 21, 2016, 01:42:21 pm
There are for sure many ways how to gain new users, but than I was interested in altcoins as newcomer, I just looked in coinmarketcap.
Protoshares was the only interesting project with enough volume and capitalization. Ripple did not gain my attention and other was a me too coins only.
Low volume coins I did not explored.
I say that only because I can not understand the logic behind fork and spread. IMO that can not bring anything good fot all of us.
Title: Re: Subsidizing Market Liquidity
Post by: monsterer on February 21, 2016, 01:42:34 pm
BM ever said in a post that "taker pay maker" will actually add an invisible but existed spread to the market, if the payment is high, everybody will try to be the maker, result in high and tight bid/ask walls but little volume. What is said in this thread is to encourage maker but not punish taker, so better liquidity.

Only true if you increase the trade fee, I'm saying just divert part of the existing fee.
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 21, 2016, 02:16:56 pm
BM ever said in a post that "taker pay maker" will actually add an invisible but existed spread to the market, if the payment is high, everybody will try to be the maker, result in high and tight bid/ask walls but little volume. What is said in this thread is to encourage maker but not punish taker, so better liquidity.

Only true if you increase the trade fee, I'm saying just divert part of the existing fee.
I'm saying zero fee + other encouragement.
Title: Re: Subsidizing Market Liquidity
Post by: CoinHoarder on February 21, 2016, 02:49:43 pm
Solid posts @tbone

BM ever said in a post that "taker pay maker" will actually add an invisible but existed spread to the market, if the payment is high, everybody will try to be the maker, result in high and tight bid/ask walls but little volume. What is said in this thread is to encourage maker but not punish taker, so better liquidity.

Only true if you increase the trade fee, I'm saying just divert part of the existing fee.

I think the issue is that maker/taker won't consist of a sufficient amount of incentive to substantially increase liquidity.
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 21, 2016, 03:54:52 pm
I wonder why only matched orders would be rewarded? Are we going to encourage self trading? The orders who placed there for a long time but not yet have chance to be filled didn't provide liquidity?
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 21, 2016, 04:42:09 pm
Some good ideas in this thread. Mimicking NASDAQ is a great idea for a first cut solution, might as well leverage what seems to work for a dominant exchange.
Title: Re: Subsidizing Market Liquidity
Post by: chono on February 21, 2016, 05:14:36 pm
subsidizing is our version of mining.
Title: Re: Subsidizing Market Liquidity
Post by: CoinHoarder on February 21, 2016, 07:11:32 pm
I wonder why only matched orders would be rewarded? Are we going to encourage self trading? The orders who placed there for a long time but not yet have chance to be filled didn't provide liquidity?

Some good ideas in this thread. Mimicking NASDAQ is a great idea for a first cut solution, might as well leverage what seems to work for a dominant exchange.

I would say we couldn't go wrong by mimicking NASDAQ's market quality program. If Nasdaq has deemed it "un-gameable", then who are we armchair experts to argue? Props to @tbone for bringing that to our attention.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 21, 2016, 07:17:36 pm
I wonder why only matched orders would be rewarded? Are we going to encourage self trading? The orders who placed there for a long time but not yet have chance to be filled didn't provide liquidity?

Some good ideas in this thread. Mimicking NASDAQ is a great idea for a first cut solution, might as well leverage what seems to work for a dominant exchange.

I would say we couldn't go wrong by mimicking NASDAQ's market quality program. If Nasdaq has deemed it "un-gameable", then who are we armchair experts to argue? Props to @tbone for bringing that to our attention.

yeah i think that's the best logical starting point, leverage their work, but we can always improve over time as we learn.
Title: Re: Subsidizing Market Liquidity
Post by: Musewhale on February 21, 2016, 07:29:28 pm
All (or most) of the people that disagree with this proposal seem to support Tonyk's fork. I say you implement your idea BM, assuming you have the votes to support it, and let the rest of the community that disagrees with it go off and support Tonyk's fork. Then, the original Bitshares chain can go on to teach them a lesson in the strength of a network effects, and the main Bitshares chain's community would be more on the same wavelength (for other things too such as MAS). ;)

crazy idea
Title: Re: Subsidizing Market Liquidity
Post by: CoinHoarder on February 21, 2016, 09:06:40 pm
All (or most) of the people that disagree with this proposal seem to support Tonyk's fork. I say you implement your idea BM, assuming you have the votes to support it, and let the rest of the community that disagrees with it go off and support Tonyk's fork. Then, the original Bitshares chain can go on to teach them a lesson in the strength of a network effects, and the main Bitshares chain's community would be more on the same wavelength (for other things too such as MAS). ;)

crazy idea

I said "IF tonyk forks Bitshares" ... At that point both chains are in head-to-head competition for the same target market. It is survival of the fittest at that point. By forking Bitshares, targeting the same market, and forking the community/developers/etc.... He is literally declaring war on Bitshares. All is fair in the cryptocurrency wars. This fork would be very different from any previous forks, as MUSE and PLAY are going after different target markets. Tonyk's fork will be competing directly with Bitshares.
Title: Re: Subsidizing Market Liquidity
Post by: Pheonike on February 21, 2016, 09:39:56 pm
This is good because it can finally provide what BitShares has been needing awhile now, Focus. All this dilution arguing has done has slowed downed development. I would rather backed two separate teams each focused on what they feel will work than one team constantly confused and keeps shooting it on feet off.
Title: Re: Subsidizing Market Liquidity
Post by: TravelsAsia on February 21, 2016, 10:34:05 pm
All (or most) of the people that disagree with this proposal seem to support Tonyk's fork. I say you implement your idea BM, assuming you have the votes to support it, and let the rest of the community that disagrees with it go off and support Tonyk's fork. Then, the original Bitshares chain can go on to teach them a lesson in the strength of a network effects, and the main Bitshares chain's community would be more on the same wavelength (for other things too such as MAS). ;)

crazy idea

I said "IF tonyk forks Bitshares" ... At that point both chains are in head-to-head competition for the same target market. It is survival of the fittest at that point. By forking Bitshares, targeting the same market, and forking the community/developers/etc.... He is literally declaring war on Bitshares. All is fair in the cryptocurrency wars. This fork would be very different from any previous forks, as MUSE and PLAY are going after different target markets. Tonyk's fork will be competing directly with Bitshares.

Was Expanse war on Ethereum with their fork? I can understand the concern but declaring war seems a little dramatic.
Title: Re: Subsidizing Market Liquidity
Post by: CoinHoarder on February 21, 2016, 11:25:09 pm
Was Expanse war on Ethereum with their fork? I can understand the concern but declaring war seems a little dramatic.

First of all, I am of the opinion Expanse is a pump and dump. Look at the lead developer's track record of failed cryptocurrencies with "gimmicky" innovation, dwindling market capitalizations, and over-promising yet under-delivering. First Franko, then Aiden, now Expanse.

Explain how Expanse was/is a positive occurrence for Ethereum?

Yet, you are comparing Apples and Oranges....

The guys behind Expanse are not (and never were) involved in the Ethereum community. See their Ethereum forum profiles and Githubs:
defaced:
https://forum.ethereum.org/profile/defaced
https://github.com/franko-org
CryptoCc:
https://forum.ethereum.org/profile/CryptoCc
can't find anything easily on their 3rd "founder"

My point with showing that information is that the Expanse fork is not a hostile takeover (a la Tonyk's fork) within the Ethereum community. If Expanse formed out of a disagreement within the Ethereum community, and a small but substantial amount of developers/community left expanse to work on the new fork, then yes it would certainly be a bad thing for Ethereum. The public perception alone that the community is splitting into two competing cryptocurrencies is a huge negative force on the market.

Further, you could still argue that since they are "working" on Expanse, that takes away possible developers (and therefore value) from Ethereum in the form of possible smart contracts that never materialize. Furthermore, Expanse community/volume/marketing certainly takes away from the Ethereum community/volume/market cap. Without its existence, these people likely would have participated/invested/traded/developed in Ethereum instead... they did choose an Ethereum fork after all.

All cryptocurrency forks are less successful than their counterparts. I can only name one anomaly (Bytecoin-> Monero), and I think that was an extreme case of an unfairly launched Cryptocurrency . Ripple dominating Stellar. Bitcoin dominating all alt coins. Litecoin dominating all of its forks. Ethereum dominating all of its forks. Nxt dominating all of its forks. Peercoin dominating all of its forks. Bitshares dominating Muse. Yet, Tonyk's fork is going to be a great success, provide a liquid smartcoin exchange, and all of us are going to switch over to it.  ::)

Expanse did not sharedrop Ethereum so perhaps it was even worse than this scenario. Then again maybe not, it is hard to compare apples and oranges.

In summary, since it is unlikely the fork will be successful, and it also takes away developers/resources/community/volume/cohesiveness/market confidence/perception of success/etc., a cryptocurrency fork is like declaring war on the cryptocurrency it forked from. It has little chance of success, and is certain to cause negatives that would likely not otherwise occur if the chain wasn't forked.
Title: Re: Subsidizing Market Liquidity
Post by: Empirical1.2 on February 21, 2016, 11:29:05 pm
Anyone considered Nubits liquidity pools that offer huge buy and sell walls by subsidizing the liquidity pool?

https://nubits.com/current-liquidity-pools

Step 1 Create millions of BitUSD through a POS minting reward for a fairly neutral cost https://bitsharestalk.org/index.php/topic,21547.0.html

Step 2 Create a trustless subsidized liquidity pool that we can voluntarily send our millions of BitUSD to, to earn additional interest and in the process create large BitUSD buy and sell walls around a tight peg. https://nubits.com/current-liquidity-pools We've already seen this process work for NuBits, the question is how much does it cost?

I like that idea because it potentially creates a tighter peg and every BitUSD holder can easily participate, I would be also interested if it could be achieved for a lower cost.

I wonder why only matched orders would be rewarded? Are we going to encourage self trading? The orders who placed there for a long time but not yet have chance to be filled didn't provide liquidity?

Some good ideas in this thread. Mimicking NASDAQ is a great idea for a first cut solution, might as well leverage what seems to work for a dominant exchange.

I would say we couldn't go wrong by mimicking NASDAQ's market quality program. If Nasdaq has deemed it "un-gameable", then who are we armchair experts to argue? Props to @tbone for bringing that to our attention.

yeah i think that's the best logical starting point, leverage their work, but we can always improve over time as we learn.

It seemed pretty good I liked that it rewarded orders very close to the peg based on amount of time they've been active. (I don't think we want to reward orders too far away from the peg to actually be useful/attract new users.)

Atm we have very few DEX users, so the only problem I see with the current liquidity proposals is that we could be overpaying for liquidity in very thinly traded hours when there isn't a lot of demand.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 21, 2016, 11:39:38 pm
I wonder why only matched orders would be rewarded? Are we going to encourage self trading? The orders who placed there for a long time but not yet have chance to be filled didn't provide liquidity?

Some good ideas in this thread. Mimicking NASDAQ is a great idea for a first cut solution, might as well leverage what seems to work for a dominant exchange.

I would say we couldn't go wrong by mimicking NASDAQ's market quality program. If Nasdaq has deemed it "un-gameable", then who are we armchair experts to argue? Props to @tbone for bringing that to our attention.

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. 

Regardless of the exact algorithm, the interesting thing about making rewards proportional to the amount of time orders are on the books is that the incentives will be dynamic based on the liquidity needs of the market in question.  In other words, in low volume/low liquidity markets, MMs will have greater opportunity to place orders that stay on the book long enough for them to actually earn rewards.  As liquidity and volume grow, the opportunity will automatically diminish as a growing number of their orders get matched more quickly. 

I think this could work very well for us.  I'd be interested to hear what @bytemaster thinks about this, as well as some of the other reasonable, rational contributors here such as @CoinHoarder, @Empirical1.2, @cylonmaker2053, @abit, etc.  I'd also like to hear whether people such as @alt, @bitcrab, and @clayop think incentivizing BitAssets liquidity is not important enough to employ a MM reward program modeled roughly on the Nasdaq's MQP Program.
Title: Re: Subsidizing Market Liquidity
Post by: Pheonike on February 21, 2016, 11:49:40 pm
You dont have to worry about dshares taken away developers. BitShares does a good job of that by itself by not wanting to pay them and/or voting them out on some political reasons instead of performance.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 22, 2016, 12:21:58 am

I wonder why only matched orders would be rewarded? Are we going to encourage self trading? The orders who placed there for a long time but not yet have chance to be filled didn't provide liquidity?

Some good ideas in this thread. Mimicking NASDAQ is a great idea for a first cut solution, might as well leverage what seems to work for a dominant exchange.

I would say we couldn't go wrong by mimicking NASDAQ's market quality program. If Nasdaq has deemed it "un-gameable", then who are we armchair experts to argue? Props to @tbone for bringing that to our attention.

yeah i think that's the best logical starting point, leverage their work, but we can always improve over time as we learn.

It seemed pretty good I liked that it rewarded orders very close to the peg based on amount of time they've been active. (I don't think we want to reward orders too far away from the peg to actually be useful/attract new users.)

Atm we have very few DEX users, so the only problem I see with the current liquidity proposals is that we could be overpaying for liquidity in very thinly traded hours when there isn't a lot of demand.

We could structure the program with rewards that are diminished during off-peak hours such that MMs would still want to keep the orders on the book, but we wouldn't pay as much for the less meaningful liquidity. 
Title: Re: Subsidizing Market Liquidity
Post by: 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.
Title: Re: Subsidizing Market Liquidity
Post by: Erlich Bachman on February 22, 2016, 05:02:55 am
subsidizing is our version of mining.

Absolutely
Bitcoin has POW
Peercoin has POS
NEM has POI
hundreds more

and BitShares has

Proof of Liquidity

POL

Where liquidity providers mine BitShares

I finally see the genius now,

Congratulations on inventing this new paradigm!
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 22, 2016, 04:49:33 pm
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.
Title: Re: Subsidizing Market Liquidity
Post by: chono on February 22, 2016, 05:06:01 pm
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%
Title: Re: Subsidizing Market Liquidity
Post by: bytemaster on February 22, 2016, 06:22:35 pm
I agree that off-chain distribution makes a lot of sense.
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on February 22, 2016, 06:34:22 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.
Title: Re: Subsidizing Market Liquidity
Post by: chono on February 22, 2016, 10:14:24 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
Title: Re: Subsidizing Market Liquidity
Post by: xeroc on February 23, 2016, 11:47:26 am
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?
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 23, 2016, 12:18:00 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. 
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 23, 2016, 12:36:56 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)?
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 23, 2016, 01:03:05 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?
Title: Re: Subsidizing Market Liquidity
Post by: puppies on February 23, 2016, 05:22:07 pm
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?
Title: Re: Subsidizing Market Liquidity
Post by: morpheus on February 23, 2016, 05:36:59 pm
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.
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on February 23, 2016, 07:25:07 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. 


Title: Re: Subsidizing Market Liquidity
Post by: abit on February 23, 2016, 08:08:23 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.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 24, 2016, 07:24:38 am
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.
Title: Re: Subsidizing Market Liquidity
Post by: xeroc on February 24, 2016, 08:00:08 am
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.
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 24, 2016, 09:16:32 am
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).
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 24, 2016, 09:41:39 am
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.

If this is off chain, what will the interface be to specify the parameters?  I suppose for the committee the parameters could be hard-coded, but asset issuers should probably be able to set their own parameters.   

Either way, we'll have to decide what parameters make sense for BitAssets.  Tony proposed 5% minimum time at best bid/ask, but that number is so low that it's pointless.  Nasdaq uses 30% as minimum amount of time at the best bid/ask, and also requires a minimum of 90% of the time within 2% of the best bid/ask. 
Title: Re: Subsidizing Market Liquidity
Post by: xeroc on February 24, 2016, 09:44:16 am
We can rely on Cryptofresh in the short term .. but any thing done with shareholders money should be verify able by any one and shouldn't rely on 3rd party services IMHO ..
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 24, 2016, 09:51:28 am
We can rely on Cryptofresh in the short term .. but any thing done with shareholders money should be verify able by any one and shouldn't rely on 3rd party services IMHO ..
I was not saying rely on CryptoFresh's data, I was saying it's tech/skills.
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 24, 2016, 10:11:43 am
If this is off chain, what will the interface be to specify the parameters?  I suppose for the committee the parameters could be hard-coded, but asset issuers should probably be able to set their own parameters.   

Either way, we'll have to decide what parameters make sense for BitAssets.  Tony proposed 5% minimum time at best bid/ask, but that number is so low that it's pointless.  Nasdaq uses 30% as minimum amount of time at the best bid/ask, and also requires a minimum of 90% of the time within 2% of the best bid/ask.
Yes this is the most important thing. The detailed rules.

Nasdaq's parameters make more sense for me.

//Edit
Now I tend to 5% minimum time on bid/ask in combined with 90% of time within 2% of the best bid/ask.

After more thinking, now I think Nasdaq's parameters don't fit our needs. What Nasdaq need is to improve liquidity of thousands of trading pairs, so maybe one maker focus on one pair, providing at least 30% of liquidity to that pair. Our (first) goal is only one trading pair: bitUSD/BTS, we want more people to provide liquidity to this one market, so it's not good to set a too restrict rule (30% minimum time), otherwise nobody can get reward, then the experience will probably fail.

Title: Re: Subsidizing Market Liquidity
Post by: abit on February 24, 2016, 11:01:00 pm
bump
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 25, 2016, 12:53:08 am
If this is off chain, what will the interface be to specify the parameters?  I suppose for the committee the parameters could be hard-coded, but asset issuers should probably be able to set their own parameters.   

Either way, we'll have to decide what parameters make sense for BitAssets.  Tony proposed 5% minimum time at best bid/ask, but that number is so low that it's pointless.  Nasdaq uses 30% as minimum amount of time at the best bid/ask, and also requires a minimum of 90% of the time within 2% of the best bid/ask.
Yes this is the most important thing. The detailed rules.

Nasdaq's parameters make more sense for me.

//Edit
Now I tend to 5% minimum time on bid/ask in combined with 90% of time within 2% of the best bid/ask.

After more thinking, now I think Nasdaq's parameters don't fit our needs. What Nasdaq need is to improve liquidity of thousands of trading pairs, so maybe one maker focus on one pair, providing at least 30% of liquidity to that pair. Our (first) goal is only one trading pair: bitUSD/BTS, we want more people to provide liquidity to this one market, so it's not good to set a too restrict rule (30% minimum time), otherwise nobody can get reward, then the experience will probably fail.

I see what you're saying.  But I doubt Nasdaq is trying to have just one market maker per market.  Also, there's no reason why many MMs can't each reach 30% individually.  After all, multiple market participants can all be at the best bid or offer at the same time.  Don't we want to incentivize as much liquidity as possible right at the peg?
Title: Re: Subsidizing Market Liquidity
Post by: CoinHoarder on February 25, 2016, 02:08:51 am
Our (first) goal is only one trading pair: bitUSD/BTS

I hear people say this all the time on these forums, and I think that is the wrong way of looking at it.

A. Cryptocurrency tokens which are USD derivatives (bitUSD/Nubits/Tether/coinoUSD/etc.) are a heavily competitive market.
A1. It is a market in which Bitshares is getting stomped by its competition (in terms of liquidity, volume, adoption, and usage).

B. Bitshares can easily issue autonomous derivatives for things like Gold, Silver, Oil, Corn, Lean Hogs, Live Cattle, Feeder Cattle, Wheat, Cocoa, Coffee, Cotton, Nasdaq, S&P 500, Apple, Google, etc...
B1. This is a market in which there is no competition in the cryptocurrency space.
B2. If we don't capitalize on these markets we are certain to lose first mover advantage.
B3. An extremely large portion of the cryptocurrency community are speculators. Give them something to speculate on. They don't want to speculate on FIAT. FIAT is boring. If I want FIAT, I'll keep my money in my bank account or in cash... it is much more easily accessible, and has more security & utility.
B4. Smartcoins as a whole is the innovation Bitshares should be marketing, not simply bitUSD.

I am not saying that bitUSD is not an important smartcoin, but we should not limit Bitshares' features for the sake of having a liquid USD token. That is an already competitive space. It is possible that these smartcoins that everyone views as obscure and unimportant are actually Bitshares' greatest strength. If the smartcoin markets were liquid enough, I would diversify my cryptocurrency portfolio into many commodities, stock, and stock indexes. I have a feeling there is a large market of people whom would want to stay within the cryptocurrency economy, but still diversify their portfolios outside of cryptocurrencies and FIAT derivatives.

This "let's get the bitUSD market liquid first then branch off into other smartcoins" is rubbish. That is the same thing everyone's been saying for over two years. By the time the market is liquid we will have lost first mover advantage. Someone could code Smartcoins up on Ethereum in no time. It will happen sooner rather than later. Bitshares will again get caught with its pants down... on the cusp of a viral features (such as bitUSD), but it is unpolished/unfinished and someone else swoops in to take the meal out from under our nose.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 25, 2016, 04:01:17 am
Our (first) goal is only one trading pair: bitUSD/BTS

I hear people say this all the time on these forums, and I think that is the wrong way of looking at it.

A. Cryptocurrency tokens which are USD derivatives (bitUSD/Nubits/Tether/coinoUSD/etc.) are a heavily competitive market.
A1. It is a market in which Bitshares is getting stomped by its competition (in terms of liquidity, volume, adoption, and usage).

B. Bitshares can easily issue autonomous derivatives for things like Gold, Silver, Oil, Corn, Lean Hogs, Live Cattle, Feeder Cattle, Wheat, Cocoa, Coffee, Cotton, Nasdaq, S&P 500, Apple, Google, etc...
B1. This is a market in which there is no competition in the cryptocurrency space.
B2. If we don't capitalize on these markets we are certain to lose first mover advantage.
B3. An extremely large portion of the cryptocurrency community are speculators. Give them something to speculate on. They don't want to speculate on FIAT. FIAT is boring. If I want FIAT, I'll keep my money in my bank account or in cash... it is much more easily accessible, and has more security & utility.
B4. Smartcoins as a whole is the innovation Bitshares should be marketing, not simply bitUSD.

I am not saying that bitUSD is not an important smartcoin, but we should not limit Bitshares' features for the sake of having a liquid USD token. That is an already competitive space. It is possible that these smartcoins that everyone views as obscure and unimportant are actually Bitshares' greatest strength. If the smartcoin markets were liquid enough, I would diversify my cryptocurrency portfolio into many commodities, stock, and stock indexes. I have a feeling there is a large market of people whom would want to stay within the cryptocurrency economy, but still diversify their portfolios outside of cryptocurrencies and FIAT derivatives.

This "let's get the bitUSD market liquid first then branch off into other smartcoins" is rubbish. That is the same thing everyone's been saying for over two years. By the time the market is liquid we will have lost first mover advantage. Someone could code Smartcoins up on Ethereum in no time. It will happen sooner rather than later. Bitshares will again get caught with its pants down... on the cusp of a viral features (such as bitUSD), but it is unpolished/unfinished and someone else swoops in to take the meal out from under our nose.

I agree with pretty much everything you're saying.  But @abit is not saying to kill off the other Smartcoins.  He's just talking about where to focus initial liquidity incentives.  We have to start somewhere, and USD is the best starting point.  Although I would personally direct initial incentives to all 3 on-ramp fiats i.e. USD, CNY, and EUR on a 75%, 20% and 5% basis respectively.  If it works, then we can expand it quickly to some of other Smartcoins, likely starting with GOLD, SILVER, OIL, etc.  It will be awesome once we really get those markets going, eh?

By the way, I also agree that our window of opportunity is going to start closing.  We need to take action now.  We can't sit on our hands or it will be certain failure.  For that reason, we should all be seriously considering @Empirical1.2 's yield harvesting proposal.  I'm not saying I'm 100% on board yet, I still think some questions need to be answered.  I hope others will also keep an open mind and ask intelligent questions rather than have knee jerk reactions out of ignorance and fear of the unknown.  We have to be willing to try and fail.  Not trying would be the worst failure of all!

Anyway, please take a look at @Empirical1.2's propsal linked below and provide input if you wouldn't mind.  Thanks.

https://bitsharestalk.org/index.php/topic,21597.0.html
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 25, 2016, 09:16:30 am
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.
Title: Re: Subsidizing Market Liquidity
Post by: sudo on February 25, 2016, 01:35:34 pm
how many  normal people would like to use bitUSD  ……?
is the mobile wallet  easy  enough??
is there more and more forum apps website  use bitUSD?
Title: Re: Subsidizing Market Liquidity
Post by: Erlich Bachman on February 25, 2016, 01:46:54 pm
Smartcoins as a whole is the innovation Bitshares should be marketing, not simply bitUSD.


This "let's get the bitUSD market liquid first then branch off into other smartcoins" is rubbish. That is the same thing everyone's been saying for over two years. By the time the market is liquid we will have lost first mover advantage. Someone could code Smartcoins up on Ethereum in no time. It will happen sooner rather than later. Bitshares will again get caught with its pants down... on the cusp of a viral features (such as bitUSD), but it is unpolished/unfinished and someone else swoops in to take the meal out from under our nose.

on point jack

who is this guy?

I vote to make him king



I've been trying to get into some bitPussy for months now, but damn!


that spread just kills me!





(http://www.keep-it-sexy.com/wp-content/uploads/2014/08/bitcoin_1.jpg)
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on February 25, 2016, 02:54:03 pm
instead of forcibly restricting trading pairs, why not a maker liquidity model like Gemini is implementing?

http://www.coindesk.com/gemini-exchange-new-trading-fees/

dynamic volume-based discount schedule.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on February 25, 2016, 03:34:09 pm
instead of forcibly restricting trading pairs, why not a maker liquidity model like Gemini is implementing?

http://www.coindesk.com/gemini-exchange-new-trading-fees/

dynamic volume-based discount schedule.

I used to advocate for at least initially restricting pairs to the ones that make the most sense.  I mean, do we really need every BitAsset to trade against every other BitAsset?  It doesn't make sense to fragment liquidity across too many markets.  On the other hand, I'm sure there are people who would find some of the exotic pairs interesting.  So rather than restricting the pairs, I think it would be sufficient to leave all pairs in place but simply concentrate liquidity incentives on the pairs that make the most sense.  Also, in order to avoid confusion caused by a clusterfuck of pointless (to most people) trading pairs in the UI, it would be helpful if new accounts have the most sensible pairs starred by default, then the user can find and star any other market of their choice.   

As for the gemini maker/taker model, it's probably worth studying.  It looks like they reward not only volume but also balance of orders between bid and offer.  The only problem with the latter is that the bid/offer balance of trades is not entirely up to the maker.  I mean, what if the market is trending down, for example, and their bids are constantly getting hit but not their offers nearly as much?  So their model seems a bit flawed in that regard unless I'm missing something.
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 26, 2016, 03:07:14 pm
bump
Title: Re: Subsidizing Market Liquidity
Post by: abit on February 29, 2016, 10:38:01 am
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.
Title: Re: Subsidizing Market Liquidity
Post by: chono on February 29, 2016, 03:00:54 pm
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.
+5%
Title: Re: Subsidizing Market Liquidity
Post by: bytemaster on February 29, 2016, 05:09:35 pm
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.
+5%

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. 
Title: Re: Subsidizing Market Liquidity
Post by: giant middle finger on February 29, 2016, 05:32:54 pm
Are you kidding us?!

This is BitShares!

We look forward to upgrades!
Title: Re: Subsidizing Market Liquidity
Post by: abit on March 03, 2016, 12:31:12 am
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.
+5%

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.
Title: Re: Subsidizing Market Liquidity
Post by: CoinHoarder on March 04, 2016, 04:46:15 am
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.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 04, 2016, 09:53:45 am
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.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 07, 2016, 08:15:45 pm
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. 
Title: Re: Subsidizing Market Liquidity
Post by: chryspano on March 07, 2016, 09:03:23 pm
@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.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on March 07, 2016, 09:29:22 pm
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.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 07, 2016, 10:00:25 pm
@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. 
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 07, 2016, 10:48:07 pm
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?
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on March 08, 2016, 12:28:41 am
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.
Title: Re: Subsidizing Market Liquidity
Post by: abit on March 08, 2016, 01:29:16 am
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.
Title: Re: Subsidizing Market Liquidity
Post by: xeroc on March 08, 2016, 09:08:40 am
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
Title: Re: Subsidizing Market Liquidity
Post by: CoinHoarder on March 09, 2016, 04:26:49 am
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.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 09, 2016, 01:49:42 pm
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.

@CoinHoarder, with #1-3, there is already incentive to place orders on either side of the book.  Nasdaq's incentives require placing orders on both the bid and the ask, presumably to promote balance.  Which kind of makes sense, although the point of #4 above is to further recognize that in some market conditions it is more risky to be on one side of the book than the other.  So the point is to provide more incentive to be on the riskier i.e. weak side in order to avoid a situation where market makers pull their orders in fear of getting steamrolled.  At the end of the day, if a market maker wants to put larger orders on the weak side of the book, then that is a good thing and they should earn more.  If they choose not to, then they will earn less and that is up to them.  I don't see what is gameable about this in particular.  If you still disagree with that, can you explain further?

By the way, I would imagine that determining which side of the book, if any, is weak at any given time is not a trivial matter.  Although it really shouldn't be too difficult to take into account a short time-frame running average of cumulative trades at the ask vs. trades at the bid, and perhaps also comparing short-term price delta to medium-term price delta.  I would imagine that ultimately people will create bots to most effectively take advantage of these reward factors, which is fine because that means they are putting liquidity where we need it most.  Thoughts?
Title: Re: Subsidizing Market Liquidity
Post by: CoinHoarder on March 11, 2016, 04:38:22 am
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.

@CoinHoarder, with #1-3, there is already incentive to place orders on either side of the book.  Nasdaq's incentives require placing orders on both the bid and the ask, presumably to promote balance.  Which kind of makes sense, although the point of #4 above is to further recognize that in some market conditions it is more risky to be on one side of the book than the other.  So the point is to provide more incentive to be on the riskier i.e. weak side in order to avoid a situation where market makers pull their orders in fear of getting steamrolled.  At the end of the day, if a market maker wants to put larger orders on the weak side of the book, then that is a good thing and they should earn more.  If they choose not to, then they will earn less and that is up to them.  I don't see what is gameable about this in particular.  If you still disagree with that, can you explain further?

I agree that #4 is useful and should be a part of the equation. I think restrictions should still be implemented in the "liquidity reward system" to increase shareholder's acceptance of the proposal, increase its usefulness to non-participating users (not participating in the "reward system",) and decrease the chances it can be gamed. I feel like implementing restrictions would help in all of those areas.

Let me ask you this. Why should someone be allowed to place an order 50% away from the peg and earn any points towards the "reward system"? or 40%? or 30%? How useful are orders that far away from the peg, really? And why would shareholders want some of the funds going to those who place such useless orders? Obviously, some restrictions need to be in place.

Furthermore, it can't simply be a 25%/25%/25%/25% split for each of the criterion. We need to analyze each criteria separately, and deem which should count for more or less weight. Personally, without thinking about it too deeply,  I feel like #3 is more important than #1 is more important than #2 is more important than #4, but this would need a lot of debate to land on something most can agree on.

By the way, I would imagine that determining which side of the book, if any, is weak at any given time is not a trivial matter.  Although it really shouldn't be too difficult to take into account a short time-frame running average of cumulative trades at the ask vs. trades at the bid, and perhaps also comparing short-term price delta to medium-term price delta.  I would imagine that ultimately people will create bots to most effectively take advantage of these reward factors, which is fine because that means they are putting liquidity where we need it most.  Thoughts?
It should not be a problem determining what side of the book is weak. There is a graph of the market depth in the client, so the data points seem to be there and retrievable, but I am not a BTS API expert. @xeroc probably knows?
Title: Re: Subsidizing Market Liquidity
Post by: Empirical1.2 on March 11, 2016, 08:38:16 am
Let me ask you this. Why should someone be allowed to place an order 50% away from the peg and earn any points towards the "reward system"? or 40%? or 30%? How useful are orders that far away from the peg, really? And why would shareholders want some of the funds going to those who place such useless orders? Obviously, some restrictions need to be in place.

 +5%

Given the current BTS momentum and spotlight, BTS will gain much more value from implementing an imperfect liquidity subsidy now and adjusting it based on participant behaviour than waiting a few weeks/months to get one right. So if the cost is reasonable to start one, <$100/200 a day, then I would start it sharpish to build on the current attention and momentum & get more people onto the DEX.
Title: Re: Subsidizing Market Liquidity
Post by: Akado on March 11, 2016, 09:21:22 am
Let me ask you this. Why should someone be allowed to place an order 50% away from the peg and earn any points towards the "reward system"? or 40%? or 30%? How useful are orders that far away from the peg, really? And why would shareholders want some of the funds going to those who place such useless orders? Obviously, some restrictions need to be in place.

 +5%

Given the current BTS momentum and spotlight, BTS will gain much more value from implementing an imperfect liquidity subsidy now and adjusting it based on participant behaviour than waiting a few weeks/months to get one right. So if the cost is reasonable to start one, <$100/200 a day, then I would start it sharpish to build on the current attention and momentum & get more people onto the DEX.

And who would do this? CNX is handling stealth. abit?
Title: Re: Subsidizing Market Liquidity
Post by: Empirical1.2 on March 11, 2016, 11:19:49 am
Let me ask you this. Why should someone be allowed to place an order 50% away from the peg and earn any points towards the "reward system"? or 40%? or 30%? How useful are orders that far away from the peg, really? And why would shareholders want some of the funds going to those who place such useless orders? Obviously, some restrictions need to be in place.

 +5%

Given the current BTS momentum and spotlight, BTS will gain much more value from implementing an imperfect liquidity subsidy now and adjusting it based on participant behaviour than waiting a few weeks/months to get one right. So if the cost is reasonable to start one, <$100/200 a day, then I would start it sharpish to build on the current attention and momentum & get more people onto the DEX.

And who would do this? CNX is handling stealth. abit?

I don't know what's required. Maybe CNX, they get a bit under-appreciated doing the harder/higher cost dev work that doesn't have an immediate impact on BTS price whereas if this gets implemented while BTS has positive momentum, the results should be immediately visible.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 11, 2016, 11:58:16 am
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.

@CoinHoarder, with #1-3, there is already incentive to place orders on either side of the book.  Nasdaq's incentives require placing orders on both the bid and the ask, presumably to promote balance.  Which kind of makes sense, although the point of #4 above is to further recognize that in some market conditions it is more risky to be on one side of the book than the other.  So the point is to provide more incentive to be on the riskier i.e. weak side in order to avoid a situation where market makers pull their orders in fear of getting steamrolled.  At the end of the day, if a market maker wants to put larger orders on the weak side of the book, then that is a good thing and they should earn more.  If they choose not to, then they will earn less and that is up to them.  I don't see what is gameable about this in particular.  If you still disagree with that, can you explain further?

I agree that #4 is useful and should be a part of the equation. I think restrictions should still be implemented in the "liquidity reward system" to increase shareholder's acceptance of the proposal, increase its usefulness to non-participating users (not participating in the "reward system",) and decrease the chances it can be gamed. I feel like implementing restrictions would help in all of those areas.

Let me ask you this. Why should someone be allowed to place an order 50% away from the peg and earn any points towards the "reward system"? or 40%? or 30%? How useful are orders that far away from the peg, really? And why would shareholders want some of the funds going to those who place such useless orders? Obviously, some restrictions need to be in place.

Furthermore, it can't simply be a 25%/25%/25%/25% split for each of the criterion. We need to analyze each criteria separately, and deem which should count for more or less weight. Personally, without thinking about it too deeply,  I feel like #3 is more important than #1 is more important than #2 is more important than #4, but this would need a lot of debate to land on something most can agree on.

I'm still not seeing how #4 can be gamed and what restrictions would prevent it.  But I think we should just get something going and tweak it later, so it would make sense to leave #4 out for now considering that it would be more complicated to specify and track, not to mention it's more of a fine tuning that would make sense to add later anyway. 

As for #3, I think orders deeper in the book definitely have value, just not as much value as those closer to the peg.  So this factor could be used to ensure that orders closer to the peg get rewarded much more than those deeper in the book.  Although for the sake of simplicity, perhaps we should just start with 2 bands around the peg, perhaps 1% and 5%.  Question is, how much more valuable is an order within 1% vs 5%, 2X?  3X?  5X? 

By the way, I'm not sure what you mean by 25%/25%/25%/25% split.  Each factor would have it's own range/set of values and when all factors are combined, each order would generate a score. 

In any event, I would imagine we would set a reward pool for each given period and each market maker could earn a total score for the given period and therefore earn a % of the available rewards depending on their share of the overall total score among all market makers during the period. 
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 11, 2016, 12:04:37 pm
Let me ask you this. Why should someone be allowed to place an order 50% away from the peg and earn any points towards the "reward system"? or 40%? or 30%? How useful are orders that far away from the peg, really? And why would shareholders want some of the funds going to those who place such useless orders? Obviously, some restrictions need to be in place.

 +5%

Given the current BTS momentum and spotlight, BTS will gain much more value from implementing an imperfect liquidity subsidy now and adjusting it based on participant behaviour than waiting a few weeks/months to get one right. So if the cost is reasonable to start one, <$100/200 a day, then I would start it sharpish to build on the current attention and momentum & get more people onto the DEX.

I agree, we should do this ASAP, before momentum dies down. 
Title: Re: Subsidizing Market Liquidity
Post by: xeroc on March 11, 2016, 12:15:34 pm
The best thing to approach CNX is probably to write down a specification to have them get the picture quickyl!
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 15, 2016, 02:07:46 pm
The best thing to approach CNX is probably to write down a specification to have them get the picture quickyl!

@xeroc, is this something you can help with?  I am offering a 10,000 BTS bounty for the worker proposal.
Title: Re: Subsidizing Market Liquidity
Post by: xeroc on March 15, 2016, 02:21:56 pm
The best thing to approach CNX is probably to write down a specification to have them get the picture quickyl!

@xeroc, is this something you can help with?  I am offering a 10,000 BTS bounty for the worker proposal.
I haven't followed the topic closely but I can surely help you bring content into a proper format .. I just don't currently find the time to re-read the threads about this topic
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 15, 2016, 05:04:17 pm
The best thing to approach CNX is probably to write down a specification to have them get the picture quickyl!

@xeroc, is this something you can help with?  I am offering a 10,000 BTS bounty for the worker proposal.
I haven't followed the topic closely but I can surely help you bring content into a proper format .. I just don't currently find the time to re-read the threads about this topic

Considering the overwhelming importance of getting liquidity going, isn't this a matter that the committee should get more involved with? 

Title: Re: Subsidizing Market Liquidity
Post by: xeroc on March 15, 2016, 07:07:09 pm
Absolutely .. the problem is that there are so many things moving and it is next to impossible to get the big picture of what those that discussed in the threads have agreed upon ..
If you put that into a few paragraphs ... we can get this into a nicely formated BSIP quickly!
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on March 15, 2016, 07:11:02 pm
Absolutely .. the problem is that there are so many things moving and it is next to impossible to get the big picture of what those that discussed in the threads have agreed upon ..
If you put that into a few paragraphs ... we can get this into a nicely formated BSIP quickly!

i agree, plus these threads become quite long and tough to follow, especially for important topics.
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on March 15, 2016, 07:21:41 pm
Absolutely .. the problem is that there are so many things moving and it is next to impossible to get the big picture of what those that discussed in the threads have agreed upon ..
If you put that into a few paragraphs ... we can get this into a nicely formated BSIP quickly!

absolutely...take it behind closed doors and discus it between 15 other people who have been to busy to read the thread.
Title: Re: Subsidizing Market Liquidity
Post by: abit on March 15, 2016, 08:01:16 pm
Absolutely .. the problem is that there are so many things moving and it is next to impossible to get the big picture of what those that discussed in the threads have agreed upon ..
If you put that into a few paragraphs ... we can get this into a nicely formated BSIP quickly!

absolutely...take it behind closed doors and discus it between 15 other people who have been to busy to read the thread.
15 people? I thought only 5~6 people behind the door.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 17, 2016, 03:23:47 pm
Absolutely .. the problem is that there are so many things moving and it is next to impossible to get the big picture of what those that discussed in the threads have agreed upon ..
If you put that into a few paragraphs ... we can get this into a nicely formated BSIP quickly!

For multiple reasons, I am not the right person to take this and run with it. So I'm not sure how this matter will move forward since it appears few are taking it seriously.  Which seems odd considering that bootstrapping liquidity (especially for the major fiat BitAssets) seems to be of critical importance.  Or am I missing something?
Title: Re: Subsidizing Market Liquidity
Post by: karnal on March 17, 2016, 03:29:06 pm
What would you guys say is stopping most people from creating the bitassets themselves and putting them up for sale?
Title: Re: Subsidizing Market Liquidity
Post by: yvv on March 17, 2016, 03:49:10 pm
What would you guys say is stopping most people from creating the bitassets themselves and putting them up for sale?

My bet, people just don't know what to do with them. Imo, the best way is to issue bitAsset, and trade back and forth against UIA which is pegged to underlying asset, like bitUSD <-> OPEN.USD, bitBTC <-> OPEN.BTC (TRADE.BTC, META.BTC) etc. This way you keep the peg tight, provide liquidity for gateways and hedge yourself against BTS volatility.

Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 17, 2016, 04:01:16 pm
What would you guys say is stopping most people from creating the bitassets themselves and putting them up for sale?

We need a more coordinated, systematic approach including subsidies for providing liquidity.  Perhaps then market makers would step up to the plate.  Actually, I'm pretty surprised that blocktrades, metaexchange and CCEDK haven't come together to provide some leadership on this matter and work with the community to find solutions.   
Title: Re: Subsidizing Market Liquidity
Post by: roadscape on March 17, 2016, 06:45:44 pm
Absolutely .. the problem is that there are so many things moving and it is next to impossible to get the big picture of what those that discussed in the threads have agreed upon ..
If you put that into a few paragraphs ... we can get this into a nicely formated BSIP quickly!

For multiple reasons, I am not the right person to take this and run with it. So I'm not sure how this matter will move forward since it appears few are taking it seriously.  Which seems odd considering that bootstrapping liquidity (especially for the major fiat BitAssets) seems to be of critical importance.  Or am I missing something?

There's been 12 pages of discussion, it would be nice if someone could sum it up in a single clean document so that it can be easily digested by more people. Even if it was literally just copy-and-paste snippets of notable points.

I saw some important variables were identified (length of time on the books, distance/spread, etc), but have any *reward equations* been proposed? This is the hardest & most important part. What variables do we measure and how do we combine them into a single score.
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on March 17, 2016, 07:09:32 pm

There's been 12 pages of discussion, it would be nice if someone could sum it up in a single clean document so that it can be easily digested by more people. Even if it was literally just copy-and-paste snippets of notable points.

I saw some important variables were identified (length of time on the books, distance/spread, etc), but have any *reward equations* been proposed? This is the hardest & most important part. What variables do we measure and how do we combine them into a single score.

My response to earlier xeroc's post is pretty close to a pseudo code... reposting will not help reducing the pages from 12...quite the opposite. [feel free to put in better English, if you see a need to do so]
Others have suggested additions which are generally cool and good, but from my point of view they needlessly complicate the algo for little bit of fine tuning.
Title: Re: Subsidizing Market Liquidity
Post by: CoinHoarder on March 18, 2016, 12:48:07 am
My response to earlier xeroc's post is pretty close to a pseudo code... reposting will not help reducing the pages from 12...quite the opposite.

I think your psuedo code is a good starting point.

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. 


I don't however agree that there should be a 150 bitUSD limit for an order to gain points for the reward. Isn't a 1000 bitUSD order more valuable to BTS shareholders (and users) than a 150 bitUSD order? It seems wrong.. the person providing more liquidity should earn a bigger portion of the rewards.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on March 18, 2016, 01:28:28 am
All this brainstorming about liquidity, and I can't even get into my OL wallet to place trades right now. We really need to get a reliable platform working before anything else. Count me out for adding liquidity to markets tonight, which sucks with the big BTS move. i hate not being able to access my positions to update them in the face of this kind of volatility.
Title: Re: Subsidizing Market Liquidity
Post by: yvv on March 18, 2016, 01:43:03 am
All this brainstorming about liquidity, and I can't even get into my OL wallet to place trades right now. We really need to get a reliable platform working before anything else. Count me out for adding liquidity to markets tonight, which sucks with the big BTS move. i hate not being able to access my positions to update them in the face of this kind of volatility.

Try another client. Dowloadable client works well. Also, there is one at https://bitshares.org/wallet and another one hosted by bitcash but I lost the link.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on March 18, 2016, 01:54:40 am
All this brainstorming about liquidity, and I can't even get into my OL wallet to place trades right now. We really need to get a reliable platform working before anything else. Count me out for adding liquidity to markets tonight, which sucks with the big BTS move. i hate not being able to access my positions to update them in the face of this kind of volatility.

Try another client. Dowloadable client works well. Also, there is one at https://bitshares.org/wallet and another one hosted by bitcash but I lost the link.

great, thank you @yvv ...the bitshares.org wallet works perfectly.
Title: Re: Subsidizing Market Liquidity
Post by: yvv on March 18, 2016, 02:04:54 am
All this brainstorming about liquidity, and I can't even get into my OL wallet to place trades right now. We really need to get a reliable platform working before anything else. Count me out for adding liquidity to markets tonight, which sucks with the big BTS move. i hate not being able to access my positions to update them in the face of this kind of volatility.

Try another client. Dowloadable client works well. Also, there is one at https://bitshares.org/wallet and another one hosted by bitcash but I lost the link.

great, thank you @yvv ...the bitshares.org wallet works perfectly.

@cylonmaker2053 If you have difficulty connecting to bitshares.openledger.info API server, go to settings, click on "API connection" and select dele-puppy.com from the list. We don't really depend on OL, and this is good.
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on March 18, 2016, 02:38:19 am
My response to earlier xeroc's post is pretty close to a pseudo code... reposting will not help reducing the pages from 12...quite the opposite.

I think your psuedo code is a good starting point.

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. 


I don't however agree that there should be a 150 bitUSD limit for an order to gain points for the reward. Isn't a 1000 bitUSD order more valuable to BTS shareholders (and users) than a 150 bitUSD order? It seems wrong.. the person providing more liquidity should earn a bigger portion of the rewards.

1. All numbers here are just that - numbers. I see them, as explained in the post, as parameters for the committee to adjust as more info is gathered by watching the algo and its performance meeting the reality.

That being said:
- the logic behind 'min 5% of the time being the best bid ask' - 5% do seem low (I actually think we should start with something like 10% - BUT keep in mind it limits the max allowable number of MMakers that get paid - setting it 30% will mean a max of int [3.33] of 3 accounts can be paid in a given market. Do we want that? Idk, seems too low to me.

-there is a very good reason why Nasdaq pays for 500 shares and do not pay proportionally more  for 600 or especially 6000 shares. - The idea is not to encourage big orders for relatively short periods but orders with enough size all the time....

-on the size of "150 bitUSD" - it is my personal (subjective) bare min. number. if we can start with 500 it would be better of course.... My only note here is to keep in mind this is MIN to qualify for the reward...one would  think that any reasonable market maker will start with at 2-3 times (maybe more) bigger orders, just so he must not constantly 'refill' the orders, as the already placed orders get matched.

2bts
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 18, 2016, 04:07:10 am
Absolutely .. the problem is that there are so many things moving and it is next to impossible to get the big picture of what those that discussed in the threads have agreed upon ..
If you put that into a few paragraphs ... we can get this into a nicely formated BSIP quickly!

For multiple reasons, I am not the right person to take this and run with it. So I'm not sure how this matter will move forward since it appears few are taking it seriously.  Which seems odd considering that bootstrapping liquidity (especially for the major fiat BitAssets) seems to be of critical importance.  Or am I missing something?

There's been 12 pages of discussion, it would be nice if someone could sum it up in a single clean document so that it can be easily digested by more people. Even if it was literally just copy-and-paste snippets of notable points.

I saw some important variables were identified (length of time on the books, distance/spread, etc), but have any *reward equations* been proposed? This is the hardest & most important part. What variables do we measure and how do we combine them into a single score.

No equation has been proposed so far.  We have only identified the primary factors.   So we need to come up with values and weightings and combine them into an equation.  Perhaps that's something you can take a stab at?  I've listed the factors again here: 

1. order size
2. time on book
3. distance from price feed
4. bid/ask balance

For the most effective possible application of #4, we need to figure out how to measure which side needs more liquidity (aka the "weak" side) at any given time (i.e. the ask side in a market trending higher, the bid side in a market trending lower) and factor that into the scoring.  However, some have suggested we should leave that for fine-tuning at a later date.  I tend to agree.  So for starters, perhaps we should simply reward equal liquidity to the bid side and to the ask side. 

Also, although orders further away from the price feed have value since they can provide market stability, for starters we should simply reward liquidity at and near the price feed, perhaps using 2 bands, say 1% and 5% around the price feed. 

We also need to start thinking about how much in funding we want to make available to pay rewards.  @Empirical1.2 threw out $100-200 per day as a potential starting point.  That would represent 4-8% of total funds available for worker proposals.  Perhaps we should go with the higher end of that, if politically feasible.

The other question is how much to apply to which markets.  Clearly we should be looking to boost liquidity in the major fiat BitAsset markets, primarily USD and CNY.  But also EUR to a lesser extent.  Perhaps the split between USD and CNY can be roughly according to exchange rate.  And then carve out a % for EUR.  So perhaps 80%/15%/5% for USD, CNY, and EUR respectively.   

Thanks for looking at this, @roadscape.
Title: Re: Subsidizing Market Liquidity
Post by: compumatrix on March 18, 2016, 04:35:24 am
I would like to propose a new feature for BTS that CNX will provide free of charge if a hard fork is approved.

We would like to allow any market pair to reward users who provide liquidity in that market. The feature would work as follows:

Every order that is filled after being open on the books for at least 10 minutes earns shares a reward pool. The shares earned are proportional to the size of the order filled.

Any user *or* worker can contribute funds to the reward pool. These funds can be denominated in any asset specified by the issuer.

At most once per day users may convert their shares in the reward pool to a pro-rata share of the rewards.

The asset issuer has the ability to enable this feature for any market their asset trades in and to specify the asset used to fund the reward pool.

With this feature Open Ledger *could* pay out OBITS to those who provide liquidity in the OPEN.BTC / BTS market.
BTS can vote for a worker to provide liquidity in the BTS / USD and BTS / CNY markets.

It is possible that trades in the BTS / OPEN.BTC market could earn rewards from both BTS and OBITS *if* shareholders voted to subsidize this market.

Assuming we implement this feature in the BTS / USD market and voters approve workers funding this at a rate of 2.5 BTS / sec (50% of allowed dilution) and the internal exchange had $100,000 of daily volume then users trading on the internal exchange would see a 1% more than they would get by trading off chain. If daily volume was $50,000 then they would see a 2% profit over doing the same trades off-chain.

The impact of this should be a major influx of new traders who can make more money trading on the internal exchange than the external exchange. This added liquidity will dramatically tighten the USD / BTS peg and give shorters much more confidence.

This implementation will require 3 new operations on the blockchain:

1. create_liquidity_reward_pool issuer ASSET FUND_ASSET MARKET_ASSET    ie: openledger OBIT OPEN.BTC OPEN.USD
2. fund_liquidity_reward_pool funding_account AMOUNT FUND_ASSET ASSET MARKET_ASSET
3. claim_liquidity_rewards username AMOUNT FUND_ASSET  ASSET MARKET_ASSET

It will also create a new worker type that can direct BTS to any fund where FUND_ASSET is BTS.



Note: CNX reserves the right to retract this offer or request payment for adding this feature. This proposal does not commit CNX to develop the feature if we decide to pursue other options.


Excellent proposal.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 18, 2016, 05:45:09 am
I would like to propose a new feature for BTS that CNX will provide free of charge if a hard fork is approved.

We would like to allow any market pair to reward users who provide liquidity in that market. The feature would work as follows:

Every order that is filled after being open on the books for at least 10 minutes earns shares a reward pool. The shares earned are proportional to the size of the order filled.

Any user *or* worker can contribute funds to the reward pool. These funds can be denominated in any asset specified by the issuer.

At most once per day users may convert their shares in the reward pool to a pro-rata share of the rewards.

The asset issuer has the ability to enable this feature for any market their asset trades in and to specify the asset used to fund the reward pool.

With this feature Open Ledger *could* pay out OBITS to those who provide liquidity in the OPEN.BTC / BTS market.
BTS can vote for a worker to provide liquidity in the BTS / USD and BTS / CNY markets.

It is possible that trades in the BTS / OPEN.BTC market could earn rewards from both BTS and OBITS *if* shareholders voted to subsidize this market.

Assuming we implement this feature in the BTS / USD market and voters approve workers funding this at a rate of 2.5 BTS / sec (50% of allowed dilution) and the internal exchange had $100,000 of daily volume then users trading on the internal exchange would see a 1% more than they would get by trading off chain. If daily volume was $50,000 then they would see a 2% profit over doing the same trades off-chain.

The impact of this should be a major influx of new traders who can make more money trading on the internal exchange than the external exchange. This added liquidity will dramatically tighten the USD / BTS peg and give shorters much more confidence.

This implementation will require 3 new operations on the blockchain:

1. create_liquidity_reward_pool issuer ASSET FUND_ASSET MARKET_ASSET    ie: openledger OBIT OPEN.BTC OPEN.USD
2. fund_liquidity_reward_pool funding_account AMOUNT FUND_ASSET ASSET MARKET_ASSET
3. claim_liquidity_rewards username AMOUNT FUND_ASSET  ASSET MARKET_ASSET

It will also create a new worker type that can direct BTS to any fund where FUND_ASSET is BTS.



Note: CNX reserves the right to retract this offer or request payment for adding this feature. This proposal does not commit CNX to develop the feature if we decide to pursue other options.


Excellent proposal.

I believe the proposal you've cited is outdated. Since then, if I'm not mistaken bytemaster has shown support for the direction this thread has been going, and has chimed in to state that he believes the reward calculations we'd been discussing should be done off-chain.  Also, one of the things we've concluded on this thread, with some guidance from Nasdaq's liquidity incentive program, is that instead of rewarding trades (which we can't guarantee won't be gamed), we should simply reward liquidity (i.e. placement of orders on the book).  In which case, a share of rewards would not be earned when a fill takes place.  Instead, rewards would be earned based on scores during any given period, with the scores calculated based on how many shares were on the book, for how long, and how close to the price feed.  Hopefully we can build on this and move it toward reality ASAP.

Title: Re: Subsidizing Market Liquidity
Post by: tonyk on March 18, 2016, 05:55:49 am
I would like to propose a new feature for BTS that CNX will provide free of charge if a hard fork is approved.

We would like to allow any market pair to reward users who provide liquidity in that market. The feature would work as follows:

Every order that is filled after being open on the books for at least 10 minutes earns shares a reward pool. The shares earned are proportional to the size of the order filled.

Any user *or* worker can contribute funds to the reward pool. These funds can be denominated in any asset specified by the issuer.

At most once per day users may convert their shares in the reward pool to a pro-rata share of the rewards.

The asset issuer has the ability to enable this feature for any market their asset trades in and to specify the asset used to fund the reward pool.

With this feature Open Ledger *could* pay out OBITS to those who provide liquidity in the OPEN.BTC / BTS market.
BTS can vote for a worker to provide liquidity in the BTS / USD and BTS / CNY markets.

It is possible that trades in the BTS / OPEN.BTC market could earn rewards from both BTS and OBITS *if* shareholders voted to subsidize this market.

Assuming we implement this feature in the BTS / USD market and voters approve workers funding this at a rate of 2.5 BTS / sec (50% of allowed dilution) and the internal exchange had $100,000 of daily volume then users trading on the internal exchange would see a 1% more than they would get by trading off chain. If daily volume was $50,000 then they would see a 2% profit over doing the same trades off-chain.

The impact of this should be a major influx of new traders who can make more money trading on the internal exchange than the external exchange. This added liquidity will dramatically tighten the USD / BTS peg and give shorters much more confidence.

This implementation will require 3 new operations on the blockchain:

1. create_liquidity_reward_pool issuer ASSET FUND_ASSET MARKET_ASSET    ie: openledger OBIT OPEN.BTC OPEN.USD
2. fund_liquidity_reward_pool funding_account AMOUNT FUND_ASSET ASSET MARKET_ASSET
3. claim_liquidity_rewards username AMOUNT FUND_ASSET  ASSET MARKET_ASSET

It will also create a new worker type that can direct BTS to any fund where FUND_ASSET is BTS.



Note: CNX reserves the right to retract this offer or request payment for adding this feature. This proposal does not commit CNX to develop the feature if we decide to pursue other options.


Excellent proposal.

I believe the proposal you've cited is outdated. Since then, if I'm not mistaken bytemaster has shown support for the direction this thread has been going, and has chimed in to state that he believes the reward calculations we'd been discussing should be done off-chain.  Also, one of the things we've concluded on this thread, with some guidance from Nasdaq's liquidity incentive program, is that instead of rewarding trades (which we can't guarantee won't be gamed), we should simply reward liquidity (i.e. placement of orders on the book).  In which case, a share of rewards would not be earned when a fill takes place.  Instead, rewards would be earned based on scores during any given period, with the scores calculated based on how many shares were on the book, for how long, and how close to the price feed.  Hopefully we can build on this and move it toward reality ASAP.
+ 1
Yes the proposal in its initial form is pretty bad actually....and the people who really care about seeing this really working.... as in working good in practice, have thrown there two cents to make it a decent if not great solution.[we still have our own biases on which will work best, but the main point is - there is a much better way to do this and the better solution is not that much harder to do... ]
Title: Re: Subsidizing Market Liquidity
Post by: Erlich Bachman on March 18, 2016, 07:52:18 am
But when will it get implemented?










Tune in again tomorrow, for another exciting edition of....


Beyonde Bitcoyne

10AM yo
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on March 18, 2016, 01:02:38 pm
All this brainstorming about liquidity, and I can't even get into my OL wallet to place trades right now. We really need to get a reliable platform working before anything else. Count me out for adding liquidity to markets tonight, which sucks with the big BTS move. i hate not being able to access my positions to update them in the face of this kind of volatility.

Try another client. Dowloadable client works well. Also, there is one at https://bitshares.org/wallet and another one hosted by bitcash but I lost the link.

great, thank you @yvv ...the bitshares.org wallet works perfectly.

@cylonmaker2053 If you have difficulty connecting to bitshares.openledger.info API server, go to settings, click on "API connection" and select dele-puppy.com from the list. We don't really depend on OL, and this is good.

Thanks again @yvv ...i've used the puppy API before, but last night i couldn't even get to the point where i could switch connections.
Title: Re: Subsidizing Market Liquidity
Post by: roadscape on March 21, 2016, 06:58:00 pm
Thanks guys for summing it up. It looks like @tonyk has the only developed idea, but it might take me longer to fully comprehend it than to offer my own. I'll begin with what I think might be the easiest/most accessible way to score market makers and if it makes sense we can meet in the middle:

For each subsidized market, every hour:

 - Let P = "center point" of the market. (Feed price? Center of spread?)
 - Take a snapshot of the order book
 - Ignore all orders (a) more than 5% away from P or (b) less than 60 minutes old

Score the remaining (i.e. eligible) orders, and sum up *per side/account*

 - score = (order_size / side_total) * (1 + distance_bonus)
   - order_total = size of the sell (ask or bid side).
   - side_total = sum of all eligible orders on the ask or bid side
   - distance_bonus = ((max_distance - distance) / max_distance) (0% off feed = 1 ; 5% off feed = 0)

If we wanted to force balanced market making, then the final score per account is MIN(bid_score, ask_score).

(At this point, we could also discard any scores that are, say, below 25th percentile.)

100% of the reward per hour is split proportionally to the scores in this round. Payouts occur every 7 days.

-------

You get the optimal reward only if your bid/ask is balanced. One side can be smaller and closer to the peg yet still be balanced. Reward is based on your relative ownership of the eligible part of the bid/ask walls. Scalable bonus for how tight your walls are (up to 100% bonus for trading at the center of the market).
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on March 21, 2016, 07:41:03 pm
Thanks guys for summing it up. It looks like @tonyk has the only developed idea, but it might take me longer to fully comprehend it than to offer my own. I'll begin with what I think might be the easiest/most accessible way to score market makers and if it makes sense we can meet in the middle:

For each subsidized marketScore the remaining (i.e. eligible) orders, and sum up *per side/account*, every hour:

 - Let P = "center point" of the market. (Feed price? Center of spread?)
 - Take a snapshot of the order book
 - Ignore all orders (a) more than 5% away from P or (b) less than 60 minutes old



 - score = (order_size / side_total) * (1 + distance_bonus)
   - order_total = size of the sell (ask or bid side).
   - side_total = sum of all eligible orders on the ask or bid side
   - distance_bonus = ((max_distance - distance) / max_distance) (0% off feed = 1 ; 5% off feed = 0)

If we wanted to force balanced market making, then the final score per account is MIN(bid_score, ask_score).

(At this point, we could also discard any scores that are, say, below 25th percentile.)

100% of the reward per hour is split proportionally to the scores in this round. Payouts occur every 7 days.

-------

You get the optimal reward only if your bid/ask is balanced. One side can be smaller and closer to the peg yet still be balanced. Reward is based on your relative ownership of the eligible part of the bid/ask walls. Scalable bonus for how tight your walls are (up to 100% bonus for trading at the center of the market).

This could work, with a few modifications.

*Modified part in italic in the original proposal if not explicitly quoted here
1)
" every hour:

 - Let P = "center point" of the market. (Feed price? Center of spread?)
 - Take a snapshot of the order book
 - Ignore all orders (a) more than 5% away from P or (b) less than 60 minutes old
"

becomes:
Every Time a new order is placed in that market:

 - Let P = "center point" of the market. (Feed price? Center of spread?)
 - Take a snapshot of the order book
 - Ignore all orders (a) more than 5% away from P
 - ignore the newly placed order

T = time since last snapshot

2)
score = (order_size / side_total) * (1 + distance_bonus) * T

3)
order_total = MIN (size of the sell (ask or bid side), maxOrder bitUSD)
maxOrder = the max order that qualifies for a bonus
 *[ we do not want orders for 50, 000 USD  existing for small periods of time to take away all the bonuses]; we can start with something like maxOrder =  500-1000 USD

//EDIT
NB depending how filled orders are handled in bts a solution how exactly to do this must be made BUT:
If any order is filled due to this newly placed order, the filled order(s) should be included in the calculations above for that round of rewards
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on March 22, 2016, 02:02:34 am
This could work, with a few modifications.

*Modified part in italic in the original proposal if not explicitly quoted here
1)
" every hour:

 - Let P = "center point" of the market. (Feed price? Center of spread?)
 - Take a snapshot of the order book
 - Ignore all orders (a) more than 5% away from P or (b) less than 60 minutes old
"

becomes:
Every Time a new order is placed in that market:

 - Let P = "center point" of the market. (Feed price? Center of spread?)
 - Take a snapshot of the order book
 - Ignore all orders (a) more than 5% away from P
 - ignore the newly placed order

T = time since last snapshot

2)
score = (order_size / side_total) * (1 + distance_bonus) * T

3)
order_total = MIN (size of the sell (ask or bid side), maxOrder bitUSD)
maxOrder = the max order that qualifies for a bonus
 *[ we do not want orders for 50, 000 USD  existing for small periods of time to take away all the bonuses]; we can start with something like maxOrder =  500-1000 USD

//EDIT
NB depending how filled orders are handled in bts a solution how exactly to do this must be made BUT:
If any order is filled due to this newly placed order, the filled order(s) should be included in the calculations above for that round of rewards

looks like a solid first cut, but i'd recommend expanding the range from midpoint for relevance. 5% from midpoint doesn't capture much of current action, so i'd widen that to something like 20%. yes, orders on the margin matter most, but market depth expanding out from the margin also counts.
Title: Re: Subsidizing Market Liquidity
Post by: roadscape on March 22, 2016, 02:24:45 pm
@tonyk Your proposed changes make sense, but continuous monitoring is much more complex than sampling*. What does it capture that sampling can't? And what if samples were e.g. 15 mins apart?

@cylonmaker2053 20% seems a bit high if we're trying to maintain a tight peg, no? For other markets it might make sense but imho for *stable* coins it should be a tight band.


Also: should we use the feed price or the center of the spread for P? (My preference would be to not rely on feed price if possible)

* more complex to implement, and correctly. and if anything goes wrong it may be difficult to "replay" the events because we don't have historical orderbook API. at any rate, this would have to be an open source script/daemon that multiple people run and cross-check results. and this, too, will be much easier if we deal with snapshots rather than streams of data. not ruling anything out but I'd like to make sure we exhaust the simplest options.
Title: Re: Subsidizing Market Liquidity
Post by: abit on March 22, 2016, 05:15:50 pm
The very basic feature to support this, is a plugin to "take snapshots" and provide required data. Implement it as a plugin so it won't affect the main functionality of the witness node, and can be enabled only when needed.

Quote
NB depending how filled orders are handled in bts a solution how exactly to do this must be made BUT:
If any order is filled due to this newly placed order, the filled order(s) should be included in the calculations above for that round of rewards
So you're talking about calculating points *before* a new order is placed, and take a new snapshot after filled. Doable.


By the way, if we're going to do this in USD/BTS market, no need to subsidize buy (BTS) side imo due to force settlement already provides liquidity. However, technically we can implement it as a parameter so it can be disabled in some markets, but enabled in other markets.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 22, 2016, 07:21:37 pm
@tonyk Your proposed changes make sense, but continuous monitoring is much more complex than sampling*. What does it capture that sampling can't? And what if samples were e.g. 15 mins apart?

* more complex to implement, and correctly. and if anything goes wrong it may be difficult to "replay" the events because we don't have historical orderbook API. at any rate, this would have to be an open source script/daemon that multiple people run and cross-check results. and this, too, will be much easier if we deal with snapshots rather than streams of data. not ruling anything out but I'd like to make sure we exhaust the simplest options.

I don't see how we can do meaningful scoring with 1-hour snapshots.  But without a way to replay events, I have no idea what the answer is.

@cylonmaker2053 20% seems a bit high if we're trying to maintain a tight peg, no? For other markets it might make sense but imho for *stable* coins it should be a tight band.

I think it's beneficial to have a deep order book, especially if black swans are a risk.  So we could reward orders deeper in the book, just not nearly as much.  For example, perhaps x reward within 2% of the peg.  Then maybe 1/5x between 2 and 5%.  And then maybe 1/20x between 5 and 20%, or something along those lines.  This way we encourage both a tight peg and a deep order book.   
 
Also: should we use the feed price or the center of the spread for P? (My preference would be to not rely on feed price if possible)

I think this has to be the price feed. Otherwise we may reward a tight spread, but around what price?
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on March 22, 2016, 07:29:12 pm
tonyk Your proposed changes make sense, but continuous monitoring is much more complex than sampling*. What does it capture that sampling can't? And what if samples were e.g. 15 mins apart?

@roadscape
OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####
---------------------------------------
As much as do not like using the feed price either.... very often currently we have
feed price 100BTS/USD
best bid 107
best ask 112

So the question is - do we really want to give a subsidy to this bid price at 7% above the peg? For me personally the answer is NO.

----------------------------------------
By the way, if we're going to do this in USD/BTS market, no need to subsidize buy (BTS) side imo due to force settlement already provides liquidity. However, technically we can implement it as a parameter so it can be disabled in some markets, but enabled in other markets.

Very good points and approach. + 1

------------------
@tbone
I finally found a post of yours I agree on all counts. The only thing about this layered approach is that it adds more complexity. Not impossibly high coding wise I guess[at worst they will have to run main code 3 times and check for orders in that interval [P<=2%;  2% < P < =5%;  5% < P <=20%], but lets se what the real coders think.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on March 23, 2016, 02:08:50 am
I think it's beneficial to have a deep order book, especially if black swans are a risk.  So we could reward orders deeper in the book, just not nearly as much.  For example, perhaps x reward within 2% of the peg.  Then maybe 1/5x between 2 and 5%.  And then maybe 1/20x between 5 and 20%, or something along those lines.  This way we encourage both a tight peg and a deep order book.   

yes, some weighting scheme by distance to bid/ask midpiont would be a good idea to try out. i agree with the value of a deep order book, but "deep" order book is very relative for us since USD 1,000 or so equivalent for any of the assets is enough to eat through most of the order books. also note that it only takes something like a 20%-30% move in BTS to "break" most of our markets, which is hardly a black swan; that kind of rapid shift in settlement price churns through most open orders pretty fast, especially for those of us trying to keep these markets liquid without bots. wide margins should be part of this scheme to make it useful.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on March 23, 2016, 02:13:30 am
@cylonmaker2053 20% seems a bit high if we're trying to maintain a tight peg, no? For other markets it might make sense but imho for *stable* coins it should be a tight band.

true, i'd just like to see a tight range based on our markets functioning property with plenty of natural liquidity, not based purely on subsidies. i like the idea of a weighted subsidy based on distance from bid/ask midpoint, but extending at least 20% deep into the order book, maybe even further, just having the rewards diminishing with distance.

any way we cut it is fine since this should be a measured experiment and we can learn from what works and doesn't.
Title: Re: Subsidizing Market Liquidity
Post by: roadscape on March 23, 2016, 01:41:19 pm
@abit if you think any part of this can be done from within graphene, that's great. I've been looking at it from an API perspective.

@tbone @cylonmaker2053 currently the scoring bonus is linear: 100% bonus @ the midpoint, and 0% bonus at 5% off. This could be scaled to a wider range, and we could also use a curve instead of a line (creating a "long tail") for the bonus.

tonyk Your proposed changes make sense, but continuous monitoring is much more complex than sampling*. What does it capture that sampling can't? And what if samples were e.g. 15 mins apart?

@roadscape
OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

My question is, what scenario are you trying to avoid (or create) by doing this?

If your order is on the books for 120 mins, and is *completely* filled at minute 125, you would not get credit for those last 5 minutes (assuming 10-minute snapshot interval). To me this doesn't seem like a problem.

If you expect orders to be on the books for less than 10 minutes at a time, I could see why we would need to be tracking this more detailed order activity.

My original line of thinking was a simple "sharedrop" of points onto order book participants at a regular interval.

My assumptions for MM subsidies:
1) The actual market activity doesn't matter nearly as much as creating a nicely-shaped order book.
2) 'Sampling' the order book every ~10 minutes is at least 95% as accurate as analyzing continuous data.
Title: Re: Subsidizing Market Liquidity
Post by: abit on March 23, 2016, 07:45:18 pm
@roadscape I prefer to calculate with full data rather than with sample data. I'm going to write a snapshot plugin.

Data structure of one market pair (for example BTS/USD):
* a calculation period = snapshots
* a snapshot = time stamp, feed price, ask orders, bid orders
* a order = direction(ask/bid), price, volume, owner, create_time

Calculations:
[Note: the algorithm below is based on feed price, but not on "best prices"]
* at the beginning of a calculation period, take a snapshot, set everyone's score = 0
* Every time (after a new block is produced) when a new order is created or cancelled, or feed price is updated, or reached the end of a calculation period, take a new snapshot.
 -> let LT= last snapshot time
     let T = current snapshot time
     let LFP = feed price of last snapshot
 -> for each order,
     let LV=volume of last snapshot,
     calculate LV' = function1 (direction, price, LFP, LV), to filter out unqualified orders
     calculate new score gained by this order after last snapshot
          NOS = function2 (direction,LV', LT, T, create_time, price, LFP)
          note: create_time may be needed here to judge whether this order is qualified.
 -> for each account(owner) on each side,
     let LAS = score on last snapshot
     calculate TLV = sum(LV'), total volume of qualified orders at last snapshot
     calculate ELV = function3(TLV), to filter out unqualified account if total volume is too low
     calculate TNS = sum(NOS), total new score gained
     calculate ENS = function4(TNS,ELV), to filter out too low total score/volume, and perhaps set a cap on new score
     calculate AS = LAS + ENS, final score at this snapshot
* at the end of a calculation period, for each side, we have a set of (account, score), so we can calculate the final rewards.

//Update: I'm going to write a plugin to provide snapshot data, so you guys can use it to do whatever calculation as you like.
Title: Re: Subsidizing Market Liquidity
Post by: cylonmaker2053 on March 24, 2016, 01:01:38 am
@tbone @cylonmaker2053 currently the scoring bonus is linear: 100% bonus @ the midpoint, and 0% bonus at 5% off. This could be scaled to a wider range, and we could also use a curve instead of a line (creating a "long tail") for the bonus.

yes, wider margin (like 20%+) would be the most important change. linear is fine as long as the margin is wider, but curved with weights trailing off towards the tails would be best.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 24, 2016, 02:54:59 am
@abit if you think any part of this can be done from within graphene, that's great. I've been looking at it from an API perspective.

@tbone @cylonmaker2053 currently the scoring bonus is linear: 100% bonus @ the midpoint, and 0% bonus at 5% off. This could be scaled to a wider range, and we could also use a curve instead of a line (creating a "long tail") for the bonus.

tonyk Your proposed changes make sense, but continuous monitoring is much more complex than sampling*. What does it capture that sampling can't? And what if samples were e.g. 15 mins apart?

@roadscape
OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

My question is, what scenario are you trying to avoid (or create) by doing this?

If your order is on the books for 120 mins, and is *completely* filled at minute 125, you would not get credit for those last 5 minutes (assuming 10-minute snapshot interval). To me this doesn't seem like a problem.

If you expect orders to be on the books for less than 10 minutes at a time, I could see why we would need to be tracking this more detailed order activity.

My original line of thinking was a simple "sharedrop" of points onto order book participants at a regular interval.

My assumptions for MM subsidies:
1) The actual market activity doesn't matter nearly as much as creating a nicely-shaped order book.
2) 'Sampling' the order book every ~10 minutes is at least 95% as accurate as analyzing continuous data.

@roadscape: Many orders will be on the books for much less than 10 minutes.  So I think sampling every 10 minutes will yield somewhat arbitrary results.  On the other hand, I imagine constant monitoring would be too resource intensive?  If so, how about sampling every 1 minute?  I don't think it would yield perfect results, but probably more than good enough, and I'm guessing without being too unreasonably resource intensive.  Thoughts?  @abits, can you comment on this as well?

Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 24, 2016, 03:00:37 am
@tbone @cylonmaker2053 currently the scoring bonus is linear: 100% bonus @ the midpoint, and 0% bonus at 5% off. This could be scaled to a wider range, and we could also use a curve instead of a line (creating a "long tail") for the bonus.

yes, wider margin (like 20%+) would be the most important change. linear is fine as long as the margin is wider, but curved with weights trailing off towards the tails would be best.

I agree with these points.
Title: Re: Subsidizing Market Liquidity
Post by: tonyk on March 24, 2016, 03:37:52 am
tonyk Your proposed changes make sense, but continuous monitoring is much more complex than sampling*. What does it capture that sampling can't? And what if samples were e.g. 15 mins apart?

@roadscape
OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

My question is, what scenario are you trying to avoid (or create) by doing this?

If your order is on the books for 120 mins, and is *completely* filled at minute 125, you would not get credit for those last 5 minutes (assuming 10-minute snapshot interval). To me this doesn't seem like a problem.

If you expect orders to be on the books for less than 10 minutes at a time, I could see why we would need to be tracking this more detailed order activity.

My original line of thinking was a simple "sharedrop" of points onto order book participants at a regular interval.

My assumptions for MM subsidies:
1) The actual market activity doesn't matter nearly as much as creating a nicely-shaped order book.
2) 'Sampling' the order book every ~10 minutes is at least 95% as accurate as analyzing continuous data.
Obviously (I thought), I am trying to avoid orders being on the order book for 30% -99% of the time between sample taking, and such orders getting no credit at all. To say nothing about such orders being filled first, means they had the best prices of all orders!!!
The less the time between sample taking the less an issue this becomes, but your original proposal was every 1 h. (way too long in my view). The smaller the time between each sample taking the less an issue it is. (so if you cut it to 3-5-7 min, this is a one way to do it)
Yet, again the proposed solution will yield ' near perfect'* results even if you sample far less frequently... and the computations involved seem to take not too much recourses.

* It is not perfect, cause if you sample once every hour, you should also credit the "placed and subsequently cancelled" orders, meeting all other criteria, in that time frame.
Title: Re: Subsidizing Market Liquidity
Post by: abit on March 25, 2016, 12:07:34 pm
Do we need to subsidize force settlement orders and/or call orders (collateral holders)?
Title: Re: Subsidizing Market Liquidity
Post by: roadscape on March 25, 2016, 11:15:04 pm
@roadscape I prefer to calculate with full data rather than with sample data. I'm going to write a snapshot plugin.

Data structure of one market pair (for example BTS/USD):
* a calculation period = snapshots
* a snapshot = time stamp, feed price, ask orders, bid orders
* a order = direction(ask/bid), price, volume, owner, create_time

Calculations:
[Note: the algorithm below is based on feed price, but not on "best prices"]
* at the beginning of a calculation period, take a snapshot, set everyone's score = 0
* Every time (after a new block is produced) when a new order is created or cancelled, or feed price is updated, or reached the end of a calculation period, take a new snapshot.
 -> let LT= last snapshot time
     let T = current snapshot time
     let LFP = feed price of last snapshot
 -> for each order,
     let LV=volume of last snapshot,
     calculate LV' = function1 (direction, price, LFP, LV), to filter out unqualified orders
     calculate new score gained by this order after last snapshot
          NOS = function2 (direction,LV', LT, T, create_time, price, LFP)
          note: create_time may be needed here to judge whether this order is qualified.
 -> for each account(owner) on each side,
     let LAS = score on last snapshot
     calculate TLV = sum(LV'), total volume of qualified orders at last snapshot
     calculate ELV = function3(TLV), to filter out unqualified account if total volume is too low
     calculate TNS = sum(NOS), total new score gained
     calculate ENS = function4(TNS,ELV), to filter out too low total score/volume, and perhaps set a cap on new score
     calculate AS = LAS + ENS, final score at this snapshot
* at the end of a calculation period, for each side, we have a set of (account, score), so we can calculate the final rewards.

//Update: I'm going to write a plugin to provide snapshot data, so you guys can use it to do whatever calculation as you like.

@abit, that would be great if this could be a plugin for the node. It will be much more efficient and accurate than doing this thru API.

@roadscape: Many orders will be on the books for much less than 10 minutes.  So I think sampling every 10 minutes will yield somewhat arbitrary results.  On the other hand, I imagine constant monitoring would be too resource intensive?  If so, how about sampling every 1 minute?  I don't think it would yield perfect results, but probably more than good enough, and I'm guessing without being too unreasonably resource intensive.  Thoughts?  @abits, can you comment on this as well?

@tbone It could probably be done every minute. If we have many quickly placed/filled orders at high volumes then it would not make sense to use the sampling approach tho. But I figured most the orders getting rewarded would be bigger walls that don't move quickly. But there are workarounds, I just wanted to explore the limits of that approach and get feedback from traders.

tonyk Your proposed changes make sense, but continuous monitoring is much more complex than sampling*. What does it capture that sampling can't? And what if samples were e.g. 15 mins apart?

@roadscape
OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

My question is, what scenario are you trying to avoid (or create) by doing this?

If your order is on the books for 120 mins, and is *completely* filled at minute 125, you would not get credit for those last 5 minutes (assuming 10-minute snapshot interval). To me this doesn't seem like a problem.

If you expect orders to be on the books for less than 10 minutes at a time, I could see why we would need to be tracking this more detailed order activity.

My original line of thinking was a simple "sharedrop" of points onto order book participants at a regular interval.

My assumptions for MM subsidies:
1) The actual market activity doesn't matter nearly as much as creating a nicely-shaped order book.
2) 'Sampling' the order book every ~10 minutes is at least 95% as accurate as analyzing continuous data.
Obviously (I thought), I am trying to avoid orders being on the order book for 30% -99% of the time between sample taking, and such orders getting no credit at all. To say nothing about such orders being filled first, means they had the best prices of all orders!!!
The less the time between sample taking the less an issue this becomes, but your original proposal was every 1 h. (way too long in my view). The smaller the time between each sample taking the less an issue it is. (so if you cut it to 3-5-7 min, this is a one way to do it)
Yet, again the proposed solution will yield ' near perfect'* results even if you sample far less frequently... and the computations involved seem to take not too much recourses.

* It is not perfect, cause if you sample once every hour, you should also credit the "placed and subsequently cancelled" orders, meeting all other criteria, in that time frame.

Your middle ground is a good idea, the main issue--I don't think it's possible to get all this info solely via RPC calls; it would require extra processing. This is doable but at that point I'd weigh it against the continuous approach.
However @abit's solution (processing data straight in the node) is probably the most proper way to accomplish this.
Title: Re: Subsidizing Market Liquidity
Post by: abit on March 26, 2016, 10:34:32 am

@abit, that would be great if this could be a plugin for the node. It will be much more efficient and accurate than doing this thru API.

@roadscape: Many orders will be on the books for much less than 10 minutes.  So I think sampling every 10 minutes will yield somewhat arbitrary results.  On the other hand, I imagine constant monitoring would be too resource intensive?  If so, how about sampling every 1 minute?  I don't think it would yield perfect results, but probably more than good enough, and I'm guessing without being too unreasonably resource intensive.  Thoughts?  @abits, can you comment on this as well?

@tbone It could probably be done every minute. If we have many quickly placed/filled orders at high volumes then it would not make sense to use the sampling approach tho. But I figured most the orders getting rewarded would be bigger walls that don't move quickly. But there are workarounds, I just wanted to explore the limits of that approach and get feedback from traders.


Your middle ground is a good idea, the main issue--I don't think it's possible to get all this info solely via RPC calls; it would require extra processing. This is doable but at that point I'd weigh it against the continuous approach.
However @abit's solution (processing data straight in the node) is probably the most proper way to accomplish this.
@roadscape too be more efficient, at first I'll write a plugin which provides basic snapshot data only via RPC (E.G. what orders exist at a given time and what the feed price is, or data sets for a given time range), then you and/or others can do more processing (easier than querying via current APIs).
Implementing all processing logic in the plugin sounds not a good idea for me.
Title: Re: Subsidizing Market Liquidity
Post by: roadscape on March 31, 2016, 12:27:31 am
Discussion also here: https://github.com/cryptonomex/graphene/issues/643

At this point I'm thinking @abit's solution would indeed work great as long as he can implement this detail:

OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

So each snapshot really needs to be a window of time (say 15mins) that contains every order that existed during that time PLUS its placement time and/or fill time. Is this what you were thinking @abit? Any idea how partially filled orders are handled with this approach?
Title: Re: Subsidizing Market Liquidity
Post by: abit on March 31, 2016, 08:24:11 am
Discussion also here: https://github.com/cryptonomex/graphene/issues/643

At this point I'm thinking @abit's solution would indeed work great as long as he can implement this detail:

OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

So each snapshot really needs to be a window of time (say 15mins) that contains every order that existed during that time PLUS its placement time and/or fill time. Is this what you were thinking @abit? Any idea how partially filled orders are handled with this approach?
My idea can be considered that a new snapshot will be taken on every new block, so all unfilled orders will be tracked. For partially filled orders, we'll know when they were created, when they were partially filled, and when they disappeared.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 31, 2016, 07:48:25 pm
Discussion also here: https://github.com/cryptonomex/graphene/issues/643

At this point I'm thinking @abit's solution would indeed work great as long as he can implement this detail:

OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

So each snapshot really needs to be a window of time (say 15mins) that contains every order that existed during that time PLUS its placement time and/or fill time. Is this what you were thinking @abit? Any idea how partially filled orders are handled with this approach?

Since we're trying to incentivize orders placed, not orders filled, I don't think we need to concern ourselves with partial fills except to the extent that a partial fill reduces the number of shares an MM has on the order book and is getting credit for at that moment.  So if an MM reduces the size of their order, it should have the same impact on the scoring as a partial fill. 
Title: Re: Subsidizing Market Liquidity
Post by: tbone on March 31, 2016, 07:50:23 pm
Discussion also here: https://github.com/cryptonomex/graphene/issues/643

At this point I'm thinking @abit's solution would indeed work great as long as he can implement this detail:

OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

So each snapshot really needs to be a window of time (say 15mins) that contains every order that existed during that time PLUS its placement time and/or fill time. Is this what you were thinking @abit? Any idea how partially filled orders are handled with this approach?
My idea can be considered that a new snapshot will be taken on every new block, so all unfilled orders will be tracked. For partially filled orders, we'll know when they were created, when they were partially filled, and when they disappeared.

If it isn't too resource intensive, snapshot on every block sounds great.
Title: Re: Subsidizing Market Liquidity
Post by: roadscape on April 02, 2016, 05:49:11 pm
Discussion also here: https://github.com/cryptonomex/graphene/issues/643

At this point I'm thinking @abit's solution would indeed work great as long as he can implement this detail:

OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

So each snapshot really needs to be a window of time (say 15mins) that contains every order that existed during that time PLUS its placement time and/or fill time. Is this what you were thinking @abit? Any idea how partially filled orders are handled with this approach?
My idea can be considered that a new snapshot will be taken on every new block, so all unfilled orders will be tracked. For partially filled orders, we'll know when they were created, when they were partially filled, and when they disappeared.

Sounds good.. so this data will be streamed to a log file for processing/scoring by external scripts? It would be ideal to have multiple people running the same script and checking to make sure the numbers are in agreement. Your approach sounds like the most accurate way to get the data.
Title: Re: Subsidizing Market Liquidity
Post by: abit on April 03, 2016, 10:07:53 am
Discussion also here: https://github.com/cryptonomex/graphene/issues/643

At this point I'm thinking @abit's solution would indeed work great as long as he can implement this detail:

OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

So each snapshot really needs to be a window of time (say 15mins) that contains every order that existed during that time PLUS its placement time and/or fill time. Is this what you were thinking @abit? Any idea how partially filled orders are handled with this approach?
My idea can be considered that a new snapshot will be taken on every new block, so all unfilled orders will be tracked. For partially filled orders, we'll know when they were created, when they were partially filled, and when they disappeared.

Sounds good.. so this data will be streamed to a log file for processing/scoring by external scripts? It would be ideal to have multiple people running the same script and checking to make sure the numbers are in agreement. Your approach sounds like the most accurate way to get the data.
I'll stream data to somewhere on the Internet.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on April 07, 2016, 10:42:47 am
Discussion also here: https://github.com/cryptonomex/graphene/issues/643

At this point I'm thinking @abit's solution would indeed work great as long as he can implement this detail:

OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

So each snapshot really needs to be a window of time (say 15mins) that contains every order that existed during that time PLUS its placement time and/or fill time. Is this what you were thinking @abit? Any idea how partially filled orders are handled with this approach?
My idea can be considered that a new snapshot will be taken on every new block, so all unfilled orders will be tracked. For partially filled orders, we'll know when they were created, when they were partially filled, and when they disappeared.

Sounds good.. so this data will be streamed to a log file for processing/scoring by external scripts? It would be ideal to have multiple people running the same script and checking to make sure the numbers are in agreement. Your approach sounds like the most accurate way to get the data.
I'll stream data to somewhere on the Internet.

@roadscape , @abit

Hey guys, how soon do you think this can be completed?  @abit, have you been making progress?  Ronny from @ccedk said he would be interested in utilizing this to reward market makers in his UIAs.  And he will soon be launching some high profile assets suck as Lisk, Digix, and Synerio.  Not to mention, it is critical for us to start bootstrapping key fiat BitAssets.  What do you guys think?
Title: Re: Subsidizing Market Liquidity
Post by: abit on April 07, 2016, 11:38:18 am
Discussion also here: https://github.com/cryptonomex/graphene/issues/643

At this point I'm thinking @abit's solution would indeed work great as long as he can implement this detail:

OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

So each snapshot really needs to be a window of time (say 15mins) that contains every order that existed during that time PLUS its placement time and/or fill time. Is this what you were thinking @abit? Any idea how partially filled orders are handled with this approach?
My idea can be considered that a new snapshot will be taken on every new block, so all unfilled orders will be tracked. For partially filled orders, we'll know when they were created, when they were partially filled, and when they disappeared.

Sounds good.. so this data will be streamed to a log file for processing/scoring by external scripts? It would be ideal to have multiple people running the same script and checking to make sure the numbers are in agreement. Your approach sounds like the most accurate way to get the data.
I'll stream data to somewhere on the Internet.

@roadscape , @abit

Hey guys, how soon do you think this can be completed?  @abit, have you been making progress?  Ronny from @ccedk said he would be interested in utilizing this to reward market makers in his UIAs.  And he will soon be launching some high profile assets suck as Lisk, Digix, and Synerio.  Not to mention, it is critical for us to start bootstrapping key fiat BitAssets.  What do you guys think?
Yes, some progresses.
Check https://data.sparkfun.com/bitshares_usd_price for a feed_price only stream. Market snapshots stream would be something like that but with much more data, which can be used to calculate scores.
If I'm given a decided formula, I can also stream scores.
Title: Re: Subsidizing Market Liquidity
Post by: xeroc on April 07, 2016, 01:13:24 pm
Yes, some progresses.
Check https://data.sparkfun.com/bitshares_usd_price for a feed_price only stream. Market snapshots stream would be something like that but with much more data, which can be used to calculate scores.
If I'm given a decided formula, I can also stream scores.
This looks great .. !!!
Title: Re: Subsidizing Market Liquidity
Post by: tbone on April 07, 2016, 01:59:08 pm
[
@roadscape , @abit

Hey guys, how soon do you think this can be completed?  @abit, have you been making progress?  Ronny from @ccedk said he would be interested in utilizing this to reward market makers in his UIAs.  And he will soon be launching some high profile assets suck as Lisk, Digix, and Synerio.  Not to mention, it is critical for us to start bootstrapping key fiat BitAssets.  What do you guys think?
Yes, some progresses.
Check https://data.sparkfun.com/bitshares_usd_price for a feed_price only stream. Market snapshots stream would be something like that but with much more data, which can be used to calculate scores.
If I'm given a decided formula, I can also stream scores.

Ok, so since time is of the essence, it sounds like the important thing to worry about is the snapshots since they can be analyzed and have the formula applied after the fact, correct?  With that in mind, it would be great to see the other required datapoints added, such as asset name, account name, number of shares, current bid/ask, and current price feed (if asset has feed).   Nice work, @abit!
Title: Re: Subsidizing Market Liquidity
Post by: roadscape on April 07, 2016, 03:01:07 pm
Discussion also here: https://github.com/cryptonomex/graphene/issues/643

At this point I'm thinking @abit's solution would indeed work great as long as he can implement this detail:

OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

So each snapshot really needs to be a window of time (say 15mins) that contains every order that existed during that time PLUS its placement time and/or fill time. Is this what you were thinking @abit? Any idea how partially filled orders are handled with this approach?
My idea can be considered that a new snapshot will be taken on every new block, so all unfilled orders will be tracked. For partially filled orders, we'll know when they were created, when they were partially filled, and when they disappeared.

Sounds good.. so this data will be streamed to a log file for processing/scoring by external scripts? It would be ideal to have multiple people running the same script and checking to make sure the numbers are in agreement. Your approach sounds like the most accurate way to get the data.
I'll stream data to somewhere on the Internet.

@roadscape , @abit

Hey guys, how soon do you think this can be completed?  @abit, have you been making progress?  Ronny from @ccedk said he would be interested in utilizing this to reward market makers in his UIAs.  And he will soon be launching some high profile assets suck as Lisk, Digix, and Synerio.  Not to mention, it is critical for us to start bootstrapping key fiat BitAssets.  What do you guys think?
Yes, some progresses.
Check https://data.sparkfun.com/bitshares_usd_price for a feed_price only stream. Market snapshots stream would be something like that but with much more data, which can be used to calculate scores.
If I'm given a decided formula, I can also stream scores.

Very good.. Will these market snapshots be saved to log files directly from the node for external parsing/scoring? How will it work?
Title: Re: Subsidizing Market Liquidity
Post by: abit on April 07, 2016, 10:11:09 pm
[
@roadscape , @abit

Hey guys, how soon do you think this can be completed?  @abit, have you been making progress?  Ronny from @ccedk said he would be interested in utilizing this to reward market makers in his UIAs.  And he will soon be launching some high profile assets suck as Lisk, Digix, and Synerio.  Not to mention, it is critical for us to start bootstrapping key fiat BitAssets.  What do you guys think?
Yes, some progresses.
Check https://data.sparkfun.com/bitshares_usd_price for a feed_price only stream. Market snapshots stream would be something like that but with much more data, which can be used to calculate scores.
If I'm given a decided formula, I can also stream scores.

Ok, so since time is of the essence, it sounds like the important thing to worry about is the snapshots since they can be analyzed and have the formula applied after the fact, correct?  With that in mind, it would be great to see the other required datapoints added, such as asset name, account name, number of shares, current bid/ask, and current price feed (if asset has feed).   Nice work, @abit!
Please check this url for BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot . Right now there are only account ids but no account names..

I'll try to score the participants of this market first. And so can you :)

Very good.. Will these market snapshots be saved to log files directly from the node for external parsing/scoring? How will it work?
Since my code is currently very dirty, I'm not going to publish it right now. So live streaming is the best way for others to be able to use the data at this moment.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on April 07, 2016, 10:44:36 pm
[
@roadscape , @abit

Hey guys, how soon do you think this can be completed?  @abit, have you been making progress?  Ronny from @ccedk said he would be interested in utilizing this to reward market makers in his UIAs.  And he will soon be launching some high profile assets suck as Lisk, Digix, and Synerio.  Not to mention, it is critical for us to start bootstrapping key fiat BitAssets.  What do you guys think?
Yes, some progresses.
Check https://data.sparkfun.com/bitshares_usd_price for a feed_price only stream. Market snapshots stream would be something like that but with much more data, which can be used to calculate scores.
If I'm given a decided formula, I can also stream scores.

Ok, so since time is of the essence, it sounds like the important thing to worry about is the snapshots since they can be analyzed and have the formula applied after the fact, correct?  With that in mind, it would be great to see the other required datapoints added, such as asset name, account name, number of shares, current bid/ask, and current price feed (if asset has feed).   Nice work, @abit!
Please check this url for BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot . Right now there are only account ids but no account names..

I'll try to score the participants of this market first. And so can you :)

Very good.. Will these market snapshots be saved to log files directly from the node for external parsing/scoring? How will it work?
Since my code is currently very dirty, I'm not going to publish it right now. So live streaming is the best way for others to be able to use the data at this moment.

Nice progress.  Quick question -- I see you have a field for feed price.  That would apply to BitAssets, but what about for UIAs?  Will you calculate the bid/ask midpoint and place that value in the feed_price field?  Or create an additional field?  Also, how often do you plan to take snapshots?  Thanks.
Title: Re: Subsidizing Market Liquidity
Post by: abit on April 07, 2016, 11:09:03 pm
For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

A snapshot is taken every time when there is a change in the market. The links I provided are live & real data pushing.
* live BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot
* live BTS/bitUSD median feed price history: https://data.sparkfun.com/bitshares_usd_price
Title: Re: Subsidizing Market Liquidity
Post by: tbone on April 08, 2016, 12:28:52 am
For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?

A snapshot is taken every time when there is a change in the market. The links I provided are live & real data pushing.
* live BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot
* live BTS/bitUSD median feed price history: https://data.sparkfun.com/bitshares_usd_price

Oh I see.  So that means that in an active market, the snapshot may be happening as often as every block?
Title: Re: Subsidizing Market Liquidity
Post by: abit on April 08, 2016, 12:55:29 am
For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?
I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

Quote
A snapshot is taken every time when there is a change in the market. The links I provided are live & real data pushing.
* live BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot
* live BTS/bitUSD median feed price history: https://data.sparkfun.com/bitshares_usd_price

Oh I see.  So that means that in an active market, the snapshot may be happening as often as every block?
Yes.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on April 08, 2016, 02:26:24 am
For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?
I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

The distance calculation result doesn't need to be in the snapshot data...but the price that will be used later for that calculation needs to be.  For BitAssets, that price comes from the feed, which you have a field for.  For UIAs, it needs to be something else, probably midpoint of best bid and best ask.  You don't have to calculate that midpoint, but you'll have to include the best bid and best ask so the midpoint can be calculated later.  See what I mean now?


Quote from: tbone
A snapshot is taken every time when there is a change in the market. The links I provided are live & real data pushing.
* live BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot
* live BTS/bitUSD median feed price history: https://data.sparkfun.com/bitshares_usd_price

Oh I see.  So that means that in an active market, the snapshot may be happening as often as every block?
Yes.

Ok, that's great.
Title: Re: Subsidizing Market Liquidity
Post by: abit on April 08, 2016, 11:15:00 am
For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?
I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

The distance calculation result doesn't need to be in the snapshot data...but the price that will be used later for that calculation needs to be.  For BitAssets, that price comes from the feed, which you have a field for.  For UIAs, it needs to be something else, probably midpoint of best bid and best ask.  You don't have to calculate that midpoint, but you'll have to include the best bid and best ask so the midpoint can be calculated later.  See what I mean now?

Sorry, I didn't get the point.

For smart coins, the feed_price is simply fetched from the blockchain, which is a value published by the witnesses, so can't be calculated out from the order book. It's a basic data. I put it there, you can either use it or not in your formula.

But for UIA? The formula of "best bid" and "best ask" is yet to be defined, so how can I give out the best middle price? As I said it's an intermediate result, not a basic data.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on April 08, 2016, 03:05:20 pm
For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?
I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

The distance calculation result doesn't need to be in the snapshot data...but the price that will be used later for that calculation needs to be.  For BitAssets, that price comes from the feed, which you have a field for.  For UIAs, it needs to be something else, probably midpoint of best bid and best ask.  You don't have to calculate that midpoint, but you'll have to include the best bid and best ask so the midpoint can be calculated later.  See what I mean now?

Sorry, I didn't get the point.

For smart coins, the feed_price is simply fetched from the blockchain, which is a value published by the witnesses, so can't be calculated out from the order book. It's a basic data. I put it there, you can either use it or not in your formula.

But for UIA? The formula of "best bid" and "best ask" is yet to be defined, so how can I give out the best middle price? As I said it's an intermediate result, not a basic data.

Ok, I see where the misunderstanding is coming from.  Yes, the midpoint is a calculated value.  But the best bid and best ask are NOT calculated values.  They are values that must be recorded in the snapshot.  So let me define them.    The best bid is the highest bid at a given time.  And the best ask is the lowest ask at a given time.  If those values are not recorded in the snapshot, there is no way to calculate the midpoint, and therefore there is no way to calculate the distance component of the score.
Title: Re: Subsidizing Market Liquidity
Post by: abit on April 08, 2016, 07:06:44 pm
For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?
I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

The distance calculation result doesn't need to be in the snapshot data...but the price that will be used later for that calculation needs to be.  For BitAssets, that price comes from the feed, which you have a field for.  For UIAs, it needs to be something else, probably midpoint of best bid and best ask.  You don't have to calculate that midpoint, but you'll have to include the best bid and best ask so the midpoint can be calculated later.  See what I mean now?

Sorry, I didn't get the point.

For smart coins, the feed_price is simply fetched from the blockchain, which is a value published by the witnesses, so can't be calculated out from the order book. It's a basic data. I put it there, you can either use it or not in your formula.

But for UIA? The formula of "best bid" and "best ask" is yet to be defined, so how can I give out the best middle price? As I said it's an intermediate result, not a basic data.

Ok, I see where the misunderstanding is coming from.  Yes, the midpoint is a calculated value.  But the best bid and best ask are NOT calculated values.  They are values that must be recorded in the snapshot.  So let me define them.    The best bid is the highest bid at a given time.  And the best ask is the lowest ask at a given time.  If those values are not recorded in the snapshot, there is no way to calculate the midpoint, and therefore there is no way to calculate the distance component of the score.
On a given time point, the snapshot comes with an entire order book (which is basic data), say a `bids` field and a `asks` field, both are lists ordered by price, the first element on each list is the best one. So?
Title: Re: Subsidizing Market Liquidity
Post by: tbone on April 08, 2016, 07:38:52 pm
For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?
I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

The distance calculation result doesn't need to be in the snapshot data...but the price that will be used later for that calculation needs to be.  For BitAssets, that price comes from the feed, which you have a field for.  For UIAs, it needs to be something else, probably midpoint of best bid and best ask.  You don't have to calculate that midpoint, but you'll have to include the best bid and best ask so the midpoint can be calculated later.  See what I mean now?

Sorry, I didn't get the point.

For smart coins, the feed_price is simply fetched from the blockchain, which is a value published by the witnesses, so can't be calculated out from the order book. It's a basic data. I put it there, you can either use it or not in your formula.

But for UIA? The formula of "best bid" and "best ask" is yet to be defined, so how can I give out the best middle price? As I said it's an intermediate result, not a basic data.

Ok, I see where the misunderstanding is coming from.  Yes, the midpoint is a calculated value.  But the best bid and best ask are NOT calculated values.  They are values that must be recorded in the snapshot.  So let me define them.    The best bid is the highest bid at a given time.  And the best ask is the lowest ask at a given time.  If those values are not recorded in the snapshot, there is no way to calculate the midpoint, and therefore there is no way to calculate the distance component of the score.
On a given time point, the snapshot comes with an entire order book (which is basic data), say a `bids` field and a `asks` field, both are lists ordered by price, the first element on each list is the best one. So?

I see what you mean now.  I guess I was looking at it a little differently since I was envisioning that at some point (if not immediately), it would be too much data if we snapshot EVERY order on the book and that we'd have to start recording only orders of "registered market makers", which is fine except for one thing -- there would be no way to determine the best bid and ask after the fact.  Because that is a very real possibility, now would be a good time to start identifying best bid/ask and place those values into their own top level fields alongside price_feed.  This way a) the code to do the scoring would not break if we have to start doing the limited snapshots, and b) perhaps more importantly, it will be far easier to visually check the scoring results against the snapshot data.   By the way, I'm not saying you should calculate the midpoint.  That can always be done after the fact.  I'm just suggesting to identify the best bid/ask as part of the snapshot. 

Title: Re: Subsidizing Market Liquidity
Post by: abit on April 13, 2016, 10:06:56 pm
Define the formula for smart coins as (only count in one side: sell bitEUR & buy BTS):
Code: [Select]
account_score = sum(order_score)

order_score = volume * seconds * price_score(feed_price,order_price)

price_score =
  if order_price < feed_price * 80%
    then 0
  else if order_price <= feed_price * 99%
    then 100 / (1 - order_price / feed_price)
  else
    100 + 10000 * (order_price / feed_price - 0.99)
So,
* price_score is 0 if order_price is less than 80% of feed_price
* price_score is 5 if order_price is 80% of feed_price
* price_score is 10 if order_price is 90% of feed_price
* price_score is 20 if order_price is 95% of feed_price
* price_score is 33 if order_price is 97% of feed_price
* price_score is 50 if order_price is 98% of feed_price
* price_score is 100 if order_price is 99% of feed_price
* price_score is 150 if order_price is 99.5% of feed_price
* price_score is 200 if order_price = feed_price

Then scores of BTS/bitEUR market in April are here:
Code: [Select]
2016-04-12
 184400378.7000,lin9uxis
 158725194.2100,bts-scotter
  48644049.8322,altfund
  37088100.0000,mf-tzo
  14851206.9189,liquidity-bot-linouxisbot
  13052533.0683,liquidity-bot-mauritso
   3235363.3944,liquidity-bot-linouxis2
   1367414.0955,liquidity-bot-mauritso2

2016-04-11
 203062435.9842,bts-scotter
  63045259.2621,altfund
  28664143.6950,lin9uxis
  10421922.3498,liquidity-bot-mauritso2
   5889780.8652,liquidity-bot-mauritso
   5057244.0000,mf-tzo
   4649968.5468,liquidity-bot-linouxis2
   4043822.3133,liquidity-bot-linouxisbot

2016-04-10
 641074500.0000,hugogoulart
 307256636.3463,bts-scotter
 105651130.2000,liondani
  98901551.4495,hcf27
  60203082.8904,altfund
   9153766.9794,liquidity-bot-linouxis2
   8539407.2832,liquidity-bot-mauritso2
   7128896.5920,liquidity-bot-linouxisbot
   6013054.6734,liquidity-bot-mauritso
   2609749.4892,lin9uxis
   2256716.3844,liquidity-bot-bm

2016-04-09
 516839795.8971,bts-scotter
 254116500.0000,hugogoulart
  46036964.3199,altfund
  42258169.8000,liondani
   8893063.7451,liquidity-bot-mauritso2
   7583349.3258,liquidity-bot-mauritso
   6019348.3032,hcf27
   5872279.0644,liquidity-bot-linouxisbot
   5126273.1861,liquidity-bot-linouxis2
   1843986.2718,liquidity-bot-bm

2016-04-08
 402232130.1660,bts-scotter
 216266250.0000,hugogoulart
 113177815.4358,altfund
  36026166.0000,liondani
  18505503.4875,liquidity-bot-mauritso2
  14579342.0448,hcf27
   9433227.9429,liquidity-bot-mauritso
   1256984.7966,liquidity-bot-gold21
    820598.4297,gold-mine
    631812.8628,liquidity-bot-linouxisbot
    548911.6506,liquidity-bot-bm

2016-04-07
 228067431.7239,bts-scotter
  91298250.0000,hugogoulart
  64178934.8070,altfund
  24261388.8000,liondani
   5664953.6586,liquidity-bot-mauritso2
   5378275.7307,liquidity-bot-mauritso
   1030284.2871,antman890
    348001.2387,hcf27
     74945.3340,liquidity-bot-gold21

2016-04-06
 204159419.3772,bts-scotter
  53689303.3404,altfund
  22085322.6000,liondani
   1019154.3606,antman890
    647557.2120,mf-tzo
    223506.2250,liquidity-bot-mauritso

2016-04-05
 194139802.9065,bts-scotter
  52144072.1850,altfund
  21599146.8000,liondani
    945507.3318,antman890

2016-04-04
 228594201.3564,bts-scotter
  62036456.5413,altfund
  23930959.8000,liondani
   1217967.2901,antman890

2016-04-03
 275702980.5606,bts-scotter
  28311683.4000,liondani
  24672346.9869,altfund
    321518.3616,antman890

2016-04-02
 283152877.3458,bts-scotter
  28497024.6000,liondani
  16613545.7664,altfund

2016-04-01
 250503237.4629,bts-scotter
  27221079.6000,liondani
  15580021.5384,altfund
   1266542.7588,inarizushi

@kenCode
Title: Re: Subsidizing Market Liquidity
Post by: tbone on April 14, 2016, 04:21:27 am
Define the formula for smart coins as (only count in one side: sell bitEUR & buy BTS):
Code: [Select]
account_score = sum(order_score)

order_score = volume * seconds * price_score(feed_price,order_price)

price_score =
  if order_price < feed_price * 80%
    then 0
  else if order_price <= feed_price * 99%
    then 100 / (1 - order_price / feed_price)
  else
    100 + 10000 * (order_price / feed_price - 0.99)
So,
* price_score is 0 if order_price is less than 80% of feed_price
* price_score is 5 if order_price is 80% of feed_price
* price_score is 10 if order_price is 90% of feed_price
* price_score is 20 if order_price is 95% of feed_price
* price_score is 33 if order_price is 97% of feed_price
* price_score is 50 if order_price is 98% of feed_price
* price_score is 100 if order_price is 99% of feed_price
* price_score is 150 if order_price is 99.5% of feed_price
* price_score is 200 if order_price = feed_price

Then scores of BTS/bitEUR market in April are here:
Code: [Select]
2016-04-12
 184400378.7000,lin9uxis
 158725194.2100,bts-scotter
  48644049.8322,altfund
  37088100.0000,mf-tzo
  14851206.9189,liquidity-bot-linouxisbot
  13052533.0683,liquidity-bot-mauritso
   3235363.3944,liquidity-bot-linouxis2
   1367414.0955,liquidity-bot-mauritso2

2016-04-11
 203062435.9842,bts-scotter
  63045259.2621,altfund
  28664143.6950,lin9uxis
  10421922.3498,liquidity-bot-mauritso2
   5889780.8652,liquidity-bot-mauritso
   5057244.0000,mf-tzo
   4649968.5468,liquidity-bot-linouxis2
   4043822.3133,liquidity-bot-linouxisbot

2016-04-10
 641074500.0000,hugogoulart
 307256636.3463,bts-scotter
 105651130.2000,liondani
  98901551.4495,hcf27
  60203082.8904,altfund
   9153766.9794,liquidity-bot-linouxis2
   8539407.2832,liquidity-bot-mauritso2
   7128896.5920,liquidity-bot-linouxisbot
   6013054.6734,liquidity-bot-mauritso
   2609749.4892,lin9uxis
   2256716.3844,liquidity-bot-bm

2016-04-09
 516839795.8971,bts-scotter
 254116500.0000,hugogoulart
  46036964.3199,altfund
  42258169.8000,liondani
   8893063.7451,liquidity-bot-mauritso2
   7583349.3258,liquidity-bot-mauritso
   6019348.3032,hcf27
   5872279.0644,liquidity-bot-linouxisbot
   5126273.1861,liquidity-bot-linouxis2
   1843986.2718,liquidity-bot-bm

2016-04-08
 402232130.1660,bts-scotter
 216266250.0000,hugogoulart
 113177815.4358,altfund
  36026166.0000,liondani
  18505503.4875,liquidity-bot-mauritso2
  14579342.0448,hcf27
   9433227.9429,liquidity-bot-mauritso
   1256984.7966,liquidity-bot-gold21
    820598.4297,gold-mine
    631812.8628,liquidity-bot-linouxisbot
    548911.6506,liquidity-bot-bm

2016-04-07
 228067431.7239,bts-scotter
  91298250.0000,hugogoulart
  64178934.8070,altfund
  24261388.8000,liondani
   5664953.6586,liquidity-bot-mauritso2
   5378275.7307,liquidity-bot-mauritso
   1030284.2871,antman890
    348001.2387,hcf27
     74945.3340,liquidity-bot-gold21

2016-04-06
 204159419.3772,bts-scotter
  53689303.3404,altfund
  22085322.6000,liondani
   1019154.3606,antman890
    647557.2120,mf-tzo
    223506.2250,liquidity-bot-mauritso

2016-04-05
 194139802.9065,bts-scotter
  52144072.1850,altfund
  21599146.8000,liondani
    945507.3318,antman890

2016-04-04
 228594201.3564,bts-scotter
  62036456.5413,altfund
  23930959.8000,liondani
   1217967.2901,antman890

2016-04-03
 275702980.5606,bts-scotter
  28311683.4000,liondani
  24672346.9869,altfund
    321518.3616,antman890

2016-04-02
 283152877.3458,bts-scotter
  28497024.6000,liondani
  16613545.7664,altfund

2016-04-01
 250503237.4629,bts-scotter
  27221079.6000,liondani
  15580021.5384,altfund
   1266542.7588,inarizushi

@kenCode

Nice work, @abit!  The only comment I have is that we previously discussed rewarding balance between buy and sell side orders.  So for example if a market makers scores 3000 on the bid side and 2000 on the ask side, they would get full credit for 2000 + 2000.  And then we could apply some factor less than 1 to the remaining 1000 from the bid side score.   I don't think the factor should be 0, but perhaps in the .25-.5 range.  In the future we can do something more sophisticated that identifies the weak and strong sides of a market when it's trending, that way we can more heavily reward liquidity provided to the weak side.   

By the way, can you test out your scoring on a UIA?  Maybe OBITS since it's one of the most active?  Thanks for your work on this, @abit!

Title: Re: Subsidizing Market Liquidity
Post by: abit on April 14, 2016, 08:48:16 am
BTS/bitEUR score (formula is here https://bitsharestalk.org/index.php/topic,21544.msg289590.html#msg289590)
Code: [Select]
2016-04-13
 183696659.8428,liquidity-bot-linouxisbot
 113107835.0706,altfund
  76662915.9213,liquidity-bot-mauritso
  32650952.0400,bts-scotter

Nice work, @abit!  The only comment I have is that we previously discussed rewarding balance between buy and sell side orders.  So for example if a market makers scores 3000 on the bid side and 2000 on the ask side, they would get full credit for 2000 + 2000.  And then we could apply some factor less than 1 to the remaining 1000 from the bid side score.   I don't think the factor should be 0, but perhaps in the .25-.5 range.  In the future we can do something more sophisticated that identifies the weak and strong sides of a market when it's trending, that way we can more heavily reward liquidity provided to the weak side.   

By the way, can you test out your scoring on a UIA?  Maybe OBITS since it's one of the most active?  Thanks for your work on this, @abit!
Thanks! Scoring of UIA pairs is on my to-do list.

According to https://cryptofresh.com/assets, in last 24 hours, the most active UIA:UIA pair is MKR:OPEN.BTC, the most active BTS pair is BTS:OPEN.BTC

UIA related pairs need to add some factors to the formula, I haven't figured out the final formula.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on April 14, 2016, 12:00:38 pm
BTS/bitEUR score (formula is here https://bitsharestalk.org/index.php/topic,21544.msg289590.html#msg289590)
Code: [Select]
2016-04-13
 183696659.8428,liquidity-bot-linouxisbot
 113107835.0706,altfund
  76662915.9213,liquidity-bot-mauritso
  32650952.0400,bts-scotter

Nice work, @abit!  The only comment I have is that we previously discussed rewarding balance between buy and sell side orders.  So for example if a market makers scores 3000 on the bid side and 2000 on the ask side, they would get full credit for 2000 + 2000.  And then we could apply some factor less than 1 to the remaining 1000 from the bid side score.   I don't think the factor should be 0, but perhaps in the .25-.5 range.  In the future we can do something more sophisticated that identifies the weak and strong sides of a market when it's trending, that way we can more heavily reward liquidity provided to the weak side.   

By the way, can you test out your scoring on a UIA?  Maybe OBITS since it's one of the most active?  Thanks for your work on this, @abit!
Thanks! Scoring of UIA pairs is on my to-do list.

According to https://cryptofresh.com/assets, in last 24 hours, the most active UIA:UIA pair is MKR:OPEN.BTC, the most active BTS pair is BTS:OPEN.BTC

UIA related pairs need to add some factors to the formula, I haven't figured out the final formula.

Doesn't really matter which UIA to test on as long as it has some good volume.  But I did ask Ronny several days ago on another thread if he would be interested in using this and he said yes.  I have no idea if @Rune would use it.  Although I don't see why not!

Anyway, what about the point I brought up about taking into account balance between buy and sell side liquidity?  Actually, I think it would be best for your script to simply produce 2 scores (one for the buy side, one for the sell side) and leave it at that.  Then the issuer can apply their own "balance factor", which would be a very simple calculation that can be done in a spreadsheet.  The issuer will already have to make some decisions about how to use the scoring data to begin with.  For example, do they want to have a minimum score for a MM to qualify for a rewards?  Do they want to reward only the top X number of MMs in a given period?  Do they want to reward only those MMs who provided a minimum % of the total liquidity?  Etc.  This will all have to be up to the issuer, and they may try different things. 
Title: Re: Subsidizing Market Liquidity
Post by: abit on April 14, 2016, 01:08:05 pm
BTS/bitEUR score (formula is here https://bitsharestalk.org/index.php/topic,21544.msg289590.html#msg289590)
Code: [Select]
2016-04-13
 183696659.8428,liquidity-bot-linouxisbot
 113107835.0706,altfund
  76662915.9213,liquidity-bot-mauritso
  32650952.0400,bts-scotter

Nice work, @abit!  The only comment I have is that we previously discussed rewarding balance between buy and sell side orders.  So for example if a market makers scores 3000 on the bid side and 2000 on the ask side, they would get full credit for 2000 + 2000.  And then we could apply some factor less than 1 to the remaining 1000 from the bid side score.   I don't think the factor should be 0, but perhaps in the .25-.5 range.  In the future we can do something more sophisticated that identifies the weak and strong sides of a market when it's trending, that way we can more heavily reward liquidity provided to the weak side.   

By the way, can you test out your scoring on a UIA?  Maybe OBITS since it's one of the most active?  Thanks for your work on this, @abit!
Thanks! Scoring of UIA pairs is on my to-do list.

According to https://cryptofresh.com/assets, in last 24 hours, the most active UIA:UIA pair is MKR:OPEN.BTC, the most active BTS pair is BTS:OPEN.BTC

UIA related pairs need to add some factors to the formula, I haven't figured out the final formula.

Doesn't really matter which UIA to test on as long as it has some good volume.  But I did ask Ronny several days ago on another thread if he would be interested in using this and he said yes.  I have no idea if @Rune would use it.  Although I don't see why not!

Anyway, what about the point I brought up about taking into account balance between buy and sell side liquidity?  Actually, I think it would be best for your script to simply produce 2 scores (one for the buy side, one for the sell side) and leave it at that.  Then the issuer can apply their own "balance factor", which would be a very simple calculation that can be done in a spreadsheet.  The issuer will already have to make some decisions about how to use the scoring data to begin with.  For example, do they want to have a minimum score for a MM to qualify for a rewards?  Do they want to reward only the top X number of MMs in a given period?  Do they want to reward only those MMs who provided a minimum % of the total liquidity?  Etc.  This will all have to be up to the issuer, and they may try different things.
I'll bring out more statistics data, E.G. average spread per account, average volume, total show up time/duration, then the issuers will have a clearer picture.

Buy and sell side will be calculated independently.

Some of the decisions you mentioned require modifications to the formula itself, fortunately it's not hard to change atm. To be more productive, it's best that the issuers come out and say what they want.
Title: Re: Subsidizing Market Liquidity
Post by: tbone on April 14, 2016, 02:44:15 pm
BTS/bitEUR score (formula is here https://bitsharestalk.org/index.php/topic,21544.msg289590.html#msg289590)
Code: [Select]
2016-04-13
 183696659.8428,liquidity-bot-linouxisbot
 113107835.0706,altfund
  76662915.9213,liquidity-bot-mauritso
  32650952.0400,bts-scotter

Nice work, @abit!  The only comment I have is that we previously discussed rewarding balance between buy and sell side orders.  So for example if a market makers scores 3000 on the bid side and 2000 on the ask side, they would get full credit for 2000 + 2000.  And then we could apply some factor less than 1 to the remaining 1000 from the bid side score.   I don't think the factor should be 0, but perhaps in the .25-.5 range.  In the future we can do something more sophisticated that identifies the weak and strong sides of a market when it's trending, that way we can more heavily reward liquidity provided to the weak side.   

By the way, can you test out your scoring on a UIA?  Maybe OBITS since it's one of the most active?  Thanks for your work on this, @abit!
Thanks! Scoring of UIA pairs is on my to-do list.

According to https://cryptofresh.com/assets, in last 24 hours, the most active UIA:UIA pair is MKR:OPEN.BTC, the most active BTS pair is BTS:OPEN.BTC

UIA related pairs need to add some factors to the formula, I haven't figured out the final formula.

Doesn't really matter which UIA to test on as long as it has some good volume.  But I did ask Ronny several days ago on another thread if he would be interested in using this and he said yes.  I have no idea if @Rune would use it.  Although I don't see why not!

Anyway, what about the point I brought up about taking into account balance between buy and sell side liquidity?  Actually, I think it would be best for your script to simply produce 2 scores (one for the buy side, one for the sell side) and leave it at that.  Then the issuer can apply their own "balance factor", which would be a very simple calculation that can be done in a spreadsheet.  The issuer will already have to make some decisions about how to use the scoring data to begin with.  For example, do they want to have a minimum score for a MM to qualify for a rewards?  Do they want to reward only the top X number of MMs in a given period?  Do they want to reward only those MMs who provided a minimum % of the total liquidity?  Etc.  This will all have to be up to the issuer, and they may try different things.
I'll bring out more statistics data, E.G. average spread per account, average volume, total show up time/duration, then the issuers will have a clearer picture.

Buy and sell side will be calculated independently.

Some of the decisions you mentioned require modifications to the formula itself, fortunately it's not hard to change atm. To be more productive, it's best that the issuers come out and say what they want.

Actually, none of the scoring methods I mentioned require further pre-processing.  But if any issuers can think of a way they would like to score that DOES require additional pre-processing, I agree now is a good time for them to speak up.  Otherwise I think we'll pretty much be all set once you break out the bid and ask sides.  On second thought, another thing I just remembered - I still think it's a good idea to add bid_ask_midpoint as a top level field next to price_feed.
Title: Re: Subsidizing Market Liquidity
Post by: abit on April 17, 2016, 12:26:01 am
Updated scores and related data in EUR/BTS market:
Code: [Select]
2016-04-01 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  250503237.4629,          82617,                 305.3737,           9.58%, bts-scotter
   27221079.6000,          86400,                  41.8000,          12.46%, liondani
   15580021.5384,          86400,                  18.2666,           9.67%, altfund
    1266542.7588,          48576,                   2.5707,           9.45%, inarizushi
2016-04-02 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  283152877.3458,          86400,                 305.3737,           9.01%, bts-scotter
   28497024.6000,          86400,                  41.8000,          11.93%, liondani
   16613545.7664,          86400,                  18.2666,           9.13%, altfund
2016-04-03 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  275702980.5606,          86400,                 305.3737,           9.15%, bts-scotter
   28311683.4000,          86400,                  41.8000,          12.08%, liondani
   24672346.9869,          84732,                  28.9513,          10.00%, altfund
     321518.3616,          17766,                   1.0707,           5.73%, antman890
2016-04-04 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  228594201.3564,          86400,                 305.3737,          11.38%, bts-scotter
   62036456.5413,          86400,                  89.4922,          13.06%, altfund
   23930959.8000,          86400,                  41.8000,          14.23%, liondani
    1217967.2901,          86400,                   1.0707,           7.92%, antman890
2016-04-05 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  194139802.9065,          86400,                 305.3737,          12.81%, bts-scotter
   52144072.1850,          86400,                  89.4922,          14.46%, altfund
   21599146.8000,          86400,                  41.8000,          15.61%, liondani
     945507.3318,          86400,                   1.0707,           9.41%, antman890
2016-04-06 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  204159419.3772,          86400,                 305.3737,          12.20%, bts-scotter
   53689303.3404,          86274,                  74.6011,          12.70%, altfund
   22085322.6000,          86400,                  41.8000,          15.02%, liondani
    1019154.3606,          86400,                   1.0707,           8.77%, antman890
     647557.2120,            165,                  13.6030,          -0.88%, mf-tzo
     223506.2250,           3720,                   5.3172,          10.16%, liquidity-bot-mauritso
2016-04-07 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  228067431.7239,          86400,                 305.3737,          11.02%, bts-scotter
   91298250.0000,          51399,                 250.0000,          13.43%, hugogoulart
   64178934.8070,          86400,                  59.0192,           9.49%, altfund
   24261388.8000,          86400,                  41.8000,          13.88%, liondani
    5664953.6586,          52272,                   7.2767,           9.15%, liquidity-bot-mauritso2
    5378275.7307,          86358,                   5.2537,           9.85%, liquidity-bot-mauritso
    1030284.2871,          77091,                   1.0707,           7.82%, antman890
     348001.2387,           9396,                   1.2819,           3.41%, hcf27
      74945.3340,           4986,                   1.4176,          10.45%, liquidity-bot-gold21
2016-04-08 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  402232130.1660,          86400,                 305.3737,           6.78%, bts-scotter
  216266250.0000,          86400,                 250.0000,           9.74%, hugogoulart
  113177815.4358,          85911,                  49.4321,           8.17%, altfund
   36026166.0000,          86400,                  41.8000,           9.78%, liondani
   18505503.4875,          86382,                   6.8498,           7.46%, liquidity-bot-mauritso2
   14579342.0448,          86400,                   1.1626,           1.31%, hcf27
    9433227.9429,          86400,                   5.0587,           8.66%, liquidity-bot-mauritso
    1256984.7966,          58737,                   1.4220,           9.54%, liquidity-bot-gold21
     820598.4297,           9780,                   6.5913,           9.72%, gold-mine
     631812.8628,          13905,                   4.0378,          10.90%, liquidity-bot-linouxisbot
     548911.6506,          27564,                   1.8700,          10.40%, liquidity-bot-bm
2016-04-09 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  516839795.8971,          86400,                 305.3737,           5.22%, bts-scotter
  254116500.0000,          86400,                 250.0000,           8.23%, hugogoulart
   46036964.3199,          86268,                  39.0550,          10.74%, altfund
   42258169.8000,          86400,                  41.8000,           8.27%, liondani
    8893063.7451,          86382,                   7.1191,          10.10%, liquidity-bot-mauritso2
    7583349.3258,          86358,                   5.0584,           8.91%, liquidity-bot-mauritso
    6019348.3032,          86400,                   3.7423,           5.59%, hcf27
    5872279.0644,          86355,                   4.0645,          10.05%, liquidity-bot-linouxisbot
    5126273.1861,          34512,                   5.0796,           8.34%, liquidity-bot-linouxis2
    1843986.2718,          86400,                   1.9250,          10.35%, liquidity-bot-bm
2016-04-10 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  641074500.0000,          40932,                 250.0000,           6.17%, hugogoulart
  307256636.3463,          77805,                 261.7285,           7.47%, bts-scotter
  105651130.2000,          40932,                  41.8000,           6.21%, liondani
   98901551.4495,          40932,                  24.7161,           4.55%, hcf27
   60203082.8904,          86142,                  48.9843,          11.24%, altfund
    9153766.9794,          81756,                   4.2575,           9.67%, liquidity-bot-linouxis2
    8539407.2832,          51045,                   6.3794,           9.98%, liquidity-bot-mauritso2
    7128896.5920,          81825,                   3.3514,          10.13%, liquidity-bot-linouxisbot
    6013054.6734,          52911,                   4.4974,          10.10%, liquidity-bot-mauritso
    2609749.4892,          22080,                   0.8181,           0.91%, lin9uxis
    2256716.3844,          41688,                   1.8667,           8.57%, liquidity-bot-bm
2016-04-11 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  203062435.9842,          86364,                 243.8607,          11.80%, bts-scotter
   63045259.2621,          86400,                  47.8009,           9.71%, altfund
   28664143.6950,          73029,                  17.7294,           6.74%, lin9uxis
   10421922.3498,          86400,                   2.7953,           7.02%, liquidity-bot-mauritso2
    5889780.8652,          86379,                   2.2405,           8.13%, liquidity-bot-mauritso
    5057244.0000,          23136,                  12.0000,           5.31%, mf-tzo
    4649968.5468,          86379,                   3.5671,          10.44%, liquidity-bot-linouxis2
    4043822.3133,          86340,                   2.6223,          10.34%, liquidity-bot-linouxisbot
2016-04-12 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  184400378.7000,          74262,                  59.8885,           2.71%, lin9uxis
  158725194.2100,          86400,                 264.4230,          13.38%, bts-scotter
   48644049.8322,          86400,                  87.5899,          15.58%, altfund
   37088100.0000,          74418,                  12.0000,           2.69%, mf-tzo
   14851206.9189,          75273,                   3.0389,           5.94%, liquidity-bot-linouxisbot
   13052533.0683,          82977,                   2.1416,           4.14%, liquidity-bot-mauritso
    3235363.3944,          63702,                   3.2218,           9.41%, liquidity-bot-linouxis2
    1367414.0955,          55479,                   1.4165,           7.43%, liquidity-bot-mauritso2
2016-04-13 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  183696659.8428,          84627,                  14.7424,           0.53%, liquidity-bot-linouxisbot
  113107835.0706,          60057,                  98.7177,          16.29%, altfund
   76662915.9213,          86007,                   8.3629,           0.97%, liquidity-bot-mauritso
   32650952.0400,          20580,                 264.4230,          15.18%, bts-scotter
2016-04-14 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  175152253.2675,          86274,                  13.1509,           0.51%, liquidity-bot-linouxisbot
  145550405.9097,          86121,                  16.2243,           1.07%, liquidity-bot-mauritso
   13981905.1650,          36879,                  27.6572,          10.56%, altfund
2016-04-15 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
  133207487.4483,          76944,                  17.1908,           1.00%, liquidity-bot-mauritso
   23654215.1253,          56328,                  27.6005,          10.20%, altfund
    2526552.0000,           9996,                  36.0000,          13.04%, liondani
    2261559.6990,           3384,                   2.4555,          -0.72%, liquidity-bot-linouxisbot
    1573635.0000,           6393,                  35.0000,          12.88%, lin9uxis
2016-04-16 score,  shown seconds,  average order size(EUR),  average spread, account
---------------------------------------------------------------------------------------------------------
   14676118.5792,          44838,                   2.2240,           0.53%, unicef
   10054002.5571,          39303,                  30.6234,          11.32%, liondani
    8992500.0000,          17985,                 100.0000,          19.64%, mf-tzo
    4197606.8352,          29196,                  12.3309,           9.70%, altfund
     816358.4748,           4944,                  16.7016,           9.63%, lin9uxis
     348007.9845,          56082,                   0.0430,           0.60%, liquidity-bot-mauritso
       3566.5392,            537,                   0.8302,          11.60%, sir-richard
@kenCode
Title: Re: Subsidizing Market Liquidity
Post by: abit on April 17, 2016, 02:12:35 pm
@kenCode @onceuponatime BTS/CAD scores are here.
Formula used to calculate score in this link : https://bitsharestalk.org/index.php/topic,21544.msg289590.html#msg289590
Code: [Select]
2016-04-01 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
2016-04-02 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  479730450.0000,          75603,                  50.0000,           0.89%, marginal
2016-04-03 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  376408700.1840,          86400,                  49.9989,           1.42%, marginal
2016-04-04 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  157197578.5920,          86400,                  49.9792,           4.25%, marginal
2016-04-05 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
   66762847.3536,          86400,                  49.9265,           6.29%, marginal
         19.5120,             21,                   0.0248,           2.65%, liquidity-bot-xdfx6
2016-04-06 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
   70602916.6782,          62619,                  58.9682,           5.27%, marginal
    9344869.5435,          42153,                  19.9497,          10.73%, altfund
     313690.8300,           3711,                   7.9000,          10.59%, liquidity-bot-mauritso
         96.3855,          18432,                   0.0005,          11.36%, liquidity-bot-xdfx6
2016-04-07 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  287759760.0000,          86400,                 120.0000,           3.67%, marginal
   18844195.8423,          86400,                  19.8560,          10.08%, altfund
    9718461.1755,          52269,                  11.1444,           9.46%, liquidity-bot-mauritso2
    7857066.6600,          86355,                   7.8996,          10.09%, liquidity-bot-mauritso
     116049.5820,           4929,                   2.1399,          10.13%, liquidity-bot-gold21
2016-04-08 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1222919640.0000,          63990,                  97.1261,           0.27%, marginal
  172131468.2187,          85929,                  70.3872,           5.36%, altfund
   44390792.0427,          86382,                  10.7678,           6.85%, liquidity-bot-mauritso2
   13834891.5900,          86400,                   7.5612,           7.74%, liquidity-bot-mauritso
    2024773.7103,          58575,                   2.1465,           9.15%, liquidity-bot-gold21
    1104040.0947,          13902,                   5.9915,          10.14%, liquidity-bot-linouxisbot
     631157.7822,          26493,                   2.1401,          10.16%, liquidity-bot-bm
2016-04-09 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  433448895.0000,          73371,                  38.2023,           0.46%, marginal
  193185544.8228,          86271,                  89.1701,           6.92%, altfund
   18432836.2542,          86379,                  10.5874,           9.14%, liquidity-bot-mauritso2
   11575350.0000,          12825,                  75.8947,          10.27%, hcf27
    8951356.4904,          86352,                   7.3768,           9.35%, liquidity-bot-mauritso
    7746293.5170,          86352,                   5.9752,          10.04%, liquidity-bot-linouxisbot
    5352933.1215,          34470,                   7.4134,           9.18%, liquidity-bot-linouxis2
    2418480.0441,          86364,                   2.1396,           9.91%, liquidity-bot-bm
2016-04-10 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  235020829.5204,          74718,                  66.4142,           8.44%, hcf27
  152601980.1036,          28224,                  17.7114,          -0.86%, marginal
  112264922.4327,          86139,                  68.4092,          10.08%, altfund
   36276140.8602,          86379,                   9.2921,           7.92%, liquidity-bot-mauritso2
   29190766.0914,          86376,                   6.7895,           7.84%, liquidity-bot-mauritso
   26815035.2262,          86376,                   7.5069,           8.77%, liquidity-bot-linouxis2
   17212301.8422,          86352,                   6.3059,           9.81%, liquidity-bot-linouxisbot
   12882037.6500,          10728,                  14.4860,           1.39%, unosuke
    7411279.1298,          86364,                   1.7573,           7.88%, liquidity-bot-bm
2016-04-11 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  226429327.8402,          86400,                  74.0978,           7.46%, altfund
  128306580.0000,          33678,                  20.0000,           0.11%, marginal
   91981309.7982,          33651,                  14.9171,           0.20%, unosuke
   24950477.4021,          86400,                   7.6895,           6.90%, liquidity-bot-mauritso2
   20819216.8554,          86376,                   5.8730,           7.42%, liquidity-bot-mauritso
   16257712.0380,          86373,                   7.8505,           9.12%, liquidity-bot-linouxis2
    9492898.0689,          86331,                   6.5211,           9.68%, liquidity-bot-linouxisbot
    3348479.0349,          86373,                   1.5270,           8.61%, liquidity-bot-bm
2016-04-12 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  399054944.4963,          86400,                  66.7580,           4.49%, altfund
   76486235.2398,          86172,                  10.5278,           3.22%, liquidity-bot-mauritso
   55305467.2596,          86310,                   8.9203,           5.20%, liquidity-bot-linouxisbot
   22898510.0523,          55479,                   7.0434,           5.05%, liquidity-bot-mauritso2
   18307597.6302,          63702,                   8.0667,           8.08%, liquidity-bot-linouxis2
    2704948.8942,          86400,                   1.5597,           8.63%, liquidity-bot-bm
2016-04-13 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  327604995.6066,          83652,                  25.8160,           0.49%, liquidity-bot-linouxisbot
  174148048.8558,          84324,                  19.7136,           0.99%, liquidity-bot-mauritso
  150599909.6640,          78348,                  40.4333,           2.33%, marginal
   56750351.1588,          50739,                  55.1550,           6.00%, altfund
     661879.8651,          34983,                   1.5169,           9.58%, liquidity-bot-bm
2016-04-14 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  573780169.6980,          86265,                  51.0970,           0.70%, liquidity-bot-linouxisbot
  259198640.7666,          86100,                  30.1531,           1.04%, liquidity-bot-mauritso
  142314300.0000,           7860,                 100.0000,           0.18%, indominon
  129195313.9890,          86400,                  40.4470,           2.76%, marginal
   49382325.0000,          38388,                  99.9648,          10.32%, hcf27
   16876810.6155,          36876,                  39.9558,          11.18%, altfund
2016-04-15 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  947160585.0000,          61686,                  96.1387,           0.42%, indominon
  399864325.5210,          56157,                  51.0970,           0.65%, liquidity-bot-linouxisbot
  231069070.9911,          82806,                  24.5363,           0.89%, liquidity-bot-mauritso
  181145163.0270,          64998,                  41.7463,           2.21%, marginal
   94376925.0000,          86400,                  91.6939,          10.76%, hcf27
   26953932.9072,          56331,                  39.9041,          11.07%, altfund
2016-04-16 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1944614835.0000,          78777,                 234.7345,           1.32%, indominon
  160461523.1514,          86400,                 166.4073,          11.31%, hcf27
   54096240.0000,           6450,                  40.0000,          -0.09%, disperse
   28312325.2809,          83421,                   3.1825,           1.00%, liquidity-bot-mauritso
   17482373.7570,          31056,                  25.2144,          10.14%, altfund
Title: Re: Subsidizing Market Liquidity
Post by: kenCode on April 17, 2016, 03:08:50 pm
 +5% +5% +5% +5% +5% +5% +5%
Title: Re: Subsidizing Market Liquidity
Post by: abit on May 12, 2016, 08:38:33 am
Update: @kenCode @onceuponatime @BunkerChain Labs more liquidity statistics data of BTS/CAD is below. If you want data of other markets please let me know.
Code: [Select]
2016-04-17 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1679784630.0000,          86400,                 220.0729,           1.85%, indominon
  413342520.0000,          86400,                  40.0000,           1.29%, disperse
  147415772.1936,          86400,                 160.9778,          11.60%, hcf27
   89943323.4054,          54282,                  16.8783,           1.05%, liquidity-bot-mauritso
   40433650.1589,          86400,                  20.4515,           9.45%, altfund
   11114188.2180,          10269,                   8.9795,           0.83%, liquidity-bot-linouxisbot
2016-04-18 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1716062835.0000,          86400,                 281.7237,           2.14%, indominon
  196092009.7368,          86400,                 184.9540,          11.31%, hcf27
  186564821.5332,          86400,                  40.0080,           2.09%, disperse
   24619179.3372,          86400,                  20.4515,          10.19%, altfund
    9467900.5362,          50544,                   1.2515,           0.51%, liquidity-bot-linouxisbot
2016-04-19 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1876070530.3704,          86400,                 251.6304,           1.48%, indominon
  327427800.0000,          86400,                  40.0000,           1.16%, disperse
  270215003.6730,          69948,                  26.9448,           0.56%, liquidity-bot-linouxisbot
  247900736.8764,          86400,                 195.4876,          10.66%, hcf27
  182062500.0000,          17631,                  50.0000,          -0.07%, onceuponatime
   94502025.0000,          17877,                  25.0000,          -0.12%, marginal
   33160397.5437,          86400,                  20.4515,           9.33%, altfund
2016-04-20 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  851181600.0000,          86400,                 215.0000,           3.22%, indominon
  392471850.0000,          86400,                  71.6423,           2.85%, onceuponatime
  295600137.1692,          79035,                  32.4233,           0.98%, liquidity-bot-linouxisbot
  214231200.0000,          86400,                  40.0000,           2.64%, disperse
  202722788.7825,          86400,                  36.3281,           2.82%, marginal
  198717551.7468,          86400,                 186.2514,          11.50%, hcf27
   26128035.2127,          86271,                  20.3121,          10.58%, altfund
    1234775.1276,           1578,                  13.6062,           1.80%, liquidity-bot-mauritso
2016-04-21 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  574943245.5240,          86400,                 199.2234,           4.10%, onceuponatime
  469674601.8288,          82737,                  38.9014,           0.56%, liquidity-bot-linouxisbot
  254933228.8119,          86400,                  90.3350,           4.25%, marginal
  233829915.0000,          74811,                 214.2290,           6.69%, indominon
  103236600.5508,          86400,                 149.0214,          13.06%, hcf27
   44048520.0000,          69180,                  40.0000,           6.14%, disperse
   35459123.5656,          46281,                  14.4396,           1.99%, liquidity-bot-mauritso
   17263562.5431,          86148,                  16.8216,          10.76%, altfund
2016-04-22 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1438698942.8346,          86400,                 137.1420,           0.98%, onceuponatime
  617953808.4951,          86151,                  51.6665,           0.63%, liquidity-bot-linouxisbot
  365934445.8084,          86400,                 140.3869,           8.32%, hcf27
   51993996.1632,          12216,                  25.1806,           0.32%, liquidity-bot-mauritso
   36136899.0792,           2322,                  58.2390,          -0.67%, marginal
   21372200.1354,          86271,                  15.7902,           9.76%, altfund
2016-04-23 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1697320301.7438,          86400,                  92.0367,           0.19%, hcf27
 1694801465.7336,          86400,                  91.6481,          -0.02%, onceuponatime
 1034187019.0377,          86400,                  55.2286,           0.02%, liquidity-bot-linouxisbot
   26186324.7135,          86400,                  17.4020,          10.46%, altfund
2016-04-24 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1654176620.6574,          76896,                 100.0262,          -0.11%, hcf27
 1463269701.0723,          76896,                  54.0614,          -1.52%, liquidity-bot-linouxisbot
 1358711400.0000,          76896,                  50.0000,          -1.53%, onceuponatime
   39200607.8700,          86400,                  17.0829,           8.62%, altfund
    3748584.4500,           7746,                   2.0363,          -0.38%, unosuke
    1254069.3837,           6534,                   3.9529,           2.10%, liquidity-bot-mauritso
2016-04-25 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
   58358130.9186,          85635,                  29.8558,           8.86%, altfund
   33496939.0944,          68835,                   2.0364,          -0.36%, unosuke
    2019105.1008,           8787,                   3.9538,           1.86%, liquidity-bot-mauritso
2016-04-26 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  177149031.6762,          27948,                  45.7554,           0.64%, liquidity-bot-linouxisbot
   24185387.2896,          86367,                   5.4528,           2.03%, liquidity-bot-mauritso
   17363588.3697,          86271,                  18.4351,          11.48%, altfund
2016-04-27 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  595482875.4582,          85974,                  45.7554,           0.51%, liquidity-bot-linouxisbot
   29916689.3946,          86313,                   5.5512,           1.71%, liquidity-bot-mauritso
   20071257.4335,          86271,                  20.3897,          11.10%, altfund
2016-04-28 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  947452356.5940,          86019,                  73.2746,           0.50%, liquidity-bot-linouxisbot
   40690830.5124,          86400,                  20.3897,           9.09%, altfund
   34111728.8160,          86346,                   7.6565,           2.02%, liquidity-bot-mauritso
   19728352.3809,           3399,                  23.6251,          -0.46%, disperse
2016-04-29 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 2227947988.1724,          86400,                  75.2492,          -1.43%, liquidity-bot-linouxisbot
  117411998.7360,          86400,                   7.6565,           0.30%, liquidity-bot-mauritso
   52077420.8892,          86271,                  20.3897,           8.77%, altfund
2016-04-30 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1222946762.6844,          86400,                  75.2492,           0.11%, liquidity-bot-linouxisbot
   44017945.8675,          86400,                   7.6565,           1.82%, liquidity-bot-mauritso
   21683841.2499,          86400,                  20.3897,          11.02%, altfund
Code: [Select]
2016-05-01 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  572562734.8896,          86400,                  75.2492,           1.72%, liquidity-bot-linouxisbot
   29011690.7916,          86397,                   7.9288,           3.11%, liquidity-bot-mauritso
   16678450.0854,          86400,                  20.3897,          12.45%, altfund
2016-05-02 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  175282627.0104,          86400,                  75.2492,           4.81%, liquidity-bot-linouxisbot
   11202146.2938,          86400,                  17.4858,          14.24%, altfund
    8893063.2807,          32901,                   2.5635,           0.95%, liquidity-bot-mauritso
2016-05-03 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  123107615.9508,          86400,                  75.2492,           5.22%, liquidity-bot-linouxisbot
   11644654.5285,          86400,                  20.0003,          15.47%, altfund
2016-05-04 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  137606707.0560,          86400,                  75.2492,           4.68%, liquidity-bot-linouxisbot
   12106146.6996,          86400,                  20.3721,          15.08%, altfund
2016-05-05 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  434611673.3328,          86364,                  87.4432,           2.69%, liquidity-bot-linouxisbot
   12377701.5975,          86400,                  20.3897,          14.79%, altfund
    2680374.8628,          39576,                   1.0716,           1.85%, liquidity-bot-mauritso4
2016-05-06 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1305533288.5548,          86238,                  99.7111,           0.60%, liquidity-bot-linouxisbot
   15784473.5538,          78615,                  21.0222,          12.95%, altfund
   11363508.3222,          86400,                   1.9318,           1.94%, liquidity-bot-mauritso4
2016-05-07 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1266293439.2160,          86025,                  95.2144,           0.45%, liquidity-bot-linouxisbot
   62093345.9601,          85851,                   6.5323,           0.89%, liquidity-bot-mauritso
   26731017.3057,          86400,                  21.4923,          10.55%, altfund
   15740399.8626,          86373,                   1.6074,           0.86%, liquidity-bot-mauritso4
2016-05-08 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1214654861.5200,          86034,                  95.2144,           0.52%, liquidity-bot-linouxisbot
   58143120.4395,          86379,                   6.5323,           0.97%, liquidity-bot-mauritso
   36772847.0229,          86178,                  21.9355,           9.72%, altfund
   22366630.0599,          86385,                   2.9839,           1.22%, liquidity-bot-mauritso4
2016-05-09 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 2102588296.1949,          86091,                  96.1060,          -0.53%, liquidity-bot-linouxisbot
   61752279.4416,          86400,                  21.4711,           8.88%, altfund
   32259025.4001,          45147,                   6.5323,           0.92%, liquidity-bot-mauritso
   10077515.1780,          52350,                   2.9795,           2.06%, liquidity-bot-mauritso4
2016-05-10 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 2337113349.8355,          86400,                  53.9059,          -3.02%, liquidity-bot-linouxisbot
   60140709.1824,          86400,                  17.3626,           5.51%, altfund
   42730700.3604,          53103,                   5.2372,           0.46%, liquidity-bot-mauritso
2016-05-11 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  414175344.1707,          53049,                  13.6305,          -3.73%, liquidity-bot-linouxisbot
   88822292.5095,          86400,                   5.7235,           0.19%, liquidity-bot-mauritso
   43268387.5026,          86391,                  32.6149,           9.09%, altfund
Title: Re: Subsidizing Market Liquidity
Post by: tbone on May 13, 2016, 03:26:34 am
@abit:

Was just wondering, how can the spread be negative?
Title: Re: Subsidizing Market Liquidity
Post by: cube on May 13, 2016, 03:58:26 am
Nice data reports.  Are you able to put them up in a site with visual charts? 


Update: @kenCode @onceuponatime @BunkerChain Labs more liquidity statistics data of BTS/CAD is below. If you want data of other markets please let me know.
Code: [Select]
2016-04-17 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1679784630.0000,          86400,                 220.0729,           1.85%, indominon
  413342520.0000,          86400,                  40.0000,           1.29%, disperse
  147415772.1936,          86400,                 160.9778,          11.60%, hcf27
   89943323.4054,          54282,                  16.8783,           1.05%, liquidity-bot-mauritso
   40433650.1589,          86400,                  20.4515,           9.45%, altfund
   11114188.2180,          10269,                   8.9795,           0.83%, liquidity-bot-linouxisbot
2016-04-18 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1716062835.0000,          86400,                 281.7237,           2.14%, indominon
  196092009.7368,          86400,                 184.9540,          11.31%, hcf27
  186564821.5332,          86400,                  40.0080,           2.09%, disperse
   24619179.3372,          86400,                  20.4515,          10.19%, altfund
    9467900.5362,          50544,                   1.2515,           0.51%, liquidity-bot-linouxisbot
2016-04-19 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1876070530.3704,          86400,                 251.6304,           1.48%, indominon
  327427800.0000,          86400,                  40.0000,           1.16%, disperse
  270215003.6730,          69948,                  26.9448,           0.56%, liquidity-bot-linouxisbot
  247900736.8764,          86400,                 195.4876,          10.66%, hcf27
  182062500.0000,          17631,                  50.0000,          -0.07%, onceuponatime
   94502025.0000,          17877,                  25.0000,          -0.12%, marginal
   33160397.5437,          86400,                  20.4515,           9.33%, altfund
2016-04-20 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  851181600.0000,          86400,                 215.0000,           3.22%, indominon
  392471850.0000,          86400,                  71.6423,           2.85%, onceuponatime
  295600137.1692,          79035,                  32.4233,           0.98%, liquidity-bot-linouxisbot
  214231200.0000,          86400,                  40.0000,           2.64%, disperse
  202722788.7825,          86400,                  36.3281,           2.82%, marginal
  198717551.7468,          86400,                 186.2514,          11.50%, hcf27
   26128035.2127,          86271,                  20.3121,          10.58%, altfund
    1234775.1276,           1578,                  13.6062,           1.80%, liquidity-bot-mauritso
2016-04-21 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  574943245.5240,          86400,                 199.2234,           4.10%, onceuponatime
  469674601.8288,          82737,                  38.9014,           0.56%, liquidity-bot-linouxisbot
  254933228.8119,          86400,                  90.3350,           4.25%, marginal
  233829915.0000,          74811,                 214.2290,           6.69%, indominon
  103236600.5508,          86400,                 149.0214,          13.06%, hcf27
   44048520.0000,          69180,                  40.0000,           6.14%, disperse
   35459123.5656,          46281,                  14.4396,           1.99%, liquidity-bot-mauritso
   17263562.5431,          86148,                  16.8216,          10.76%, altfund
2016-04-22 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1438698942.8346,          86400,                 137.1420,           0.98%, onceuponatime
  617953808.4951,          86151,                  51.6665,           0.63%, liquidity-bot-linouxisbot
  365934445.8084,          86400,                 140.3869,           8.32%, hcf27
   51993996.1632,          12216,                  25.1806,           0.32%, liquidity-bot-mauritso
   36136899.0792,           2322,                  58.2390,          -0.67%, marginal
   21372200.1354,          86271,                  15.7902,           9.76%, altfund
2016-04-23 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1697320301.7438,          86400,                  92.0367,           0.19%, hcf27
 1694801465.7336,          86400,                  91.6481,          -0.02%, onceuponatime
 1034187019.0377,          86400,                  55.2286,           0.02%, liquidity-bot-linouxisbot
   26186324.7135,          86400,                  17.4020,          10.46%, altfund
2016-04-24 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1654176620.6574,          76896,                 100.0262,          -0.11%, hcf27
 1463269701.0723,          76896,                  54.0614,          -1.52%, liquidity-bot-linouxisbot
 1358711400.0000,          76896,                  50.0000,          -1.53%, onceuponatime
   39200607.8700,          86400,                  17.0829,           8.62%, altfund
    3748584.4500,           7746,                   2.0363,          -0.38%, unosuke
    1254069.3837,           6534,                   3.9529,           2.10%, liquidity-bot-mauritso
2016-04-25 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
   58358130.9186,          85635,                  29.8558,           8.86%, altfund
   33496939.0944,          68835,                   2.0364,          -0.36%, unosuke
    2019105.1008,           8787,                   3.9538,           1.86%, liquidity-bot-mauritso
2016-04-26 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  177149031.6762,          27948,                  45.7554,           0.64%, liquidity-bot-linouxisbot
   24185387.2896,          86367,                   5.4528,           2.03%, liquidity-bot-mauritso
   17363588.3697,          86271,                  18.4351,          11.48%, altfund
2016-04-27 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  595482875.4582,          85974,                  45.7554,           0.51%, liquidity-bot-linouxisbot
   29916689.3946,          86313,                   5.5512,           1.71%, liquidity-bot-mauritso
   20071257.4335,          86271,                  20.3897,          11.10%, altfund
2016-04-28 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  947452356.5940,          86019,                  73.2746,           0.50%, liquidity-bot-linouxisbot
   40690830.5124,          86400,                  20.3897,           9.09%, altfund
   34111728.8160,          86346,                   7.6565,           2.02%, liquidity-bot-mauritso
   19728352.3809,           3399,                  23.6251,          -0.46%, disperse
2016-04-29 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 2227947988.1724,          86400,                  75.2492,          -1.43%, liquidity-bot-linouxisbot
  117411998.7360,          86400,                   7.6565,           0.30%, liquidity-bot-mauritso
   52077420.8892,          86271,                  20.3897,           8.77%, altfund
2016-04-30 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1222946762.6844,          86400,                  75.2492,           0.11%, liquidity-bot-linouxisbot
   44017945.8675,          86400,                   7.6565,           1.82%, liquidity-bot-mauritso
   21683841.2499,          86400,                  20.3897,          11.02%, altfund
Code: [Select]
2016-05-01 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  572562734.8896,          86400,                  75.2492,           1.72%, liquidity-bot-linouxisbot
   29011690.7916,          86397,                   7.9288,           3.11%, liquidity-bot-mauritso
   16678450.0854,          86400,                  20.3897,          12.45%, altfund
2016-05-02 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  175282627.0104,          86400,                  75.2492,           4.81%, liquidity-bot-linouxisbot
   11202146.2938,          86400,                  17.4858,          14.24%, altfund
    8893063.2807,          32901,                   2.5635,           0.95%, liquidity-bot-mauritso
2016-05-03 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  123107615.9508,          86400,                  75.2492,           5.22%, liquidity-bot-linouxisbot
   11644654.5285,          86400,                  20.0003,          15.47%, altfund
2016-05-04 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  137606707.0560,          86400,                  75.2492,           4.68%, liquidity-bot-linouxisbot
   12106146.6996,          86400,                  20.3721,          15.08%, altfund
2016-05-05 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  434611673.3328,          86364,                  87.4432,           2.69%, liquidity-bot-linouxisbot
   12377701.5975,          86400,                  20.3897,          14.79%, altfund
    2680374.8628,          39576,                   1.0716,           1.85%, liquidity-bot-mauritso4
2016-05-06 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1305533288.5548,          86238,                  99.7111,           0.60%, liquidity-bot-linouxisbot
   15784473.5538,          78615,                  21.0222,          12.95%, altfund
   11363508.3222,          86400,                   1.9318,           1.94%, liquidity-bot-mauritso4
2016-05-07 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1266293439.2160,          86025,                  95.2144,           0.45%, liquidity-bot-linouxisbot
   62093345.9601,          85851,                   6.5323,           0.89%, liquidity-bot-mauritso
   26731017.3057,          86400,                  21.4923,          10.55%, altfund
   15740399.8626,          86373,                   1.6074,           0.86%, liquidity-bot-mauritso4
2016-05-08 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 1214654861.5200,          86034,                  95.2144,           0.52%, liquidity-bot-linouxisbot
   58143120.4395,          86379,                   6.5323,           0.97%, liquidity-bot-mauritso
   36772847.0229,          86178,                  21.9355,           9.72%, altfund
   22366630.0599,          86385,                   2.9839,           1.22%, liquidity-bot-mauritso4
2016-05-09 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 2102588296.1949,          86091,                  96.1060,          -0.53%, liquidity-bot-linouxisbot
   61752279.4416,          86400,                  21.4711,           8.88%, altfund
   32259025.4001,          45147,                   6.5323,           0.92%, liquidity-bot-mauritso
   10077515.1780,          52350,                   2.9795,           2.06%, liquidity-bot-mauritso4
2016-05-10 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
 2337113349.8355,          86400,                  53.9059,          -3.02%, liquidity-bot-linouxisbot
   60140709.1824,          86400,                  17.3626,           5.51%, altfund
   42730700.3604,          53103,                   5.2372,           0.46%, liquidity-bot-mauritso
2016-05-11 score,  shown seconds,  average order size(CAD),  average spread, account
---------------------------------------------------------------------------------------------------------
  414175344.1707,          53049,                  13.6305,          -3.73%, liquidity-bot-linouxisbot
   88822292.5095,          86400,                   5.7235,           0.19%, liquidity-bot-mauritso
   43268387.5026,          86391,                  32.6149,           9.09%, altfund
Title: Re: Subsidizing Market Liquidity
Post by: abit on May 13, 2016, 01:23:47 pm
@abit:

Was just wondering, how can the spread be negative?
Negative spread means someone was selling smart coins below the feed price.

Nice data reports.  Are you able to put them up in a site with visual charts? 
Hope someone else would do that. I'm not willing to run web services, however I can provide data feeds, like this https://data.sparkfun.com/bitshares_usd_price
Title: Re: Subsidizing Market Liquidity
Post by: CoinHoarder on June 21, 2016, 04:56:56 pm
 +5% +5%

What is happening with this? Bitshares really needs this or something like it.

I still think my idea is better, but something is better than nothing. Last time I discussed my idea with forum members, I was never convinced that it wouldn't work. The main antagonists mainly slapped their knees and said "Nubits = bad". However, they wrongly deduced that my idea is anything like Nubits... because it isn't. It is quite different from Nubits in numerous ways. For instance, Nubits' recent derailing of their peg would not of happened with my proposal.

1.   Bitshares autonomously issues new BTS tokens, specifically for the purpose of funding liquidity operations.
2.   Bitshares shorts every committee-issued SmartCoin, and puts them up for sale at an arbitrary percentage over the price feed, while at the same time putting up buy orders at the same arbitrary percentage below the peg. Autonomous liquidity is provided for both sides of the markets.
3.   The percentage the SmartCoins are sold over (and under) the price feed, the amount of liquidity provided for each SmartCoin market and the amount of collateral is determined by the committee. Thus, it can be adjusted whenever the community deems it is necessary.
4.   Considering that the autonomous liquidity is provided at an arbitrary amount above (and below) the peg, Bitshares will make a profit each time these autonomous liquidity operations are utilized. Thus, the amount of funds available for these liquidity operations will grow in time without the need for any more dilution. This profit can be used to provide more liquidity, or it can be burned as the community sees fit.
5.   If the liquidity pool for any certain SmartCoin is running low, Bitshares can autonomously issue more BTS tokens so that the amount of liquidity provided (which is again set by the committee) is maintained.
     a.   This step would only be necessary if:
              i.   The committee adds more SmartCoins (such as bitAPPLE, bitGOOGLE, etc.) to the DEX.
             ii.   On the off chance that the market making operations are unprofitable due to market trends. Market making operations cannot be guaranteed to be profitable.
6.   Instant liquidity is observed across all SmartCoin markets, effectively bootstrapping DEX liquidity and fixing one of Bitshares’ most glaring problems.
7.   As “natural liquidity” (liquidity provided by actual users) grows, the committee can lower the amount of liquidity provided autonomously. Effectively, this proposal works as training wheels on a bicycle. As soon as the DEX has sufficient “natural liquidity”, all autonomous liquidity operations can cease and the BTS/SmartCoins that were printed can be burned.
     a.   Autonomous liquidity operations can be ceased on a market-by-market basis, as inherently some markets will be dynamically more liquid than others.
Title: Re: Subsidizing Market Liquidity
Post by: bitsharesbrazil on June 21, 2016, 05:45:55 pm
very important topic for dex n smartcoins future, our main product.......i need reread everything carefully this is for pros!
Title: Re: Subsidizing Market Liquidity
Post by: R on August 12, 2016, 03:41:53 pm
https://steemit.com/gridcoin/@cm-steem/brainstorming-new-boinc-projects-anyone-can-create-a-project-and-reward-their-users-with-gridcoin#@cm-steem/re-cm-steem-brainstorming-new-boinc-projects-anyone-can-create-a-project-and-reward-their-users-with-gridcoin-20160812t153824382z

Thoughts? The major difficulty would be providing the liquidity software to volunteers without providing said volunteers the ability to steal funds from the liquidity software. If this difficult issue was solved, then we could easily distribute liquidity software to several thousand individuals from all around the world.

If a BOINC project was created for this purpose, you could go a step further and distribute UIA against those running the liquidity software: https://steemit.com/steem/@cm-steem/gauging-interest-would-you-be-interested-being-able-to-tip-boinc-users-your-crypto-asset-of-choice
Title: Re: Subsidizing Market Liquidity
Post by: R on August 29, 2016, 01:31:52 pm
*bump*

Any thoughts regarding my BTS liquidity bot BOINC project idea?
Title: Re: Subsidizing Market Liquidity
Post by: R on July 19, 2017, 03:45:49 pm
Bump!

What do you think of performing manual UIA sharedrops against participants in fill orders for MPA on the BTS DEX?

I'm thinking of taking the list of an MPA's asset holders, then grabbing each of these user's trading history for the last month, then filter for fill orders & evaluate their market making participation for sharedrop issuance.. should we only be incentivizing fill orders or should we also consider incentivizing collateral?