[ANN] RMBTB.com: New China Bitcoin exchange

[BitPirate]

The giveaway is now over, as expected we had quite a lot of takers....

We're looking to build market depth. The prevailing bitcoin price in China is quite significantly lower than Mt Gox at the moment, but there is also a nice gap between the China exchanges.

If there are any potential market makers interested in exploiting the gap, please PM me -- we can cut a good deal and I can help you get money in.

[monsterer]

The giveaway is now over, as expected we had quite a lot of takers....

We're looking to build market depth. The prevailing bitcoin price in China is quite significantly lower than Mt Gox at the moment, but there is also a nice gap between the China exchanges.

If there are any potential market makers interested in exploiting the gap, please PM me -- we can cut a good deal and I can help you get money in.

Here's an idea if you want to increase liquidity - make your fees lower for limit orders than they are for market orders?

[TimJBenham]

Here's an idea if you want to increase liquidity - make your fees lower for limit orders than they are for market orders?

The relevant distinction is between orders that provide liquidity and those that take it. Your idea would just cause all market orders to be entered as limit orders with an extreme limit.

[BitPirate]

It's a nice idea though but would need to be applied in a different way (there's no way to distinguish between order types until they are executed anyway, which happens asynchronously).

I was toying with the idea of introducing new order types, such as "volatility reducing" orders that automatically lead/trail the last price by around 10% (and get re-placed every 20 minutes or so, so they would catch sudden dips/spikes).

It would take some time to implement and test, but it was on my to-do list anyway. They could carry lower fees.

Anyway, the offer is still open for arbitrageurs in the meantime :-)

[TimJBenham]

It's a nice idea though but would need to be applied in a different way (there's no way to distinguish between order types until they are executed anyway, which happens asynchronously).

Orders that execute against the order book take liquidity; orders that enter the order book add liquidity. That implies that you charge the fee when the order executes.

[BitPirate]

It's a nice idea though but would need to be applied in a different way (there's no way to distinguish between order types until they are executed anyway, which happens asynchronously).

Orders that execute against the order book take liquidity; orders that enter the order book add liquidity. That implies that you charge the fee when the order executes.

yes, the fee is charged at execution time; but don't users expect to be informed of the fee rate at order time? Perhaps "the fee is 0.3% but could be cheaper" isn't so bad...?

[monsterer]

The relevant distinction is between orders that provide liquidity and those that take it. Your idea would just cause all market orders to be entered as limit orders with an extreme limit.

Simply impose a restriction that limit orders cannot be placed between Bid or Ask. Or you can have a restriction that says you give a rebate for all limit order which sit in the book for 'long enough'.

[monsterer]

I was toying with the idea of introducing new order types, such as "volatility reducing" orders that automatically lead/trail the last price by around 10% (and get re-placed every 20 minutes or so, so they would catch sudden dips/spikes).

You don't need to do that - if there is a big enough incentive for market-markers, the volatility (and spread) will be automatically reduced by their actions. You can achieve this either through rebate on limit orders, or by changing your fee model so the round-trip trade cost is less.

[TimJBenham]

The relevant distinction is between orders that provide liquidity and those that take it. Your idea would just cause all market orders to be entered as limit orders with an extreme limit.

Simply impose a restriction that limit orders cannot be placed between Bid or Ask.

That would forbid reducing the spread. I think that's the opposite of what you want.

[TimJBenham]

It's a nice idea though but would need to be applied in a different way (there's no way to distinguish between order types until they are executed anyway, which happens asynchronously).

Orders that execute against the order book take liquidity; orders that enter the order book add liquidity. That implies that you charge the fee when the order executes.

yes, the fee is charged at execution time; but don't users expect to be informed of the fee rate at order time? Perhaps "the fee is 0.3% but could be cheaper" isn't so bad...?

Exactly. No-one complains if the fee is unexpectedly lower. If you really want to encourage people to leave orders up you give a negative fee by rebating the market maker some of the liquidity taker's fee. This would severely cut your initial fee income, but an exchange that does this would soon have the smallest spreads and become the "go to" place for traders. Or you can provide this benefit to only a few market makers with whom you have deals.

There is always some compromise between making money in the short term and growing the exchange.

BTW your username is kind of unfortunate if you want to be trusted.

[monsterer]

That would forbid reducing the spread. I think that's the opposite of what you want.

Yes, there is an edge case with partial fills which would leave a limit order between Bid->Ask. Scratch that idea.

Still though, giving a rebate for limit orders which sit on the book for long enough ought to encourage liquidity.

[BIT4BRAIN]

HOWS THIS COMPARE TO BTCCHINA.COM  ANYONE?

[BitPirate]

Hoping some others will chime in... if you want others' opinions, you can ignore me.

Obviously, I think we're better ;-) Our top priority is security and ease of use (I think some of the other exchanges in China are not secure). Our volume and depth is still low. We're working on that.

We've launched a few new features recently. For example, a notifications centre; you can receive emails or SMS when key actions take place on your account (e.g. get informed when someone logs in, or when a trade goes through).

We're also about to launch a full trading API, which should be mostly compatible with Mt. Gox, but with better security than other competitor trade APIs:
- API secrets are IP locked and automatically rotated every 2 hours (mitigates risk of storing symmetric secrets in the database)
- you can specify access and trade limits for each API key you create
- you can specify IP whitelists for each API key you create

We're offering a split fee -- trades via the API will be 50% off.

Documentation etc. coming soon.

[ABitBack]

I think you need to edit the title and thread if the giveaway is over now. Just strikethrough it, but mention the 2BTC treasure hunt instead. Looking good by the way. An affiliate program going to be integrated at all?

[joesmoe2012]

Everything on your site is looking good too, can't wait to start making some money.

[BitPirate]

I think you need to edit the title and thread if the giveaway is over now. Just strikethrough it, but mention the 2BTC treasure hunt instead. Looking good by the way. An affiliate program going to be integrated at all?

Thanks! Will do. We've got treasure hunt posts in the Chinese forum.. didn't post them here as some of the clues required Chinese.


A referral progam is on the todo list -- a few other things to clean up first.

The main issue we've had with giveaways is how to differentiate real accounts from dead ones -- so in the previous giveaway, we set deposit requirements. People didn't seem so keen on that though. Perhaps something based on volume commission would work better.

[BitPirate]

Everything on your site is looking good too, can't wait to start making some money.

Thanks :-) Doing the last unit tests and translating the documentation -- should be ready soon!

[BitPirate]

A few new changes.

The Secure API is up and running... Lots of details here: https://www.rmbtb.com/help-secureapi-en/

And we have a new ticker:



More changes in the works too...

[joesmoe2012]

How long do SWIFT transfers to Poland take?

Do you support SEPA transfers?

[BitPirate]

How long do SWIFT transfers to Poland take?

Do you support SEPA transfers?

Hi! They are international wire transfers... but the fee is minimal. Depending on the size, it takes approx. a week. Right now the web front-end only supports Chinese online payment methods, for compliance purposes, but we can provide the relevant info by e-mail.