Author Topic: Incentivising Liquidity  (Read 6637 times)

0 Members and 1 Guest are viewing this topic.

Offline theredpill

I keep saying it and will say it again.

We need relative orders that allow orders to be placed in relation to the feed price and then move with it.

If you had a script that did that, but you had to pay a transaction fee when the price drifted by some value from the original, would you use it?

It can be implemented using your own server (I'd make a worker to write the tool and split it with xeroc for using his library). But without a hardfork and some serious coding, it isn't immediately implementable on the chain.

I'm against this because put a lot of trust in the publishing feeds and risk on the system since witness could easily manipulate the feed and run with a lot of money. Also this can easily be work around using third part tools or bots.

I'm actually talking about making a third party tool or bot to do what jonny's asking since you can't do it on the chain.

That's a fair concern about relying on someone else's data. You could use your own feed so it doesn't rely on anyone else.

Yes I see now, I get confused by the hardfork part. About paying fee when price drifted, this gonna be solved by proposal #1 of BM. (except for anti-spam fee)
« Last Edit: December 04, 2015, 02:52:36 am by theredpill »

Offline btstip

  • Hero Member
  • *****
  • Posts: 644
    • View Profile
  • BitShares: btstip-io
Hey rgcrypto, here are the results of your tips...
Curious about BtsTip? Visit us at http://sharebits.io and start tipping BTS on https://bitsharestalk.org/ today!
Created by hybridd

Offline rgcrypto

  • Hero Member
  • *****
  • Posts: 557
    • View Profile
    • Cryptoctopus Blog
Now it is time for take the ass off the chair and make the world we wish to see.

#sharebits "theredpill" 1 FISTBUMP
#sharebits "theredpill" 1 HIGHFIVE
#sharebits "theredpill" 50 BTS

Offline maqifrnswa

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
I keep saying it and will say it again.

We need relative orders that allow orders to be placed in relation to the feed price and then move with it.

If you had a script that did that, but you had to pay a transaction fee when the price drifted by some value from the original, would you use it?

It can be implemented using your own server (I'd make a worker to write the tool and split it with xeroc for using his library). But without a hardfork and some serious coding, it isn't immediately implementable on the chain.

I'm against this because put a lot of trust in the publishing feeds and risk on the system since witness could easily manipulate the feed and run with a lot of money. Also this can easily be work around using third part tools or bots.

I'm actually talking about making a third party tool or bot to do what jonny's asking since you can't do it on the chain.

That's a fair concern about relying on someone else's data. You could use your own feed so it doesn't rely on anyone else.
maintains an Ubuntu PPA: https://launchpad.net/~showard314/+archive/ubuntu/bitshares [15% delegate] wallet_account_set_approval maqifrnswa true [50% delegate] wallet_account_set_approval delegate1.maqifrnswa true

Offline theredpill

Really? Do you have a list?
I think metaexchange, but anyway we just start BTS 2.0, the system is in its infancy now, there's lots of tools coming out soon. I for instance am building something. Now it is time for take the ass off the chair and make the world we wish to see.

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
I keep saying it and will say it again.

We need relative orders that allow orders to be placed in relation to the feed price and then move with it.

If you had a script that did that, but you had to pay a transaction fee when the price drifted by some value from the original, would you use it?

It can be implemented using your own server (I'd make a worker to write the tool and split it with xeroc for using his library). But without a hardfork and some serious coding, it isn't immediately implementable on the chain.

I'm against this because put a lot of trust in the publishing feeds and risk on the system since witness could easily manipulate the feed and run with a lot of money. Also this can easily be work around using third part tools or bots.
Really? Do you have a list?
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline theredpill

I keep saying it and will say it again.

We need relative orders that allow orders to be placed in relation to the feed price and then move with it.

If you had a script that did that, but you had to pay a transaction fee when the price drifted by some value from the original, would you use it?

It can be implemented using your own server (I'd make a worker to write the tool and split it with xeroc for using his library). But without a hardfork and some serious coding, it isn't immediately implementable on the chain.

I'm against this because put a lot of trust in the publishing feeds and risk on the system since witness could easily manipulate the feed and run with a lot of money. Also this can easily be work around using third part tools or bots.


Offline maqifrnswa

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
I keep saying it and will say it again.

We need relative orders that allow orders to be placed in relation to the feed price and then move with it.

If you had a script that did that, but you had to pay a transaction fee when the price drifted by some value from the original, would you use it?

It can be implemented using your own server (I'd make a worker to write the tool and split it with xeroc for using his library). But without a hardfork and some serious coding, it isn't immediately implementable on the chain.
maintains an Ubuntu PPA: https://launchpad.net/~showard314/+archive/ubuntu/bitshares [15% delegate] wallet_account_set_approval maqifrnswa true [50% delegate] wallet_account_set_approval delegate1.maqifrnswa true

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: clayop
I think the first step is to not charge nothing (except anti-spam prevention) for operations that locks up money in the system, like borrow, vesting or making our order book.
Reducing call order update fee was discussed among committee members, and bitcrab did a survey IIRC.

And... ?

I remember there are many support for reducing the fee. I will input committee about this again.
Bitshares Korea - http://www.bitshares.kr
Vote for me and see Korean Bitshares community grows
delegate-clayop

Offline Helikopterben

  • Sr. Member
  • ****
  • Posts: 202
    • View Profile
I'm thinking give the incentive only to the short-seller-maker to reduce the premium and compensate for the added risk inherent with the short side in bitshares.
Clever idea, but how do you identify whether a maker is also a short seller? Any short position may be unrelated to a given trade.

Good point.  Maybe require the account to have 100% of the asset collateralized to qualify for the rebate.  In other words, if you put an order on the books to sell $1, then you need to have at least $1 in debt to qualify. Obviously this wouldnt be perfect because users would only need debt relative to their ask size but i'm sure there may be other ways to do this.

Offline theredpill

I think the first step is to not charge nothing (except anti-spam prevention) for operations that locks up money in the system, like borrow, vesting or making our order book.
Reducing call order update fee was discussed among committee members, and bitcrab did a survey IIRC.

And... ?

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: clayop
I think the first step is to not charge nothing (except anti-spam prevention) for operations that locks up money in the system, like borrow, vesting or making our order book.
Reducing call order update fee was discussed among committee members, and bitcrab did a survey IIRC.
Bitshares Korea - http://www.bitshares.kr
Vote for me and see Korean Bitshares community grows
delegate-clayop

Offline theredpill

I think the first step is to not charge nothing (except anti-spam prevention) for operations that locks up money in the system, like borrow, vesting or making our order book.

Offline theredpill


http://www.investopedia.com/articles/active-trading/042414/what-makertaker-fees-mean-you.asp
Quote
The maker-taker plan harks back to 1997, when Island Electronic Communications Network creator Joshua Levine designed a pricing model aimed to give providers an incentive to trade in markets with narrow spreads. Under this scenario, makers would receive a $0.002/share rebate and takers would pay a $0.003/share fee, and the exchange would keep the $0.001/share difference. By the mid-2000s, rebate capture strategies had emerged as a staple of market incentive features, with payments ranging from 20 to 30 cents for every 100 shares traded.

I'm thinking give the incentive only to the short-seller-maker to reduce the premium and compensate for the added risk inherent with the short side in bitshares.

Meanwhile we keep charging 40 BTS for borrow and update collateral... That's odd.

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: clayop
Great idea... and if we ever come to have easy-to-use market maker bots built into the wallet, this could allow massive crowd-sourced liquidity.

I support this. Users can define reference feed price, relative or absolute price, tolerance, maximum iteration, and then create MM bot (or relative order).
Bitshares Korea - http://www.bitshares.kr
Vote for me and see Korean Bitshares community grows
delegate-clayop

Tuck Fheman

  • Guest
I keep saying it and will say it again.

We need relative orders that allow orders to be placed in relation to the feed price and then move with it.

Until then, there's metaexchange.

Offline lil_jay890

  • Hero Member
  • *****
  • Posts: 1197
    • View Profile
I keep saying it and will say it again.

We need relative orders that allow orders to be placed in relation to the feed price and then move with it.

I don't think trailing orders would make that big of a difference... Plus I think those are handled by the broker in traditional markets. I don't think there is a trailing stop that can be put directly on the exchanges.

Offline JonnyB

  • Hero Member
  • *****
  • Posts: 636
    • View Profile
    • twitter.com/jonnybitcoin
I keep saying it and will say it again.

We need relative orders that allow orders to be placed in relation to the feed price and then move with it.
I run the @bitshares twitter handle
twitter.com/bitshares

Offline Chronos

I'm thinking give the incentive only to the short-seller-maker to reduce the premium and compensate for the added risk inherent with the short side in bitshares.
Clever idea, but how do you identify whether a maker is also a short seller? Any short position may be unrelated to a given trade.

Offline Helikopterben

  • Sr. Member
  • ****
  • Posts: 202
    • View Profile
The way market makers work in regular markets is that they are obligated to sell/buy at a certain price and usually it is a minimum of 1000 shares.

If they choose to sell 1000 shares as 25.50 they must keep those on the order books until their 1000 shares are gone.  What they will do is put a bid in just above the current bid, say at 25.46.  If someone sells them 1000 shares at their bid, they pocket the 4 cent spread because they will be immediately able to sell into their 1000 share sell order.

Why would someone do this you ask?  Why would they obligate themselves to sell at a certain price?  The reason is that they get commissions from the brokers that use them to fill their orders.  This is why if BTS has market makers, they should be compensated by the trading fees.  Hence we should use option 1.

Yes market makers in traditional markets often get rebates. 

http://www.investopedia.com/articles/active-trading/042414/what-makertaker-fees-mean-you.asp
Quote
The maker-taker plan harks back to 1997, when Island Electronic Communications Network creator Joshua Levine designed a pricing model aimed to give providers an incentive to trade in markets with narrow spreads. Under this scenario, makers would receive a $0.002/share rebate and takers would pay a $0.003/share fee, and the exchange would keep the $0.001/share difference. By the mid-2000s, rebate capture strategies had emerged as a staple of market incentive features, with payments ranging from 20 to 30 cents for every 100 shares traded.

I'm thinking give the incentive only to the short-seller-maker to reduce the premium and compensate for the added risk inherent with the short side in bitshares.

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
I am also in favor of #1 simply because BTS is already too complex for many traders .. let's don't make their profit calculations worse

this
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline Chronos

Option 1 is a negative maker fee. It seems it has some community support.

Now we need specifics. How about 0.2% rebate for makers, and 0.2% fee for takers? Do you think that's too little, or too much? It makes sense to me that the maker rebate would be exactly counterbalanced by an equivalently-sized taker fee, in order to prevent abuse via self-trades.

Offline lil_jay890

  • Hero Member
  • *****
  • Posts: 1197
    • View Profile
The way market makers work in regular markets is that they are obligated to sell/buy at a certain price and usually it is a minimum of 1000 shares.

If they choose to sell 1000 shares as 25.50 they must keep those on the order books until their 1000 shares are gone.  What they will do is put a bid in just above the current bid, say at 25.46.  If someone sells them 1000 shares at their bid, they pocket the 4 cent spread because they will be immediately able to sell into their 1000 share sell order.

Why would someone do this you ask?  Why would they obligate themselves to sell at a certain price?  The reason is that they get commissions from the brokers that use them to fill their orders.  This is why if BTS has market makers, they should be compensated by the trading fees.  Hence we should use option 1.

Offline botfund

  • Full Member
  • ***
  • Posts: 174
    • View Profile
  • BitShares: botfund
I think we should support percentage based trade fee and split it to maker% and taker% which can be set by committee. maker%+taker% >= 0. You can set maker% = -0.05% and taker% = 0.1%. This way maker can share fee with the network.
This is a simpler way to do the same thing.

  • NEGATIVE_MAKER_FEE = cash in the pocket of makers
  • MAKER_SHARES = more complexity and rules to accomplish the same result

I also think that liquidity would be helped by allowing orders to be placed relative to the price feed.

EDIT: Just to be clear, I'm saying that MAKER_SHARES aren't needed because a negative maker fee solves the same problem much more simply.
I really like this to be implemented and negative maker fee to improve the liquidity. I saw it worked especially near the fill price.
Regarding to the implementation, I know it's simpler if you allow both assets as fee. In this way you just match the orders like there's no fee. Then just subtract the fee from the received assets. Let's take BTS:USD as an example. If the taker is selling 10000 BTS and taker fee is 0.1% and the price is 0.05. Before fee subtract, it's 500 USD. After subtract, he gets 499.5USD and 0.5USD will be collected as fee. You'll have the same simple calculation even when maker's fee is >0, =0 or <0. That's why most exchanges use this simple rule and keep both assets as profit.
If BTA as fee is impacting the architecture, we may need the fee pool to turn it into BTS but that will be not so elegant. I think it's good to allow profit to be BTA. Anyway normally BTS and BTA fees will be likely to be similar in value.

[edit]: in the example, if maker's fee >0, it should be on BTS and USD if maker fee<0.
« Last Edit: December 03, 2015, 02:26:10 pm by botfund »

Offline Empirical1.2

  • Hero Member
  • *****
  • Posts: 1366
    • View Profile
In favour of No.1

(Kraken seems to only offer 0% maker fees for very high volume, so no maker fees for every maker would be very positive.)

Not in favour of No.2

It seems complicated & commits BTS to an approach which might not work for an extended period of time.

What about a negative fee system, funded by a worker proposal applied to just one market, such as BitGold, for a limited time period to evaluate the impact it has on bootstrapping liquidity?

Example:

Define a specific range that we would like to see BitGold trading in and reward makers within that range.

We could have a set hourly budget which rolls over if it's not fully claimed thus ensuring at some point makers will be incentivised to offer liquidity in that market.

The budget could also start out small and increase depending on results. It then also gives us the option to remove it, whether it's successful/unsuccessful and also then apply it to other BitAssets having tried it on just one market at a much lower cost.

Because of BTS volatility, I also think relative orders are very important if that's possible to give people confidence to leave orders on the books.
« Last Edit: December 03, 2015, 09:51:22 am by Empirical1.2 »
If you want to take the island burn the boats

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I am also in favor of #1 simply because BTS is already too complex for many traders .. let's don't make their profit calculations worse

Offline merivercap

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
    • BitCash
I would do #1.  It's common in traditional and bitcoin exchanges.

Bitfinex:
https://www.bitfinex.com/pages/fees
BitCash - http://www.bitcash.org 
Beta: bitCash Wallet / p2p Gateway: (https://m.bitcash.org)
Beta: bitCash Trade (https://trade.bitcash.org)

Offline theredpill

#1 Yes let's do it ASAP

#2 Not sure because of complexity, risk of gamming

Offline Chronos

I think we should support percentage based trade fee and split it to maker% and taker% which can be set by committee. maker%+taker% >= 0. You can set maker% = -0.05% and taker% = 0.1%. This way maker can share fee with the network.
This is a simpler way to do the same thing.

  • NEGATIVE_MAKER_FEE = cash in the pocket of makers
  • MAKER_SHARES = more complexity and rules to accomplish the same result

I also think that liquidity would be helped by allowing orders to be placed relative to the price feed.

EDIT: Just to be clear, I'm saying that MAKER_SHARES aren't needed because a negative maker fee solves the same problem much more simply.
« Last Edit: December 03, 2015, 05:48:11 am by Chronos »

Offline tbone

  • Hero Member
  • *****
  • Posts: 632
    • View Profile
  • BitShares: tbone2
1. Place orders that sit on the books for at least X minutes if they get filled instantly (less than X min) we will assume you are trading against yourself to "MINE" "MAKER_SHARES".

Then the optimal strategy is to wait X+n minutes and then trade with yourself?

Yes, but during those X minutes the price can move and someone else can take you up on your order.  It may not even be relevant because trading with yourself has costs and you are not guaranteed to match yourself.

I think both proposals have merits.  I like proposal #1 because it can't be gamed and makers will still be rewarded when someone takes their bid or offer within X minutes.  I would combine it with %-based fees (which we need anyway) so makers get rewarded based on share volume, not trade volume.  The only drawback is that the incentives are limited to the fees paid by the taker and we may want to offer larger incentives at the start.  In which case we'd have to look at proposal #2 or something else if we can't set the taker fee high enough to reward makers as much as necessary in the critical early stages.

Offline btstip

  • Hero Member
  • *****
  • Posts: 644
    • View Profile
  • BitShares: btstip-io
Hey fuzzy, here are the results of your tips...
Curious about BtsTip? Visit us at http://sharebits.io and start tipping BTS on https://bitsharestalk.org/ today!
Created by hybridd

Offline fuzzy

Great idea... and if we ever come to have easy-to-use market maker bots built into the wallet, this could allow massive crowd-sourced liquidity.

BAM!
#sharebits "roadscape" 2 HIGHFIVE

You get two for that one...
WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
As I said, I am not overly exited for this but what is the price tag on this, anyway?

Also some more clarity on what exact fees will be used for this buyback, will be appreciated. One example for a bitAsset and one for UIA should take only several minutes to write but will help a lot, I think. Thanks.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline botfund

  • Full Member
  • ***
  • Posts: 174
    • View Profile
  • BitShares: botfund
I think we should support percentage based trade fee and split it to maker% and taker% which can be set by committee. maker%+taker% >= 0. You can set maker% = -0.05% and taker% = 0.1%. This way maker can share fee with the network.


Offline roadscape

Great idea... and if we ever come to have easy-to-use market maker bots built into the wallet, this could allow massive crowd-sourced liquidity.
http://cryptofresh.com  |  witness: roadscape

Offline bytemaster

1. Place orders that sit on the books for at least X minutes if they get filled instantly (less than X min) we will assume you are trading against yourself to "MINE" "MAKER_SHARES".

Then the optimal strategy is to wait X+n minutes and then trade with yourself?

Yes, but during those X minutes the price can move and someone else can take you up on your order.  It may not even be relevant because trading with yourself has costs and you are not guaranteed to match yourself.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
1. Place orders that sit on the books for at least X minutes if they get filled instantly (less than X min) we will assume you are trading against yourself to "MINE" "MAKER_SHARES".

Then the optimal strategy is to wait X+n minutes and then trade with yourself?
Correct. :P
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline monsterer

1. Place orders that sit on the books for at least X minutes if they get filled instantly (less than X min) we will assume you are trading against yourself to "MINE" "MAKER_SHARES".

Then the optimal strategy is to wait X+n minutes and then trade with yourself?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
Brilliant idea worth considering.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
I see now. So did the fake volume bot on OL led to any increases to the real volume?

A good , and already tested, tool to have for the upcoming MAKER_SHARES anyway, but just curious.

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

Offline bytemaster

I have two basic proposals for incentivising liquidity:

Proposal 1: Maker / Taker

Add an asset flag that allows issuers to only charge fees to the Taker (the new order being placed) and not the Maker (the open order on the books).  Currently both sides are charged.  The Taker is the one that pays for liquidity.

Proposal 2:  Share Market fees with Maker

The default model is to just give the Maker what the Taker paid, but this model does not generate any leverage. At most it gives the Maker an incentive proportional to the market fee. We would like to amplify the incentive for Market Makers early on when the risk is the highest by reallocating future revenue to current Makers.   Under this model, there would be huge incentive to be a Maker on day 1 and no incentive to be a maker on day 1000 (other than not paying the market fee).

In effect, the long-term success of a market depends upon it getting bootstrapped and we should give the "makers" a share of the long-term success proportional to their contribution to liquidity.

Every time a Maker's open order is matched, they receive MAKER_SHARES equal to SIZE_OF_ORDER * RATE  where RATE starts out at 1 and decays to 0 with a half life of 1 year.  The supply of MAKER_SHARES will grow proportional to volume until the RATE hits 0 after (4 years).
MAKER_SHARES will only be awarded for orders that sit on the books for at least X minutes (to prevent trading against yourself).

MAKER_SHARES will automatically be purchased back from the market with the market fees earned on the asset.  MAKER_SHARES will thus represent a stake in the future success of an individual market and they can only be earned by providing visible liquidity.

To maximize the number of MAKER_SHARES you earn you want to do the following:

1. Place orders that sit on the books for at least X minutes if they get filled instantly (less than X min) we will assume you are trading against yourself to "MINE" "MAKER_SHARES".
2. Buy back and resell as often as possible.

Whoever performs this service ends up "owning" a large share of the BitAsset market and they deserve it. BitShares benefits because it is earning fees from every trade in the system just like it always did.

Failure to pay for liquidity early on is like a company that wants to grow without hiring developers or marketers. We must provide profit motives for the services we want to see.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.