ShopSend a private security report to [email protected]. Start with a cleartext email containing your public PGP key if the report includes exploit details, private code, device identifiers, or other sensitive material. Wait for Coinkite's encrypted reply before sending the full report.
The canonical policy is Coinkite Responsible Disclosure. That page controls if this summary and the policy ever differ.
Before you send a report
Coinkite asks researchers to provide a reasonable period for investigation and repair before publishing. Make a good-faith effort not to leak or destroy Coinkite user data, and do not defraud Coinkite or its users while testing.
Keep the report private until a disclosure date has been coordinated. Do not place an exploit, private test result, customer information, seed phrase, PIN, passphrase, private key, wallet backup, descriptor, XPUB, or funded transaction file in a public issue tracker.
If you are unsure whether a test is safe or within scope, email [email protected] before running it.
What to include
Coinkite's policy asks for a proof of concept, a detailed description, the potential impact, and your attribution preference. A report is faster to reproduce when it contains:
- affected product and hardware revision;
- firmware version, release channel, and download source;
- exact preconditions and attacker access required;
- numbered reproduction steps and the observed result;
- a minimal proof of concept, logs, or code needed to reproduce;
- expected behavior and why the observed result crosses a security boundary;
- impact on private keys, signing authorization, PIN protection, recovery, or device integrity;
- whether user data, a real wallet, or physical hardware was touched;
- your name and public link for credit, or a request to remain anonymous.
Use a disposable seed and an unfunded or controlled test wallet whenever the issue permits. Remove personal data and secrets that are not required to reproduce the result.
Reports Coinkite wants
The responsible-disclosure policy names these examples:
- leakage of private-key material;
- making hardware sign a transaction the owner did not authorize;
- misleading a user into approving a transaction against the user's interests;
- bypassing the PIN sequence or a similar access control;
- remote code execution on a Coinkite product.
A theoretical attack class is not enough by itself. Show that the issue applies to a Coinkite product and provide a working demonstration when that can be done safely.
Reports normally outside scope
The current policy says these reports are generally not interesting unless they lead to a hardware-product vulnerability:
- ordinary website findings on Coinkite properties or third-party services;
- denial-of-service attacks;
- spam;
- forged email headers;
- DMARC configuration;
- clickjacking;
- vulnerabilities confined to third-party applications or sites;
- broad scanner output or possible attack classes without proof that they affect a Coinkite product.
Read the canonical policy before testing. Scope can change, and unusual findings should be discussed privately rather than forced into a category.
Use PGP for sensitive details
Email [email protected] with a short cleartext introduction and your public PGP key. Coinkite asks researchers to begin this way and says it will reply so the technical report can continue over encrypted email.
The first message can contain:
- your name or chosen handle;
- the affected product;
- a one-sentence impact summary that does not reveal the exploit;
- your public PGP key or fingerprint;
- a request for the correct encrypted next step.
Do not assume that an ordinary support form, Telegram group, X direct message, GitHub issue, or public pull request is an appropriate channel for an undisclosed vulnerability.
Response and rewards
Coinkite says it will analyze a private disclosure and respond promptly. The policy does not publish a fixed first-response deadline or remediation deadline. The disclosure date is chosen after the impact and fix path are understood.
A qualifying security bug may receive a Bitcoin bounty at Coinkite's discretion. No fixed reward table is published. Accepted researchers may also receive public credit, if wanted, a personalized Bugmug, and replacement Coinkite hardware destroyed during legitimate research.
Researchers from competitors and well-funded labs may submit reports. Coinkite asks for clear coordination in those cases and says it does not pay bounties for those submissions.
Ready to report?
Send the initial private message to Coinkite Security and link the canonical policy in your notes.
Sources and verification
Verified on July 17, 2026. The canonical Coinkite policy states that it was updated in March 2026.