Multi-Signature Security

Understanding the building blocks of XRPL multi-sig.

SignerList Object:

- SignerEntries: Array of authorized signers
- SignerQuorum: Threshold required to authorize

- Account: Address of authorized signer
- SignerWeight: Weight this signer contributes

- Sum of signing weights must meet or exceed quorum
- Any combination of signers can authorize if threshold met
- Order doesn't matter

Example:
SignerList {
    SignerQuorum: 3,
    SignerEntries: [
        {Account: "rAlice", SignerWeight: 2},
        {Account: "rBob", SignerWeight: 1},
        {Account: "rCarol", SignerWeight: 1}
    ]
}

- Alice alone: 2 < 3 ✗
- Alice + Bob: 2 + 1 = 3 ✓
- Alice + Carol: 2 + 1 = 3 ✓
- Bob + Carol: 1 + 1 = 2 ✗
- All three: 2 + 1 + 1 = 4 ✓

SignerListSet Transaction:

{
    "TransactionType": "SignerListSet",
    "Account": "rMultiSigAccount",
    "SignerQuorum": 3,
    "SignerEntries": [
        {
            "SignerEntry": {
                "Account": "rAlice",
                "SignerWeight": 2
            }
        },
        {
            "SignerEntry": {
                "Account": "rBob",
                "SignerWeight": 1
            }
        },
        {
            "SignerEntry": {
                "Account": "rCarol",
                "SignerWeight": 1
            }
        }
    ]
}

- Must sign with current authorized key (master or regular)
- SignerQuorum must be achievable with listed signers
- Maximum 32 signers per list
- Each signer must be valid XRPL address
- Signers cannot be the account itself

- Reserve requirement increases with signer count
- Currently: 2 XRP per signer + base reserve
- 3 signers = 6 XRP additional reserve

Multi-Sig Transaction Structure:

- Signers: Array of signer accounts and their signatures
- Each signer signs the same transaction hash

1. Build transaction (same as single-sig)
2. Each signer signs independently
3. Collect all signatures
4. Assemble into Signers array
5. Submit combined transaction

Signature Assembly:
{
    "TransactionType": "Payment",
    "Account": "rMultiSigAccount",
    "Destination": "rRecipient",
    "Amount": "1000000",
    "Fee": "30",  // Higher for multi-sig
    "Sequence": 42,
    "Signers": [
        {
            "Signer": {
                "Account": "rAlice",
                "TxnSignature": "3045022100...",
                "SigningPubKey": "03AB..."
            }
        },
        {
            "Signer": {
                "Account": "rBob",
                "TxnSignature": "30440220...",
                "SigningPubKey": "02CD..."
            }
        }
    ]
}

Multi-Sig Transaction Fees:

Standard Formula:
fee = base_fee * (1 + number_of_signatures)

Example (3 signatures):
base_fee = 10 drops
multi_sig_fee = 10 * (1 + 3) = 40 drops

- More signatures = more verification work
- Larger transaction size
- More storage in ledger
- Cost scales with complexity

- During congestion, fees increase
- Multi-sig multiplier still applies
- Can become significant for many signers

- Use minimum signers to meet threshold
- Don't include extra signatures unnecessarily
- Consider threshold design for fee efficiency

---

Different organizational needs require different multi-sig designs.

Equal Weight (M-of-N):

All signers have weight 1, quorum is M.

2-of-3:
SignerQuorum: 2
Signers: [A=1, B=1, C=1]
Use: Personal backup, small team

3-of-5:
SignerQuorum: 3
Signers: [A=1, B=1, C=1, D=1, E=1]
Use: Business operations, board approval

5-of-7:
SignerQuorum: 5
Signers: Seven equal signers
Use: High-security treasury, committee decisions

- Any M signers can authorize
- (N-M+1) signers must be compromised for theft
- (N-M+1) signers must be lost for lockout

Trade-off:
Higher M = More secure against compromise
Higher M = Higher risk of access loss
Typical: M = ceil(N/2) + 1 or similar

Hierarchical Control:

Different signers have different authority levels.

Executive Override:
SignerQuorum: 4
Signers: [CEO=3, CFO=2, Treasury=1, Controller=1]

- CEO + Treasury: 3 + 1 = 4 ✓
- CFO + Treasury + Controller: 2 + 1 + 1 = 4 ✓
- CEO alone: 3 < 4 ✗
- CFO + Treasury: 2 + 1 = 3 ✗

- CEO can override with one backup signer
- Finance team needs full consensus
- Reflects organizational hierarchy

Investment Committee:
SignerQuorum: 5
Signers: [ChairPerson=3, Member1=2, Member2=2, Secretary=1]

- Chair + any Member = 3 + 2 = 5 ✓
- Both Members: 2 + 2 = 4 ✗
- Chair needs at least Secretary: 3 + 1 = 4 ✗
- Ensures Chair involvement in decisions

Emergency Access Patterns:

- Normal: Need 4-of-5
- Secure but slow to coordinate

- Backup key in escrow/lawyer's safe
- Can reduce threshold via SignerListSet
- Requires advance planning

Alternative: Tiered Accounts:
Hot Wallet: 2-of-3 (fast, limited funds)
Warm Wallet: 3-of-5 (moderate security)
Cold Storage: 5-of-7 (maximum security)

- Cold → Warm: Requires 5 signatures
- Warm → Hot: Requires 3 signatures
- Daily ops: Hot wallet (2 signatures)

Geographic Multi-Sig:

Purpose: No single location can authorize

Configuration:
SignerQuorum: 3
Signers: [
    NYC_Signer=1,
    London_Signer=1,
    Singapore_Signer=1,
    Tokyo_Signer=1
]

- At least 3 different time zones/locations sign
- Single office breach doesn't compromise funds
- Coordination requires communication across locations

- Time zone coordination
- Communication latency
- Local regulations for key storage

- Disaster resilience
- Jurisdictional diversity
- Collusion difficulty

---

Multi-sig security is only as good as operational procedures.

Initial Key Ceremony:

Purpose: Securely generate and distribute multi-sig keys

- Key generators (one per signer)
- Witness/auditor
- Ceremony coordinator

1. PREPARATION

1. KEY GENERATION

1. PUBLIC KEY COLLECTION

1. SIGNER LIST CREATION

1. ACTIVATION

1. DOCUMENTATION

Multi-Sig Transaction Flow:

1. INITIATION

1. REVIEW

1. SIGNING

1. COLLECTION

1. SUBMISSION

1. CONFIRMATION

- Out-of-band verification for large amounts
- Signed messages for signature requests
- Multiple channels for confirmation

Adding a Signer:

Scenario: New employee joins finance team

1. New signer generates keypair
2. New signer provides public address
3. Create new SignerListSet with added signer
4. Existing signers authorize the change
5. New configuration takes effect

Transaction:
{
    "TransactionType": "SignerListSet",
    "Account": "rMultiSigAccount",
    "SignerQuorum": 3,
    "SignerEntries": [
        // existing signers
        {SignerEntry: {Account: "rAlice", SignerWeight: 2}},
        {SignerEntry: {Account: "rBob", SignerWeight: 1}},
        // NEW signer
        {SignerEntry: {Account: "rNewPerson", SignerWeight: 1}}
    ]
}

Removing a Signer:

Scenario: Employee leaves company

1. Immediately update SignerList to remove
2. Remaining signers authorize change
3. Verify removal confirmed
4. Document for audit

Critical: Remove before departure if possible!
```

Recovery Scenarios:

- If threshold still achievable: Continue operating
- Update SignerList to remove lost key
- Add replacement signer if desired
- No emergency, normal process

- If master key not disabled: Use master key
- Update SignerList with new signers
- Establish new threshold

- CANNOT recover
- Funds permanently locked
- This is why master key backup matters

- Immediately update SignerList
- Remove compromised signer
- If enough keys compromised: Race attacker
- Consider moving funds to new account

- Keep master key backup (unless specific reason not to)
- Document recovery procedures
- Test recovery annually
- Legal arrangements for key holders

---

Understanding what can go wrong.

Coordination Failure:

Risk: Cannot gather enough signatures

- Signers unavailable (travel, illness, death)
- Communication failure
- Time zone challenges
- Organizational conflict

- Threshold < total signers (redundancy)
- Clear escalation procedures
- Backup signers
- Time-limited signing requests
- Async-friendly tooling

- 3-of-5: Any 2 can be unavailable
- 5-of-5: All must be available
- Operational flexibility vs security

Collusion Attack:

Risk: Sufficient signers conspire to steal

- Need 3 colluding signers
- If all honest: No risk
- If 2 collude: Still need 1 more
- If 3 collude: Can steal everything

- Background checks on signers
- Geographic/organizational diversity
- Monitoring and alerts
- Delays for large transactions
- Escrow for cooling-off period

- Multi-sig doesn't prevent internal fraud
- It increases collusion requirements
- Social/organizational controls also needed

Key Loss Cascade:

- Company uses 4-of-6 multi-sig
- Over time, 2 signers leave without transition
- Now only 4 active signers remain
- One more departure = funds locked

- Regular signer list audits
- Exit procedures for departing signers
- Prompt replacement of lost keys
- Documented thresholds and counts

Key Compromise Cascade:

• Same vendor hardware wallets for all signers

• Vendor has vulnerability

• All keys potentially compromised

• Diverse key storage (different vendors)

• Mix of hardware and other solutions

• Different key types (secp256k1 + Ed25519)

OpSec for Multi-Sig:

- Keys stored in different locations
- Access controls on storage locations
- Tamper-evident seals
- Regular verification keys exist

- Encrypted channels for coordination
- Out-of-band verification for large transactions
- No signing without independent confirmation

- Written procedures
- Regular drills
- Audit trail for all operations
- Separation of duties

- Verification protocols
- "Duress" signals
- Time delays for unusual requests
- Multiple-channel confirmation

---

Sophisticated configurations for complex needs.

Two-Tier Authorization:

Concept: Different thresholds for different amounts

- Cannot do in single account
- Use multiple accounts with different configs

- Quick approval for daily operations

- Higher security for significant transfers

- Daily ops from Account A
- Large needs: Transfer from B to A first
- B→A transfer requires 4-of-7
- Then spend from A with 2-of-3

Shamir's Secret Sharing Concept:

Note: Not native XRPL, but applicable to key management

Purpose: Backup master key without single point of failure

- Split master key into N shares
- Any M shares can reconstruct
- Less than M shares reveal nothing

- Create 5 shares of master key
- Distribute to trusted parties/locations
- Any 3 can recover full key
- 2 compromised shares: Key still safe

- Master key as emergency backup
- Shares in escrow, lawyers, safe deposits
- Recover only in dire emergency
- Day-to-day use multi-sig without master

Escrow-Based Delays:

Purpose: Give time to detect and respond to theft

1. Create escrow instead of direct payment
2. Set FinishAfter to future time (24-72 hours)
3. Recipient can claim after delay
4. Sender can cancel before delay expires

- Multi-sig account creates escrow
- If detected as fraudulent before finish time
- Multi-sig can cancel the escrow
- Recovery window for compromises

Example:
Large withdrawal requested → Created as escrow
Escrow: Claimable in 48 hours
Monitoring detects anomaly at hour 12
Multi-sig sends EscrowCancel
Funds returned, theft prevented

✅ Native multi-sig eliminates smart contract risk. XRPL multi-sig is part of the consensus protocol itself, not external code. The same security analysis that validates single-signature transactions applies.

✅ Properly configured multi-sig prevents single-point-of-failure losses. When key holders are genuinely independent and thresholds appropriately set, neither theft nor loss from a single compromised party is possible.

✅ Weighted multi-sig accurately reflects organizational hierarchies. Corporate governance structures can be encoded directly into the signing requirements, enforcing controls cryptographically.

⚠️ Long-term key holder stability is an organizational challenge. People leave companies, die, or become incapacitated. Key management across these transitions is a human problem, not a cryptographic one.

⚠️ Coordination costs may exceed security benefits for some organizations. The operational overhead of gathering multiple signatures may lead to workarounds that undermine security.

⚠️ Legal recognition of multi-sig varies by jurisdiction. Courts may not understand or recognize multi-sig configurations in disputes, estate planning, or regulatory contexts.

🔴 Multi-sig with disabled master key and insufficient active signers causes permanent fund loss. This has happened. Always maintain redundancy above threshold.

🔴 Same-vendor hardware for all signers creates correlated failure risk. A vulnerability affecting one device affects all. Use diverse key storage.

🔴 Colluding signers meeting threshold can steal funds. Multi-sig prevents external theft, not insider collusion. Additional controls needed for insider threat.

Multi-sig is the gold standard for protecting significant cryptocurrency holdings. It's the appropriate solution for any situation where a single person shouldn't have unilateral control—which includes most organizational and many personal high-value scenarios.

The challenges are operational, not cryptographic. Key management across organizational changes, coordination costs, and insider threat mitigation require careful procedural design. The cryptography is bulletproof; the human systems around it require ongoing attention.

Assignment: Create a comprehensive multi-sig policy document template suitable for organizational adoption, including configuration guidance, operational procedures, and governance framework.

Requirements:

Part 1: Configuration Policy

• When to use multi-sig vs. single-sig
• Threshold selection based on value and risk
• Signer selection criteria
• Weight assignment principles
• Diversity requirements (geography, vendor, organizational)

Part 2: Operational Procedures

• Key ceremony (initial setup)
• Transaction initiation and approval workflow
• Signature collection and verification
• Signer addition/removal
• Emergency procedures
• Regular security reviews

Part 3: Governance Framework

• Roles and responsibilities
• Approval authorities for different transaction types
• Escalation procedures
• Audit and compliance requirements
• Policy amendment process

Part 4: Risk Management

• Key loss scenarios and responses
• Compromise scenarios and responses
• Organizational change procedures
• Business continuity planning
• Insurance and legal considerations

Part 5: Implementation Checklist

• Pre-implementation review

• Implementation steps

• Post-implementation verification

• Ongoing maintenance tasks

• Policy completeness (30%)

• Practical applicability (25%)

• Security coverage (25%)

• Clarity and usability (20%)

Time Investment: 5-6 hours

Value: This template can be adopted directly by organizations implementing XRPL multi-sig, saving significant planning time and ensuring comprehensive coverage.

For Next Lesson:
We'll examine network-level security—how XRPL's peer-to-peer network resists Sybil attacks, eclipse attacks, and denial of service attempts that operate below the transaction layer.

End of Lesson 10

Total words: ~5,600
Estimated completion time: 60 minutes reading + 5-6 hours for deliverable