Author Topic: Incentivising Liquidity  (Read 3350 times)

0 Members and 1 Guest are viewing this topic.

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: clayop
Re: Incentivising Liquidity
« Reply #30 on: December 04, 2015, 01:12:48 am »
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

Re: Incentivising Liquidity
« Reply #31 on: December 04, 2015, 01:19:25 am »
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 Helikopterben

  • Sr. Member
  • ****
  • Posts: 202
    • View Profile
Re: Incentivising Liquidity
« Reply #32 on: December 04, 2015, 01:22:24 am »
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 clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: clayop
Re: Incentivising Liquidity
« Reply #33 on: December 04, 2015, 01:48:20 am »
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 maqifrnswa

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
Re: Incentivising Liquidity
« Reply #34 on: December 04, 2015, 01:56:55 am »
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 theredpill

Re: Incentivising Liquidity
« Reply #35 on: December 04, 2015, 02:05:29 am »
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 tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
Re: Incentivising Liquidity
« Reply #36 on: December 04, 2015, 02:09:13 am »
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

Re: Incentivising Liquidity
« Reply #37 on: December 04, 2015, 02:20:01 am »
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 maqifrnswa

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
Re: Incentivising Liquidity
« Reply #38 on: December 04, 2015, 02:39:10 am »
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 rgcrypto

  • Hero Member
  • *****
  • Posts: 557
    • View Profile
    • Cryptoctopus Blog
Re: Incentivising Liquidity
« Reply #39 on: December 04, 2015, 02:39:52 am »
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 btstip

  • Hero Member
  • *****
  • Posts: 644
    • View Profile
  • BitShares: btstip-io
Re: Incentivising Liquidity
« Reply #40 on: December 04, 2015, 02:41:09 am »
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 theredpill

Re: Incentivising Liquidity
« Reply #41 on: December 04, 2015, 02:49:46 am »
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 »