Search content
Sort by
Showing 20 of 34 results by tbosman
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
Currency pairs have the form XBT/EUR (500 EUR/XBT), LTC/EUR (14 EUR/LTC) and XBT/LTC (40 LTC/XBT).
Is there any option to flip the order on XBT/LTC?
Such that it's possible to show a) LTC/XBT (in sub-menu LTC?) and b) XBT/LTC (in sub-menu XBT?).
Cheers.
I would also like to see this option. The reason is almost every other site I have seen and traded on shows XBT/LTC the other way ie. - LTC/XBTIs there any option to flip the order on XBT/LTC?
Such that it's possible to show a) LTC/XBT (in sub-menu LTC?) and b) XBT/LTC (in sub-menu XBT?).
Cheers.
I'm much more accustomed to seeing it this way. I would like to see this option too thanks.
Peace.
XBT/USD notation in the scientific world would mean: XBT per USD. So a notation of USD/XBT would say x USD per Bitcoin.
That the forex world uses XBT/USD as "x Bitcoin in USD" confused me a lot in the beginning.
LTC/BTC flip was already asked here and discussed around 20-30 pages ago, as per information from there, such flip will not happened. The best solution is to handle flip on your side where you need it, it is not so difficult.
Thanks
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
no update about the order book bug yet?
We think we've fixed all the issues people were seeing, and all those fixes are now live. So please let us know if you see anything that still doesn't look right.
There were a variety of cases, but all of them were caused by a bid > ask condition. For example, suppose the book contains these orders:
sell 1 lot @ 130
buy 0.5 lot @ 127
buy 0.5 lot @ 120
sell 0.5 lot @ trailing stop 126, limit 100
buy 1 lot @ 110
So current ask is 130 and bid is 127.
A new order is placed to
The 120 bid triggers the trailing stop @ 126 and puts in a limit sell order at 100. Now the bid is 120 and ask is 100 (bid > ask condition). If the ask side initiates the trade, the trade will be done at $120. If the bid side initiates the trade, the trade will be done at $100 (which appears to have skipped over the buy @ 110).
So those of you who thought you were being skipped over, you weren't. It's just that someone with a higher bid in the book got filled at a price below your offer. Of course, the converse could happen too, where someone on the ask side might appear to have been skipped over when in fact someone with a lower ask just got filled at a higher price.
In one sense, this isn't really a bug, because whichever side initiates is supposed to get the best offer on the book from their perspective. So if the buy side initiates, they should get the lowest ask on the book - i.e. $100 in the case above. It's just that when bid > ask, this normally sound principle leads to unexpected price action that doesn't look right. And we'd probably be answering support tickets and questions on social media forever if it wasn't fixed. In the scenario above, the fix is that the trade will execute at $120 regardless of which side initiates the trade. That seemed the best solution, and will avoid the strange price action, but it also means that the side initiating the trade under this bid > ask condition isn't always going to get the best offer on the book (as they normally would when ask > bid).
This is how it works now, but not before. Before the timestamp on an order was just the time of order entry, and this timestamp carried over to orders that triggered from advanced orders. Now the timestamp is determined by the time the order is created, so an order that triggers from an advanced order is given a new timestamp. Apparently in the original design of the trade engine, triggered orders got a new timestamp, but at some point this was changed to the timestamp just being the time of order entry because that was simpler and it was thought that it wouldn't be a problem.
Suppose the orders in the example are placed in the following sequence:
sell 1 lot @ 130
sell 0.5 lot @ trailing stop 126, limit 100
buy 0.5 lot @ 120
buy 0.5 lot @ 127
buy 1 lot @ 110
sell 1 lot at 125
As you say, the newest order initiates, but before this meant that the buy order @ 120 would initiate because it was considered newest and this would result in a fill at 100. Apparently there was also an issue with sorting that sometimes caused the older order to initiate (resulting in a fill at 120), but this has been fixed as well.
With both of the fixes, the newest order always initiates and the age of an order is determined by when it is created (so an order that triggers from another gets a new timestamp). In the example, this means that the triggered sell @ 100 will always initiates and the fill will be at 120.
I'm not sure when we'll have the time to do this, but at some point we'd like to write up a document explaining all the rules of the trade engine so the technical details of how trade matching works exactly are available. Some exchanges have done this for basic order types, but I'm not sure any exchange has ever done it to include the advanced orders (but let me know if you know of one).
I do have a few questions about the matching if you can answer them yourself, if not i can wait for the document.
- How is the price protection calculated for market orders?
- Is order matching atomic? I.e. if a orders crosses the market, will it match orders as far as possible before anything else happens, or is it possible for incoming/triggered orders to be added as the order 'walks' the book.
- I understand that any triggered order will be handled as a new limit/market order with a fresh timestamp. So this means that if multiple orders are triggered by the same trade/order being executed, they will arrive with the stame timestamp right? How is execution priority handled in that case?
This explains the priority for the stop/loss and stop-limit order types on NYSE Euronext. Is this comparable to how it works at kraken?
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
no update about the order book bug yet?
We think we've fixed all the issues people were seeing, and all those fixes are now live. So please let us know if you see anything that still doesn't look right.
There were a variety of cases, but all of them were caused by a bid > ask condition. For example, suppose the book contains these orders:
sell 1 lot @ 130
buy 0.5 lot @ 127
buy 0.5 lot @ 120
sell 0.5 lot @ trailing stop 126, limit 100
buy 1 lot @ 110
So current ask is 130 and bid is 127.
A new order is placed to
The 120 bid triggers the trailing stop @ 126 and puts in a limit sell order at 100. Now the bid is 120 and ask is 100 (bid > ask condition). If the ask side initiates the trade, the trade will be done at $120. If the bid side initiates the trade, the trade will be done at $100 (which appears to have skipped over the buy @ 110).
So those of you who thought you were being skipped over, you weren't. It's just that someone with a higher bid in the book got filled at a price below your offer. Of course, the converse could happen too, where someone on the ask side might appear to have been skipped over when in fact someone with a lower ask just got filled at a higher price.
In one sense, this isn't really a bug, because whichever side initiates is supposed to get the best offer on the book from their perspective. So if the buy side initiates, they should get the lowest ask on the book - i.e. $100 in the case above. It's just that when bid > ask, this normally sound principle leads to unexpected price action that doesn't look right. And we'd probably be answering support tickets and questions on social media forever if it wasn't fixed. In the scenario above, the fix is that the trade will execute at $120 regardless of which side initiates the trade. That seemed the best solution, and will avoid the strange price action, but it also means that the side initiating the trade under this bid > ask condition isn't always going to get the best offer on the book (as they normally would when ask > bid).
This is how it works now, but not before. Before the timestamp on an order was just the time of order entry, and this timestamp carried over to orders that triggered from advanced orders. Now the timestamp is determined by the time the order is created, so an order that triggers from an advanced order is given a new timestamp. Apparently in the original design of the trade engine, triggered orders got a new timestamp, but at some point this was changed to the timestamp just being the time of order entry because that was simpler and it was thought that it wouldn't be a problem.
Suppose the orders in the example are placed in the following sequence:
sell 1 lot @ 130
sell 0.5 lot @ trailing stop 126, limit 100
buy 0.5 lot @ 120
buy 0.5 lot @ 127
buy 1 lot @ 110
sell 1 lot at 125
As you say, the newest order initiates, but before this meant that the buy order @ 120 would initiate because it was considered newest and this would result in a fill at 100. Apparently there was also an issue with sorting that sometimes caused the older order to initiate (resulting in a fill at 120), but this has been fixed as well.
With both of the fixes, the newest order always initiates and the age of an order is determined by when it is created (so an order that triggers from another gets a new timestamp). In the example, this means that the triggered sell @ 100 will always initiates and the fill will be at 120.
I'm not sure when we'll have the time to do this, but at some point we'd like to write up a document explaining all the rules of the trade engine so the technical details of how trade matching works exactly are available. Some exchanges have done this for basic order types, but I'm not sure any exchange has ever done it to include the advanced orders (but let me know if you know of one).
I do have a few questions about the matching if you can answer them yourself, if not i can wait for the document.
- How is the price protection calculated for market orders?
- Is order matching atomic? I.e. if a orders crosses the market, will it match orders as far as possible before anything else happens, or is it possible for incoming/triggered orders to be added as the order 'walks' the book.
- I understand that any triggered order will be handled as a new limit/market order with a fresh timestamp. So this means that if multiple orders are triggered by the same trade/order being executed, they will arrive with the stame timestamp right? How is execution priority handled in that case?
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
no update about the order book bug yet?
We think we've fixed all the issues people were seeing, and all those fixes are now live. So please let us know if you see anything that still doesn't look right.
There were a variety of cases, but all of them were caused by a bid > ask condition. For example, suppose the book contains these orders:
sell 1 lot @ 130
buy 0.5 lot @ 127
buy 0.5 lot @ 120
sell 0.5 lot @ trailing stop 126, limit 100
buy 1 lot @ 110
So current ask is 130 and bid is 127.
A new order is placed to
The 120 bid triggers the trailing stop @ 126 and puts in a limit sell order at 100. Now the bid is 120 and ask is 100 (bid > ask condition). If the ask side initiates the trade, the trade will be done at $120. If the bid side initiates the trade, the trade will be done at $100 (which appears to have skipped over the buy @ 110).
So those of you who thought you were being skipped over, you weren't. It's just that someone with a higher bid in the book got filled at a price below your offer. Of course, the converse could happen too, where someone on the ask side might appear to have been skipped over when in fact someone with a lower ask just got filled at a higher price.
In one sense, this isn't really a bug, because whichever side initiates is supposed to get the best offer on the book from their perspective. So if the buy side initiates, they should get the lowest ask on the book - i.e. $100 in the case above. It's just that when bid > ask, this normally sound principle leads to unexpected price action that doesn't look right. And we'd probably be answering support tickets and questions on social media forever if it wasn't fixed. In the scenario above, the fix is that the trade will execute at $120 regardless of which side initiates the trade. That seemed the best solution, and will avoid the strange price action, but it also means that the side initiating the trade under this bid > ask condition isn't always going to get the best offer on the book (as they normally would when ask > bid).
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
http://i43.tinypic.com/2rrv6f9.jpg
Perhaps I'm wrong but where do you see the 420BTC? Also the last trade is 2h ago.
I know it's a tight border. But doesn't it make sense? If the price drop more than 3% (limit) I speculate that it drops more in future and rebuy BTC then and speculate on a long(er) time raise.
Oh thought you were talking eur. I'm gonna go with Serpens66 on that one, especially if your just speculating on the price, EURUSD conversion is as good as fixed rate compared to Bitcoin. If you have to trade against the spread you're going to get eaten in no time, it's 2% between bid and ask right now. So it would have to fall another 2% before you break even, and then again you may be wrong. 
Perhaps I'm wrong but where do you see the 420BTC? Also the last trade is 2h ago.
I know it's a tight border. But doesn't it make sense? If the price drop more than 3% (limit) I speculate that it drops more in future and rebuy BTC then and speculate on a long(er) time raise.
It's always good to 'backtest' you're strategy against historical prices. They a look at this chart (BTCEUR) : http://bitcoinwisdom.com/markets/kraken/btceur , get a calculator and see what would've happened if you did this a day, a week or a month ago, to get a feel for the profitability of your strategy. In the last month the daily difference between high and low has been more than 3% on 9 separate days, which would've surely triggered your stop. You have to keep in mind that your stop is reset any time the best bid reaches a new high, and triggered any time the best bid 3% below that. It doesn't matter if it's just for a second and for a size of 0.0001 btc.
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
Perhaps a stupid question, but do you think the market at Kraken is large enough to go with a trailing stop limit of 4%/3% and a volume of 2.3? Or do you think when the limit is hit, there isn't enough need on the market to fullfill such a "large" order (24h volume was about 26 BTC)?
Where did you see that number, at the moment it's about 430 btc. And if you do a limit it doesn't matter because the order stays there until it's filled. That being said, 4% seems a little low to me. A 4% swing is a sneeze in bitcoinland. Might as well just put that order in now as it's going to be hit within 2 days anyway but probably at a worse price.
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
Still don't really get it, there's no limit parameter, so how does that work? Say you request trades since between 12:00 and 13:00 with offset 0, and you get 100 trades. What would you get than if you do the same with offset 10? The last 90 trades between 12:00 and 13:00 plus the first 10 after that?
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
Anybody know what this input in the api is for: ofs = result offset ?
It's a parameter in the methods for closed orders and recent trades, but i don't really understand what it means.
It's a parameter in the methods for closed orders and recent trades, but i don't really understand what it means.
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
The problem is not Kraken but the fact there is not much people trading BTC in EUR.
Actually, if we only consider BTC/EUR, Kraken will soon be the first exchange!
Last 24h
Mt.Gox BTC/EUR 675.000000 EUR 318.1867 BTC
Kraken BTC/EUR 607.990000 EUR 316.6295 BTC
BTC-e BTC/EUR 613.498000 EUR 170.6412 BTC
Best prices too!
Actually, if we only consider BTC/EUR, Kraken will soon be the first exchange!
Last 24h
Mt.Gox BTC/EUR 675.000000 EUR 318.1867 BTC
Kraken BTC/EUR 607.990000 EUR 316.6295 BTC
BTC-e BTC/EUR 613.498000 EUR 170.6412 BTC
Best prices too!
Just expanding on this a bit.... (bitcoinaverage.com):
Code:
mtgox 39.83% 847.05 690.0 EUR
bitcoin_de 21.19% 450.60 611.8 EUR
bitonic 12.41% 263.92 602.6 EUR
kraken 11.06% 235.31 610.0 EUR
btce 05.81% 123.49 617.0 EUR
localbitcoins 04.83% 102.69 626.0 EUR
bitcoin_de 21.19% 450.60 611.8 EUR
bitonic 12.41% 263.92 602.6 EUR
kraken 11.06% 235.31 610.0 EUR
btce 05.81% 123.49 617.0 EUR
localbitcoins 04.83% 102.69 626.0 EUR
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
This is not related to recent issues reported here by several users, but it will be amazing if kraken trading platform has "stop loss orders" triggered off of market price rather than executed price.
This would be even more beneficial at the current low volume (at least in XTC terms).
See help>>trading guideThis would be even more beneficial at the current low volume (at least in XTC terms).
Stop Loss: Triggers a market order (buy or sell) when market price hits the stop price.
[...]
Market Price: "Market price" for an order means the lowest current ask price (for buy orders), or the highest current bid price (for sell orders). This is important for understanding how stop or take profit orders trigger. A stop loss sell order, for example, will trigger when stop price is less than or equal to market price (the highest current bid price).
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
Okay i've found some trades you can look at that show the problem.
Trade OWJLMF-AADOB-WDCSH5 and two others around that time, around 17:15:39 GMT+1, buying XBTEUR got filled at 613.73000, yet there has been an ask wall at 612 the entire day (i checked the logs, it was there when the trade got executed). The ask is still there now, 35 minutes later.
XBTEUR buy at market order, trade TNGIYO-HKZD5-LUNGHS, got filled at 612, showed up in recent trade data as a buy. Trade TY3SUL-MWL5L-PXIQNH, order was a limit at 612, filled immediately, but showed up in recent trade data as a sell. (Should be a buy as there was an ask at 612 already).
Trade OWJLMF-AADOB-WDCSH5 and two others around that time, around 17:15:39 GMT+1, buying XBTEUR got filled at 613.73000, yet there has been an ask wall at 612 the entire day (i checked the logs, it was there when the trade got executed). The ask is still there now, 35 minutes later.
XBTEUR buy at market order, trade TNGIYO-HKZD5-LUNGHS, got filled at 612, showed up in recent trade data as a buy. Trade TY3SUL-MWL5L-PXIQNH, order was a limit at 612, filled immediately, but showed up in recent trade data as a sell. (Should be a buy as there was an ask at 612 already).
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
I am pretty sure that is not a polling issue on the webpage, as the api must be giving off weird data too. I do think the orderbook given off by the api is incorrect, unfortunately i only log the best bid/ask in which i couldn't find an error. I do know from the behaviour of my bot a short time interval where the orderbook probably was mangled.
edit: removed some details about my algo.
I hope this helps.
edit: removed some details about my algo.
I hope this helps.
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
The market data page shows the book was crossed on two separate occasions last night. http://i40.tinypic.com/1zgfck8.png
I have a hunch that the it's just the reading of the orderbook part thats broken, not the engine itself. There was a similar situation a while ago.
I have a hunch that the it's just the reading of the orderbook part thats broken, not the engine itself. There was a similar situation a while ago.
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
Any luck asking for higher limits? I've "pitched" my algo because they were reluctant to up the limits on account of my balance being small, but i'm still waiting on the response. I'm would like to now what kind of a rates i should think of for a volume of around 10-20K usd per day.
Related to this, i understand kraken values its trading engine resources highly. I really think you should krank down the decimals allowed for prices. 5 decimals
at 600 eur per btc is insignificantly low compared to transaction cost and spread, especially with these kinds of volumes. I sometimes see bots trying to outbid eachother for 0.00001 price differences, which does almost nothing for the spread nor trading volume but takes up just as much resources nonetheless. Incidentally it also makes it much easier to see what average price at size is going to be when looking at the orderbook.
I'd say 2 decimals is more then enough, which is relatively still higher then the ticksize in fiat forex, where volume is much higher, volatility lower and transaction cost much smaller. Also bitstamp does it succesfully being one of the biggest players.
Anyone wants to weigh in on this?
edit: Another thing about the api, it seems to me that calls for account balance/trade history/open orders is much less intensive to your system, as this is just a read operation. Maybe it's an idea to have a separate limit for these calls, or let them count towards your limit fractionally or something. To me higher limits are mainly necessary to know faster whether my orders are filled yet this takes away from the amount of orders i can do right now.
tbosman - support did reply to your ticket. Did you not get the response?
I'll run the idea of fewer decimal places by the devs and see what they say. If we made such a change we would of course announce it first.
I got a response to the initial ticket requesting more info about my trading, which i responded to on january 9 (two emails), but haven't heard back since. Not in the spam folder either.
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
(continuing this from the beta-thread that was necro'ed)
Hi - It's not a big deal, but you've necroed our beta thread. We have a post-launch thread now and that's the best place to post stuff (it's in this same subforum).
I agree that if you're trying to operate as a liquidity provider or market maker, the standard limits aren't nearly enough. But we do offer higher limits for people who will be acting as liquidity providers. Just create a support ticket about it and PM me with the ticket number.
The standard rate limit should allow for 1 call every 5 seconds, so I'm not sure why you're having trouble with 1 call every 6 seconds.
Any chance of better rate limits for regular users as well? One call every 5 seconds is rather low. Right now, volume is low enough that this likely isn't a big issue, but bots can help to push volume and liquidity (even bots not operated for the purpose of market making) and being able to have more rapidly updating data is quite useful for bots.
Alternatively, and probably even better, a websocket/streaming API that provides continuous updates (like what MtGox is using or the "hidden" Bitstamp websocket) would be nice.
Any plans to upgrade this public part of the API?
Any luck asking for higher limits? I've "pitched" my algo because they were reluctant to up the limits on account of my balance being small, but i'm still waiting on the response. I'm would like to now what kind of a rates i should think of for a volume of around 10-20K usd per day. I was trying to develop a liquidity provider algo to this exchange but it's impossible to work with current rate limits.
I'm receiving the error rate limit exceeded even if i post one request every 6 seconds.
That limit is ridiculously low for developing trading bots.
Hope you will find a way to allow at least 1 order or request per second in the future, this is a very serious issue for an exchange that wants to attract liquidity and be competitive.
Can you please write of these limits in the API page?
It sucks to lose 3 working days to code something big and then realizing it can't work because of this ridiculous low rate limit!
I'm receiving the error rate limit exceeded even if i post one request every 6 seconds.
That limit is ridiculously low for developing trading bots.
Hope you will find a way to allow at least 1 order or request per second in the future, this is a very serious issue for an exchange that wants to attract liquidity and be competitive.
Can you please write of these limits in the API page?
It sucks to lose 3 working days to code something big and then realizing it can't work because of this ridiculous low rate limit!
Hi - It's not a big deal, but you've necroed our beta thread. We have a post-launch thread now and that's the best place to post stuff (it's in this same subforum).
I agree that if you're trying to operate as a liquidity provider or market maker, the standard limits aren't nearly enough. But we do offer higher limits for people who will be acting as liquidity providers. Just create a support ticket about it and PM me with the ticket number.
The standard rate limit should allow for 1 call every 5 seconds, so I'm not sure why you're having trouble with 1 call every 6 seconds.
Any chance of better rate limits for regular users as well? One call every 5 seconds is rather low. Right now, volume is low enough that this likely isn't a big issue, but bots can help to push volume and liquidity (even bots not operated for the purpose of market making) and being able to have more rapidly updating data is quite useful for bots.
Alternatively, and probably even better, a websocket/streaming API that provides continuous updates (like what MtGox is using or the "hidden" Bitstamp websocket) would be nice.
Any plans to upgrade this public part of the API?
Related to this, i understand kraken values its trading engine resources highly. I really think you should krank down the decimals allowed for prices. 5 decimals
at 600 eur per btc is insignificantly low compared to transaction cost and spread, especially with these kinds of volumes. I sometimes see bots trying to outbid eachother for 0.00001 price differences, which does almost nothing for the spread nor trading volume but takes up just as much resources nonetheless. Incidentally it also makes it much easier to see what average price at size is going to be when looking at the orderbook.
I'd say 2 decimals is more then enough, which is relatively still higher then the ticksize in fiat forex, where volume is much higher, volatility lower and transaction cost much smaller. Also bitstamp does it succesfully being one of the biggest players.
Anyone wants to weigh in on this?
edit: Another thing about the api, it seems to me that calls for account balance/trade history/open orders is much less intensive to your system, as this is just a read operation. Maybe it's an idea to have a separate limit for these calls, or let them count towards your limit fractionally or something. To me higher limits are mainly necessary to know faster whether my orders are filled yet this takes away from the amount of orders i can do right now.
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
Minor issue. My last two trades for XBT/XRP @ buy/market show 'Canceled' (in red) when they have actually gone through immediately and without issue. It's just a visual thing... It should read 'Closed' (in green).
What does the executed volume say? Did you perhaps do an order for you entire balance? I get this when the fees for the order cause your balance to become zero when executing the order. So say you have 1btc in your account and do a 1 btc market sell order with fees deducted from the btc balance. Then the order will have status cancelled and volume executed 0.999.. or something. Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
Does anyone have a problem with displaying a upper graph?
Sometime it shop up but mostly I have to refresh page several times before it show up correctly. I tray several browser and computers and I have the similar problem..
Sometime it shop up but mostly I have to refresh page several times before it show up correctly. I tray several browser and computers and I have the similar problem..
Do you mean the upper graphs on the market data page? So far as I know, nobody else has reported this, but if other's are having trouble we'd like to know.
@CybeRoky: Do you mean the right table with the last trades on market data?
However it's about a 30% chance to see "No trades currently available" there. Then I have to refresh, till I see the trades. In about ~5% cases I also can't see the Orderbook.
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
(continuing this from the beta-thread that was necro'ed)
Hi - It's not a big deal, but you've necroed our beta thread. We have a post-launch thread now and that's the best place to post stuff (it's in this same subforum).
I agree that if you're trying to operate as a liquidity provider or market maker, the standard limits aren't nearly enough. But we do offer higher limits for people who will be acting as liquidity providers. Just create a support ticket about it and PM me with the ticket number.
The standard rate limit should allow for 1 call every 5 seconds, so I'm not sure why you're having trouble with 1 call every 6 seconds.
Any chance of better rate limits for regular users as well? One call every 5 seconds is rather low. Right now, volume is low enough that this likely isn't a big issue, but bots can help to push volume and liquidity (even bots not operated for the purpose of market making) and being able to have more rapidly updating data is quite useful for bots.
Alternatively, and probably even better, a websocket/streaming API that provides continuous updates (like what MtGox is using or the "hidden" Bitstamp websocket) would be nice.
Any plans to upgrade this public part of the API?
I was trying to develop a liquidity provider algo to this exchange but it's impossible to work with current rate limits.
I'm receiving the error rate limit exceeded even if i post one request every 6 seconds.
That limit is ridiculously low for developing trading bots.
Hope you will find a way to allow at least 1 order or request per second in the future, this is a very serious issue for an exchange that wants to attract liquidity and be competitive.
Can you please write of these limits in the API page?
It sucks to lose 3 working days to code something big and then realizing it can't work because of this ridiculous low rate limit!
I'm receiving the error rate limit exceeded even if i post one request every 6 seconds.
That limit is ridiculously low for developing trading bots.
Hope you will find a way to allow at least 1 order or request per second in the future, this is a very serious issue for an exchange that wants to attract liquidity and be competitive.
Can you please write of these limits in the API page?
It sucks to lose 3 working days to code something big and then realizing it can't work because of this ridiculous low rate limit!
Hi - It's not a big deal, but you've necroed our beta thread. We have a post-launch thread now and that's the best place to post stuff (it's in this same subforum).
I agree that if you're trying to operate as a liquidity provider or market maker, the standard limits aren't nearly enough. But we do offer higher limits for people who will be acting as liquidity providers. Just create a support ticket about it and PM me with the ticket number.
The standard rate limit should allow for 1 call every 5 seconds, so I'm not sure why you're having trouble with 1 call every 6 seconds.
Any chance of better rate limits for regular users as well? One call every 5 seconds is rather low. Right now, volume is low enough that this likely isn't a big issue, but bots can help to push volume and liquidity (even bots not operated for the purpose of market making) and being able to have more rapidly updating data is quite useful for bots.
Alternatively, and probably even better, a websocket/streaming API that provides continuous updates (like what MtGox is using or the "hidden" Bitstamp websocket) would be nice.
Any plans to upgrade this public part of the API?
I'd like to see higher standard rate limits as well. It's an issue I've raised before with the devs, but not in quite a while, so I'll raise it again. We're planning a websocket for streaming data as well, but I think it's realistically going to be at least a few months for that. In the meantime, though, feel free to inquire about the higher rates for market makers as I suggested above.
Just in case my ticket number is #9805
Re: [ANN] KRAKEN.COM - Exchange Now Open with USD, EUR, BTC, LTC, XRP, NMC
What is deposit fee for ripple? I've just deposit 100XRP for test and I get 50XRP to Kraken account. That's almost 1 of fee if I am correct?
https://www.kraken.com/u/funding/deposit?asset=XXRPQuote
Ripple XRP Deposit
Deposit XRP to your account by sending them to the deposit address shown below.
To help avoid mistakes in copying the info to your client, use the available buttons to either launch your client with the deposit info automatically entered, or select the address for copy + paste to your client. Always double-check to make sure the info copied correctly. Please note that we are not responsible for coins mistakenly sent to the wrong place.
Don't exceed your daily or monthly funding limits. If you exceed the limits, your account will be frozen until you get verified for higher limits, or until the funds are returned to you.
Address Setup Fee Ʀ50.00000
Deposit XRP to your account by sending them to the deposit address shown below.
To help avoid mistakes in copying the info to your client, use the available buttons to either launch your client with the deposit info automatically entered, or select the address for copy + paste to your client. Always double-check to make sure the info copied correctly. Please note that we are not responsible for coins mistakenly sent to the wrong place.
Don't exceed your daily or monthly funding limits. If you exceed the limits, your account will be frozen until you get verified for higher limits, or until the funds are returned to you.
Address Setup Fee Ʀ50.00000
https://www.kraken.com/u/funding/deposit?asset=XXRP
404
Page Not Found
The page you requested doesn't exist or was recently moved.
Where I can find all your Address Setup Fee for all cryptocurrency