Smart Contracts and the Law: Risks, Compliance & Best Practices

Smart contracts promise near-instant performance and lower transaction costs, but they also sit at the intersection of contract law, data protection, financial regulation, cybersecurity, and corporate governance. This guide explains the legal implications of using smart contracts in plain English, shows you how to implement them safely, and gives you checklists, metrics, and a four-week rollout plan you can actually follow. It’s written for founders, product managers, in-house counsel, compliance leads, and engineers who need a practical playbook—not a casebook.

Disclaimer: This article is for general information only and is not legal advice. For decisions about your specific situation, consult a qualified attorney in your jurisdiction.

Key takeaways

• Smart contracts can create binding obligations if basic contract elements are present and electronic-record rules are observed.
• “Code is law” is a myth in court—text terms, disclosures, and dispute clauses still matter.
• Data rules apply: immutability must be balanced with deletion/erasure rights and access controls.
• Financial and sanctions laws still apply when tokens or automated payments are involved.
• Property and title in digital assets are evolving, with newer commercial-law rules on control and transfer. Delaware Code Online
• Operational safeguards are essential: kill-switches, auditability, and access controls are now explicit regulatory expectations in some regions.

What a smart contract is (and isn’t) in legal terms

What it is and why it matters

At its core, a smart contract is software that automatically performs steps of an agreement when pre-defined conditions are met. Legally, the question is whether that software records or performs a contract—and in many jurisdictions, the answer is yes, provided traditional elements (offer, acceptance, consideration, intention) can be shown and any writing/signature requirements are satisfied electronically. Leading commentary in common-law systems has confirmed that automated execution does not prevent enforceability.

Requirements / prerequisites

• Clear business logic that maps to legal obligations.
• A way to present human-readable terms and capture assent.
• Identity attribution and audit trails.
• Platform choice (public chain vs permissioned), with cost and security trade-offs.

Step-by-step for beginners

1. Map the deal: Write a plain-language specification of the obligation, triggers, timeouts, and exceptions.
2. Split “legal vs code”: Decide what must be automated (escrow release, access grant) vs. what should stay in text (warranties, liability caps).
3. Link the two: Reference code artifacts (hash, address, repo) in the text agreement and reference the agreement URL/hash inside the contract storage.
4. Capture consent: Build a signing flow that attributes actions to a person/entity and logs timestamps and fingerprints.
5. Prove identity/control: Use wallets tied to verified identities or enterprise identity providers before allowing “signing” transactions.

Beginner modifications & progressions

• Simplify: Start with a non-custodial escrow or milestone release with manual override.
• Scale up: Move to multi-party workflows with oracles and time-based fallbacks.

Recommended frequency / metrics

• Track cycle time to execution, reversal rate, dispute rate per 1,000 contracts, and on-chain failure rate. Monthly reviews catch logic drift.

Safety & common mistakes

• Treating code comments as legal terms.
• No reliable way to attribute wallet activity to a person.
• Hard-coding addresses or price feeds without change control.

Mini-plan

• Step 1: Draft a one-page text agreement and code a minimal escrow with a timelock.
• Step 2: Add a consent screen that binds the text to the code hash and logs acceptance.

Enforceability essentials: formation, writing, and signature

What it is and why it matters

Electronic-commerce laws in many jurisdictions give electronic records and signatures the same legal effect as paper, and they recognize the use of electronic agents—software acting on behalf of a person—in forming contracts, so long as the actions are attributable. That’s the legal bridge that lets an automated function “click” for you.

Requirements / prerequisites

• A process to present terms, record assent, and attach that assent to the specific transaction.
• Opt-in consent where consumer rules apply, with clear disclosures about receiving records electronically.
• Where state-level electronic-transaction rules apply, ensure you meet them (most U.S. states have adopted a uniform framework).

Step-by-step

1. Design the assent flow: Combine wallet signature or enterprise SSO with a human-readable terms page and an explicit “I agree” step.
2. Bind the records: Store the contract hash, code address, and version inside your execution data.
3. Attribute actions: Maintain a mapping between user identity and the key/wallet used to trigger the contract.

Beginner modifications & progressions

• Beginner: Off-chain e-signature + on-chain execution reference.
• Advanced: On-chain signature schemes plus off-chain notarization of the long-form contract.

Metrics

• Assent completeness rate (all necessary clicks/acks present).
• Attribution success rate (percentage of actions tied to verified identities).

Safety & mistakes

• Letting anyone trigger performance without verifying authority.
• Missing consumer disclosures about electronic records where required.

Mini-plan

• Step 1: Add a pre-transaction consent page with downloadable terms.
• Step 2: Write the terms’ content hash into the smart contract storage/event log.

Code vs. text: how to integrate them so courts can read your deal

What it is and why it matters

Courts interpret contracts, not repositories. If all meaning lives in code, you risk ambiguity about collateral terms (warranties, IP rights, remedies). The best practice is to pair a human-readable agreement with code that automates specific clauses, and to make the two provably refer to each other.

Requirements / prerequisites

• A signed human-readable agreement (even if short).
• A reliable way to freeze a code version (hash/pin).
• Plain-language descriptions of automated steps and failure modes.

Step-by-step

1. Define scope: Identify clauses to automate and those that remain textual.
2. Cross-reference: Put the code hash in the text; store the agreement hash in a contract variable or emitted event.
3. Versioning: Tag every deployment to a release in your repo and capture the tag in the agreement schedule.

Beginner modifications & progressions

• Minimal viable approach: A two-page “terms + schedule” with code link.
• Advanced: Use templates that create both the code and the text annex in one build step.

Metrics

• Version mismatch rate (text/code disagree).
• Dispute rate tied to ambiguity (internal post-mortems).

Safety & mistakes

• Treating README text as binding terms.
• Omitting a human-readable explanation of what the code does on edge cases.

Mini-plan

• Step 1: Create a “Contract Schedule A: Automated Clauses” that lists each function and its legal effect.
• Step 2: In deployment, write the schedule’s hash to a public variable.

Governing law, jurisdiction, and dispute resolution (don’t leave it to chance)

What it is and why it matters

Distributed systems don’t tell you which law applies. Without express clauses, you risk conflicting rules and expensive forum fights.

Requirements / prerequisites

• Governing law clause compatible with your counterparties’ locations.
• Venue/arbitration clause that works for cross-border disputes.
• A service-of-process address or agent.

Step-by-step

1. Add a governing-law clause in the text agreement.
2. Choose arbitration or court litigation; if arbitration, name rules and seat.
3. Provide a physical or electronic address for notices.

Beginner modifications & progressions

• Beginner: Standard commercial arbitration with online filings.
• Advanced: Tiered dispute resolution (negotiation → mediation → arbitration) with time-outs mirrored in code.

Metrics

• Time to resolve disputes, percentage resolved pre-arbitration.

Safety & mistakes

• Silent contracts with no forum selection.
• Clauses that conflict with mandatory consumer protections.

Mini-plan

• Step 1: Insert a one-paragraph governing-law and forum clause.
• Step 2: Add a dispute-resolution timelock mirrored by a pause in automated performance.

Consumer protection and fairness: disclosures that actually stick

What it is and why it matters

Where transactions involve individuals, consumer-law obligations bite: clear disclosures, cancellation windows in some sectors, and transparency about fees and automated decision-making.

Requirements / prerequisites

• Plain-language summaries before assent.
• Clear refund/cancellation logic expressed in both code and text.
• Contact and complaint channels that a non-technical user can access.

Step-by-step

1. Build a pre-contract summary page.
2. Mirror consumer rights (refunds, reversals) in your automated flows.
3. Provide printable/email copies of the agreement.

Beginner modifications & progressions

• Beginner: Static FAQs and downloadable PDFs.
• Advanced: Personalized disclosures that reflect the parameters the code will execute.

Metrics

• Chargeback/complaint rate, successful refund automation rate.

Safety & mistakes

• Hiding key terms in code only.
• Failing to give a durable copy of terms at or after assent.

Mini-plan

• Step 1: Write a one-page “Key Facts” sheet.
• Step 2: Add a refund function callable by the consumer within a time window.

Data protection and privacy: immutability meets erasure rights

What it is and why it matters

If your contract touches personal data, data-protection rules apply. Immutability is great for audit trails but clashes with rights like erasure and correction. Regulators have flagged this tension and recommend careful architecture choices (e.g., keeping personal data off-chain, using pointers, hashing, and permissioned networks when needed). EUR-Lex

Requirements / prerequisites

• Data-mapping (which fields are personal; on-chain vs off-chain).
• Minimization and pseudonymization strategies.
• Ability to stop further automated processing and archive logic/records when required—something some regions now explicitly require for smart contracts used in data-sharing.

Step-by-step

1. Keep personal data off-chain; store only proofs or encrypted references.
2. Implement access controls and key-rotation procedures.
3. Add kill/interrupt controls and archiving to honor legal requests (e.g., erasure where applicable), while still keeping audit logs.

Beginner modifications & progressions

• Beginner: Off-chain database + on-chain hash.
• Advanced: Permissioned chain with revocation lists and privacy-preserving proofs.

Metrics

• Data-minimization score (fields on-chain vs off-chain).
• Time to honor data requests (access/erasure), number of privacy incidents.

Safety & mistakes

• Writing raw personal data on-chain.
• No plan for stopping/archiving automated logic when required by law.

Mini-plan

• Step 1: Replace on-chain personal fields with salted hashes/pointers.
• Step 2: Add an admin-only pause function that halts data-related execution.

Financial-regulatory overlays: securities, tokens, payments, and sanctions

What it is and why it matters

If your smart contract deals with tokens, automated yields, or trading, financial-regulatory frameworks may apply. A well-known investigation concluded that certain token offerings were securities offerings subject to registration or exemption requirements. In the EU, a comprehensive regime now governs crypto-asset issuance and services, with staged application dates. And wherever you operate, sanctions rules apply to automated transfers.

Requirements / prerequisites

• Regulatory mapping: Are you issuing a token? Running a platform? Providing custody?
• KYC/AML/sanctions controls proportional to the risk.
• Disclosures and white papers/offering docs where required.

Step-by-step

1. Classify your token or contract functionality (utility, payment, governance, e-money, asset-referenced).
2. Determine whether you need authorization/registration; apply transitional provisions where available.
3. Implement sanctions screening and wallet-risk checks before allowing automated transfers.

Beginner modifications & progressions

• Beginner: Geofence higher-risk regions; add manual review for large transactions.
• Advanced: On-chain allow-lists and role-based transfer controls integrated with compliance APIs.

Metrics

• Percentage of flows screened, false-positive rate, regulatory filings on time.

Safety & mistakes

• Assuming decentralization exempts you from regulation.
• No geolocation or sanctions controls in automated payouts.

Mini-plan

• Step 1: Add sanctions screening to the payout flow.
• Step 2: Draft a short risk disclosure sheet for token purchasers.

Property, title, and transfer of digital assets: who owns what, and when?

What it is and why it matters

Commercial-law rules are evolving to treat certain digital assets as controllable electronic records, with “control” functioning like possession and special “take-free” protections for good-faith purchasers. This matters for lending, collateral, and token transfers executed by smart contracts. Business Law Section of The Florida Bar

Requirements / prerequisites

• Understand how your jurisdiction defines control and how a transferee acquires rights free of adverse claims.
• Document who has control over contract-upgrade keys and multi-sig treasuries.

Step-by-step

1. Map which assets your contract moves (NFTs, payment tokens).
2. Ensure your system gives a clear control signal to the party intended to hold rights.
3. Where applicable, perfect security interests by control rather than filing.

Beginner modifications & progressions

• Beginner: Single-asset escrow with explicit “controller” role.
• Advanced: Multichain vault with attestations proving control.

Metrics

• Control attribution accuracy (who can move the asset).
• Time to settle and failed transfer rate.

Safety & mistakes

• Ambiguous admin keys that undermine a buyer’s control.
• Relying solely on public ledgers without documenting off-chain equities.

Mini-plan

• Step 1: Name the controller in the text agreement and bind that identity to the control mechanism.
• Step 2: Log control transfers with signed receipts.

Operational risk, security, and bugs: when “self-executing” goes wrong

What it is and why it matters

Bugs or design flaws can drain funds or misallocate rights. A historical exploit showed how logic errors in decentralized code can cause massive losses and trigger regulatory attention.

Requirements / prerequisites

• Secure SDLC, peer review, and professional audits.
• Formal verification where feasible for high-value paths.
• Emergency controls: pause/kill, rate limits, timelocks, circuit breakers.

Some regions explicitly require that smart contracts used for data-sharing include safe termination, archiving, and access control capabilities. Build those in from day one.

Step-by-step

1. Threat-model: list economic and technical attack surfaces (reentrancy, oracle manipulation).
2. Add pausable modifiers and two-man rules for upgrades.
3. Run audits and fix-verify-retire a version before mainnet.

Beginner modifications & progressions

• Beginner: Use audited templates and small bounties.
• Advanced: Multi-layered monitoring with on-chain circuit breakers triggered by oracle variance.

Metrics

• Critical vulnerability count over time, mean time to detect and pause, coverage of unit/integration tests.

Safety & mistakes

• No way to stop a runaway function.
• Ignoring dependencies (libraries, proxy patterns) during audits.

Mini-plan

• Step 1: Add a two-key pause mechanism controlled by separate teams.
• Step 2: Create runbooks for pausing, rolling back, and notifying users.

Oracles, upgrades, and admin keys: power with accountability

What it is and why it matters

Oracles, upgrade proxies, and admin keys are off-chain or meta-layer powers that can override outcomes. Courts and regulators look at who holds real control.

Requirements / prerequisites

• Oracle SLAs, fallbacks, and dispute windows.
• Documented governance around admin keys and upgrades.
• Transparent disclosures to users.

Step-by-step

1. Choose at least two price/data sources with medianizing logic.
2. Use timelocks and multi-sig for upgrades.
3. Disclose who can pause, upgrade, or seize and under what conditions.

Beginner modifications & progressions

• Beginner: Single oracle plus manual override for outliers.
• Advanced: Oracle committee with on-chain voting and insurance backing.

Metrics

• Oracle divergence rate, upgrade notice period adherence, admin-action audit rate.

Safety & mistakes

• Undisclosed superuser powers.
• No fallback for oracle failure.

Mini-plan

• Step 1: Publish an “Admin Powers” table.
• Step 2: Add a 24-hour upgrade timelock with public alerts.

DAOs and governance: who’s liable?

What it is and why it matters

If you rely on a decentralized organization to operate the protocol, courts may still treat the DAO as a legal “person” for enforcement purposes. A headline case resulted in a judgment against a DAO, including penalties and an order to shutter web infrastructure. That precedent shows decentralization does not remove liability.

Requirements / prerequisites

• Consider forming a wrapper entity where appropriate.
• Clear governance and delegation mechanics.
• Compliance ownership—someone must be accountable.

Step-by-step

1. Decide whether a foundation, LLC, or other structure is needed.
2. Document governance processes and control over treasuries and upgrades.
3. Assign compliance duties (reporting, sanctions, disclosures).

Beginner modifications & progressions

• Beginner: Small multisig council with charters.
• Advanced: Token-holder votes with quorum and veto safeguards.

Metrics

• Participation rates, quorum attainment, incident response times.

Safety & mistakes

• Assuming anonymity shields members.
• No responsible party for regulatory contact.

Mini-plan

• Step 1: Adopt a governance charter.
• Step 2: Publish a compliance contact and incident-response mailbox.

Evidence, record-keeping, and admissibility

What it is and why it matters

You need to prove what happened: that a party assented, that an event occurred, that funds moved for a reason. Electronic-record rules and audit trails make your life easier in court if you design for them.

Requirements / prerequisites

• Immutable event logs plus off-chain archives.
• Time-stamping and hashing of key records.
• Exportable logs that map addresses to identities (subject to privacy law).

Step-by-step

1. Emit structured events with identifiers and reason codes.
2. Store nightly snapshots of state and off-chain copies of agreements.
3. Maintain a directory mapping identities to keys with access controls.

Beginner modifications & progressions

• Beginner: CSV exports signed and archived monthly.
• Advanced: WORM storage with third-party attestations.

Metrics

• Completeness of evidence packs, time to produce records upon request.

Safety & mistakes

• Missing linkage between human identity and on-chain addresses.
• No retention policy aligned with sector rules.

Mini-plan

• Step 1: Define an evidence schema.
• Step 2: Automate monthly export + hash-anchor to a public chain.

Cross-border rollouts and standards to watch

What it is and why it matters

If you operate across regions, know the timelines and requirements that affect your implementation—especially where crypto-asset frameworks or data-sharing smart-contract safeguards apply. The EU’s crypto-asset regime phased in through 2024 and beyond, and the data-sharing regime sets smart-contract requirements like safe termination and archiving. micapapers.com

Requirements / prerequisites

• Regulatory calendar for each market.
• Gap analyses for identity, disclosures, and technical controls.

Step-by-step

1. Build a per-jurisdiction checklist (tokens, custody, disclosures).
2. Toggle features by region (e.g., disable certain automated flows where authorizations aren’t yet in place).
3. Re-paper existing deals with addenda referencing new technical controls.

Beginner modifications & progressions

• Beginner: Single-region pilot.
• Advanced: Feature flags and policy-as-code enforced in CI/CD.

Metrics

• Compliance coverage by region, time to implement regulatory changes.

Safety & mistakes

• Ignoring transitional grandfathering deadlines.
• Rolling out features uniformly without regional toggles.

Mini-plan

• Step 1: Create a regulatory timeline doc.
• Step 2: Add feature flags controlling token issuance, marketing, and transfers by region.

Quick-start checklist

People & responsibilities

• Assign an accountable owner for legal, security, and data protection.
• Identify a contract steward for versioning and code–text alignment.

Documents

• Short-form human-readable terms.
• Schedule linking terms to code hash/address.
• Governance and admin-power disclosure.

Technical

• Identity and consent flow (wallet + verified identity).
• Pause/kill switch, upgrade timelock, admin multisig.
• Off-chain storage of personal data; on-chain hashes only.
• Oracle redundancy and SLAs.

Compliance

• Sanctions screening in payouts.
• Regional toggles for token features and disclosures.
• Data-sharing contracts: safe termination, archiving, access control.

Troubleshooting & common pitfalls

• “We hard-coded the wrong address.”
  Add an admin-gated address registry with change controls and timelocks.
• “Users claim they never agreed.”
  Your consent flow likely doesn’t bind identity to the transaction. Capture a signed statement and store the terms’ hash with the event log.
• “We can’t stop an erroneous payout.”
  You lack a pause or interrupt function. Add one and document when it can be used; in data-sharing contexts, this is now more than a best practice.
• “A regulator says our token looks like a security.”
  Revisit how benefits are marketed and who performs managerial efforts; align with registration/exemption paths where applicable.
• “Our DAO believes no one is liable.”
  Precedent says otherwise; form a wrapper and assign accountability.

How to measure progress (legal-ops KPIs for smart contracts)

• Contract cycle time: from draft to execution.
• Dispute rate and time to resolution.
• Pause/interrupt MTTR when incidents occur.
• Assent attribution rate: % of contracts with complete identity binding.
• Regulatory coverage: % of applicable controls implemented per region.
• Data-request SLA: time to fulfill access/erasure requests.

A simple 4-week starter plan (from zero to compliant pilot)

Week 1 — Foundations & design

• Pick one narrow use case (e.g., milestone escrow).
• Draft a two-page human-readable agreement with a schedule listing each automated clause.
• Choose platform (public L2 vs permissioned), repository, and deployment flow.
• Design identity + consent flow with downloadable terms and explicit acceptance.

Week 2 — Build the minimum viable legal-tech stack

• Implement the smart contract with pause() and an upgrade timelock.
• Store the agreement hash in contract storage; emit it in an event on acceptance.
• Add dual oracles and a fallback path.
• Document admin powers and escalation runbook.

Week 3 — Compliance, privacy, and security polish

• Sanctions screening on payouts; geofence where needed.
• Keep personal data off-chain; use pointers or salted hashes.
• Draft a data-handling policy and implement an interrupt/archiving capability for data-sharing automations.
• Run an external audit or peer review; fix and redeploy.

Week 4 — Pilot & governance

• Launch to a limited group with clear disclosures and support.
• Stand up a governance file naming the controllers of admin keys and the conditions for using them.
• Collect KPIs (cycle time, dispute rate, MTTR).
• Schedule a legal/compliance retrospective and plan for phase two.

FAQs

1) Are smart contracts legally enforceable?
Yes—if the usual contract elements are present and any writing/signature requirements are satisfied electronically. Automated performance by software agents does not, by itself, prevent enforceability where electronic-record laws apply.

2) Do I need a paper contract if the code already defines the behavior?
You should still have human-readable terms. Courts interpret text; code should automate specific clauses and be cross-referenced to the text for clarity.

3) How do I handle the “right to erasure” when the ledger is immutable?
Avoid putting personal data on-chain. Store references or hashes instead, and build interrupt/archiving capabilities to stop further processing and preserve auditability.

4) If my project is decentralized, do financial regulations still apply?
Decentralization does not immunize you. Token sales or platform activities can trigger offering, licensing, or market-abuse obligations depending on the facts.

5) What about sanctions compliance for automated payouts?
Screen counterparties and wallets, apply geofencing where appropriate, and keep records. There is specific guidance tailored to virtual-currency activity.

6) Who owns a digital asset transferred by a smart contract?
Modern commercial-law rules focus on control of certain digital records. Achieving control (and being a qualifying purchaser) can give strong protection against competing claims. Uniform Law Commission

7) Do I really need a pause/kill switch?
Yes. Beyond best practice, some jurisdictions now require safe termination and archiving capabilities for smart contracts used in data-sharing.

8) Can a DAO be sued?
Yes. A recent judgment treated a DAO as a legal “person” for enforcement and imposed penalties and shutdown orders.

9) How do I prove consent happened?
Log the acceptance event with the terms’ hash, timestamp, and the attributed identity behind the signing key. Electronic-record rules support enforceability when properly attributed.

10) Do EU crypto-asset rules affect non-EU projects?
If you target EU users or provide services in the EU, the regime can apply, with key dates that already kicked in for some token categories and service providers. Plan region-specific toggles. EUR-LexESMA

11) Are on-chain signatures enough?
They can be, but pair them with clear human-readable disclosures and a consent step to strengthen enforceability—especially for consumer transactions.

12) What should go into my oracle and admin-key policy?
Name who controls each key, define when a pause/upgrade can occur, require a notice period (timelock), and specify fallbacks for oracle failures.

Conclusion

Smart contracts aren’t a legal black box. With the right architecture—human-readable terms, identity and consent, privacy-by-design, pause and archive controls, and a governance plan—you can capture speed and transparency without tripping legal wires. Start small, instrument your KPIs, and iterate your controls as the regulatory picture evolves.

CTA: Ready to ship your first compliant smart-contract workflow? Pick a narrow use case, run the Week-1 steps today, and make it real.

References

• Legal statement on cryptoassets and smart contracts, UK Jurisdiction Taskforce, 2019, https://technation.io/wp-content/uploads/2019/11/6.6056_JO_Cryptocurrencies_Statement_FINAL_WEB_111119-1.pdf
• Smart contracts (project page summarizing advice), Law Commission of England and Wales, 25 Nov 2021, https://lawcom.gov.uk/project/smart-contracts/
• The Launch of the Legal Statement on the Status of Cryptoassets and Smart Contracts (speech), Judiciary of England and Wales, 18 Nov 2019, https://www.judiciary.uk/wp-content/uploads/2019/11/LegalStatementLaunch.GV_.2-1.pdf
• 15 U.S. Code § 7001 – General rule of validity (Electronic signatures; electronic agents), Cornell Law School (Legal Information Institute), current version, https://www.law.cornell.edu/uscode/text/15/7001
• Electronic Signatures in Global and National Commerce Act – Consumer Compliance Examination Manual excerpt, Federal Deposit Insurance Corporation, Oct 2024, https://www.fdic.gov/resources/supervision-and-examinations/consumer-compliance-examination-manual/documents/10/x-3-1.pdf
• Uniform Electronic Transactions Act (overview), Uniform Law Commission, current page, https://www.uniformlaws.org/acts/catalog/current/E
• U.S. Guide to Electronic Signatures (overview document), Uniform Law Commission, 2017, https://www.uniformlaws.org/HigherLogic/System/DownloadDocumentFile.ashx
• Regulation (EU) 2016/679 (General data protection regulation) – official text, EUR-Lex, 4 May 2016, https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/
• Blockchain and the GDPR: Solutions for a responsible use of the blockchain in the context of personal data, CNIL (French Data Protection Authority), 29 Oct 2018, https://www.cnil.fr/en/blockchain-and-gdpr-solutions-responsible-use-blockchain-context-personal-data
• Regulation (EU) 2023/2854 (Data Act) – Official Journal text incl. smart-contract requirements, EUR-Lex, 22 Dec 2023, https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng
• Report of Investigation: The DAO (Release No. 81207), U.S. Securities and Exchange Commission, 25 Jul 2017, https://www.sec.gov/files/litigation/investreport/34-81207.pdf
• Press release: SEC Issues Investigative Report Concluding DAO Tokens Were Securities, U.S. Securities and Exchange Commission, 25 Jul 2017, https://www.sec.gov/newsroom/press-releases/2017-131
• Sanctions Compliance Guidance for the Virtual Currency Industry, U.S. Department of the Treasury – OFAC, 15 Oct 2021, https://ofac.treasury.gov/media/913571/download
• OFAC Information for Industry Groups (virtual currency), U.S. Department of the Treasury – OFAC, current page, https://ofac.treasury.gov/additional-ofac-resources/ofac-information-for-industry-groups
• Statement on Ooki DAO default judgment (Press Release 8715-23), U.S. Commodity Futures Trading Commission, 9 Jun 2023, https://www.cftc.gov/PressRoom/PressReleases/8715-23