> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xkey.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Hybrid co-signing

> Optional end-user + backend 2/2 approval — not the default Company Wallets path.

<Warning>
  **SKU boundary.** Company Wallets default to **organization multi-party approvals** (API users + human operators in the same org). End-user passkey **plus** backend API key (2/2) is a **hybrid / Embedded-adjacent** pattern. Use it only when you intentionally share custody with an end user.
</Warning>

## When to use this pattern

* Business wallets where the end user must approve every spend
* Compliance flows that require user presence + server automation
* Migrating from a co-custody model without moving to full custodial Company automation

## When not to use it

* Pure treasury / payment orchestration (use org consensus + API keys)
* High-volume backend sweeps (user presence does not scale)

## Mechanism (shared platform)

The engine is the same Activity consensus state machine:

1. Create a sub-organization with two root users (end-user authenticator + backend API key) and `rootQuorumThreshold: 2`, **or**
2. Use a policy `consensus` expression that requires both actors

Typical flow: client stamps with passkey → activity enters `CONSENSUS_NEEDED` → backend calls `approveActivity` → enclave signs.

Related reading:

* [Delegated access (server-side)](/concepts/policies/delegated-access-backend) — backend-limited control under a user-owned sub-org
* [Root quorum](/concepts/users/root-quorum)
* [Embedded wallets](/embedded-wallets/overview) — preferred SKU when end-user auth is first-class

## Company Wallets default instead

For institutional automation, prefer:

1. Parent org + API-only users
2. Tags + deny-by-default policies
3. `approvers.count() >= N` among operator passkeys
4. Optional custodial send + Enterprise sponsorship