In this article
You set spending limits and permissions on a shared company wallet by using a multisig structure that requires more than one person to approve anything above a threshold you choose, paired with a smaller daily allowance that one trusted person can spend without a second signature for routine, low-risk payments. The combination lets a team move quickly on small amounts while making sure no single person — employee or attacker — can move the company's money alone.
A shared wallet with one set of keys controlled by one person is a single point of failure: if that person's device is compromised, leaves the company on bad terms, or simply makes a mistake, there's nothing standing between a mistake and a loss. The fix isn't to lock everything behind committee-level approval, which just pushes people toward workarounds. It's to tier access by amount, the same way a company already tiers approval for a wire transfer or a large purchase order.
What is a multisig wallet, and why does it matter for spending limits?
A multisig (multi-signature) wallet is a wallet that requires a minimum number of approvals — say, two out of three authorized signers — before any transaction can go out, rather than relying on a single private key. Instead of one person holding the keys to the company's funds, the wallet is configured with a set of signers and a threshold, and no transaction executes until that threshold is met.
This matters for spending limits because the threshold itself is the limit — a 2-of-3 setup for day-to-day operations might sit alongside a 3-of-5 setup reserved for anything above a chosen amount, so a larger payment automatically requires more people to agree before it can move. The signers can be company principals, a mix of internal staff and an external advisor, or even a scheduled rotation, but the structural point is the same: moving money requires more than compromising, bribing, or mistakenly trusting one person.
How do you decide the right number of signers and the approval threshold?
Start from how many people genuinely need to be able to initiate a payment versus how many need to approve one, and set the threshold so that no single person on either side can move funds alone. A common small-team setup is three signers with a 2-of-3 threshold: any two of the three can approve a transaction, so the wallet survives one person being unavailable, while no individual can act alone.
For a larger organization or a wallet holding significant reserves, it's common to run two tiers: a lower-threshold wallet (2-of-3, say) funded periodically from a higher-threshold treasury wallet (3-of-5 or more) that holds the bulk of the company's funds and is used rarely. The treasury wallet's higher bar means a larger loss would require more people to be compromised or complicit at once, while the operating wallet's lower bar keeps day-to-day payments from bottlenecking on five people's schedules.
Based on common small-business multisig configurations.
How does a daily spending allowance work alongside a multisig threshold?
A daily or per-transaction allowance lets one designated person spend up to a set amount without waiting for a second signature, while anything above that amount still routes through the full multisig approval. This is the mechanism that keeps a well-secured wallet from becoming unusable for small, routine costs — a software subscription, a contractor's weekly invoice, a reimbursement — where requiring two people to coordinate every time would just push the team toward keeping a separate, less secure wallet for convenience.
The allowance resets on a schedule (daily or weekly, most commonly) and is itself configured at the wallet level, so it can't be changed by the person using it — raising their own limit still requires the same multisig approval as a large one-off payment would. Several wallet platforms built for teams and companies support this as a native feature rather than a workaround: a spending limit attached to one address that bypasses full multisig approval up to a cap, while every other address and every amount above the cap still requires the full threshold.
How do you decide what amount should require extra approval?
| Spending tier | Typical approach |
|---|---|
| Routine, recurring (subscriptions, small vendor invoices) | Daily allowance, one approver, logged automatically |
| Moderate, one-off (a new contractor's first invoice, equipment) | Standard multisig threshold (e.g., 2-of-3) |
| Large or irreversible (payroll run, a six-figure settlement, a treasury transfer) | Higher threshold (e.g., 3-of-5), sometimes with a mandatory time delay before execution |
| Anything leaving the company's own wallets to an external party for the first time | Full threshold regardless of amount, plus the payee verification steps covered in the payment-fraud pieces on this blog |
The specific dollar cutoffs matter less than the principle: the tier should track what the company could not easily absorb or reverse, not an arbitrary round number. A company that moves $500,000 in payroll each month and a company that moves $5,000 need very different thresholds for what counts as "routine."
Who should actually hold the signing keys?
Spread signers across people and across devices, not just across names on paper. A multisig configured with three signers who are all logged into the same device, the same password manager, or the same recovery phrase storage location is not meaningfully more secure than a single key — whatever compromises one compromises all three at once. Each signer should hold their key on a separate device, ideally including at least one hardware wallet among the set, and should never share recovery phrases with another signer "for convenience."
For a small company, this often means: one key held by the founder on a hardware wallet, one held by a co-founder or senior finance person on a separate hardware wallet, and one held by a trusted external party (an accountant, a lawyer, or a specialized custody service) who is not involved in day-to-day operations and serves mainly as a tiebreaker or backstop if an internal signer becomes unreachable.
A hardware wallet matters here specifically because it keeps the signing key offline, generated and stored on a dedicated device that never exposes the key to an internet-connected computer or phone. A key stored in a software wallet or a password manager is only as secure as the device it lives on — if that laptop is compromised by malware, the key can be extracted along with it. Requiring at least one, and ideally a majority, of signers to use hardware devices means an attacker who compromises someone's laptop or phone still can't sign a transaction without physical access to a separate piece of hardware, which is a meaningfully higher bar than compromising software alone.
Should every signer use the same type of device or wallet software?
Deliberately varying the hardware and software across signers is worth the minor inconvenience, because it removes a single shared vulnerability from taking down every key at once. If all three signers use the same hardware wallet model and the same companion software, a vulnerability discovered in that specific combination — rare, but not unheard of in the history of crypto wallet software — could in principle affect all three simultaneously. Mixing brands and keeping at least one signer on an entirely different setup (a different hardware vendor, or a different custody approach altogether) means that no single supply-chain or software issue can compromise the whole threshold in one stroke.
This is a second-order concern compared with getting the threshold and the key separation right in the first place, but it's a cheap addition once the basic structure is in place, and it costs nothing beyond buying a second type of device.
How do permissions differ from spending limits?
A spending limit controls how much can move; a permission controls what a given person or role is allowed to do at all, regardless of amount. In a well-structured setup, someone can have permission to propose a transaction — drafting it, entering the recipient and amount — without having permission to approve it, so the same person can't both create and execute a payment alone even if they somehow also held a signing key. Separating "can propose" from "can approve" is a cheap and effective control, because it means a single compromised account can, at worst, draft a fraudulent transaction for someone else to notice and reject, not actually send one.
Role-based permissions become more important as a team grows: a bookkeeper might be able to propose payments against a defined vendor list but never add a new, unverified recipient; a finance lead might approve but not propose, to keep the two functions separate; and only the smallest group of senior signers might be able to change the wallet's own configuration — who the signers are, what the threshold is, what the daily allowance covers. Most multisig platforms log every proposal, approval, and configuration change against the account that performed it, which gives you an audit trail for free as long as you've actually separated the roles in the first place.
What does setting this up actually look like, step by step?
- Choose the operating wallet's signersPick three people who are reliably reachable day to day — commonly the founder, a co-founder or finance lead, and one other senior team member — and set a 2-of-3 threshold.
- Set the daily allowanceBased on average routine spending (subscriptions, small vendor payments), set an allowance of roughly $2,000–$5,000 per day that one designated person can spend without a second signature.
- Create a separate treasury wallet for reservesAdd two more signers — commonly an external advisor and a second co-founder — for a 3-of-5 threshold, and fund the operating wallet from here on a schedule rather than holding the bulk of company funds in the lower-threshold wallet.
- Separate proposing from approvingGive a bookkeeper or ops person the ability to draft and propose transactions against a defined vendor list, without giving them a signing key — every proposal still needs two of the three operating signers to approve it.
- Document the recovery plan before you need itWrite down, and test on a small amount, what happens if one signer is unreachable: who steps in, and how the wallet's configuration gets updated without falling below the threshold in the process.
What happens when a payment comes from outside the company and needs to be split among several recipients?
Spending limits and permissions govern money leaving the company's own wallet. A separate but related question is how incoming money that's owed to several parties — a closing payment split between a company and its partners, say — gets divided without first landing in one person's control and then being manually redistributed, which recreates the single-point-of-failure problem on the way out. A payment router built for multi-party deals, like Shaka, solves this at the payment layer rather than the wallet layer: each recipient's share is agreed and signed before the payer sends anything, and the payment settles directly to each party's own address in one transaction — no intermediate pooling in a shared wallet that then has to be trusted to disburse correctly.
That's a different mechanism from the multisig and permission setup described above, but the two solve the same underlying problem from opposite ends: multisig protects money sitting in a wallet the company controls; a payment router protects money in transit to several parties who don't share a wallet at all. A company that receives multi-party payments regularly often benefits from both — a router for how shared deal proceeds arrive, and a properly tiered multisig for how the company's own operating funds are then spent.
How often should the setup actually be reviewed?
Treat the wallet's signer list, thresholds, and permissions the way you'd treat building access or server credentials — reviewed whenever someone joins or leaves, and audited on a routine schedule even when nothing has obviously changed. A departed employee who still holds a signing key, or a daily allowance set for a team size the company has since outgrown, are the kind of gaps that sit unnoticed for months precisely because the wallet keeps working fine in the meantime. A short quarterly check — who are the current signers, does the threshold still match what the company holds, does the daily allowance still match routine spending — catches both before either becomes a problem.
What's the most common mistake companies make when they first set this up?
The most common mistake isn't choosing the wrong threshold — it's configuring a reasonable threshold and then quietly routing around it the first time it's inconvenient. A signer who's traveling asks a colleague to "just approve this one for me," a founder shares a recovery phrase with an assistant to speed up a time-sensitive payment, or a team creates a second, lower-security wallet for "quick stuff" that ends up holding more than anyone intended because it's easier to use. Every one of these erases the protection the multisig was set up to provide, and they tend to happen under exactly the time pressure that also makes a team more vulnerable to a fraudulent urgent request in the first place.
The fix isn't stricter rules on paper — it's making the legitimate fast path (the daily allowance) wide enough that people don't feel they need a workaround for ordinary business, while keeping the threshold on anything larger genuinely non-negotiable. A multisig that gets bypassed under pressure once will get bypassed again, and the second time is rarely for a reason as good as the first.
Set the rule once, write it down somewhere every signer can see, and treat "this is urgent, just approve it" as the specific moment the rule exists for — not a reasonable exception to it. A wallet structure that only holds up when nothing is urgent isn't really protecting the company from much of anything, and urgency is precisely the condition under which it matters most.
