The Compliance Layer Is the Product: How Onchain Compliance Actually Works, Chain by Chain

Financial institutions moving into digital assets tend to ask the same question early on: how do you enforce compliance on a network that was designed to be open to anyone? The answer depends heavily on which blockchain they choose. On some networks, it's built into the protocol; on others, it's something you construct at the token level.

This distinction matters more than most vendor conversations let on. If a regulator issues a court order, a fraud investigation opens, or an account lands on a sanctions list, how and where that gets enforced depends entirely on which network the asset lives on. For institutions evaluating blockchain infrastructure, understanding where compliance actually lives (in the protocol or in the application) is a foundational decision that shapes how a tokenized asset behaves for its entire lifecycle.

This piece compares two approaches that represent the ends of that spectrum: Stellar, where compliance controls are native to the network, and Ethereum, where compliance is implemented through token standards like ERC-3643. It then looks at a third model, represented by Canton and Midnight, where the network itself is private by default and compliance becomes a question of what gets disclosed, and to whom.

Two Philosophies, One Goal

Stellar builds compliance into the base protocol. Every asset on Stellar is governed by a mechanism called a trustline: a permission an account must explicitly establish before it can hold a given asset. The issuer controls who can create that trustline in the first place. Beyond that gatekeeping function, Stellar also gives issuers the ability to freeze specific accounts and claw back assets directly at the protocol level, without needing any additional code. They're core to how the network operates, built into every asset by default.

Ethereum leaves compliance to the application layer. Ethereum's base protocol has no concept of trustlines, freezing, or clawback. Any compliance behavior has to be implemented in the smart contract governing the token itself, which is where standards like ERC-3643 come in. ERC-3643 is a token standard purpose-built for regulated assets, defining a framework for identity verification, transfer restrictions, and issuer-level controls such as forced transfers and freezing, all enforced through smart contract logic rather than the underlying network.

A Third Model: When Privacy Is the Compliance Layer

Stellar and Ethereum sit at opposite ends of one spectrum, but they share an assumption: the ledger is public, and compliance means controlling who can transact on it. A newer generation of networks starts from the opposite assumption. On Canton and Midnight, data is private by default, and compliance is expressed through who is allowed to see and authorize each piece of it.

• Canton: compliance through need-to-know data distribution. Canton is a public but permissioned network designed for regulated financial institutions. Its distinguishing feature is sub-transaction privacy: transactions happen only between pre-agreed parties, and each node receives only the portion of a transaction that involves the parties it hosts. There is no global copy of the ledger for everyone to read. That changes what compliance looks like in practice. A regulator or auditor can be added as an observer on specific contracts, gaining read access without gaining control, and every state change requires the authorization of the parties it binds, so unilateral action is impossible by construction. The controls institutions expect from standards like ERC-3643, including identity-gated transfers, compliance attestations on settlement, and court-ordered seizure that preserves the chain of custody, are being built on top of Canton’s token standard with these privacy guarantees intact. OpenZeppelin is building the open-source library layer for the network, documented in the OpenZeppelin Canton docs.
• Midnight: compliance through selective disclosure. Midnight takes privacy further with zero-knowledge cryptography. Data is private by default and stays on the user’s side; smart contracts define exactly which facts are made public, and everything else remains hidden. This enables a compliance pattern the other networks cannot offer: proving a fact without revealing the underlying data. A user can prove they passed KYC with an approved issuer, that they are not on a sanctions list, or that a transfer stays within a regulatory limit, all without exposing their identity, balance, or transaction history to the network. Disclosure is targeted rather than broadcast, so information can be revealed to a designated party, such as an auditor or regulator, without becoming public. OpenZeppelin’s Contracts for Compact library provides the building blocks: token standards with confidential balances, allowlists and blocklists for KYC and sanctions screening, and privacy-preserving access control.

For institutions, the compliance question inverts on these networks. On Stellar and Ethereum, the challenge is adding control to an open network. On Canton and Midnight, the challenge is deciding what to disclose, and to whom, on a network that reveals nothing by default. Confidentiality obligations like banking secrecy and data protection law stop being in tension with using a shared ledger at all.

What This Means in Practice

The practical difference shows up in a few places institutions care about.

• Where the rules live. On Stellar, compliance behavior is consistent across every asset that uses trustlines, because it's a property of the network itself. On Ethereum, compliance behavior is only as strong as the smart contract that implements it. Two tokens built on ERC-3643 can still differ in how they're configured, which means the quality of the implementation matters as much as the standard itself.
• Who can see the data. On Stellar and Ethereum, every balance and transfer is public, and privacy has to be engineered separately if it is needed at all. On Canton, data is distributed strictly on a need-to-know basis between the parties to each transaction. On Midnight, data is private by default and disclosed selectively through zero-knowledge proofs. For institutions with confidentiality obligations, this is often the deciding factor, not a secondary one.
• How much custom development is required. Stellar's native controls mean less custom logic to write and, in turn, fewer smart contracts to secure and maintain. Ethereum's approach requires a compliant token contract to be built, tested, and put through security audits before launch, which adds development time but also gives institutions more flexibility to design controls specific to their use case.
• How mature and battle-tested the approach is. ERC-3643 has seen substantial adoption across tokenized funds and other regulated asset issuances on Ethereum and other EVM-compatible networks, and the standard itself has been shaped by real deployments. Stellar's trustline model has existed since the network's early design and is used broadly across its asset issuance ecosystem. Both are established, but institutions should evaluate the ecosystem of tooling, smart contract audits, and precedent around whichever path they choose, not just the theoretical design.
• Flexibility versus consistency. The application-layer approach on Ethereum means compliance logic can be tailored closely to a specific regulatory framework or business requirement. The protocol-layer approach on Stellar means less design work up front but less room to customize behavior beyond what the network natively supports.

Why This Matters for Infrastructure Decisions

Neither approach is universally better. The right choice depends on what an institution is issuing, which regulatory frameworks it needs to satisfy, and how much internal engineering capacity it has to build and maintain compliant smart contracts.

What matters is that this decision gets made deliberately, with a clear understanding of where compliance actually lives on the chosen network. Institutions evaluating tokenized deposits, tokenized funds, or other tokenized real-world assets should be asking their infrastructure partners this question directly: when something goes wrong, where in the stack does the intervention happen, and who controls it?

Whether compliance sits in the protocol or in a smart contract, the mechanism enforcing it needs to be assessed by a team with experience securing financial infrastructure. A compliance control that hasn't been through rigorous smart contract audits is a liability wearing the shape of a safeguard.

The Takeaway

Compliance on public blockchains is an architectural choice that shows up differently depending on the network, and financial institutions need to evaluate it with the same rigor they'd apply to any other piece of financial infrastructure. As tokenization moves further into the financial system, the institutions ahead of the curve will be the ones that can already answer their regulator's first question: where does control sit, and who holds it.

FAQs

What is the difference between Stellar and Ethereum's approach to onchain compliance?

Stellar builds compliance controls, such as trustlines, freezing, and clawback, directly into the protocol. Ethereum has no native compliance features, so issuers implement these controls through smart contracts using standards like ERC-3643.

What is a trustline on Stellar?

A trustline is a permission that an account must establish before it can hold a specific asset. Issuers control who is allowed to create a trustline, which gives them protocol-level control over who can hold their asset.

What is ERC-3643?

ERC-3643 is a token standard for regulated digital assets on Ethereum and other EVM-compatible networks. It defines a framework for identity verification, transfer restrictions, and issuer controls like forced transfers and freezing, all enforced through smart contract logic.

Which approach is better for financial institutions?

Neither is universally better. Stellar's native controls reduce custom development, while Ethereum's application-layer approach through standards like ERC-3643 offers more flexibility to tailor compliance logic to specific regulatory requirements. The right choice depends on the institution's use case, regulatory obligations, and engineering capacity.

Why does it matter where compliance controls live?

Where compliance lives affects how consistent enforcement is across assets, how much custom development and security audits are required, and how much control an issuer retains after an asset is issued. It's a foundational infrastructure decision, not a technical detail to resolve after launch.

How does the Canton Network handle onchain compliance?

Canton is a public but permissioned network with privacy built into the protocol. Transactions happen only between pre-agreed parties, and each participant sees only its portion of a transaction. Regulators can be granted read access as observers on specific contracts, and every state change requires authorization from the parties it affects, so issuer and regulatory controls operate without exposing data to the rest of the network.

How does Midnight handle onchain compliance?

Midnight uses zero-knowledge proofs to keep data private by default while contracts define which facts are disclosed. Institutions can enforce KYC, sanctions screening, and transfer limits by having users prove compliance without revealing identities, balances, or transaction history, and can disclose information to a specific party, such as a regulator, without making it public.