Documenting the Xelis Proofs Exploit and the Potential Core Team Fraud
Why would the Xelis team cover up a proofs bug unless they exploited it themselves?
Xelis is an implementation of the Dero Homomorphic Encryption Blockchain Protocol (DHEBP) in Rust. The founder of Xelis is a former Dero community developer that goes by the monicker Slixe.
Xelis was officially launched in April 2024. On New Year Eve 2025 however, something happened that strongly indicates the chain is corrupt and forever beyond repair.
The Xelis Emergency Hardfork Announcement
On December 30th, Slixe posts a long announcement on Discord stating that a hardfork will have to take place before 2025 which, among others, will patch a security bug.
This announcement is highly suspicious for many reasons. First and foremost because the security patch is sandwiched between some feature updates, despite the fact that a bounty had been claimed. And second, because in the announcement they explain how the source code wouldn’t be updated but instead users would have to download precompiled binaries. This only means one thing, they did not want people to inspect the source code to look for differences that would indicate what the vulnerability was about. Also, nothing is explained about the bug other than that it’s a critical security vulnerability.
The Four Week Long Radio Silence
Personally, I had written off Slixe as a malicious actor long ago. I did it when I received proof that Slixe had been promoting Xelis among Dero holders by divulging fake news about Dero’s core team Captain (which is reportedly working on a Quantum Resistance upgrade, among others). In early January 2025 however, despite his refusal to elaborate on the patched critical bug right away, many still gave Slixe the benefit of the doubt on the bug debacle. The timing played in Slixe’s favor too, since everyone was fresh out of the New Year Festivities with a low propensity to carefully read, let alone inspect, his announcement for red flags. Slixe’s refusal to release a full bug report is something I, on the other hand, started calling out right away. The 6th of January I wrote a Telegram post where I explained that Slixe’s refusal to issue a full bug report meant only one thing, that this bug was about proofs. You can find my Telegram post in my channel here. The reasoning is simple, in privacy coins a proofs bug is practically unpatchable unless one can prove that it wasn’t exploited. Because once someone mints new coins by exploiting flawed commitments, they can use the inherent privacy of the chain to go undetected. We saw this happen with Haven recently. Haven’s supply, calculated based on chain’s age and block rewards, was supposed to be around 35M coins in February 2024, only to find out that at least 500M excess coins had been minted in a proofs exploit. This is why the only reason for a privacy chain dev to hesitate to disclose the nature of a critical bug is if the bug involved proofs. For 4 weeks Slixe refused to disclose any details about the bug, and he also refused to update the source code.
The Bug Post Mortem
Finally, on January 24th, a Post-Mortem blog post is released. Unfortunately however, despite the promising title, there is only one short paragraph dedicated to the bug. You can find the full blog post here, but below I will quote the only paragraph that addresses the critical bug:
1.) zK Proof Improvement (Bug Bounty Identified)
Improve verification by ensuring the handle of each source commitment is correctly built as we do for the receiver, preventing someone to brick its account or do any additional damage.
While calling this a post mortem is criminal, this paragraph does confirm that the security patch was indeed about proofs. Why this matters is that it confirms the worst case scenario, which is that Xelis had a bug in its proofs. Proofs, in a privacy coin, make sure that an account cannot spend more coins than it has. Bulletproofs make sure that at the end of a transaction the involved accounts have valid balances. Bulletproofs normally do these checks without inspecting the unencrypted accounts, they do this in the blind and for that reason they are called zero knowledge proofs. In this incomplete post mortem, Xelis devs do admit that there was an issue with the sender commitments. And that sounds a lot like a bulletproofs bug. Issues with sender commitments means there was an issue with the process that verifies that sender balances are conform to protocol rules. In other words, senders could probably send more coins than they had without getting caught. Their wording is also worryingly vague, brick an account or do any additional damage. Brick an account how? By creating a negative balance? Do additional damage how, by creating new coins?
Conclusion
Ever since the third and final act of this emergency hardfork was performed, I’ve been actively calling on Xelis developers to release proof that their zk proofs bug wasn’t exploited. My Twitter account was permanently suspended for no valid reason only two days after I pointed out that Slixe, the founder of Xelis, was going to Guantanamo faster than Bin Laden if any whale from New York had fallen for his scam. I’ve also been calling on Xelis users to request a supply audit.
Considering that Xelis at some point pumped as high as $40 per coin, if this zero knowledge proofs bug was planted and exploited by the Xelis team itself, then this would have been the perfect scam. And an extremely profitable scam, which would explain the fast pace at which Xelis expanded by buying influencers and listings. Because, where did all the money come from? It probably came from all the millions of coins that the core team sold at the pico top in the first weeks after launch when sell pressure was non existent (because everyone had just started to mine it).
How To Press Charges Against Slixe (If Needed)
Xelis miners and users should know that the Xelis team is much less anonymous than it seems. Slixe, the founder of Xelis, is confirmed to have attended Nonsensus which was held from October 31st through November 2nd 2023 at Wild Horse Pass Casino in Phoenix, AZ. This is another piece of information I had tweeted just before my account was permanently suspended without any valid reason. If, after a supply audit, it comes out that someone exploited this bug from day 1 then that strongly indicates that the Xelis team itself exploited the bug and you might want to consider taking legal action. Xelis’s team behavior strongly indicates this as well, because if this bug was exploited by an outsider then they would be the first to shut down the project like Haven did. Why else would they keep working on a chain where 99% of the supply is likely in the hands of an outsider? Their stubborn cover up strongly indicates they themselves exploited the bug to enrich themselves at the expense of all the credulous people that fell for their grift.