§ 0 · A consultancy at the seam between code and law

Contracts that hold up on-chain and on paper.

Smart Contracts Legal designs the legal architecture around tokens, DAOs and cross-border deals, and audits the code that carries it. The aim is simple to state and hard to do: what the documents promise is what the contract does.

Book a scoping call See how we work

Not a law firm. We do not give legal advice. We work alongside the counsel you engage, as legal engineers and security reviewers. $3bn+ in total value locked audited · Ethereum · Solana · Arbitrum · Optimism

§ 1Practice

Legal engineering.

Five kinds of work. Each starts with a document and ends with something a machine can enforce, or with a clear note on what it cannot.

1.1

Smart contract legal engineering

We draft, review and structure smart contracts so they line up with enforceable legal terms, without giving up the decentralization that made you write them in the first place.

Contract terms review
Risk allocation and fallback logic
Enforceability map: which clause each function enforces, and which it cannot

The documentEither party may terminate this agreement on thirty days' written notice.

The contractfunction terminate() external onlyParty { require( block.timestamp >= notice[msg.sender] + 30 days, "notice period" ); _settleAndClose(); }

1.2

DAO structuring and governance

A DAO, a decentralized autonomous organization, coordinates through on-chain votes instead of a board. It still needs an entity somewhere, a jurisdiction, and rules for the treasury that a court and a smart contract can both read.

Entity selection and jurisdiction strategy
Governance design: proposal thresholds, quorums, timelocks
Treasury counseling

The documentResolutions pass with a two-thirds majority of the votes cast.

The contractrequire(yes * 3 >= (yes + no) * 2, "no supermajority"); require(yes + no >= quorum, "no quorum");

1.3

Token structuring and regulatory strategy

Whether you are launching a token, managing a treasury, or working out whether the thing you have built is a security, we lay out a path that stands up to scrutiny and hand your counsel a map rather than a mystery.

Token classification and legal analysis
Public versus private sale frameworks
Securities, commodities and broker-dealer questions, mapped for counsel

The documentTokens sold in the private round are locked for twelve months from closing.

The contractrequire(block.timestamp >= lockedUntil[holder], "lock-up"); // set once at closing; not owner-editable

1.4

Cross-border deals

Blockchain M&A, joint ventures and venture rounds across the US, Asia and Europe. Crypto-native assets and intellectual property need deal terms that know what a private key is.

Deal structuring for crypto-native assets and IP
Regulatory due diligence and risk assessments
Coordination with counsel in each jurisdiction

The documentClosing is conditional on transfer of the protocol's administrative keys to the buyer's multisignature wallet.

The contractrequire(protocol.owner() == buyerMultisig, "keys"); require(timelock.admin() == buyerMultisig, "timelock");

1.5

Ongoing Web3 advisory

For a small number of clients we stay on: reviewing what ships, what changes, and what the regulators said this month, so soundness is a habit rather than a project.

Retained review of upgrades and new contracts
Governance and treasury check-ins
Regulatory watch, in plain English

The documentMaterial upgrades to the protocol require prior review.

The contractmodifier reviewed(bytes32 codehash) { require(approved[codehash], "not reviewed"); _; }

§ 2Security

Audits and adversarial testing.

An audit is a structured attempt to break your contract before someone else does. Ours ends in a report you can publish.

Security engineers, cryptographers and formal verification specialists read the code line by line, then attack it. Formal verification means proving, mathematically, that the code matches its specification for the properties that matter most, such as "no one but the owner can pause" or "total supply never changes."

Findings are ranked by how much they could cost you, fixed by your team, and re-tested by ours. The final report is written to be published: a public record that the work was done and what it found.

ScopeThreat model, trust assumptions, privileged roles, and the exact commit under review.
ReviewManual line-by-line review, adversarial testing, fuzzing, and formal verification where it earns its keep.
FindingsEach with severity, impact in plain English, a proof of concept, and a recommended fix.
Re-testEvery fix verified on the new commit before the report is final.
AfterContinuous monitoring for state and privilege changes, and an incident response plan ready before it is needed.

CriticalHighMediumLowInformational

$3bn+

Total value locked in contracts we have audited

4 chains

Ethereum, Solana, Arbitrum, Optimism, and other major ecosystems

Day zero

Security practices designed in from the first commit, not bolted on

§ 3How we work

From clause to code, in four steps.

Twenty-four seconds, no sound. The steps are written out below the film.

From clause to code · 0:24 Best viewed full screen on a phone

STEP 1

Read the term

Every clause grants a right, sets a restriction, or provides a remedy. We start by naming which.

STEP 2

Map it to code

Each phrase becomes a check the contract runs before it moves anything. Nothing in the code that is not in the document.

STEP 3

Test it adversarially

We attack the contract the way a hostile party would, then rank what we find by what it could cost you.

STEP 4

Ship with a paper trail

Fixes re-tested, report published, monitoring on. What the document says is what the contract does.

Transcript of the film

TITLE From clause to code. How a term in a document becomes a rule on a blockchain, and how we check that the two say the same thing.

STEP 1 Read the term. Every clause does one of three things: it grants a right, sets a restriction, or provides a remedy. We start by naming which. Clause 4.2, a restriction: transfers are permitted only to holders who have completed identity checks and who are not resident in a restricted jurisdiction.

STEP 2 Map it to code. Each phrase becomes a check the contract runs before it moves anything. Nothing in the code that is not in the document; nothing in the document the code cannot enforce.

STEP 3 Test it adversarially. We attack the contract the way a hostile party would, then rank what we find by how much it could cost you. Findings: a medium, a low and an informational, all fixed and re-tested.

STEP 4 Ship with a paper trail. Findings fixed and re-tested. Report published. Monitoring switched on. What the document says is what the contract does.

§ 4Who we serve

Four kinds of client, four kinds of question.

The work is the same in every case: read the documents, read the code, and close the gap between them.

Enterprise 4.1

Bringing an on-chain product into a business that answers to regulators, auditors and a board.

Asks: Is the vendor's contract safe? What do we tell the board? Which policies change?
We deliver: Vendor and protocol diligence, board-level assurance, and policies written for the way the product actually works.

DAOs and Web3-native protocols 4.2

Teams whose governance, treasury and product all live in contracts, and who launch to the public.

Asks: Which entity, where? How do we launch the token? Is the code ready for mainnet?
We deliver: Structure and governance design, token strategy, and an audit before the first block.

Layer 2 protocol teams 4.3

A Layer 2 is a network built on top of a base chain to make transactions faster and cheaper. Its risks sit in the seams: bridges, sequencers, upgrade keys.

Asks: Who can upgrade us, and how fast? What happens when the bridge pauses? Who sits on the security council?
We deliver: Bridge and upgrade-path review, security council design, and the documents that match them.

Founders and funds 4.4

Buying, selling, partnering or raising, where the asset changing hands is a protocol, a token or a key.

Asks: What exactly are we buying? What can the other side's contracts do that their deck does not mention?
We deliver: Deal structure for crypto-native assets, technical and regulatory diligence, and closing mechanics that live on-chain.

§ 5Code v. law

Where the document and the contract disagree.

Six things we find often enough to keep a list. None is a scandal on its own. Each becomes one when nobody wrote it down.

The document says	The code does
"The protocol is immutable."	upgradeTo(address) exists on the proxy, callable by one admin key, no timelock.
"Holders own the underlying asset."	Holders own a token. The asset is held by an entity whose documents say something else.
"Transfers are restricted to eligible investors."	Any address can receive tokens. The restriction lives in a PDF.
"The DAO decides."	A 5-of-9 multisig decides. The DAO advises.
"Funds cannot be moved without a vote."	A pause() and a sweep() exist, and one person holds the key to both.
"The fee is 0.3%."	setFee(uint256), owner-only, no cap, no notice period.

Sometimes the code is right and the document should change. Sometimes the reverse. Either way, the gap is the finding, and closing it is the job.

§ 6Contact

Start with a scoping call.

Tell us what you are building or buying, and where the documents and the code currently stand. We come back with a scope, a timeline and a fixed fee where the work allows one.

New engagementssales@smartcontractslegal.com

For your general counselgc@smartcontractslegal.com