A hidden spell check sent my recovery phrase to Google. Five days later, 17 BTC worth was gone.

Key questions

Video response (3 March 2019)

Watch on YouTube

My video response to Coinomi's statement, with the reproduction of the spell-check requests. It opens on YouTube. saved 97327e6f

TL;DR

Based on my personal experience and careful research, I've discovered potential security vulnerabilities with the Coinomisaved d80295d7 multi-asset wallet. Its design could lead to seed phrases appearing in clear text inside the HTTPS request payload to googleapis.com during desktop restore testing, potentially compromising the security of your digital assets. In my case, I believe this issue led to a loss of approximately 17 BTC worth of cryptocurrency.

During the process of investigating this issue, I encountered CipherBladesaved 94f6fce1, a company with a limited history that is potentially operating through a chain of offshore shell companies. This company also publicly disclosed my private cryptocurrency wallet addresses without consent, a clear violation of privacy norms.

In light of these experiences, I urge anyone using or considering using Coinomi or engaging CipherBlade's services to be aware of these potential risks. Despite the claims of both companies, critical scrutiny is advised before engagement.

For a deeper understanding, please review the following links:

Based on my experiences, I would caution potential users to carefully consider the potential risks before using Coinomi. This post provides further details to help understand my concerns.

The incident

In retrospect, I acknowledge that it may not have been wise to place trust in the Coinomi wallet by using it with my Exodus wallet passphrase. This decision was based on the fact that I downloaded the software directly from the Coinomi website, the setup file was digitally signed, and the wallet had been mentioned by several reputable websites, such as bitcoinwiki.org. My aim was to transfer assets that were not supported by the Exodus wallet, using the same passphrase/seed.

The incident occurred on 2019-02-14. Upon downloading and installing the Coinomi application (Windows version), I observed that while the setup file was digitally signed, the main application was not signed after the installation process had been completed.

I publicly contacted Coinomi via Twitter (@warith2020saved 523b59bf) about this issue, and they acknowledged it. Subsequently, they uploaded a new version with the main application signed. By this point, I had already entered my Exodus wallet passphrase into the Coinomi application.

On 2019-02-22, I discovered that a significant proportion (over 90%) of my Exodus wallet assets had been transferred to various wallet addresses. The first transaction, involving Bitcoin (BTC), commenced on 2019-02-19 03:30 UTC. This was followed by transfers of Ethereum (ETH), including ERC20 tokens, Litecoin (LTC), and finally Bitcoin Cash (BCH).

Technical analysis

I began by retracing my steps and analysing the sequence of events. The only new action I had taken was the installation and use of the Coinomi wallet. This led me to my initial hypothesis: the unsigned version of the application might contain a backdoor.

Subsequently, I conducted a more thorough investigation, comparing both the unsigned and signed versions of the setup file. The only difference between the two was the addition of a digital signature to the main executable file and the Java file (the main application).

At this point, I suspected that there might be something amiss with the application, beyond the lack of a digital signature on the main executable. To test this theory, I replicated my actions in a new virtual machine, this time installing "Fiddler," a software tool that enables the monitoring and debugging of HTTP/HTTPS traffic from all applications running on a machine.

While running Fiddler in the background, I started the Coinomi wallet. The first thing I noticed was that the Coinomi application began to download a dictionary wordlist from the following web address:
https://redirector.gvt1.com/edgedl/chrome/dict/en-us-8-0.bdic

When I clicked on 'restore wallet' and pasted a random passphrase, an alarming discovery was made: the entire passphrase appeared in clear text inside the HTTPS request payload to googleapis.com, a domain owned by Google, as part of a spell-check function! Here is a screenshot of the HTTP request for reference:

SHA-256 ecf18fa0a6…

To substantiate my findings, I have uploaded a video, allowing anyone to test and replicate what I did:

Download the video evidence (MP4, 2.4 MB)SHA-256 cf48f6226e…

Anyone can verify this by pasting any random sentence with a spelling mistake into the textbox in Coinomi's 'Restore Wallet' page. It will be underlined with a red line after appearing in clear text inside the HTTPS request payload to googleapis.com. [2026 note: this describes version 1.0.4 as tested in February 2019; both of its installers are archived on this page.]

Technically speaking, Coinomi's core functionality is built using the Java programming language. The user interface is designed using HTML/JavaScript and rendered using an integrated Chromium-based browser (Google's open-source project).

The whole process uses JxBrowser to build cross-platform applications. And before anyone (like Coinomi's CTO) suggests this is an issue with JxBrowser, they acknowledged this spell-checking behavior on their website back in 2016 and provided instructions on how to disable it:
View JxBrowser Documentationsaved 6ad7595d [2026 note: the page is gone; this links to an archived copy. The current JxBrowser spell checker guidesaved f0ee5da3 still says "By default, spell checking is enabled."]

In essence, the textbox where you enter your passphrase is actually an HTML file run by a Chromium browser component. Text typed or pasted in this box results in an HTTPS request to googleapis.com for spell-checking.

The consequence of this flaw is that an unknown party with access to data sent to googleapis.com could have obtained the seed and use it to steal my crypto assets worth approximately 17 BTC (or its equivalent) at the current market price. It's widely known among those involved in technology and cryptocurrency that a sequence of 12 random English words separated by spaces could well be a passphrase for a cryptocurrency wallet.

Coinomi's response

The behavior could stem from configuration choices in the embedded browser's spell-checker. The vendor disputes that any data was processed. Both views and the evidence are presented for readers to evaluate.

Throughout our exchanges, the Coinomi team seemed primarily concerned about their public image and the technical details of the bug, rather than the consequences of the security flaw. Despite my urging them to acknowledge the issue, they appeared to dismiss the severity of the situation and its impact on my stolen cryptocurrency assets. The team reminded me of potential legal implications if I were to share this information publicly, while seemingly neglecting their own responsibility in the loss of my assets and the potential risk posed to other users.

Given the urgency and severity of the situation, their response time struck me as surprisingly lackadaisical. This is not the first time Coinomi has been accused of such behavior. Luke Childs previously reported a security vulnerability in Coinomi's software, and it appears that their response was similarly dismissive, as documented here:
Bitsonline articlesaved cb3648a7 [2026 note: the page is gone; this links to an archived copy.] and Luke Childs' blog postsaved b5992395. [2026 note: the flaw Luke Childs reported on GitHub in 2017, wallet addresses sent in plain text, is now registered as CVE-2017-20200, whose record cites that GitHub issue.]

Policy excerpts (Google API Services)

• "Deceptive or unauthorized use of Google API Services is prohibited … Do not misrepresent what data is collected …"
• "Be transparent about the data you access with clear and prominent privacy disclosures …"
• "Google may monitor use of the APIs … and may suspend access if in violation of the Terms."

Recap

In summary, for the purpose of further investigation, here are the key events:

• On 2019-02-14, I entered my passphrase into the Coinomi wallet for the first time. This passphrase appeared in clear text inside the HTTPS request payload to googleapis.com.
• Between 2019-02-14 and 2019-02-19, an individual with access to data sent to googleapis.com could have processed information that included my passphrase.
• On 2019-02-19 beginning at approximately 03:30 UTC and continuing for about 15 minutes, my cryptocurrency assets were stolen. By the end of this period, 90% of my assets had been taken. The remaining assets were left untouched because these particular assets were supported by the Exodus wallet but not the Coinomi wallet, a detail that could be seen as more than coincidental. [2026 note: the Exodus history times the four coin transfers from 03:30 to 03:48 UTC; see chapter 06.]

For clarity, it's important to note that I took extensive precautions to keep my passphrase and wallet secure. I utilized a separate, isolated virtual machine equipped with anti-virus/anti-malware software and a firewall. I have been using other wallets on the same virtual machine for years, and until this incident, nothing had been stolen. The only wallet that was compromised was the one in which I had recently used my passphrase: the Coinomi wallet.

What's next

I am considering initiating legal action against the company responsible for Coinomi if they do not acknowledge and take responsibility for this issue. The company is registered in the United Kingdom as 'Coinomi LTD'. If anyone else has experienced a sudden loss of crypto assets and has used the Coinomi wallet, your case could be relevant. Interestingly, Coinomi claims on their website that, 'Most importantly, no Coinomi wallet has ever been hacked or otherwise compromised to date.' This claim appears to be contradicted by my experience.

It's important to note that potentially all desktop versions of the Coinomi wallet may be affected. I cannot confirm whether the mobile versions are also affected. The individual or group capturing passphrases may be selectively targeting wallets with substantial assets in an attempt to maintain a low profile.

Final thoughts

This ordeal has proven to be a costly and emotionally taxing learning experience, and I share it in hopes that others may avoid a similar fate. From this incident, I've gleaned the following critical lessons:

• Security Audit Requirements: Be extremely wary when entrusting any multi-asset crypto wallet. Ensure they have undergone an external security audit by a reputable third-party, and that this audit is publicly accessible and recent.
• Coinomi Caution: Exercise extreme caution when dealing with Coinomi and your hard-earned cryptocurrencies. In my experience, they did not assume responsibility when critical security issues arose.
• Google Services Privacy: Be careful when entrusting sensitive information to Google services/products. They have vast control over data, and their policies may not be stringent enough to prevent misuse by employees or malicious parties.

The primary purposes of this publication are:

• User Awareness: To raise critical awareness among current and potential Coinomi wallet users about this serious vulnerability.
• Restitution Demand: To demand proper restitution for my stolen cryptocurrency assets from Coinomi, either in cryptocurrency or fiat currency. The longer they delay, the greater the potential value becomes.
• Google Investigation: To urge Google to initiate a thorough investigation into this issue, considering both the financial losses and serious privacy implications for users worldwide.

Finally, I encourage readers to share this information to increase awareness. I firmly believe that this will help protect hundreds of thousands of crypto assets and enable many users to safeguard their hard-earned cryptocurrency assets.

In the future, if you need to spell check your passphrase/seed and ensure it adheres to the English dictionary, think twice before using Coinomi wallet.

Overview

Coinomi, under the pressure of the community (to whom I extend my special thanks), has finally released an official statement concerning the incident. You can find their statement at this link (screenshotSHA-256 32fff7e192…): Coinomi's official statement on Mediumsaved 4702b00f

Firstly, I wish they would display the same level of transparency that I have shown by publishing my responses on their social media channels, allowing readers to make their own judgements based on both sides of the story.

I had anticipated that Coinomi's official statement would be lacking in some areas, but I did not expect it to be as inadequate as it turned out to be. However, it seems to be a clear reflection of the mentality behind their proclaimed "never been hacked" wallet.

I will now address their official statement, quoting and providing screenshots of parts of their response. This seems necessary, given their tendency to delete their posts.

Coinomi's statement, point by point

Starting with their announcement title:

SHA-256 a247c7abf4…

Referring to this severe security issue as merely "findings" is not only misleading, but it also demonstrates an evasion of responsibility. Coinomi appears to be hesitant to label this issue as a critical vulnerability, even though its seriousness extends beyond just 'critical.' In the field of information security, vulnerabilities are typically ranked according to their severity: Low, Medium, High, or Critical. Given the gravity of this situation, I propose that the information security community introduce a new ranking: the "Coinomi Level," which would denote the highest level of severity.

Going to the next statement:

SHA-256 37b704018b…

"The seed phrase wasn't being transmitted in plain text, instead it was being encapsulated inside a HTTPS request with Google being the sole recipient"

When I mentioned that my passphrase was transmitted in plain text, I was referring to the fact that it reached Google API servers without any form of encryption. It is essential to understand the difference between transmitting data through a secure tunnel (as is done with HTTPS) and actually encrypting the data before transmitting it.

Hypothetically speaking, if Coinomi had encrypted the passphrase prior to sending it to Google, then even if this data was transmitted via HTTP (without SSL/TLS), it would still have reached the destination in an encrypted format. The notion of securely transmitting my unencrypted passphrase to Google under the guise of taking all necessary security measures is rather amusing, if not alarming.

"The seed phrase wasn't being transmitted at all unless the user chose to explicitly restore their Desktop wallets"

Coinomi's statement is rather humorous, essentially implying, "This isn't a vulnerability because the issue only arises when the user chooses to restore their wallet. Otherwise, they would be safe." This suggests that, as a Coinomi user, you're not supposed to use the "restore your wallet" feature, and that this option exists solely to spell-check your passphrase against Google's dictionary.

"The spell-check requests that were sent over to Google API were not processed, cached or stored and the requests themselves returned an error (code: 400) as they were flagged as "Bad Request"¹ and weren't processed further by Google"

Coinomi's claim is somewhat misleading. How can Google's API server respond with a "Bad Request" without first understanding the content sent to it? The screenshot Coinomi provided, showing Google's web service response, is actually from the perspective of the web application. A web application doesn't respond to a request until it first processes the data and determines its validity.

In reality, the situation might be much worse than Coinomi is implying. Google's API servers require a valid API Key to use their web services. In Coinomi's case, they sent the request using an invalid (unauthorized) API Key, causing Google's API server to treat the request as a bad request. This would likely trigger investigation of the cause of the bad request. Upon seeing the 12 English words separated by spaces (which looks like a passphrase to a cryptocurrency wallet), an unknown party might start to question its origins. This situation becomes even more concerning if the server is managed by a third party or has been compromised.

In other words, if Coinomi had used a valid API Key, Google would have been obligated to handle the data more responsibly. This could potentially make anyone attempting to misuse the passphrase think twice.

Going to the next statement:

SHA-256 df96d8a15c…

"Our engineers immediately tracked down the cause of this issue, which wasn't a bug in our source code but instead was a bad configuration option in a plug-in used in Desktop wallets only."

Claiming that this issue wasn't part of their "source code" is quite misleading, and it appears that Coinomi is attempting to evade responsibility. The JxBrowser component/plug-in is bundled with Coinomi's wallet at the source code level, and developers have the ability to enable or disable any undesired feature of JxBrowser directly from the source code. Essentially, this was a feature that Coinomi misused, and it consequently turned into a critical security bug.

Coinomi's team seems to be trying to divert the community's attention and place the blame on JxBrowser for their own mistakes. However, it's worth noting that JxBrowser clearly explained this default behavior in their documentation as early as 2016, and provided instructions on how to disable it:

SHA-256 9fc4452ccd…

The original link can be found here: Configuring Spell Checker (JxBrowser, 2016)saved 6ad7595d [2026 note: the page is gone; this links to an archived copy. The same instruction is in the current JxBrowser spell checker guidesaved f0ee5da3.]

To make it simple for the readers, Coinomi could have avoided the "spell check" scandal with a single line of code:

spellChecker.setEnabled(false);

It seems that the developers at Coinomi, whom they refer to as the "Code Gurus," did not take the time to familiarize themselves with the JxBrowser documentation. It is puzzling why they even chose to use JxBrowser in the first place. The core functionality of the Coinomi wallet is already based on the Java programming language, which inherently provides cross-platform compatibility. There should have been no need for a third-party component like JxBrowser. The likely explanation is that they were too lazy to develop the UI natively in Java and opted for a quick and hasty solution to release the Desktop version promptly, possibly disregarding proper quality assurance testing, assuming it was conducted at all.

Legal implications

The interesting aspect of the "spell check" vulnerability, when viewed from a legal perspective, is that it could be considered a "feature" or, more specifically, a hidden feature. Coinomi did not disclose this feature anywhere in their "Terms of Use," their wallet application, or their documentation.

Now, let's discuss the terms and conditions of using the Google API. You can find these terms in the following links:
Google APIs Terms of Servicesaved 9581b29d
Google API Services User Data Policysaved 4fdcc241

Quoting some of their terms:

SHA-256 e2535d411b…

SHA-256 c23e850127…

It is evident that Coinomi has violated several terms and conditions in their actions. For instance, they utilized the Google API without a valid API Key, which constitutes unauthorized usage, and they failed to inform their users about this practice. In essence, they deceived Coinomi wallet users by implementing a hidden "spell check" feature that relies on Google API servers to verify their passphrases/seeds.

Coinomi stated in their official announcement that the data they sent to Google API servers were not "processed, cached or stored". Don't take my word for it, and let's see what Google says in their terms:

SHA-256 72df73425f…

Based on our analysis, it can be concluded that the utilization of Google API to "spell check" users' passphrases/seeds was a hidden feature that was not disclosed in the "Terms of Use" that I agreed to before installing the application. Had I been aware of this feature, I would not have used the application unless my intention was specifically to enhance my passphrase vocabulary. The omission of this information deprived users of the opportunity to make an informed decision about the potential risks associated with using the application.

It appears that there is a need for a change not only in their CTO but also in their legal representation.

Support ticket deception and privacy

First and foremost, the public disclosure of my support ticket is a blatant breach of my privacy as a client. It contained confidential information pertaining to my case, including my personal crypto-currency addresses and the destination crypto-currency addresses. Such sensitive information should only be accessible to the relevant authorities and the parties directly involved in the case.

Furthermore, it is perplexing that Coinomi would label me as a "blackmailer" in their official statement, considering the fact that I willingly provided them with my personal wallet passphrase/seed. If my intention were to engage in fraudulent activities, why would I voluntarily share such sensitive information with them? I am relieved that I transmitted my passphrase/seed through an encrypted channel, as it appears that they would have been willing to publish it otherwise.

Key facts and evidence

I will recap the events to understand why I was affirmative with my conclusion that my assets were stolen because of Coinomi wallet and not because any other reason:

• Downloaded and installed Coinomi wallet on 2019-02-14.
• Pasted Exodus wallet passphrase/seed into Coinomi's wallet on the same day.
• Opened a new Coinomi wallet with a different passphrase and transferred crypto assets from an exchange to the wallet.
• Crypto assets were stolen on 2019-02-19.
• The only compromised wallet was the Coinomi wallet where the Exodus passphrase was pasted.
• Multiple wallets on the same virtual machine were not affected.
• Assets in the new Coinomi wallet were not stolen.

Based on these facts, it is evident that the only wallet that was compromised was the Coinomi wallet into which the Exodus passphrase was pasted. This wallet had a vulnerability or feature that allowed spell checking of passphrases/seeds using Google API servers.

Misleading, contradictory and unprofessional tweets

The team behind Coinomi made significant efforts to mislead the community by disseminating false information. I have gathered several screenshots of their tweets to shed light on the questionable practices employed by the company and to provide the community with a clearer understanding of the nature of this organization:

SHA-256 81c9e269e6…

SHA-256 cc60dc1e4c…

SHA-256 bede345467…

SHA-256 58348872cf…

SHA-256 f6a018e7a2…

Website takedown attempt

In a further attempt to silence this case, Coinomi filed a copyright and trademark abuse report to have this website taken down. The complaint, which falsely claimed trademark violation, was an effort to revoke the site's hosting and suppress the evidence presented here.

SHA-256 08ec7c618c…

The USPTO trademark filing (serial 88228678)saved 42cf385b

[2026 note: in 2026 three abuse reports were filed against this case file; none says who asked for them; see chapter 09.]

Patient zero

In their official statement, Coinomi argued that they had received no reports of hacked Desktop wallets, using this as a justification. However, it is important to note that there have been multiple reports on Reddit of stolen assets from Coinomi wallets. Despite this, I would like to outline several reasons why I may have been one of the first victims of this incident:

• The Desktop wallet is new and it's less than 3 months old (announcement screenshotSHA-256 2848d1e614…). [2026 note: Coinomi announced the Desktop beta on 31 December 2018.]
• Desktop users are a lot less compared to the mobile version of the wallet.
• To trigger the bug, the user has to restore his wallet.
• My address had decent amount of crypto assets that attracted the criminal who stole my crypto assets.

Who's behind Coinomi?

It appears that the team behind Coinomi, particularly the management, is evading responsibility and operating in secrecy. I am providing a list of individuals involved so that the community can recognize them if they are associated with any future projects or if they decide to rename Coinomi to something like "Spell Checker." Their actions have had a detrimental impact on the cryptocurrency ecosystem, as they lack credibility and professionalism.

SHA-256 a80a04b4ad…

SHA-256 47634fddd4…

[2026 note: this list shows Coinomi's staff as of March 2019. According to Coinomi's own website and a team member's biography, Coinomi was relaunched in 2024 by a team that includes the co-founder listed above (chapter 08).]

Final thoughts

Based on my second statement and the video response on YouTubesaved 97327e6f I shared, I am confident that I have presented all the relevant facts and evidence to support my claims regarding the theft of my cryptocurrency assets. I have also provided clear evidence that demonstrates Coinomi's lack of credibility.

Since Coinomi continues to refuse to take responsibility for my loss, I have no choice but to pursue legal action against them. If they insist on taking the hard path, so be it.

To the person who stole my cryptocurrency assets, I want to convey this final message. The situation is escalating, and legal investigations will soon commence. You still have an opportunity to rectify your mistake and return the assets to the following addresses:

Overview

Coinomi made desperate attempts to salvage its tarnished public image following the "spell check" scandal. Despite their unsuccessful social media tactics, they resorted to hiring a third-party company called CipherBladesaved 94f6fce1 to defend them and discredit my case against them.

It is important to note that Coinomi has a history of engaging in cheap practices (see my second statement), as I have previously mentioned. In this instance, they went so far as to employ CipherBlade, a company with minimal experience and no established track record, in an attempt to whitewash their wrongdoing. I urge you to read the entire statement from CipherBlade to understand the extent of Coinomi's cheap tactics.

In their report on Mediumsaved 9e9e311e, CipherBlade concluded that my funds were stolen due to malware on my machine and not as a result of Coinomi's "Spell Check" hidden feature that transmitted my seed/passphrase to a third party in plain text. Despite claiming impartiality, CipherBlade ignored several crucial facts and attempted to mislead the community, much like Coinomi. It is worth noting that CipherBlade directly challenged me in their report, calling into question their claimed impartiality.

Furthermore, CipherBlade did not make any effort to contact me or verify the information from my perspective. This raises doubts about their alleged lack of bias in favor of Coinomi. It is evident to anyone with common sense that CipherBlade is making concerted efforts to launder Coinomi's public image, just as they previously did with their ShapeShift defencesaved 139fa869.

A reminder

First of all, let me remind you of the following tweet that Coinomi posted after my first statement:
Coinomi's tweet (screenshot)SHA-256 81c9e269e6…

They stated that they hired a Blockchain analysis firm and they claimed that the funds were NOT stolen. I wonder, was it CipherBlade? How is it that they are now stating that the funds were indeed stolen?

Coinomi also mentioned in their support ticketSHA-256 724eb7f528…, before the issue became public, that they were collaborating with their partner "Chainalysis," another Blockchain analysis firm, and they claimed that they would blacklist the addresses involved. However, upon my own investigation and confirmation with several exchanges, it appears that no such blacklisting has occurred. This raises questions about what Chainalysis had to say about the incident. Were Coinomi's intentions to leverage the reputation of Chainalysis for trust and to mitigate the situation?

Coinomi also stated in their official statementsaved 4702b00f that they have contacted Google, but there is no update regarding their claim since 2019-02-27:

SHA-256 a5ec9f34d6…

Furthermore, Coinomi has accused me of blackmailing them, suggesting that I intentionally sent the stolen crypto-currency to myself and falsely blamed them for my loss. However, it is contradictory that they now change their narrative and confirm that the funds were indeed stolen.

These inconsistent statements and actions by Coinomi only serve to further undermine their credibility. They have propagated false information in an attempt to mislead the community, and they have resorted to hiring external entities to support their position. Such behavior raises serious doubts about the integrity and trustworthiness of Coinomi as a company.

Making things clear

CipherBlade was hired by Coinomi to write the report, and they clearly stated that in their report:

SHA-256 e89f65c33c…

It is interesting to observe how Coinomi carefully chooses their words to present a more favorable picture. Their use of the phrase "we were compensated for our time" actually implies that they paid for the report. It is clear that CipherBlade was biased towards one party, otherwise, why would Coinomi invest money in a report that may not guarantee a favorable outcome and could be influenced by them. This raises doubts about the objectivity and independence of the report provided by CipherBlade.

Furthermore, CipherBlade disregarded the substantial evidence and facts presented in my initial and subsequent statements. Their report relied solely on assumptions, without considering the concrete evidence that my loss was a result of my seed/passphrase being sent to Google. Coinomi has a legal obligation to engage with Google and initiate an investigation, yet CipherBlade conveniently overlooked this crucial fact as it does not align with Coinomi's stance in this case. This selective omission raises doubts about the integrity and thoroughness of CipherBlade's analysis.

Despite CipherBlade's repeated suggestions in their report, I want to clarify that my objective is not to investigate or apprehend the individual responsible for the theft of my crypto-currency assets. Instead, my primary goal is to pursue legal action against Coinomi to seek compensation for my losses. The crux of the matter lies in the fact that Coinomi's software contained a concealed feature, undisclosed in their documentation and terms of use, which transmitted my seed/passphrase to a third-party server. This omission on Coinomi's part is the basis for my legal claim and pursuit of justice.

I didn't directly utilize Google API services; instead, I relied on Coinomi's wallet, which incorporates a feature that transmits the user's seed/passphrase to Google servers. Consequently, Coinomi bears legal responsibility for engaging with Google and pursuing the identification of the perpetrator. To illustrate, in cases where an exchange experiences a security breach resulting in the theft of users' funds, affected users typically initiate legal action against the exchange rather than the individual responsible for the breach. This is because users place their trust in the exchange to safeguard their funds, aligning with the principles outlined in Data Breach laws in the UK and Europe. It appears that CipherBlade may lack a comprehensive understanding of these laws, despite claiming to possess expertise in legal proceedings and advice.

Ironically, despite proclaiming themselves as a cyber-security firm, CipherBlade failed to recognize the severity of the "Spell Check" bug as a CRITICAL vulnerability in their report. Their oversight in acknowledging the gravity of the issue raises questions about their competence in the field. With that in mind, I sarcastically nominate CipherBlade as the epitome of excellence in the cyber-security industry (pun intended).

CipherBlade's report

When one encounters a case study report authored by a purported blockchain analysis firm, the natural expectation is for a technical analysis supported by substantial evidence. However, in the case of CipherBlade, their report primarily revolves around presenting negative arguments against me while offering favorable assumptions in favor of Coinomi. The report gives the impression of being drafted by a legal firm aiming to defend its client's interests (or possibly even written by Coinomi themselves).

Most of the arguments raised by CipherBlade in their report have already been addressed in my previous statements. However, I would like to emphasize and quote some of the false arguments that CipherBlade presented in their report to support Coinomi's position positively. It is important to examine these arguments in detail to expose their inaccuracies and misleading nature.

Quoting from CipherBlade's report:

SHA-256 4308668ead…

This is a clear example of CipherBlade contradicting itself. They acknowledge that digital signatures are used to verify the authenticity and integrity of a file, ensuring it has not been tampered with. In the case of Coinomi, the main executable files were not digitally signed, which supports my claim that there were security vulnerabilities. This inconsistency further strengthens the validity of my argument.

CipherBlade's claim that it is nearly impossible for a digitally signed installer file to contain a malicious executable file is a misleading and incorrect statement. It demonstrates a lack of technical and cybersecurity knowledge on their part. Digital signatures are meant to verify the authenticity and integrity of a file, but they do not guarantee the absence of malicious content. Malicious files can still be present within a digitally signed installer file, especially if the digital signature itself has been compromised or the file has been tampered with after the signing process. This statement by CipherBlade showcases their misunderstanding of cybersecurity principles and raises doubts about the credibility of their report.

A digital signature is used to build trust between the developer and the user by ensuring the integrity and authenticity of a file. However, it is important to understand that a compromised digital signature certificate can be used by an attacker to digitally sign malicious files on behalf of the original developer. Additionally, there have been instances where attackers have successfully modified executable files before the building process or during the creation of the final setup or installer file, even in cases where the application was digitally signed. These examples highlight the fact that a digital signature, while important, is not a foolproof guarantee of the security and trustworthiness of an application. It is crucial to implement robust security measures throughout the development process to detect and prevent such compromises:
Ars Technica, "Powerful backdoor found in software used by >100 banks and energy cos." (2017)saved 02009fdf.

Now, let me highlight a significant point to conclude this argument. The deletion of a tweet by Coinomi, where they initially confirmed the absence of a digital signature, raises suspicion and prompts questions about their actions. The removal of this tweet may give the impression that Coinomi is attempting to hide or alter previously acknowledged information. It is important to consider the implications of such actions, as they can impact the perception of the company's trustworthiness and credibility.
screenshot of the deleted tweetSHA-256 d3bc6a55c6…
my original tweet of 14 February 2019saved 228e3ac4

Moving to the next statement:

SHA-256 98ae3e7d3b…

I have thoroughly addressed this argument in my second statement, providing a detailed explanation of why I believe I was likely one of the early victims. In that statement, I highlighted a crucial point that the desktop wallet I used was relatively new, with a lifespan of less than three months. Additionally, I presented other pertinent facts that support my claim. For further information and a comprehensive understanding of the circumstances, I invite you to review my second statement:
Patient Zero

There have been multiple reports of users experiencing stolen funds both before and after my incident when using Coinomi's wallet. While the cause could be attributed to the same vulnerability, such as another potential backdoor in Coinomi's wallet or users' inadequate security precautions, it was evident in my case that my crypto-currency assets were stolen due to the presence of Coinomi's hidden "Spell Check" feature. This feature specifically played a significant role in the compromise of my assets, as detailed in my previous statements.

Referring to my solid facts as a "hypothesis" is yet another misleading statement. In my second statement, I provided detailed explanations regarding how Google explicitly states that it handles invalid requests to their API server with caution. The specific details can be found in my previous statement, where I outline the clear evidence supporting my claims here:
Legal Implications

Moving on to the final quote in this part:

SHA-256 9e6158e316…

CipherBlade claims that the possible cause of my stolen crypto-currency assets is malware that monitors the computer's clipboard. Once more, it's just an assumption that I have already addressed in my video responsesaved 97327e6f.

As mentioned in the video, Coinomi was installed on a separate and isolated virtual machine. Both my main machine and the virtual machine were equipped with an Anti-Virus/malware application called SpyShelter. SpyShelter is an advanced Anti-Spyware program with a Host Intrusion Prevention System (HIPS). It actively monitors and detects the behavior of applications, regardless of whether they are considered malware or not. One of its features is clipboard protection, which alerts the user if any application attempts to access or capture clipboard data. More information about this feature can be found on the SpyShelter website: SpyShelter: Clipboard Protectionsaved f6bc0b3c [2026 note: the page is gone; this links to an archived copy.]

Moreover, it is important to note that I have utilized a password manager to copy and paste passwords related to various other crypto-currency wallets, bank accounts, PayPal, Amazon, eBay, and numerous other platforms over the past five years. Despite this, no compromises or thefts occurred except for the wallet in which I pasted my seed/passphrase, specifically Coinomi's wallet. In light of this, I invite CipherBlade to share their cyber-security expertise and enlighten me with their insights.

The so-called blockchain forensics

Once again, I find it intriguing how CipherBlade employs terms like "Blockchain Forensics" to amplify their expertise and promote their services. In reality, their approach can be described as "Blockchain Visualization," a task that individuals with average Blockchain analysis skills and knowledge can surpass. In fact, I was able to achieve more comprehensive visualization and gather data using freely available open-source tools, which allowed me to uncover certain IP addresses and email accounts associated with the addresses involved in this series of transactions.

I will start quoting their so-called "Blockchain Forensics":

SHA-256 50bfe3cfbe…

SHA-256 a59908877a…

Once again, CipherBlade's conclusions appear contradictory. Initially, they attributed the cause of the incident to a potential malware that monitors the computer's clipboard. However, they have now shifted their explanation to a keylogger based on their analysis of ETH transactions. It is perplexing how they managed to transition from a blockchain visualization diagram to determining the characteristics of malware. It seems they may be employing some undisclosed advanced technology worthy of a NASA patent.

I'm honestly not sure how they came to that conclusion! Therefore let's raise some valid questions to CipherBlade:

• Did they provide any solid proof that links these addresses to any known malware?
  The answer is clearly NO.
• Did they provide any solid proof that these addresses belong to other victims?
  The answer is clearly NO.

Furthermore, CipherBlade attempted to support their claim by presenting a graph that they believe represents the characteristics of a "mixing" service. However, it appears that CipherBlade may lack a comprehensive understanding of how a mixing service operates. The other addresses they attribute to other victims could potentially belong to unrelated individuals, whether they are involved in criminal activities or not. These addresses might also be part of the mixer's address pool, which is used to fund the Consolidation Wallet and make the tracing process more challenging.

Each mixing service provider operates differently, with their own unique characteristics. Some mixing services are designed to make transactions harder to trace, while others may be more traceable. However, the common practice among mixing services is to fund the user's new wallet address with coins that are not associated with the mixing process itself. The mixing service assumes the risk associated with the mixing process. Below is a simple illustration taken from an existing mixing service (reference removed to avoid the accusation of promoting illegal services):

SHA-256 35bd9c3ac4…

On the other hand, when CipherBlade analyzed BTC transactions, they came to the conclusion that these transactions reflect mixing service characteristics:

SHA-256 a848174c85…

So the question arises, how can CipherBlade's analysis simultaneously characterize the entity that stole my crypto-currency assets as both malware in ETH transactions and a mixing service in BTC transactions? This apparent contradiction raises concerns about the consistency and reliability of their findings. It is important to address this inconsistency and seek a comprehensive and unbiased investigation to determine the true nature and identity of the entity responsible for the theft of my assets.

Moving to the final quote in this part:

SHA-256 3103168e48…

This statement brings a sense of amusement. The implication made is that a crypto-currency thief would choose to make a single or direct transaction to move the stolen funds, which would be remarkably foolish. It is common knowledge that any competent crypto-currency thief would seek ways to make the stolen assets untraceable. Utilizing a mixing service is a straightforward and effective option for achieving this objective.

About CipherBlade and its claims

CipherBlade is a relatively new company that commenced operations in mid-2018 and has a limited history, depending on one's perspective. On their website, they assert that they have successfully recovered millions of dollars:

SHA-256 49f4085c0c…

Despite the concerns raised later in this piece, it's important to acknowledge that CipherBlade claims to have successfully recovered millions of dollars in cryptocurrency, according to statements on their website. Such a feat, if accurate, would be a significant accomplishment in the field of digital asset recovery. However, readers should be aware that without independent verification or substantiated case details, such claims should be approached with scrutiny.

It is ironic to note that despite their claim of recovering millions of dollars, CipherBlade initially used a free email address instead of a professional business email address when they started their business. This observation is based on a screenshot taken from their website in September 2018.

SHA-256 cae315166f…

It is worth noting that the incorporation recordssaved bc9f394f of CipherBlade reveal a connection to multiple companies, with many of them being registered in Seychelles. Seychelles is often associated with offshore companies, offering a relatively easy process for company registration. It is known as a destination favored by individuals seeking to engage in money laundering (ICIJ: "Sun and Shadows"saved 1107816b), tax evasion, or hiding their true identities behind fictitious business names.

The characteristics of CipherBlade's incorporation document suggest that it shares similarities with what is commonly referred to as a shell company or virtual company. These types of entities can raise suspicions due to their lack of substantive business operations. To gain a more comprehensive understanding of the questionable nature of CipherBlade's business practices, I recommend reading the following articles for further detailed information:

The challenge

CipherBlade has challenged me to upload an image of my virtual machine for Digital Forensics analysis to determine whether my machine was infected with malware. However, considering the questionable nature of CipherBlade's business and the lack of trust I have in their operations, it would be unwise for me to share my personal data with a company that raises suspicions.

However, I appreciate the concept of the challenge and believe it should apply to both Coinomi and CipherBlade to ensure fairness and transparency in the assessment of the incident:

• An independent and reputable third-party with a proven track record and expertise in digital forensics will be engaged to conduct a thorough analysis.
• The fees for the digital forensics analysis will be deposited into a trusted escrow service to ensure transparency and fairness.
• If the results of the digital forensics analysis conclude that my machine was free of malware, then Coinomi will assume full responsibility for reimbursing my stolen cryptocurrency assets (17 BTC or its equivalent). In such case, Coinomi will also be responsible for covering the fees associated with the digital forensics analysis. However, if the analysis determines that my machine was indeed infected with malware, I will bear the responsibility for covering the fees of the digital forensics analysis.

To add an interesting twist, I have a challenge for CipherBlade. In their report, they suggested that it would be relatively straightforward to trace and recover the stolen crypto-currency assets if proper procedures were followed. In light of this, I hereby grant them full permission to undertake the recovery of my stolen assets, and I offer them a 25% bounty on any successfully recovered funds as an incentive.

At the very least, they can update their website later to proudly announce that they have successfully recovered hundreds of thousands of dollars (pun intended).

Privacy violation

CipherBlade has infringed upon my privacy by publicly disclosing my personal cryptocurrency wallet addresses without my consent. These addresses are considered private information, particularly in my case involving illegal activity, and should only be accessible to the authorities and the relevant parties involved in the case.

It is evident that CipherBlade demonstrates a lack of professionalism and, more importantly, knowledge about laws governing privacy and data breaches. As a result, I will be reporting this incident to the Information Commissioner's Office as a violation of privacy.

Final thoughts

I believe that based on the facts I have presented, it is reasonable to conclude that CipherBlade is a typical one-man show offshore company operating through a questionable chain of shell companies. Their business model appears to rely on profiting from people's losses and offering their services in cleaning up the mess created by other companies through their so-called blockchain analysis reports.

They engaged with Coinomi to benefit financially from writing the report and to gain attention by misleading the community with false information, claiming to have resolved this contentious case. However, their report has ultimately had negative consequences for them and has further damaged their reputation.

On the contrary, it is disheartening to see Coinomi facing financial repercussions for commissioning an external report that failed to support their position and did not receive any validation. It is unfortunate that they have resorted to baseless and inappropriate insinuations. Such tactics only serve to undermine their credibility further.

The four transfers of 19 February 2019

These four coin transfers and the ERC-20 tokens moved with the ETH (not itemized here) make up the loss I estimated in my first statement at about 17 BTC worth, US$60,000 to 70,000 at February 2019 prices. My Exodus wallet history shows each transfer, in local time (UTC+4). The BTC and ETH transactions were re-checked on public block explorers on 18 October 2026, and the LTC and BCH ones, from the transaction-id prefixes Exodus shows, on 30 October 2026: the ETH transfer was mined at 03:39:59 UTC, which confirms the four-hour offset, so the first transfer left at 03:30 UTC.

SHA-256 b39f6b8181…

SHA-256 dae3a74825…

SHA-256 54ad461eb7…

SHA-256 a38a54c5cb…

Exchange-linked endpoints

Exchange-linked endpoints cited in public analysis of this case:

• Binance (direct): 0xa8d100f62dab0c7ecb156cf477bdcf96ed3a80dd
• Likely EXMO (direct): 0xcefcf283bf71054ad87de4a3f92272ff1355c5d5
• Binance via intermediaries: 0x2ea4979bb1fc2e0314fadc6893c75a5986d3bc00, 0xc2c40013e24286a78ba8d8d55146727323cde1f3
• Service to Binance deposit: 0xfde0e8207f0d29a659f318ffc0fa3e3eb1b4341a to 0xe460167a64abc859869cc037caee2a3ab0ebfe70
• Service to Huobi deposit: 0xbfc8a7da31c82a8a53ca34ae7969b8fbbe6bf86d
• ERC-20 staging: 0x241eb1560fd282f06ec59c0dab913b6a9034af5a
• KuCoin deposit: 0x4da99b6038a3ea89c81b19c4b159cd382bff8ff7

Interpretation: funds moved victim, thief, consolidation, exchange infrastructure (sometimes through an intermediary). These are the points where exchanges can preserve records and help attribution (KYC, IP addresses, devices, withdrawal trails and linked accounts).

BTC and BCH

The BTC later moved on through a peel chain that touched regulated endpoints. The BCH was consolidated and was dormant when this analysis was written (August 2025).

Method and caveats

1. Open-source collection: the files on this page (timeline, screenshots, PDFs), Coinomi's statements and the JxBrowser documentation.
2. Address-centric tracing: for ETH, BTC and BCH, the victim, thief, consolidation, service and exchange addresses were compiled; ETH normal, internal and token transfers and BTC and BCH UTXO flows were extracted into flow graphs, with regulated endpoints annotated.
3. Preservation requests: exchanges that received these funds can be asked to preserve KYC records, login IPs and devices, deposit and withdrawal paths and linked accounts for the window 14 to 22 February 2019 onward.

Indicators (copyable)

Every address below has its own copy button; this copies the whole list:

The browser engine inside Coinomi carries the exact request

Coinomi Desktop 1.0.4 bundles JxBrowser 6.22.1 by TeamDev, a Chromium browser for Java programs; the library's license file in the installer names "Coinomi Ltd." as the licensee. browsercore64.exe, the process in figure 1, is that engine. Its main file, browsercore64.dll (Chrome 64.0.3282.24, SHA-256 d40eadb743051edad32a27557d77ef3b0c7be3eee828a7a8fd8fbc21f8340e33), contains these texts, the same ones figure 1 shows going out:

What Chromium's own code says the feature does

The same request is written in Chromium's source code for that exact version, 64.0.3282.24 (spelling_service_client.ccsaved 7c67987f), next to Google's own description of it:

"Chromium can provide smarter spell-checking, by sending the text that the users type into the browser, to Google's servers. ... If the feature is enabled, Chromium will send the entire contents of text fields as user types them to Google, along with the browser's default language." ... "The feature is disabled by default."

Chromium source code, tag 64.0.3282.24

In Google Chrome this online spelling service stays off unless the user turns on "Use a web service to help resolve spelling errors" (the setting kSpellCheckUseSpellingService is registered as false in spellcheck_factory.ccsaved daa68e8e). Coinomi's wallet has no such setting and never asked. dummytoken is the placeholder Chromium uses when it is built without Google API keys (google_api_keys.ccsaved 15b4d15c: #define DUMMY_API_TOKEN "dummytoken"), so Google's keyInvalid answer came after the request, with the words in it, had reached Google.

Coinomi's own code never switched it off

The wallet's screens are a web application written by Coinomi and packed in the installer (ui/static/js/app.667c2ad68355c1d62a0e.js, SHA-256 4cab18d18a4303b0b341f5a0c85104109839314301583fd2d70890c7b88b1946). It builds the Restore wallet box as a plain text area that holds a variable called seed:

s("textarea",{directives:[{name:"model",rawName:"v-model",value:e.seed,expression:"seed"},{name:"focus",rawName:"v-focus"}],class:{invalid:e.invalid},domProps:{value:e.seed}, ...

It never sets spellcheck="false", the HTML attribute that tells a browser engine not to spell-check a field; the word does not occur in that file. A second recovery-phrase box, shown after Forgot password? ("Type your recovery phrase here"), is built the same way. Of the 6,516 compiled program files in the wallet, none outside JxBrowser mentions spell checking (JxBrowser's own files do, 20 times, which shows the search finds it where it exists), and none sets the switch JxBrowser later added to stop Google traffic. The signed installer contains the same program: apart from its signature files, every file matches the unsigned one.

The second box was not tested in 2019; the code shows only that it is built the same way as the first.

The "fix by the JxBrowser team"

Coinomi wrote that the plug-in "enabled the spell-check functionality by default in a recent update and was fixed by the jxBrowser plug-in team just 6 days ago". The record says otherwise on both points:

• Spell checking on by default was not new. JxBrowser's support article "Configuring Spell Checker", "Modified on: Mon, 29 Feb, 2016", already said "By default spell checker is enable" (my 2019 screenshot of it: coinomi_quote_4.pngSHA-256 9fc4452ccd…), and its guide for version 6saved 5e8c7c65, the version Coinomi shipped, says: "By default spell checker is enable and configured to use English (en-US) language. Chromium engine checks text in all text fields and text areas on the loaded web page". The same guide shows the call that switches it off.
• Coinomi says the fix came "just 6 days ago" and also "the same day we were contacted by Warith Al Maawali", which its own timeline gives as 22 February 2019; The Block was told "patched immediately on Feb. 22". The only JxBrowser release that week was JxBrowser 6.23saved f4b464c0, on 21 February 2019, and it changed no default. It added an option the application itself has to set: "To disable Google traffic to these servers, please set the --disable-google-traffic Chromium switcher before creating the first Browser instance in your application." Its list of servers names the dictionary download seen in figure 1 (redirector.gvt1.com).

Either way, switching spell checking off in the restore box was in Coinomi's hands, in Coinomi's code, before I typed my phrase.

What Coinomi itself admitted

From Coinomi's official statement of 27 February 2019 (archived copySHA-256 32fff7e192…, original on Mediumsaved 4702b00f):

• "Our engineers confirmed that spell-check functionality was indeed enabled for the Desktop wallets only".
• The plug-in "was fixed by the jxBrowser plug-in team just 6 days ago", on "the same day we were contacted by Warith Al Maawali", which the statement dates "22 Feb 2019"; Coinomi told The Blocksaved 95da3eba it was "patched immediately on Feb. 22". I typed my phrase on 14 February, a week earlier.
• "If you are using Coinomi Desktops and you restored an existing wallet into your Desktop wallet we recommend that you create a new wallet and move your funds there". In other words, Coinomi advised treating such a phrase as exposed.
• "under no circumstances a seed phrase should go online even if this is in encrypted mode and for this we sincerely apologize."

The same statement says the requests "were not processed, cached or stored", and: "We have been successfully securing your blockchain assets since 2014". By the account Coinomi's CEO later gave the High Court, cryptocurrency had been stolen in June 2018 (chapter 08).

About HTTPS decryption in my video

In 2019 Cointelegraphsaved a53afb9c wrote that my video "appears to show that the option to decrypt HTTPS is selected in the software". It was: Fiddler has to decrypt HTTPS on my test machine for the request to be readable at all. Decryption changes what an observer can see, not what the program sends. The request comes from the Chromium spelling code shown above, which sends it whether or not anyone is watching.

A former Coinomi developer's private messages

In February 2019 someone who had worked on Coinomi's code contacted me privately. At first he doubted my claim. After reading my analysis he wrote the first message below, and in December 2022 the other two. These are excerpts from a private conversation: his name is withheld, one word is blurred, and nothing else is changed. The full, unaltered originals are kept off this website and can be given to a court; their SHA-256 hashes are listed under private originals.

SHA-256 ec95be37c6…

SHA-256 647a0d9c51…

SHA-256 d43b8a26c8…

The same weakness, found again elsewhere

• 2017, Coinomi again. The 2017 Coinomi flaw Luke Childs reported on GitHub (see Coinomi's response in chapter 03) now has an official record, which cites that GitHub issue: CVE-2017-20200saved d8a87d28, published 23 September 2025, "cleartext transmission of sensitive information" in Coinomi up to version 1.7.6. The record quotes Coinomi's reply: "there isn't any security implication associated with your findings."
• 2022, "spell-jacking". Researchers at otto-js showed that the enhanced spell check of Chrome and Edge sent form fields, sometimes passwords, to Google and Microsoft. Google answered that the feature "requires an opt-in from the user" (BleepingComputersaved cafbc40d, 17 Sep 2022). Coinomi Desktop asked for no opt-in, and the researchers' advice to websites was the same one-attribute change: spellcheck="false".
• 2022, "Demonic", CVE-2022-32969. Halbornsaved 51ba51e6 showed that browsers save the contents of non-password fields to disk, which "can cause the secret recovery phrase to be stored on disk in plain text" in wallets such as MetaMask. A different path, the same lesson: a browser feature that a wallet does not switch off can leak the recovery phrase.

The founders' case in the English courts

Coinomi Ltd, the UK company, was owned in equal halves by Georgios (George) Kimionis, Coinomi's CEO in 2019, and Giannis Ntzegkoutanis (spelled Jegutanis on Coinomi's own website). In 2022 Mr Ntzegkoutanis petitioned the High Court (claim CR-2022-001219) against Mr Kimionis, Coinomi Ltd, Coinomi Holdings Ltd (Cyprus) and Coinomi Ltd (British Virgin Islands). He alleges that Coinomi's business and assets were moved to the Cyprus and BVI companies "for no consideration", and, in the judgment's summary of his case, that "the respondent has retained, directly or indirectly, Coinomi’s cryptocurrency which, in April 2022, may have been worth £3.5 million, and he may have retained further cryptocurrency, with a value of £1.4 million in April 2022, which he (the respondent) claims was stolen in June 2018" (High Court judgment, paragraph 15). Mr Kimionis's answer, in the same summary: "At the time when Coinomi was dissolved, it owned minimal cryptocurrency" (paragraph 26). These are the two sides' allegations; the court has not decided them. Mr Kimionis denies the transfer allegation; his case is that "the Coinomi business never belonged to [the Company]" but to him and then to his BVI company, Dollzen Ltd.

• 21 Dec 2022, High Court, [2022] EWHC 3178 (Ch)saved 0ca66534: the petition's claims for compensation and for a constructive trust in favour of the company "are struck out as against the respondent".
• 12 Dec 2023, Court of Appeal, [2023] EWCA Civ 1480saved 62303d4c: "I would allow the appeal and dismiss the application for paragraphs 32.2 and 32.3 of the petition to be struck out." The judgment says "it appears to be common ground that" "On 12 December 2018, Coinomi Cyprus applied to register the 'Coinomi' trademark with the U.S. Patent and Trademark Office", that "On 20 December 2018, Mr Kimionis gave instructions for ownership of the 'coinomi.com' domain name to be transferred to Coinomi Cyprus", that by the end of January 2020 the intellectual property in the app's source code had been transferred to Coinomi Cyprus, and that "Mr Kimionis is the ultimate beneficial owner of Coinomi Cyprus and Coinomi BVI". The barristers' chambers for each side published notes (Serle Courtsaved 955a209a for the appellant, 33 Chamberssaved dc82ff7e for the respondents).
• No later judgment is published. Whether the case went to trial, settled or was dropped is not public.

Cryptocurrency stolen in June 2018

In the High Court judgment of 21 December 2022, Mr Ntzegkoutanis's petition says that Mr Kimionis "may have retained further cryptocurrency, with a value of £1.4 million in April 2022, which he (the respondent) claims was stolen in June 2018" (paragraph 15). Mr Kimionis's own case, as the judge summarised it: "although cryptocurrency was stolen in June 2018, most belonged to Dollzen, and the respondent was unable to track down the stolen currency" (paragraph 26).

On ownership: Dollzen Ltd, the company his case says most of that cryptocurrency belonged to, is his BVI company, which he says owned the Coinomi business at the time. The court did not decide who owned the cryptocurrency, how it was stolen or who was responsible.

The UK company

Companies House, Coinomi Ltd, company 10451885saved 755a1fa5:

• 28 Oct 2016: incorporated.
• 19 Oct 2018: the register records the end of Mr Ntzegkoutanis's directorship (filed 31 Oct 2018); the Court of Appeal notes "There is a dispute as to whether Mr Ntzegkoutanis is still a director."
• 7 Jul 2020: its last accounts are filed, for the year to 31 October 2019.
• 13 Oct 2020: dissolved. 23 Mar 2022: restored by order of the court (registered 28 Mar). 24 Mar 2026: dissolved again.

Who runs Coinomi now

On 1 October 2024 Coinomi's own Reddit account announced "Coinomi is BACK on Android! ... After two years of overcoming hurdles, we are excited to announce our return". Coinomi's website now lists Giannis Jegutanis as "Founder, Coinomi" on its Ventures teamsaved cff6b5b2, and team member Koby Lazarsaved 0339e72c writes: "In 2024, I partnered with Giannis to restore Coinomi's legacy." Of the 20 newest English-language 1-star reviews on Trustpilotsaved bc9904ad on 30 October 2026 (the site's default view at that address), eleven, posted between September 2023 and May 2024, carry the same reply from Coinomi, all dated 8 July 2024: "Coinomi is currently under new management and undergoing a complete revamp." What this page says about Coinomi's conduct in 2019 concerns the company as it was run then.

CipherBlade's company records

Companies House, CipherBlade Ltd, company 11539349saved c052d7c3 (the record linked in chapter 05): incorporated 28 August 2018 and owned at first by five Seychelles companies; from 5 June 2019 until September 2023 it declared that it had no registrable person with significant control; its first accounts, filed 24 February 2020, are "Accounts for a dormant company made up to 31 August 2019", a period that includes its 2019 report on my case; dissolved 29 October 2024. I have not established which CipherBlade company wrote that report. In October 2023 CipherBlade, LLC of Pennsylvania sued a CipherBlade company in Alaska and several former partners (case 3:23-cv-00238saved 4f3ea7bf), alleging that they took over its business; those are allegations, and the outcome is not public.

2019: a trademark used to ask my host to take this case file down

The April 2019 complaint to my host (takedown attempt) relied on the US trademark "COINOMI", application 88228678saved 5b5166a0. The USPTO record shows it was filed on 13 December 2018 (by Coinomi Holdings Ltd, the Cyprus company, according to the Court of Appeal), received a non-final office action on 12 March 2019, and was registered only on 10 September 2019. In April 2019 it was a pending application, not a registered mark. The record now names LOKSIAS SA of Geneva as the owner.

2026: three abuse reports to my host

In 2026 my hosting company, Hetzner, forwarded three abuse reports against this case file, each asking for it to be taken down. None named a login form, a recovery-phrase field, a wallet-connect prompt or any other phishing mechanism, and this page has none: it has no form and asks visitors for nothing. Its only software files are the two 2019 Coinomi installers, kept as evidence with a warning. I answered each report, and the site stayed online.

What the scan claimed

The report said the installer contained "confirmed backdoors": 1,565 references to port 31337, 1,514 to port 6666, 1,496 to port 8888 and 1,507 to port 8080, each "near valid IP addresses", and called this "intentional malicious design".

The control test

The installer (coinomi-wallet-1.0.4-win64_UNSIGNED.exe, 98,081,120 bytes, SHA-256 3d95bab665e65914ef1962e611c54c9d62bd6ace3514dee4a0a775f7fcfe7482) measures as almost perfectly random: 7.9999 bits of entropy per byte, zlib shrinks it by only 0.13%, and 1,493 of its 1,497 blocks of 64 KiB look random, as compressed data does. In random data every two-byte value turns up about once in 65,536 positions, so each one is expected here about 1,497 times. Counting each number as a two-byte value across the file gives the report's four numbers exactly, and numbers nobody calls a backdoor turn up just as often:

The text "31337" does not appear anywhere in the file. The "IP addresses" next to each hit are just the four neighbouring bytes read as an address.

Test run on the server copy of the file on 18 October 2026: count of each number as a big-endian two-byte sequence (little-endian counts, 1,424 to 1,577, and the plain-text search gave the same picture), Shannon entropy over the whole file and over each 64 KiB block, and zlib level 6.

Original disclaimer

The AI report was published with this notice, which still applies to anything quoted from it: the analysis was generated by an artificial intelligence system from the unsigned installer, the wallet addresses and a request for a comprehensive analysis; it is supplementary information, not proof; for official investigation and forensic analysis, refer to qualified cybersecurity professionals and law enforcement.

Allegations of coordinated discrediting

Following the public disclosure of the vulnerability, a coordinated effort appeared to unfold, aimed at discrediting not only my name but also the accounts of other users who shared similar experiences. There is a strong indication that individuals, often referred to as "shills" or paid promoters, were employed to attack the credibility of anyone who made their complaint public. This section archives numerous reports from different users who have faced similar issues with Coinomi, suggesting a broader pattern of user fund losses and subsequent suppression of complaints.

An account that repeatedly defended Coinomi and attacked critics

Nine posts by @aseiberg66 between 1 May and 10 June 2019, and archived screenshots of that account's posts from April and May 2019:

• @aseiberg661 May 2019saved ca3265c5
• @aseiberg661 May 2019saved c7b49725
• @aseiberg6629 May 2019saved fdeb8ae7
• @aseiberg6629 May 2019saved 95bc9cf9
• @aseiberg6629 May 2019saved 42e1387a
• @aseiberg6630 May 2019saved a5bfd0d7
• @aseiberg6630 May 2019saved d1910605
• @aseiberg6610 Jun 2019saved f2dc470f
• @aseiberg6610 Jun 2019saved ac9a8b48

SHA-256 70cf349426…

SHA-256 a9fd33e952…

SHA-256 0e32a14142…

SHA-256 138c03845a…

Complaints and loss reports on X

The @avoid_coinominot saved account keeps a longer thread of these and related incidents.

Reported incidents on forums and review sites

Copies of every page this case cites

Web pages change and disappear: 15 of the 47 posts on X cited here are no longer public (4 deleted, 11 from suspended or protected accounts, as X's embed service answered on 30 October 2026). On 30 October 2026 every external page this case file cites, and every source added that day, was captured where the site allowed it: as a screenshot (PNG), a printed copy (PDF, with the address and the time of capture in its header) and the page's HTML source, or, for data services, as the raw response. Where a site refused an automated browser, the copy comes from X's public embed page or from the Wayback Machine. 25 of the 160 could not be saved at all, and the table says which and why.

Copies of public records (court judgments, company and trademark registers, vulnerability records), open-source code, the blocklists and the user posts this case cites are published here; HTML is published as text, so none of its scripts can run on this site. Copies of news articles, blogs and company pages are protected by copyright, so they are held off this website like the private originals below: their SHA-256 hashes are listed in the table and in held-copies-SHA256SUMS-2026-10-30b.txtSHA-256 5b91520f83…, and the files can be provided on request. The log of the capture runs, with the address, HTTP status and hash of every file, is captures-manifest-2026-10-30b.jsonlSHA-256 71510bae20….

Private originals, held but not published

The message excerpts in chapter 07 and chapter 02 come from private conversations. The full originals are not published, to protect the other people in them. They are kept unaltered off this website and can be given to a court. Their SHA-256 hashes, published here on 30 October 2026, prove that any later copy is the same file.

Proof of date

SHA256SUMS.txt lists the SHA-256 of every file in this archive: the evidence files, the 2026 analysis, the published copies of cited pages, the hash lists of the held copies and private originals, and a copy of this page as published on the afternoon of 30 October 2026. That list is timestamped with OpenTimestampssaved e2518d27 (SHA256SUMS.txt.ots): the timestamp is anchored in the Bitcoin blockchain within hours of publication, and from then on it proves that the list, and so every file in it, existed on 30 October 2026 and has not changed since. The copy of this page in the list is published as text (page-2026-10-30b.html.txt). To check, download both files and run ots verify SHA256SUMS.txt.ots, or drop them on opentimestamps.org. SHA256SUMS.txt and the copy of this page show no hash beside their links, because a file cannot contain its own hash, and no timestamp file does, because it changes when Bitcoin confirms it. Earlier lists stay published under their date, and no file they name is ever changed or removed: SHA256SUMS-2026-10-18.txtSHA-256 3283ce2da7… (18 October 2026) and SHA256SUMS-2026-10-30a.txtSHA-256 ae9eb162c3… with its own timestamp SHA256SUMS-2026-10-30a.txt.ots, the list of the first upload of 30 October 2026, published that morning as SHA256SUMS.txt (its files include the morning copy of this page, page-2026-10-30.html.txtSHA-256 0b6309fd57…). Every entry of the morning list is in the current list with the same hash, so a change to the archive cannot hide.