SSP Enterprise: Multisig Vaults for Teams
Most company crypto setups have a person-shaped hole in them. Someone holds the hardware wallet. Someone knows where the seed phrase is. The controls are real — approvals in a spreadsheet, a policy document, a rule that two people must be on the call — but none of them are enforced by anything except everyone agreeing to follow them.
SSP Enterprise closes that hole by moving the rule into the address itself. A vault is an M-of-N multisig where the threshold is part of how the address is derived, so the network refuses to settle a transaction that has not met it. No amount of internal pressure, compromised laptop, or departing employee changes that arithmetic.
This article is the map of the whole system: how organisations, vaults, roles, proposals and policies fit together, and — importantly — which of those things actually stop a transaction and which merely shape it.
The problem with one person holding the keys
The single-signer problem is not really about trust. It is about concentration.
A single key means one compromised machine drains the treasury. It means one person on holiday blocks payroll. It means one departure creates a scramble to rotate everything, and one bad day creates an incident with no technical constraint standing between an impulse and an irreversible transfer.
Multisig converts every one of those into a survivable event, because no single secret is sufficient. What is multisig, and why it matters covers the model itself. What follows is how it is organised when the holder is a company rather than a person.
Organisations, vaults, and signers
Three layers, and it is worth keeping them distinct in your head.
An organisation is the container: the people, the roles, the audit trail, the billing relationship. It is identified by a WK identity rather than an email address, and it carries an immutable organisation index between 100 and 99999 that becomes part of every derivation path underneath it. Immutable is the load-bearing word — that index cannot be edited later, because changing it would change every address the organisation has ever derived.
A vault is a specific M-of-N multisig on a specific chain. One organisation can have many, and they do not have to share a threshold, a chain, or a signer set. A treasury vault at 3-of-5 on Bitcoin and a payouts vault at 2-of-3 on Ethereum are separate custody objects that happen to be administered from the same place.
A signer is a person, represented by the two devices SSP always uses: the browser extension and the SSP Key app. When a signer approves a vault proposal, both of their devices participate — so the N in your M-of-N counts people, and each of those people is themselves protected by a 2-of-2.
Vaults are available across the chains SSP supports: Bitcoin, Litecoin, Dogecoin, Ravencoin, Flux, Zcash and Bitcoin Cash on the UTXO side; Ethereum, BSC, Avalanche, Polygon and Base on the EVM side; and Solana. Derivation follows BIP-48 with the organisation index in the account position — the BIP-48 specification is the primary source, and BIP-48 explained covers how SSP uses it.
The threshold is in the address
This is the part that makes enterprise multisig different from an approval workflow, and it is worth being precise about.
When a vault is created, the signers' public keys and the required number of signatures are combined to produce the address. The threshold is not a setting stored next to the vault; it is an input to the address. That has three consequences worth planning around.
Nobody can lower it. Not an administrator, not SSP, not an attacker with access to the dashboard. The chain validates against the address, and the address encodes the rule.
Changing signers means a new vault. Adding or removing a signer changes the address, which means moving funds rather than editing a record. This is a genuine operational cost, and it is the main thing to think through before choosing your signer set. 2-of-2 vs 2-of-3 vs m-of-n is the guide to picking a threshold you will not immediately want to change.
Losing signers below the threshold is unrecoverable. A 3-of-5 vault survives two signers disappearing and not three. Plan for the departures, the lost phones, and the eventual estate questions before you fund anything — inheritance and emergency access applies to organisations at least as much as to individuals.
Some chains offer flexibility in how a signer's approval is produced. On EVM chains a vault can require both of a signer's devices or accept a single-device mode; on Solana, a single-key signing mode trades the per-signer 2-of-2 for larger signer sets, up to 7-of-15. Those are deliberate trade-offs between committee size and per-person security, chosen when the vault is created. The single-key Schnorr option was introduced for enterprise vaults with exactly that trade in mind.
Roles are not signing power
The most common confusion in shared-custody products is conflating the org chart with the key material. SSP keeps them separate on purpose.
Organisation roles — owner, admin, member, viewer — govern the workspace. They decide who can invite people, who can create vaults, who can change organisational settings. An owner can modify anyone; an admin can modify members and viewers but not other admins; a viewer cannot invite at all.
Vault roles — admin, signer, viewer — govern one specific vault. Only a signer's key is in the address.
The important consequence: being an organisation owner does not make you able to spend. If the owner is not a signer on a vault, the owner cannot move its funds, no matter what the dashboard says. Administrative authority and custody authority are different things, and in SSP they are stored in different places — one in a database, one in an address.
That separation is what lets a finance lead administer vaults they cannot unilaterally drain, and what makes a compromised admin account a coordination problem rather than a solvency problem.
What a proposal goes through
Spending from a vault is a proposal, not a click.
A signer or vault admin drafts a transaction. It becomes visible to the vault's signers, who review and approve on their own devices — each approval decoded on the device rather than taken on trust from a server. Once M signatures exist, the transaction can be broadcast. Until then it sits, and if it never reaches M it expires rather than lingering indefinitely.
Simulation runs before you approve, not after: the proposal is executed against a fork of current chain state so the review screen can show what the transaction would actually do, and flag risky patterns rather than leaving you to read raw call data. That was added to enterprise vaults in v1.40.
Policies shape proposals; signatures settle them
SSP Enterprise supports address whitelists, destination restrictions, time locks with value thresholds, and rules requiring admin approval above a certain amount. They are genuinely useful, and they are worth stating honestly for what they are.
These are coordination-layer controls, not custody enforcement. A whitelist stops a proposal being created and approved through the normal flow. It does not become part of the address, and it is not validated by the network. The only thing the chain enforces is the signature threshold.
We say this plainly because the alternative — implying that a policy engine is a custody guarantee — is how people end up surprised. The correct mental model is that policies are the process controls a finance team wants, layered on top of a custody guarantee that exists independently of them. If every policy in the system were bypassed tomorrow, an attacker would still need M signatures from M people's paired devices.
What gets written down
Every state-changing action in an organisation is recorded: vault creation, member joins and departures, role changes, invitations issued and accepted, ownership transfers, and every proposal transition. Audit records are permanent — no expiry, no cleanup job — because the value of an audit trail is entirely in the parts you did not anticipate needing.
Certain operations go further and require re-signing with your two devices at the moment you perform them: transferring ownership, deleting an organisation, removing a member, changing the enterprise email. The server generates the challenge, never the client, and every attempt — successful or not — is logged permanently.
Getting started
An organisation is created from an SSP identity, vaults are created within it, and signers join by invitation to their own WK identity rather than to an email address. Each signer submits their extended public key so the vault address can be derived, and the vault becomes active once the full signer set has contributed.
Before that, the two decisions worth taking slowly are the threshold and the signer set, because both are expensive to change afterwards. Everything else — policies, roles, integrations, notification preferences — can be adjusted whenever you like.
The launch announcement covers what shipped originally, and SSP's contracts and account-abstraction infrastructure were audited by Halborn in 2025. If the underlying 2-of-2 model that each signer uses is new to you, what is 2-of-2 multisig is the place to start.
