SFC - Treasury Operations
Revision 1.1 · Updated 2026-04-17 · Changelog
The SEAL Framework Checklist (SFC) for Treasury Operations provides structured guidelines for securely managing and operating an organization's treasury covering governance, access control, transaction security, monitoring, and vendor management.
Scope note: These baselines target internal treasury operations (DAO treasuries, protocol treasuries, operational wallets). Professional treasury operations such as OTC desks, market-making, or custody-as-a-service may warrant additional or differentiated baselines beyond this scope.
Related: Custody platform account management (phishing-resistant MFA, credential management, recovery methods, account lifecycle) is governed by SFC - Identity & Accounts. Treasury-specific controls below focus on transaction security and platform configuration.
For more details on certifications or self-assessments, refer to the Certification Guidelines.
Section 1: Governance & Treasury Architecture
- Accountability scope covers policy upkeep, security reviews, operational hygiene, access control oversight, and incident escalation
- Registry includes wallet/account address, network/chain, custody provider, custody model, purpose/classification, authorized signers/approvers, controlled contracts or protocols, and last review date
- Updated within 24 hours for security-critical changes (signer changes, new wallets), 3 days for routine changes
- Accessible to authorized treasury personnel
- Custody model documented for each wallet/account (custodial, self-custody, co-managed, MPC, multisig, HSM)
- Technology trade-offs understood by the team (not necessarily a formal document — could be a brief internal memo)
- Custody architecture reviewed when treasury size, operational needs, or risk profile changes significantly
- Covers wallet setups, custody configurations, signer/approver permission changes, and protocol integrations
- Changes require documented approval before implementation
- All changes logged with justification and approver
- Changes reflected in the treasury registry within defined timeframes
- Rollback procedures documented for critical changes
Section 2: Risk Classification & Fund Allocation
- Classification considers financial exposure, operational dependency, and regulatory impact
- Example impact scheme: Low <1%, Medium 1-10%, High 10-25%, Critical >25% of total assets (organizations may define their own buckets)
- Operational types defined based on transaction frequency and urgency requirements
- Each classification maps to specific controls including approval thresholds, MFA requirements, whitelist delays, and monitoring levels
- Classification reviewed on a defined cadence and when treasury conditions change materially
- Organization-defined concentration limits per wallet, per custody provider, and per chain
- Rebalancing triggers documented (e.g., when a wallet exceeds its allocation ceiling or falls below operational minimums)
- Allocation limits reviewed periodically and after significant treasury changes
- Maximum value movable by a single person defined and enforced
- Maximum value movable by any automated path (API key, bot, integration) defined and enforced
- Limits scale with wallet/account classification
- Exceeding limits requires elevated approval or quorum
Section 3: Access Control & Platform Security
- Transaction policy rules configured: multi-approval workflows, approval thresholds scaled to transaction value, address whitelisting with cooling-off periods, velocity/spending limits
- Hardware security key MFA required for all approvers on High and Critical accounts
- Session timeouts reviewed and configured appropriately for sensitive operations
- Network restrictions where supported: IP allowlisting, VPN for admin access
- Separation of duties enforced: initiators cannot approve their own transactions, admins cannot unilaterally execute withdrawals
- Platform configurations documented and reviewed at least quarterly
- Covers API keys, service accounts, and signing keys
- Credentials stored in dedicated secret management systems, not in code, documents, or shared drives
- Hardware security key MFA required for accessing or authorizing privileged credentials
- Credential rotation schedule defined and enforced
- Access to credentials logged and monitored
- Access reviews conducted at least quarterly for High/Critical accounts, annually for others
- Reviews verify each user still requires their current access level
- Access promptly revoked when personnel change roles or leave
- Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock
- Signing devices (hardware wallets) securely stored when not in use
- Backup materials (seed phrases, recovery keys) stored securely with geographic distribution
- VPN mandatory for all remote treasury platform access
- Travel security procedures for personnel with signing or custody access capabilities
- Mobile devices used as second factors have endpoint security monitoring
- No single root user holds all control; where a root account exists, its use is minimized and audited
- Privileged actions (root account use, owner/admin operations) require quorum approval where the platform supports it
- Owner and admin credentials isolated from day-to-day operational access
- Hardware security key MFA required for all privileged access
- Privileged-access events logged, alerted on, and reviewed
Section 4: Transaction Security
- Pre-execution verification covers recipient address (validated through multiple independent sources, never copied from email/chat/history), amount, network, and simulation
- Calldata decoded and simulated via a trusted tool; for high-value operations, results verified against an independent decoder or simulator
- Test transactions required before sending to new addresses
- Multi-party confirmation required for high-value transfers, including video call verification with liveness checks at organization-defined thresholds and read-aloud parameter confirmation
- Specific procedures for large incoming transfers and OTC transactions where applicable
- Knowledge covers transaction verification, address validation, social engineering awareness, emergency procedures, and custody-platform-specific workflows
- Competence demonstrated before authorization (e.g., verifying a test transaction end-to-end)
- Knowledge refreshed annually and within 30 days of significant procedure changes
- Dedicated primary and backup channels on different platforms
- End-to-end encryption, MFA required, invitation-based membership
- Identity verified as standard procedure during signing/approval operations (e.g., code phrases, video call, secondary authenticated channel)
- Anti-social-engineering protocols: established verification procedures for address changes or unusual requests
- Documented procedures for channel compromise including switching to backup channels and out-of-band verification
- All treasury personnel trained on these procedures; compromise response tested annually
Section 5: Protocol Deployments
- Due diligence process for protocols before deployment (e.g., audit status, team reputation, operational history)
- Exposure limits defined at organization-chosen granularity (protocol, chain, category) and reviewed periodically
- Risk re-evaluation triggered by security incidents, major governance proposals, or newly disclosed vulnerabilities
- Entry procedures: smart contract address verification against multiple independent sources, token approval management (minimal approvals, revocation after use)
- Emergency withdrawal/exit procedures documented for all active positions
- Alternative access methods documented in case primary UIs are unavailable (direct contract interaction, CLI tools, alternative frontends)
- Unbonding/unstaking timelines understood and factored into liquidity planning
Section 6: Monitoring & Incident Response
- Monitoring scope covers transaction activity, account state, custody platform and vendor health, and (where applicable) deployed protocol positions and compliance screening
- External threat intelligence ingested for relevant ecosystem incidents and vendor advisories
- Alerting with defined severity levels and escalation paths; critical alerts trigger immediate investigation
- Monitoring system integrity protected — alerts triggered when monitoring is altered, disabled, or degraded
- Severity levels defined with escalation paths specific to treasury operations
- Containment playbook covering fund protection actions (emergency freeze, transfer to cold storage, policy lockdown) and key scenarios (platform compromise, unauthorized transaction, signer key compromise, vendor breach)
- Emergency contacts pre-documented (custody provider security, SEAL 911, legal counsel) and stakeholder communication plan
- Drills annually and after major procedure changes; documented with date, participants, response times, issues, and improvements
Section 7: Vendor & Infrastructure
- Initial due diligence before adoption: security certifications (SOC 2, ISO 27001), audit history, insurance coverage, incident history
- Ongoing monitoring: SOC report currency, security incident notifications, service availability tracking
- Contractual security requirements verified periodically (at least annually)
- Critical vendor changes (ownership, infrastructure, security posture) trigger re-evaluation
- Alternate access methods for custody platforms documented and tested (e.g., API access, mobile app, secondary UI)
- Backup RPC providers configured
- Procedures for operating treasury if primary custody platform is unavailable
- Backup infrastructure tested at least annually
Section 8: Accounting & Reporting
- All treasury transactions recorded with categorization, documentation, and authorization chain
- Periodic reconciliation between custody platform records, on-chain balances, and accounting records
- Reconciliation frequency scaled to account classification: daily for Active Operations, weekly for Warm Storage, monthly for Cold Vault
- Discrepancies investigated and resolved promptly
- Treasury reporting procedures documented with defined cadence and audience
- Coverage scope documented: what's covered (custody theft, hack, insider fraud) and what's excluded
- Coverage amounts appropriate relative to assets held
- Custody provider's insurance evaluated as part of vendor due diligence
- Insurance coverage reviewed at least annually or when treasury size changes significantly