FinTech · High-value · Full key lifecycle management
The problem
A custody firm holds $5B+ in crypto assets across dozens of chains
for pension funds, corporate treasuries, and ETF issuers. The key
management practice is:
Multi-sig wallets with 3-of-5 or higher thresholds, co-
signers spread across geographies and HSMs.
Quarterly key rotation required by internal controls.
Emergency rotation when a co-signer leaves, a device is
compromised, or a jurisdiction-specific event requires it.
Post-incident forensics is often “screenshot of the
multi-sig dashboard at the time.”
The pain points:
Rotations are manual and fragile. An errant key not
rotated properly becomes a permanent liability, or a
ticking time bomb when someone’s HSM quietly fails.
Recovery is an emergency. Lost keys = lost funds. Wallet
providers offer “social recovery” but with proprietary flows
and questionable guarantees.
Audit trails are shallow. “This $100M transfer was signed
by these three keys on this date” has to be reconstructed
across multiple systems.
Cross-jurisdiction coordination is hard. EU and US
subsidiaries each have their own HSMs and approval rules;
moving funds between them requires reconciling two different
workflows.
Why Quidnug fits
Quidnug’s guardian model (QDP-0002) and nonce ledger (QDP-0001)
are the exact primitives a custody shop needs, upgraded beyond
typical multi-sig:
Problem
Quidnug primitive
”Which keys can authorize a transfer?”
GuardianSet for each wallet/account
”Rotate a key every 90 days”
AnchorRotation with MaxAcceptedOldNonce
”Invalidate a compromised key immediately”
AnchorInvalidation (freeze epoch)
“Emergency recovery with oversight”
GuardianRecovery with time-lock veto
”Forensically audit last year’s activity”
Ledger snapshot + signed event stream
”Coordinate policy across subsidiaries”
Fork-block transaction at shared height
”Detect stale-key signatures”
Lazy epoch probe (QDP-0007)
High-level architecture
Quidnug Custody Root
(company-level identity)
│
│ has guardians:
│ {CEO, CISO, COO, external-auditor}
│
▼
┌──────────────────────────────┐
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ US Vault │ │ EU Vault │
│ (subsidiary) │ │ (subsidiary) │
└──────┬───────┘ └──────┬───────┘
│ │
│ has approvers: │
│ {signer1, signer2, │
│ signer3, signer4, │
│ signer5} │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ Wallet accounts│ │Wallet accounts│
│ (one quid each)│ │(one quid each)│
└───────────────┘ └───────────────┘
│ │
▼ ▼
On-chain (multi-sig On-chain (multi-sig
contract executes) contract executes)
Each level has its own guardian set with distinct rules:
Root: requires executive-level quorum for structural
changes.
Subsidiary: declares the pool of authorized approvers.
Individual wallet: specifies the specific threshold for
that wallet (e.g., cold-storage wallet might require 5-of-7
vs. hot-wallet 2-of-3).
Data model
Wallet as a quid
Each custody wallet is a quid. Its guardian set is the set of
authorized signers. The wallet’s on-chain (Ethereum/Bitcoin/
etc.) multi-sig contract is configured to accept signatures
that match the quorum declared on Quidnug.
recoveryDelay: 7 days # long time-lock for cold storage
requireGuardianRotation: true # no primary-key fast path
Approval as title + events
A transfer authorization is a title representing “the authorization
to transfer X from wallet Y”. Approvers cosign via events
(same pattern as interbank wires).
title: "tx-auth-2026-04-18-abc"
owner: wallet-cold-btc-001
attributes:
targetChain: "bitcoin"
targetAddress: "bc1q..."
amount: "10.5"
currency: "BTC"
proposedAt: <unix>
events on this title:
- wire.cosign {signer: signer1, epoch: 0}
- wire.cosign {signer: signer2, epoch: 0}
- wire.cosign {signer: signer3, epoch: 0}
- wire.cosign {signer: signer4, epoch: 0}
- wire.cosign {signer: signer5, epoch: 0} ← quorum met
- wire.approved (system-emitted)
Once the wire.approved event fires, the subsidiary’s bridge
system extracts each signer’s signature and submits to the
on-chain multi-sig contract.
Epoch-based audit
Every signer’s signing key has an epoch, an integer that
monotonically advances on each rotation. A historical transfer
audit looks like:
"Transfer X was approved at block 123456:
- signer1 signed at epoch=2 (rotated 2026-02-15)
- signer2 signed at epoch=3 (rotated 2026-03-20)
- signer3 signed at epoch=1 (rotated 2025-11-05)
- signer4 signed at epoch=0 (never rotated, still original onboarding key!)
- signer5 signed at epoch=2
Quorum weight: 5 of 5. Threshold: 5. APPROVED."
An auditor immediately sees that signer4 is overdue for a
rotation. Actionable.
Quarterly rotation workflow
Every 90 days, each signer rotates their key:
1. Generate new keypair in HSM (signer's local ceremony).
2. Submit AnchorRotation:
- fromEpoch: current
- toEpoch: current + 1
- newPublicKey: <hex>
- minNextNonce: 1
- maxAcceptedOldNonce: 100 (grace for in-flight approvals)
3. Nodes across subsidiaries automatically learn of the rotation
via push gossip (QDP-0005). In-flight transfer titles
that the signer had started approving still complete
under their old-epoch key up to the cap.
4. New transfers are signed with the new-epoch key.
If the rotation doesn’t happen within the policy window, a
monitoring rule triggers an alert and (optionally) an
auto-invalidation of the stale epoch, locking the signer
out until they complete the rotation.
Emergency key loss
Scenario: signer3’s HSM catastrophically fails at 2am Sunday.
Several transfers are in flight. Recovery:
1. Ops confirms HSM is bricked (standard diagnostic).
2. signer3's personal guardians initiate recovery:
- signer3's manager
- signer3's backup HSM (stored in separate geo)
- the subsidiary's compliance officer
(3-of-5 recovery guardians; see signer3's own GuardianSet)
4. During delay: each in-flight transfer can still complete
with signer3's original signatures.
5. If signer3 is actually fine (just on vacation) and this is
a social-engineering attempt, signer3 can veto from a
different trusted device.
6. At delay expiration: commit fires. signer3's epoch advances.
Any future signatures require the new HSM.
No emergency vendor calls. No protocol downtime. Just a
cryptographically-auditable flow.
Subsidiary isolation
EU and US subsidiaries are separate quids with their own
approver sets. Moving funds between them is an explicit
transfer-out-of-one, transfer-in-to-other flow that requires
BOTH subsidiaries’ approval quorums.
Compliance value: US compliance officer can’t unilaterally
move funds sitting in the EU subsidiary. EU data-privacy rules
are enforceable because EU subsidiary’s approvals don’t
implicitly grant US access.
Key Quidnug features
Guardian sets with requireGuardianRotation, blocks
primary-key-only rotations on sensitive quids. Every rotation
goes through the time-locked guardian path.
AnchorRotation with MaxAcceptedOldNonce, bounded grace
window for rotation.
AnchorInvalidation, immediate kill-switch for compromised
keys.
Push gossip (QDP-0005), rotations propagate across EU/US
nodes within seconds.
Lazy epoch probe (QDP-0007), the US subsidiary’s node
detecting “hasn’t seen signer-EU-3 sign in 35 days” probes
the EU home domain before accepting a signature.
K-of-K bootstrap (QDP-0008), opening a new subsidiary in
APAC bootstraps from US + EU + two other peers.
Fork-block trigger (QDP-0009), when the firm raises the
minimum threshold to 6-of-9 globally, fork-block coordinates
all subsidiaries.
demo.py, eight-step end-to-end flow: register 7 signers,
install a 5-of-7 policy, propose a transfer, watch the
verdict transition pending -> authorized as cosignatures
accumulate, render the forensic audit, freeze, and observe
denial of a follow-on transfer.
A signer’s key is confirmed compromised. Immediate action:
Terminal window
# Freeze the epoch
curl-XPOST$NODE_US/api/anchors-d'{
"kind":"invalidation",
"signerQuid":"us-signer-3",
"epochToInvalidate":2,
"anchorNonce":<next>,
"validFrom":<now>,
"signature":"<signed by a currently-trusted signer or via guardian quorum>"
}'
Now no further transactions at that epoch are admitted
anywhere in the network (even cross-subsidiary).
6. Cross-subsidiary transfer
US wallet → EU wallet transfer:
1. US subsidiary creates an "outbound transfer" title with their
5-of-7 quorum.
2. Their on-chain multi-sig executes: funds move from US BTC
address to EU BTC address.
3. EU subsidiary creates an "inbound attestation" title
confirming receipt, cosigned by EU's quorum.
4. Both titles link to each other via a shared correlation ID.
Compliance sees a full chain: US approvers + EU approvers both
on-chain.
7. Lazy epoch probe in action
The US subsidiary has signer-EU-3 in its trust graph (for
cross-subsidiary transfer verification). EU-3 hasn’t signed
anything the US node has seen in 35 days.
When a new cross-subsidiary transfer arrives with EU-3’s
signature:
US node:
1. Check recency of EU-3: > 7-day window → stale.
2. Quarantine the transaction.
3. Probe EU's domain: GET /api/v2/domain-fingerprints/eu.custody/latest
4. EU node responds with its latest fingerprint; EU-3's epoch
is 4 (they rotated 3 times we didn't see).
5. US ledger updates EU-3's epoch.
6. Re-validate the transaction: signed at epoch 4? OK, accept.
signed at stale epoch 2? Reject.
Catches the scenario where an attacker has EU-3’s old (rotated-
out) key and tries to use it in the US.
8. Subsidiary opening (bootstrap)
Opening an APAC subsidiary:
Terminal window
# 8a. APAC node is fresh. Bootstrap trust list seeded by firm ops:
Root quid key, structural authority. Catastrophic if
compromised (can rewrite guardian sets).
Attackers
Attacker
Capability
Goal
External
No access to any firm infrastructure
Steal holdings
Insider: signer
Has one signing HSM
Participate in theft
Insider: sysadmin
Can reboot nodes, modify config, not keys
Subtle sabotage
Insider: executive
Guardian quorum member
Collusion
State adversary
Network observer, legal compulsion
Surveillance / seizure
Supply-chain
Compromised dependency, HSM firmware
Persistent backdoor
Social engineer
Access to signers via email / phone
Trick into signing
Threats
T1. Theft via compromised signer quorum
Attack. Attacker compromises 5 of 7 cold-wallet signers’
HSMs and triggers a transfer to their own address.
Mitigations.
Cold-wallet quorum is high (5-of-7 minimum). Compromising
5 independent HSMs is a major operation.
Signers spread geographically and across HSM vendors,
correlated-HSM-compromise is much harder than a single
vendor bug.
requireGuardianRotation=true on cold wallets means any
signer-set change goes through time-locked guardian
recovery, giving compliance / ops a window to intervene.
Residual risk. Determined state-level adversary with
multiple independent compromises. Mitigated by insurance +
monitoring + air-gapped cold signers.
T2. Insider collusion
Attack. Three signers + compliance officer collude to move
funds to an attacker-controlled address.
Mitigations.
Quorum math should be set so any single insider group can’t
meet threshold (N-1 if possible). Cold wallet with
5-of-7 means 3 colluders can’t succeed.
Periodic rotation (every 90 days) limits the window of
stable collusion.
Executive-level oversight: guardian-set updates require
root quid’s guardians (CEO, CISO, COO, auditor), a
signer-level collusion can’t amend the quorum structure.
Residual risk. Sufficient collusion (5+ people) defeats
any quorum. Mitigated by culture, rotation, compensation
design.
T3. Guardian-quorum takeover
Attack. Attacker compromises a signer’s personal guardians
(spouse, manager, backup HSM) and initiates a recovery to an
attacker-controlled key.
Mitigations.
recoveryDelay of 7 days for cold-wallet signers. During
this window, the legit signer (if they’re fine) can veto.
Veto mechanism: any of the personal guardians can veto a
pending recovery if the signer has an out-of-band way to
contact them.
EnableLazyEpochProbe (QDP-0007) means unexpected rotations
fire visible cross-subsidiary events that compliance sees.
Residual risk. Attacker with access to both the signer’s
HSM AND sufficient personal guardians can complete a
recovery. Mitigated by physical security of backup HSMs,
guardian rotation, and periodic re-attestation.
T4. Root quid compromise
Attack. CEO’s phone is stolen + phished. Attacker
initiates a guardian-set update modifying the root’s
structure.
Mitigations.
Root guardians are {CEO, CISO, COO, external auditor},
2 executives + external auditor required for quorum.
External auditor is organizationally independent, phishing
them separately is unlikely.
requireGuardianRotation=true on root means no fast-path.
7-day delay at root level → lots of time for anomaly
detection.
Residual risk. Low; all top-level keys would have to be
simultaneously compromised.
T5. Stale-key attack across subsidiaries
Attack. Attacker gets hold of a signer’s OLD key (pre-
rotation) and tries to use it in a subsidiary that hasn’t
observed the rotation.
Mitigations.
Push gossip (QDP-0005) propagates rotations across
subsidiaries in seconds to minutes.
Lazy epoch probe (QDP-0007) catches the case where
push missed a subsidiary: the receiving node probes the
signer’s home domain before accepting a stale-looking
signature.
MaxAcceptedOldNonce cap (default 100) limits the
grace window.
Residual risk. Window between rotation and propagation
is short and monitorable.
T6. Replay of a signed approval
Attack. Intercepted approval for transfer A replayed as
transfer B.
Mitigations.
Signatures bind to the specific title’s canonical content.
Different content = different signable bytes = signature
mismatch.
Anchor-nonce monotonicity: same nonce can’t appear twice.
Residual risk. None.
T7. On-chain multi-sig contract bug
Attack. The Bitcoin / Ethereum multi-sig contract that
ultimately executes the transfer has a vulnerability.
Mitigations.
This is the on-chain side, not Quidnug’s responsibility.
Quidnug authorizes; the on-chain contract enforces.
Multi-sig contracts are extensively audited and battle-
tested (Gnosis Safe, etc.).
Residual risk. Outside this use case’s scope.
T8. Signer ransomware
Attack. Attacker encrypts a signer’s HSM interface and
demands ransom to unlock.
Mitigations.
Signers have backup HSMs in separate locations.
Guardian recovery lets the firm rotate the ransomware’d
signer to a fresh HSM in under 7 days (or minutes for
hot wallets).
Temporary quorum reduction is possible via guardian-
set update (4-of-6 until the 7th signer is replaced).
Residual risk. Minor operational disruption; no fund loss.
T9. Fork-block abuse
Attack. Executive quorum pushes a fork-block that lowers
quorum thresholds, enabling a later insider attack.
Mitigations.
Fork-block requires 2/3 of domain validators, this is
the consortium governance layer, not an internal-only
decision.
MinForkNoticeBlocks = 1440 (~24h) notice.
External auditor in the executive quorum provides
independent oversight.
Residual risk. Majority-executive collusion. Mitigated
by governance, insurance, and audit.
T10. Regulatory compulsion
Attack. State actor subpoenas the firm’s root signing keys.
Mitigations.
Keys are HSM-protected; the firm cannot “hand over” keys
directly, they can be used but not extracted.
Transfers still require quorum; a compelled executive
signature alone doesn’t meet threshold.
Multi-jurisdictional signers: US subsidiary’s signers
aren’t subject to EU court orders and vice versa.
Residual risk. If enough jurisdictions’ signers are
compelled simultaneously, compulsion can force transfers.
This is the deliberate “compliance with subpoenas” path;
no protocol avoids it.
Not defended against
Off-chain custody (cash, paper certificates). Quidnug
is for cryptographic assets with signed transactions.
User-level social engineering. If an attacker convinces
a signer to actually sign a malicious transfer, the system
works as designed.
Multi-subsidiary collusion. EU + US executives both
corrupt = bigger than protocol-level concern.
Privacy of holdings. On-chain balances are visible;
this is a blockchain property, not something Quidnug
changes.