Sharing Keys Across Organizations: Multisig Vaults Without Merging Teams

Most Bitcoin multisig wallets assume that all the signers belong to the same group. The treasury sits inside one company. The family vault is set up by one person and the rest of the household are signers on that single account. The DAO has a single safe operated by a single set of admins.

That assumption breaks down quickly in practice.

A startup wants to set up a 2-of-3 treasury where their accountant — who works at a separate firm — holds one of the keys. A family wants a joint vault co-signed by family members who each have their own SigVault accounts. A DAO wants signers drawn from several member organizations, each with their own internal workflows. An escrow setup needs one key from the buyer's company, one from the seller's, and one from a neutral third party.

In every case, the signers don't belong to a single team. Forcing them to is the wrong solution: it conflates membership, audit trails, and permissions across organizations that should stay separate.

SigVault solves this with organizations and cross-organization key sharing. This post walks through how it works and when to reach for it.

Organizations in SigVault

An organization in SigVault is a shared workspace — a way for multiple users to collaborate on vaults under a common roof. Each org has its own:

• Members, each with a role (Admin or Member) and a set of fine-grained permissions
• Device pool, populated by members exposing their hardware wallets to the org
• Vaults, owned and operated by the org

A single user can belong to many organizations at once. Switching between them is a click in the sidebar.

What an organization is not: a custodian. SigVault never holds private keys on behalf of an org or its members. All signing happens on hardware devices that members physically control. The org is a coordination layer, not a key holder.

The key sharing model

Here is the part that's different from most wallet platforms: in SigVault, a member can take one of their personal hardware devices and share it with an organization. Sharing makes the device's public key visible inside the org's vault builder, so other members can include it when constructing a multisig wallet.

What sharing does not do:

• It does not transfer ownership of the device. You can rename, unregister, or revoke at any time.
• It does not expose the private key. The seed phrase stays on your hardware, exactly as before.
• It does not grant blanket signing authority. Every transaction still requires you to physically approve it on the device.
• It does not auto-add the device to any vault. The org can only propose including your device; you have to accept (more on this below).

A device can be shared with multiple organizations at the same time. Each share is independent — revoking one doesn't affect the others.

For the full mechanics and what the org can and can't see, read Sharing Keys Across Organizations in the docs.

Building a vault from keys across orgs

Once devices are in an org's pool, an admin (or any member with wallet:create) opens the org's vault builder and selects which devices participate.

Because any member can share any of their devices with an org, vaults can naturally span organizational boundaries:

• Alice belongs to Acme Corp and shares her BitBox02 there.
• Bob is an outside accountant at Klein & Sons CPA. He's also a guest member of Acme Corp and shares his Coldcard with them.
• Carol is the CEO and belongs to Acme Corp; she shares her Ledger.

Acme can now build a 2-of-3 treasury vault using Alice's BitBox02 + Bob's Coldcard + Carol's Ledger. Bob's primary identity stays with his accounting firm. Acme doesn't need to add him to anything beyond a guest seat. If the engagement ends, Bob revokes his share and the team can either rotate the vault or leave it as-is (his key still exists on his device — but he's no longer in the org).

The same pattern works for:

• Family vaults, where each family member has their own SigVault account and shares one device into a shared family org
• Escrow, where one device comes from the buyer's org, one from the seller's, and one from a third-party mediator's org
• Cross-company joint ventures, where the JV's org gets keys from each parent company's representative
• DAOs, where the treasury is co-signed by signers drawn from several member orgs

The vault doesn't care whose org "owns" the signers. It just cares that the public keys are in the descriptor and that the corresponding devices show up to sign when transactions need to move.

The per-vault consent step

Cross-org key sharing would be dangerous without a fundamental safeguard: when an admin builds a vault containing your device, you have to approve that specific vault before the wallet gets provisioned.

Sharing your device with an org gives them visibility into your public key. It does not authorize them to use your key in any vault they please. SigVault enforces this with a per-vault consent step:

1. Admin selects devices and submits the vault.
2. SigVault creates the wallet record but holds it in NOT_STARTED.
3. Every selected device's owner gets a notification in their Inbox with the vault's name, threshold, and the device being requested.
4. Each owner accepts or declines independently.
5. The vault only provisions once everyone has accepted. A single decline marks the vault failed; the admin builds a new one with a different set.

There's no auto-accept and no timeout. You can leave a request pending indefinitely while you ask the admin about it out-of-band. You can decline without explanation. The walkthrough is in Building Shared Vaults.

The cumulative effect is three layers of opt-in before a key joins an org vault:

1. You accept the org invite.
2. You opt-in to expose the device.
3. You approve the specific vault.

Any of those can be revoked, and revocation is one click.

When is this the right tool?

Cross-org vaults are worth reaching for when the natural trust boundaries don't line up with a single team:

• The signers belong to different companies, households, or legal entities
• One party should not see the other parties' vaults or operations
• One party may rotate out independently of the others
• You want the audit trail kept inside each party's own organization

When you're just setting up an internal team treasury, the simpler answer is to keep all signers as members of one org. Cross-org sharing adds a useful extra layer of consent that mostly pays off when the parties are genuinely distinct.

Try it

If you already have a SigVault account, you can spin up an organization from the dashboard under Organizations → New organization, invite teammates by email, and start exposing devices in Settings → Device Shares. The dashboard guides the rest.

If you're new, pick an instance to get started.

For the deep-dive on the model, the consent flow, and the API surface, the docs are the source of truth:

• Organizations Overview
• Members and Roles
• Sharing Keys Across Organizations
• Building Shared Vaults