[ PACK LIBRARY / PAYMENTS & BLOCKCHAIN ]

FOUNDATIONFREE SAMPLETESTED

Custody and key-management policy: self-custody vs MPC vs third-party

STAFF DAVID / SIGGY · V0.2.0
bsv-skills:key-derivation

REQUIRES

  • claude plugin install bsv-skills@b-open-io

WHEN TO REACH FOR THIS

Before your staff touch a single private key, they need a written custody stance: who holds keys, how they are derived and rotated, what spending is allowed without a human, and who approves the rest. This foundation is a decision document that trains David and Siggy on how your organization handles key material so every later payment or wallet task runs inside explicit limits you set ahead of time.

REQUIRES

  • BSV skills (for the derivation model the policy references): claude plugin install bsv-skills@b-open-io
  • Sigma Auth plugin if identity keys are in scope: claude plugin install sigma-auth@b-open-io
  • No accounts or keys needed to author the policy itself.

CONTEXT INPUTS

Fill these in. This section IS the deliverable's raw material — the prompt turns your answers into a finished policy.

{{CUSTODY_MODEL}}       # self-custody | third-party custodian | MPC/multi-sig | mixed
{{WHY_THIS_MODEL}}      # The tradeoff you accepted (control vs offloaded responsibility)
{{KEY_TYPES}}           # e.g. payment key, BAP identity key, ordinals key, treasury key
{{DERIVATION}}          # Type42 (BRC-42) | BIP32 (BRC-32) | mnemonic-rooted; invoice-number scheme
{{HOT_VS_COLD}}         # Which keys are online (hot) vs offline/hardware (cold)
{{SPENDING_LIMITS}}     # Per-tx and per-day ceilings that need no human approval
{{RATE_LIMITS}}         # Max transactions per window before a freeze/alert
{{APPROVAL_FLOW}}       # Who signs off above the limit; how many approvers
{{ADDRESS_ALLOWLIST}}   # Destinations funds may go to without extra review
{{ROTATION_TRIGGERS}}   # Events that force a key rotation (departure, suspected leak, schedule)
{{BACKUP_LOCATION}}     # Where encrypted backups live; who can decrypt them
{{INCIDENT_CONTACT}}    # Who is paged on a suspected compromise

THE PROMPT

PASTE INTO YOUR AGENT
You are David (BSV key management) with Siggy (identity keys) advising. Turn the
context inputs into a custody and key-management policy document. This is a policy,
not an implementation - do not write wallet code.

Load the `bsv-skills:key-derivation` skill and use its model to describe, precisely
and correctly, how {{KEY_TYPES}} are derived under {{DERIVATION}} - including the
BRC-43 invoice-number format ({securityLevel}-{protocol}-{keyId}) where identity or
protocol keys are involved. Do not overstate: state only what the derivation scheme
actually guarantees.

Produce a document with these sections:
1. Custody stance - {{CUSTODY_MODEL}} and {{WHY_THIS_MODEL}}, stated as an accepted
   tradeoff (self-custody = full control + full accountability; third-party = shifted
   responsibility, reduced control; MPC/multi-sig = split key material).
2. Key inventory - each entry in {{KEY_TYPES}}: purpose, derivation, hot or cold
   ({{HOT_VS_COLD}}), and where its backup lives ({{BACKUP_LOCATION}}).
3. Spending controls - {{SPENDING_LIMITS}}, {{RATE_LIMITS}}, {{ADDRESS_ALLOWLIST}},
   and the {{APPROVAL_FLOW}} for anything above the limits.
4. Rotation - {{ROTATION_TRIGGERS}} and a pointer to the rotation runbook.
5. Incident response - first actions on suspected compromise and {{INCIDENT_CONTACT}}.

For any input left blank, do NOT guess a value - list it as an open decision the
buyer must make, with the tradeoff spelled out.

Negative prompts:
- Do NOT invent limits, approvers, or allowlist entries the buyer did not provide.
- Do NOT write or scaffold wallet/signing code - this is a decision document.
- Do NOT claim a custody model is "most secure"; frame each as an explicit tradeoff.
- Do NOT put any real private key, WIF, or seed phrase in the document.

EXPECTED OUTPUT

A finished custody and key-management policy document (markdown) with a filled key inventory, spending controls, rotation triggers, and an incident section — plus a clearly marked list of any decisions left open. No code, no secrets.

FOLLOW-UP CHAIN

  • pb-key-rotation — Execute a clean BAP key rotation when a trigger fires
  • pb-wallet-backup — Encrypt and back up wallets per the backup policy
  • pb-compliance-profile — Pair the custody stance with a regulatory posture
  • pb-agent-payment-policy — Extend spending limits to autonomous agents

← PACK CONTENTS