[ PACK LIBRARY / PAYMENTS & BLOCKCHAIN ]
REQUIRES
Document who holds your keys, how keys are derived and rotated, and which payments require approval. David and Siggy use your answers to prepare a custody policy that later wallet and payment tasks can reference.
claude plugin install bsv-skills@b-open-ioclaude plugin install sigma-auth@b-open-ioFill 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
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.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.
pb-key-rotation — Execute a clean BAP key rotation when a trigger firespb-wallet-backup — Encrypt and back up wallets per the backup policypb-compliance-profile — Pair the custody stance with a regulatory posturepb-agent-payment-policy — Extend spending limits to autonomous agents