What a hot wallet is
Control of crypto comes down to control of a private key: whoever holds the key can authorise a transaction by signing it. A wallet is the software or hardware that stores those keys and produces signatures. A hot wallet is one where the key material lives on a machine that is online — a server, a phone, a browser extension — so a transaction can be built, signed, and broadcast to the network at any moment without a human moving anything between systems.
A cold wallet is the opposite: the key never touches an internet-connected device. It might live on a dedicated hardware device, an air-gapped machine, or paper, and a transaction is signed offline before only the finished signature is broadcast. Because the key is never exposed to a networked system, a remote attacker has nothing to reach. The cost is friction — signing from cold storage is a deliberate, manual step.
The trade-off is exposure against availability. A hot wallet can pay out instantly and run unattended, which is what an automated system needs, but its keys are reachable by anyone who compromises the host. A cold wallet is far harder to steal from remotely, but it cannot sign on demand. Most operations use both: a small working balance in a hot wallet, and the bulk of funds in cold storage, topped up to the hot wallet only as needed.
Why it matters for crypto payments
A payment system has to sign transactions constantly — to sweep deposits and, above all, to send funds out — so some portion of its keys is necessarily hot. An automated payout cannot wait for someone to authorise it from an offline device. The security question is therefore not whether to have a hot wallet, but how much value sits behind hot keys, who can trigger a signature, and what controls stand between a request and a broadcast transaction.
Because hot keys are the part of the system an attacker most wants, the defences around them are what matter: limiting how much is reachable at once, requiring approval before value moves, scoping which credential can authorise which action, and recording every signing event for review. A signing key is only as safe as the process that decides when it is allowed to sign.
Hot and cold keys on halfin
halfin signs on a merchant's behalf, so the relevant controls are the ones around that signing — not a custody promise. The guarantees on offer are about how the keys are used: a payout is signed only after it is approved, API keys carry scoped permissions so a credential can authorise only the actions it is granted, and signing events are auditable so money movement can be reviewed rather than taken on trust. halfin does not advertise custody assurances beyond signing, permissions, and audit.
For a merchant integrating payouts, a single or mass payout is an action that ends in a signed, broadcast transaction, so it sits behind approval and permission checks rather than firing the instant the API is called. Mass payouts fan out as individual lines, each carrying its own idempotency key, so a retried request re-sends the same instruction instead of paying twice — the guard that keeps an always-online payout path from turning a network hiccup into a double spend.
Webhooks close the loop. Because the events that report money leaving — payout.completed and payout.failed — are HMAC-signed, an integration can confirm a notification genuinely came from halfin before acting on it. As with every signed message in the platform, the rule is to verify first: treat the signature, not the payload's appearance, as the source of truth.
- Hot keys are online and sign on demand; cold keys stay offline and sign manually — speed versus exposure.
- An automated payout path needs hot signing, so the controls around it are what protect the funds.
- On halfin, money movement is approval-gated, permission-scoped, and auditable — signing guarantees, not custody promises.
- Payout webhooks are HMAC-signed; verify the signature before acting on a completed or failed payout.