Custody Models & Security Permutations

Four models from single-device development to n-party governance

1 Single Device (Development)
Device A
Share 0
Share 1
✓ Can sign alone (1-of-1)
✗ No external coordination needed
Security
Low
Device compromise = total key loss
Availability
High
Offline signing always available
Cost
Free
Single device, no infrastructure
Usability
Simple
No coordination required
Storage iOS Keychain (both shares)
Backup Manual export to encrypted file only
Recovery Device lost = key permanently lost
Threshold 1-of-1 (single device can sign)
Best For:
  • Development and testing
  • Single-user, non-custodial wallets
  • Throwaway or experimental keys
  • High-frequency signing workflows
Risks & Limitations:
  • No redundancy—one device failure = total loss
  • No offline backup option (unless manually exported)
  • Single point of failure if device compromised
2a Two Devices — QR Bootstrap (2-of-2)
Device A
Share 0
↔ QR
Device B
Share 1
✓ Both devices required to sign
✓ Air-gap capable (offline transfer)
✗ Synchronous coordination required
Security
High
Share never crosses device boundary
Availability
Medium
Both devices must be online to sign
Cost
Free
Both devices user-owned
Usability
Good
One QR scan per setup + file backup
Storage Each device: Keychain + iCloud backup
Transfer QR code (offline, air-gap safe)
Backup Each device exports encrypted file
Recovery Device lost? Import from backup file
Threshold 2-of-2 (both shares required)
Best For:
  • Co-custody arrangements (married couples)
  • Business partnerships with offline-first requirement
  • Offline key backup and air-gap transfer
  • Users prioritizing security over convenience
Upgrade Path:
Model 2a → Add Server (Model 3)
Both devices keep existing shares, server joins as 3rd share
2b Two Devices — Bluetooth Real-Time (2-of-2)
Device A
Share 0
↔ BLE/mTLS
Device B
Share 1
✓ Real-time protocol execution
✓ Live confirmation feedback
✗ Devices must be in BLE range
Security
High
Same as 2a + mTLS encryption
Availability
Medium
Requires both devices in range
Cost
Free
BLE built into all iOS devices
Usability
Excellent
6-8 seconds per key generation
Storage Each device: Keychain + iCloud backup
Transfer BLE with mTLS + QR certificate exchange
Backup Each device exports encrypted file
Recovery Same as 2a (file import)
Threshold 2-of-2 (both shares required)
Best For:
  • Same scenarios as 2a, but with better UX
  • High-frequency signing without internet
  • Live confirmation workflows (approvals)
  • Devices in physical proximity (home, office)
Comparison with 2a:
2a (QR): Slower (1-2 min) but offline-safe
2b (BLE): Faster (6-8s) but requires proximity
Both: Use 2a for backup, 2b for active signing
3 2-of-3 Threshold (Device + Device + Server)
Device A
Share 0
↔
Device B
Share 1
↔
Server
Share 2 (HSM)
✓ Any 2 of 3 parties can sign
✓ No single point of failure
✓ Device loss is recoverable
Security
Very High
Threshold redundancy + HSM
Availability
High
One device or server can be offline
Cost
Moderate
Server + HSM (optional)
Usability
Good
Threshold refresh + audit logging
Storage Devices: Keychain | Server: HSM (non-extractable)
Transfer Network + mTLS (requires internet)
Backup Server provides redundancy; threshold refresh for new device
Recovery Lost Device A? Use Device B + Server to refresh
Threshold 2-of-3 (any 2 parties can sign)
Best For:
  • Enterprise custody with policy enforcement
  • Institutional cold storage + hot access
  • Audit trail and transaction logging
  • Compliance-heavy organizations
Mitigated Risks:
  • ✓ Server compromise doesn't break key (still have 2 devices)
  • ✓ Device loss is recoverable (other device + server)
  • ✓ Audit trail on all server operations
Upgrade Path:
Model 2a/2b → Add Server (Model 3)
Existing 2 devices keep shares, server joins threshold
4 N-Party Organization (e.g., 3-of-5 Governance)
Admin 1
Share 0
Admin 2
Share 1
Admin 3
Share 2
Admin 4
Share 3
Admin 5
Share 4
✓ Any 3 of 5 parties can authorize transaction
✓ Quorum-based governance
✓ Full n-party capability
Security
Very High
Quorum consensus required
Availability
Medium
Quorum (3-of-5) must be online
Cost
Moderate
Each participant's device
Usability
Complex
Multi-party coordination protocol
Storage Each admin's device: Keychain
Transfer Network + mTLS (all parties coordinate)
Backup Threshold refresh for lost party
Recovery Quorum (3 of 5) authorizes new share
Threshold 3-of-5 (quorum voting)
Best For:
  • DAO and decentralized treasuries
  • Multi-signature organization (board approval)
  • Corporate governance with multiple signatories
  • Family governance (parents + trustees)
Governance Considerations:
  • ⚠ Coordination complexity with many parties
  • ⚠ Need to handle party dropout gracefully
  • ⚠ Quorum requirement may slow down approvals
  • ✓ No single point of failure (consensus required)
Onboarding New Admin:
Existing quorum (3 of 5) → Runs threshold refresh
→ New admin gets share via BLE/QR

Model Comparison Matrix

Model Security Availability Cost Use Case Recovery
1. Single Device Low High Free Development Lost forever
2a. 2 Devices (QR) High Medium Free Co-custody, offline-first File backup import
2b. 2 Devices (BLE) High Medium Free Co-custody, real-time File backup import
3. 2-of-3 Threshold Very High High Moderate Enterprise custody Threshold refresh
4. 3-of-5 N-Party Very High Medium Moderate DAO/Governance Quorum refresh

How to Choose Your Model

  1. Is this for development or production?
    • → Development: Model 1 (single device)
    • → Production: Model 2a/2b/3/4
  2. Do you need redundancy?
    • → No: Model 1 or Model 2a/2b (2-of-2, both required)
    • → Yes: Model 3 (2-of-3, threshold redundancy)
  3. Is internet always available?
    • → No (offline-first): Model 2a (QR transfer)
    • → Yes (online): Model 2b (BLE) or Model 3 (network)
  4. Do you need quorum governance?
    • → No: Model 2a/2b/3
    • → Yes: Model 4 (n-party, 3-of-5 voting)