~/notes / corporate wallet
Corporate Crypto Wallet: What It Must Do That a Personal One Does Not
Approval flows, address allowlists, role separation and audit trails. The features that separate a business crypto wallet from a personal one, and why each exists.
A personal wallet has one job: keep a key safe and let one person sign. A corporate crypto wallet has a different job, and most of its features exist because a company cannot accept the failure modes that an individual can. Against an institutional crypto wallet, which documents this rather than describing it, the trade-offs become measurable.
The core difference: no single person can move funds
In a personal setup, whoever holds the key controls the funds. That is the design.
In a company, that is a liability. If one employee can move the treasury, then a compromised laptop, a departing employee, or a convincing phone call is an existential event. Every serious corporate wallet feature follows from removing that single point of control.
The mechanism is either multi-signature, where several keys must sign, or a policy engine, where the platform enforces approval rules before signing on your behalf. Both achieve the same outcome. Multi-signature puts the enforcement in the protocol, a policy engine puts it in the provider. Which is appropriate depends on whether you would rather trust cryptography you have to operate or a regulated counterparty you have to select.
Role separation
At minimum a business crypto wallet needs three distinct roles.
Initiator can create a transaction but not approve it. Usually the person who knows who needs paying.
Approver can approve but not initiate. Usually finance or a director.
Administrator can change settings, add users and modify the allowlist, but should not be able to unilaterally approve a payment.
The failure this prevents is the one where a single compromised account both creates and approves a withdrawal. If the same person can do both, the approval step is decoration. The institutional version of the same problem runs through a platform built for institutional allocations, with an extra reporting layer on top.
Address allowlisting with a delay
Withdrawals go only to pre-registered addresses. Adding a new address requires approval and a time delay before it becomes usable, typically twenty-four hours.
The delay is the important part and it is frequently configured away because it is inconvenient. It should not be. The delay converts a successful account compromise from an immediate loss into an alert with time to respond. Almost every large corporate crypto theft involved an attacker adding an address and using it within minutes.
Spending limits by role and period
Per-transaction, daily and monthly caps, set per user. This bounds the damage from any single failure and it makes the routine case frictionless: small recurring payments go through without ceremony, large ones require the full approval chain.
An audit trail that satisfies an auditor
Every action recorded with who, what, when, and from where. Immutable, exportable, and including failed and rejected attempts as well as successful ones.
The rejected attempts matter. A pattern of rejected withdrawal attempts is the clearest early signal of a compromised account, and a log that only records successes will not show it.
Reporting that reconciles
Balances at period end, all movements with fiat values at the time of the transaction, fees separated, and an export format your accounting system can ingest. If the wallet cannot produce a period-end statement, somebody is building one manually every month.
Where this leaves self-custody
A company can absolutely run its own multi-signature setup. Several do it well. What it requires is: key holders who understand the process, a documented recovery procedure that has been tested, geographic separation of key material, and a plan for what happens when a key holder leaves or is unavailable.
That is real operational work and it does not stop. The alternative is a corporate crypto wallet with approval controls built in, where the provider carries the operational burden and you carry counterparty risk instead.
Neither answer is universally right. The question to ask is which risk your company is better equipped to manage: the operational risk of running key infrastructure, or the counterparty risk of a regulated provider. Most companies below a certain size are considerably better at the second.
# Corrections and technical nitpicks are welcome. Send them over. They get published with the fix.