XChain
Learn Understand Overview How it works Use cases Why XChain Look things up FAQ Glossary Try it Get started The wallet The explorer
Developers For developers The SDK Actions Components Testing White paper GitHub
Run
Platform Main site Wallet Explorer Documentation Encoder status Bootstraps & sync Validator hub MCP for agents

Security and release signing

Every XChain Wallet release is published with a signed manifest of hashes, so you can check that the file you downloaded is the file we built. This page publishes the key that signs it, and it is one of two independent places that key is published.

The release signing key

PGP fingerprint: 1A29E7C4C228F0E55D40A8C3B5B0E5ADAFDA7CE7

The key is XChain Wallet Release Signing <releases@dankest.llc>, an ed25519 key created on 2026-08-06 and expiring on 2028-08-05. Its primary half is certify-only and kept offline; the subkey that actually signs a release manifest is 27A1593607C828903EF67DAD10ADF79899B41573.

One XChain Wallet release has been signed with this key: version 0.336.0, published on 6 August 2026, and it covers Android only. The Android .apk is on our download page, and the signed manifest describing it is at https://downloads.xchain.io/wallet/RELEASE_HASHES/v0.336.0.txt with its signature in the same folder.

That manifest says in its own signed header that its coverage is partial, and names Android as the lane it covers. So read it for what it is: full proof for the file it lists, and no statement at all about anything else. No desktop, extension or iOS release has been signed or published yet, so any file offered to you as one of those is not a release of ours. There are no official installers and no update feed contents for those platforms in circulation.

One channel today, and what that means for you

Right now this page is the only place you can read the fingerprint. That is worth saying plainly rather than leaving you to discover it: a fingerprint is only as trustworthy as your ability to check it against a copy the attacker did not control, and today there is no second copy for you to check against.

The intended design is two channels on separate hosts with separate deployment paths, so that someone who could quietly change one could not quietly change both. The second one is not published yet. Until it is, treat this page as a single point of trust and weigh it accordingly.

When the second channel exists, this section will name it and tell you what to do if the two ever disagree. We would rather tell you there is one than point you at a second copy you cannot actually reach.

Three different keys, and how to tell them apart

More than one key is involved in shipping XChain, and confusing them is an easy mistake to make. They do different jobs and are not interchangeable:

  • The release signing key is the one on this page. It signs the hash manifest that says "these exact bytes are the release". It is the only one you need in order to verify a download.
  • The tag signing key signs the git tag each release is cut from, which says "this tag was cut by the maintainer". Its public half is committed in the wallet repository at tools/release/tag-signing-key.asc, and its fingerprint is 64926B64D5A96D16BB07F1B3E71BA4EAA162AACC. It is checked by our own release pipeline; it does not verify a downloaded artifact.
  • An older releases@xchain.io key appears in some platform documentation. It is not the wallet release signing key and must not be used in its place.

If a document says "the release key" without saying which one, take the fingerprint as the answer and not the name.

Verifying a download

Verifying a release is a short recipe: download the artifact, download the signed hash manifest published beside it, check the manifest's signature against the fingerprint above, then check that your file's hash appears in the manifest. Doing them in that order matters, because a hash that matches an unverified manifest proves nothing at all.

The full recipe, including what the manifest does and does not prove for builds delivered by an app store rather than downloaded directly, is written out in Verify a release. If you want to go further and rebuild an artifact yourself to confirm our bytes are the ones the published source produces, see Reproducible builds.

Reporting a vulnerability

Report privately first, and give us the chance to ship a fix before the details are public. Vulnerabilities in a self-custodial wallet put real funds at risk, and a disclosure that lands before a patch exists puts them at risk faster.

Email security@dankest.llc. Include a description of the issue and the threat it poses, reproduction steps or a proof-of-concept, the wallet version and which shell you tested against (extension, web or desktop), and any mitigation you would like considered. We acknowledge within 72 hours and triage within 7 days.

For sensitive reports you can encrypt to the key whose fingerprint is published at the top of this page. If you would rather make first contact before sending anything sensitive, say so and we will arrange an encrypted exchange first.

For anything that is not a vulnerability, the wallet support page lists the ordinary channels.

What we will never ask you for

Nobody from XChain will ever ask for your seed phrase, your private key, or your wallet password. Not to verify you, not to restore anything, not to investigate a report you sent us. There are no exceptions, so any message that asks is not from us however convincing it looks. A security report never needs any of them, and one that arrives containing them will be deleted rather than answered.