Open Standard
DARC
Control
Standard
The standard for operational trust in digital asset systems. DARC defines how protocols operate in practice — evaluating the controls, processes, and infrastructure that determine real-world reliability, beyond your codebase.
The existing audit landscape assesses code, not operations. Key management, multisig controls, infrastructure access, and incident response remain largely unassessed.
There is no standard for operational maturity. As a result, due diligence is inconsistent, institutional capital faces friction, and operational risk is difficult to compare.
A standardized, externally verifiable signal of operational maturity across two certification tiers. It allows protocols to:
- Demonstrate baseline operational discipline
- Differentiate from unaudited or under-managed systems
- Provide a consistent reference for investors and partners
A Clear Baseline
Core operational controls across:
- Multisig configuration and key management
- Infrastructure security and access control
- Governance setup and upgrade permissions
- Incident response and escalation procedures
- Baseline operational security practices
Assessment Process
- Scope definition across key operational domains
- Review of controls, processes, and configurations
- Identification of gaps and required improvements
- Certification upon meeting baseline requirements
Public Registry
Certified protocols are listed in the DARC Public Registry. Status, tier, and audit history are publicly available and verifiable on-chain.
Annual Recertification
Maintain certification through annual audits at a standardized, fractional cost.
Open Standard
Control Catalog
GV
DARC1
Foundational controls
GV-1.01
Named security owner
One person accountable for security posture.
GV-1.02
Security policy
Written in plain language, accessible to all personnel.
GV-1.03
Asset inventory
Wallets, keys, domains, accounts, devices: what exists and who owns it.
GV-1.04
Critical assets identified
Keys, wallets, admin accounts, and domains documented. Critical = asset whose compromise would result in fund loss, data breach, or service outage.
GV-1.05
Onboarding security acknowledgment
Security policy acknowledged before access is granted.
GV-1.06
Confidentiality agreements
NDAs for all personnel handling keys, funds, or sensitive code.
GV-1.07
Security responsibilities in contracts
Employment and contractor agreements include security responsibilities.
GV-1.08
Social engineering awareness
Personnel informed of industry-specific vectors: impersonation, fake job offers, malicious meeting links, urgent transfer requests. Verification procedure defined for unusual requests.
DARC2
+ Risk management and oversight
GV-2.01
Risk register maintained
Identified risks, likelihood, impact, and mitigations documented and maintained.
GV-2.02
Risk assessment reviewed after significant changes
Reviewed after new products, incidents, or market shifts.
GV-2.03
Formal data/system classification scheme
Critical, sensitive, and standard classifications with controls mapped per level.
GV-2.04
Security program KPIs
Performance measured on at least six KPIs: MTTD, MTTR, audit-finding time-to-close, training completion rate, drill completion and gap-closure rate, and signer-quorum reachability SLA attainment. Targets documented per KPI.
GV-2.05
Security policy reviewed annually
Reviewed annually and after significant changes.
GV-2.06
Regulatory awareness
Team knows which regulations apply and basic compliance status.
GV-2.07
Change management procedures
Procedures defined for security-relevant changes.
GV-2.08
Threat intelligence
Actively track threats relevant to your stack and ecosystem.
GV-2.09
Pre-established law enforcement contacts
Pre-established contacts with law enforcement and relevant regulators.
GV-2.10
Data breach prevention controls
For systems handling user data: minimize data collected, encrypt at rest and in transit, breach detection and notification procedures.
GV-2.11
Formal change advisory process
Formal change advisory process for security-relevant decisions.
GV-2.12
Domain-specific owners assigned
Named owners for each operational area (multisig ops, treasury ops, DevOps/infra, DNS/frontend). Accountability covers policy maintenance, reviews, and incident escalation.
KM
DARC1
Foundational controls
KM-1.01
Keys encrypted at rest
Never stored in plaintext, docs, or chat.
KM-1.02
Backup for all critical keys
Stored separately from the primary.
KM-1.03
Backup recovery tested
At least once per critical key/seed to confirm the backup is complete and usable.
KM-1.04
Backup media environmental protection
Protected against fire, water, and other environmental hazards.
KM-1.05
2FA on key systems
Required for all systems that store or provide access to key material (KMS, vaults, custodial platforms).
KM-1.06
No shared signing devices
No single device may hold two or more signing keys for the same multisig.
KM-1.07
Wallet and key registry
All keys, who holds them, what they control, which wallets, addresses, and chains. Canonical registry — MS and TM domains add domain-specific columns.
KM-1.08
Key Compromise Protocol
Written KCP exists: who to notify, immediate containment (move funds to new wallet), and escalation contacts. At least 2 team members can locate and execute it.
DARC2
+ Formal key lifecycle
KM-2.01
Documented key generation procedures
Isolated environment and verified software required for key generation.
KM-2.02
Geographic distribution of backups
Backups stored across geographically separate locations.
KM-2.03
Tamper-evident storage for key material
Key material stored in tamper-evident containers or media.
KM-2.04
Key rotation schedule defined and enforced
Rotation schedule documented and actively enforced for all key types.
KM-2.05
Documented KCP with procedures per key type
Specific procedures per key type, approved communication channels, and role-based actors with backups.
KM-2.06
Keyholder onboarding/offboarding checklists
Checklists with approved communication channels for transitions.
KM-2.07
Independent channel confirmation before signing
Before signing, each approver confirms the transaction through a channel independent of the request path.
KM-2.08
Background checks for keyholders
Scope scales with fund exposure: identity verification at minimum, criminal/financial checks for signers controlling >$1M equivalent.
MS
DARC1
Foundational controls
MS-1.01
Multisig required for all fund-controlling wallets
No single-signer for anything material.
MS-1.02
Minimum 3 signers, threshold ≥50%
For example 2-of-3 or 3-of-5. No N-of-N configurations.
MS-1.03
Signer details in key registry
Signer addresses, signer identity, and which multisig recorded in the KM wallet registry.
MS-1.04
Hardware wallet signing required
Every signature must originate from a hardware wallet or equivalent hardware-backed signing device for any multisig controlling funds or permissions. Browser extensions and mobile hot wallets are not acceptable. Testnet and ephemeral development multisigs are exempt.
MS-1.05
Signing hardware authenticity verified
Sourced only from the manufacturer or an explicitly authorized reseller. Authenticity-check procedure (firmware signature verification, tamper-evidence inspection) run on first use and outcome recorded.
MS-1.06
No key reuse across multisigs
Each signing role gets a fresh key bound to one multisig and used for no other purpose.
MS-1.07
Independent pre-sign verification
Each signer independently verifies destination address, transfer amount, and calldata against the transaction request before signing. Verification documented (screenshot, chat confirmation, or signing tool log).
MS-1.08
No single entity controls quorum
No single entity controls enough signing keys to meet the approval threshold.
DARC2
+ Operational multisig maturity
MS-2.01
Multisig classification by risk level
Classification by impact and criticality with proportional controls.
MS-2.02
Signer verification
Message signing proof of address ownership required for all signers.
MS-2.03
Signer training and assessment
Completed before authorization, covering on-chain transaction verification, the emergency runbook, and crypto-specific phishing/social-engineering tactics.
MS-2.04
Written transaction lifecycle handbook
Covers: drafting and intent approval, pre-signing simulation, signature collection, broadcast confirmation, and post-execution audit-log entry.
MS-2.05
Transaction hash verified across 2+ independent interfaces
Different providers or independently hosted infrastructure required.
MS-2.06
High-risk transaction classification
Transactions that can execute arbitrary code (EVM DELEGATECALL to non-allowlisted targets, proxy upgrades to unreviewed implementations) classified as high-risk and trigger the MS-2.07 approval pathway.
MS-2.07
High-risk transaction thresholds defined
Elevated approval required, waiting periods required; exceptions documented with justification.
MS-2.08
Private mempool for sensitive operations
High-value or sensitive transactions submitted through a private mempool or equivalent private-submission path to reduce frontrunning and MEV exposure.
MS-2.09
Emergency playbooks
Playbooks for key compromise, lost access, and urgent actions.
MS-2.10
Emergency-contact roster
Covers every signer and stakeholder. Each signer has a backup contact. Refreshed every six months and after any role change affecting signer reachability.
MS-2.11
Secure communication channels
E2E encrypted channels, identity verification during signing, documented procedures for channel compromise.
MS-2.12
Signer removal timelines per risk level
Higher risk requires faster removal. Quarterly check that each named signer can independently sign.
MS-2.13
Isolated devices for high-value signing
High-value signing operations performed on isolated devices or networks separate from daily-use systems.
MS-2.14
Signer reachability within 12 hours
Quorum reachable within 12 hours for routine operations.
MS-2.15
Continuous multisig monitoring
Alerts on: low signer balance, unknown counterparty, nonce discontinuity, module/guard changes, threshold transfers, owner set reconfiguration, and failed transactions.
MS-2.16
Multisig transaction audit trails retained 1+ year
All multisig transaction records retained for at least one year.
AC
DARC1
Foundational controls
AC-1.01
MFA on all organizational accounts
No exceptions. SMS-based MFA not acceptable as the sole second factor for accounts with access to funds, keys, or admin systems — TOTP or hardware keys required.
AC-1.02
Password manager required
Every person with organizational account access stores credentials in an approved password manager. Plaintext passwords in documents, chat, email, or browser auto-fill are prohibited.
AC-1.03
Unique strong passwords per account
No password reuse across accounts.
AC-1.04
Individual accounts only
No shared personal credentials.
AC-1.05
Departing personnel access removed within one day
Access to every organizational system removed within one day of the effective separation date.
AC-1.06
Onboarding security acknowledgment
Security policy acknowledged before access is granted (per GV domain).
AC-1.07
Credentials never shared via email or chat
Use password manager sharing or an encrypted channel.
AC-1.08
Full disk encryption on all devices
All organizational devices must have full disk encryption enabled.
AC-1.09
Auto-lock on all devices
All organizational devices must auto-lock after a defined idle period.
AC-1.10
Automated OS and security patching
Applied automatically on all organizational devices with a documented patch-latency SLA.
AC-1.11
No public/shared Wi-Fi for sensitive systems
Key management, custody, and admin systems must not be accessed on public or shared Wi-Fi.
AC-1.12
Screen lock in shared spaces
Screen lock and privacy measures required when working in shared spaces.
AC-1.13
Browser extension restrictions on signing devices
Unapproved browser extensions prohibited on devices used for signing or accessing custody platforms. Minimal approved-extension list maintained.
AC-1.14
Remote-wipe capability on all devices
Every organizational device has working remote-wipe via native OS account-tied capability or equivalent. Verified at provisioning and must remain enabled.
AC-1.15
Lost/stolen device runbook
Written runbook covering: who gets paged first, triggering the remote wipe, rotating any credentials on the device, and escalating per the IR playbook.
DARC2
+ Formalized access management
AC-2.01
Hardware security key for sensitive accounts
Every account reaching funds, keys, cloud admin consoles, or production infra must use FIDO2/WebAuthn hardware security key. TOTP is insufficient for these accounts.
AC-2.02
Phishing-resistant MFA preferred everywhere
Phishing-resistant MFA deployed as the default across all organizational accounts.
AC-2.03
Account lifecycle procedures
Documented approval required for account creation, modification, and revocation.
AC-2.04
Least privilege enforced
Each role gets minimum necessary access.
AC-2.05
Regular access reviews
Critical systems reviewed every six months; other systems annually. Review records include reviewer, date, and each change made.
AC-2.06
Service accounts and API key inventory
All service accounts and API keys tracked with a named responsible owner per credential.
AC-2.07
Credential rotation schedule
Rotation schedule defined; immediate rotation on suspected compromise.
AC-2.08
Software and tool evaluation before adoption
Evaluation required for all tools including AI tools and browser extensions.
AC-2.09
Security awareness training twice per year
At least one live phishing simulation per cycle. Curriculum covers crypto-specific vectors: recruiting-pretext scams, wallet-drainer extensions, clipboard-swap malware, and impersonation attacks.
AC-2.10
Insider threat assessment
Damage scenarios documented per role.
AC-2.11
Separation of duties for sensitive actions
No single person both initiates and approves a funds-moving, key-touching, or privileged-infrastructure action.
AC-2.12
Malware protection on all devices
Antivirus, EDR, or equivalent deployed. Must cover crypto-specific threats: clipboard hijackers and malicious wallet extensions.
AC-2.13
Remote work policy formalized
VPN for sensitive systems, approved devices, and home network requirements.
AC-2.14
BYOD policy
Specifies which resources a personal device may reach and required baseline controls: full-disk encryption, auto-lock, automatic patching, remote-wipe capability, and documented personal/work data separation.
AC-2.15
Device security baseline confirmed before access
Disk encryption, auto-lock, patching, and remote-wipe confirmed before granting access and rechecked at a defined cadence.
AC-2.16
Documented onboarding checklist
Identity verification, device provisioning, MFA setup, security training, policy acknowledgment. Consistently applied.
AC-2.17
Offboarding checklist
Covers device return/sanitization, account disabling, shared credential revocation, secret rotation, physical item retrieval, and confirmation no active session remains.
AC-2.18
Involuntary termination access cut-off
Access cut at moment of notification or earlier. Only exception: legal requirement to notify first (in writing); access cut within one hour of notification.
AC-2.19
Account recovery points to org-controlled infrastructure
Password-reset and recovery options on every org account point only to infrastructure the organization controls. Personal email, employee phone numbers, and SMS recovery are prohibited.
AC-2.20
SaaS platform hardening baselines published
Baselines for email/calendar, team-chat, and source-control platforms specifying MFA posture, session duration, sharing defaults, and audit-log retention. Deployments checked against baseline.
AC-2.21
Travel protocol for signers
Travel-specific device with no persistent key material, no connection to org systems from untrusted networks without VPN, and scheduled check-in cadence with another signer during travel.
SD
DARC1
Foundational controls
SD-1.01
Branch protection on main/production
Require reviews before merge.
SD-1.02
Signed commits on main/production branches
Commit signing required on all protected branches.
SD-1.03
Automated secret scanning on all repositories
Continuous scanning for accidentally committed secrets.
SD-1.04
Pre-commit hooks for secret patterns
Developer workstations run git hooks that reject commits containing matches to the secret-scanning patterns.
SD-1.05
Dependency scanning for known vulnerabilities
Automated scanning of all dependencies against known CVEs.
SD-1.06
Dependencies from official sources, version pinned
All dependencies sourced from official registries with pinned versions.
SD-1.07
Secrets not in source code
Use a secrets management system or environment variables. Env vars must not be committed to version control and must be restricted to the runtime environment.
SD-1.08
Dev/staging isolated from production credentials
Dev and staging environments have no path to the credentials that grant production access.
SD-1.09
Cloud accounts secured with MFA
AWS, GCP, Vercel, and similar accounts secured with MFA. No root/owner key in daily use.
DARC2
+ Secure pipeline and infrastructure
SD-2.01
Two-reviewer approval for protected branches
No merge to a protected branch without approval from at least two reviewers who did not author the change.
SD-2.02
External contributor PRs don't auto-trigger CI/CD
CI/CD pipelines require manual approval before running on external contributor pull requests.
SD-2.03
SAST integrated in CI/CD pipeline
Static application security testing runs on every build.
SD-2.04
Repository sandboxing
Each repository runs in its own sandbox with no shared state. Privileged work (wallet signing, cloud admin) performed from a separate OS account with no overlap with the development account.
SD-2.05
CI/CD config changes require multi-reviewer approval
Changes to pipeline definitions, runners, triggers, and deployment targets treated as protected-branch merges.
SD-2.06
CI/CD runners have no persistent production secrets
Runners do not hold persistent access to production secrets between runs.
SD-2.07
Dedicated secrets management system
Not plaintext environment variables — a proper secrets management system required.
SD-2.08
No direct read access to production secrets
No human workflow grants direct read access to production secret values. Any retrieval goes through an audited break-glass process.
SD-2.09
Deterministic builds with strict dependency sets
Builds are reproducible and use locked, strict dependency sets.
SD-2.10
Dependency changelogs reviewed before updates
Changelogs reviewed and approved before any dependency update goes to production.
SD-2.11
Testing and validation in staging before production
All changes validated in staging environment before production deployment.
SD-2.12
Tool approval process
Approval required for IDEs, extensions, and AI assistants before adoption.
SD-2.13
Secure configuration baselines documented
Baselines documented for cloud infra, servers, and CI/CD — reviewed for drift.
SD-2.14
Cloud security hardening
IAM least privilege, logging enabled (CloudTrail/equivalent), no public-facing storage buckets.
SD-2.15
Disaster recovery procedures documented
Basic disaster recovery procedures with defined RTO/RPO for critical systems.
SC
DARC1
Foundational controls
SC-1.01
External smart contract audit before mainnet
At least one audit by a recognized firm. Organization documents the criteria used to qualify a firm as recognized.
SC-1.02
Audit report available
Publicly available or available to certification auditor.
SC-1.03
Critical/high findings addressed before deployment
All critical and high severity audit findings resolved prior to mainnet deployment.
SC-1.04
Deployed contracts verified and source published
Source code published on Etherscan or equivalent block explorer.
SC-1.05
Deployed bytecode matches audited source
Verified by reproducing compilation with documented compiler version, optimization settings, and EVM target. Compilation parameters recorded as audit artifacts.
SC-1.06
Privileged functions documented
Admin, owner, and upgrader functions documented with access control details.
SC-1.07
Deployment procedures documented
Basic deployment procedures documented covering who deploys, how, and what checks are performed.
DARC2
+ Governed deployments
SC-2.01
Multiple independent audits
At least 2 independent external audits for core contracts, at least 3 for contracts managing >$100M.
SC-2.02
Timelock on privileged operations
Timelock on all privileged operations except designated emergency functions (pause, freeze, circuit breakers). Emergency functions require multisig authorization and post-execution review.
SC-2.03
Pause mechanism implemented and tested
Pause mechanism implemented and tested for all critical contracts.
SC-2.04
Upgrade governance documented
Who can upgrade, approval process, and timelock duration documented.
SC-2.05
Deployment pipeline: testnet → staging → mainnet
Simulation required at each step before advancing.
SC-2.06
Re-audit on major upgrades
Re-audit triggered on major upgrades or new core contract deployments.
SC-2.07
Fast-track procedure for critical security patches
Defined fast-track deployment procedure with maximum deployment SLA for critical security patches.
SC-2.08
Bug bounty program active
Rewards tiered by severity with a published reward table and minimums per severity level.
SC-2.09
Remediation tracking
All audit findings tracked to resolution.
SC-2.10
Designated emergency on-chain authority
Designated person or council authorized to execute emergency on-chain actions (pause, freeze).
SC-2.11
On-chain token governance controls
For protocols with on-chain token governance: minimum proposal review period defined, quorum thresholds documented, monitoring for abnormal voting patterns.
IM
DARC1
Foundational controls
IM-1.01
Named person responsible for security incidents
One individual accountable for incident response.
IM-1.02
Emergency contact list
Internal team, external security resources (ecosystem emergency response services, forensics firms), maintained and accessible. Canonical list — MS extends with signer contacts.
IM-1.03
Written incident response document
Covers: (a) first contact person, (b) incident communication channel, (c) three immediate actions — contain, assess scope, notify. Accessible to all team members.
IM-1.04
Incident reporting channel known to all
All team members know the incident reporting channel.
IM-1.05
Audit logs for key systems
At minimum: auth events, transactions, and deployments.
DARC2
+ Formal response capability
IM-2.01
Incident response team with defined roles
Commander, technical, comms, and legal roles defined.
IM-2.02
Response playbooks for key scenarios
Playbooks for: exploit, key compromise, infra failure, DNS hijack, and supply chain incidents.
IM-2.03
Incident classification taxonomy
Defined severity levels for classifying incidents.
IM-2.04
Escalation paths by severity level
Clear escalation paths defined per severity classification.
IM-2.05
Signer reachability integrated with IR
Incident response can execute emergency on-chain actions within the required SLA.
IM-2.06
24/7 monitoring with alerting and paging
Redundant paging systems, auto-escalation on non-acknowledgment, and management notification for high-severity incidents.
IM-2.07
Tamper-evident logging with 1+ year retention
Logs protected against tampering with defined retention of at least one year.
IM-2.08
Security event on monitoring changes
Security event triggered when monitoring is silenced, disabled, or reconfigured, and when logs are modified, truncated, or removed.
IM-2.09
IR channels on two independent platforms
Working fallback if primary is compromised. Keys, victim PII, and unpublished vuln details stay on end-to-end encrypted paths only.
IM-2.10
Post-incident reviews conducted and documented
Reviews conducted after every incident with documented findings.
IM-2.11
Stakeholder status update procedures
Defined procedures for communicating status to stakeholders during active incidents.
IM-2.12
Evidence collection procedures
How to preserve logs, on-chain data, screenshots, and comms for forensics and potential legal action.
IM-2.13
Annual incident response drills
Annual drills conducted and results documented.
IM-2.14
Cross-protocol coordination contacts
Contacts established with ecosystem emergency response services, partner protocols, and infrastructure vendor support. Reviewed quarterly.
TM
DARC1
Foundational controls
TM-1.01
Treasury wallets use multisig
Follows MS domain requirements.
TM-1.02
Company funds segregated from user/client funds
Organizational treasury kept separate from any user or client holdings.
TM-1.03
Treasury details in key registry
Address, purpose, chain, and custody model recorded in KM wallet registry.
TM-1.04
Test transfer to new addresses
A small test transfer to any newly-added destination confirms address correctness before the full-value transaction is sent.
TM-1.05
Address verified from multiple sources
Never from email, chat, or transaction history alone.
TM-1.06
Basic spending policies
Who can initiate and approval thresholds for different transfer amounts.
TM-1.07
Treasury transactions recorded
All treasury transactions recorded with basic categorization.
DARC2
+ Custody architecture and controls
TM-2.01
Recorded custody arrangement per wallet
Every treasury wallet or account has a recorded custody arrangement — who holds signing material, which party can initiate movement, and the technical mechanism used.
TM-2.02
Treasury wallet classification by loss-impact
At minimum four bands: negligible (<0.5%), moderate (0.5–5%), substantial (5–20%), catastrophic (>20%). Controls scaled per class.
TM-2.03
Value caps per wallet, chain, and provider
Caps on value held in any single wallet, chain, or custody provider. Breaches require an approved exception before the position is held.
TM-2.04
Custody platform security configuration
Where supported: separation of initiator/approver, per-day and per-transaction caps, re-auth on privileged ops, IP allowlisting, and destination-address allowlisting with waiting period. Configuration re-validated quarterly.
TM-2.05
Transaction verification: simulation + multi-party confirmation
Required for large transfers before execution.
TM-2.06
Synchronous call for high-value transfers
Transfers above high-value threshold require a call between requester and at least one approver. Call confirms identity and reads destination address aloud for verification.
TM-2.07
Documented inbound receive-flow for large transfers
Fresh destination address generated, round-trip test transfer performed, and sender identity re-verified on a separate channel. OTC trades have their own counterparty-onboarding flow.
TM-2.08
Treasury signer competency requirements
Anyone with treasury signing or approval authority must demonstrate competence in: on-chain verification, address validation, recognizing social engineering, and the specific custody platform workflow. Refreshed annually and within 30 days of material workflow changes.
TM-2.09
Credential and secret management for treasury systems
Not in code; rotated on schedule.
TM-2.10
Quarterly access reviews for treasury systems
Access to treasury systems reviewed at least quarterly.
TM-2.11
Protocol deployment due diligence
Audit status, TVL, and history reviewed before committing funds to any protocol.
TM-2.12
Vendor security evaluation for custody providers
SOC 2, incident history, and insurance evaluated for all custody providers.
TM-2.13
Reconciliation at defined frequency
On-chain balances reconciled against internal records per account classification. Discrepancies trigger investigation.
TM-2.14
Treasury infrastructure change tracking
Changes to wallets, access policies, platform integrations, and signer rosters go through a tracked change record. Each critical change has a pre-written rollback runbook.
TM-2.15
Treasury disbursement limits with timelock
Timelock enforced for amounts exceeding defined thresholds.
TM-2.16
Monitoring for unusual treasury outflows
Active monitoring with alerts on anomalous outflow patterns.
TM-2.17
Extended treasury monitoring
Includes: new device enrollments and auth anomalies on custody platforms, vendor/platform service availability, and monitoring system integrity.
CM
DARC1
Foundational controls
CM-1.01
Monitor all treasury/multisig wallets
Alert on unexpected transactions across all fund-holding wallets.
CM-1.02
Alerting on large transfers
Alerts triggered for transfers above defined thresholds.
CM-1.03
Alerting on signer/threshold changes
Alerts on any change to the multisig owner set or approval threshold.
CM-1.04
Named reviewer with defined cadence
Named individual assigned to review alerts. If critical alerts go unreviewed, a second person is notified.
CM-1.05
At least one monitoring tool in use
Active monitoring service or tool deployed for on-chain activity.
DARC2
+ Proactive detection
CM-2.01
Smart contract monitoring
Monitor for unexpected interactions, parameter changes, and failed transactions.
CM-2.02
Credential-leak surveillance
Covering breach corpora, paste sites, public code repositories, and dark-web marketplaces.
CM-2.03
Organizational account monitoring
Monitor social media accounts and domains for unauthorized access.
CM-2.04
Alert priority tiers with named responders
Every alert assigned a priority tier; each tier defines a named responder and escalation trigger if not acknowledged within the tier's SLA.
CM-2.05
On-call schedule with coverage
On-call schedule maintained with coverage for operational needs.
CM-2.06
Alert triage procedures
Defined procedures to distinguish real incidents from false positives.
CM-2.07
Monitoring coverage documented
Covered systems and signals, known detection gaps, and deferred coverage with justification documented.
CM-2.08
Monitoring integrated with incident response
Monitoring alerts feed directly into the incident response workflow.
CM-2.09
Protocol health signal monitoring
For protocols with lending, staking, or liquidity pools: continuous monitoring of TVL, collateralization ratios, liquidation-trigger distances, and yield-source anomalies.
CM-2.10
DeFi-specific attack pattern monitoring
Monitoring for flash-loan-enabled exploits, governance manipulation, sudden liquidation cascades, and anomalous protocol interactions.
SY
DARC1
Foundational controls
SY-1.01
Inventory of critical external dependencies
RPC providers, oracles, bridges, indexers, and hosting documented.
SY-1.02
Dependencies from official sources only
npm, PyPI, crates.io — not forks, not random URLs.
SY-1.03
Version pinning for all dependencies
Lockfiles committed to version control.
SY-1.04
Automated dependency vulnerability scanning in CI/CD
All dependencies scanned for known CVEs on every build.
SY-1.05
No unversioned external resources in build/deploy
No build or deploy step pulls unversioned external resources.
SY-1.06
Cross-chain bridge risk assessment
For any protocol using bridges: validator set size, upgrade authority, incident history, and maximum exposure limits documented. Conditional — only if using bridges.
DARC2
+ Verified and managed supply chain
SY-2.01
Vendor risk assessment for critical providers
Assessment required for all critical infrastructure providers: RPC, oracle, custody, and hosting.
SY-2.02
Oracle architecture documented
Including redundancy approach for price-critical operations. Oracle design covered in audit scope.
SY-2.03
Oracle configuration documented
Update frequency, deviation thresholds, and stale price handling documented. Covered in audit scope.
SY-2.04
Oracle failure scenarios for liquidation protocols
Failure scenarios and circuit breaker requirements documented and covered in audit scope. Conditional: only if protocol has liquidation mechanics.
SY-2.05
RPC provider redundancy
At least 2 independent RPC providers for production.
SY-2.06
Dependency changelogs reviewed before every production update
Changelogs reviewed and approved before every dependency update to production.
SY-2.07
Typosquatting checks before new packages
Checks performed before installing any new package.
SY-2.08
SBOM maintained for production systems
Software Bill of Materials maintained and kept current.
SY-2.09
Human supply chain identity verification
Identity verification required for anyone with access to keys, funds, infrastructure, or production systems. Code-only contributors may work pseudonymously if all contributions go through documented review.
SY-2.10
Third-party code evaluated for data exfiltration risk
Analytics, widgets, and SDKs evaluated before inclusion.
SY-2.11
Bridge exposure limits and emergency exit plans
Exposure limits defined, monitoring for bridge anomalies, and emergency position exit plans. Conditional: only if using bridges.
SY-2.12
Wallet connector and frontend SDK versions pinned
Versions pinned and reviewed before update. Conditional: only if deploying frontends.
SY-2.13
Supplier security incidents trigger re-evaluation
Any supplier security incident triggers re-evaluation of the relationship and controls.
SY-2.14
Frontend build integrity
Hash of CI build output matches hash of deployed artifact on CDN. Runtime monitoring covered separately in FD domain.
FD
DARC1
Foundational controls
FD-1.01
Domain inventory
All domains, registrars, expiration dates, and purpose documented.
FD-1.02
MFA on registrar and DNS accounts
Every account that can change registrar settings, DNS records, or zone configuration protected with MFA per AC-1.01, with SMS excluded as the second factor.
FD-1.03
Auto-renewal enabled on all domains
Funded by a payment method valid through the next renewal cycle, with a reminder set before card expiration.
FD-1.04
Payment methods current, backup renewal owner
Payment methods verified current with a named backup person for domain renewal.
FD-1.05
Email authentication (SPF, DKIM, DMARC)
Outbound email authenticated end-to-end: SPF enumerates legitimate senders, DKIM signs every message, and DMARC enforces alignment reaching p=reject after a monitoring period. Domains not used to send email publish null SPF plus p=reject DMARC.
FD-1.06
TLS certificate expiration tracking
Every certificate enrolled in an expiration-tracking system that alerts at least 30 days before expiry, with a named owner per certificate.
DARC2
+ Hardened and monitored
FD-2.01
DNSSEC enabled on all primary domains
DNSSEC enabled and maintained on all primary organizational domains.
FD-2.02
CAA records restricting certificate issuance
CAA record published on every domain restricting TLS issuance to specific CAs in use, with an iodef reporting address for abuse notifications.
FD-2.03
Hardware security key on registrar accounts
Critical domain registrar accounts protected by FIDO2/WebAuthn hardware key and enterprise-tier registrar with multiple named accounts, audit logs, and role separation.
FD-2.04
Registry lock on critical domains
Server-side registry lock (EPP clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited) applied, with a documented out-of-band unlock procedure.
FD-2.05
Transfer locks on all domains
Transfer locks enabled on all organizational domains.
FD-2.06
Security-event reporting mailbox on separate DNS zone
Domain security reporting directed to a mailbox on a different DNS zone than the domains being protected.
FD-2.07
Change-control process for DNS and registrar changes
Domain transfers, deletions, nameserver changes, and production record changes require second-reviewer approval, team notification, auditable log entry, and registrar-side confirmation via a second channel.
FD-2.08
Documented TTL strategy per DNS zone
Baseline TTL values per record type, rationale, and emergency-lowering procedure documented.
FD-2.09
Continuous DNS zone monitoring
Monitors for: delegation and authority changes, resource-record changes, CAA record changes, and email-authentication changes. Alerts routed with timestamp and diff against known-good zone file.
FD-2.10
Certificate Transparency log monitoring
CT logs continuously watched for every organizational domain. New certificates generate alerts; wildcard certificates flagged specifically.
FD-2.11
Content Security Policy headers on all frontends
CSP headers deployed and maintained on all frontend properties.
FD-2.12
Subresource Integrity for externally loaded scripts
SRI required for all externally loaded scripts on pages where users sign transactions or access custody. Auto-updating third-party scripts must not load on signing/custody pages.
FD-2.13
MTA-STS policy published
MTA-STS policy published for all organizational sending domains.
FD-2.14
Domain classification by risk level
Domains classified by risk level with proportional controls applied per class.
FD-2.15
Automated TLS certificate renewal
ACME or equivalent. Manual renewal only where not supported — exception documented.
FD-2.16
User-warning procedure for frontend/DNS compromise
Team can publish a warning within minutes through at least two channels independent of the compromised domain. Publishing credentials accessible during incidents from systems independent of the frontend.
PS
DARC1
Foundational controls
PS-1.01
Hardware wallets and signing devices secured
Stored in locked safe/cabinet when not in use.
PS-1.02
Clear desk policy
No seed phrases, passwords, or sensitive material left visible.
PS-1.03
Visitor policy for sensitive workspaces
Policy in place for any workspace where key material or signing operations occur.
PS-1.04
Security-critical hardware procurement provenance
Servers, HSMs, and signing devices procured directly from the manufacturer or an explicitly authorized reseller. Procurement provenance recorded.
DARC2
+ Controlled physical access
PS-2.01
Physical security perimeters defined
Perimeters defined for areas where signing, key storage, or sensitive operations occur.
PS-2.02
Access control for secure areas
Badge, key, biometric, or combination. Access logged.
PS-2.03
Physical security monitoring
Cameras or equivalent monitoring for all secure areas.
PS-2.04
Equipment siting and protection
Servers, HSMs, and signing stations positioned to prevent unauthorized access and environmental damage.
PS-2.05
Environmental protections for key infrastructure
Fire suppression, flood protection, and climate control for facilities housing key material or infrastructure.
PS-2.06
Secure areas for key ceremonies
Designated secure areas with documented access procedures for key ceremonies.
PS-2.07
Working-in-secure-areas procedures
No unauthorized devices, no photography, and escorted visitors required in secure areas.