From afacb8109e70063232bd801391316796dccd9d75 Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 29 Sep 2025 22:47:16 -0400 Subject: [PATCH 01/23] fix: update README.md for clarity and consistency in incident management playbooks --- .../treasury-ops/transaction-verification.mdx | 461 ++++++++++++++++++ 1 file changed, 461 insertions(+) create mode 100644 docs/pages/treasury-ops/transaction-verification.mdx diff --git a/docs/pages/treasury-ops/transaction-verification.mdx b/docs/pages/treasury-ops/transaction-verification.mdx new file mode 100644 index 00000000..d00d1306 --- /dev/null +++ b/docs/pages/treasury-ops/transaction-verification.mdx @@ -0,0 +1,461 @@ +--- +title: "Treasury Transaction Verification (Large Protocols & High-Value Movements)" +tags: + - Treasury Ops + - Protocol + - Operations + - Risk Management + - DeFi +contributors: + - role: wrote + users: [dickson] + +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Guide: Large Cryptocurrency Transfers + + + + +## Core Principles + +Large cryptocurrency transfers require rigorous verification because transactions are irreversible. This guide covers both receiving and sending significant amounts, with security measures scaling to transfer size. + +--- + +## Part 1: Receiving Large Transfers + +### Pre-Transfer Setup (48 Hours Before) + +#### Generate Fresh Deposit Address + +Always create a new address for large incoming transfers. Never reuse addresses from previous large transfers. + +**Why use fresh addresses?** Prevents counterparties from viewing your entire treasury balance/history and isolates each major transfer for clean audit trails. + +**For Institutional Custody** (Coinbase, Anchorage, BitGo): +- **Verify you're on the correct website** - check URL carefully, bookmark the official site, watch for phishing lookalikes +- Use the platform's "offline deposit address" or "new address" function +- Enable all available 2FA/MFA when generating addresses + +**For Self-Custody**: +- Use hardware wallet with verified firmware +- Document derivation path: `m/44'/60'/0'/0/x` (Ethereum) or `m/84'/0'/0'/0/x` (Bitcoin) + +**For higher security (>$5M transfers)**: Generate addresses in air-gapped environment - hardware wallet never connected to internet during address generation. + +#### Address Verification Protocol + +Have 2-3 team members independently verify the address: + +``` +1. Generate address in custody platform +2. Person A: Verify via custody UI +3. Person B: Verify via hardware wallet screen (if applicable) +4. Person C: Cross-check via block explorer after first test transaction +5. Perform checksum validation: + - Ethereum: EIP-55 checksum + - Bitcoin: Bech32 checksum +``` + +**For transfers >$1M**: Require all verifiers to sign a document confirming they verified the address character-by-character. + +#### Bidirectional Test Transaction + +This should occur **24-48 hours before the main transfer**. + +**Phase 1: Sender → You (Incoming Test)** +``` +1. Sender sends small amount (0.001 ETH or 0.0001 BTC) to your new address +2. Verify receipt through multiple sources: + - Custody platform interface + - Primary block explorer (Etherscan, Blockchain.com) + - Secondary block explorer (redundancy check) +3. Document transaction hash and confirmation time +``` + +**Phase 2: You → Sender (Outgoing Test)** +``` +4. Send test amount BACK to sender's address +5. Sender confirms they received the return +6. Sender provides return transaction hash +7. You verify the hash matches your outbound transaction +``` + +**Why bidirectional?** Proves address can both receive AND withdraw funds before large transfer arrives, and confirms both parties control their stated addresses. + +**For transfers >$1M**: Require sender to sign a message with their sending address proving cryptographic control, not just ability to send from it. + +#### Coordinate with Sender + +Provide via encrypted channel (PGP email or Signal): +- Deposit address +- Network specification (Ethereum mainnet chain ID 1, Bitcoin mainnet) +- Test transaction hash (incoming only) +- Video call scheduled time for live transfer + +Request from sender: +- Source wallet addresses they'll send from (for immediate detection when transaction broadcasts) +- Approximate transfer timing: specific date and time window + - Example: "Tuesday, March 15th, 2:00-6:00 PM EST" + - This allows you to have all required personnel available and monitoring +- Whether they'll use single or multiple transactions + +**Best practices for transaction splitting:** +- **<$10M**: Single transaction preferred (simpler, one confirmation cycle, cleaner records) +- **>$10M**: Consider 2-3 separate transactions (reduces single-transaction risk, allows staged confirmation, provides pause points to verify each step) +- **>$50M**: Multiple transactions strongly recommended with 30-minute intervals between each + +**For transfers >$5M - Anti-Social-Engineering Protocols:** + +Establish code phrase during initial verified meeting. Use this phrase to authenticate any address changes or unusual requests. Example: "What was the name of the restaurant where we finalized the agreement?" Exchange secondary contact numbers for key personnel - if primary contact requests changes, call secondary to confirm. Maintain out-of-band verification: if request comes via email, confirm via phone. + +**Red flags that should trigger immediate verification:** +- Urgent requests to bypass procedures or claims of "emergency" +- Requests to send to "temporary" or "new" address without proper verification +- Pressure to skip test transactions or any rushed requests + +If anything feels wrong, STOP and verify through multiple channels. Urgency is an attacker's favorite tool - legitimate counterparties will understand security delays. + +### Day of Transfer + +#### Pre-Transfer Video Verification (30 minutes prior to transfer) + +Require video call with minimum 2 internal people present. + +**Liveness and identity verification** (prevents AI deepfakes): +``` +1. Ask participant to hold up specific number of fingers (change unpredictably) +2. Ask them to wave their hand in front of their face +3. Request they state current date and time +4. Reference specific details from previous conversations only real participant would know +5. If anything seems off, halt the transfer and investigate +``` + +**Critical confirmations during call:** + +1. **Address Reconfirmation** + - Read deposit address character-by-character from your screen + - Sender confirms they see identical address on their screen + - **Critical: "Read ONLY from your custody platform or hardware wallet screen"** + - **Do NOT copy from email, Etherscan, any block explorer, or any intermediary source** + - **Only trust the address shown directly in your custody interface or on your hardware wallet device** + - This prevents compromised email or man-in-the-middle attacks from causing misdirection + +2. **Test Transaction Review** + - Display both test transactions on block explorer during call + - Confirm sender sees same transaction hashes + - Verify sender's address matches test transaction sender address + - Review the bidirectional test from 24-48 hours ago + +3. **Amount and Network** + - State total amount in native units and USD equivalent + - Confirm network explicitly: "Ethereum mainnet, chain ID 1" (not testnet, not L2) + - If ERC-20 tokens: State token name AND read out full contract address + - Example: "Sending 100,000 USDC, contract address 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" + - Verify contract address against official source (token website, CoinGecko) on call + - Confirm no mistakes in decimal places or token contract + +#### Live Monitoring + +**Understanding Blockchain Finality:** + +Wait for enough confirmations that a chain reorganization becomes economically infeasible or cryptographically impossible. + +**Monitoring phases:** +``` +1. Transaction Broadcast: Appears in mempool, verify correct parameters +2. First Confirmation: Included in a block +3. Progressive Confirmations: Each block makes reversal exponentially harder +4. Finality: Sufficient confirmations reached, transaction irreversible +``` + +**Confirmation requirements by chain:** + +- **Ethereum**: 12 confirmations (~3 minutes) | 32+ for >$10M transfers +- **Bitcoin**: 6 confirmations (~60 minutes) | 3 acceptable for <$100K +- **Polygon**: 128 confirmations (~5 minutes) +- **BSC**: 15 confirmations (~45 seconds) +- **Avalanche**: 1 confirmation (~2 seconds) +- **Solana**: 32 slots (~15 seconds) + +**For transfers >$10M**: Wait for double the standard confirmation count. + +**On-call updates from Technical Operator:** +- "Transaction in mempool, parameters correct" +- "Block 1 confirmed, no anomalies" +- "Block 12 confirmed, [X.XXX] ETH received and final" + +#### Dual Confirmation Requirement + +Before ending call, verify through TWO sources: +1. Custody platform showing updated balance +2. Block explorer showing confirmed transaction + +**For transfers >$10M**: Add third verification via direct node query or alternative explorer. + +#### Post-Receipt Actions + +**Immediate (within 15 min):** +- Document transaction hash, block number, timestamp +- Record amount in native units and USD equivalent +- Note all personnel involved + +**Within 30 minutes:** +- Email confirmation to sender with transaction details +- Update internal treasury ledger + +--- + +## Part 2: Sending Large Cryptocurrency Transfers + +### Pre-Transfer Planning (72 Hours Before) + +#### Authorization + +Document and obtain approvals: +- Purpose of transfer +- Recipient verification +- Amount and timeline +- Required signatures based on amount: + - <$100K: Treasury Manager + - $100K-$1M: CFO + Security Officer + - >$1M: CFO + CEO (or governance vote for DAOs) + +**For transfers >$10M**: Board resolution or full governance vote with documented quorum. + +#### Recipient Address Verification + +Multi-source verification is critical: + +``` +STEP 1: Receive address through official channel +├─> Request via verified email/signed contract +├─> Request recipient sign message proving address control + +STEP 2: Independent verification by 3 people +├─> Person A: Gets address from recipient's website +├─> Person B: Gets address from direct recipient communication +├─> Person C: Verifies via blockchain history (if known entity) +└─> All three MUST match exactly + +STEP 3: Mandatory test transaction +├─> Send $10-100 equivalent first +├─> Wait for recipient confirmation +├─> Recipient provides test transaction hash +├─> Verify hash matches your outbound transaction +└─> Proves recipient controls address and communications secure +``` + +**Never skip the test transaction.** This single step prevents the majority of costly errors. + +#### Whitelist Addition (If Using Custody Platform) + +Most institutional custody platforms support whitelisting: + +``` +1. Submit whitelist request with justification +2. Wait mandatory cooling-off period: + - Standard: 24-48 hours + - High security: 72 hours + - >$10M transfers: 1 week +3. Different team member approves whitelist addition +4. Test transaction AFTER whitelist approval +5. Then proceed with large transfer +``` + +**Why cooling-off periods?** Prevents attackers who gain account access from immediately adding malicious addresses and draining funds. Gives time for legitimate personnel to notice unauthorized changes. + +### Day of Transfer + +#### Final Verification Checklist (15 min before) + +Minimum 2 people present, verify: + +``` +□ Authorization documentation signed +□ Recipient address verified by 3 independent sources +□ Test transaction confirmed successful by recipient +□ Whitelist cooling-off period complete (if applicable) +□ Exact amount confirmed (recipient expects this amount) +□ Network confirmed (mainnet, not testnet) +□ Sufficient balance in source wallet (amount + fees + buffer) +□ All required approvers available next 60 minutes +``` + +**For transfers >$1M**: Conduct formal video call with all approvers present. + +#### Execution Protocol + +**Video Call Requirements** (for large transfers): + +``` +1. Screen share custody interface or wallet +2. Primary operator reads transaction parameters aloud: + - "Sending [X.XXXXX] ETH" + - "To address: 0x[read full address character-by-character]" + - "On network: Ethereum mainnet, chain ID 1" + +3. Each approver independently verifies on their device: + - Destination matches authorized recipient + - Amount matches approved transfer + - Network is correct (not testnet) + +4. Approvers use MFA to approve: + - Hardware security key, biometric, or authenticator app + - For hardware wallets: verify address on device screen + - Verbally confirm: "I approve this transaction" + +5. Final approval triggers broadcast to blockchain +``` + +**Critical verification moment**: After broadcast, immediately verify transaction hash shown in custody platform matches what appears in block explorer. This detects any tampering between approval and broadcast. + +#### Post-Submission Monitoring + +Monitor transaction through finality: + +``` +1. Copy transaction hash from custody platform +2. Enter into block explorer immediately +3. Verify parameters match intended transaction +4. Monitor confirmation progress: + - Ethereum: Wait for 12 confirmations (~3 minutes) + - Bitcoin: Wait for 6 confirmations (~60 minutes) + - For >$10M: Wait for double the standard confirmations +5. Watch for recipient confirmation of receipt +``` + +#### Confirmation and Documentation + +After transaction reaches finality: + +``` +1. Internal record (within 15 min): + - Transaction hash and block number + - Timestamp and confirmation count + - Source wallet balance updated in records + +2. Request receipt from recipient (within 30 min): + - Formal acknowledgment they received funds + - For >$1M: Signed receipt document + +3. Permanent documentation: + - Full transaction details (hash, block, timestamp, amount) + - Authorization chain (who approved, when) + - Personnel involved + - Total cost (amount + fees) + - USD equivalent at execution time +``` + +--- + +## Multi-Signature Best Practices + +### Signer Security + +Each signer maintains: +- Dedicated hardware wallet for treasury operations +- Verified and updated firmware +- Secure physical storage when not in use +- Backup seed phrase in separate geographic location +- No delegation of signing authority + +**For >$5M treasuries**: Geographically distribute signers across time zones and jurisdictions. + +### Threshold Configurations + +Scale security with asset value: + +``` +$100K-$1M: 2-of-3 multi-sig +$1M-$10M: 3-of-5 multi-sig +$10M-$50M: 4-of-6 multi-sig +>$50M: 5-of-7 or higher +``` + +### Signing Ceremony (>$10M transfers) + +Formal process for largest transfers: + +``` +1. Schedule 48 hours in advance +2. Each signer receives transaction details packet +3. Independent verification by each signer +4. Video conference with all signers +5. Screen share showing parameters +6. Each signer reads parameters aloud +7. Sequential signing with narration +8. Final signer confirms broadcast +9. All verify transaction in explorer +10. Session recorded and documented +``` + +--- + +## Critical Risk Mitigations + +### Address Verification + +**Hardware wallet display verification:** +- Always check address on hardware wallet screen +- Never trust computer display alone +- Verify entire address character-by-character + +**Address poisoning defense:** +- Never copy from transaction history +- Always copy from authoritative source +- Use custody platform address books when available + +### Communication Security + +**Email compromise prevention:** +- Address confirmation during video call prevents MITM +- Live verbal verification catches discrepancies +- Code phrases for authentication + +**Social engineering defense:** +- Never accept urgent bypass requests +- Callback on known numbers to verify +- Any request to skip verification triggers security review + +### Multi-Party Controls + +**Prevents single-actor fraud:** +- Multiple personnel for large transfers +- Video recording of approvals (with consent) +- Separation of duties: requester ≠ approver ≠ technical executor + +### Transaction Parameter Security + +**Custody platform policy engines:** +- Enforce withdrawal limits automatically +- Block transactions to non-whitelisted addresses +- Require elevated approvals above thresholds +- Create circuit breakers if account compromised + +--- + +## Key Principles Summary + +1. **Test everything**: Small test transactions can catch human errors +2. **Verify independently**: Multiple people through different channels +3. **Never rush**: Urgency benefits attackers, not you +4. **Hardware wallet verification**: Trust the device screen, not the computer +5. **Verify addresses**: Verify addresses during video calls +6. **Defense in depth**: One failure shouldn't cause catastrophic loss + +**In cryptocurrency, there are no chargebacks.** Every transaction is final. The procedures in this guide may seem extensive, but preventing a single mistake justifies significant operational overhead. + +The cost of verification is measured in minutes. The cost of a mistake is measured in millions. + +--- + + + + From 01550344c07ccbfa21052c065a9776f47482dcef Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 29 Sep 2025 23:15:47 -0400 Subject: [PATCH 02/23] refactor: enhance transaction verification documentation for clarity and security protocols - Streamlined address verification steps and clarified requirements for test transactions. - Updated security protocols for large transfers, including anti-social-engineering measures. - Improved formatting and consistency throughout the document for better readability. --- .../treasury-ops/transaction-verification.mdx | 127 +++++------------- 1 file changed, 30 insertions(+), 97 deletions(-) diff --git a/docs/pages/treasury-ops/transaction-verification.mdx b/docs/pages/treasury-ops/transaction-verification.mdx index d00d1306..0ab5720f 100644 --- a/docs/pages/treasury-ops/transaction-verification.mdx +++ b/docs/pages/treasury-ops/transaction-verification.mdx @@ -41,13 +41,11 @@ Always create a new address for large incoming transfers. Never reuse addresses **For Institutional Custody** (Coinbase, Anchorage, BitGo): - **Verify you're on the correct website** - check URL carefully, bookmark the official site, watch for phishing lookalikes - Use the platform's "offline deposit address" or "new address" function -- Enable all available 2FA/MFA when generating addresses **For Self-Custody**: - Use hardware wallet with verified firmware - Document derivation path: `m/44'/60'/0'/0/x` (Ethereum) or `m/84'/0'/0'/0/x` (Bitcoin) - -**For higher security (>$5M transfers)**: Generate addresses in air-gapped environment - hardware wallet never connected to internet during address generation. +- Generate addresses in air-gapped device/environment #### Address Verification Protocol @@ -55,9 +53,8 @@ Have 2-3 team members independently verify the address: ``` 1. Generate address in custody platform -2. Person A: Verify via custody UI -3. Person B: Verify via hardware wallet screen (if applicable) -4. Person C: Cross-check via block explorer after first test transaction +2. Person A: Verify via custody UI (if applicable) +3. Person B: Verify via hardware wallet (if applicable) 5. Perform checksum validation: - Ethereum: EIP-55 checksum - Bitcoin: Bech32 checksum @@ -81,16 +78,12 @@ This should occur **24-48 hours before the main transfer**. **Phase 2: You → Sender (Outgoing Test)** ``` -4. Send test amount BACK to sender's address -5. Sender confirms they received the return -6. Sender provides return transaction hash -7. You verify the hash matches your outbound transaction +4. Send test amount BACK to another address you control +5. You confirm you received the return transaction ``` **Why bidirectional?** Proves address can both receive AND withdraw funds before large transfer arrives, and confirms both parties control their stated addresses. -**For transfers >$1M**: Require sender to sign a message with their sending address proving cryptographic control, not just ability to send from it. - #### Coordinate with Sender Provide via encrypted channel (PGP email or Signal): @@ -100,7 +93,7 @@ Provide via encrypted channel (PGP email or Signal): - Video call scheduled time for live transfer Request from sender: -- Source wallet addresses they'll send from (for immediate detection when transaction broadcasts) +- Source wallet addresses they'll send from - Approximate transfer timing: specific date and time window - Example: "Tuesday, March 15th, 2:00-6:00 PM EST" - This allows you to have all required personnel available and monitoring @@ -111,7 +104,7 @@ Request from sender: - **>$10M**: Consider 2-3 separate transactions (reduces single-transaction risk, allows staged confirmation, provides pause points to verify each step) - **>$50M**: Multiple transactions strongly recommended with 30-minute intervals between each -**For transfers >$5M - Anti-Social-Engineering Protocols:** +**Anti-Social-Engineering Protocols:** Establish code phrase during initial verified meeting. Use this phrase to authenticate any address changes or unusual requests. Example: "What was the name of the restaurant where we finalized the agreement?" Exchange secondary contact numbers for key personnel - if primary contact requests changes, call secondary to confirm. Maintain out-of-band verification: if request comes via email, confirm via phone. @@ -126,7 +119,7 @@ If anything feels wrong, STOP and verify through multiple channels. Urgency is a #### Pre-Transfer Video Verification (30 minutes prior to transfer) -Require video call with minimum 2 internal people present. +Require video call with minimum 2 _internal_ people present. **Liveness and identity verification** (prevents AI deepfakes): ``` @@ -142,15 +135,14 @@ Require video call with minimum 2 internal people present. 1. **Address Reconfirmation** - Read deposit address character-by-character from your screen - Sender confirms they see identical address on their screen - - **Critical: "Read ONLY from your custody platform or hardware wallet screen"** + - **Critical: "Read ONLY from your custody platform or hardware wallet"** - **Do NOT copy from email, Etherscan, any block explorer, or any intermediary source** - - **Only trust the address shown directly in your custody interface or on your hardware wallet device** - - This prevents compromised email or man-in-the-middle attacks from causing misdirection + - **Only trust the address shown directly in your custody interface or on your hardware wallet** + - This prevents compromised email, address poisoning, and man-in-the-middle attacks from causing misdirection 2. **Test Transaction Review** - - Display both test transactions on block explorer during call - - Confirm sender sees same transaction hashes - - Verify sender's address matches test transaction sender address + - Display test transaction on block explorer during call + - Confirm sender sees same transaction hash - Review the bidirectional test from 24-48 hours ago 3. **Amount and Network** @@ -177,14 +169,10 @@ Wait for enough confirmations that a chain reorganization becomes economically i **Confirmation requirements by chain:** -- **Ethereum**: 12 confirmations (~3 minutes) | 32+ for >$10M transfers -- **Bitcoin**: 6 confirmations (~60 minutes) | 3 acceptable for <$100K +- **Ethereum**: 12 confirmations (~2.5 minutes) +- **Bitcoin**: 6 confirmations (~60 minutes) - **Polygon**: 128 confirmations (~5 minutes) -- **BSC**: 15 confirmations (~45 seconds) -- **Avalanche**: 1 confirmation (~2 seconds) -- **Solana**: 32 slots (~15 seconds) - -**For transfers >$10M**: Wait for double the standard confirmation count. +- **Solana**: ~12.8 seconds **On-call updates from Technical Operator:** - "Transaction in mempool, parameters correct" @@ -197,8 +185,6 @@ Before ending call, verify through TWO sources: 1. Custody platform showing updated balance 2. Block explorer showing confirmed transaction -**For transfers >$10M**: Add third verification via direct node query or alternative explorer. - #### Post-Receipt Actions **Immediate (within 15 min):** @@ -208,7 +194,6 @@ Before ending call, verify through TWO sources: **Within 30 minutes:** - Email confirmation to sender with transaction details -- Update internal treasury ledger --- @@ -225,9 +210,7 @@ Document and obtain approvals: - Required signatures based on amount: - <$100K: Treasury Manager - $100K-$1M: CFO + Security Officer - - >$1M: CFO + CEO (or governance vote for DAOs) - -**For transfers >$10M**: Board resolution or full governance vote with documented quorum. + - >$1M: CFO + CEO #### Recipient Address Verification @@ -236,13 +219,9 @@ Multi-source verification is critical: ``` STEP 1: Receive address through official channel ├─> Request via verified email/signed contract -├─> Request recipient sign message proving address control -STEP 2: Independent verification by 3 people -├─> Person A: Gets address from recipient's website -├─> Person B: Gets address from direct recipient communication -├─> Person C: Verifies via blockchain history (if known entity) -└─> All three MUST match exactly +STEP 2: Independent verification through multiple sources (e.g., email, phone call) +├─> At least two team members independently confirm the recipient address using different communication channels (such as verified email and a direct phone call with the recipient) STEP 3: Mandatory test transaction ├─> Send $10-100 equivalent first @@ -252,21 +231,19 @@ STEP 3: Mandatory test transaction └─> Proves recipient controls address and communications secure ``` -**Never skip the test transaction.** This single step prevents the majority of costly errors. +**Never skip the test transaction.** #### Whitelist Addition (If Using Custody Platform) -Most institutional custody platforms support whitelisting: +Most custody platforms support whitelisting: ``` 1. Submit whitelist request with justification 2. Wait mandatory cooling-off period: - Standard: 24-48 hours - High security: 72 hours - - >$10M transfers: 1 week 3. Different team member approves whitelist addition 4. Test transaction AFTER whitelist approval -5. Then proceed with large transfer ``` **Why cooling-off periods?** Prevents attackers who gain account access from immediately adding malicious addresses and draining funds. Gives time for legitimate personnel to notice unauthorized changes. @@ -275,11 +252,11 @@ Most institutional custody platforms support whitelisting: #### Final Verification Checklist (15 min before) -Minimum 2 people present, verify: +Minimum 2 _internal_ people present, verify: ``` □ Authorization documentation signed -□ Recipient address verified by 3 independent sources +□ Recipient address verified by 2 independent sources □ Test transaction confirmed successful by recipient □ Whitelist cooling-off period complete (if applicable) □ Exact amount confirmed (recipient expects this amount) @@ -292,7 +269,7 @@ Minimum 2 people present, verify: #### Execution Protocol -**Video Call Requirements** (for large transfers): +**Video Call Requirements**: ``` 1. Screen share custody interface or wallet @@ -304,7 +281,7 @@ Minimum 2 people present, verify: 3. Each approver independently verifies on their device: - Destination matches authorized recipient - Amount matches approved transfer - - Network is correct (not testnet) + - Network is correct 4. Approvers use MFA to approve: - Hardware security key, biometric, or authenticator app @@ -314,8 +291,6 @@ Minimum 2 people present, verify: 5. Final approval triggers broadcast to blockchain ``` -**Critical verification moment**: After broadcast, immediately verify transaction hash shown in custody platform matches what appears in block explorer. This detects any tampering between approval and broadcast. - #### Post-Submission Monitoring Monitor transaction through finality: @@ -327,7 +302,6 @@ Monitor transaction through finality: 4. Monitor confirmation progress: - Ethereum: Wait for 12 confirmations (~3 minutes) - Bitcoin: Wait for 6 confirmations (~60 minutes) - - For >$10M: Wait for double the standard confirmations 5. Watch for recipient confirmation of receipt ``` @@ -343,58 +317,18 @@ After transaction reaches finality: 2. Request receipt from recipient (within 30 min): - Formal acknowledgment they received funds - - For >$1M: Signed receipt document 3. Permanent documentation: - Full transaction details (hash, block, timestamp, amount) - Authorization chain (who approved, when) - Personnel involved - - Total cost (amount + fees) - - USD equivalent at execution time ``` --- ## Multi-Signature Best Practices -### Signer Security - -Each signer maintains: -- Dedicated hardware wallet for treasury operations -- Verified and updated firmware -- Secure physical storage when not in use -- Backup seed phrase in separate geographic location -- No delegation of signing authority - -**For >$5M treasuries**: Geographically distribute signers across time zones and jurisdictions. - -### Threshold Configurations - -Scale security with asset value: - -``` -$100K-$1M: 2-of-3 multi-sig -$1M-$10M: 3-of-5 multi-sig -$10M-$50M: 4-of-6 multi-sig ->$50M: 5-of-7 or higher -``` - -### Signing Ceremony (>$10M transfers) - -Formal process for largest transfers: - -``` -1. Schedule 48 hours in advance -2. Each signer receives transaction details packet -3. Independent verification by each signer -4. Video conference with all signers -5. Screen share showing parameters -6. Each signer reads parameters aloud -7. Sequential signing with narration -8. Final signer confirms broadcast -9. All verify transaction in explorer -10. Session recorded and documented -``` +See the[Multisigs for Protocols](/wallet-security/multisigs-for-protocols/overview) guide. --- @@ -403,7 +337,7 @@ Formal process for largest transfers: ### Address Verification **Hardware wallet display verification:** -- Always check address on hardware wallet screen +- Always check address on hardware wallet - Never trust computer display alone - Verify entire address character-by-character @@ -427,8 +361,8 @@ Formal process for largest transfers: ### Multi-Party Controls **Prevents single-actor fraud:** -- Multiple personnel for large transfers -- Video recording of approvals (with consent) +- Multiple personnel +- Video recording of approvals - Separation of duties: requester ≠ approver ≠ technical executor ### Transaction Parameter Security @@ -446,9 +380,8 @@ Formal process for largest transfers: 1. **Test everything**: Small test transactions can catch human errors 2. **Verify independently**: Multiple people through different channels 3. **Never rush**: Urgency benefits attackers, not you -4. **Hardware wallet verification**: Trust the device screen, not the computer +4. **Hardware wallet verification**: Trust the device, not the computer 5. **Verify addresses**: Verify addresses during video calls -6. **Defense in depth**: One failure shouldn't cause catastrophic loss **In cryptocurrency, there are no chargebacks.** Every transaction is final. The procedures in this guide may seem extensive, but preventing a single mistake justifies significant operational overhead. From 1277089fd95b380971afcc961b165f78a6f82fe9 Mon Sep 17 00:00:00 2001 From: Dickson Date: Tue, 30 Sep 2025 10:37:54 -0400 Subject: [PATCH 03/23] feat: add Treasury Operations guide for large cryptocurrency transfers - Introduced a new section in the vocs.config.ts for Treasury Operations, including a guide on transaction verification for large transfers. - Created a comprehensive documentation file for Treasury Transaction Verification, detailing security protocols, verification steps, and best practices for handling significant cryptocurrency movements. - Updated fetched-tags.json to include relevant tags for the new guide. --- .../transaction-verification.mdx | 12 +++++----- utils/fetched-tags.json | 22 +++++++++++++------ vocs.config.ts | 8 +++++++ 3 files changed, 29 insertions(+), 13 deletions(-) rename docs/pages/{treasury-ops => treasury-operations}/transaction-verification.mdx (96%) diff --git a/docs/pages/treasury-ops/transaction-verification.mdx b/docs/pages/treasury-operations/transaction-verification.mdx similarity index 96% rename from docs/pages/treasury-ops/transaction-verification.mdx rename to docs/pages/treasury-operations/transaction-verification.mdx index 0ab5720f..b8f22f48 100644 --- a/docs/pages/treasury-ops/transaction-verification.mdx +++ b/docs/pages/treasury-operations/transaction-verification.mdx @@ -100,9 +100,9 @@ Request from sender: - Whether they'll use single or multiple transactions **Best practices for transaction splitting:** -- **<$10M**: Single transaction preferred (simpler, one confirmation cycle, cleaner records) -- **>$10M**: Consider 2-3 separate transactions (reduces single-transaction risk, allows staged confirmation, provides pause points to verify each step) -- **>$50M**: Multiple transactions strongly recommended with 30-minute intervals between each +- **\<$10M**: Single transaction preferred (simpler, one confirmation cycle, cleaner records) +- **\>$10M**: Consider 2-3 separate transactions (reduces single-transaction risk, allows staged confirmation, provides pause points to verify each step) +- **\>$50M**: Multiple transactions strongly recommended with 30-minute intervals between each **Anti-Social-Engineering Protocols:** @@ -208,9 +208,9 @@ Document and obtain approvals: - Recipient verification - Amount and timeline - Required signatures based on amount: - - <$100K: Treasury Manager + - \<$100K: Treasury Manager - $100K-$1M: CFO + Security Officer - - >$1M: CFO + CEO + - \>$1M: CFO + CEO #### Recipient Address Verification @@ -265,7 +265,7 @@ Minimum 2 _internal_ people present, verify: □ All required approvers available next 60 minutes ``` -**For transfers >$1M**: Conduct formal video call with all approvers present. +**For transfers \>$1M**: Conduct formal video call with all approvers present. #### Execution Protocol diff --git a/utils/fetched-tags.json b/utils/fetched-tags.json index 3d61ba29..61982812 100644 --- a/utils/fetched-tags.json +++ b/utils/fetched-tags.json @@ -5,22 +5,23 @@ "Community & Marketing", "Compliance", "DAO", + "DeFi", "Devops", "Engineer/Developer", "HR", "Human Resources", "Individual Security", "Legal & Compliance", + "Operations", "Operations & Strategy", "Physical Security", "Protocol", + "Risk Management", "SEAL/Initiative", "SRE", - "Security", "Security Specialist", - "Threat Actors", "Travel", - "Wallet Drainers", + "Treasury Ops", "Web3", "Whitehat" ], @@ -365,12 +366,12 @@ "SRE" ], "/incident-management/playbooks/hacked-drainer": [ - "Security", - "Wallet Drainers" + "Security Specialist", + "Operations & Strategy" ], "/incident-management/playbooks/hacked-elusive-comet": [ - "Security", - "Threat Actors" + "Security Specialist", + "Operations & Strategy" ], "/incident-management/playbooks/malware": [ "Security Specialist", @@ -921,6 +922,13 @@ "Engineer/Developer", "Security Specialist" ], + "/treasury-ops/transaction-verification": [ + "Treasury Ops", + "Protocol", + "Operations", + "Risk Management", + "DeFi" + ], "/vulnerability-disclosure/bug-bounties": [ "Engineer/Developer", "Security Specialist" diff --git a/vocs.config.ts b/vocs.config.ts index ecd53f24..fa0075c1 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -358,6 +358,14 @@ const config = { { text: 'Volume Encryption', link: '/encryption/volume-encryption', dev: true }, ] }, + { + text: 'Treasury Operations', + collapsed: false, + dev: true, + items: [ + { text: 'Guide: Large Cryptocurrency Transfers', link: '/treasury-operations/transaction-verification', dev: true }, + ] + }, ] }, { From 96136ea07f9277fe7d7fba8e052199fee3c224ab Mon Sep 17 00:00:00 2001 From: Dickson Date: Tue, 30 Sep 2025 23:10:06 -0400 Subject: [PATCH 04/23] refactor: update transaction verification documentation for clarity and best practices - Revised sections on deposit address selection for both institutional custody and self-custody multisigs, emphasizing the importance of using established addresses. - Enhanced address verification protocols, including detailed steps for verifying multisig configurations. - Clarified critical instructions for address confirmation during transactions, ensuring security against phishing and address poisoning. - Improved overall formatting and consistency for better readability. --- .../transaction-verification.mdx | 45 ++++++++++--------- 1 file changed, 25 insertions(+), 20 deletions(-) diff --git a/docs/pages/treasury-operations/transaction-verification.mdx b/docs/pages/treasury-operations/transaction-verification.mdx index b8f22f48..5fa6cc02 100644 --- a/docs/pages/treasury-operations/transaction-verification.mdx +++ b/docs/pages/treasury-operations/transaction-verification.mdx @@ -32,32 +32,35 @@ Large cryptocurrency transfers require rigorous verification because transaction ### Pre-Transfer Setup (48 Hours Before) -#### Generate Fresh Deposit Address +#### Choose Appropriate Deposit Address -Always create a new address for large incoming transfers. Never reuse addresses from previous large transfers. - -**Why use fresh addresses?** Prevents counterparties from viewing your entire treasury balance/history and isolates each major transfer for clean audit trails. +The address strategy depends on your custody model: **For Institutional Custody** (Coinbase, Anchorage, BitGo): +- **Always generate a fresh deposit address** for large incoming transfers - **Verify you're on the correct website** - check URL carefully, bookmark the official site, watch for phishing lookalikes - Use the platform's "offline deposit address" or "new address" function +- **Why fresh addresses?** Prevents counterparties from viewing your entire treasury balance/history and isolates each major transfer for clean audit trails -**For Self-Custody**: -- Use hardware wallet with verified firmware -- Document derivation path: `m/44'/60'/0'/0/x` (Ethereum) or `m/84'/0'/0'/0/x` (Bitcoin) -- Generate addresses in air-gapped device/environment +**For Self-Custody Multisigs**: +- **Use your established, proven multisig address** that has been successfully tested in prior transactions +- **Never generate a fresh multisig for large transfers** - multisig setup is complex and a new deployment risks misconfiguration +- The battle-tested multisig you've been using is safer than a newly created one +- Document the multisig configuration: threshold (e.g., 3-of-5), signer addresses, and deployment transaction +- Verify multisig configuration on block explorer before providing address to sender #### Address Verification Protocol Have 2-3 team members independently verify the address: ``` -1. Generate address in custody platform -2. Person A: Verify via custody UI (if applicable) -3. Person B: Verify via hardware wallet (if applicable) -5. Perform checksum validation: +1. Retrieve address from custody platform or multisig interface +2. Person A: Verify via custody UI or block explorer (multisig configuration) +3. Person B: Independently verify via separate block explorer or multisig interface +4. Perform checksum validation: - Ethereum: EIP-55 checksum - Bitcoin: Bech32 checksum +5. For multisigs: Verify threshold and signer configuration match expected setup ``` **For transfers >$1M**: Require all verifiers to sign a document confirming they verified the address character-by-character. @@ -135,9 +138,10 @@ Require video call with minimum 2 _internal_ people present. 1. **Address Reconfirmation** - Read deposit address character-by-character from your screen - Sender confirms they see identical address on their screen - - **Critical: "Read ONLY from your custody platform or hardware wallet"** + - **Critical: "Read ONLY from your custody platform or multisig interface (Safe, Zodiac, etc.)"** - **Do NOT copy from email, Etherscan, any block explorer, or any intermediary source** - - **Only trust the address shown directly in your custody interface or on your hardware wallet** + - **Only trust the address shown directly in your custody interface or multisig platform** + - For multisigs: State the configuration (e.g., "3-of-5 multisig at address 0x...") - This prevents compromised email, address poisoning, and man-in-the-middle attacks from causing misdirection 2. **Test Transaction Review** @@ -285,7 +289,7 @@ Minimum 2 _internal_ people present, verify: 4. Approvers use MFA to approve: - Hardware security key, biometric, or authenticator app - - For hardware wallets: verify address on device screen + - For multisigs: Each signer verifies transaction details on their signing device - Verbally confirm: "I approve this transaction" 5. Final approval triggers broadcast to blockchain @@ -336,9 +340,10 @@ See the[Multisigs for Protocols](/wallet-security/multisigs-for-protocols/overvi ### Address Verification -**Hardware wallet display verification:** -- Always check address on hardware wallet -- Never trust computer display alone +**Multisig and custody interface verification:** +- Always verify addresses directly from your custody platform or multisig interface (Safe, Zodiac, etc.) +- For multisigs: Cross-check configuration (threshold, signers) on block explorer +- Never trust copy-pasted addresses from email or chat - Verify entire address character-by-character **Address poisoning defense:** @@ -380,8 +385,8 @@ See the[Multisigs for Protocols](/wallet-security/multisigs-for-protocols/overvi 1. **Test everything**: Small test transactions can catch human errors 2. **Verify independently**: Multiple people through different channels 3. **Never rush**: Urgency benefits attackers, not you -4. **Hardware wallet verification**: Trust the device, not the computer -5. **Verify addresses**: Verify addresses during video calls +4. **Use multisig for self-custody**: Multiple signers prevent single points of failure +5. **Verify addresses live**: Always verify addresses during video calls from authoritative sources **In cryptocurrency, there are no chargebacks.** Every transaction is final. The procedures in this guide may seem extensive, but preventing a single mistake justifies significant operational overhead. From f4d9dc7205df2b2ff003d02ea9e842e51f20beae Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 3 Oct 2025 23:42:29 -0400 Subject: [PATCH 05/23] refactor: improve transaction verification documentation and fix tag path - Enhanced clarity and formatting throughout the transaction verification guide, including detailed steps for address verification and test transactions. - Updated the tag path in fetched-tags.json to reflect the correct directory structure for the transaction verification documentation. - Added additional best practices for security during large cryptocurrency transfers, ensuring comprehensive coverage of verification protocols. --- .../transaction-verification.mdx | 47 ++++++++++++++----- utils/fetched-tags.json | 2 +- 2 files changed, 36 insertions(+), 13 deletions(-) diff --git a/docs/pages/treasury-operations/transaction-verification.mdx b/docs/pages/treasury-operations/transaction-verification.mdx index 5fa6cc02..11742524 100644 --- a/docs/pages/treasury-operations/transaction-verification.mdx +++ b/docs/pages/treasury-operations/transaction-verification.mdx @@ -9,10 +9,15 @@ tags: contributors: - role: wrote users: [dickson] - --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +import { + TagList, + AttributionList, + TagProvider, + TagFilter, + ContributeFooter, +} from "../../../components"; @@ -26,8 +31,6 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr Large cryptocurrency transfers require rigorous verification because transactions are irreversible. This guide covers both receiving and sending significant amounts, with security measures scaling to transfer size. ---- - ## Part 1: Receiving Large Transfers ### Pre-Transfer Setup (48 Hours Before) @@ -37,17 +40,19 @@ Large cryptocurrency transfers require rigorous verification because transaction The address strategy depends on your custody model: **For Institutional Custody** (Coinbase, Anchorage, BitGo): + - **Always generate a fresh deposit address** for large incoming transfers - **Verify you're on the correct website** - check URL carefully, bookmark the official site, watch for phishing lookalikes - Use the platform's "offline deposit address" or "new address" function - **Why fresh addresses?** Prevents counterparties from viewing your entire treasury balance/history and isolates each major transfer for clean audit trails **For Self-Custody Multisigs**: + - **Use your established, proven multisig address** that has been successfully tested in prior transactions - **Never generate a fresh multisig for large transfers** - multisig setup is complex and a new deployment risks misconfiguration - The battle-tested multisig you've been using is safer than a newly created one - Document the multisig configuration: threshold (e.g., 3-of-5), signer addresses, and deployment transaction -- Verify multisig configuration on block explorer before providing address to sender +- Verify multisig configuration on block explorer before providing address to sender #### Address Verification Protocol @@ -70,6 +75,7 @@ Have 2-3 team members independently verify the address: This should occur **24-48 hours before the main transfer**. **Phase 1: Sender → You (Incoming Test)** + ``` 1. Sender sends small amount (0.001 ETH or 0.0001 BTC) to your new address 2. Verify receipt through multiple sources: @@ -80,6 +86,7 @@ This should occur **24-48 hours before the main transfer**. ``` **Phase 2: You → Sender (Outgoing Test)** + ``` 4. Send test amount BACK to another address you control 5. You confirm you received the return transaction @@ -90,12 +97,14 @@ This should occur **24-48 hours before the main transfer**. #### Coordinate with Sender Provide via encrypted channel (PGP email or Signal): + - Deposit address - Network specification (Ethereum mainnet chain ID 1, Bitcoin mainnet) - Test transaction hash (incoming only) - Video call scheduled time for live transfer Request from sender: + - Source wallet addresses they'll send from - Approximate transfer timing: specific date and time window - Example: "Tuesday, March 15th, 2:00-6:00 PM EST" @@ -103,6 +112,7 @@ Request from sender: - Whether they'll use single or multiple transactions **Best practices for transaction splitting:** + - **\<$10M**: Single transaction preferred (simpler, one confirmation cycle, cleaner records) - **\>$10M**: Consider 2-3 separate transactions (reduces single-transaction risk, allows staged confirmation, provides pause points to verify each step) - **\>$50M**: Multiple transactions strongly recommended with 30-minute intervals between each @@ -112,6 +122,7 @@ Request from sender: Establish code phrase during initial verified meeting. Use this phrase to authenticate any address changes or unusual requests. Example: "What was the name of the restaurant where we finalized the agreement?" Exchange secondary contact numbers for key personnel - if primary contact requests changes, call secondary to confirm. Maintain out-of-band verification: if request comes via email, confirm via phone. **Red flags that should trigger immediate verification:** + - Urgent requests to bypass procedures or claims of "emergency" - Requests to send to "temporary" or "new" address without proper verification - Pressure to skip test transactions or any rushed requests @@ -125,6 +136,7 @@ If anything feels wrong, STOP and verify through multiple channels. Urgency is a Require video call with minimum 2 _internal_ people present. **Liveness and identity verification** (prevents AI deepfakes): + ``` 1. Ask participant to hold up specific number of fingers (change unpredictably) 2. Ask them to wave their hand in front of their face @@ -136,6 +148,7 @@ Require video call with minimum 2 _internal_ people present. **Critical confirmations during call:** 1. **Address Reconfirmation** + - Read deposit address character-by-character from your screen - Sender confirms they see identical address on their screen - **Critical: "Read ONLY from your custody platform or multisig interface (Safe, Zodiac, etc.)"** @@ -145,6 +158,7 @@ Require video call with minimum 2 _internal_ people present. - This prevents compromised email, address poisoning, and man-in-the-middle attacks from causing misdirection 2. **Test Transaction Review** + - Display test transaction on block explorer during call - Confirm sender sees same transaction hash - Review the bidirectional test from 24-48 hours ago @@ -164,6 +178,7 @@ Require video call with minimum 2 _internal_ people present. Wait for enough confirmations that a chain reorganization becomes economically infeasible or cryptographically impossible. **Monitoring phases:** + ``` 1. Transaction Broadcast: Appears in mempool, verify correct parameters 2. First Confirmation: Included in a block @@ -179,6 +194,7 @@ Wait for enough confirmations that a chain reorganization becomes economically i - **Solana**: ~12.8 seconds **On-call updates from Technical Operator:** + - "Transaction in mempool, parameters correct" - "Block 1 confirmed, no anomalies" - "Block 12 confirmed, [X.XXX] ETH received and final" @@ -186,20 +202,21 @@ Wait for enough confirmations that a chain reorganization becomes economically i #### Dual Confirmation Requirement Before ending call, verify through TWO sources: + 1. Custody platform showing updated balance 2. Block explorer showing confirmed transaction #### Post-Receipt Actions **Immediate (within 15 min):** + - Document transaction hash, block number, timestamp - Record amount in native units and USD equivalent - Note all personnel involved **Within 30 minutes:** -- Email confirmation to sender with transaction details ---- +- Email confirmation to sender with transaction details ## Part 2: Sending Large Cryptocurrency Transfers @@ -208,6 +225,7 @@ Before ending call, verify through TWO sources: #### Authorization Document and obtain approvals: + - Purpose of transfer - Recipient verification - Amount and timeline @@ -281,12 +299,12 @@ Minimum 2 _internal_ people present, verify: - "Sending [X.XXXXX] ETH" - "To address: 0x[read full address character-by-character]" - "On network: Ethereum mainnet, chain ID 1" - + 3. Each approver independently verifies on their device: - Destination matches authorized recipient - Amount matches approved transfer - Network is correct - + 4. Approvers use MFA to approve: - Hardware security key, biometric, or authenticator app - For multisigs: Each signer verifies transaction details on their signing device @@ -332,21 +350,23 @@ After transaction reaches finality: ## Multi-Signature Best Practices -See the[Multisigs for Protocols](/wallet-security/multisigs-for-protocols/overview) guide. +See the Multisigs for Protocols guide. ---- +# TODO: Add link to Multisigs for Protocols guide. AFTER IT IS MERGED ## Critical Risk Mitigations ### Address Verification **Multisig and custody interface verification:** + - Always verify addresses directly from your custody platform or multisig interface (Safe, Zodiac, etc.) - For multisigs: Cross-check configuration (threshold, signers) on block explorer - Never trust copy-pasted addresses from email or chat - Verify entire address character-by-character **Address poisoning defense:** + - Never copy from transaction history - Always copy from authoritative source - Use custody platform address books when available @@ -354,11 +374,13 @@ See the[Multisigs for Protocols](/wallet-security/multisigs-for-protocols/overvi ### Communication Security **Email compromise prevention:** + - Address confirmation during video call prevents MITM - Live verbal verification catches discrepancies - Code phrases for authentication **Social engineering defense:** + - Never accept urgent bypass requests - Callback on known numbers to verify - Any request to skip verification triggers security review @@ -366,6 +388,7 @@ See the[Multisigs for Protocols](/wallet-security/multisigs-for-protocols/overvi ### Multi-Party Controls **Prevents single-actor fraud:** + - Multiple personnel - Video recording of approvals - Separation of duties: requester ≠ approver ≠ technical executor @@ -373,6 +396,7 @@ See the[Multisigs for Protocols](/wallet-security/multisigs-for-protocols/overvi ### Transaction Parameter Security **Custody platform policy engines:** + - Enforce withdrawal limits automatically - Block transactions to non-whitelisted addresses - Require elevated approvals above thresholds @@ -396,4 +420,3 @@ The cost of verification is measured in minutes. The cost of a mistake is measur - diff --git a/utils/fetched-tags.json b/utils/fetched-tags.json index 61982812..4cf4bb6d 100644 --- a/utils/fetched-tags.json +++ b/utils/fetched-tags.json @@ -922,7 +922,7 @@ "Engineer/Developer", "Security Specialist" ], - "/treasury-ops/transaction-verification": [ + "/treasury-operations/transaction-verification": [ "Treasury Ops", "Protocol", "Operations", From 57c5df525c6a2592327e79bb87e123c8f5b8088c Mon Sep 17 00:00:00 2001 From: Dickson Date: Sat, 4 Oct 2025 20:35:38 -0400 Subject: [PATCH 06/23] feat: add new section for Custodial Inventory & Controls in Treasury Operations - Introduced a new item in the Treasury Operations guide, linking to the Custodial Inventory & Controls documentation for enhanced resource accessibility. --- ...ication-registration-and-documentation.mdx | 493 ++++++++++++++++++ vocs.config.ts | 1 + 2 files changed, 494 insertions(+) create mode 100644 docs/pages/treasury-operations/classification-registration-and-documentation.mdx diff --git a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx new file mode 100644 index 00000000..8d644e2c --- /dev/null +++ b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx @@ -0,0 +1,493 @@ +# Custodial Treasury Security: Inventory & Controls Framework + +Proper documentation and classification of custodial accounts is essential for institutional treasury security. This guide covers the security assessment, classification, and control frameworks for crypto assets held with third-party custodians. + +## Classification Process + +Use this dual classification to determine appropriate security controls for each custodial account. + +### Step 1: Impact Assessment + +Evaluate the consequences if this account is compromised or unavailable. + +#### Financial Impact + +Calculate the total value at risk in this account: + +- Current market value of all assets held +- Include value of any active positions (e.g., staked assets, DeFi deposits) + +#### Operational Impact + +Assess the consequences if this account becomes unavailable: + +- What specific operations require this account? +- Do you have a secondary custody account that can handle these operations? +- What is the financial impact if unavailable for 7 days? + +#### Impact Classification + +| Level | Financial Exposure | Operational Dependency | +| ------------ | ------------------ | -------------------------------------------- | +| **Low** | \<$100K | No critical operations depend on it | +| **Medium** | $100K - $1M | Important but alternative funding available | +| **High** | $1M - $10M | Critical operations, limited alternatives | +| **Critical** | \>$10M | Business-critical, no alternatives for weeks | + +### Step 2: Operational Assessment + +Evaluate how frequently and urgently this account must be accessed. + +#### Transaction Frequency + +Document typical transaction patterns: + +- Transactions per month +- Typical transaction sizes +- Predictability of transaction timing + +#### Access Urgency + +Define response time requirements: + +- What is the maximum acceptable delay for routine transactions? +- Are there scenarios requiring same-day execution? +- What are the consequences of 24-hour, 72-hour, or 7-day delays? + +#### Coordination Requirements + +Assess how transactions are executed: + +- How many approvers are needed for typical transactions? +- Are transactions handled manually or through automated systems? +- Do approvers need to coordinate across timezones? + +Note: Single-approver configurations should only be used for low-value operational accounts (\<$10K) with additional compensating controls like strict spending limits and daily reconciliation. + +#### Operational Classification + +| Type | Frequency | Response Window | Example Use Cases | +| --------------------- | ------------- | --------------- | -------------------------------------------------- | +| **Cold Vault** | \<5 tx/month | 48-72 hours | Long-term reserves, infrequent rebalancing | +| **Warm Storage** | 5-50 tx/month | 4-24 hours | Scheduled payments, planned operations | +| **Active Operations** | \>50 tx/month | \<4 hours | Trading capital, frequent operational expenses | +| **Time-Critical** | Unpredictable | \<2 hours | Collateral management, market-sensitive operations | + +### Step 3: Security Control Matrix + +Combine impact and operational assessments to determine required controls. + +| Use Case | Impact | Operational | Approvers | MFA Requirement | Whitelist Delay | Additional Controls | +| ----------------------------- | ----------- | ------------- | --------- | ------------------ | --------------- | ------------------------------------------- | +| Primary Reserve (>$50M) | Critical | Cold Vault | 5-7 | Hardware mandatory | 72 hours | Geographic distribution | +| Secondary Reserve ($10M-$50M) | Critical | Cold Vault | 4-5 | Hardware mandatory | 48 hours | Geographic distribution | +| Active Treasury ($1M-$10M) | High | Warm Storage | 3-4 | Hardware mandatory | 24 hours | Daily reconciliation, velocity limits | +| Trading Capital | High | Active Ops | 3 | Hardware mandatory | None | Real-time monitoring, simulation required | +| DeFi Positions | Medium-High | Warm Storage | 3 | Hardware mandatory | 24 hours | Contract whitelist, position monitoring | +| Liquidation Protection | Medium-High | Time-Critical | 2 | Hardware required | None | Pre-approved destinations, automated alerts | +| Operational Wallet | Medium | Active Ops | 2 | Hardware required | 12 hours | Daily caps, weekly audit | +| Payments | Low | Active Ops | 2 | Standard TOTP | 6 hours | Per-tx cap, monthly aggregate limit | + +### Step 4: Enhanced Controls for High-Risk Accounts + +For Critical and High impact accounts, implement additional security layers beyond the baseline controls. + +#### Transaction Verification + +- Test transactions: Send maximum $100 to new addresses before executing full transaction +- Multi-channel confirmation: Request via one channel, approve via separate channel +- Simulation requirement: All transactions must be simulated before execution +- Address verification: Verify new addresses against three independent sources + +#### Access Security + +- Hardware security keys (FIDO2/WebAuthn) mandatory for all approvers +- IP whitelisting with 24-hour change approval delay +- Device fingerprinting with new device approval process +- Session timeout and re-authentication for sensitive operations +- Dedicated credentials: Use separate email addresses and passwords exclusively for custody access, not shared with other corporate systems + +#### Device Security + +- Dedicated secure workstations for custody access only +- Network isolation on separate VLAN/segment +- VPN mandatory for all platform access +- Full disk encryption with automatic screen lock +- MDM-enforced security baseline with remote wipe capability + +--- + +## Documentation Templates + +### Registration Template + +Use this template when initially documenting a custodial account. + +``` +CUSTODIAL ACCOUNT REGISTRATION + +Account Name: [Descriptive name] +Custodian: [Provider name and legal entity] +Account ID: [Custodian reference number] +Network(s): [Bitcoin, Ethereum, etc.] +Registration Date: YYYY-MM-DD +Registered By: [Name] + +CLASSIFICATION +Impact Level: [Low / Medium / High / Critical] +Operational Type: [Cold Vault / Warm Storage / Active Operations / Time-Critical] + +Justification: +- Financial exposure: $XXX,XXX,XXX +- Operational dependency: [Description] +- Recovery time objective: [X hours/days] + +ASSETS CONTROLLED +Asset | Network | Value | Purpose +--------|----------|-----------|------------------------------ +BTC | Bitcoin | $XXX,XXX | [Reserve/Trading/Operations] +ETH | Ethereum | $XXX,XXX | [Reserve/Trading/Operations] +USDC | Ethereum | $XXX,XXX | [Reserve/Trading/Operations] + +CUSTODY MODEL +Type: [Qualified Custodian / Co-managed / MPC Platform] +Key Management: [MPC 3-of-5 / Multi-sig 2-of-3 / HSM] +Key Control: [Custodian only / Co-managed / Client-controlled] +Recovery Capability: [Yes - describe / No] + +INITIAL ACCESS SETUP +Primary Administrator: [Name, added YYYY-MM-DD] +Initial Approvers: [Names, added YYYY-MM-DD] + +Note: Complete access details documented in Access Change Template +Note: Security configuration documented in Security Configuration Template + +ATTESTATION +This account [meets / deviates from] security standards for its classification. + +[If deviation: Explain gap and compensating controls] + +CONTACTS +Security Owner: [Name, email, phone] +Backup Contact: [Name, email, phone] +Custodian Support: [Name, email, phone] + +Last Updated: YYYY-MM-DD +Updated By: [Name] +``` + +--- + +### Access Change Template + +Use this template when modifying user access to a custodial account. + +``` +CUSTODIAL ACCOUNT ACCESS CHANGE + +Account Name: [Name] +Custodian: [Provider] +Account ID: [Reference] +Change Date: YYYY-MM-DD +Changed By: [Name] + +ACCESS MODIFICATIONS + +Additions: +Name/Role | Access Level | MFA Method | Justification +----------|--------------|----------------|------------------------------ +[Name] | [Approver] | [Hardware key] | [Reason for addition] + +Removals: +Name/Role | Access Level | Removal Reason +----------|--------------|------------------------------- +[Name] | [Approver] | [Personnel change / Security / Other] + +Permission Changes: +Name/Role | Old Level | New Level | Justification +----------|-----------|-----------|--------------------------- +[Name] | [Initiator] | [Approver] | [Reason for elevation] + +CURRENT ACCESS LIST (after changes) +Name/Role | Level | MFA Method | Device ID +----------|-----------|---------------|--------- +[Name] | Admin | Hardware key | [ID] +[Name] | Approver | Hardware key | [ID] +[Name] | Approver | Hardware key | [ID] +[Name] | Initiator | TOTP | [ID] + +VERIFICATION +[ ] All removed users confirmed deactivated in custodian platform +[ ] All new users completed MFA setup +[ ] Access permissions tested and verified +[ ] Emergency contacts updated +[ ] Documentation updated in [location] + +APPROVALS +Requested By: _________________ Date: _______ +Approved By: _________________ Date: _______ +Security Review: _________________ Date: _______ + +Change Ticket: [Reference number if applicable] +``` + +--- + +### Security Configuration Template + +Use this template to document detailed security settings. Complete this after initial account registration. + +``` +CUSTODIAL ACCOUNT SECURITY CONFIGURATION + +Account: [Name] +Custodian: [Provider] +Last Configuration Update: YYYY-MM-DD +Configured By: [Name] + +AUTHENTICATION SETTINGS + +Multi-Factor Authentication: +Role | Primary Method | Backup Method | Enrollment Status +Administrator | Hardware key + biometric | Hardware key + PIN | [Active] +Approver | Hardware key | TOTP + SMS | [Active] +Initiator | Hardware key or TOTP | SMS | [Active] +Viewer | TOTP | SMS | [Active] + +Session Controls: +- Timeout: [X minutes] +- Re-auth required for: [High-value transactions, policy changes, user management] +- Concurrent sessions: [Allowed/Blocked] + +ACCESS CONTROL + +Current User List: +Name/Role | Level | MFA Method | Device ID | Added Date +----------|----------|--------------|----------|------------ +[Name] | Admin | Hardware key | [ID] | YYYY-MM-DD +[Name] | Approver | Hardware key | [ID] | YYYY-MM-DD +[Name] | Approver | Hardware key | [ID] | YYYY-MM-DD + +Note: Track all access changes using Access Change Template + +Approval Thresholds: +Transaction Value | Required Approvers | Time Delay | Additional Requirements +<$10K | 1 | None | MFA only +$10K - $100K | 2 | 4 hours | MFA +$100K - $1M | 3 | 24 hours | Test transaction +>$1M | 4 | 48 hours | Multi-channel confirmation, test tx + +Separation of Duties: +[ ] Initiators cannot approve own transactions +[ ] Admins cannot unilaterally execute withdrawals +[ ] Minimum [X] unique approvers required + +NETWORK RESTRICTIONS + +IP Whitelist: +XXX.XXX.XXX.XXX - [Office Location] +XXX.XXX.XXX.XXX - [VPN Range] +XXX.XXX.XXX.XXX - [Backup Location] + +Change Approval: [24 hour delay / XX approvers required] +Emergency Override: [Process description] + +VPN Requirement: [Mandatory / Optional] +Geographic Restrictions: [Blocked countries/regions] +Device Fingerprinting: [Enabled / Disabled] + +TRANSACTION POLICIES + +Address Whitelisting: +Status: [Enabled / Disabled] +Current Addresses: [XX addresses] +Addition Process: [XX approvers, YY hour delay] +Review Schedule: [Monthly / Quarterly] + +Transaction Limits: +Limit Type | Amount | Override Process +------------------|----------|----------------- +Single Transaction | $XXX,XXX | [Authorization required] +Hourly Aggregate | $XXX,XXX | [Authorization required] +Daily Aggregate | $XXX,XXX | [Authorization required] +Weekly Aggregate | $XXX,XXX | [Authorization required] +Monthly Aggregate | $XXX,XXX | [Authorization required] + +Time-Lock Settings: +Change Type | Delay Period +-------------------------------------|------------- +New address addition | XX hours +Policy modification | XX hours +High-value transaction (>$XXX,XXX) | XX hours + +MONITORING & ALERTS + +Real-Time Alerts: +Type | Enabled +---------------------------|-------- +All outgoing transactions | [ ] +New device login | [ ] +Failed authentication attempts (>X) | [ ] +Policy violations | [ ] +Large transactions (>$XXX,XXX) | [ ] +Unusual access times | [ ] +New geographic location | [ ] + +Alert Routing: +Severity | Contact | Method | Response Time +---------|------------------|-------------|-------------- +Critical | [Name, phone] | SMS + Call | <15 min +High | [Name, phone] | SMS + Email | <1 hour +Medium | [Name, email] | Email | <4 hours + +VERIFICATION +[ ] All settings tested and operational +[ ] Alert routing verified +[ ] User access confirmed +[ ] Documentation stored in [location] + +Configured By: _________________ Date: _______ +Reviewed By: _________________ Date: _______ +Approved By: _________________ Date: _______ +``` + +--- + +### Quarterly Review Template + +Use this template for regular security reviews of custodial accounts. + +``` +CUSTODIAL ACCOUNT QUARTERLY REVIEW + +Account: [Name] +Custodian: [Provider] +Review Period: [Q1/Q2/Q3/Q4 YYYY] +Review Date: YYYY-MM-DD +Reviewed By: [Name] + +ACCESS AUDIT + +Current Users: +Name/Role | Level | Last Login | MFA Status | Action Required +[Name] | Admin | YYYY-MM-DD | Active | None +[Name] | Approver | YYYY-MM-DD | Active | None +[Name] | Approver | Never logged in | Inactive | Remove access + +Access Changes This Quarter: [X additions, Y removals, Z modifications] + +Findings: +[ ] All users still require current access level +[ ] No dormant accounts (>90 days inactive) +[ ] MFA functioning for all users +[ ] No unauthorized access detected + +Actions Required: +- [List any access to be removed/modified] +- [List any policy updates needed] + +TRANSACTION REVIEW + +Transaction Volume: +- Total transactions: [X] +- Average per month: [Y] +- Largest transaction: $XXX,XXX +- Total outflow: $XXX,XXX + +Pattern Analysis: +[ ] Transactions within expected parameters +[ ] No unusual transaction patterns detected +[ ] All large transactions properly authorized +[ ] Test transactions performed correctly + +Anomalies Detected: +- [List any unusual activity or violations] + +SECURITY CONFIGURATION + +Whitelist Review: +- Current addresses: [X] +- Addresses added this quarter: [Y] +- Addresses to remove: [Z] +- Review complete: [Yes/No] + +Spending Limits: +Current | Actual Usage | Status +Single: $XXX,XXX | Max: $XXX,XXX | [Appropriate / Adjust] +Daily: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust] +Monthly: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust] + +Findings: +[ ] Limits appropriate for current usage +[ ] No limit breaches this quarter +[ ] IP whitelist current and accurate +[ ] Time-locks functioning properly + +ALERT EFFECTIVENESS + +Alerts This Quarter: +Type | Count | False Positive Rate +Critical | [X] | [Y%] +High | [X] | [Y%] +Medium | [X] | [Y%] + +Response Times: +Severity | Target | Actual Average | Status +Critical | <15 min | [X min] | [Met/Missed] +High | <1 hour | [X min] | [Met/Missed] +Medium | <4 hours | [X hours] | [Met/Missed] + +Findings: +[ ] Alert routing working correctly +[ ] Response times meeting SLAs +[ ] No missed critical alerts + +Actions Required: +- [Adjust alert thresholds if needed] +- [Update contact information] + +CUSTODIAN RELATIONSHIP + +SOC Reports: [Current / Expired - date] +Security Incidents: [Any custodian-wide incidents this quarter] +Service Quality: [Any issues or concerns] +Communication: [Regular contact maintained] + +RISK ASSESSMENT UPDATE + +Classification Review: +Current: [Impact Level / Operational Type] +Still Appropriate: [Yes / No] + +If No, Recommended Change: +New Classification: [Level / Type] +Justification: [Explain change in risk profile] + +Asset Value Change: [% increase/decrease] +Operational Change: [Any significant changes in usage] + +RECOMMENDATIONS + +Security Improvements: +1. [Recommendation] +2. [Recommendation] +3. [Recommendation] + +Operational Improvements: +1. [Recommendation] +2. [Recommendation] + +ATTESTATION + +This account [continues to meet / deviates from] security standards. + +[If deviation: Describe and provide remediation plan] + +APPROVALS + +Reviewer: _________________ Date: _______ +Security Officer: _________________ Date: _______ +Treasury Lead: _________________ Date: _______ + +Next Review Due: YYYY-MM-DD +``` diff --git a/vocs.config.ts b/vocs.config.ts index fa0075c1..ff7191da 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -364,6 +364,7 @@ const config = { dev: true, items: [ { text: 'Guide: Large Cryptocurrency Transfers', link: '/treasury-operations/transaction-verification', dev: true }, + { text: 'Custodial Inventory & Controls', link: '/treasury-operations/classification-registration-and-documentation', dev: true }, ] }, ] From c7c794d98acb1186d6b63693a34d8dfa3ea295bd Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 6 Oct 2025 21:01:15 -0400 Subject: [PATCH 07/23] fix: update Ethereum confirmation requirements in transaction verification documentation - Changed the confirmation requirement for Ethereum from 12 confirmations (~2.5 minutes) to 2 epochs (~12.8 minutes) for improved accuracy. --- docs/pages/treasury-operations/transaction-verification.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/treasury-operations/transaction-verification.mdx b/docs/pages/treasury-operations/transaction-verification.mdx index 11742524..61da993f 100644 --- a/docs/pages/treasury-operations/transaction-verification.mdx +++ b/docs/pages/treasury-operations/transaction-verification.mdx @@ -188,7 +188,7 @@ Wait for enough confirmations that a chain reorganization becomes economically i **Confirmation requirements by chain:** -- **Ethereum**: 12 confirmations (~2.5 minutes) +- **Ethereum**: 2 epochs (~12.8 minutes) - **Bitcoin**: 6 confirmations (~60 minutes) - **Polygon**: 128 confirmations (~5 minutes) - **Solana**: ~12.8 seconds From 0132e5d48793b7d6457436663ae600dae0382324 Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 6 Oct 2025 21:26:26 -0400 Subject: [PATCH 08/23] refactor: enhance Treasury Operations documentation with impact assessments and operational classifications - Added sections on financial, operational, and regulatory impacts for account unavailability. - Updated impact classification table to include regulatory considerations and adjusted financial exposure metrics. - Revised operational assessment notes to reflect changes in account value thresholds and approval requirements for transactions. --- ...ication-registration-and-documentation.mdx | 45 ++++++++++++------- 1 file changed, 29 insertions(+), 16 deletions(-) diff --git a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx index 8d644e2c..48f7f150 100644 --- a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx +++ b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx @@ -16,6 +16,7 @@ Calculate the total value at risk in this account: - Current market value of all assets held - Include value of any active positions (e.g., staked assets, DeFi deposits) +- What is the financial impact if unavailable for 7 days? #### Operational Impact @@ -23,16 +24,24 @@ Assess the consequences if this account becomes unavailable: - What specific operations require this account? - Do you have a secondary custody account that can handle these operations? -- What is the financial impact if unavailable for 7 days? +- What is the reputational impact if this account is compromised or unavailable? + +#### Regulatory Impact + +Evaluate regulatory and compliance consequences: + +- Are assets in this account subject to regulatory reporting requirements (SEC filings, audit requirements)? +- Does this account hold regulated assets (e.g., stablecoins subject to reserves reporting)? +- What are the regulatory deadlines that could be missed if this account is unavailable? #### Impact Classification -| Level | Financial Exposure | Operational Dependency | -| ------------ | ------------------ | -------------------------------------------- | -| **Low** | \<$100K | No critical operations depend on it | -| **Medium** | $100K - $1M | Important but alternative funding available | -| **High** | $1M - $10M | Critical operations, limited alternatives | -| **Critical** | \>$10M | Business-critical, no alternatives for weeks | +| Level | Financial Exposure (% of Total Assets) | Operational Dependency | Regulatory Impact | +| ------------ | -------------------------------------- | -------------------------------------------- | ---------------------------------------------------- | +| **Low** | \<1% | No critical operations depend on it | No regulatory reporting tied to this account | +| **Medium** | 1% - 10% | Important but alternative funding available | Periodic reporting; delays manageable | +| **High** | 10% - 25% | Critical operations, limited alternatives | Regular regulatory filings; delays cause violations | +| **Critical** | \>25% | Business-critical, no alternatives for weeks | Real-time reporting requirements; SEC filings; audit | ### Step 2: Operational Assessment @@ -62,7 +71,7 @@ Assess how transactions are executed: - Are transactions handled manually or through automated systems? - Do approvers need to coordinate across timezones? -Note: Single-approver configurations should only be used for low-value operational accounts (\<$10K) with additional compensating controls like strict spending limits and daily reconciliation. +Note: Single-approver configurations should only be used for low-value operational accounts (\<0.1%) with additional compensating controls like strict spending limits and daily reconciliation. #### Operational Classification @@ -79,9 +88,10 @@ Combine impact and operational assessments to determine required controls. | Use Case | Impact | Operational | Approvers | MFA Requirement | Whitelist Delay | Additional Controls | | ----------------------------- | ----------- | ------------- | --------- | ------------------ | --------------- | ------------------------------------------- | -| Primary Reserve (>$50M) | Critical | Cold Vault | 5-7 | Hardware mandatory | 72 hours | Geographic distribution | -| Secondary Reserve ($10M-$50M) | Critical | Cold Vault | 4-5 | Hardware mandatory | 48 hours | Geographic distribution | -| Active Treasury ($1M-$10M) | High | Warm Storage | 3-4 | Hardware mandatory | 24 hours | Daily reconciliation, velocity limits | +| Primary Reserve (>25% assets) | Critical | Cold Vault | 5-7 | Hardware mandatory | 72 hours | Geographic distribution, MPC recommended | +| Secondary Reserve (10-25%) | Critical | Cold Vault | 4-5 | Hardware mandatory | 48 hours | Geographic distribution, MPC recommended | +| Active Treasury (5-10%) | High | Warm Storage | 3-4 | Hardware mandatory | 24 hours | Daily reconciliation, velocity limits | +| Trading Capital (variable) | High | Active Ops | 3 | Hardware mandatory | None | Real-time monitoring, simulation required | | Trading Capital | High | Active Ops | 3 | Hardware mandatory | None | Real-time monitoring, simulation required | | DeFi Positions | Medium-High | Warm Storage | 3 | Hardware mandatory | 24 hours | Contract whitelist, position monitoring | | Liquidation Protection | Medium-High | Time-Critical | 2 | Hardware required | None | Pre-approved destinations, automated alerts | @@ -102,6 +112,8 @@ For Critical and High impact accounts, implement additional security layers beyo #### Access Security - Hardware security keys (FIDO2/WebAuthn) mandatory for all approvers + - Secure fallback: Each approver must register minimum 2 hardware keys stored in separate secure locations + - Key loss procedure: Temporary access via backup key + additional approver verification via multiple channels + mandatory key replacement within 48 hours - IP whitelisting with 24-hour change approval delay - Device fingerprinting with new device approval process - Session timeout and re-authentication for sensitive operations @@ -271,11 +283,12 @@ Name/Role | Level | MFA Method | Device ID | Added Date Note: Track all access changes using Access Change Template Approval Thresholds: -Transaction Value | Required Approvers | Time Delay | Additional Requirements -<$10K | 1 | None | MFA only -$10K - $100K | 2 | 4 hours | MFA -$100K - $1M | 3 | 24 hours | Test transaction ->$1M | 4 | 48 hours | Multi-channel confirmation, test tx +Transaction Value (% of Total Assets) | Required Approvers | Time Delay | Additional Requirements +<0.1% | 1 | None | MFA +0.1% - 1% | 3 | 4 hours | MFA +1% - 10% | 4 | 24 hours | Multi-channel confirmation, test transaction +10% - 25% | 5 | 24 hours | Multi-channel confirmation, test transaction +>25% | 7 | 48 hours | Multi-channel confirmation, test transaction Separation of Duties: [ ] Initiators cannot approve own transactions From be78f1faf8612de5104a83bb36b96a88d0b1a242 Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 6 Oct 2025 21:38:46 -0400 Subject: [PATCH 09/23] chore: add spacing for improved readability in Treasury Operations documentation - Added extra line breaks in the classification registration and documentation section to enhance visual clarity and separation of content. --- .../classification-registration-and-documentation.mdx | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx index 48f7f150..7e5394ac 100644 --- a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx +++ b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx @@ -127,6 +127,16 @@ For Critical and High impact accounts, implement additional security layers beyo - Full disk encryption with automatic screen lock - MDM-enforced security baseline with remote wipe capability +#### MPC for Large Holdings + +For organizations managing >10% of total assets or >$10M equivalent in a single custodial account consider using MPC: + +- Evaluate MPC (Multi-Party Computation) custody solutions that distribute key material across multiple parties +- Consider threshold signature schemes (e.g., 3-of-5 or 5-of-9) where no single party controls sufficient key shares +- Implement geographic distribution of key share holders across multiple jurisdictions +- Establish clear key refresh and rotation procedures +- Document recovery procedures and test annually + --- ## Documentation Templates From c5eff14c4876f374ad2f282a0933de24555f7db8 Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 6 Oct 2025 21:53:46 -0400 Subject: [PATCH 10/23] feat: expand Treasury Operations documentation with Zero Trust Architecture and security monitoring guidelines - Added a new section on Zero Trust Architecture alternatives, detailing bastion host and cloud workspace isolation approaches for enhanced security. - Introduced security monitoring and logging recommendations for organizations managing critical accounts, emphasizing the use of SIEM and audit logs for effective oversight. --- ...ication-registration-and-documentation.mdx | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx index 7e5394ac..ebef6d09 100644 --- a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx +++ b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx @@ -137,6 +137,36 @@ For organizations managing >10% of total assets or >$10M equivalent in a single - Establish clear key refresh and rotation procedures - Document recovery procedures and test annually +#### Zero Trust Architecture Alternative + +A zero trust architecture can be implemented by centralizing all access through a single, highly secure environment (such as a bastion host or isolated cloud workspace), rather than relying on individual endpoint security. + +- **Bastion Host Approach:** Deploy hardened jump server that acts as sole gateway to custody platforms + - All custody sessions route through bastion with full session recording + - Bastion enforces MFA, device posture checks, and approved software versions + - No direct custody access from employee devices + - Centralized patch management and security configuration + +- **Cloud Workspace Isolation:** Use browser-isolated environments (Citrix, AWS WorkSpaces, Azure Virtual Desktop) + - Custody access occurs only within controlled virtual environment + - Copy/paste and download restrictions prevent data exfiltration + - Session timeout and automatic workspace destruction after use + - Eliminates risk from compromised employee devices + +#### Security Monitoring & Logging + +#### Security Monitoring & Logging + +For Critical and High impact accounts, implement centralized security monitoring: + +- **SIEM Deployment:** Deploy SIEM to centralize logs from custody platforms, authentication systems, and access devices. Create real-time correlation rules for suspicious patterns (failed authentication, geographic anomalies, policy changes). + +- **Internal Incident Response:** Build dedicated incident response capability for custody-related security events. Define clear escalation procedures, maintain 24/7 on-call rotation for Critical accounts, and establish playbooks for custody compromise scenarios. + +- **Essential Log Sources:** Authentication events, transaction attempts, policy modifications, access changes, whitelist updates, IP address changes, new device enrollments, and approval workflows. + +For Medium and Low impact accounts, leverage custodian's native audit logs with weekly manual review and automated alerting for critical events (new device enrollment, policy changes, transactions above threshold). + --- ## Documentation Templates From 5ab34a0dce0561fa2f00c52b361fe5c1139c3818 Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 6 Oct 2025 21:54:48 -0400 Subject: [PATCH 11/23] refactor: streamline security monitoring section in Treasury Operations documentation - Removed redundant header for the Security Monitoring & Logging section to improve clarity and flow. - Maintained focus on centralized security monitoring recommendations for critical and high impact accounts. --- .../classification-registration-and-documentation.mdx | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx index ebef6d09..d9d10c53 100644 --- a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx +++ b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx @@ -155,8 +155,6 @@ A zero trust architecture can be implemented by centralizing all access through #### Security Monitoring & Logging -#### Security Monitoring & Logging - For Critical and High impact accounts, implement centralized security monitoring: - **SIEM Deployment:** Deploy SIEM to centralize logs from custody platforms, authentication systems, and access devices. Create real-time correlation rules for suspicious patterns (failed authentication, geographic anomalies, policy changes). From 9454b44ca7c830028e45cb8965b8dad3099ed8cf Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 6 Oct 2025 21:56:34 -0400 Subject: [PATCH 12/23] feat: add DeFi Risk Assessment reference to Treasury Operations documentation - Included a link to the DeFi Risk Assessment Guide for recommended procedures related to DeFi interactions. - Enhanced the documentation to provide clearer guidance for security measures in decentralized finance contexts. --- .../classification-registration-and-documentation.mdx | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx index d9d10c53..7505ede9 100644 --- a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx +++ b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx @@ -109,6 +109,9 @@ For Critical and High impact accounts, implement additional security layers beyo - Simulation requirement: All transactions must be simulated before execution - Address verification: Verify new addresses against three independent sources +For DeFi interactions: refer to the [DeFi Risk Assessment Guide](https://entethalliance.org/specs/defi-risks/v1/) for recommended procedures. + + #### Access Security - Hardware security keys (FIDO2/WebAuthn) mandatory for all approvers From 6125fc2d0ca3910d598f47d59d016a77063cae4a Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 6 Oct 2025 21:59:11 -0400 Subject: [PATCH 13/23] feat: introduce Custodial Treasury Security framework in documentation - Added a new section titled "Custodial Treasury Security: Inventory & Controls Framework" to enhance guidance on custodial account management. - Included tags and contributor information for better resource categorization and attribution. - Integrated components for improved documentation structure and user engagement. --- ...ication-registration-and-documentation.mdx | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx index 7505ede9..ec46ddfc 100644 --- a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx +++ b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx @@ -1,5 +1,32 @@ +--- +title: "Custodial Treasury Security: Inventory & Controls Framework" +tags: + - Treasury Ops + - Operations + - Risk Management +contributors: + - role: wrote + users: [dickson] + - role: reviewed + users: [relotnek] +--- + +import { + TagList, + AttributionList, + TagProvider, + TagFilter, + ContributeFooter, +} from "../../../components"; + + + + # Custodial Treasury Security: Inventory & Controls Framework + + + Proper documentation and classification of custodial accounts is essential for institutional treasury security. This guide covers the security assessment, classification, and control frameworks for crypto assets held with third-party custodians. ## Classification Process @@ -545,3 +572,8 @@ Treasury Lead: _________________ Date: _______ Next Review Due: YYYY-MM-DD ``` + +--- + + + From fa17eb0cd1ff0d6e195d5853f9237f0a80003825 Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 6 Oct 2025 22:44:05 -0400 Subject: [PATCH 14/23] refactor: update Zero Trust Architecture section in Treasury Operations documentation - Revised the description of Zero Trust architecture to emphasize continuous verification of users, devices, and context. - Enhanced clarity in the bastion host and cloud workspace isolation approaches, including specific security measures and risk reduction strategies. - Improved overall readability and consistency in the documentation. --- ...classification-registration-and-documentation.mdx | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx index ec46ddfc..6b5ef7e7 100644 --- a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx +++ b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx @@ -169,19 +169,19 @@ For organizations managing >10% of total assets or >$10M equivalent in a single #### Zero Trust Architecture Alternative -A zero trust architecture can be implemented by centralizing all access through a single, highly secure environment (such as a bastion host or isolated cloud workspace), rather than relying on individual endpoint security. +A Zero Trust architecture involves continuous verification of user, device, and context, rather than reliance on a single perimeter or network location. Centralizing access through a secure environment (such as a bastion host or isolated cloud workspace) can support Zero Trust principles when combined with strong identity and device posture enforcement. -- **Bastion Host Approach:** Deploy hardened jump server that acts as sole gateway to custody platforms - - All custody sessions route through bastion with full session recording +- **Bastion Host Approach:** Deploy a hardened jump server that acts as the sole gateway to custody platforms. + - All custody sessions route through the bastion with full session recording - Bastion enforces MFA, device posture checks, and approved software versions - No direct custody access from employee devices - Centralized patch management and security configuration -- **Cloud Workspace Isolation:** Use browser-isolated environments (Citrix, AWS WorkSpaces, Azure Virtual Desktop) - - Custody access occurs only within controlled virtual environment +- **Cloud Workspace Isolation:** Use browser-isolated or virtual workspace environments (e.g., Citrix, AWS WorkSpaces, Azure Virtual Desktop) + - Custody access occurs only within a controlled virtual environment - Copy/paste and download restrictions prevent data exfiltration - Session timeout and automatic workspace destruction after use - - Eliminates risk from compromised employee devices + - Significantly reduces risk from compromised employee devices #### Security Monitoring & Logging From 9b6168119957d2baec63daeec856306bcd09dad0 Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 6 Oct 2025 22:45:38 -0400 Subject: [PATCH 15/23] feat: update Treasury Operations documentation with guide link and contributor details - Reintroduced the "Guide: Large Cryptocurrency Transfers" link in the Treasury Operations configuration for better resource accessibility. - Added a new contributor role for review in the transaction verification documentation to enhance attribution. - Updated fetched-tags.json to include relevant tags for the custodial inventory and transaction verification sections. --- docs/pages/treasury-operations/transaction-verification.mdx | 2 ++ utils/fetched-tags.json | 5 +++++ vocs.config.ts | 2 +- 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/pages/treasury-operations/transaction-verification.mdx b/docs/pages/treasury-operations/transaction-verification.mdx index 61da993f..ea2041e0 100644 --- a/docs/pages/treasury-operations/transaction-verification.mdx +++ b/docs/pages/treasury-operations/transaction-verification.mdx @@ -9,6 +9,8 @@ tags: contributors: - role: wrote users: [dickson] + - role: reviewed + users: [relotnek] --- import { diff --git a/utils/fetched-tags.json b/utils/fetched-tags.json index 4cf4bb6d..8d59b46c 100644 --- a/utils/fetched-tags.json +++ b/utils/fetched-tags.json @@ -922,6 +922,11 @@ "Engineer/Developer", "Security Specialist" ], + "/treasury-operations/classification-registration-and-documentation": [ + "Treasury Ops", + "Operations", + "Risk Management" + ], "/treasury-operations/transaction-verification": [ "Treasury Ops", "Protocol", diff --git a/vocs.config.ts b/vocs.config.ts index ff7191da..fed78d29 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -363,8 +363,8 @@ const config = { collapsed: false, dev: true, items: [ - { text: 'Guide: Large Cryptocurrency Transfers', link: '/treasury-operations/transaction-verification', dev: true }, { text: 'Custodial Inventory & Controls', link: '/treasury-operations/classification-registration-and-documentation', dev: true }, + { text: 'Guide: Large Cryptocurrency Transfers', link: '/treasury-operations/transaction-verification', dev: true }, ] }, ] From 62a2a199de5418676bb4798d70fa8718bda0cfa1 Mon Sep 17 00:00:00 2001 From: Dickson Date: Tue, 7 Oct 2025 17:19:12 -0400 Subject: [PATCH 16/23] feat: enhance Treasury Operations documentation with detailed controls for account classifications - Updated the impact and operational classification table to include comprehensive controls for each account type, emphasizing security measures and specific requirements. - Added detailed descriptions for low, medium, and high-risk accounts, including transaction limits, monitoring, and approval processes. - Revised device security and access protocols to strengthen custody access and ensure compliance with best practices. --- docs/pages/config/contributors.json | 12 +++++++++ ...ication-registration-and-documentation.mdx | 26 +++++++++---------- 2 files changed, 25 insertions(+), 13 deletions(-) diff --git a/docs/pages/config/contributors.json b/docs/pages/config/contributors.json index 30c93303..e08dc3d7 100644 --- a/docs/pages/config/contributors.json +++ b/docs/pages/config/contributors.json @@ -190,5 +190,17 @@ "company": "SEAL", "job_title": "Frameworks Contributors", "description": "Frameworks Contributors" + }, + "bsamuels453": { + "slug": "bsamuels453", + "name": "Ben S", + "role": "contributor", + "avatar": "https://avatars.githubusercontent.com/bsamuels453", + "github": "https://github.com/bsamuels453", + "twitter": "https://x.com/thebensams", + "website": "https://bsamuels.net/", + "company": "Trail of Bits", + "job_title": "Director of Engineering for Blockchain", + "description": "Frameworks Contributors" } } \ No newline at end of file diff --git a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx index 6b5ef7e7..1101f57c 100644 --- a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx +++ b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx @@ -8,7 +8,7 @@ contributors: - role: wrote users: [dickson] - role: reviewed - users: [relotnek] + users: [relotnek, bsamuels453] --- import { @@ -115,15 +115,14 @@ Combine impact and operational assessments to determine required controls. | Use Case | Impact | Operational | Approvers | MFA Requirement | Whitelist Delay | Additional Controls | | ----------------------------- | ----------- | ------------- | --------- | ------------------ | --------------- | ------------------------------------------- | -| Primary Reserve (>25% assets) | Critical | Cold Vault | 5-7 | Hardware mandatory | 72 hours | Geographic distribution, MPC recommended | -| Secondary Reserve (10-25%) | Critical | Cold Vault | 4-5 | Hardware mandatory | 48 hours | Geographic distribution, MPC recommended | -| Active Treasury (5-10%) | High | Warm Storage | 3-4 | Hardware mandatory | 24 hours | Daily reconciliation, velocity limits | -| Trading Capital (variable) | High | Active Ops | 3 | Hardware mandatory | None | Real-time monitoring, simulation required | -| Trading Capital | High | Active Ops | 3 | Hardware mandatory | None | Real-time monitoring, simulation required | -| DeFi Positions | Medium-High | Warm Storage | 3 | Hardware mandatory | 24 hours | Contract whitelist, position monitoring | -| Liquidation Protection | Medium-High | Time-Critical | 2 | Hardware required | None | Pre-approved destinations, automated alerts | -| Operational Wallet | Medium | Active Ops | 2 | Hardware required | 12 hours | Daily caps, weekly audit | -| Payments | Low | Active Ops | 2 | Standard TOTP | 6 hours | Per-tx cap, monthly aggregate limit | +| Payments | Low | Active Ops | 2 | Standard TOTP | 6 hours | **Baseline (all accounts):** Dedicated devices for custody access, address whitelisting enabled, test small amount to new addresses before full transaction, transaction simulation. **Low-specific:** Per-transaction cap, monthly aggregate limit | +| Operational Wallet | Medium | Active Ops | 2 | Hardware required | 12 hours | All Low controls + daily transaction caps, weekly reconciliation, monthly audit | +| Liquidation Protection | Medium-High | Time-Critical | 2 | Hardware required | None | All Low/Medium controls + automated alerts for position health, real-time monitoring | +| DeFi Positions | Medium-High | Warm Storage | 3 | Hardware mandatory | 24 hours | All Low/Medium controls + smart contract whitelist, position monitoring, daily reconciliation | +| Trading Capital (variable) | High | Active Ops | 3 | Hardware mandatory | 6 hours | All Low/Medium controls + smart contract whitelist, real-time monitoring, daily reconciliation | +| Active Treasury (5-10%) | High | Warm Storage | 3-4 | Hardware mandatory | 24 hours | All Low/Medium controls + transaction velocity limits, SIEM monitoring， multi-channel confirmation | +| Secondary Reserve (10-25%) | Critical | Cold Vault | 4-5 | Hardware mandatory | 48 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended | +| Primary Reserve (>25% assets) | Critical | Cold Vault | 5-7 | Hardware mandatory | 72 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended | ### Step 4: Enhanced Controls for High-Risk Accounts @@ -144,18 +143,19 @@ For DeFi interactions: refer to the [DeFi Risk Assessment Guide](https://entetha - Hardware security keys (FIDO2/WebAuthn) mandatory for all approvers - Secure fallback: Each approver must register minimum 2 hardware keys stored in separate secure locations - Key loss procedure: Temporary access via backup key + additional approver verification via multiple channels + mandatory key replacement within 48 hours -- IP whitelisting with 24-hour change approval delay +- IP whitelisting with 24-hour change approval delay - if treasury software supports application-level IP whitelisting, restrict to VPN IP range only - Device fingerprinting with new device approval process - Session timeout and re-authentication for sensitive operations - Dedicated credentials: Use separate email addresses and passwords exclusively for custody access, not shared with other corporate systems #### Device Security -- Dedicated secure workstations for custody access only +- Dedicated secure workstations and mobile devices for custody access only (no general browsing, email, or other corporate activities) - Network isolation on separate VLAN/segment -- VPN mandatory for all platform access +- VPN mandatory for all platform access; if treasury platform supports it, configure IP whitelisting to only allow access from VPN IP addresses - Full disk encryption with automatic screen lock - MDM-enforced security baseline with remote wipe capability +- Mobile endpoint security monitoring (e.g., iVerify) for devices used as second factors or keystores, without requiring full MDM admin control #### MPC for Large Holdings From 862013fdb663c7715fb523da2045622f97c50f3a Mon Sep 17 00:00:00 2001 From: Dickson Date: Thu, 16 Oct 2025 23:28:20 -0400 Subject: [PATCH 17/23] feat: update Treasury Operations configuration and documentation - Modified the link for "Custodial Inventory & Controls" to point to the new classification page. - Added new entries for "Registration Documents" and "Enhanced Controls for High-Risk Accounts" in the Treasury Operations configuration. - Deleted the outdated "Custodial Treasury Security: Inventory & Controls Framework" documentation to streamline resources and improve clarity. --- ...ication-registration-and-documentation.mdx | 579 ------------------ .../treasury-operations/classification.mdx | 142 +++++ .../treasury-operations/enhanced-controls.mdx | 110 ++++ .../registration-documents.mdx | 415 +++++++++++++ vocs.config.ts | 4 +- 5 files changed, 670 insertions(+), 580 deletions(-) delete mode 100644 docs/pages/treasury-operations/classification-registration-and-documentation.mdx create mode 100644 docs/pages/treasury-operations/classification.mdx create mode 100644 docs/pages/treasury-operations/enhanced-controls.mdx create mode 100644 docs/pages/treasury-operations/registration-documents.mdx diff --git a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx b/docs/pages/treasury-operations/classification-registration-and-documentation.mdx deleted file mode 100644 index 1101f57c..00000000 --- a/docs/pages/treasury-operations/classification-registration-and-documentation.mdx +++ /dev/null @@ -1,579 +0,0 @@ ---- -title: "Custodial Treasury Security: Inventory & Controls Framework" -tags: - - Treasury Ops - - Operations - - Risk Management -contributors: - - role: wrote - users: [dickson] - - role: reviewed - users: [relotnek, bsamuels453] ---- - -import { - TagList, - AttributionList, - TagProvider, - TagFilter, - ContributeFooter, -} from "../../../components"; - - - - -# Custodial Treasury Security: Inventory & Controls Framework - - - - -Proper documentation and classification of custodial accounts is essential for institutional treasury security. This guide covers the security assessment, classification, and control frameworks for crypto assets held with third-party custodians. - -## Classification Process - -Use this dual classification to determine appropriate security controls for each custodial account. - -### Step 1: Impact Assessment - -Evaluate the consequences if this account is compromised or unavailable. - -#### Financial Impact - -Calculate the total value at risk in this account: - -- Current market value of all assets held -- Include value of any active positions (e.g., staked assets, DeFi deposits) -- What is the financial impact if unavailable for 7 days? - -#### Operational Impact - -Assess the consequences if this account becomes unavailable: - -- What specific operations require this account? -- Do you have a secondary custody account that can handle these operations? -- What is the reputational impact if this account is compromised or unavailable? - -#### Regulatory Impact - -Evaluate regulatory and compliance consequences: - -- Are assets in this account subject to regulatory reporting requirements (SEC filings, audit requirements)? -- Does this account hold regulated assets (e.g., stablecoins subject to reserves reporting)? -- What are the regulatory deadlines that could be missed if this account is unavailable? - -#### Impact Classification - -| Level | Financial Exposure (% of Total Assets) | Operational Dependency | Regulatory Impact | -| ------------ | -------------------------------------- | -------------------------------------------- | ---------------------------------------------------- | -| **Low** | \<1% | No critical operations depend on it | No regulatory reporting tied to this account | -| **Medium** | 1% - 10% | Important but alternative funding available | Periodic reporting; delays manageable | -| **High** | 10% - 25% | Critical operations, limited alternatives | Regular regulatory filings; delays cause violations | -| **Critical** | \>25% | Business-critical, no alternatives for weeks | Real-time reporting requirements; SEC filings; audit | - -### Step 2: Operational Assessment - -Evaluate how frequently and urgently this account must be accessed. - -#### Transaction Frequency - -Document typical transaction patterns: - -- Transactions per month -- Typical transaction sizes -- Predictability of transaction timing - -#### Access Urgency - -Define response time requirements: - -- What is the maximum acceptable delay for routine transactions? -- Are there scenarios requiring same-day execution? -- What are the consequences of 24-hour, 72-hour, or 7-day delays? - -#### Coordination Requirements - -Assess how transactions are executed: - -- How many approvers are needed for typical transactions? -- Are transactions handled manually or through automated systems? -- Do approvers need to coordinate across timezones? - -Note: Single-approver configurations should only be used for low-value operational accounts (\<0.1%) with additional compensating controls like strict spending limits and daily reconciliation. - -#### Operational Classification - -| Type | Frequency | Response Window | Example Use Cases | -| --------------------- | ------------- | --------------- | -------------------------------------------------- | -| **Cold Vault** | \<5 tx/month | 48-72 hours | Long-term reserves, infrequent rebalancing | -| **Warm Storage** | 5-50 tx/month | 4-24 hours | Scheduled payments, planned operations | -| **Active Operations** | \>50 tx/month | \<4 hours | Trading capital, frequent operational expenses | -| **Time-Critical** | Unpredictable | \<2 hours | Collateral management, market-sensitive operations | - -### Step 3: Security Control Matrix - -Combine impact and operational assessments to determine required controls. - -| Use Case | Impact | Operational | Approvers | MFA Requirement | Whitelist Delay | Additional Controls | -| ----------------------------- | ----------- | ------------- | --------- | ------------------ | --------------- | ------------------------------------------- | -| Payments | Low | Active Ops | 2 | Standard TOTP | 6 hours | **Baseline (all accounts):** Dedicated devices for custody access, address whitelisting enabled, test small amount to new addresses before full transaction, transaction simulation. **Low-specific:** Per-transaction cap, monthly aggregate limit | -| Operational Wallet | Medium | Active Ops | 2 | Hardware required | 12 hours | All Low controls + daily transaction caps, weekly reconciliation, monthly audit | -| Liquidation Protection | Medium-High | Time-Critical | 2 | Hardware required | None | All Low/Medium controls + automated alerts for position health, real-time monitoring | -| DeFi Positions | Medium-High | Warm Storage | 3 | Hardware mandatory | 24 hours | All Low/Medium controls + smart contract whitelist, position monitoring, daily reconciliation | -| Trading Capital (variable) | High | Active Ops | 3 | Hardware mandatory | 6 hours | All Low/Medium controls + smart contract whitelist, real-time monitoring, daily reconciliation | -| Active Treasury (5-10%) | High | Warm Storage | 3-4 | Hardware mandatory | 24 hours | All Low/Medium controls + transaction velocity limits, SIEM monitoring， multi-channel confirmation | -| Secondary Reserve (10-25%) | Critical | Cold Vault | 4-5 | Hardware mandatory | 48 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended | -| Primary Reserve (>25% assets) | Critical | Cold Vault | 5-7 | Hardware mandatory | 72 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended | - -### Step 4: Enhanced Controls for High-Risk Accounts - -For Critical and High impact accounts, implement additional security layers beyond the baseline controls. - -#### Transaction Verification - -- Test transactions: Send maximum $100 to new addresses before executing full transaction -- Multi-channel confirmation: Request via one channel, approve via separate channel -- Simulation requirement: All transactions must be simulated before execution -- Address verification: Verify new addresses against three independent sources - -For DeFi interactions: refer to the [DeFi Risk Assessment Guide](https://entethalliance.org/specs/defi-risks/v1/) for recommended procedures. - - -#### Access Security - -- Hardware security keys (FIDO2/WebAuthn) mandatory for all approvers - - Secure fallback: Each approver must register minimum 2 hardware keys stored in separate secure locations - - Key loss procedure: Temporary access via backup key + additional approver verification via multiple channels + mandatory key replacement within 48 hours -- IP whitelisting with 24-hour change approval delay - if treasury software supports application-level IP whitelisting, restrict to VPN IP range only -- Device fingerprinting with new device approval process -- Session timeout and re-authentication for sensitive operations -- Dedicated credentials: Use separate email addresses and passwords exclusively for custody access, not shared with other corporate systems - -#### Device Security - -- Dedicated secure workstations and mobile devices for custody access only (no general browsing, email, or other corporate activities) -- Network isolation on separate VLAN/segment -- VPN mandatory for all platform access; if treasury platform supports it, configure IP whitelisting to only allow access from VPN IP addresses -- Full disk encryption with automatic screen lock -- MDM-enforced security baseline with remote wipe capability -- Mobile endpoint security monitoring (e.g., iVerify) for devices used as second factors or keystores, without requiring full MDM admin control - -#### MPC for Large Holdings - -For organizations managing >10% of total assets or >$10M equivalent in a single custodial account consider using MPC: - -- Evaluate MPC (Multi-Party Computation) custody solutions that distribute key material across multiple parties -- Consider threshold signature schemes (e.g., 3-of-5 or 5-of-9) where no single party controls sufficient key shares -- Implement geographic distribution of key share holders across multiple jurisdictions -- Establish clear key refresh and rotation procedures -- Document recovery procedures and test annually - -#### Zero Trust Architecture Alternative - -A Zero Trust architecture involves continuous verification of user, device, and context, rather than reliance on a single perimeter or network location. Centralizing access through a secure environment (such as a bastion host or isolated cloud workspace) can support Zero Trust principles when combined with strong identity and device posture enforcement. - -- **Bastion Host Approach:** Deploy a hardened jump server that acts as the sole gateway to custody platforms. - - All custody sessions route through the bastion with full session recording - - Bastion enforces MFA, device posture checks, and approved software versions - - No direct custody access from employee devices - - Centralized patch management and security configuration - -- **Cloud Workspace Isolation:** Use browser-isolated or virtual workspace environments (e.g., Citrix, AWS WorkSpaces, Azure Virtual Desktop) - - Custody access occurs only within a controlled virtual environment - - Copy/paste and download restrictions prevent data exfiltration - - Session timeout and automatic workspace destruction after use - - Significantly reduces risk from compromised employee devices - -#### Security Monitoring & Logging - -For Critical and High impact accounts, implement centralized security monitoring: - -- **SIEM Deployment:** Deploy SIEM to centralize logs from custody platforms, authentication systems, and access devices. Create real-time correlation rules for suspicious patterns (failed authentication, geographic anomalies, policy changes). - -- **Internal Incident Response:** Build dedicated incident response capability for custody-related security events. Define clear escalation procedures, maintain 24/7 on-call rotation for Critical accounts, and establish playbooks for custody compromise scenarios. - -- **Essential Log Sources:** Authentication events, transaction attempts, policy modifications, access changes, whitelist updates, IP address changes, new device enrollments, and approval workflows. - -For Medium and Low impact accounts, leverage custodian's native audit logs with weekly manual review and automated alerting for critical events (new device enrollment, policy changes, transactions above threshold). - ---- - -## Documentation Templates - -### Registration Template - -Use this template when initially documenting a custodial account. - -``` -CUSTODIAL ACCOUNT REGISTRATION - -Account Name: [Descriptive name] -Custodian: [Provider name and legal entity] -Account ID: [Custodian reference number] -Network(s): [Bitcoin, Ethereum, etc.] -Registration Date: YYYY-MM-DD -Registered By: [Name] - -CLASSIFICATION -Impact Level: [Low / Medium / High / Critical] -Operational Type: [Cold Vault / Warm Storage / Active Operations / Time-Critical] - -Justification: -- Financial exposure: $XXX,XXX,XXX -- Operational dependency: [Description] -- Recovery time objective: [X hours/days] - -ASSETS CONTROLLED -Asset | Network | Value | Purpose ---------|----------|-----------|------------------------------ -BTC | Bitcoin | $XXX,XXX | [Reserve/Trading/Operations] -ETH | Ethereum | $XXX,XXX | [Reserve/Trading/Operations] -USDC | Ethereum | $XXX,XXX | [Reserve/Trading/Operations] - -CUSTODY MODEL -Type: [Qualified Custodian / Co-managed / MPC Platform] -Key Management: [MPC 3-of-5 / Multi-sig 2-of-3 / HSM] -Key Control: [Custodian only / Co-managed / Client-controlled] -Recovery Capability: [Yes - describe / No] - -INITIAL ACCESS SETUP -Primary Administrator: [Name, added YYYY-MM-DD] -Initial Approvers: [Names, added YYYY-MM-DD] - -Note: Complete access details documented in Access Change Template -Note: Security configuration documented in Security Configuration Template - -ATTESTATION -This account [meets / deviates from] security standards for its classification. - -[If deviation: Explain gap and compensating controls] - -CONTACTS -Security Owner: [Name, email, phone] -Backup Contact: [Name, email, phone] -Custodian Support: [Name, email, phone] - -Last Updated: YYYY-MM-DD -Updated By: [Name] -``` - ---- - -### Access Change Template - -Use this template when modifying user access to a custodial account. - -``` -CUSTODIAL ACCOUNT ACCESS CHANGE - -Account Name: [Name] -Custodian: [Provider] -Account ID: [Reference] -Change Date: YYYY-MM-DD -Changed By: [Name] - -ACCESS MODIFICATIONS - -Additions: -Name/Role | Access Level | MFA Method | Justification -----------|--------------|----------------|------------------------------ -[Name] | [Approver] | [Hardware key] | [Reason for addition] - -Removals: -Name/Role | Access Level | Removal Reason -----------|--------------|------------------------------- -[Name] | [Approver] | [Personnel change / Security / Other] - -Permission Changes: -Name/Role | Old Level | New Level | Justification -----------|-----------|-----------|--------------------------- -[Name] | [Initiator] | [Approver] | [Reason for elevation] - -CURRENT ACCESS LIST (after changes) -Name/Role | Level | MFA Method | Device ID -----------|-----------|---------------|--------- -[Name] | Admin | Hardware key | [ID] -[Name] | Approver | Hardware key | [ID] -[Name] | Approver | Hardware key | [ID] -[Name] | Initiator | TOTP | [ID] - -VERIFICATION -[ ] All removed users confirmed deactivated in custodian platform -[ ] All new users completed MFA setup -[ ] Access permissions tested and verified -[ ] Emergency contacts updated -[ ] Documentation updated in [location] - -APPROVALS -Requested By: _________________ Date: _______ -Approved By: _________________ Date: _______ -Security Review: _________________ Date: _______ - -Change Ticket: [Reference number if applicable] -``` - ---- - -### Security Configuration Template - -Use this template to document detailed security settings. Complete this after initial account registration. - -``` -CUSTODIAL ACCOUNT SECURITY CONFIGURATION - -Account: [Name] -Custodian: [Provider] -Last Configuration Update: YYYY-MM-DD -Configured By: [Name] - -AUTHENTICATION SETTINGS - -Multi-Factor Authentication: -Role | Primary Method | Backup Method | Enrollment Status -Administrator | Hardware key + biometric | Hardware key + PIN | [Active] -Approver | Hardware key | TOTP + SMS | [Active] -Initiator | Hardware key or TOTP | SMS | [Active] -Viewer | TOTP | SMS | [Active] - -Session Controls: -- Timeout: [X minutes] -- Re-auth required for: [High-value transactions, policy changes, user management] -- Concurrent sessions: [Allowed/Blocked] - -ACCESS CONTROL - -Current User List: -Name/Role | Level | MFA Method | Device ID | Added Date -----------|----------|--------------|----------|------------ -[Name] | Admin | Hardware key | [ID] | YYYY-MM-DD -[Name] | Approver | Hardware key | [ID] | YYYY-MM-DD -[Name] | Approver | Hardware key | [ID] | YYYY-MM-DD - -Note: Track all access changes using Access Change Template - -Approval Thresholds: -Transaction Value (% of Total Assets) | Required Approvers | Time Delay | Additional Requirements -<0.1% | 1 | None | MFA -0.1% - 1% | 3 | 4 hours | MFA -1% - 10% | 4 | 24 hours | Multi-channel confirmation, test transaction -10% - 25% | 5 | 24 hours | Multi-channel confirmation, test transaction ->25% | 7 | 48 hours | Multi-channel confirmation, test transaction - -Separation of Duties: -[ ] Initiators cannot approve own transactions -[ ] Admins cannot unilaterally execute withdrawals -[ ] Minimum [X] unique approvers required - -NETWORK RESTRICTIONS - -IP Whitelist: -XXX.XXX.XXX.XXX - [Office Location] -XXX.XXX.XXX.XXX - [VPN Range] -XXX.XXX.XXX.XXX - [Backup Location] - -Change Approval: [24 hour delay / XX approvers required] -Emergency Override: [Process description] - -VPN Requirement: [Mandatory / Optional] -Geographic Restrictions: [Blocked countries/regions] -Device Fingerprinting: [Enabled / Disabled] - -TRANSACTION POLICIES - -Address Whitelisting: -Status: [Enabled / Disabled] -Current Addresses: [XX addresses] -Addition Process: [XX approvers, YY hour delay] -Review Schedule: [Monthly / Quarterly] - -Transaction Limits: -Limit Type | Amount | Override Process -------------------|----------|----------------- -Single Transaction | $XXX,XXX | [Authorization required] -Hourly Aggregate | $XXX,XXX | [Authorization required] -Daily Aggregate | $XXX,XXX | [Authorization required] -Weekly Aggregate | $XXX,XXX | [Authorization required] -Monthly Aggregate | $XXX,XXX | [Authorization required] - -Time-Lock Settings: -Change Type | Delay Period --------------------------------------|------------- -New address addition | XX hours -Policy modification | XX hours -High-value transaction (>$XXX,XXX) | XX hours - -MONITORING & ALERTS - -Real-Time Alerts: -Type | Enabled ----------------------------|-------- -All outgoing transactions | [ ] -New device login | [ ] -Failed authentication attempts (>X) | [ ] -Policy violations | [ ] -Large transactions (>$XXX,XXX) | [ ] -Unusual access times | [ ] -New geographic location | [ ] - -Alert Routing: -Severity | Contact | Method | Response Time ----------|------------------|-------------|-------------- -Critical | [Name, phone] | SMS + Call | <15 min -High | [Name, phone] | SMS + Email | <1 hour -Medium | [Name, email] | Email | <4 hours - -VERIFICATION -[ ] All settings tested and operational -[ ] Alert routing verified -[ ] User access confirmed -[ ] Documentation stored in [location] - -Configured By: _________________ Date: _______ -Reviewed By: _________________ Date: _______ -Approved By: _________________ Date: _______ -``` - ---- - -### Quarterly Review Template - -Use this template for regular security reviews of custodial accounts. - -``` -CUSTODIAL ACCOUNT QUARTERLY REVIEW - -Account: [Name] -Custodian: [Provider] -Review Period: [Q1/Q2/Q3/Q4 YYYY] -Review Date: YYYY-MM-DD -Reviewed By: [Name] - -ACCESS AUDIT - -Current Users: -Name/Role | Level | Last Login | MFA Status | Action Required -[Name] | Admin | YYYY-MM-DD | Active | None -[Name] | Approver | YYYY-MM-DD | Active | None -[Name] | Approver | Never logged in | Inactive | Remove access - -Access Changes This Quarter: [X additions, Y removals, Z modifications] - -Findings: -[ ] All users still require current access level -[ ] No dormant accounts (>90 days inactive) -[ ] MFA functioning for all users -[ ] No unauthorized access detected - -Actions Required: -- [List any access to be removed/modified] -- [List any policy updates needed] - -TRANSACTION REVIEW - -Transaction Volume: -- Total transactions: [X] -- Average per month: [Y] -- Largest transaction: $XXX,XXX -- Total outflow: $XXX,XXX - -Pattern Analysis: -[ ] Transactions within expected parameters -[ ] No unusual transaction patterns detected -[ ] All large transactions properly authorized -[ ] Test transactions performed correctly - -Anomalies Detected: -- [List any unusual activity or violations] - -SECURITY CONFIGURATION - -Whitelist Review: -- Current addresses: [X] -- Addresses added this quarter: [Y] -- Addresses to remove: [Z] -- Review complete: [Yes/No] - -Spending Limits: -Current | Actual Usage | Status -Single: $XXX,XXX | Max: $XXX,XXX | [Appropriate / Adjust] -Daily: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust] -Monthly: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust] - -Findings: -[ ] Limits appropriate for current usage -[ ] No limit breaches this quarter -[ ] IP whitelist current and accurate -[ ] Time-locks functioning properly - -ALERT EFFECTIVENESS - -Alerts This Quarter: -Type | Count | False Positive Rate -Critical | [X] | [Y%] -High | [X] | [Y%] -Medium | [X] | [Y%] - -Response Times: -Severity | Target | Actual Average | Status -Critical | <15 min | [X min] | [Met/Missed] -High | <1 hour | [X min] | [Met/Missed] -Medium | <4 hours | [X hours] | [Met/Missed] - -Findings: -[ ] Alert routing working correctly -[ ] Response times meeting SLAs -[ ] No missed critical alerts - -Actions Required: -- [Adjust alert thresholds if needed] -- [Update contact information] - -CUSTODIAN RELATIONSHIP - -SOC Reports: [Current / Expired - date] -Security Incidents: [Any custodian-wide incidents this quarter] -Service Quality: [Any issues or concerns] -Communication: [Regular contact maintained] - -RISK ASSESSMENT UPDATE - -Classification Review: -Current: [Impact Level / Operational Type] -Still Appropriate: [Yes / No] - -If No, Recommended Change: -New Classification: [Level / Type] -Justification: [Explain change in risk profile] - -Asset Value Change: [% increase/decrease] -Operational Change: [Any significant changes in usage] - -RECOMMENDATIONS - -Security Improvements: -1. [Recommendation] -2. [Recommendation] -3. [Recommendation] - -Operational Improvements: -1. [Recommendation] -2. [Recommendation] - -ATTESTATION - -This account [continues to meet / deviates from] security standards. - -[If deviation: Describe and provide remediation plan] - -APPROVALS - -Reviewer: _________________ Date: _______ -Security Officer: _________________ Date: _______ -Treasury Lead: _________________ Date: _______ - -Next Review Due: YYYY-MM-DD -``` - ---- - - - diff --git a/docs/pages/treasury-operations/classification.mdx b/docs/pages/treasury-operations/classification.mdx new file mode 100644 index 00000000..52355430 --- /dev/null +++ b/docs/pages/treasury-operations/classification.mdx @@ -0,0 +1,142 @@ +--- +title: "Custodial Treasury Security: Classification Framework" +tags: + - Treasury Ops + - Operations + - Risk Management +contributors: + - role: wrote + users: [dickson] + - role: reviewed + users: [relotnek, bsamuels453] +--- + +import { + TagList, + AttributionList, + TagProvider, + TagFilter, + ContributeFooter, +} from "../../../components"; + + + + +# Custodial Treasury Security: Classification Framework + + + + +Proper documentation and classification of custodial accounts is essential for institutional treasury security. This guide focuses on the security assessment and classification framework for crypto assets held with third-party custodians. + +> See also: [Registration Documents](./registration-documents) and [Enhanced Controls for High-Risk Accounts](./enhanced-controls) + +## Classification Process + +Use this dual classification to determine appropriate security controls for each custodial account. + +### Step 1: Impact Assessment + +Evaluate the consequences if this account is compromised or unavailable. + +#### Financial Impact + +Calculate the total value at risk in this account: + +- Current market value of all assets held +- Include value of any active positions (e.g., staked assets, DeFi deposits) +- What is the financial impact if unavailable for 7 days? + +#### Operational Impact + +Assess the consequences if this account becomes unavailable: + +- What specific operations require this account? +- Do you have a secondary custody account that can handle these operations? +- What is the reputational impact if this account is compromised or unavailable? + +#### Regulatory Impact + +Evaluate regulatory and compliance consequences: + +- Are assets in this account subject to regulatory reporting requirements (SEC filings, audit requirements)? +- Does this account hold regulated assets (e.g., stablecoins subject to reserves reporting)? +- What are the regulatory deadlines that could be missed if this account is unavailable? + +#### Impact Classification + +| Level | Financial Exposure (% of Total Assets) | Operational Dependency | Regulatory Impact | +| ------------ | -------------------------------------- | -------------------------------------------- | ---------------------------------------------------- | +| **Low** | \<1% | No critical operations depend on it | No regulatory reporting tied to this account | +| **Medium** | 1% - 10% | Important but alternative funding available | Periodic reporting; delays manageable | +| **High** | 10% - 25% | Critical operations, limited alternatives | Regular regulatory filings; delays cause violations | +| **Critical** | \>25% | Business-critical, no alternatives for weeks | Real-time reporting requirements; SEC filings; audit | + +### Step 2: Operational Assessment + +Evaluate how frequently and urgently this account must be accessed. + +#### Transaction Frequency + +Document typical transaction patterns: + +- Transactions per month +- Typical transaction sizes +- Predictability of transaction timing + +#### Access Urgency + +Define response time requirements: + +- What is the maximum acceptable delay for routine transactions? +- Are there scenarios requiring same-day execution? +- What are the consequences of 24-hour, 72-hour, or 7-day delays? + +#### Coordination Requirements + +Assess how transactions are executed: + +- How many approvers are needed for typical transactions? +- Are transactions handled manually or through automated systems? +- Do approvers need to coordinate across timezones? + +Note: Single-approver configurations should only be used for low-value operational accounts (\<0.1%) with additional compensating controls like strict spending limits and daily reconciliation. + +#### Operational Classification + +| Type | Frequency | Response Window | Example Use Cases | +| --------------------- | ------------- | --------------- | -------------------------------------------------- | +| **Cold Vault** | \<5 tx/month | 48-72 hours | Long-term reserves, infrequent rebalancing | +| **Warm Storage** | 5-50 tx/month | 4-24 hours | Scheduled payments, planned operations | +| **Active Operations** | \>50 tx/month | \<4 hours | Trading capital, frequent operational expenses | +| **Time-Critical** | Unpredictable | \<2 hours | Collateral management, market-sensitive operations | + +### Step 3: Security Control Matrix + +Combine impact and operational assessments to determine required controls. + +| Use Case | Impact | Operational | Approvers | MFA Requirement | Whitelist Delay | Additional Controls | +| ----------------------------- | ----------- | ------------- | --------- | ------------------ | --------------- | ------------------------------------------- | +| Payments | Low | Active Ops | 2 | Standard TOTP | 6 hours | **Baseline (all accounts):** Dedicated devices for custody access, address whitelisting enabled, test small amount to new addresses before full transaction, transaction simulation. **Low-specific:** Per-transaction cap, monthly aggregate limit | +| Operational Wallet | Medium | Active Ops | 2 | Hardware required | 12 hours | All Low controls + daily transaction caps, weekly reconciliation, monthly audit | +| Liquidation Protection | Medium-High | Time-Critical | 2 | Hardware required | None | All Low/Medium controls + automated alerts for position health, real-time monitoring | +| DeFi Positions | Medium-High | Warm Storage | 3 | Hardware mandatory | 24 hours | All Low/Medium controls + smart contract whitelist, position monitoring, daily reconciliation | +| Trading Capital (variable) | High | Active Ops | 3 | Hardware mandatory | 6 hours | All Low/Medium controls + smart contract whitelist, real-time monitoring, daily reconciliation | +| Active Treasury (5-10%) | High | Warm Storage | 3-4 | Hardware mandatory | 24 hours | All Low/Medium controls + transaction velocity limits, SIEM monitoring， multi-channel confirmation | +| Secondary Reserve (10-25%) | Critical | Cold Vault | 4-5 | Hardware mandatory | 48 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended | +| Primary Reserve (>25% assets) | Critical | Cold Vault | 5-7 | Hardware mandatory | 72 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended | + +### Step 4: Document Your Decision + + + +- Record impact level and operational type with justification +- Capture approver thresholds and required controls +- Store links to relevant custody accounts and addresses + +Proceed to: [Registration Documents](./registration-documents) + +For Critical/High accounts, ensure you also review: [Enhanced Controls for High-Risk Accounts](./enhanced-controls) + + + diff --git a/docs/pages/treasury-operations/enhanced-controls.mdx b/docs/pages/treasury-operations/enhanced-controls.mdx new file mode 100644 index 00000000..0b74b5d5 --- /dev/null +++ b/docs/pages/treasury-operations/enhanced-controls.mdx @@ -0,0 +1,110 @@ +--- +title: "Enhanced Controls for High-Risk Custodial Accounts" +tags: + - Treasury Ops + - Operations + - Risk Management +contributors: + - role: wrote + users: [dickson] + - role: reviewed + users: [relotnek, bsamuels453] +--- + +import { + TagList, + AttributionList, + TagProvider, + TagFilter, + ContributeFooter, +} from "../../../components"; + + + + +# Enhanced Controls for High-Risk Accounts + + + + +For Critical and High impact custodial accounts, implement the following controls in addition to baseline measures. + +--- + +## Transaction Verification + +- Test transactions: Send maximum $100 to new addresses before executing full transaction +- Multi-channel confirmation: Request via one channel, approve via separate channel +- Simulation requirement: All transactions must be simulated before execution +- Address verification: Verify new addresses against three independent sources + +For DeFi interactions: refer to the [DeFi Risk Assessment Guide](https://entethalliance.org/specs/defi-risks/v1/) for recommended procedures. + +## Access Security + +- Hardware security keys (FIDO2/WebAuthn) mandatory for all approvers + - Secure fallback: Each approver must register minimum 2 hardware keys stored in separate secure locations + - Key loss procedure: Temporary access via backup key + additional approver verification via multiple channels + mandatory key replacement within 48 hours +- IP whitelisting with 24-hour change approval delay - if treasury software supports application-level IP whitelisting, restrict to VPN IP range only +- Device fingerprinting with new device approval process +- Session timeout and re-authentication for sensitive operations +- Dedicated credentials: Use separate email addresses and passwords exclusively for custody access, not shared with other corporate systems + +## Device Security + +- Dedicated secure workstations and mobile devices for custody access only (no general browsing, email, or other corporate activities) +- Network isolation on separate VLAN/segment +- VPN mandatory for all platform access; if treasury platform supports it, configure IP whitelisting to only allow access from VPN IP addresses +- Full disk encryption with automatic screen lock +- MDM-enforced security baseline with remote wipe capability +- Mobile endpoint security monitoring (e.g., iVerify) for devices used as second factors or keystores, without requiring full MDM admin control + +## MPC for Large Holdings + +For organizations managing >10% of total assets or >$10M equivalent in a single custodial account consider using MPC: + +- Evaluate MPC (Multi-Party Computation) custody solutions that distribute key material across multiple parties +- Consider threshold signature schemes (e.g., 3-of-5 or 5-of-9) where no single party controls sufficient key shares +- Implement geographic distribution of key share holders across multiple jurisdictions +- Establish clear key refresh and rotation procedures +- Document recovery procedures and test annually + +## Zero Trust Architecture Alternative + +A Zero Trust architecture involves continuous verification of user, device, and context, rather than reliance on a single perimeter or network location. Centralizing access through a secure environment (such as a bastion host or isolated cloud workspace) can support Zero Trust principles when combined with strong identity and device posture enforcement. + +- Bastion Host Approach: Deploy a hardened jump server that acts as the sole gateway to custody platforms. + - All custody sessions route through the bastion with full session recording + - Bastion enforces MFA, device posture checks, and approved software versions + - No direct custody access from employee devices + - Centralized patch management and security configuration + +- Cloud Workspace Isolation: Use browser-isolated or virtual workspace environments (e.g., Citrix, AWS WorkSpaces, Azure Virtual Desktop) + - Custody access occurs only within a controlled virtual environment + - Copy/paste and download restrictions prevent data exfiltration + - Session timeout and automatic workspace destruction after use + - Significantly reduces risk from compromised employee devices + +## Security Monitoring & Logging + +For Critical and High impact accounts, implement centralized security monitoring: + +- SIEM Deployment: Deploy SIEM to centralize logs from custody platforms, authentication systems, and access devices. Create real-time correlation rules for suspicious patterns (failed authentication, geographic anomalies, policy changes). + +- Internal Incident Response: Build dedicated incident response capability for custody-related security events. Define clear escalation procedures, maintain 24/7 on-call rotation for Critical accounts, and establish playbooks for custody compromise scenarios. + +- Essential Log Sources: Authentication events, transaction attempts, policy modifications, access changes, whitelist updates, IP address changes, new device enrollments, and approval workflows. + +For Medium and Low impact accounts, leverage custodian's native audit logs with weekly manual review and automated alerting for critical events (new device enrollment, policy changes, transactions above threshold). + +--- + +### See also + +- Classification: [Custodial Treasury Security: Classification Framework](./classification) +- Templates: [Registration Documents](./registration-documents) + + + + + diff --git a/docs/pages/treasury-operations/registration-documents.mdx b/docs/pages/treasury-operations/registration-documents.mdx new file mode 100644 index 00000000..8182d694 --- /dev/null +++ b/docs/pages/treasury-operations/registration-documents.mdx @@ -0,0 +1,415 @@ +--- +title: "Custodial Account Registration Documents" +tags: + - Treasury Ops + - Operations + - Risk Management +contributors: + - role: wrote + users: [dickson] + - role: reviewed + users: [relotnek, bsamuels453] +--- + +import { + TagList, + AttributionList, + TagProvider, + TagFilter, + ContributeFooter, +} from "../../../components"; + + + + +# Registration Documents + + + + +Use these standardized templates to register custodial accounts, track access changes, document security configurations, and perform quarterly reviews. + +> See also: [Classification Framework](./classification) and [Enhanced Controls for High-Risk Accounts](./enhanced-controls) + +--- + +## Registration Template + +Use this template when initially documenting a custodial account. + +``` +CUSTODIAL ACCOUNT REGISTRATION + +Account Name: [Descriptive name] +Custodian: [Provider name and legal entity] +Account ID: [Custodian reference number] +Network(s): [Bitcoin, Ethereum, etc.] +Registration Date: YYYY-MM-DD +Registered By: [Name] + +CLASSIFICATION +Impact Level: [Low / Medium / High / Critical] +Operational Type: [Cold Vault / Warm Storage / Active Operations / Time-Critical] + +Justification: +- Financial exposure: $XXX,XXX,XXX +- Operational dependency: [Description] +- Recovery time objective: [X hours/days] + +ASSETS CONTROLLED +Asset | Network | Value | Purpose +--------|----------|-----------|------------------------------ +BTC | Bitcoin | $XXX,XXX | [Reserve/Trading/Operations] +ETH | Ethereum | $XXX,XXX | [Reserve/Trading/Operations] +USDC | Ethereum | $XXX,XXX | [Reserve/Trading/Operations] + +CUSTODY MODEL +Type: [Qualified Custodian / Co-managed / MPC Platform] +Key Management: [MPC 3-of-5 / Multi-sig 2-of-3 / HSM] +Key Control: [Custodian only / Co-managed / Client-controlled] +Recovery Capability: [Yes - describe / No] + +INITIAL ACCESS SETUP +Primary Administrator: [Name, added YYYY-MM-DD] +Initial Approvers: [Names, added YYYY-MM-DD] + +Note: Complete access details documented in Access Change Template +Note: Security configuration documented in Security Configuration Template + +ATTESTATION +This account [meets / deviates from] security standards for its classification. + +[If deviation: Explain gap and compensating controls] + +CONTACTS +Security Owner: [Name, email, phone] +Backup Contact: [Name, email, phone] +Custodian Support: [Name, email, phone] + +Last Updated: YYYY-MM-DD +Updated By: [Name] +``` + +--- + +## Access Change Template + +Use this template when modifying user access to a custodial account. + +``` +CUSTODIAL ACCOUNT ACCESS CHANGE + +Account Name: [Name] +Custodian: [Provider] +Account ID: [Reference] +Change Date: YYYY-MM-DD +Changed By: [Name] + +ACCESS MODIFICATIONS + +Additions: +Name/Role | Access Level | MFA Method | Justification +----------|--------------|----------------|------------------------------ +[Name] | [Approver] | [Hardware key] | [Reason for addition] + +Removals: +Name/Role | Access Level | Removal Reason +----------|--------------|------------------------------- +[Name] | [Approver] | [Personnel change / Security / Other] + +Permission Changes: +Name/Role | Old Level | New Level | Justification +----------|-----------|-----------|--------------------------- +[Name] | [Initiator] | [Approver] | [Reason for elevation] + +CURRENT ACCESS LIST (after changes) +Name/Role | Level | MFA Method | Device ID +----------|-----------|---------------|--------- +[Name] | Admin | Hardware key | [ID] +[Name] | Approver | Hardware key | [ID] +[Name] | Approver | Hardware key | [ID] +[Name] | Initiator | TOTP | [ID] + +VERIFICATION +[ ] All removed users confirmed deactivated in custodian platform +[ ] All new users completed MFA setup +[ ] Access permissions tested and verified +[ ] Emergency contacts updated +[ ] Documentation updated in [location] + +APPROVALS +Requested By: _________________ Date: _______ +Approved By: _________________ Date: _______ +Security Review: _________________ Date: _______ + +Change Ticket: [Reference number if applicable] +``` + +--- + +## Security Configuration Template + +Use this template to document detailed security settings. Complete this after initial account registration. + +``` +CUSTODIAL ACCOUNT SECURITY CONFIGURATION + +Account: [Name] +Custodian: [Provider] +Last Configuration Update: YYYY-MM-DD +Configured By: [Name] + +AUTHENTICATION SETTINGS + +Multi-Factor Authentication: +Role | Primary Method | Backup Method | Enrollment Status +Administrator | Hardware key + biometric | Hardware key + PIN | [Active] +Approver | Hardware key | TOTP + SMS | [Active] +Initiator | Hardware key or TOTP | SMS | [Active] +Viewer | TOTP | SMS | [Active] + +Session Controls: +- Timeout: [X minutes] +- Re-auth required for: [High-value transactions, policy changes, user management] +- Concurrent sessions: [Allowed/Blocked] + +ACCESS CONTROL + +Current User List: +Name/Role | Level | MFA Method | Device ID | Added Date +----------|----------|--------------|----------|------------ +[Name] | Admin | Hardware key | [ID] | YYYY-MM-DD +[Name] | Approver | Hardware key | [ID] | YYYY-MM-DD +[Name] | Approver | Hardware key | [ID] | YYYY-MM-DD + +Note: Track all access changes using Access Change Template + +Approval Thresholds: +Transaction Value (% of Total Assets) | Required Approvers | Time Delay | Additional Requirements +<0.1% | 1 | None | MFA +0.1% - 1% | 3 | 4 hours | MFA +1% - 10% | 4 | 24 hours | Multi-channel confirmation, test transaction +10% - 25% | 5 | 24 hours | Multi-channel confirmation, test transaction +>25% | 7 | 48 hours | Multi-channel confirmation, test transaction + +Separation of Duties: +[ ] Initiators cannot approve own transactions +[ ] Admins cannot unilaterally execute withdrawals +[ ] Minimum [X] unique approvers required + +NETWORK RESTRICTIONS + +IP Whitelist: +XXX.XXX.XXX.XXX - [Office Location] +XXX.XXX.XXX.XXX - [VPN Range] +XXX.XXX.XXX.XXX - [Backup Location] + +Change Approval: [24 hour delay / XX approvers required] +Emergency Override: [Process description] + +VPN Requirement: [Mandatory / Optional] +Geographic Restrictions: [Blocked countries/regions] +Device Fingerprinting: [Enabled / Disabled] + +TRANSACTION POLICIES + +Address Whitelisting: +Status: [Enabled / Disabled] +Current Addresses: [XX addresses] +Addition Process: [XX approvers, YY hour delay] +Review Schedule: [Monthly / Quarterly] + +Transaction Limits: +Limit Type | Amount | Override Process +------------------|----------|----------------- +Single Transaction | $XXX,XXX | [Authorization required] +Hourly Aggregate | $XXX,XXX | [Authorization required] +Daily Aggregate | $XXX,XXX | [Authorization required] +Weekly Aggregate | $XXX,XXX | [Authorization required] +Monthly Aggregate | $XXX,XXX | [Authorization required] + +Time-Lock Settings: +Change Type | Delay Period +-------------------------------------|------------- +New address addition | XX hours +Policy modification | XX hours +High-value transaction (>$XXX,XXX) | XX hours + +MONITORING & ALERTS + +Real-Time Alerts: +Type | Enabled +---------------------------|-------- +All outgoing transactions | [ ] +New device login | [ ] +Failed authentication attempts (>X) | [ ] +Policy violations | [ ] +Large transactions (>$XXX,XXX) | [ ] +Unusual access times | [ ] +New geographic location | [ ] + +Alert Routing: +Severity | Contact | Method | Response Time +---------|------------------|-------------|-------------- +Critical | [Name, phone] | SMS + Call | <15 min +High | [Name, phone] | SMS + Email | <1 hour +Medium | [Name, email] | Email | <4 hours + +VERIFICATION +[ ] All settings tested and operational +[ ] Alert routing verified +[ ] User access confirmed +[ ] Documentation stored in [location] + +Configured By: _________________ Date: _______ +Reviewed By: _________________ Date: _______ +Approved By: _________________ Date: _______ +``` + +--- + +## Quarterly Review Template + +Use this template for regular security reviews of custodial accounts. + +``` +CUSTODIAL ACCOUNT QUARTERLY REVIEW + +Account: [Name] +Custodian: [Provider] +Review Period: [Q1/Q2/Q3/Q4 YYYY] +Review Date: YYYY-MM-DD +Reviewed By: [Name] + +ACCESS AUDIT + +Current Users: +Name/Role | Level | Last Login | MFA Status | Action Required +[Name] | Admin | YYYY-MM-DD | Active | None +[Name] | Approver | YYYY-MM-DD | Active | None +[Name] | Approver | Never logged in | Inactive | Remove access + +Access Changes This Quarter: [X additions, Y removals, Z modifications] + +Findings: +[ ] All users still require current access level +[ ] No dormant accounts (>90 days inactive) +[ ] MFA functioning for all users +[ ] No unauthorized access detected + +Actions Required: +- [List any access to be removed/modified] +- [List any policy updates needed] + +TRANSACTION REVIEW + +Transaction Volume: +- Total transactions: [X] +- Average per month: [Y] +- Largest transaction: $XXX,XXX +- Total outflow: $XXX,XXX + +Pattern Analysis: +[ ] Transactions within expected parameters +[ ] No unusual transaction patterns detected +[ ] All large transactions properly authorized +[ ] Test transactions performed correctly + +Anomalies Detected: +- [List any unusual activity or violations] + +SECURITY CONFIGURATION + +Whitelist Review: +- Current addresses: [X] +- Addresses added this quarter: [Y] +- Addresses to remove: [Z] +- Review complete: [Yes/No] + +Spending Limits: +Current | Actual Usage | Status +Single: $XXX,XXX | Max: $XXX,XXX | [Appropriate / Adjust] +Daily: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust] +Monthly: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust] + +Findings: +[ ] Limits appropriate for current usage +[ ] No limit breaches this quarter +[ ] IP whitelist current and accurate +[ ] Time-locks functioning properly + +ALERT EFFECTIVENESS + +Alerts This Quarter: +Type | Count | False Positive Rate +Critical | [X] | [Y%] +High | [X] | [Y%] +Medium | [X] | [Y%] + +Response Times: +Severity | Target | Actual Average | Status +Critical | <15 min | [X min] | [Met/Missed] +High | <1 hour | [X min] | [Met/Missed] +Medium | <4 hours | [X hours] | [Met/Missed] + +Findings: +[ ] Alert routing working correctly +[ ] Response times meeting SLAs +[ ] No missed critical alerts + +Actions Required: +- [Adjust alert thresholds if needed] +- [Update contact information] + +CUSTODIAN RELATIONSHIP + +SOC Reports: [Current / Expired - date] +Security Incidents: [Any custodian-wide incidents this quarter] +Service Quality: [Any issues or concerns] +Communication: [Regular contact maintained] + +RISK ASSESSMENT UPDATE + +Classification Review: +Current: [Impact Level / Operational Type] +Still Appropriate: [Yes / No] + +If No, Recommended Change: +New Classification: [Level / Type] +Justification: [Explain change in risk profile] + +Asset Value Change: [% increase/decrease] +Operational Change: [Any significant changes in usage] + +RECOMMENDATIONS + +Security Improvements: +1. [Recommendation] +2. [Recommendation] +3. [Recommendation] + +Operational Improvements: +1. [Recommendation] +2. [Recommendation] + +ATTESTATION + +This account [continues to meet / deviates from] security standards. + +[If deviation: Describe and provide remediation plan] + +APPROVALS + +Reviewer: _________________ Date: _______ +Security Officer: _________________ Date: _______ +Treasury Lead: _________________ Date: _______ + +Next Review Due: YYYY-MM-DD +``` + +--- + + + + + diff --git a/vocs.config.ts b/vocs.config.ts index 64130898..75b116b1 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -363,7 +363,9 @@ const config = { collapsed: false, dev: true, items: [ - { text: 'Custodial Inventory & Controls', link: '/treasury-operations/classification-registration-and-documentation', dev: true }, + { text: 'Custodial Inventory & Controls', link: '/treasury-operations/classification', dev: true }, + { text: 'Registration Documents', link: '/treasury-operations/registration-documents', dev: true }, + { text: 'Enhanced Controls for High-Risk Accounts', link: '/treasury-operations/enhanced-controls', dev: true }, { text: 'Guide: Large Cryptocurrency Transfers', link: '/treasury-operations/transaction-verification', dev: true }, ] }, From 88bd50a4dbe5eaeac594582788c4b6b27b4836d7 Mon Sep 17 00:00:00 2001 From: Dickson Date: Thu, 16 Oct 2025 23:52:05 -0400 Subject: [PATCH 18/23] feat: enhance Treasury Operations documentation with custody/MPC policy thresholds and engine rules - Added a new section detailing custody/MPC policy thresholds, including approver requirements and suggested thresholds for various treasury operations. - Introduced core rule elements for custody policy engines, outlining transaction rules and actions. - Expanded on the definitions of policy scope to clarify operational contexts and approval processes. --- .../treasury-operations/enhanced-controls.mdx | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/docs/pages/treasury-operations/enhanced-controls.mdx b/docs/pages/treasury-operations/enhanced-controls.mdx index 0b74b5d5..10696776 100644 --- a/docs/pages/treasury-operations/enhanced-controls.mdx +++ b/docs/pages/treasury-operations/enhanced-controls.mdx @@ -69,6 +69,47 @@ For organizations managing >10% of total assets or >$10M equivalent in a single - Establish clear key refresh and rotation procedures - Document recovery procedures and test annually +### Custody/MPC Policy Thresholds for Treasury Operations + +- Minimum of 3 distinct approvers across roles (e.g., Treasury, Security, Finance) +- Target majority approval (≥50% of designated approver group; e.g., 3/5, 4/7) +- Scale quorum size with assets-at-risk and operational blast radius +- Enforce separation of duties: requester cannot be an approver; admins cannot unilaterally execute withdrawals + +Policy scope definitions (examples): + +- Emergency Freeze: Temporarily block withdrawals/policy changes across workspaces +- Protocol Parameters: Custody/policy engine settings, risk rules, policy changes +- Capital Allocation: Movements between accounts, exchanges, or strategies +- Treasury – Large: Routine treasury transfers above internal threshold +- Treasury – Small: Routine operational transfers below internal threshold +- Constrained DeFi: Time-sensitive interactions with pre-approved protocols/contracts + +Suggested approver thresholds (treasury contexts): + +| Operation | Impact | Urgency | Approver Threshold | +| -------------------- | -------- | -------------- | ----------------------------- | +| Emergency Freeze | Critical | Emergency | 2/4 | +| Protocol Parameters | High | Routine | 4/7 (7/9+ for upgrades) | +| Capital Allocation | High | Time-Sensitive | 3/5 | +| Treasury - Large | High | Routine | 4/7 | +| Treasury - Small | Medium | Routine | 3/5 | +| Constrained DeFi | Medium | Time-Sensitive | 2/3 | + +## Custody Policy Engine Rules + +Most custody/MPC platforms provide a policy engine that evaluates transaction rules and takes one of three actions: allow, block, or require additional approvals. + +Core rule elements: + +- Action: allow | block | escalate (require more approvers) +- Asset selector: all assets or specific assets/tokens +- Amount limits: per-transaction limit and optional rolling window aggregation +- Source and destination selectors: account/wallet groups, internal vs external addresses, exchanges +- Transaction type: transfers, contract interactions, approvals/signing +- Initiators and approvers: who can initiate and who must authorize (with thresholds) +- Rule identity and ordering: each rule has an ID; engines typically evaluate rules in order (first-match wins) + ## Zero Trust Architecture Alternative A Zero Trust architecture involves continuous verification of user, device, and context, rather than reliance on a single perimeter or network location. Centralizing access through a secure environment (such as a bastion host or isolated cloud workspace) can support Zero Trust principles when combined with strong identity and device posture enforcement. From 2b7718adf8744c2d72524b06065345bc40dcc2cf Mon Sep 17 00:00:00 2001 From: Dickson Date: Thu, 16 Oct 2025 23:55:33 -0400 Subject: [PATCH 19/23] feat: update fetched-tags.json for Treasury Operations classifications - Modified existing classification paths and added new entries for "Classification" and "Enhanced Controls" under Treasury Operations. - Improved categorization of tags to better reflect operational roles and risk management strategies. --- utils/fetched-tags.json | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/utils/fetched-tags.json b/utils/fetched-tags.json index 8d59b46c..d162656a 100644 --- a/utils/fetched-tags.json +++ b/utils/fetched-tags.json @@ -922,7 +922,17 @@ "Engineer/Developer", "Security Specialist" ], - "/treasury-operations/classification-registration-and-documentation": [ + "/treasury-operations/classification": [ + "Treasury Ops", + "Operations", + "Risk Management" + ], + "/treasury-operations/enhanced-controls": [ + "Treasury Ops", + "Operations", + "Risk Management" + ], + "/treasury-operations/registration-documents": [ "Treasury Ops", "Operations", "Risk Management" From ea58091188d818b651d2531d25647ba113b8c535 Mon Sep 17 00:00:00 2001 From: Dickson Wu <33645481+DicksonWu654@users.noreply.github.com> Date: Fri, 31 Oct 2025 22:57:12 -0400 Subject: [PATCH 20/23] Update docs/pages/treasury-operations/enhanced-controls.mdx Co-authored-by: Elliot <34463580+ElliotFriedman@users.noreply.github.com> --- docs/pages/treasury-operations/enhanced-controls.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/pages/treasury-operations/enhanced-controls.mdx b/docs/pages/treasury-operations/enhanced-controls.mdx index 10696776..05ba2c88 100644 --- a/docs/pages/treasury-operations/enhanced-controls.mdx +++ b/docs/pages/treasury-operations/enhanced-controls.mdx @@ -81,8 +81,8 @@ Policy scope definitions (examples): - Emergency Freeze: Temporarily block withdrawals/policy changes across workspaces - Protocol Parameters: Custody/policy engine settings, risk rules, policy changes - Capital Allocation: Movements between accounts, exchanges, or strategies -- Treasury – Large: Routine treasury transfers above internal threshold -- Treasury – Small: Routine operational transfers below internal threshold +- Treasury – Large: Routine treasury transfers above internal threshold or rate limit +- Treasury – Small: Routine operational transfers below internal threshold or rate limit - Constrained DeFi: Time-sensitive interactions with pre-approved protocols/contracts Suggested approver thresholds (treasury contexts): From 3296a971916fa1ee57949a3c42df5a58fe895a9f Mon Sep 17 00:00:00 2001 From: Dickson Wu <33645481+DicksonWu654@users.noreply.github.com> Date: Fri, 31 Oct 2025 22:57:45 -0400 Subject: [PATCH 21/23] Update docs/pages/treasury-operations/transaction-verification.mdx Co-authored-by: Elliot <34463580+ElliotFriedman@users.noreply.github.com> --- docs/pages/treasury-operations/transaction-verification.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/pages/treasury-operations/transaction-verification.mdx b/docs/pages/treasury-operations/transaction-verification.mdx index ea2041e0..b9364403 100644 --- a/docs/pages/treasury-operations/transaction-verification.mdx +++ b/docs/pages/treasury-operations/transaction-verification.mdx @@ -118,7 +118,9 @@ Request from sender: - **\<$10M**: Single transaction preferred (simpler, one confirmation cycle, cleaner records) - **\>$10M**: Consider 2-3 separate transactions (reduces single-transaction risk, allows staged confirmation, provides pause points to verify each step) - **\>$50M**: Multiple transactions strongly recommended with 30-minute intervals between each +**Anti-Duress Protocols:** +Since kidnapping and other forms of duress have been employed by criminals to steal cryptocurrency, organizations should prepare for this. Establish a duress word that indicates a transfer is not being made of your own free will. Once the duress word is mentioned during an exchange involving the transfer, law enforcement will be contacted and the transaction not processed. Procedures should be put in place with concrete run books for these situations. Safe words should not appear in run books or any digital format. **Anti-Social-Engineering Protocols:** Establish code phrase during initial verified meeting. Use this phrase to authenticate any address changes or unusual requests. Example: "What was the name of the restaurant where we finalized the agreement?" Exchange secondary contact numbers for key personnel - if primary contact requests changes, call secondary to confirm. Maintain out-of-band verification: if request comes via email, confirm via phone. From 2ede7acd725a075f7c63b75ee5432f766d2e0394 Mon Sep 17 00:00:00 2001 From: Dickson Date: Sun, 2 Nov 2025 16:17:15 -0500 Subject: [PATCH 22/23] Update contributors and enhance documentation attribution - Added Elliot Friedman as a contributor in contributors.json. - Updated contributor lists in transaction verification, enhanced controls, and classification documentation to include Elliot Friedman for improved attribution. --- docs/pages/config/contributors.json | 12 ++++++++++++ docs/pages/treasury-operations/classification.mdx | 2 +- docs/pages/treasury-operations/enhanced-controls.mdx | 2 +- .../treasury-operations/transaction-verification.mdx | 2 +- 4 files changed, 15 insertions(+), 3 deletions(-) diff --git a/docs/pages/config/contributors.json b/docs/pages/config/contributors.json index e08dc3d7..a8fe80e7 100644 --- a/docs/pages/config/contributors.json +++ b/docs/pages/config/contributors.json @@ -202,5 +202,17 @@ "company": "Trail of Bits", "job_title": "Director of Engineering for Blockchain", "description": "Frameworks Contributors" + }, + "ElliotFriedman": { + "slug": "ElliotFriedman", + "name": "Elliot", + "role": "contributor", + "avatar": "https://avatars.githubusercontent.com/ElliotFriedman", + "github": "https://github.com/ElliotFriedman", + "twitter": "https://x.com/Elliot0x", + "website": "", + "company": "", + "job_title": "", + "description": "" } } \ No newline at end of file diff --git a/docs/pages/treasury-operations/classification.mdx b/docs/pages/treasury-operations/classification.mdx index 52355430..203dcbd1 100644 --- a/docs/pages/treasury-operations/classification.mdx +++ b/docs/pages/treasury-operations/classification.mdx @@ -8,7 +8,7 @@ contributors: - role: wrote users: [dickson] - role: reviewed - users: [relotnek, bsamuels453] + users: [relotnek, bsamuels453, ElliotFriedman] --- import { diff --git a/docs/pages/treasury-operations/enhanced-controls.mdx b/docs/pages/treasury-operations/enhanced-controls.mdx index 05ba2c88..df28569e 100644 --- a/docs/pages/treasury-operations/enhanced-controls.mdx +++ b/docs/pages/treasury-operations/enhanced-controls.mdx @@ -8,7 +8,7 @@ contributors: - role: wrote users: [dickson] - role: reviewed - users: [relotnek, bsamuels453] + users: [relotnek, bsamuels453, ElliotFriedman] --- import { diff --git a/docs/pages/treasury-operations/transaction-verification.mdx b/docs/pages/treasury-operations/transaction-verification.mdx index b9364403..cf82276a 100644 --- a/docs/pages/treasury-operations/transaction-verification.mdx +++ b/docs/pages/treasury-operations/transaction-verification.mdx @@ -10,7 +10,7 @@ contributors: - role: wrote users: [dickson] - role: reviewed - users: [relotnek] + users: [relotnek, ElliotFriedman] --- import { From 6b0fbbab7a1ea017ea45d62a42c0874059c6021a Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 3 Nov 2025 11:02:18 -0500 Subject: [PATCH 23/23] Update contributors.json to standardize job titles and descriptions - Changed job titles and descriptions for contributors to singular form for consistency. - Added missing details for Elliot Friedman, including website and company information. --- docs/pages/config/contributors.json | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/pages/config/contributors.json b/docs/pages/config/contributors.json index a8fe80e7..e9dd7452 100644 --- a/docs/pages/config/contributors.json +++ b/docs/pages/config/contributors.json @@ -188,8 +188,8 @@ "twitter": "https://x.com/_SEAL_Org", "website": "https://securityalliance.org", "company": "SEAL", - "job_title": "Frameworks Contributors", - "description": "Frameworks Contributors" + "job_title": "Frameworks Contributor", + "description": "Frameworks Contributor" }, "bsamuels453": { "slug": "bsamuels453", @@ -201,7 +201,7 @@ "website": "https://bsamuels.net/", "company": "Trail of Bits", "job_title": "Director of Engineering for Blockchain", - "description": "Frameworks Contributors" + "description": "Frameworks Contributor" }, "ElliotFriedman": { "slug": "ElliotFriedman", @@ -210,9 +210,9 @@ "avatar": "https://avatars.githubusercontent.com/ElliotFriedman", "github": "https://github.com/ElliotFriedman", "twitter": "https://x.com/Elliot0x", - "website": "", - "company": "", - "job_title": "", - "description": "" + "website": "https://kleidi.io/", + "company": "Solidity Labs", + "job_title": "Founder & Engineer", + "description": "Frameworks Contributor" } } \ No newline at end of file