Topic: [ANN] KRAKEN.COM - Exchange with USD EUR GBP JPY CAD BTC LTC XRP NMC XDG STR ETH - page 17. (Read 628889 times)

Hi pinkflower,

We are certainly open to suggestions on the currencies you'd like to see added to that platform. If there's a specific currency you'd like to see added, feel free to open a support request and we'll take note of it.


Hi CryptoTeng,

Your support request is currently still being handled by our specialized team. In the meantime, please note that any further communication and/or updates from us will be through your original ticket.

Our informant is still waiting for an answer, so much for taking this issue serious. The last email he got was more than 3 weeks ago.
Furthermore, as long as the data shows these peaks/dips every customer must assume that these peaks are real. Especially when Kraken does not issue an official statement that warns ALL its customers about these occurrences. Therefore, claiming refunds and/or compensation is more than justified.

Do I understand you correct that one could distinguish between real and false peaks by taking a look at the volume? Thus a peak/dip with very low volume is a false peak/dip, and if it is real it is paired with a large trade volume.

Taking a look at the ETH/EUR peak on June 19 using a 1 h interval, the volume is rather low for this type of peak, especially when comparing to the dip on June 22th which is paired with a rather high volume. However, we need to put ourselves in the situation on June 19th. So, we only look at trade data before the peak and neglect the trade data after the peak. Then the volume is not particularly low, actually it is higher than in most other 1h intervals within the last 48h.

After taking a look at the Dash/BTC market, we could further test this way to distinguish between real and false peaks. 1h intervals are used as it is not possible in Cryptowatch to go back to all peaks using a 15min interval. Times are given in CET.
1)   June 29 04:00-06:00 a double peak of 2.5% with very low volume: Real or not real
2)   July 3rd around 08:00 a peak of 1.5% with a bit higher volume: Real or not real
3)   July 4th around 08:00 big dip and peak, both roughly 4%, relative high volume: Real or not real
According to your way to distinguish, the first is a false peak, as the volume is rather low, and peak 2 and 3 are real because they have relative high trade volumes.
Am I correct, or is number 1 also a real peak?

As you might see, the way to distinguish does not guarantee a correct result. And even if this technique would yield a guaranteed correct result, it seems a bit odd that traders need to check your data for consistency in order to know whether the data is real or false.
Last, but not least. You are right. A misprint/mistake can happen. However, if one is responsible and is aware of a fault then one should try to correct it. Especially, when your customers trust you to display correct OHLC data. Let's not forget that customers pay fees for your service. Furthermore, this mistake is happening on a regular basis since more than a year. Therefore, I doubt that Kraken has taken this issue seriously.

Okay, but are you open to suggestions from the community, then do your own diligence or do you want to decide on those affairs on your own? Ty for giving us here some of your time to listen and reply.

Interesting, so it is a "misprint" again. At least you are now in line with the Kraken support. If your statement can be trusted is another issue. You have lied before, so why shouldn't you do so again? A bit suspicious, because Kraken seems not to be able to check their data for consistency after server restarts. A year should have been enough to build some kind of automated check whether the data is correct or not. And this is issue is going on for more than a year.

Then regardless of what is happening to the ticket, I still have the question why you (Kraken) are not correcting the OHLC data? As long as you knowingly present false/faulty OHLC data you are conducting market manipulation, at the very least by neglecting to correct. Those peaks create a very deceptive picture for traders. And since countless occurrences have been reported to you since the very least May 2017, you are knowingly (maybe even intentionally) presenting false data.
(Note: This is a general question, and not about the ticket itself, so it should be no problem to answer it.)

Just for your info: "Manipulation according to SEC https://www.sec.gov/fast-answers/answerstmanipulhtm.html
Manipulation is intentional conduct designed to deceive investors by controlling or artificially affecting the market for a security. Manipulation can involve a number of techniques to affect the supply of, or demand for, a stock. They include: spreading false or misleading information about a company; improperly limiting the number of publicly-available shares; or rigging quotes, prices or trades to create a false or deceptive picture of the demand for a security. Those who engage in manipulation are subject to various civil and criminal sanctions."

About the ticket. Then let's hope you (or someone else from the Kraken support) will reply there. To my knowledge our informant is still waiting for a reply to his last email about this case.

Hi CryptoTeng. After speaking at length with the trading team we've come to some conclusions that I'd like you share. First off, I had made an error in stating that trades had gone through in those instances. Based on the information that we have now, that was an error on my part. I'm sorry about that.

A misprint looks a lot like any other candle with excessive real volume, which is why they are so hard to narrow down. In the ETH/EUR case of June 19, there was a misprint for a few minutes. A moment's pause in our internal system caused this. Normally, the system is cleared out and the visual interface should reflect this but rarely, a misprint can happen. 

When the system pause happens, there is no actual volume traded. At the end of this pause, however, the cancelled volume falsely appears within the minute of system restart. This means that a 1 minute candle collects the data for more than a minute. As a result, a few minutes volume becomes falsely visible within a 1 minute candle.

Our site went down for roughly 2 minutes and when it came back online there was still old data that should have been cleared out that caused a misprint in the chart. Sell orders were not executed because no clients were actually buying at that price range.

As for the DASH/BTC issue in May, there was downtime with our API. The 15 minute candle starting from May 23 UTC 22:00 is where there is an unnatural spike. When disconnection occurred the data should have been wiped, but there was an error and the data falsely appears (like the previous case) within the 15 minute candle. In this case, the exaggerated candle would not reflect actual trades that went through, but instead reflects stale data clumped into a small frame of time.

As for the ticket and whether it is solved or not at this time, that would need to be addressed in the ticket. It's at a specialized team at the moment because we take legal threats and market manipulation accusations very seriously. Any further communication from us will be through that ticket. Thanks for understanding.


Hi Mbidox. I understand your concern about the fee. The main difference that you'll notice with exchanges and wallets is the fact that we have fees to withdraw from the exchange, rather than miner's fees only. This is the same with many of the exchanges that our clients use. What we would suggest is that you withdraw funds to your own wallet and spend them from there, rather than spending directly from your Kraken account.

I've made a note of your suggestion for a dynamic fee option. If that comes into play in the future you would see it in our support documents. Thanks for reaching out and please let us know if you have any other questions.

Since February according to
https://jochen-hoenicke.de/queue/#0,6m
a transaction costs again only max. 5 satoshies per byte.

So for an average transaction of 226 bytes, that's 1130 satoshies, which equals 0.00001130 BTC.

Why does Kraken still pay the miners 0.00050000 BTC? This is totally inappropriate. 

I've been waiting since February for Kraken to adjust the transaction fee back to the new reality. But nothing happened. I have the feeling that I am the only one, who has noticed that in the meantime the real rate of change has fallen sharply again.

With me it does not hurry, if I withdraw my BTC's from Kraken. And I think many others are not in a hurry either.

So my suggestion: Kraken should offer 2 differnt fees and let the user choose whether he wants a quick transfer or not. Even for a quick transfer, these 0.0005 BTC's are totally over the top.

Or an other suggestion: Kraken should make the fee dynamic. Nobody wants to pay 0.00050000 BTC for a transaction, if 0.00001130 BTC is enough.

I'm rather angry.

Would appreciate a statement from Kraken. Thank you.

Hi CryptoTeng. I havn't forgotten about you. I'm still speaking with the trading team to make sure we have the correct information for you. Thanks for your patience.

hey septimus,

do you remember this issue (actually the same as the current one). According to our info Kraken still denies to pay refunds/compensation for the case on April 3rd, or better let's put it this way, Kraken just does not reply to email communication about this issue, not even the legal department. Additionally, according to you the issue on 3rd April was a misprint, but the OHLC data of that day still shows the false peak. Are you going to take as much care of the current case as you did for the one on 3rd of April?

Maybe you really could finally clarify how a customer can distinguish between false and real peaks. For the problem on 3rd April you claimed it to be false peak, for the similar issues on May 24th and June 19th you call the peaks real (whereby the Kraken support claims they are false).

Furthermore, you never answered the questions posted about the issue on 3rd of April.

So, actually everything give the impression that Kraken does not care to solve this problem.

Just checked with the informant. He hasn't been contacted by you, Kieren, or any other Kraken representative yet. Any news from your side Septimus?

Hi Cryptoteng. I'll follow up with you once we have more information on this issue. Thanks for your patience.


Hi pinkflower & RivAngE. We're always looking to add more coins/tokens but it does come down to our own due diligence. You can follow our Blog and Twitter for the most up-to-date information on new listings.

I think Kraken doesn't add any new coin because they are very selective with the coins. I am using it and I enjoy Kraken too

I'm also interested in knowing that, since they have not added any new coin for months now as far as I have noticed.
That's too bad because KRAKEN is my most trusted Exchange at the moment and whenever I deposit FIAT to buy crypto, I do it through KRAKEN. However I have to buy LTC/XRP/ZEC which are cheap to move and withdraw to another exchange in order to buy coins that are not listed here.

Septimus, what are Kraken's requirements for coin listing? Do they need the project's developers to apply or do you choose according to your own criteria? Ty.

Don't know whether you have the right one. Let's hope you do. Maybe just take care of all cases regarding this type of issue. Still, the contradictions of you and the Kraken support are interesting.

Hi CryptoTeng. Thanks for that information. I've located the ticket that was created on the 19th and will follow up on this with Kieren. Please let us know if you need anything else.

Please stop pretending. Our informant is being denied any kind of refund and/or compensation, even after contacting the legal departemnt after the initial contact with your pretense of a support. Kraken simply ignores answering the follow up emails. LOL, this is turning kind of funny Septimus.

And the issue is clear. Open positions were not closed even though Kraken's OHLC clearly shows those positions limits were clearly passed. The support claims no trades took place, so no closing of positions.... This means you display false OHLC data. And the same type of problem was reported several times over the past year. We even had contact about this issue here in the forum.

Now you claim, that the peaks are real. Maybe you can answer this general questions then. So, if this should be true, don't you agree that our buddies open positions should be closed when they were in the peak and opened before the peak?
And why does the Kraken support then tell that no trades took place in first place?

This is all very very weird. Don't you think?

Hi Cryptoteng. Please let us know in the ticket where you feel the error is and we'll be sure to address it. The other option would be to let me know your ticket number, or your friend's ticket number and I'll have a look into this for them. Thanks.

This is a plain lie Septimus, either by you, or by the support team towards our informant. The support team claimed that no trades took place on both dates. and our informant has evidence that his open positions in those peaks were not closed. Furhtermore Kraken denied closing his position with the argument that no trades took place in those peaks.

So, either you are lying here in the forum, or the customers support is lying towards our informant. Neither of the possibilities looks well septimus.

If you want we can post screenshots showing the peaks and the non traded positions including the indications which clearly show the positions were opened
before the peak.

Hi Cryptoteng. I've consulted with the trading team and they filled me in on what happened here. In both of these instances there was at least 1 trade that went through at these prices. For May 24th, the previous candle closed at 0.04450, the next one opened at 0.04867, which was the high (the spiked order had actually filled). Then the priced dropped back down and the candle closed at 0.04516.

For June 19th ETH/EUR, a large order filled at 511.51 when the market price in the previous 30min candle was 442. The volume in the spike was 1600 ETH whereas the previous candle volume was only 8.9 ETH. The next candle volume was 147.21. So to be clear, there was nothing being manipulated in either of these instances.

If you feel that this does not resolve your issue, please open a ticket and we would be happy to go over these findings with you.