Overview

Interbank Wire Authorization

FinTech · High-value · M-of-N signing · Guardian recovery

The problem

A mid-sized bank settles ~$2B/day across Fedwire, CHIPS, SWIFT, and a regional faster-payments rail. For wires above a policy threshold (e.g., $1M), internal controls require two separately-credentialed officers to cosign, with a compliance officer review for anything above $10M.

Current production reality at most banks:

• Cosigning is a spreadsheet workflow wrapped around a hardware security module (HSM). The “second signature” is often a scanned approval PDF attached in a ticket.
• When an HSM dies (firmware bug, cert expiry, a staff member departs), remediation is an emergency vendor ticket. Wires pile up.
• Replay protection is transaction-ID uniqueness in the core banking system, which is a single point of contention. If the core is unreachable (e.g., DR failover), two branches can process the same wire twice.
• There’s no cryptographic audit trail of “which officer’s key approved this wire”, only a database row with a user ID.

When an auditor or regulator asks “prove this $50M wire was authorized by two distinct, active officers on that date,” the answer is a screenshot of an SSO login event plus an emailed PDF. Nobody is happy about that.

Why Quidnug fits

The capabilities Quidnug offers line up directly with the primitives a multi-party wire-approval system needs:

A wire approval becomes: a TITLE transaction over the wire instruction, authorized by the bank’s M-of-N guardian set, with each cosigner’s signature at their own monotonically-advancing nonce.

High-level architecture

           ┌─────────────────────────────────────────────┐
           │  Bank Core Banking System (existing)        │
           │  Generates wire instructions                 │
           └──────────────────┬──────────────────────────┘
                              │
                              │  "Submit wire for signing"
                              ▼
    ┌──────────────────────────────────────────────────────┐
    │  Quidnug Bank Node (consortium node #1)               │
    │  ├─ Bank root quid: "bank-us-wire"                    │
    │  ├─ Officer quids: alice-op, bob-op, carol-compliance │
    │  ├─ Guardian set for "bank-us-wire":                  │
    │  │   threshold=2,                                     │
    │  │   members={alice-op(w=1), bob-op(w=1),             │
    │  │            carol-compliance(w=2)}                  │
    │  └─ Domain: "wires.federal.us"                        │
    └──────────────────────────────────────────────────────┘
              │         │         │            │
              │         │         │            │
              ▼         ▼         ▼            ▼
         ┌────────┐ ┌──────┐ ┌──────────┐ ┌─────────┐
         │Alice's │ │Bob's │ │Carol's   │ │ Fed/    │
         │HSM     │ │HSM   │ │HSM       │ │ CHIPS   │
         │(EAST)  │ │(WEST)│ │(Compl.)  │ │ Gateway │
         └────────┘ └──────┘ └──────────┘ └─────────┘

Each officer holds their own HSM-backed signing key. The bank’s node tracks the on-chain guardian set; wire instructions route to officers for signing; signed titles are published to a consortium of peer banks (clearing counterparties, correspondent banks, regulators) that all run Quidnug nodes.

Key Quidnug features used

• GuardianSetUpdate (QDP-0002), declares which officers have approval authority, with weighted thresholds so the compliance officer (weight=2) counts as two regular officers. Every officer in the set must have on-chain consented.
• Per-signer anchor nonces (QDP-0001), each wire approval includes an officer’s anchor-nonce that must strictly advance. A replayed approval from a captured session is rejected at the ledger.
• Guardian-based recovery (QDP-0002 §6.4.4), when Alice’s HSM fails, her coworkers (her personal guardian set, separate from the bank’s approval set) initiate a rotation to a new HSM. The default 1-hour time-lock window is plenty for Alice to veto if she’s at a coffee shop and not actually dead.
• GuardianResignation (QDP-0006), when Alice leaves the bank, she resigns from the approval set. Doesn’t invalidate wires already in flight.
• Lazy epoch probe (QDP-0007), correspondent banks that haven’t seen Alice sign a wire in 30 days probe her home domain before accepting a new approval. Catches the “Alice’s old key was compromised after she rotated but before the counterparty learned of the rotation” attack.
• Fork-block trigger (QDP-0009), when the consortium decides to raise the high-value threshold from $10M to $25M, a fork-block transaction signed by a quorum of member banks activates the new rule at a future height across all participants simultaneously.

Value delivered

Runnable POC

Full end-to-end demo at examples/interbank-wire-authorization/:

• wire_approval.py, pure decision logic: tier selection, weighted signers, role gating, per-signer NonceLedger, counterparty verification.
• wire_approval_test.py, 14 pytest cases across the full decision surface.
• demo.py, seven-step end-to-end flow: install tiered policy, run three wires across the tier boundaries, receiver re-verification, replay-defense demonstration.

cd examples/interbank-wire-authorization
python demo.py

What’s in this folder

• README.md, this document (high-level)
• architecture.md, detailed data model, sequence diagrams, per-component breakdown
• integration.md, how the use case composes on top of the three architectural pillars (QDP-0012 governance, QDP-0013 federation, QDP-0014 discovery + sharding); why each bank is its own network
• operations.md, deployment topology by bank scale (community / regional / national / global), capacity planning, daily ops playbook, incident response, SWIFT/Fedwire/SEPA bridge patterns
• launch-checklist.md, T-180 through T+30 bank-onboarding sequence: legal + regulatory foundation, HSM procurement, governance setup, peer federation, staged rollout to production
• implementation.md, concrete Quidnug API calls with Go and shell examples
• threat-model.md, attacker profiles, what the design defends against, explicit limits

Related

• QDP-0001: Nonce Ledger
• QDP-0002: Guardian Recovery
• QDP-0007: Lazy Epoch Propagation
• QDP-0009: Fork-Block Trigger
• QDP-0012: Domain Governance governor / consortium / cache separation; the mechanism behind per-bank governance quorums
• QDP-0013: Network Federation one-protocol-many-networks; every bank is its own network linked to peers via TRUST_IMPORT
• QDP-0014: Node Discovery + Sharding NODE_ADVERTISEMENT + .well-known/quidnug-network.json for cross-bank counterparty discovery
• UseCases/elections/, companion coordination- archetype use case (same governance + federation + discovery story, different deployment profile)

Out of scope for this design

• Actual settlement finality. Quidnug authorizes; the Fedwire / CHIPS / SWIFT gateway still settles. This design is the approval and audit layer, not replacement for the rails.
• AML/KYC on the payee. Standard compliance tooling still runs; the Quidnug layer attests that the bank’s internal controls were followed.
• Encryption of wire contents. All signed data is in the open on the consortium chain. A production system would encrypt the wire payload and store a hash on-chain, decrypting via a separate key-management flow. That’s a design axis orthogonal to trust.

Architecture: Interbank Wire Authorization

Participants

Domain structure

wires.federal.us          (main domain, bank's approval flow)
├── wires.fed.chips.us    (CHIPS-specific quorum rules)
├── wires.fed.fedwire.us  (Fedwire-specific)
└── wires.international.swift  (SWIFT, international)

Each sub-domain can have its own validator threshold and its own approval quorum, a CHIPS wire may require a different officer set than a SWIFT wire.

Identity hierarchy

                     ┌──────────────────────┐
                     │   bank-us-wire       │  (root bank quid)
                     │   GuardianSet:       │  Recovers ROOT.
                     │   {CEO, CFO, legal}  │  Threshold 2-of-3.
                     └──────────┬───────────┘
                                │
              ┌─────────────────┼─────────────────┐
              │                 │                 │
              ▼                 ▼                 ▼
        ┌──────────┐      ┌──────────┐     ┌────────────────┐
        │ alice-op │      │ bob-op   │     │carol-compliance│
        │          │      │          │     │                │
        │Guardian: │      │Guardian: │     │Guardian:       │
        │{spouse,  │      │{spouse,  │     │{spouse, mgr,   │
        │ mgr,     │      │ mgr,     │     │ legal}         │
        │ bkup HSM}│      │ bkup HSM}│     │                │
        └──────────┘      └──────────┘     └────────────────┘

Officers’ personal guardian sets are separate from the bank’s approval set. Two distinct concerns:

• Bank approval set (GuardianSet for bank-us-wire): who can sign wires on the bank’s behalf. Weighted: Alice(1), Bob(1), Carol(2). Threshold: 2.
• Individual recovery sets (one per officer quid): who can recover for Alice if her HSM fails. Personal, Alice picks her own guardians.

Data flow: wire approval

┌─────────────────────────────────────────────────────────────────┐
│ Step 1. Core banking produces a wire instruction                 │
│   { payer, payee, amount, ref, date, rail }                      │
└─────────────────────────────────────────────────────────────────┘
                                 │
                                 ▼
┌─────────────────────────────────────────────────────────────────┐
│ Step 2. Pre-flight checks (amount → required quorum)             │
│                                                                   │
│   amount < 1M  → 1 signer required                               │
│   amount < 10M → 2 signers required                              │
│   amount ≥ 10M → compliance mandatory (carol-compliance)         │
└─────────────────────────────────────────────────────────────────┘
                                 │
                                 ▼
┌─────────────────────────────────────────────────────────────────┐
│ Step 3. Wire titled on-chain (first signer)                      │
│                                                                   │
│   POST /api/v1/titles                                            │
│   {                                                              │
│     assetId: "wire-2026-04-18-xyz",                              │
│     domain: "wires.fed.fedwire.us",                              │
│     owners: [{ ownerId: "bank-us-wire", percentage: 100 }],      │
│     attributes: {                                                │
│       payer: "...", payee: "...", amount: "50000000",            │
│       rail: "FEDWIRE", ref: "..."                                │
│     },                                                           │
│     signatures: { "alice-op": <sig_alice_nonce_5> }              │
│   }                                                              │
└─────────────────────────────────────────────────────────────────┘
                                 │
                                 ▼
┌─────────────────────────────────────────────────────────────────┐
│ Step 4. Second signer appends an event                           │
│                                                                   │
│   POST /api/v1/events                                            │
│   {                                                              │
│     subjectId: "wire-2026-04-18-xyz",                            │
│     subjectType: "TITLE",                                        │
│     eventType: "wire.cosign",                                    │
│     payload: { signerQuid: "bob-op", keyEpoch: 0 },              │
│     signature: <sig_bob_nonce_N>  (Bob's monotonically-advancing │
│                                   anchor nonce, not wire nonce)  │
│   }                                                              │
└─────────────────────────────────────────────────────────────────┘
                                 │
                                 ▼
┌─────────────────────────────────────────────────────────────────┐
│ Step 5. Compliance review (if required)                          │
│                                                                   │
│   Same shape as Step 4, but signerQuid = carol-compliance and    │
│   weight=2 counts toward threshold.                              │
└─────────────────────────────────────────────────────────────────┘
                                 │
                                 ▼
┌─────────────────────────────────────────────────────────────────┐
│ Step 6. Quorum check (node-side)                                 │
│                                                                   │
│   Sum of signer weights ≥ threshold AND                          │
│   every signer validly in the current GuardianSet AND            │
│   every signer's nonce strictly advances AND                     │
│   all signatures verify against current epoch keys.              │
│                                                                   │
│   If ✓: emit "wire.approved" event. The core banking system      │
│   polls for the approved event and instructs the rail.           │
└─────────────────────────────────────────────────────────────────┘
                                 │
                                 ▼
┌─────────────────────────────────────────────────────────────────┐
│ Step 7. Settlement confirmation (external rail)                  │
│                                                                   │
│   Core banking system calls back with settlement ID; another     │
│   event appended to the wire's stream:                           │
│                                                                   │
│   eventType: "wire.settled",                                     │
│   payload: { fedReference: "...", timestamp: ... }               │
└─────────────────────────────────────────────────────────────────┘

Data flow: HSM failure recovery

Alice’s HSM dies at 3am. Incident:

[t=0]   Alice's HSM enters fault state. All new signing fails.
        Node's lazy-epoch probe to peers may start flagging
        "Alice hasn't signed in N min", operational signal only.

[t+10m] Ops confirms HSM is bricked. Initiates guardian recovery.

        POST /api/v2/guardian/recovery/init
        {
          kind: "guardian_recovery_init",
          subjectQuid: "alice-op",
          fromEpoch: 0, toEpoch: 1,
          newPublicKey: <hex from Alice's backup HSM or new token>,
          minNextNonce: <current+1>,
          maxAcceptedOldNonce: <current>,
          anchorNonce: <alice's anchor-nonce + 1>,
          validFrom: <now>,
          guardianSigs: [
            { guardianQuid: "alice-spouse", keyEpoch: 0, signature: ... },
            { guardianQuid: "alice-mgr",    keyEpoch: 0, signature: ... },
          ]
          // Alice's personal M-of-N recovery quorum met (2-of-3)
        }

[t+11m] Recovery accepted. Time-lock delay begins (default 1 hour).
        PendingRecovery stored; Alice can veto if she's actually fine.

[t+1h11m] No veto. Commit transaction lands automatically or is
        explicitly POSTed. Alice's currentEpoch advances to 1;
        new HSM's key is authoritative going forward.

[t+1h12m] Any in-flight wire approvals signed under the OLD epoch
        within the MaxAcceptedOldNonce window still settle. After
        that cap, old-epoch signatures are rejected.

Wires that Alice had partially approved before the HSM failure complete via the original signatures, the rotation doesn’t retroactively invalidate her prior valid approvals.

Data flow: officer departure

Alice leaves the bank. Three things happen:

1. GuardianSetUpdate on bank-us-wire, remove Alice from the approval set. Requires: bank’s root-quid signature + current approval-set quorum (2 of {Alice, Bob, Carol}).

   Since Alice is the one leaving, the remaining signers (Bob + Carol) approve. Alice can opt to sign too or not, the threshold is already met without her if Carol(w=2) signs with Bob(w=1).

2. GuardianResignation, Alice can optionally withdraw from her own role proactively. Not strictly required since the set update removes her, but documents her exit in the chain.

3. Alice’s personal quid lives on, in case any wires she signed before departure need post-hoc auditing. Her currentEpoch is frozen (invalidation anchor); no new approvals from her key work.

Quorum math edge cases

Weighted threshold with compliance

GuardianSet:
  { alice-op (w=1), bob-op (w=1), carol-compliance (w=2) }
  threshold: 2

• Alice + Bob → 2. ✓
• Alice + Carol → 3. ✓ (over-threshold is fine)
• Carol alone → 2. ✓ (compliance officer’s weight covers the threshold alone, this is deliberate for $10M+ wires where the bank’s policy lets compliance unilaterally authorize; check if that’s actually what you want or if threshold should be 3)

To prevent the “Carol alone” case, raise threshold to 3:

threshold: 3

Now Carol alone (w=2) is insufficient; a line officer must also sign.

Weighted threshold with distrust of Carol

If the bank policy is that compliance is a check-and-balance (not a unilateral approver), set threshold=3 and keep Carol at w=2. Means compliance can’t act alone; always requires an operator.

Consortium trust graph

Correspondent banks operate their own nodes. The trust setup:

bank-us-wire ──0.95──► bank-correspondent-london
    ▲
    │ 0.9
    │
bank-us-wire ──0.85──► bank-regulator-occ  (regulator observer)
    ▲
    │ 0.8
    │
bank-us-wire ──0.7──► small-counterparty-bank  (smaller party)

From the correspondent’s perspective, when they receive a wire title and event stream claiming the bank approved it, they verify:

1. Every signer is in bank-us-wire’s current GuardianSet as of the approval’s block height.
2. Every signature verifies against the signer’s current-epoch key (from the blockchain’s identity registry).
3. Nonces are monotonic.
4. Threshold is met.

If the correspondent hasn’t seen the bank’s recent guardian-set updates (partition, just rejoined the network), push gossip (QDP-0005) delivers them on demand, and the lazy-epoch probe (QDP-0007) catches edge cases.

Scale estimates

Typical US mid-sized bank:

• 2,000 high-value wires/day
• 50 authorized approval officers across regions
• 5 compliance officers
• ~20 correspondent bank peers

Workload on a single Quidnug node:

• 2,000 titles/day = ~100 KB/day in titles
• ~6,000 events/day (avg 3 signatures per wire)
• ~100 KB/day peer gossip for inter-bank propagation

Quidnug’s consortium-scale target (thousands of TPS with many correspondents) is comfortable headroom above this workload.

Next

See implementation.md for concrete code, threat-model.md for security analysis.

Implementation: Interbank Wire Authorization

Concrete Quidnug API calls for a working implementation. Examples in cURL and Go. Real production code would use signed HSM outputs; here we use ECDSA keys generated by the Quidnug client for clarity.

0. Prerequisites

A Quidnug node running with the nonce ledger enabled:

ENABLE_NONCE_LEDGER=true \
ENABLE_PUSH_GOSSIP=true \
ENABLE_LAZY_EPOCH_PROBE=true \
NODE_AUTH_SECRET=<32-byte hex> \
./bin/quidnug

1. Bootstrap identities

Create quids for the bank, three officers, and each officer’s personal guardian (spouse, manager, backup HSM, we’ll reuse a single quid per role for brevity here; production would be distinct real people).

# Bank root quid
curl -X POST http://localhost:8080/api/identities -d '{
  "quidId": "bank-us-wire",
  "name": "US Wire Bank",
  "creator": "bank-us-wire",
  "updateNonce": 1,
  "homeDomain": "wires.federal.us"
}'

# Officers
for who in alice-op bob-op carol-compliance; do
  curl -X POST http://localhost:8080/api/identities -d "{
    \"quidId\": \"$who\",
    \"name\": \"$who\",
    \"creator\": \"bank-us-wire\",
    \"updateNonce\": 1,
    \"homeDomain\": \"wires.federal.us\"
  }"
done

2. Install the bank’s approval guardian set

Every officer in the new set must have consented on-chain. The bank’s root signature + consent sigs are assembled by whatever ceremony the bank runs (in-person, quarterly, with HSMs).

package main

import (
    "context"
    "encoding/hex"
    "encoding/json"
    "net/http"
    "bytes"
    "time"

    "github.com/quidnug/quidnug/internal/core"
)

func installBankApprovalSet(apiBase string) error {
    // Build the new set.
    newSet := core.GuardianSet{
        Guardians: []core.GuardianRef{
            {Quid: "alice-op",          Weight: 1, Epoch: 0},
            {Quid: "bob-op",            Weight: 1, Epoch: 0},
            {Quid: "carol-compliance",  Weight: 2, Epoch: 0},
        },
        Threshold:     3,                       // Carol alone insufficient
        RecoveryDelay: 1 * time.Hour,
    }

    update := core.GuardianSetUpdate{
        Kind:        core.AnchorGuardianSetUpdate,
        SubjectQuid: "bank-us-wire",
        NewSet:      newSet,
        AnchorNonce: 1,
        ValidFrom:   time.Now().Unix(),
    }

    // Signable canonical bytes (same for bank, each new guardian,
    // and any current-set approvers).
    signable, _ := core.GuardianSetUpdateSignableBytes(update)

    // Bank root signs (primary signature).
    update.PrimarySignature = &core.PrimarySignature{
        KeyEpoch:  0,
        Signature: signWithHSM("bank-us-wire", signable),
    }

    // Each guardian signs consent.
    for _, g := range []string{"alice-op", "bob-op", "carol-compliance"} {
        update.NewGuardianConsents = append(update.NewGuardianConsents,
            core.GuardianSignature{
                GuardianQuid: g,
                KeyEpoch:     0,
                Signature:    signWithHSM(g, signable),
            })
    }

    // First install, no current-set guardians yet. Subsequent updates
    // would also include CurrentGuardianSigs.

    body, _ := json.Marshal(update)
    resp, err := http.Post(apiBase+"/api/v2/guardian/set-update",
        "application/json", bytes.NewReader(body))
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    if resp.StatusCode != http.StatusAccepted {
        return fmt.Errorf("install: %d", resp.StatusCode)
    }
    return nil
}

// signWithHSM is a stub; production calls into PKCS#11 / AWS KMS / etc.
func signWithHSM(quid string, data []byte) string {
    return hex.EncodeToString(make([]byte, 64))
}

Verify:

curl http://localhost:8080/api/v2/guardian/set/bank-us-wire

3. Submit a wire for approval

A $50M wire requires compliance (weight=2) + an operator. Three step sequence:

3a. Title the wire (first signer, Alice)

curl -X POST http://localhost:8080/api/v1/titles -d '{
  "type": "TITLE",
  "assetId": "wire-2026-04-18-xyz",
  "domain": "wires.fed.fedwire.us",
  "owners": [{
    "ownerId": "bank-us-wire",
    "percentage": 100.0
  }],
  "titleType": "wire.instruction",
  "attributes": {
    "payer": "bank-us-wire",
    "payee": "recipient-abc",
    "amount": "50000000",
    "currency": "USD",
    "rail": "FEDWIRE",
    "reference": "WIRE-2026-04-18-XYZ-001",
    "valueDate": "2026-04-19"
  },
  "creator": "alice-op",
  "signatures": {
    "alice-op": "<hex signature over canonical title bytes>"
  }
}'

Alice’s signature uses her current-epoch key and her anchor nonce + 1. The anchor nonce is separate from the wire’s internal sequence, it’s a per-officer monotonic counter.

3b. Cosign via event (Bob)

curl -X POST http://localhost:8080/api/v1/events -d '{
  "type": "EVENT",
  "subjectId": "wire-2026-04-18-xyz",
  "subjectType": "TITLE",
  "eventType": "wire.cosign",
  "payload": {
    "signerQuid": "bob-op",
    "keyEpoch": 0,
    "anchorNonce": 47
  },
  "creator": "bob-op",
  "signature": "<hex signature>"
}'

3c. Compliance review (Carol, if amount ≥ $10M)

curl -X POST http://localhost:8080/api/v1/events -d '{
  "type": "EVENT",
  "subjectId": "wire-2026-04-18-xyz",
  "subjectType": "TITLE",
  "eventType": "wire.compliance_approved",
  "payload": {
    "signerQuid": "carol-compliance",
    "keyEpoch": 0,
    "anchorNonce": 124,
    "complianceNotes": "KYC up to date; sanctions clear"
  },
  "creator": "carol-compliance",
  "signature": "<hex signature>"
}'

3d. Node quorum validation (automatic)

On each wire.cosign / wire.compliance_approved event, your application-side listener computes the current signer weights:

func quorumMet(wireID string, ledger *core.NonceLedger, now time.Time) (bool, error) {
    // 1. Get the bank's effective guardian set (post-resignations).
    set := ledger.EffectiveGuardianSet("bank-us-wire", now)

    // 2. Read the wire's event stream.
    events, err := readEvents(wireID, "TITLE")
    if err != nil {
        return false, err
    }

    // 3. Accumulate signer weights among valid cosigns.
    signers := map[string]bool{}
    var weight uint32
    for _, ev := range events {
        if ev.EventType != "wire.cosign" && ev.EventType != "wire.compliance_approved" {
            continue
        }
        quid := ev.Payload["signerQuid"].(string)
        if signers[quid] {
            continue // duplicate cosign; don't double-count
        }
        for _, g := range set.Guardians {
            if g.Quid == quid && g.Weight > 0 {
                weight += uint32(g.Weight)
                signers[quid] = true
                break
            }
        }
    }

    return weight >= uint32(set.Threshold), nil
}

When quorum is met, emit an wire.approved event, the external settlement system picks this up.

4. Officer key rotation (planned)

Alice proactively rotates her key every 90 days (bank policy).

# Generate new keypair in backup HSM, publish the new public key.
curl -X POST http://localhost:8080/api/anchors -d '{
  "kind": "rotation",
  "signerQuid": "alice-op",
  "fromEpoch": 0,
  "toEpoch": 1,
  "newPublicKey": "<hex of new ECDSA P-256 pubkey>",
  "minNextNonce": 101,
  "maxAcceptedOldNonce": 100,
  "anchorNonce": 51,
  "validFrom": <now>,
  "signature": "<signed with CURRENT epoch-0 key>"
}'

maxAcceptedOldNonce caps how many more old-epoch anchors are admitted, zero means “no grace window.”

5. HSM failure recovery

Alice’s HSM failed. Her personal guardians (spouse quid, manager quid, backup HSM quid) initiate recovery.

curl -X POST http://localhost:8080/api/v2/guardian/recovery/init -d '{
  "kind": "guardian_recovery_init",
  "subjectQuid": "alice-op",
  "fromEpoch": 0,
  "toEpoch": 1,
  "newPublicKey": "<hex of Alice'\''s new HSM pubkey>",
  "minNextNonce": 101,
  "maxAcceptedOldNonce": 0,
  "anchorNonce": 52,
  "validFrom": 1713400000,
  "guardianSigs": [
    { "guardianQuid": "alice-spouse", "keyEpoch": 0, "signature": "..." },
    { "guardianQuid": "alice-mgr",    "keyEpoch": 0, "signature": "..." }
  ]
}'

This opens a 1-hour time-lock window. If the recovery is malicious (e.g., Alice’s spouse’s key was compromised and it’s a social- engineering attempt on the bank), Alice can veto from her original HSM if it’s still alive, or, if the HSM is confirmed dead, the bank can halt the recovery via its oversight quorum.

After 1 hour, any party can submit commit:

curl -X POST http://localhost:8080/api/v2/guardian/recovery/commit -d '{
  "kind": "guardian_recovery_commit",
  "subjectQuid": "alice-op",
  "recoveryAnchorHash": "<hash of the init>",
  "anchorNonce": 53,
  "validFrom": <now>,
  "committerQuid": "alice-mgr",
  "committerSig": "<sig>"
}'

Alice’s currentEpoch advances to 1 on accepted block. Future wire approvals must use the new key.

6. Officer departure

Alice is leaving. Two signed operations:

6a. Remove from approval set

Build a GuardianSetUpdate for bank-us-wire with the new set excluding Alice. Bank root signs + current-set quorum (Bob + Carol) consents.

6b. Alice resigns her personal recovery role (if she was a

guardian for any other officer)

curl -X POST http://localhost:8080/api/v2/guardian/resign -d '{
  "kind": "guardian_resign",
  "guardianQuid": "alice-op",
  "subjectQuid": "bob-op",
  "guardianSetHash": "<sha256 of bob-op'\''s current set>",
  "resignationNonce": 1,
  "effectiveAt": <now + 7 days>,
  "signature": "<alice signs>"
}'

Effective 7 days out, gives Bob time to add a replacement guardian.

7. Consortium policy change: raise threshold to $25M

The industry group agrees to raise the compliance-mandatory threshold from $10M to $25M. Coordinate via fork-block at a future height:

# Quorum of consortium members (not just one bank) sign this.
curl -X POST http://localhost:8080/api/v2/fork-block -d '{
  "trustDomain": "wires.federal.us",
  "feature": "enable_nonce_ledger",   /* sample, real change would be app-level */
  "forkHeight": 123456,               /* ~24h away */
  "forkNonce": 1,
  "proposedAt": 1713400000,
  "signatures": [
    { "validatorQuid": "bank-us-wire",         "keyEpoch": 0, "signature": "..." },
    { "validatorQuid": "bank-correspondent-ldn","keyEpoch": 0, "signature": "..." },
    { "validatorQuid": "bank-regulator-occ",   "keyEpoch": 0, "signature": "..." }
  ]
}'

At block 123456 every participating node flips its policy deterministically, no out-of-band coordination.

8. Audit report: “prove this wire’s approval chain”

# 1. Get the wire title with its approval events.
curl http://localhost:8080/api/v1/titles/wire-2026-04-18-xyz
curl http://localhost:8080/api/v1/events/TITLE/wire-2026-04-18-xyz

# 2. Get the guardian set as of the block that contained the title.
curl http://localhost:8080/api/v2/guardian/set/bank-us-wire

# 3. Verify each signer's signature against their current-epoch key
#    at the time (use the identity registry's historical view).

A single audit tool can reassemble: “at block 100,000, on date 2026-04-18, bank-us-wire’s guardian set was X, the wire was signed by {alice-op@e=0, bob-op@e=0, carol-compliance@e=0} at their respective monotonic nonces, quorum weight = 4 ≥ threshold 3, therefore the approval was valid.”

9. Monitoring

Key Prometheus metrics to alert on:

• quidnug_guardian_set_weakened_total{subject="bank-us-wire"} rising → officers are resigning faster than replacements arrive.
• quidnug_guardian_resignations_rejected_total{reason="set_hash_mismatch"} → someone is trying stale resignations (integration bug or attack).
• quidnug_nonce_replay_rejections_total{enforced="true"} rising → replay attempts, investigate.
• quidnug_probe_failure_total on a correspondent bank → they’re having trouble seeing our rotations; may need to reach out operationally.

10. Testing

Integration test skeleton:

func TestInterbankWire_HappyPath(t *testing.T) {
    node := newTestNode()
    node.NonceLedgerEnforce = true

    // Install bank set.
    installTestBankSet(t, node)

    // Submit wire title.
    wireID := "wire-test-1"
    submitTitle(t, node, wireID, 50_000_000, "alice-op")

    // Cosign events.
    submitCosignEvent(t, node, wireID, "bob-op", 47)
    submitCosignEvent(t, node, wireID, "carol-compliance", 124)

    // Quorum check.
    ok, err := quorumMet(wireID, node.NonceLedger, time.Now())
    if err != nil { t.Fatal(err) }
    if !ok { t.Fatal("quorum should be met: alice(1) + bob(1) + carol(2) = 4 >= 3") }
}

func TestInterbankWire_ComplianceAlone_BelowThreshold(t *testing.T) {
    // threshold = 3, Carol alone = 2
    // → not approved
}

func TestInterbankWire_ReplayRejected(t *testing.T) {
    // Submit the same cosign event twice; second rejected.
}

Where to go next

• threat-model.md, security analysis and known limits.
• ../ai-agent-authorization/, same pattern adapted to AI agents instead of bank officers.
• QDP-0002 §6.4.4 deep dive on the guardian-set-update authorization rules.

Threat Model: Interbank Wire Authorization

Assets

1. Wire authorization authority, the ability to cause funds to move via the settlement rails.
2. Approval audit trail, the cryptographic record of who approved what, when.
3. Officer signing keys, HSM-protected keys whose compromise enables unauthorized wire approval.
4. Bank’s root quid, the identity that controls the approval guardian set itself; compromising it enables swapping in attacker-controlled officers.

Attackers

Threats and mitigations

T1. External forgery of a wire approval

Attack. Attacker with no insider access tries to submit a wire title claiming to be signed by Alice.

Mitigation.

• Every signature verifies against signerKeys[alice-op][alice's current epoch], attacker doesn’t have Alice’s HSM.
• Monotonic nonce means even a replay of a captured valid signature is rejected (nonce already accepted).
• Even if the attacker has network access, the NODE_AUTH_SECRET HMAC gates inter-node traffic.

Residual risk. None structural. Reduces to “can the attacker compromise an HSM”, which is the endpoint security problem, not a protocol problem.

T2. Captured session replay

Attack. Attacker intercepts Alice’s valid approval for wire A and replays it as approval for wire B.

Mitigation.

• The signature binds to the specific wire title’s content. Replaying Alice’s wire-A signature against wire-B produces a signature that doesn’t match wire-B’s canonical bytes.
• Anchor-nonce monotonicity: even if the attacker crafts wire B to have identical bytes (unlikely given amount/payee/timestamp), the nonce has already been accepted.

Residual risk. None.

T3. Single compromised officer HSM

Attack. Alice’s HSM is compromised. Attacker has one signing key.

Mitigation.

• Wire still requires threshold 3. Alice alone = weight 1. Attacker also needs another compromise.
• Alice’s anchor nonce is monotonic. If Alice notices unusual activity and rotates via her personal guardian recovery, the old key is immediately unable to sign new wires.
• MaxAcceptedOldNonce cap on rotation limits the window.

Residual risk. If attacker compromises Alice AND Bob before anyone notices, they reach threshold 2 (w=1+1). Still under 3. Need Alice+Bob+Carol or Alice+Carol or Bob+Carol to reach 3+ with w=2 Carol. So: two or three simultaneous compromises required depending on who’s compromised. This is a significantly higher bar than “one compromise.”

T4. Compliance officer collusion

Attack. Carol (weight=2) collaborates with Alice (weight=1) to steal. Their combined weight (3) meets threshold.

Mitigation (partial, organizational).

• Weight distribution is a policy decision. The design doc’s threshold=3 setup specifically addresses this by requiring three parties (Carol + Alice + Bob) for any wire. If the bank wants the weaker property, it picks threshold=2.
• If threshold=3, Carol and Alice alone = 3 (w=2+1) does meet threshold. The fix is threshold=4 with compliance staying at w=2, requires two operators AND compliance.

Residual risk. Protocol cannot prevent quorum-of-allowed-parties collusion by design. Standard corporate governance (separation of duties, rotation, background checks) is the countermeasure.

T5. Attacker compromises bank root quid

Attack. The root quid that controls the approval set is compromised. Attacker adds their own key to the approval set and drains the bank.

Mitigation.

• Root quid has its own guardian set (CEO, CFO, legal). A GuardianSetUpdate for bank-us-wire requires primary signature (root’s current-epoch key) AND current-set consent quorum.
• Root-quid key compromise requires also compromising multiple executive guardians, far above the single-key-compromise bar.
• Even if achieved, the GuardianSetUpdate lands on the blockchain and the anomaly is auditable.

Residual risk. Low; this is the “CEO gets phished” scenario where traditional controls (executive HSMs with in-person use, quarterly attestation) apply.

T6. Guardian takeover

Attack. Alice’s personal guardians (spouse, manager, backup HSM) are all compromised. Attacker initiates a recovery to their own key.

Mitigation.

• Time-lock delay: default 1 hour, configurable up to 1 year. The legitimate Alice (if her key is fine) can veto during the window.
• EnableLazyEpochProbe (QDP-0007) means correspondent banks probe on stale signers. An unexpected recovery fires visible events.
• Guardian RequireGuardianRotation flag can be set on officer quids, forcing any rotation to go through the time-locked recovery path, so there’s no “fast path” recovery for high- value officers.

Residual risk. An attacker with guardian quorum AND the ability to prevent Alice from vetoing (e.g., Alice is on a plane for 12 hours) can complete a recovery. Mitigation: longer delay for high-value officers; compensating monitoring.

T7. Correspondent bank lies

Attack. Correspondent bank claims they received a valid approval from us; actually they got half-signed state and are trying to collect on an unapproved wire.

Mitigation.

• Wire isn’t “approved” until the event stream has a quorum. The correspondent can re-verify our guardian set and weigh signatures independently, they have all the public state.
• Push gossip + fingerprints ensure both sides see the same state.

Residual risk. If correspondent also has their own internal gaps, that’s their problem; they can’t forge our approval without cryptographic material they don’t have.

T8. Fork-block hijack

Attack. A malicious quorum of consortium members passes a fork-block lowering the compliance threshold, enabling easier theft.

Mitigation.

• Fork-block requires 2/3 (ceiling) of validators in the domain. Compromising a majority of banks’ root keys is the prerequisite orders of magnitude above compromising one officer.
• MinForkNoticeBlocks = 1440 (~24h) means any change is visible to every participant for 24 hours before activation. Operators can observe a malicious fork in advance and halt their nodes.
• Post-activation, a future fork can roll back. Nothing is permanent unless the consortium says so.

Residual risk. Requires majority-validator compromise. At that point the consortium has bigger problems.

T9. Denial-of-service on the approval flow

Attack. Attacker floods the node with fake approval submissions to keep legitimate ones from being processed.

Mitigation.

• IP-level rate limiting (per-IP token bucket).
• NODE_AUTH_SECRET gates inter-node traffic; external floods can’t affect gossip.
• Dedup-first validation on gossip means replayed valid messages cost ~1 map lookup each.
• Push-gossip producer rate limiter (QDP-0005 §7) throttles any single party.

Residual risk. A well-provisioned attacker can cause resource exhaustion against a single node, but not corrupt state.

T10. Supply-chain compromise

Attack. A Quidnug dependency (Go stdlib, Gorilla mux, Prometheus client) has a backdoor that exfiltrates signing keys.

Mitigation.

• Dependencies are minimal; see go.mod.
• Keys never leave HSMs in the designed flow. A dependency compromise can see signable bytes but not signing material.
• Apache-2.0 includes explicit patent grant; no custom crypto.
• Reproducible builds (TODO for the project) would help detect tampering.

Residual risk. Standard supply-chain risk level, comparable to any Go binary running in production. Mitigated by standard practices.

Not defended against

Explicit limits of this design:

1. Off-chain policy enforcement. The protocol authorizes wires; it doesn’t sanity-check the payee’s sanctions status. That’s OFAC / application-layer concern.

2. Rail-level double-spends. Quidnug says “this wire is approved.” If your core banking system then tries to send the same approval to Fedwire twice, Fedwire’s own idempotency keys should catch it. Quidnug doesn’t try to control the rails.

3. Insider with root-quid access. If the bank’s CEO actively participates in fraud, the protocol documents the crime beautifully but doesn’t prevent it. Standard corporate governance is needed.

4. HSM implementation bugs. If the HSM’s P-256 implementation has a known weakness (e.g., biased nonce during ECDSA sign), the protocol’s correctness doesn’t save you. Use good HSMs.

5. Long-range chain rewrites. Since Quidnug’s consensus is relational, a node could theoretically accept a re-written history from a very-trusted peer. Mitigation: audit logs, the ledger’s monotonic nonce invariants, and operator vigilance. Not a cryptographic guarantee the way Bitcoin’s is.

6. Confidentiality. Wire contents are public on the consortium chain in this design. Production would encrypt payloads and store hashes on-chain. See §“Out of scope” in README.md.

Residual monitoring

Run Prometheus scrapes on:

• quidnug_guardian_resignations_total, spikes suggest an insider mass-exit.
• quidnug_guardian_set_weakened_total, structural vulnerability opening.
• quidnug_nonce_replay_rejections_total{enforced="true"}, attack attempts.
• quidnug_gossip_rate_limited_total, compromised peer flooding.
• quidnug_probe_failure_total, network partition isolating a correspondent (could be precursor to forged-approval attack).

Incident response playbook

1. Officer key suspected compromised.

   • Page on-call HSM operator.
   • Run POST /api/anchors invalidation on the compromised epoch (freeze it). Zero tolerance for maxAcceptedOldNonce.
   • Guardian-set update removing the officer from approval quorum.
   • If no rotation possible: guardian recovery with shortest permitted delay.

2. Bank root quid compromise suspected.

   • Halt all nodes (operator switch, not protocol).
   • Re-verify guardian-set state.
   • Initiate root-quid rotation via executive guardian quorum.
   • Audit all recent guardian-set changes for unauthorized modifications.

3. Unexpected fork-block transaction observed.

   • Review signatures on the fork-block tx.
   • If quorum is legitimate: communicate with consortium.
   • If quorum involves suspect validator signatures: file an emergency-halt request with the consortium. Each node can independently refuse to activate the feature by operator override.

References

• QDP-0002 §13 Threat Model
• QDP-0001 §3.2 Attacker Model
• SECURITY.md

Interbank wire authorization integration with the three architectural pillars

How the interbank-wire use case composes on top of the three architectural QDPs (0012 Domain Governance, 0013 Network Federation, 0014 Node Discovery + Sharding). Companion to README.md + architecture.md, which predate the pillars and describe the wire-authorization mechanics without addressing the larger protocol architecture.

Read the pillar operator-facing summaries first: deploy/public-network/governance-model.md, deploy/public-network/federation-model.md, deploy/public-network/sharding-model.md.

1. What’s new here vs. elections

The interbank-wire-authorization use case is structurally similar to elections: coordination-archetype, multi-party governance, guardian-recoverable keys, auditable event streams. But the deployment profile is fundamentally different:

So the integration needs emphasize: federation (every bank is its own network), discovery (finding the right node for a counterparty’s transaction at wire time), and governance (changes to signatory rosters need explicit on-chain action, not ad-hoc spreadsheets).

2. QDP-0012 governance, every bank is its own governing body

2.1 The domain + governance shape

Each bank is an operator with its own domain tree:

bank.<id>                              (the bank's root domain)
    ├── wires.outbound                 (wires originated by this bank)
    ├── wires.inbound                  (wires received by this bank)
    ├── signatories                    (who's authorized to cosign)
    ├── audit                          (compliance log)
    └── peering.counterparty-banks     (trust edges to other banks)

For bank.chase, the governance structure:

Domain: bank.chase.wires.outbound
  governors:
    chase-chief-executive-quid         weight=3
    chase-chief-compliance-quid        weight=2
    chase-chief-risk-quid              weight=2
    fed-reserve-monitor-quid           weight=2   # regulator observer
  governanceQuorum: 0.7   # 7 of 9 weighted
  notice period: 24 hours normally; 1h emergency clause for REMOVE_VALIDATOR

  consortium (validators):
    node-chase-ny-primary              weight=1
    node-chase-london-primary          weight=1
    node-chase-sg-primary              weight=1
  validatorTrustThreshold: 0.67  # 2-of-3 blocks accepted

  cache replicas:
    node-chase-ny-cache-1..5
    node-chase-london-cache-1..3
    node-chase-sg-cache-1..2
    (plus any read-only observer node the regulator runs)

Crucially, the regulator (fed-reserve-monitor-quid) is a governor, not a validator. They can vote on governance changes + observe every transaction, but they don’t produce blocks. This distinction matters: regulators need visibility + authority-to-block-bad-changes but shouldn’t hold block- production keys (that’s the bank’s operational concern).

2.2 Signatory quorum as a domain property

A wire transfer needs M-of-N cosigning from authorized bank employees. Instead of hardcoding this in application logic, the signatory quorum is a governance property of the bank.chase.wires.outbound domain:

{
  "domain": "bank.chase.wires.outbound",
  "signatoryQuorum": {
    "minSigners": 2,
    "minTotalWeight": 3,
    "requiredRoles": ["wire-officer", "compliance-officer"],
    "maxSigners": 5
  },
  "signatoryPool": {
    "wire-officer-alice-quid": { "weight": 1, "role": "wire-officer" },
    "wire-officer-bob-quid":   { "weight": 1, "role": "wire-officer" },
    "compliance-carol-quid":   { "weight": 2, "role": "compliance-officer" },
    "vp-david-quid":           { "weight": 2, "role": "vp-operations" }
  }
}

Any addition / removal / weight change to the signatory pool is a DOMAIN_GOVERNANCE action (QDP-0012), signed by the bank’s governor quorum, subject to the 24-hour notice period. This is the critical protection against insider attack: a compromised wire-officer can’t silently add a co-conspirator; that change takes 24 hours + signatures from multiple governors.

2.3 Wire-specific governance actions

Three wire-specific actions extend the standard QDP-0012 set:

Each action takes effect after the notice period. During the notice window, the old policy remains active; the old signatories can continue cosigning pending wires. This ensures no in-flight wires are orphaned by a signatory-pool change.

3. QDP-0013 federation, every bank is its own network

3.1 The federation topology

Every bank runs its own Quidnug network. Cross-bank wires federate bilaterally:

            ┌─────────────────┐      federation       ┌─────────────────┐
            │  Bank A network │◄────────────────────►│  Bank B network │
            │  bank.chase.*   │   TRUST_IMPORT for    │ bank.deutsche.* │
            │                 │   counterparty        │                 │
            │  own consortium │   attestations        │  own consortium │
            │  own governors  │                        │  own governors  │
            └─────────────────┘                        └─────────────────┘
                     ▲                                          ▲
                     │                                          │
                     │ federation                   federation │
                     │                                          │
                     ▼                                          ▼
            ┌──────────────────────────────────────────────────────────┐
            │    Correspondent bank network (or SWIFTnet bridge)      │
            │    federates between pairs of origination banks         │
            └──────────────────────────────────────────────────────────┘

Each bank operator independently runs their consortium, holds their own keys, and manages their own domain tree. What federation adds is the ability to cross-reference attestations between networks.

3.2 Three federation use cases

Use case 1: a wire originated at Bank A, destined to Bank B. Bank A’s network publishes a WIRE_AUTHORIZED event. Bank B’s network federates with Bank A’s to verify:

• Wire came from a signatory in good standing on Bank A’s chain.
• Quorum of signatures met Bank A’s policy.
• Wire amount + currency + beneficiary match what’s being remitted.

Bank B then publishes its own WIRE_RECEIVED event on its chain referencing Bank A’s originating event. Two signed records of the same wire, one per bank. Reconciliation becomes trivial.

Use case 2: regulator audits across banks. A federal regulator (FinCEN, FSA, FCA, etc.) runs a read-only node that federates with every bank under their jurisdiction. They can query “show me every wire over $1M to sanctioned countries in Q4 2026” across dozens of banks without having to request data from each one.

All responses are cryptographically signed by the originating bank’s governor quorum; the regulator has no access to any bank’s private keys but can verify every response is authentic.

Use case 3: correspondent-bank reputation. A bank choosing whether to open a correspondent relationship with another bank can query that bank’s public reputation edges, e.g., “has FinCEN flagged this bank for sanctions violations in the last 24 months?” Trust edges from regulators (or from other banks) are public + signed + verifiable.

3.3 Privacy boundaries

Some wire details are public on both banks’ chains (from

• to quids, timestamp, wire amount in aggregate). Others are encrypted payloads with on-chain hash commitments (the memo line, internal routing details, KYC documentation).

Only authorized parties (originator bank, receiver bank, the two beneficiaries’ banks if different, plus regulators with subpoena-backed access) can decrypt the encrypted parts. The hashes on-chain are enough for auditors to verify later that “what was actually sent” matches the public record.

This pattern is generalizable to any federation with privacy concerns, see QDP-0017 for the data-subject-rights framework that formalizes it.

4. QDP-0014 node discovery + sharding

4.1 Operator-to-nodes hierarchy for a global bank

A major bank runs nodes in every major banking center (NY, London, Singapore, Tokyo, Hong Kong, Frankfurt, etc.). Each node is attested by the bank’s operator quid:

chase-operator-quid
    ──TRUST 1.0──►  node-chase-ny-primary    (validator)
    ──TRUST 1.0──►  node-chase-ny-backup     (validator)
    ──TRUST 1.0──►  node-chase-london-primary (validator)
    ──TRUST 1.0──►  node-chase-london-backup (validator)
    ──TRUST 1.0──►  node-chase-sg-primary    (validator)
    ──TRUST 1.0──►  node-chase-ny-cache-1..5 (cache, NY region)
    ──TRUST 1.0──►  node-chase-london-cache-1..3
    ──TRUST 1.0──►  node-chase-sg-cache-1..2
    ──TRUST 1.0──►  node-chase-archive-1     (archive)
    ──TRUST 1.0──►  node-chase-archive-2     (archive, different region)
    in operators.bank.chase

4.2 Node advertisements per role

Each node publishes a signed NODE_ADVERTISEMENT:

{
    "nodeQuid": "node-chase-ny-primary-quid",
    "operatorQuid": "chase-operator-quid",
    "endpoints": [
        { "url": "https://wires-ny.chase.com", "region": "us-ny", "priority": 1, "weight": 100 }
    ],
    "supportedDomains": ["bank.chase.wires.outbound", "bank.chase.wires.inbound"],
    "capabilities": {
        "validator": true,
        "cache": true,
        "archive": false,
        "gossipSink": true
    },
    "protocolVersion": "2.4.0",
    "expiresAt": 1748030400,
    "advertisementNonce": 847
}

Clients (a corporate treasury team originating a wire, a compliance officer auditing) use the discovery API:

GET /api/v2/discovery/domain/bank.chase.wires.outbound

Returns the three NY/London/SG validators plus the 10 regional caches. The client’s HTTP library picks the closest (by geoip, or by a pre-configured region preference) and submits the wire authorization there.

4.3 Wire-processing topology

Daily volume at a major bank is ~500k wires / day. Peak is ~10k/minute during end-of-day cutoffs. The topology needs to handle this without dropping wires:

┌──────────────────────────────────────────────────────┐
│ Validators (3 regions, 2-of-3 consortium)            │
│  - Produce blocks for wires.outbound + wires.inbound │
│  - Handle ~1000 authorized wires/s at peak            │
└────────────────────┬─────────────────────────────────┘
                     │ gossip
┌──────────────────────────────────────────────────────┐
│ Cache tier (10+ nodes, 3 regions)                    │
│  - Handle read queries from corporate treasury        │
│    teams + compliance officers                        │
│  - Target: 50k+ QPS per region                        │
└────────────────────┬─────────────────────────────────┘
                     │ api gateway
                     ▼
┌──────────────────────────────────────────────────────┐
│ api-wires-<region>.chase.com                         │
│  - Cloudflare Worker routing                         │
│  - Corporate treasury + compliance access             │
│  - Rate-limited per corporate account                │
└──────────────────────────────────────────────────────┘

Shard by:

• Geography: each region has its own validator pool and cache tier. US wires hit NY; Europe hits London; Asia hits Singapore. Cross-region wires gossip across consortiums.
• Capability: validators don’t serve reads; caches don’t produce blocks; archives are rarely touched except during regulatory queries.
• Domain-tree: wires.outbound and wires.inbound are separate domains, each with its own consortium. Some smaller banks run them on the same consortium; giant banks run them independently for isolation.

5. No-node participation for corporate clients

A mid-size corporation (say, a supply-chain company needing to pay international suppliers) doesn’t run a Quidnug node. They:

1. Hold a cryptographic quid for their treasury department.
2. Have trust edges from their bank(s) attesting to their account authorization.
3. Use client-side SDK to sign wire-authorization events.
4. POST to the bank’s api gateway.

The bank’s validator consortium verifies:

• The corporate’s quid is in good standing.
• Signatory quorum for THE CORPORATE entity’s policy is met (e.g., CFO + controller for wires > $1M).
• The wire is properly formed.

If all pass, the wire is authorized + transmitted to the correspondent/receiving bank via existing SWIFT or a federated Quidnug link.

The corporate gets real-time verifiability (they know when the wire hit each stage) without running any infrastructure. Same pattern as voters in elections, full cryptographic participation, zero infrastructure. This is QDP-0014’s “lightweight participation” mode.

6. Cross-network flow: end-to-end wire

Full sequence, touching all three pillars:

1. Corporate treasurer at MegaCorp prepares wire instruction:
      $2.5M USD from MegaCorp's USD account at Chase
      to beneficiary's EUR account at Deutsche Bank.

2. MegaCorp's treasurer (Alice) and CFO (Bob) both sign an
   instruction (each with their own quid; quorum 2-of-2
   required per MegaCorp's internal policy for $1M+).
   Published as WIRE_REQUEST event on MegaCorp's own domain
   bank.chase.corporate.megacorp.wire-requests (delegated
   sub-tree).

3. Chase's validator consortium receives the request via
   gossip. Validates:
   - MegaCorp corporate quid is authorized on Chase's books.
   - Quorum met per MegaCorp's policy.
   - Wire format + currency valid.
   - AML screening passes.

4. Chase publishes WIRE_AUTHORIZED event on
   bank.chase.wires.outbound domain. Signed by 2-of-3
   consortium validators. This is the cryptographic
   "Chase has approved this wire."

5. Chase's network federates with Deutsche's network via
   QDP-0013. Deutsche's consortium picks up the event,
   validates:
   - Event signed by Chase's validator consortium (verify
     against Chase's .well-known file pinned pubkey).
   - Beneficiary exists at Deutsche.
   - Wire format compatible with Deutsche's standards.

6. Deutsche publishes WIRE_RECEIVED event on
   bank.deutsche.wires.inbound domain. References Chase's
   WIRE_AUTHORIZED event by its tx ID.

7. Deutsche credits the beneficiary's account. Publishes
   SETTLEMENT event referencing the WIRE_RECEIVED.

8. Chase's inbound federation picks up the SETTLEMENT event,
   publishes SETTLEMENT_CONFIRMED on its own chain, completing
   the loop.

9. Both banks' regulators (FinCEN, BaFin) see the complete
   chain of events via their read-only federation nodes.

10. MegaCorp's treasurer can verify every step by fetching
    the events from either bank's api gateway.

Every step is cryptographically signed + publicly verifiable. The whole wire takes ~30 seconds vs. the current ~1 hour minimum for SWIFT + correspondent banking. Regulatory access is real-time instead of quarterly after-action reviews.

7. Governance changes mid-wire-day

Unlike elections (which happen on a fixed schedule), interbank wires happen 24/7. Governance changes have to be non-disruptive.

7.1 Adding a new signatory mid-day

Routine, happens whenever a new person is hired or promoted to a wire-authorization role.

1. Governor quorum signs ADD_SIGNATORY transaction.
2. 24-hour notice period: the new signatory can’t sign wires yet.
3. At activation, the new signatory is added to the pool with the specified role + weight.

Banks routinely plan these 24h+ in advance (employee onboarding takes that long anyway).

7.2 Emergency removal of a compromised signatory

If a signatory’s key is suspected compromised:

1. Any governor can initiate REMOVE_SIGNATORY with the 1-hour emergency clause.
2. Immediate audit event published noting the removal + reason.
3. 1 hour later: signatory is removed from the pool. Any pending wires they signed in the last hour are flagged for manual review.
4. Post-incident: guardian recovery on their individual quid if desired (separate from the pool-removal action).

7.3 Cross-bank coordinated changes

Occasionally two or more banks need to coordinate changes (e.g., standard cutoff times for a new currency pair). Each bank independently publishes the change on their own network; federation ensures the other bank sees it. No central coordinator is required; the federation topology is the coordination layer.

8. Operational readings

• operations.md, deployment topology, capacity planning, daily operations playbook, incident response.
• launch-checklist.md, 3-6 month bank-onboarding-to-live-wire-traffic sequence.

For the architectural pillars themselves:

• deploy/public-network/governance-model.md
• deploy/public-network/federation-model.md
• deploy/public-network/sharding-model.md

9. Not covered here

Two substantial topics this integration doc deliberately defers:

• SWIFT/Fedwire/SEPA bridging. Each jurisdiction has existing wire-transfer infrastructure. The Quidnug design replaces the authorization layer, not the transport layer, a wire authorized on Quidnug still typically moves via SWIFT. Bridge design is its own substantial project; see operations.md §5 for the integration pattern.

• Regulatory reporting (AML, CTR, SAR). Each country’s reporting requirements differ. Quidnug makes the data available in a standardized format; the per-jurisdiction reporting code lives in bank-specific applications on top.

Both are legitimate production concerns; both are application-layer, not protocol-layer. A deploying bank builds them atop the Quidnug substrate the same way they build SWIFT message generation atop internal databases today.

Interbank wire authorization operations

Deployment topology, capacity planning, daily operations, and incident response for a bank running Quidnug-based wire authorization. Adapted from UseCases/elections/operations.md for banking deployment profile.

1. Deployment scale

Different from elections: wire volume per day is higher and more continuous. 24/7 operation. Lower tolerance for outages (minutes of downtime = tens of millions in delayed settlements).

2. Deployment architecture

2.1 Small community bank

  ┌──────────────────────────┐
  │ Primary validator        │  (in-branch data center or
  │ (validator + cache +     │   cloud + private connection)
  │  archive, behind CF)     │
  └──────────┬───────────────┘
             │ gossip
  ┌──────────────────────────┐
  │ Backup validator         │  (disaster-recovery facility)
  │ (validator + cache)      │
  └──────────┬───────────────┘
             │
  ┌──────────────────────────┐
  │ Regional cache           │  (bank's HQ, wide-area redundancy)
  └──────────────────────────┘
             │
             ▼
  corporate treasury clients (via API)

Three nodes. 2-of-3 validator consortium. Governors: bank CEO, head of ops, head of compliance, state banking commissioner.

2.2 Regional bank

East-coast region               West-coast region
┌─────────────────────┐         ┌─────────────────────┐
│ val-east-1          │◄───────►│ val-west-1          │
│ val-east-2          │         │ val-west-2          │
└──────┬──────────────┘         └──────┬──────────────┘
       │                               │
       │ gossip                        │ gossip
       │                               │
┌──────────────────────────────────────────────────────┐
│ Central consortium member (audit + reconciliation)   │
│ (validator, tiebreaker)                             │
└──────────────────────────────────────────────────────┘

Per region, cache tier:
east: 3 cache nodes
west: 2 cache nodes

Archive: 2 nodes, geographically distributed.

5 validators, 2-of-5 for normal operation, geo-redundant.

2.3 National bank

┌───────────────────────────────────────────────────────────┐
│ Consortium (11 nodes, 6-of-11 quorum)                    │
│ - 3 east-coast (primary, backup, audit-focused)          │
│ - 3 west-coast                                            │
│ - 2 Texas (central)                                       │
│ - 1 London (for EUR wires)                               │
│ - 1 Singapore (for Asian wires)                          │
│ - 1 Compliance observer (Fed/OCC monitor)                │
└───────────────────────────────────────────────────────────┘

Cache tier:
  5 caches per major region (NY, LA, Chicago, DFW, Atlanta,
  London, Singapore) = ~35 cache nodes total.

Archive:
  4 nodes: 2 in separate regulator-approved data centers,
  2 in cold-storage backup.

2.4 Global bank

Per major banking center, a full regional consortium:

• 3-5 validators
• 5-10 cache nodes
• 1-2 archive
• Regulator observer nodes per jurisdiction

Cross-region federation per QDP-0013. Each jurisdiction may have its own regulator + its own governance variation (e.g., EU wires governed under EU rules; US wires under FFIEC/OCC).

Total: 50-150 nodes spread across 8-15 countries.

3. Hardware

Validators are expensive, they need high-IOPS SSD for replay + crash recovery. Caches are cheap; can be spot instances. Archives are slow but huge.

Per QDP-0014’s sharding model, validator-cache-archive separation is enforced via node advertisement capabilities a cache node cannot produce blocks even if configured incorrectly.

4. Capacity planning

4.1 Wire volume

For a national bank with 50k wires/day = ~0.58/s sustained = ~10/s peak (end-of-day cutoff). Per-wire transaction size:

50k wires/day × 3 KB = 150 MB/day on-chain data. 55 GB/year. Archive nodes handle this; cache tier keeps only recent months.

4.2 Query load

Much higher than write load. Corporate treasury + compliance teams + regulator access + reconciliation systems all query frequently:

• Wire status queries: ~200k/day (4x wire count)
• Compliance report generation: ~1k/day
• Reconciliation batch jobs: continuous
• Regulator queries: variable, occasionally high

Rate limit: 50k/hour per corporate client, 1M/hour aggregate. Cache tier should handle 50-100k QPS per region.

4.3 Latency targets

• Wire authorization (originator side): <3s from signing to consortium-accepted block
• Cross-bank handoff: <30s from authorization on Bank A to WIRE_RECEIVED event on Bank B
• End-to-end settlement: <2 minutes
• Regulator query response: <5 seconds for live data, <30 seconds for archive queries

Block interval: 3 seconds (shorter than elections’ 60s) because wire latency matters; consortium members produce blocks more aggressively.

5. Integration with existing wire infrastructure

Quidnug handles authorization + audit; existing systems handle transport (SWIFT MT, Fedwire, SEPA, CHIPS).

5.1 SWIFT bridge

Corporate → Quidnug authorization (cryptographic quorum) →
  WIRE_AUTHORIZED event →
  Quidnug-to-SWIFT bridge service generates MT103 message →
  SWIFT network delivers →
  Receiving bank's SWIFT MT103 → Quidnug-to-SWIFT bridge
  generates WIRE_RECEIVED event on Quidnug.

The bridge is a trusted service operated by the bank’s IT team. Not a Quidnug primitive, just application code tying existing SWIFT connectivity to Quidnug’s authorization + audit layer.

For banks wanting to skip SWIFT entirely (interbank settlement via Quidnug alone), QDP-0013 federation makes this possible but requires bilateral agreement with every counterparty bank. Realistic only for closed-consortium scenarios (e.g., a central-bank settlement network).

5.2 Fedwire

Similar bridge pattern. Fedwire’s ISO 20022 message format is structurally similar to SWIFT MT; one bridge handles both with different message-generation modules.

The bank’s Fedwire credentials (the one-per-bank account with the Fed) stay in the bank’s existing infrastructure; Quidnug events trigger Fedwire message generation.

5.3 SEPA

SEPA credit transfers (SCT) and instant payments (SCT Inst) both have ISO 20022 message formats. Same bridge pattern.

SEPA is the closest to “real-time” in existing infrastructure and benefits the most from Quidnug’s authorization + audit speed. A Quidnug-accelerated SEPA flow can complete in seconds end-to-end.

6. Daily operations playbook

6.1 Pre-market (03:00-06:00 local)

• Operations team runs overnight reconciliation between consortium state and core banking system.
• Batch settlement jobs for prior-day wires complete.
• Archive backup runs.
• Morning briefing: on-call rotation, known incidents.

6.2 Market open (06:00-18:00)

• Wire traffic ramps throughout the morning.
• Peak hours: 09:00-11:00 (Europe open), 15:00-16:00 (US close + Europe late).
• End-of-day cutoff: typically 17:00 or 18:00 local.
• Real-time monitoring: per-region validator participation, cross-bank federation latency, cache hit rates.

6.3 End-of-day cutoff

• Hard cutoff published as a MARKET_CLOSE event per region.
• Wires submitted after cutoff queue for next-day.
• Consortium waits for all in-flight wires to settle before sealing the final block of the day.
• Daily reconciliation automated: every wire matched against every settlement event; any unmatched flagged for manual review.

6.4 Overnight (18:00-03:00)

• Backup + archive sync.
• Regulator reports generated + submitted per jurisdiction requirements (varies; US: CTR for >$10k wires, SAR for suspicious activity).
• System maintenance window for non-urgent updates.

7. Incident response

7.1 Validator node down during market hours

Detection: health-check alert on the validator.

Response:

1. Immediately confirm: is it just network, process, or hardware?
2. Remaining validators continue (6-of-11 quorum preserved if one is down).
3. IR team investigates in parallel with continued operation.
4. If recovery time > 1 hour during peak: trigger emergency REMOVE_VALIDATOR to unblock any 6-required operation.
5. Post-incident: audit event published; root cause analysis within 48h.

7.2 Cross-bank federation partition

Detection: federation latency alert, e.g., Chase-to- Deutsche federation hasn’t echoed a WIRE_RECEIVED event in more than 5 minutes.

Response:

1. Check both banks’ status pages for correlated outages.
2. Verify network connectivity (BGP, DNS, Cloudflare status).
3. If transient: automated retry with exponential backoff.
4. If sustained: bridge to SWIFT as fallback; notify affected corporates.
5. Post-healing: reconcile any wires that went via SWIFT fallback against the federation record.

7.3 Suspected signatory key compromise

Detection: anomalous wire pattern (volume, destination, time-of-day) flagged by AML engine; or direct security-team alert.

Response:

1. Freeze the signatory’s quid immediately (via governor quorum emergency REMOVE_SIGNATORY action, 1 hour notice).
2. Audit all wires signed by that signatory in the last 24h; flag for additional manual review before settlement.
3. Notify affected corporates.
4. Law enforcement referral per bank policy.
5. Guardian recovery on the compromised quid; new key installed only if the original holder is cleared.

7.4 Regulator subpoena

Detection: legal notice arrives.

Response:

1. Legal team reviews scope.
2. Operations generates read-only access for the regulator’s designated investigator, a federated read-only node connecting to the bank’s network with scoped domain access.
3. All queries the regulator runs are logged on-chain (the regulator’s node publishes its queries as events on an audit domain, so the subpoena scope is provable).
4. Regulator’s queries return cryptographically-verifiable data; no edits possible; the chain IS the record.
5. If regulator also wants decrypted payload data (KYC docs, wire memos), legal team evaluates scope; decryption keys are released per the legal requirement.

This is a significant UX upgrade over current state, regulatory queries today require months of IT work extracting data from multiple systems + internal review. With Quidnug, it’s hours.

8. Security discipline

8.1 Key custody

8.2 Separation of duties

• Block-production (validator) keys ≠ wire-signing (signatory) keys.
• Governance keys ≠ operational keys.
• A compromised wire officer cannot alone produce wires; quorum + separation-of-duty enforced on-chain.
• A compromised validator cannot alone change signatory pools; that requires governance quorum.

8.3 Annual audit

• External security audit of the bank’s Quidnug infrastructure annually.
• Quarterly penetration testing.
• Daily automated security scans.

9. Cost at scale

Compare to current wire infrastructure: global banks spend ~$100M+/year on wire systems alone (SWIFT connectivity, Fedwire licensing, FX infrastructure). Quidnug’s deployment is a fraction.

10. References

• README.md, wire-authorization semantics.
• architecture.md, data model + flows.
• integration.md, architectural-pillar integration.
• launch-checklist.md, bank- onboarding sequence.
• threat-model.md, attack analysis.
• UseCases/elections/operations.md companion operations doc; same-pattern at election scale rather than daily-banking scale.

Interbank wire authorization launch checklist

Sequential T-180 through T+30 onboarding steps for bringing a bank onto Quidnug-based wire authorization. Work top to bottom; each item gates the next.

Written for a national bank joining its first correspondent consortium (the most common starting profile). Small community banks can collapse steps 3-4 (fewer governors, single region); global banks should multiply the regional stand-up steps across jurisdictions.

Parallels UseCases/elections/launch-checklist.md but adapted for banking deployment profile. Read README.md, integration.md, and operations.md first.

T-180 to T-120 days: Legal + regulatory foundation

Wire authorization is one of the most heavily regulated activities a bank does. Nothing happens before legal sign-off.

Regulatory strategy

• General counsel + compliance chief review + approve the overall architecture. Specifically: does running wire authorization on Quidnug satisfy: - Home-jurisdiction central-bank rules (Fed for US, BaFin for DE, BoE for UK, etc.) - FFIEC IT Examination Handbook (US federal banking) - OCC Heightened Standards (for national banks) - FATF Recommendation 16 (Wire Transfers) - Basel Committee Principles for Sound Management of Operational Risk
• File advance notice with primary regulator (US: OCC + Federal Reserve; EU: ECB + national regulator). Some jurisdictions require 30-90 day advance notice for operational-risk framework changes.
• Engage independent banking-software auditor for pre-certification. Must have prior experience with SWIFT/Fedwire/SEPA gateway integrations.
• Legal opinion letter on whether on-chain signatures satisfy the “two officer” requirement under applicable rules (varies; many jurisdictions treat cryptographic signatures as equivalent to written ones if audit trail is preserved).
• Privacy review: any PII in wire metadata that leaves the bank’s controlled environment needs GDPR / CCPA / LGPD assessment. Plan: encrypt wire payloads, store only hashes on-chain for cross-bank audit.
• Cyber insurance review: policy coverage for cryptographic-key custody, HSM failure, blockchain infrastructure.

Governance foundation

• Internal governance committee formed + briefed on the protocol architecture. Typical composition: - CEO or designated COO - Chief Compliance Officer - Chief Risk Officer - Head of Wire Operations - Head of IT / CISO - External regulator liaison (observer, non-voting)
• Governance structure defined + documented (see integration.md §2): - Governor quorum (who, weights, threshold) - Consortium membership (which of the bank’s own nodes produce blocks) - Peer-bank trust edges (counterparty banks) - Emergency-notice clause (normal 24h / emergency 1h) - Signatory roster + per-wire-class thresholds - Guardian quorums per governor (QDP-0002)
• Signatory policy published internally: - Wire-class thresholds ($1M, $10M, $100M, $1B) - Required signer count per class - Maker/checker separation rules - Dual-control for policy changes
• Board of directors briefed + resolution passed authorizing the new infrastructure.

T-120 to T-90 days: Hardware + infrastructure procurement

HSM procurement

Wire authorization is HSM-dependent. Every signing key lives in hardware; never plaintext in RAM.

• HSM vendor selected. Acceptable options: - Thales Luna Network HSM (bank-grade) - Entrust nShield Connect - AWS CloudHSM (cloud-native equivalents) - Azure Dedicated HSM - Google Cloud HSM
• HSMs procured per region: - Primary data center: 2 HSMs (active + standby) - DR data center: 2 HSMs - Each additional region: 2 HSMs
• HSM firmware version locked + documented.
• Air-gapped key-ceremony room provisioned (offline laptop + paper backup printer + Faraday cage or shielded room).

Node hardware

• Validator hardware procured per operations.md §3: - 8 cores, 32 GB RAM, 2 TB NVMe (IOPS 50k+), 10 Gbps - Per-region: 2-3 validators (redundancy) - Total depending on bank scale (see operations.md §2)
• Cache tier hardware procured (1 per 10k wires/day of throughput, per region).
• Archive node hardware procured (20 TB disk, 2+ per bank minimum, geographically separated).
• Observer node hardware for regulators (lower-spec; regulators may supply their own).

Network + connectivity

• Private cross-region connectivity (AWS Direct Connect, Azure ExpressRoute, MPLS) for validator gossip.
• Cloudflare (or equivalent) enterprise account for public-facing cache + well-known endpoints.
• Dedicated circuits for SWIFT (existing), Fedwire (existing), SEPA (existing). Quidnug doesn’t replace these; it augments them.
• VPN + zero-trust network access for corporate treasury clients.

Software + keys

• Quidnug node binary built from a specific tagged release (e.g., v2.4.0). SHA-256 hashes published. Reproducible build verified.
• All governor keys generated via air-gapped key ceremony. Paper backups printed + distributed to separate safe-deposit boxes (dual control).
• Guardian quorums installed for each governor key (following QDP-0002). Typical: 3-of-5 guardians per governor, drawn from executive + board.
• Validator node keys generated directly inside HSMs; never exportable.
• Signatory keys (wire officers) generated on YubiKey or equivalent, one per officer. Backup guardian quorum per signatory (typically 2-of-3 coworkers).
• CLI tooling (quidnug-cli wires) tested in staging.

T-90 days: Domain + consortium setup

Publish the network descriptor

• Publish https://bank.<id>.com/.well-known/quidnug-network.json per QDP-0014 §7. Signed by the bank’s operator key. Includes: - Operator quid + pubkey (the bank’s root identity) - API gateway URLs - Seed nodes + capabilities - Governors + quorum - Domain tree - Peer banks + federation links (QDP-0013)
• Publish backup mirror of the well-known file at a federated location (e.g., https://quidnug.com/.well-known/banks/<id>.json) for resilience if the bank’s public site is down.

Register the bank’s domain tree

• Register the bank’s root domain: bash quidnug-cli domain register \ --name "bank.<id>" \ --validators "<consortium-quids>" \ --governors "<governor-quids>" \ --governance-quorum 0.7 \ --threshold 0.67 \ --notice-period 24h \ --emergency-notice 1h \ --key <operator-key>
• Register sub-domains: bash for child in wires.outbound wires.inbound \ signatories audit \ peering.counterparty-banks; do quidnug-cli domain register \ --name "bank.<id>.$child" \ --parent-delegation-mode inherit \ --key <operator-key> done
• Register wire-class policy domains (one per threshold tier): bash for tier in standard-under-1m high-value-1m-10m \ executive-10m-100m board-over-100m; do quidnug-cli domain register \ --name "bank.<id>.wires.policy.$tier" \ --parent-delegation-mode inherit \ --signatory-threshold <N> \ --key <operator-key> done
• Verify all domains visible in the bank’s API at api.bank.<id>.com/api/domains.

Stand up the consortium

• All consortium members (the bank’s own validators) deploy Quidnug node binary from the audited release.
• Each publishes its own NODE_ADVERTISEMENT per QDP-0014: bash quidnug-cli node advertise \ --operator-quid <bank-operator-quid> \ --endpoints "https://node<i>.bank.<id>.com:443,http/2,<region>,1,100" \ --capabilities "validator,archive" \ --supported-domains "bank.<id>.*" \ --expires-in "7d" \ --sign-with <node-i-key>
• Bank operator publishes TRUST attestation edges to each validator: bash quidnug-cli trust grant \ --truster <bank-operator-quid> \ --trustee <node-i-quid> \ --domain "operators.bank.<id>" \ --level 1.0 \ --sign-with <operator-key>
• Pairwise peering: all validators trust each other at 0.95 in the peering.* domain.
• Block production verified: all validators see blocks from all others at Trusted tier.

Register signatories

• Each wire officer registers an IDENTITY transaction under bank.<id>.signatories: bash quidnug-cli identity register \ --domain "bank.<id>.signatories" \ --name "alice.wireop" \ --pubkey <alice-yubikey-pubkey> \ --creator <hr-manager-quid> \ --attributes '{"role":"wire-officer","region":"NY"}' \ --sign-with <hr-manager-key>
• Governance quorum signs ADD_SIGNATORY event per officer, granting authority in specific policy domains: bash quidnug-cli wires add-signatory \ --signatory-quid <alice-quid> \ --policy-domain "bank.<id>.wires.policy.high-value-1m-10m" \ --weight 1 \ --governor-signatures "<sigs>" \ --sign-with <governor-primary-key>
• Each signatory’s guardian quorum published (for key recovery if YubiKey lost).

T-60 days: Federation setup + peer onboarding

Peer bank TRUST edges

Interbank wires cross networks (per QDP-0013). Before you can send a wire to another bank, you need a federation relationship.

• Bilateral federation agreement signed with each peer bank (legal document, not cryptographic). Covers: - Liability boundaries - Regulator observability terms - Emergency-response communication channels - Dispute-resolution procedure
• TRUST_IMPORT transactions configured per peer bank: bash quidnug-cli federation import \ --source-network "bank.<peer-id>" \ --source-root-quid <peer-operator-quid> \ --trust-level 0.9 \ --domain "peering.counterparty-banks" \ --external-trust-source "https://bank.<peer-id>.com/.well-known/quidnug-network.json" \ --sign-with <operator-key>
• Peer bank verifies the import from their side; signs reciprocal TRUST_IMPORT. Both networks now recognize each other’s signatures.

SWIFT/Fedwire/SEPA bridge configuration

• Quidnug-to-SWIFT bridge service deployed (see integrations/iso20022/README.md).
• Bridge signs events when sending/receiving wires: - WIRE_AUTHORIZED → SWIFT MT103 outbound - SWIFT MT103 inbound → WIRE_RECEIVED event
• Bridge service runs with its own dedicated quid (separate from signatory quids; separation-of-duty).
• Fedwire bridge (for US-domestic) + SEPA bridge (for EU) configured analogously.

Regulator node

• Regulator observer node provisioned (either by the bank in the regulator’s data center, or by the regulator themselves connecting to the bank’s network).
• Observer node registered as capability=observer only (no validator, no archive, purely read).
• Regulator credentials issued for scoped-access queries (domain-level visibility per their mandate).
• Regulator training completed: how to run recounts, how to subpoena data, how to file an audit query.

T-45 days: Audit + software review

External audit

• External security-audit firm completes review of: - Quidnug node binary (reviewed at the QDP level) - Bank-specific integration code (bridges, policy enforcement, monitoring) - HSM integration correctness - Key-ceremony procedures
• Penetration-testing engagement on staging environment.
• Audit report published to regulators + governance committee.
• All high-severity findings addressed; medium-severity findings scheduled for post-launch; low-severity tracked.

Internal code audit

• Wire-policy-enforcement code (what triggers additional signers for high-value wires) reviewed by compliance + risk.
• AML engine integration verified: every wire above threshold gets automated AML screen before authorization.
• Signatory-revocation flow tested: when Alice leaves the bank, her quid is removed from the signatory roster within 1 hour.

Dry run #1 (1,000 fake wires)

• Staging environment reset to clean state.
• 1,000 fake wires generated across all policy tiers.
• Internal signatories authorize per policy rules.
• SWIFT bridge delivers simulated MT103 messages (to a test counterparty network).
• Reconciliation job runs; 1,000/1,000 match expected.
• “Suspected-fraud” scenario: 5 deliberately-malformed wires; AML engine flags them; compliance officer vetoes via governance quorum.
• “Validator-failure” scenario: kill 1 of 5 validators mid-batch; 4-of-5 continues.
• Document all issues in dry-run-1-postmortem.md.

T-30 days: Final polish + training

Dry run #2 (10,000 fake wires, realistic mix)

• Larger-scale test with 10,000 fake wires across all policy tiers + all regions.
• Peer bank (also in staging) runs receiving-side flow; cross-bank handoff latency measured.
• Regulator observer runs live-audit queries during the run.
• Performance: all 10,000 wires authorize within the 3s SLA; cross-bank handoff within the 30s SLA.
• Issues found + fixed.

Staff training

• Wire officers complete certified training on: - YubiKey operation + daily key management - Wire-authorization workflow - Suspected-fraud escalation - Guardian-recovery procedure (if YubiKey lost)
• Operations team trained on: - Monitoring dashboards - Incident-response playbook (ops.md §7) - Validator + consortium health - Federation-partition response
• Compliance team trained on: - Live query tools - Governance-change workflow (REMOVE_SIGNATORY, emergency notice) - Regulator subpoena response
• Corporate treasury clients briefed: - New client API (for corporates wanting direct integration) - Status-page expectations

Corporate client onboarding

• Top 10 corporate clients (by wire volume) invited to participate in closed beta.
• Each gets a client-side Quidnug quid (their treasurer’s key) + guardian-recovery-as-a-service offering if desired.
• Test wires sent from beta clients in staging.
• Feedback incorporated.

Infrastructure freeze

• Code freeze: no production deploys after T-14 except for critical security fixes.
• Final HSM firmware + node-binary versions locked.
• All consortium members confirm on-call rotation for go-live.

T-14 days: Staged rollout begins

Wire authorization doesn’t have an “election day”, it’s continuous. Ramp up gradually.

Tier-1 rollout: internal test wires only

• Production network live but accepting only internal test wires (wires between the bank’s own accounts).
• All internal reconciliation match.
• Compliance team monitors: no false positives, no missed authorizations.

Daily checks during ramp-up

Each day from T-14 to T-1:

• Morning: all consortium nodes healthy; all HSMs responsive.
• Peak-hour traffic simulation: 10x expected production load injected to verify capacity.
• End-of-day reconciliation: 100% match.
• Any incidents: INCIDENT_<type> event published + fix.

T-7 days: Beta corporate wires

Tier-2 rollout: beta corporates

• 10 beta corporate clients begin sending real (low-value) wires via the new infrastructure.
• Parallel path: same wires also flow via legacy infrastructure as backup; reconciliation nightly to confirm both produce same result.
• Increase to 50 beta corporates over the week.

Status page + monitoring

• Public status page live at status.bank.<id>.com.
• Regulator has live dashboard access.
• Internal SRE team 24/7 on-call.

T-1 day: Pre-flight

• All consortium members verify blockchain head matches.
• Final smoke test: 100 synthetic wires across all tiers; all authorize within SLA.
• Publish GO_LIVE_READY event to audit domain.
• On-call roster confirmed; key personnel reachable.
• Communications lead briefed on launch-day message.

T-0: Go-live day

Market open

• First real production wire authorized via Quidnug. (Low-value, well-known corporate counterparty; CEO + CISO both watching in real time.)
• GO_LIVE event published to audit domain.
• Press release (if applicable) coordinated with regulator.

Throughout day 1

• Wire volume ramps throughout the day as more corporates + counterparties transition.
• Every wire monitored manually for the first hour; then spot-checks throughout the day.
• Incident-response team on-site, not just on-call.

End of day 1

• Day-1 wire count vs expected: report to governance committee.
• Reconciliation run against all counterparties.
• Incidents: none expected, but any found get postmortem within 24h.

T+7 days: Week-1 review

• Operational postmortem: - Total wires authorized - Total volume ($) - Average authorization latency - Any incidents + resolutions - SLA attainment (target: 99.9% within 3s)
• Expand rollout to remaining corporates per schedule.
• Regulator week-1 report submitted per requirements.

T+30 days: Month-1 review + full migration

• All corporate clients migrated to new infrastructure.
• Legacy wire-authorization system put in “receive only” mode (can receive inbound from correspondents, but no new outbound; prepares for decommission).
• Month-1 operational metrics report: - Uptime (target: 99.95%) - Wire volume processed - Cost savings vs legacy - Audit query response time (target: <5s live, <30s archive)
• Regulator month-1 briefing + sign-off for full production.
• Board of directors update.

T+90 days: Legacy decommission

• Legacy wire-authorization system decommissioned.
• All paper-based cosigning workflows retired.
• Annual-audit cycle transitions from old system to Quidnug chain queries.
• First full quarter of operation closed with clean regulatory review.

Metrics to track

For every operational day, track these against targets from operations.md §4:

What to do if…

…a signatory’s YubiKey is reported lost

1. Signatory’s guardian quorum (typically 2-of-3 coworkers) initiates QuidRecoveryInit per QDP-0002.
2. 1-hour time-lock window starts. Signatory cannot veto since the YubiKey is lost; if it turns out to be misplaced and they find it, they can reclaim within the window.
3. After time-lock, new YubiKey provisioned; signatory resumes wire-authorization authority.
4. Audit event published: SIGNATORY_KEY_RECOVERED.
5. All wires signed within the preceding 72 hours by the old key flagged for review (potential compromise window).

…a validator node fails during market hours

1. Confirm it’s a real failure (not transient network).
2. Consortium continues with remaining validators (quorum preserved per operations.md §7.1).
3. Spare validator brought online from DR tier; new node publishes NODE_ADVERTISEMENT; consortium re-balances.
4. Post-incident: root-cause analysis + postmortem within 48h.

…cross-bank federation is partitioned

1. Wires to/from the partitioned counterparty queue.
2. Fallback to SWIFT / Fedwire / SEPA for urgent wires.
3. Monitor both networks’ status pages.
4. Once partition heals, federation catches up automatically via gossip; reconciliation confirms no wires lost or duplicated.
5. If partition exceeds 1 hour during market hours: escalate to senior management + regulator notice.

…a wire is contested by a corporate client

1. Corporate submits WIRE_DISPUTE event via their client.
2. Operations team pulls full signature chain from chain queries: who signed, when, under which policy.
3. If dispute is clerical (wrong account, wrong amount but authorized): standard wire-recall procedure.
4. If dispute alleges unauthorized signing: security team investigates + potential signatory compromise handling.
5. Chain queries are cryptographically verifiable so dispute resolution is fast + unambiguous compared to legacy “search 4 systems” approach.

…a regulator subpoenas wire data

1. Legal team reviews scope.
2. Operations provisions read-only scoped access for the regulator’s investigator (federated read-only node + scoped domain access).
3. All queries the regulator runs are logged on-chain (regulator’s node publishes queries as events on an audit domain; subpoena scope is provable).
4. If decrypted payload data required (wire memo, KYC docs, beneficiary details): legal team releases decryption keys per subpoena.
5. Response time: hours to days, vs months under legacy.

…a peer bank exits the federation (e.g., acquired or failed)

1. Governance quorum signs TRUST_IMPORT_REVOCATION for the exiting peer.
2. In-flight wires to/from the peer are drained via SWIFT fallback.
3. Historical wires remain on-chain for audit; new wires to that peer are blocked.
4. If the peer is being acquired, reconfiguration of the federation to the acquirer’s network takes 30-90 days (repeat the peer-onboarding flow from T-60).

…the home regulator revokes permission

1. Immediately halt all new wire authorizations (governor quorum emergency FREEZE_NEW_WIRES action).
2. In-flight wires complete via legacy path.
3. Legal team + senior management engage regulator.
4. If permanent revocation: decommission the network. Archive all data for retention period per jurisdiction (typically 5-7 years for banking).

References

• README.md, wire-authorization semantics.
• architecture.md, data model + flows.
• integration.md, architectural-pillar integration (QDP-0012/0013/0014).
• operations.md, deployment topology, daily operations, incident response.
• threat-model.md, attack analysis.
• implementation.md, concrete Quidnug API calls.
• UseCases/elections/launch-checklist.md companion launch checklist for the other coordination- archetype use case.
• deploy/public-network/reviews-launch-checklist.md public-network reviews launch template this doc cribs from.