What the COLDCARD Entropy Failure Teaches Malaysian Merchants About Wallet Security
- What Actually Happened
- Separate Payment Operations from Treasury Custody
- What BTCPay Server Does and Does Not Remove
- A Practical Merchant Security Policy
- Getting Started at Bitcoin House Malaysia
Update — August 6, 2026
Since this article was published, the wallet-security discussion has expanded beyond COLDCARD.
Bitkey stated that its wallets were not affected by the COLDCARD entropy failure because Bitkey does not use the affected firmware or random-number generator, and because its wallet uses three keys generated across separate environments. Bitkey also introduced a temporary 15% discount and covered shipping costs for customers seeking alternative hardware.
However, Bitkey subsequently disclosed a separate bug in its Recovery Contact and inheritance-enrollment process. The issue involved a non-cryptographic random-number generator used for a one-time relationship-enrollment secret. Bitkey stated that the bug did not weaken its wallet spending keys, that there was no evidence of customer exploitation, and that exploitation would require highly unusual access to its service infrastructure. A patch has been submitted to app stores.
This update reinforces the central lesson of the original article: wallet security should not be reduced to choosing a supposedly flawless product. Merchants should evaluate how keys are generated, how risks are distributed, how recovery systems work, and how vendors respond when vulnerabilities are discovered.
*Continue reading: [After COLDCARD: What Bitkey’s Response and Its Own Bug Teach Us About Wallet Security]
Bitcoin House Malaysia — Merchant Education Series
What Actually Happened
Coinkite published a security advisory on July 30, 2026, warning that seeds generated on affected COLDCARD firmware may contain substantially less randomness than intended.
The problem was introduced during a firmware integration in March 2021. The affected seed-generation path used a software pseudo-random number generator instead of correctly reaching the intended hardware random-number generator. Specific firmware versions across the COLDCARD Mk2, Mk3, Mk4, Mk5, and Q product lines were affected.
As of August 4, Galaxy Research estimated that more than 1,500 BTC, worth over $100 million at the time, had been compromised across multiple suspected attack waves. That figure remains an investigative estimate rather than a final confirmed total.
This was not a failure of Bitcoin or the Lightning Network. Blocks continued to be produced, transactions continued to confirm, and Lightning payments continued to operate. The failure happened inside one product’s key-generation implementation.
Coinkite has released corrected firmware, but installing an update does not repair a seed already generated by vulnerable firmware. Coinkite’s guidance for potentially affected users is to generate a completely new seed using fixed firmware, verify the backup and receiving address, send a small test transaction, and only then migrate the remaining funds.
Coinkite states that seeds created with at least 50 fair, independent, private and unexposed dice rolls are not considered at risk from this RNG issue alone. Users who do not remember how many rolls they entered, or whether the rolls remained private, should follow the official migration guidance.
Separate Payment Operations from Treasury Custody
A merchant should not manage every bitcoin balance in the same wallet.
Think about a physical business. You keep a limited amount of cash in the register for daily transactions. You do not keep the entire company reserve inside the cashier drawer. Bitcoin operations should follow the same principle.
An operating wallet handles incoming payments, refunds, and limited day-to-day amounts. It needs to be convenient and available to staff responsible for payment operations.
A treasury wallet holds funds the business does not expect to spend during normal operations. It requires stricter access controls, tested backups, and a clear recovery plan.
The two wallets should not share the same seed or routine spending permissions. Where practical, they should also use separate devices or custody arrangements so that a failure in the operating wallet does not automatically expose the treasury.
What BTCPay Server Does and Does Not Remove
For merchants who need more control over payment infrastructure, BTCPay Server offers a self-hosted model with no processing percentage. Successful Lightning payments can settle quickly, and self-hosting reduces dependence on conventional payment processors.
But no processing fee does not mean zero cost. A production deployment may still require a VPS, domain, Bitcoin or Lightning node maintenance, channel liquidity, backups, security monitoring, staff training, customer education and support, accounting records, and exchange or withdrawal costs when converting to ringgit. Merchants also remain exposed to Bitcoin price volatility while funds are held before conversion.
A Practical Merchant Security Policy
Before accepting meaningful Bitcoin payments, a merchant should define a simple wallet policy.
Set an operating-balance limit
Decide how much bitcoin may remain in the daily payment wallet. The limit should reflect normal payment and refund needs, not the maximum amount the wallet can technically hold. When the operating wallet exceeds that limit, move excess funds to a separate treasury arrangement or convert to ringgit.
Define who can spend
A cashier may need to confirm incoming payments, but that does not mean every staff member should be able to send funds or change recovery settings. Separate payment confirmation from outgoing-payment authority wherever possible.
Test recovery before relying on it
Writing down a backup is not the same as proving it works. Test the recovery process with a small amount first. Confirm that wallet addresses and balances match before placing meaningful funds at risk.
Prepare for service failure
If a payment wallet, Lightning service, or hosting provider becomes temporarily unavailable, the merchant should know whether customers can use an alternative payment method and how existing funds can be recovered. No merchant payment system should depend on a single tool without a fallback plan.
Getting Started at Bitcoin House Malaysia
Bitcoin House Malaysia merchant setup sessions use small test payments to demonstrate how Bitcoin payment tools work in practice.
In our sessions, participants start with a hands-on Lightning payment experience using YakiHonne, a Nostr-based social and payment application that combines a decentralized identity layer with an integrated Lightning wallet. It is a low-friction way to send and receive a first Bitcoin payment, understand how invoices work, and see how Nostr-based communication and Bitcoin payments can exist within the same application. From there, sessions move into the broader questions: how custody and recovery work, how much value should remain in an operating wallet, when funds should move to a separate treasury arrangement, and how conversion to ringgit affects fees, accounting, and cash flow.
More advanced sessions introduce BTCPay Server, self-hosting, Lightning liquidity, wallet backups, staff permissions, accounting workflows, and incident-response planning.
The goal is not to present any single wallet or hardware device as the answer for every business. The goal is to help merchants understand which tool fits each job, test it with a small amount, and build a payment process that can recover when something goes wrong.
Key Takeaway: The COLDCARD failure shows that self-custody risk starts at key generation, not just key storage.
This article is for education only and should not be treated as tax, legal, or financial advice. Merchants should consult qualified professionals before accepting Bitcoin as part of their business operations.
#Bitcoin #Malaysia #Payments #Lightning #BTCPay
Write a comment