Blockchain Compliance by Design: Smart Contract Controls for Regulated Crypto Flows

If you are building a tokenised asset, security token or regulated crypto transaction flow, compliance cannot be added only after the smart contracts have been developed. Rules about who may hold or transfer the token, which jurisdictions may participate, when assets may be frozen or redeemed and what happens when compliance data is unavailable can affect the token standard, identity layer, oracle design, administrative permissions and legal documents.

The practical question is therefore not only whether the code can execute a transaction. It is whether the product should permit that transaction under the applicable legal, regulatory and commercial rules, and which parts of that decision can safely be translated into technical controls.

This is the purpose of compliance by design: identifying the requirements that apply to a blockchain or crypto product and building the objectively testable parts into its operating architecture from the start. Depending on the product, this may include wallet eligibility rules, KYC or KYB status, sanctions-related controls, jurisdictional restrictions, holding limits and pre-transfer checks.

Compliance by design does not make a product legally compliant by itself. It helps ensure that defined rules are applied consistently, while legal documents and human decision-making continue to address classification, judgment, liability, exceptions and remedies.

When Does a Blockchain Product Need Compliance by Design?

Not every blockchain product needs compliance controls embedded directly into the code. For lower-risk products, some requirements may be handled through interface-level controls, off-chain checks, and legal terms.

But some products need more. If the token represents securities, fund interests, or other regulated assets; if only eligible investors may hold or receive it; if transfers are restricted by law or contract; or if KYC, KYB, sanctions, or jurisdictional checks determine whether a transaction can proceed, compliance has to be part of the product architecture. The same is true where institutional partners require audit trails, controls, intervention rights, or the ability to pause, freeze, recover, redeem, or force-transfer tokens.

If that sounds like your product, compliance is not something to bolt on later. The real question is how to build it in without breaking the product you set out to make.

Why Code Is Law Is Not Enough for Regulated Transaction Flows

“If a smart contract permits a transaction, the transaction is valid within the logic of the system” – this is the core idea often associated with code is law.

The phrase reflects a broader theory discussed by Lawrence Lessig: behaviour is shaped not only by formal law, but also by social norms, markets, and architecture. In blockchain systems, code is architecture. It determines what users can technically do – whether a transaction is allowed, blocked, automated, or made irreversible.

But code is law is better understood as an architectural principle, not a legal defence. It explains how software can constrain behaviour, but it does not mean that every technically possible transaction is lawful or immune from legal challenge. Depending on the facts and jurisdiction, an exploit of a bug, vulnerability, or unintended protocol feature may still raise legal issues, including fraud, theft, unjust enrichment, breach of duty, market abuse, or other claims.

That is why code cannot be treated as a complete substitute for law. Smart contracts may automate performance, but they do not fully resolve questions of liability, risk allocation, ownership, consumer protection, sanctions, or regulatory compliance.

Many projects have responded by combining legal terms with code execution – an approach Sergey Ostrovskiy has also written about, arguing that legal terms and technical execution should reinforce each other rather than substitute for one another.

But even that combination may no longer be enough on its own. As Web3 moves into more complex, regulated, user-facing territory, the design question needs to shift again – from “what can the code execute?" to “what should the system allow before execution?”. That shift is what compliance by design is about, and it is the focus of the rest of this piece.

What ‘Compliance by Design’ Means for Blockchain Products

Where compliance checks happen only after a transaction has been initiated or completed, blockchain execution can make intervention difficult. Transactions may execute almost instantly, records can be hard to reverse, and networks operate continuously. A compliance model based mainly on manual review or after-the-fact enforcement is therefore poorly suited to on-chain transactions.

This is where compliance by design becomes important. Instead of treating compliance as a separate layer added after deployment, legal, regulatory, and commercial rules are built into the token, protocol, or smart contract from the start.

The core shift is from ex post (i.e. after the fact) enforcement to ex ante (i.e. before the fact) prevention. In practice, this means that a transaction should not execute unless it satisfies predefined requirements that can be objectively tested by the system. For example, a permissioned token may reject a transfer unless the recipient wallet is linked to a verified identity, satisfies the issuer’s eligibility rules, and is not flagged under applicable sanctions or jurisdictional restrictions.

Compliance by design does not remove the need for legal analysis and documentation. But it helps translate legal requirements into product architecture, so prohibited or non-compliant transactions can be blocked before they happen.

How to Translate Legal Requirements into Smart Contract Controls

Translating legal requirements into code is not straightforward. Law and software work differently. Legal rules are often principles-based, flexible, and context-dependent. Their interpretation may change through court decisions, regulatory guidance, and market practice.

Technical rules, by contrast, must be precise and deterministic. A smart contract cannot interpret ambiguity or exercise legal judgment like a court, regulator, or lawyer. It executes predefined instructions exactly as written. This means that converting legal requirements into code is not just a translation exercise. It requires turning nuanced legal concepts into objective, machine-readable rules without losing their legal intent.

So, legal teams determine which rules apply. The technical challenge is making the protocol or smart contract recognise and enforce the parts of those rules that can be converted into objective controls. In practice, this usually requires two layers: on-chain rules that the smart contract can enforce, and off-chain data that tells the system whether those rules are satisfied. The decision on which layer to use should follow a simple test: a rule belongs on-chain only if its conditions can be defined objectively, supplied through sufficiently reliable data, and updated when the underlying legal or factual position changes. Rules that call for legal interpretation, proportionality, suitability, or contextual judgment should stay off-chain, subject to human review.

Permissioned Tokens: ERC-3643 and Pre-Transfer Compliance Checks

One practical example of compliance by design is the ERC-3643 standard, also known as T-REX, which is designed for permissioned tokens and regulated assets. Unlike a standard ERC-20 transfer, which usually executes if the sender has enough balance, an ERC-3643 transfer is conditional. Before the transfer is recorded on-chain, the smart contract checks whether the transaction satisfies predefined compliance rules. If the sender, recipient, or transaction fails those checks, the transfer is rejected before execution.

ERC-3643 achieves this through a modular architecture. Instead of placing all logic in one contract, different contracts perform different functions. Two key components are:

• On-chain Identity Registry: links wallet addresses to verified digital identities and allows the system to confirm whether a wallet has completed the required onboarding checks, such as KYC or KYB. The architecture can allow eligibility to be verified through on-chain identities and attestations without placing the underlying KYC/KYB documents directly on-chain, although the privacy implications depend on the implementation.
• Compliance Contracts/Modules: contain the rules that determine whether a transfer is permitted. These may include investor eligibility, jurisdictional restrictions, sanctions screening, holding periods, transfer limits, ownership thresholds, or other legal and commercial conditions.

This modular structure makes ERC-3643 easier to adapt as requirements change. Because compliance logic is separated from the token itself, issuers can update the relevant rules without reissuing the underlying token.

ERC-3643 can help operationalise transfer restrictions and eligibility controls, but it does not by itself determine the legal classification of the token or remove the need to assess whether the asset is a security, financial instrument, e-money token, fund interest, or another regulated product.

Oracles and Off-Chain Data: Supplying KYC, Sanctions and Eligibility Inputs

Not all compliance-relevant information can or should be stored on-chain. Smart contracts, including standards such as ERC-3643, often need off-chain data to determine whether a transaction satisfies predefined objective rules. This may include sanctions lists, KYC/KYB records, beneficial ownership information, jurisdictional restrictions, investor eligibility, or other compliance data.

Oracles help connect this off-chain information to on-chain systems. They collect, verify, and transmit external data to smart contracts, allowing the code to respond to real-world facts. For example, a smart contract may block a transfer if oracle data indicates that the recipient wallet is linked to a sanctioned person, an unverified investor, or a restricted jurisdiction.

However, oracles introduce their own risks. They may fail, provide inaccurate data, or be affected by manipulation, outages, delays, or errors in the underlying data source. These risks should be addressed in the relevant legal documents. The documents should explain which data sources are used, who is responsible for their accuracy, what happens if data is delayed or unavailable, and how losses are allocated if incorrect data causes a transaction to be wrongly blocked or permitted. Where compliance inputs include personal data, projects should also consider privacy, data minimisation, access control, and the legal basis for processing that data.

This is another reason legal documents still matter: they define risk, responsibility, and remedies when the technology does not work as intended.

Why Smart Contract Controls Still Need Legal Agreements

Compliance by design is a control architecture, not a replacement for legal analysis or documentation. Code is binary: a condition is either met or not met. It can block a transfer, check an eligibility rule, or automate performance. Code can enforce objective rules, but it cannot fully define the parties’ rights, allocate risk, include disclaimers, set liability limits, provide warranties, choose governing law, or explain remedies if a dispute arises.

These issues are typically addressed in legal documents: T&Cs for interfaces or services, SAFTs or OTC agreements for token sales depending on the product, transaction and jurisdiction, subscription agreements for securities or investment products, and other transaction documents where appropriate.

This is also where the concept of a Ricardian contract becomes relevant. It is designed to bridge legal prose and software execution: the legal document remains human-readable, but key terms can be parsed by software, digitally signed, and linked to related transactions through a cryptographic hash. The point is not that the contract disappears into code, but that the legal and technical layers can reference each other more reliably.

The broader point is simple: compliance by design does not eliminate legal documents. The strongest Web3 compliance structures are hybrid: smart contracts enforce objective controls, while legal instruments define the rights, obligations, risks, and remedies behind them.

What Founders Should Decide Before Development Begins

Compliance by design is not simply a smart contract feature. It is an operating model connecting legal requirements, product rules, technical controls, external data and legal documentation.

Before development begins, founders should determine which regulatory regimes may apply, who may use or hold the product, which restrictions can be tested objectively, what data the system will rely on and who is responsible for keeping that data accurate and current. They should also decide how controls will be updated, who may approve exceptions or emergency actions and what happens when an oracle, identity provider or screening system fails.

The strongest structure is usually hybrid. Smart contracts enforce clearly defined rules; off-chain systems provide identity and compliance inputs; governance processes control updates and exceptions; and legal documents define rights, responsibilities, liability and remedies.

The objective is not to encode the law in its entirety. It is to ensure that the product architecture reflects the rules the business is expected to follow and that the company can demonstrate how those rules are implemented in practice.