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".
Correct. :P1. 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?
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?
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.
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 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.
I really like this to be implemented and negative maker fee to improve the liquidity. I saw it worked especially near the fill price.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 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
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.
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.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.
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 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.
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://www.investopedia.com/articles/active-trading/042414/what-makertaker-fees-mean-you.asp (http://www.investopedia.com/articles/active-trading/042414/what-makertaker-fees-mean-you.asp)QuoteThe 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.
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.
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.
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.
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 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 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.
Really? Do you have a list?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?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.
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.
Now it is time for take the ass off the chair and make the world we wish to see.(http://ct.fra.bz/ol/fz/sw/i53/5/6/8/frabz-Ok-bitches-Lets-kick-some-asses-0294e3.jpg)
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.