Operational Runbooks

Authored by:

Isaac Patka

SEAL | Shield3

Geoffrey Arone

Shield3

Louis Marquenet

Opsek

Pablo Sabbatella

SEAL | Opsek

Dickson Wu

SEAL

These are example runbooks for common multisig operations. Review and customize them for your protocol before use.

Token Transfer Runbook

Quick Reference

When to Use

Sending tokens (ETH, ERC20, SOL, SPL tokens) from a multisig to another address.

Prerequisites

• Recipient address verified via independent source (not just chat message)
• Amount confirmed
• Reason for transfer documented or approved

EVM (Safe) Procedure

1. Create Transaction

Proposer:

1. Go to https://app.safe.global
2. Select correct Safe and network
3. Click "New Transaction" > "Send tokens"
4. Enter recipient address (use checksummed format)
5. Select token and enter amount
6. Review and create transaction

2. Verify Transaction

Each signer must:

[ ] Correct Safe address
[ ] Correct network (Ethereum/Base/etc.)
[ ] Expected nonce
[ ] Recipient address matches independent source
[ ] Token is correct
[ ] Amount is correct
[ ] Simulation shows expected transfer
[ ] Message hash matches hardware wallet

Hash verification:

./safe_hashes.sh --network mainnet --address [SAFE_ADDRESS] --nonce [NONCE]

Or use OpenZeppelin Safe Utils.

Simulation check:

• Click "Simulate" in Safe UI
• Verify token transfer event shows correct recipient and amount
• No unexpected transfers or approvals

3. Sign

• Review transaction on hardware wallet
• Verify message hash matches tool output
• Sign
• Communicate: "Verified and signed, X more needed"

4. Execute

• Last signer clicks "Execute" (or designated executor)
• Confirm transaction on-chain via block explorer
• Communicate: "Executed - [tx hash]"

Solana (Squads) Procedure

1. Create Transaction

Proposer:

1. Go to https://squads.xyz/squads-multisig
2. Select correct Squad
3. Click "Send" > Select token
4. Enter recipient address and amount
5. Create proposal

2. Verify Transaction

Each signer must:

[ ] Correct Squad address
[ ] Recipient address matches independent source
[ ] Token is correct
[ ] Amount is correct
[ ] Simulation shows expected transfer

Simulation check:

• Click "Simulate" after first signature
• For SOL: Find "System Program Instruction", verify destination and amount
• For tokens: Find "Token Program Instruction", verify destination, mint, and amount

3. Sign

• Click "Approve"
• Verify hash in Squads UI matches Ledger display
• Sign on Ledger
• Communicate: "Verified and signed, X more needed"

4. Execute

• Last signer executes
• Verify on Solana Explorer
• Communicate: "Executed - [tx signature]"

Verification Details

Recipient Address

Always verify recipient via independent source:

• Direct communication with recipient (video call or verified channel)
• Published address in official documentation
• On-chain verification (existing relationship)

Never trust an address shared only via chat message.

Amount Verification

For ERC20 or SPL tokens, verify decimals:

• USDC or USDS: 6 decimals (1,000,000 = 1 token)
• Most ERC20: 18 decimals

Common Issues

Threshold Change Runbook

Quick Reference

When to Use

• Increasing threshold for higher security
• Decreasing threshold for operational efficiency
• Adjusting after signer count changes

Prerequisites

• Justification documented
• New threshold meets policy requirements:
  • Minimum 50% of signers
  • Cannot exceed total signer count
• If decreasing: approval from security contact
• All signers notified of change

Policy Requirements

EVM (Safe) Procedure

1. Create Transaction

Proposer:

1. Go to https://app.safe.global
2. Settings > Setup > Owners
3. Click "Change threshold"
4. Select new threshold from dropdown
5. Create transaction

2. Verify Transaction

Each signer must:

[ ] Transaction is ONLY changing threshold (no other changes)
[ ] New threshold value is correct
[ ] New threshold meets policy requirements
[ ] No signers being added or removed in same transaction
[ ] Message hash matches hardware wallet

Simulation check:

• Should show changeThreshold call to Safe
• New threshold value matches intended

3. Sign and Execute

Standard signing process:

• Verify hash on hardware wallet
• Sign
• Communicate: "Verified and signed, X more needed"
• Last signer executes

4. Verify

• Check Safe settings show new threshold
• Test that the next transaction requires new threshold

Solana (Squads) Procedure

1. Create Proposal

1. Go to https://squads.xyz/squads-multisig
2. Configuration > Change Threshold
3. Select new threshold
4. Create proposal

2. Verify and Sign

[ ] Only threshold being changed
[ ] New value is correct
[ ] Meets policy requirements

3. Execute

Standard execution after threshold reached.

Post-Change

• Update registration or internal documentation with new threshold
• Notify all signers of new threshold
• Update any documentation referencing old threshold

Common Scenarios

Adding Signer + Adjusting Threshold

When adding a signer, it is often appropriate to increase threshold.

Option 1: Two transactions

1. Add signer (threshold stays same)
2. Increase threshold

Option 2: Single batch transaction (EVM)

1. Use Transaction Builder
2. Batch addOwnerWithThreshold (sets new threshold automatically)

Removing Signer + Adjusting Threshold

When removing a signer, threshold cannot exceed new signer count:

1. If threshold equals signers: reduce threshold first or use batch
2. Remove signer transaction will auto-adjust if needed

Common Issues

Emergency Pause Runbook

This is an example runbook. Review and customize it for your protocol before use. Add your specific contract addresses, pause functions, emergency contacts, and communication channels.

Quick Reference

When to Use

• Active exploit detected
• Suspicious activity on protocol contracts
• Key compromise affecting protocol
• Vulnerability disclosure requiring immediate action

Immediate Actions (First 30 Minutes)

1. Alert Team

• Send alert to emergency Signal group
• Page signers via configured paging system
• Notify the security contact

Alert template:

URGENT: [Brief description]
Multisig: [Name]
Action needed: [Pause/Freeze/etc.]
Respond ASAP - <2hr SLA

2. Assess Situation

• Confirm threat is real (not false alarm)
• Identify affected contracts or assets
• Determine which pause function(s) to call
• Estimate urgency

3. Prepare Transaction

Proposer (can be any signer or delegated proposer):

1. Go to Safe or Squads UI
2. Use Transaction Builder for contract interaction
3. Select target contract
4. Select pause() or appropriate emergency function
5. Create transaction

Signing Process (Streamlined)

Emergency signing follows abbreviated verification.

Minimum Verification

[ ] Correct multisig address
[ ] Correct network
[ ] Target contract is correct (verify address)
[ ] Function is pause() or expected emergency function
[ ] No unexpected additional calls
[ ] Hash matches hardware wallet

Sign and Communicate

• Sign immediately after verification
• Message: "Signed - [X/Y] - [your name]"
• Stay available until executed

Execute

• Execute as soon as threshold is reached
• Verify pause took effect (check contract state)
• Communicate: "EXECUTED - pause confirmed"

Contract Reference

After Pause

Immediate (Within 1 hour)

• Confirm pause is effective
• Document incident using Incident Reporting
• Notify stakeholders

Short-term (Within 24 hours)

• Root cause analysis
• Plan for resolution
• Draft public communication if needed

Resolution

• Fix underlying issue
• Test fix thoroughly
• Plan unpause procedure
• Execute unpause with full verification (not emergency process)

If Primary UI is Down

Use backup infrastructure:

EVM:

1. Eternal Safe
2. Configure with backup RPC
3. Load Safe address
4. Create custom transaction with pause calldata

Solana:

1. Squads Backup
2. Configure RPC
3. Load multisig

See Backup Signing & Infrastructure for detailed instructions.

Key Compromise Variant

If a signer key is compromised:

1. Do not use compromised key for any operations
2. Alert team via backup channel (assume primary may be compromised)
3. Assess if attacker has threshold
4. Prepare signer rotation transaction
5. Execute removal of compromised signer
6. Rotate compromised signer to new address

Communication Channel Compromise

If a communication channel is compromised:

1. Switch to backup channel immediately
2. Verify identity of all participants via secondary method
3. Do not trust any pending requests from compromised channel
4. Assume attacker may attempt social engineering

Drill Checklist

For emergency drills (run bi-annually):

• Page all signers
• Measure time to reach threshold
• Practice emergency signing flow on testnet
• Test backup communication channels
• Test backup UIs
• Document results and improve procedures

Escalation

If threshold cannot be reached within SLA:

1. Contact backup signers
2. Escalate to decision makers
3. Consider alternative mitigations
4. Document why threshold was not met

Related Documents

• Safe Multisig: Step-by-Step Verification
• Squads Multisig: Step-by-Step Verification
• Emergency Procedures
• Backup Signing & Infrastructure
• Incident Reporting