What multisig means
An ordinary crypto address is single-signature: one private key can produce a valid signature, and that signature alone moves the funds. The strength of that arrangement is also its weakness — whoever obtains the key can spend everything, and losing the key loses the funds outright. There is no second factor, no co-signer, and no recourse. Multisig changes the rule that governs spending so that no single key is sufficient on its own.
A multisig setup is defined by two numbers. N is how many keys exist; M is how many of them must sign for a transaction to be accepted. The protocol enforces the threshold: a transaction carrying fewer than M valid signatures is simply rejected by the network, the same way an unsigned transaction would be. Common configurations are 2-of-2 (both keys required, no redundancy), 2-of-3 (any two of three — the most common operational choice), and larger M-of-N for treasuries that want several independent approvers.
The keys are deliberately kept apart — held by different people, stored on different devices, or split across different locations. That separation is the entire point. Because M signatures are needed and the keys do not sit together, compromising one key no longer compromises the funds, and the loss of one key does not strand them either, as long as M of the remaining keys are intact. Multisig trades the simplicity of a single key for resilience against both theft and loss.
Why it matters for crypto payments
Accepting and sending crypto means signing transactions, and the keys that can sign are the keys that can move money. For any business holding meaningful balances, a single signing key is a single point of failure: one stolen credential, one compromised machine, or one careless export can drain a wallet with nothing standing in the way. Multisig removes that single point by requiring more than one key to agree before value can leave.
The same property supports governance, not just security. An M-of-N threshold lets a business require that a payout be approved by more than one party — separating the person who requests a transaction from the people who authorize it, so no individual can move funds alone. For a treasury, that is the difference between a control and a hope. Multisig is one well-understood way to express that rule directly at the protocol level, where the network — not a policy document — enforces it.
Multisig is not a universal answer. Native support varies by chain: Bitcoin has long had script-based multisig, while other chains express the same idea through smart contracts or threshold-signature schemes with different trade-offs in cost, complexity, and on-chain footprint. The right number of keys, who holds them, and how signing is operated are design decisions, not defaults — a 2-of-3 wallet whose three keys all live on one laptop provides none of the protection its scheme implies.
Multisig and halfin
halfin is payment infrastructure that signs on a merchant's behalf, so the way it controls signing is described through signing, permissions, and audit rather than as a guarantee beyond them. The merchant's concern is not which key topology halfin uses internally, but whether money movement is gated, scoped, and recorded — the same goal a business would reach for when it reaches for multisig on its own wallet.
Those controls show up where they matter most: on payouts. Sending a single or mass payout ends in a signed, broadcast transaction, and that transaction sits behind approval rather than firing the instant the API is called — payouts enter a pending-approval state first. API keys carry scoped permissions, so a credential can authorize only the actions it has been granted, and signing events are auditable so money movement can be reviewed instead of taken on trust. The aim is the same separation-of-authority that multisig provides: no single action, on its own, sends funds.
Webhooks extend that discipline to notifications. 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 multisig, the principle is that authority must be proven, not assumed: verify the signature first and treat it, not the payload's appearance, as the source of truth.
- Multisig requires more than one key to authorize a transaction, so no single key can move the funds alone.
- It is written as M-of-N: N keys exist and any M of them must sign — 2-of-3 is the most common operational choice.
- Separating the keys is the point: it protects against both a single stolen key and a single lost one.
- halfin describes its signing controls through signing, permissions, and audit — approval-gated, permission-scoped, auditable money movement — not a custody guarantee beyond that.