[ANN] KRAKEN.COM - Exchange with USD EUR GBP JPY CAD BTC LTC XRP NMC XDG STR ETH

[ledmaniak]

The unofficial kraken app(made by a user here on the forums) is big news on a prominent tech website in The Netherlands: http://tweakers.net/nieuws/93916/microsoft-laat-eerste-bitcoin-app-toe-op-windows-phone-platform.html

English: http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Ftweakers.net%2Fnieuws%2F93916%2Fmicrosoft-laat-eerste-bitcoin-app-toe-op-windows-phone-platform.html&act=url


This is the news we can use to get more volume on kraken!

Kraken: When are you planning to release android and iOS apps? I think you will be the first official one..

[1713249230]

1713249230

[1713249230]

1713249230

[1713249230]

1713249230

[1713249230]

1713249230

[1713249230]

1713249230

[1713249230]

1713249230

[Dargo]

Hi,

concerning account & withdrawals.
On the 'WIthdrawal Page' it states

"Important: The name on the bank account you are withdrawing to must match the name on the account you are withdrawing from."

Does the name have to be a 100% match ? or do you check manually , and when it resembles is ok ?
If it has to be a 100% match , is there a way to get it changed ?

When i verified tier 2 , i switched the order first & last name.
And Iused my calling name , instead of my exact name on my passport.
like rob instead of robert

kind regards.

If the order of first and last name are switched, this should be fixed, so create a ticket about it. The difference between "Rob" and "Robert" isn't a problem.

[Dargo]

The site is now completely down

Doesn't Kraken have any emergency crew on call or at least some PR person that lives outside of the Pacific timezone for these type of things?

It's an interesting detail indeed that they are based on completely different timezone than where most customers are located and seem not to have anyone available in other timezones...

No response to this from Dargo?... It is certainly frustrating. Being that I am in the Middle East and exactly 12 hours different...

Yep it's awkward that the majority of our team is out of sync with the majority of our customers because of the different time zones. We've hired three people for customer support who are based in Europe. But the two who work full time are currently in California training at the office, and the third just works part-time.

As far as customer support goes, the first priority is to eliminate the slow response times. Once we get that issue resolved, we can start thinking about how to deal with the time zone issue. Delays in support caused by the time zone difference are relatively minor compared to the net delays customers are experiencing.

As far as PR goes, I mentioned above that we're looking at what we can do to get information out to users more quickly if there's some issue with deposits, withdrawals, the site goes down, etc. Keep in mind that we have limited resources, so it's going to be a matter of doing the best we can with what we've got. But I'm sure it can be improved quite a bit.

[Dargo]

The unofficial kraken app(made by a user here on the forums) is big news on a prominent tech website in The Netherlands: http://tweakers.net/nieuws/93916/microsoft-laat-eerste-bitcoin-app-toe-op-windows-phone-platform.html

English: http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Ftweakers.net%2Fnieuws%2F93916%2Fmicrosoft-laat-eerste-bitcoin-app-toe-op-windows-phone-platform.html&act=url


This is the news we can use to get more volume on kraken!

Kraken: When are you planning to release android and iOS apps? I think you will be the first official one..

The iOS app will be first, but we don't have a release date at this time.   

[MusX]

no update about the order book bug yet?

[ledmaniak]

The site is now completely down

Doesn't Kraken have any emergency crew on call or at least some PR person that lives outside of the Pacific timezone for these type of things?

It's an interesting detail indeed that they are based on completely different timezone than where most customers are located and seem not to have anyone available in other timezones...

No response to this from Dargo?... It is certainly frustrating. Being that I am in the Middle East and exactly 12 hours different...

Yep it's awkward that the majority of our team is out of sync with the majority of our customers because of the different time zones. We've hired three people for customer support who are based in Europe. But the two who work full time are currently in California training at the office, and the third just works part-time.

As far as customer support goes, the first priority is to eliminate the slow response times. Once we get that issue resolved, we can start thinking about how to deal with the time zone issue. Delays in support caused by the time zone difference are relatively minor compared to the net delays customers are experiencing.

As far as PR goes, I mentioned above that we're looking at what we can do to get information out to users more quickly if there's some issue with deposits, withdrawals, the site goes down, etc. Keep in mind that we have limited resources, so it's going to be a matter of doing the best we can with what we've got. But I'm sure it can be improved quite a bit.

Sounds great! Good to hear that you guys are taking customer concerns serious. Lot of exchanges can learn from that.


For your information:
There are currently two parties in The Netherlands close to a banking license to trade XBT<->EUR. One focuses on the dutch market, the other on west-european market. The last one is already relatively big with a big customer base. As far as I can see, they can become some serious competition to kraken, especially when they get through the legal papers..

[Dargo]

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 buy sell 1 lot at 125.  The order picks up the 0.5 lots @ 127 and then the rest of it goes on the book as 0.5 lot @ 125. Now the current ask is 125 and bid is 120.

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).  

[denfucoin]

Deposit made on saturday, waiting for the funds to be available. I guess the weekend does exist in this business. If kraken support is around I made a request : #18205.

[ledmaniak]

Deposit made on saturday, waiting for the funds to be available. I guess the weekend does exist in this business. If kraken support is around I made a request : #18205.

A USD/EURO deposit? Banks don't work in the weekend(I love bitcoin ). Your payment should be processed somewhere today so maybe you get it today or tomorrow.

[tbosman]

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 buy sell 1 lot at 125.  The order picks up the 0.5 lots @ 127 and then the rest of it goes on the book as 0.5 lot @ 125. Now the current ask is 125 and bid is 120.

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).  

I don't really follow your explanation. How do you determine the side which initiates the trade? In this case the bid of 120 was there before the stop was triggered, so the sell order came last and is the initiating side right? I don't see how this ever could lead to a scenario where the trades executing at a price beyond the best bid/ask.

[denfucoin]

Deposit made on saturday, waiting for the funds to be available. I guess the weekend does exist in this business. If kraken support is around I made a request : #18205.

A USD/EURO deposit? Banks don't work in the weekend(I love bitcoin ). Your payment should be processed somewhere today so maybe you get it today or tomorrow.

All good. I receive my euros. Thanks a lot kraken.

[Serpens66]

today during this crash and also now kraken was/is slow =/
I often got/get the message "This data is not currently available. Please try again later." when I try to see my history. And submitting an order takes 5 seconds instead of 1 second.
or is it just me?

[Dargo]

today during this crash and also now kraken was/is slow =/
I often got/get the message "This data is not currently available. Please try again later." when I try to see my history. And submitting an order takes 5 seconds instead of 1 second.
or is it just me?

One of our team (and nobody else) is experiencing some issues as well. We think it might be a routing problem affecting some users. If anyone else is having issues, please report.

[Serpens66]

today during this crash and also now kraken was/is slow =/
I often got/get the message "This data is not currently available. Please try again later." when I try to see my history. And submitting an order takes 5 seconds instead of 1 second.
or is it just me?

One of our team (and nobody else) is experiencing some issues as well. We think it might be a routing problem affecting some users. If anyone else is having issues, please report.

At the moment everything is fine again...
But how about the "No trades currently available." on the market data on "recent trades" after refreshing the page? Me and also others get this in about 25% of the time, not only now.  Now with this high traffic it seems like it's 50% off the time. Kind of frustrating.

[Dargo]

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 buy sell 1 lot at 125.  The order picks up the 0.5 lots @ 127 and then the rest of it goes on the book as 0.5 lot @ 125. Now the current ask is 125 and bid is 120.

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).  

I don't really follow your explanation. How do you determine the side which initiates the trade? In this case the bid of 120 was there before the stop was triggered, so the sell order came last and is the initiating side right? I don't see how this ever could lead to a scenario where the trades executing at a price beyond the best bid/ask.

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).    

[Rannasha]

A question in the category "quite non-urgent":

In the language settings there is an option for both "English (GB)" and "British English". What's the difference?

[raskul]

would just like to post my appreciation of Kraken once more.
3 days since SEPA withdrawal (UK bank) and funds arrived this morning.

keep up the great work guys.

 

[finder_keeper]

Hi, is it possible to convert a USD balance (resulting from an XBT/USD trade) into EUR at the prevailing exchange rate?

Thanks!

[OleOle]

Hi, is it possible to convert a USD balance (resulting from an XBT/USD trade) into EUR at the prevailing exchange rate?

Thanks!

No, it's not.

What is possible though is sell USD to XBT, then with the XBT buy EUR.

Check Bloomberg, Reuters, XE.com or another reputable site to get the latest fx rates and see if doing USD to XBT to EUR gives a commensurate exchange rate.

Good luck!

[finder_keeper]

Hi, is it possible to convert a USD balance (resulting from an XBT/USD trade) into EUR at the prevailing exchange rate?

Thanks!

No, it's not.

What is possible though is sell USD to XBT, then with the XBT buy EUR.

Check Bloomberg, Reuters, XE.com or another reputable site to get the latest fx rates and see if doing USD to XBT to EUR gives a commensurate exchange rate.

Good luck!

It's not even close - first, the XBT/USD volumes are too low. Secondly, because withdrawing USD takes a long time and seems to be unreliable, there's a Gox-like premium for buying XBT with USD.

If Kraken were to use their bank to convert USD to EUR (the way bitstamp does, but in the other direction), they would benefit from increased trade volume from all the USD deposits.