distributed · policy-enforced · multisig HSM
An exchange keeps a few percent of funds hot. The rest sits in cold storage — until it moves to top the hot wallet back up. That refill is the largest, least-automated transaction your business makes, and today it runs on one of two shaky foundations: a manual signing ceremony, or a custodian who holds your keys.
You already rate-limit it, monitor it, and accept it can be drained. The catastrophic loss is the cold reserve behind it — and the only time it's reachable is the moment it opens to refill the hot side.
Either people hand-sign with hardware wallets under time pressure when the hot wallet runs dry, or a SaaS custodian signs for you. One is slow and error-prone; the other isn't your keys.
An attacker doesn't need your hot wallet. They need the moment your cold wallet opens to fill it — and they need that moment to be governed by software they can reach, not hardware you hold.
why an HSM · and why it must be multisig
Putting a signing key on an internet-connected server is the bet exchanges keep losing — it is the single most common way custodial Bitcoin is stolen. Since 2012, there has been a hot-wallet/server drain in nearly every year.
A loss in nearly every year — on the order of ~1,000,000 BTC in total, concentrated in Mt. Gox (~750k) and Bitfinex (~120k). Mixed-asset hacks show the Bitcoin portion; values priced at the time, disputed figures given as ranges. Sources →
Keep the signing key on tamper-resistant hardware it can never leave. A fully-owned server still can't extract it — the most-exploited failure mode is gone.
A single device on a single host is still a single point: own that one box, or coerce that one operator, and it signs. The bottleneck moved, it didn't vanish.
2-of-3 across independent hosts, each enforcing its own policy. No single hacked server or insider moves funds — and any one signer can fail without freezing the rest.
The refill problem
The cold→hot refill is where sovereignty, automation and policy collide — and today you get to pick two at most. Here's what's actually on the table.
Option A · do it yourself
Secure keys — but a human ritual.
Option B · hand it off
Automated and fast — but not your keys.
Nobody ships all three at once: automation, hardware keys you physically hold, and policy that can't be overridden in software. That's the whole reason this exists.
The mineracks approach
Three independent hardware signers — Coldcards in HSM mode — each on a separate host, ideally a separate site. A keyless coordinator builds the refill transaction and fans it to any two. They check it against their own on-device rules and auto-sign. The signed refill broadcasts to your hot wallet. No human in the loop — and no single machine can move a satoshi.
A per-transaction cap, a velocity limit (max per hour/day), and an address whitelist that allows only your own hot-wallet deposit addresses. Break a rule and the secure element refuses to sign — no software path around it.
2-of-3 across separate hosts and sites. Own one signer and you move nothing. Lose one signer to a reboot, outage or dead device and refills carry on. Lose two and funds simply freeze — safe.
The automation layer carries no keys, so its compromise can't move funds. The rules and the signing live on the Coldcards' secure elements. The coordinator only proposes; the hardware decides.
Everyday refills run untouched — no human involved. When you deliberately want a larger spend, the owner enters a one-time code from a normal authenticator app, and only then will 2-of-3 sign above the everyday cap — still bounded by a separate on-device surge ceiling the coordinator can't exceed. The coordinator merely relays your code; the secret never leaves the Coldcards and your phone. Automation for the routine, a deliberate human gate for the exceptional.
An automated refill, start to finish
Security model · for the reviewer who asks "what if it's breached?"
Every serious custody review reduces to one question: what happens when a server is compromised, an operator goes rogue, or a data centre dies? Here's the honest answer, failure by failure.
Coordinator fully compromised
Signer host(s) compromised
A host — or a whole site — lost
No single point to attack or lose
We show our working: a fully-compromised coordinator can move at most 1.5× a single signer's per-period velocity ceiling (two signatures burned per unit of value). Set each ceiling to two-thirds of your chosen limit and the worst case equals that limit — enforced on hardware, not software.
How it compares
Honest positioning beats a feature grid. Here's how the distributed policy HSM lines up against the options exchanges actually use to guard reserves and refill the hot side.
| Approach | Keys you physically hold |
Runs unattended |
Policy on the hardware |
No vendor to trust |
Cost |
|---|---|---|---|---|---|
| Single hot-wallet signer one server signs everything | ~ | ✓ | ✗ | ✓ | low |
| Manual cold multisig humans sign with hardware wallets | ✓ | ✗ | ~ | ✓ | low $ |
| MPC custody SaaS Fireblocks, BitGo, Copper… | ✗ | ✓ | ~ | ✗ | high $$$ |
| Enterprise HSM / vault Ledger Enterprise, Thales, CloudHSM | ✓ | ~ | ✓ | ~ | high $$$ |
| Collaborative custody Unchained, Casa, Nunchuk | ✓ | ✗ | ~ | ~ | mid $$ |
| mineracks distributed policy HSM 2-of-3 Coldcards · self-hosted | ✓ | ✓ | ✓ | ✓ | low $ |
High-throughput hot signing — hundreds of withdrawals an hour — is what MPC clusters are built for, and we'll tell you to keep using one there. A hardware signer isn't a certified, high-TPS appliance, and we don't pretend otherwise. What mineracks secures is the cold and warm tiers — the 95% of reserves and the refill pipe between them: low-throughput, high-stakes, and exactly where automation with hardware keys you hold beats both a 3am ceremony and a custodian. Cheaper than Fireblocks for the bulk of your funds, and sovereign by construction.
See a live 2-of-3 sign real-signet refills under policy → multisighsm.com
mineracks.com · [email protected] · Brisbane, Australia