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:- Create a sub-organization with two root users (end-user authenticator + backend API key) and
rootQuorumThreshold: 2, or - Use a policy
consensusexpression that requires both actors
CONSENSUS_NEEDED → backend calls approveActivity → enclave signs.
Related reading:
- Delegated access (server-side) — backend-limited control under a user-owned sub-org
- Root quorum
- Embedded wallets — preferred SKU when end-user auth is first-class
Company Wallets default instead
For institutional automation, prefer:- Parent org + API-only users
- Tags + deny-by-default policies
approvers.count() >= Namong operator passkeys- Optional custodial send + Enterprise sponsorship