The DARC Standard

DARC-18

• GV-1.01Named security owner
• GV-1.02Written security policy in plain language, accessible to personnel
• GV-1.03Critical assets identified with the three-part test
• GV-1.04Security-policy acknowledgment step in onboarding
• GV-1.05NDA for personnel
• GV-1.06Security responsibilities in employment and contractor contracts
• GV-1.07Verification runbook for unusual requests
• GV-1.08Social-engineering awareness trainingComing soon

DARC-210

• GV-2.01Risk register with likelihood, impact, and mitigationsComing soon
• GV-2.02Risk assessment reviewed after significant changesComing soon
• GV-2.03Data and system classification scheme with mapped controlsComing soon
• GV-2.04Security program KPIs, at least six, with documented targetsComing soon
• GV-2.05Annual security policy review and review on significant changeComing soon
• GV-2.06Regulatory awareness, applicable regulations identifiedComing soon
• GV-2.07Change management, formal advisory step plus emergency pathComing soon
• GV-2.08Active threat intelligence relevant to stack and ecosystemComing soon
• GV-2.09Data-breach prevention controls on user-data systemsComing soon
• GV-2.10Domain-specific owners for each operational areaComing soon

DARC-16

• KM-1.01Every key and seed is stored encrypted
• KM-1.02Every critical key has a backup that fails independently
• KM-1.03Backup recovery tested offline for each critical key
• KM-1.04Backup media protected against environmental hazards
• KM-1.05Device and provenance recorded for every key
• KM-1.06Key compromise runbook (KCP)

DARC-28

• KM-2.01Documented key-generation procedures (isolated environment, verified software)Coming soon
• KM-2.02Geographic distribution of key backupsComing soon
• KM-2.03Tamper-evident storage for key materialComing soon
• KM-2.04Key rotation schedule with explicit trigger eventsComing soon
• KM-2.05Key Compromise Protocol with per-type procedures and role-based actorsComing soon
• KM-2.06Keyholder onboarding and offboarding checklists with approved channelsComing soon
• KM-2.07Independent confirmation per approver before signingComing soon
• KM-2.08Background checks for keyholders, proportional to exposureComing soon

DARC-19

• MS-1.01Multisig on every wallet that controls funds or permissions
• MS-1.02Multisigs no single key can drain or freeze
• MS-1.03Hardware-wallet signing for every multisig controlling funds or permissions
• MS-1.04Signing hardware sourced from the manufacturer or an authorized reseller
• MS-1.05One signing key per multisig, no reuse across multisigs
• MS-1.06Independent transaction verification by every signerComing soon
• MS-1.07Signers distributed so no single party meets the threshold
• MS-1.08Signing devices with a full display, clear signing, local unlock and verifiable firmware
• MS-1.09Manufacturer authenticity check before a device signs in production

DARC-216

• MS-2.01Multisig risk classification with proportional controlsComing soon
• MS-2.02Signer verification via message-signing proof of address ownershipComing soon
• MS-2.03Signer training and assessment program with annual refreshComing soon
• MS-2.04End-to-end signed-transaction handbook with five checkpointsComing soon
• MS-2.05Transaction hash verified across two independent interfacesComing soon
• MS-2.06Arbitrary-code-execution transactions classified as high-riskComing soon
• MS-2.07High-risk approval pathway, elevated approval and waiting periodsComing soon
• MS-2.08Private-mempool submission for high-value or sensitive operationsComing soon
• MS-2.09Written emergency procedures reachable through a secondary channelComing soon
• MS-2.10Emergency-contact roster with backup contact per signerComing soon
• MS-2.11Secure communication channels with channel-compromise proceduresComing soon
• MS-2.12Signer-removal timelines per risk level + quarterly liveness checkComing soon
• MS-2.13Isolated devices or networks for high-value signing operationsComing soon
• MS-2.14Signer reachability, quorum within 12 hours for routine operationsComing soon
• MS-2.15Continuous monitoring with seven required alert categoriesComing soon
• MS-2.16Multisig transaction audit-trail retention, 1+ yearComing soon

DARC-114

• AC-1.01Organization 2FA requirement enforced
• AC-1.02Approved password manager required for credential storage
• AC-1.03Unique strong passwords per account
• AC-1.04Individual accounts only, no shared credentials
• AC-1.05Timely offboarding revocation
• AC-1.06Security onboarding is completed before any significant access is granted
• AC-1.07Secure secret sharing via password manager or other encrypted channel
• AC-1.08Full-disk encryption on every organizational device
• AC-1.09Auto-lock on every device
• AC-1.10Weekly OS and security-patch installation
• AC-1.11No public or shared Wi-Fi for key, custody, or admin access
• AC-1.12Screen lock and visual privacy in shared spaces
• AC-1.13Remote-wipe capability enabled and demonstrated
• AC-1.14Lost-or-stolen device runbook

DARC-222

• AC-2.01Hardware-key (FIDO2/WebAuthn) authentication on high-impact accountsComing soon
• AC-2.02Phishing-resistant MFA recommended for all other accounts with documented upgrade pathComing soon
• AC-2.03Account-lifecycle procedures, documented approval for creation, modification, revocationComing soon
• AC-2.04Least-privilege enforcement, minimum necessary access per roleComing soon
• AC-2.05Access reviews, 6-monthly for critical systems, annual for the restComing soon
• AC-2.06Service-account and API-key inventory with named owner per credentialComing soon
• AC-2.07Credential rotation schedule with immediate rotation on suspected compromiseComing soon
• AC-2.08Approved-tool evaluation with annual sweep against installed-tool inventoryComing soon
• AC-2.09Security-awareness training, twice yearly with live phishing simulationComing soon
• AC-2.10Insider-threat assessment, damage scenarios documented per roleComing soon
• AC-2.11No single person initiates and approves the same action for funds, keys, or privileged infraComing soon
• AC-2.12Malware protection covering industry-specific threatsComing soon
• AC-2.13Remote-work policy, VPN, approved devices, home-network requirementsComing soon
• AC-2.14BYOD policy with documented baseline and access scopeComing soon
• AC-2.15Baseline device-security check at access grant and on a recurring cadenceComing soon
• AC-2.16Documented onboarding checklist, identity, device, MFA, training, ackComing soon
• AC-2.17Offboarding checklist, devices, accounts, credentials, physical items, sessionsComing soon
• AC-2.18Involuntary-termination access cut at notification or earlierComing soon
• AC-2.19Recovery options point only to organization-controlled infrastructureComing soon
• AC-2.20Hardening baselines for SaaS identity and productivity platformsComing soon
• AC-2.21Travel protocol for signers and custody-system personnelComing soon
• AC-2.22Organizational account inventory with one-business-day update SLAComing soon

DARC-18

• SD-1.01Branch protection on production branches
• SD-1.02Signed commits required on protected branches
• SD-1.03Secret scanning enabled
• SD-1.04Pre-commit secret-scanning hook configured
• SD-1.05No unrevoked secrets committed to source
• SD-1.06Dev and staging environments have no path to the credentials or keys that grant production access
• SD-1.07MFA on cloud and platform accounts
• SD-1.08Root credential isolated and in sealed custody

DARC-213

• SD-2.01Two non-author reviewers required on protected-branch mergesComing soon
• SD-2.02External-contributor PRs require manual CI/CD triggerComing soon
• SD-2.03SAST integrated in CI/CD pipelineComing soon
• SD-2.04Per-repository sandboxing and privileged-work account separationComing soon
• SD-2.05CI/CD config changes follow the protected-branch process; build agents are ephemeral and scopedComing soon
• SD-2.06No persistent production-secret access for CI/CD runnersComing soon
• SD-2.07Dedicated secrets management systemComing soon
• SD-2.08No direct read access to production secret values; audited break-glass onlyComing soon
• SD-2.09Deterministic builds, self-verified reproducible compilationComing soon
• SD-2.10Staging validation before production deploymentComing soon
• SD-2.11Secure configuration baselines for cloud, servers, CI/CDComing soon
• SD-2.12Cloud security hardening, IAM least-privilege, logging, no public storageComing soon
• SD-2.13DR procedures with RTO/RPO, automated backups, exercised restore pathComing soon

DARC-17

• SC-1.01External smart-contract audit by a recognized firm before mainnet deployment
• SC-1.02Audit report publicly available or available to the certification auditor
• SC-1.03Critical and high-severity audit findings addressed before deployment
• SC-1.04Deployed contracts verified on the block explorer with source published
• SC-1.05Deployed bytecode traceable to audited source
• SC-1.06Privileged functions documented with access-control detailsComing soon
• SC-1.07Documented deployment proceduresComing soon

DARC-211

• SC-2.01Two-plus independent external audits for core contracts; three-plus for critical-riskComing soon
• SC-2.02Timelock on privileged operations; emergency functions require multisig + post-execution reviewComing soon
• SC-2.03Pause mechanism implemented and tested for critical contractsComing soon
• SC-2.04Documented upgrade governance, who, approval, timelockComing soon
• SC-2.05Deployment pipeline, testnet → staging → mainnet with simulationComing soon
• SC-2.06Re-audit triggered on major upgrades or new core contract deploymentsComing soon
• SC-2.07Critical-patch SLA with per-severity time-to-deployComing soon
• SC-2.08Bug bounty program with tiered, published reward tableComing soon
• SC-2.09Audit findings tracked to resolutionComing soon
• SC-2.10Designated authority for emergency on-chain actionsComing soon
• SC-2.11On-chain governance, review period, quorum, abnormal-pattern monitoringComing soon

DARC-15

• IM-1.01Named person responsible for security incidents
• IM-1.02Emergency contact list, internal team and external responders
• IM-1.03Incident response runbook
• IM-1.04Incident reporting channel known to every operator
• IM-1.05Audit logs on key systems: auth, transactions, deployments

DARC-215

• IM-2.01Incident response team with roles, scribe, and named backupsComing soon
• IM-2.02Response playbooks for key scenariosComing soon
• IM-2.03Incident classification taxonomy with severity levelsComing soon
• IM-2.04Escalation paths by severity levelComing soon
• IM-2.05Signer reachability integrated with incident responseComing soon
• IM-2.0624/7 monitoring with alerting and paging redundancyComing soon
• IM-2.07Tamper-evident logging with at least one year of retentionComing soon
• IM-2.08Security event on monitoring or logging changesComing soon
• IM-2.09IR channels on two platforms with independent infrastructure; sensitive content on E2EE onlyComing soon
• IM-2.10Post-incident reviews conducted and documentedComing soon
• IM-2.11Stakeholder status-update procedures during incidentsComing soon
• IM-2.12Evidence collection procedures for forensics and legalComing soon
• IM-2.13Annual incident response drillsComing soon
• IM-2.14Extended emergency-contact roster with cross-protocol and vendor contactsComing soon
• IM-2.15Written threat picture for protocol operationsComing soon

DARC-17

• TM-1.01Treasury wallets follow multisig requirementsComing soon
• TM-1.02Segregation of company funds from user or client fundsComing soon
• TM-1.03Treasury operations playbook maintained and uploadedComing soon
• TM-1.04Destination addresses verified from multiple authoritative sourcesComing soon
• TM-1.05Documented spending policy per treasury walletComing soon
• TM-1.06Treasury transactions recorded with basic categorizationComing soon
• TM-1.07Small test transfer before full-value transactions to new destinationsComing soon

DARC-218

• TM-2.01Custody arrangement recorded per treasury walletComing soon
• TM-2.02Treasury wallets classified by loss-impact with proportional controlsComing soon
• TM-2.03Concentration caps per wallet, per chain, per custody provider, exceptions require approvalComing soon
• TM-2.04Custody-platform configuration, SoD, value caps, re-auth, IP allowlist, destination allowlistComing soon
• TM-2.05Transaction verification, simulation plus multi-party confirmation for large transfersComing soon
• TM-2.06Synchronous voice call with liveness check for transfers above high-value thresholdComing soon
• TM-2.07Inbound receive-flow, fresh address, round-trip test, identity re-verificationComing soon
• TM-2.08Treasury signer/approver competence demonstrated and refreshed annuallyComing soon
• TM-2.09Credential and secret management for treasury systemsComing soon
• TM-2.10Quarterly access reviews for treasury systemsComing soon
• TM-2.11Protocol due diligence before committing treasury fundsComing soon
• TM-2.12Vendor security evaluation for custody providersComing soon
• TM-2.13On-chain ↔ internal-records reconciliation at defined per-class frequencyComing soon
• TM-2.14Tracked treasury-infrastructure changes with pre-written rollback runbooksComing soon
• TM-2.15Disbursement limits with timelock above thresholdsComing soon
• TM-2.16Monitoring for unusual treasury outflowsComing soon
• TM-2.17Custody-platform anomaly + vendor-availability + monitoring-integrity included in treasury monitoringComing soon
• TM-2.18Per-signer and per-automation movement ceilings derived from TM-2.02 risk bandComing soon

DARC-14

• CM-1.01On-chain monitoring of treasury and multisig wallets
• CM-1.02Alerts on large transfers above defined thresholds
• CM-1.03Alerts on signer-set and threshold changes
• CM-1.04Named alert reviewerComing soon

DARC-210

• CM-2.01Smart-contract monitoring, unexpected interactions, parameter changes, failed transactionsComing soon
• CM-2.02Credential-leak surveillance, breach corpora, paste sites, public repos, dark webComing soon
• CM-2.03Organizational-account monitoring (social media, domains)Coming soon
• CM-2.04Alert priority tiers with named responders and escalation triggersComing soon
• CM-2.05On-call schedule with coverage for operational needsComing soon
• CM-2.06Alert triage procedures, distinguish real incidents from false positivesComing soon
• CM-2.07Documented monitoring coverage, covered systems, signals, gaps, deferralsComing soon
• CM-2.08Monitoring → IR workflow integrationComing soon
• CM-2.09Protocol-health monitoring for active lending, staking, or liquidity poolsComing soon
• CM-2.10DeFi-specific attack-pattern monitoringComing soon

DARC-14

• SY-1.01Dependencies from official package registriesComing soon
• SY-1.02Dependency versions pinned with committed lockfiles
• SY-1.03Automated dependency-vulnerability scanning
• SY-1.04Pinned external resources, toolchains, and CI actions

DARC-214

• SY-2.01Vendor risk assessment for critical infrastructure providersComing soon
• SY-2.02Oracle architecture documented with redundancy approach; in audit scopeComing soon
• SY-2.03Oracle configuration documented, frequency, deviation thresholds, stale handling; in audit scopeComing soon
• SY-2.04Oracle failure scenarios + circuit breakers documented for liquidation mechanics; in audit scopeComing soon
• SY-2.05RPC provider redundancy, at least two independent providersComing soon
• SY-2.06Dependency changelogs reviewed before every production updateComing soon
• SY-2.07Typosquatting checks before installing new packagesComing soon
• SY-2.08SBOM maintained for production systemsComing soon
• SY-2.09Identity verification for personnel with access to keys/funds/infra; pseudonymous code contributors allowed only via reviewComing soon
• SY-2.10Third-party code evaluated for data exfiltration riskComing soon
• SY-2.11Bridge exposure limits, monitoring, emergency-exit plans (if using bridges)Coming soon
• SY-2.12Wallet connector and frontend SDK versions pinned and reviewed (if deploying frontends)Coming soon
• SY-2.13Supplier security incidents trigger re-evaluationComing soon
• SY-2.14Frontend build integrity, CI build hash matches deployed CDN artifactComing soon

DARC-16

• FD-1.01MFA on registrar and DNS-control accounts (SMS excluded)
• FD-1.02Domain owner and domain backup operator
• FD-1.03Domain renewal continuity with funded payment
• FD-1.04Outbound email authentication (SPF, DKIM)
• FD-1.05Certificate owner and certificate backup operator
• FD-1.06TLS certificate expiry and revocation readiness

DARC-215

• FD-2.01DNSSEC enabled on all primary domainsComing soon
• FD-2.02CAA records restricting TLS issuance with iodef reportingComing soon
• FD-2.03Registrar account on FIDO2 + enterprise-tier registrar with server-side locks for critical domainsComing soon
• FD-2.04Registrar-side EPP transfer locks (and update/delete locks for critical domains)Coming soon
• FD-2.05Security-event reporting mailbox on independent DNS zoneComing soon
• FD-2.06DNS change-control, second reviewer, team notification, audit log, second-channel registrar confirmationComing soon
• FD-2.07DNS TTL strategy with emergency-lowering procedureComing soon
• FD-2.08Continuous DNS-zone monitoring covering four threat categoriesComing soon
• FD-2.09Certificate Transparency monitoring with wildcard flaggingComing soon
• FD-2.10Content Security Policy headers on all frontendsComing soon
• FD-2.11SRI for external scripts on signing/custody pages; no auto-updating third-party scriptsComing soon
• FD-2.12MTA-STS published on sending domains (conditional)Coming soon
• FD-2.13Domain classification by risk with proportional controlsComing soon
• FD-2.14Automated TLS renewal (ACME) with documented manual-only exceptionsComing soon
• FD-2.15User-warning procedure for frontend or DNS compromise, two independent channelsComing soon

DARC-15

• PS-1.01Key-bearing artifacts in locked physical storage
• PS-1.02Clear-desk discipline where keys live
• PS-1.03Visitor policy for workspaces with key material
• PS-1.04Direct or authorized-reseller procurement for security-critical hardware
• PS-1.05Key material spread so no single container holds a multisig quorum

DARC-27

• PS-2.01Defined physical-security perimeters for signing, key-storage, and sensitive operationsComing soon
• PS-2.02Access control for secure areas with loggingComing soon
• PS-2.03Physical-security monitoring for secure areasComing soon
• PS-2.04Equipment siting and protection from unauthorized access and environmental damageComing soon
• PS-2.05Environmental protections, fire, flood, climate, for facilities housing key materialComing soon
• PS-2.06Designated secure areas for key ceremonies with documented access proceduresComing soon
• PS-2.07Working-in-secure-areas procedures, no unauthorized devices, no photography, escorted visitorsComing soon