Originally published on Twitter on October 14, 2024.

Last week, I attended the Permissionless III conference in Salt Lake City, Utah. I was pretty surprised by the number of attendees working in compliance, enforcement investigations, or regulatory roles designing compliance frameworks. I knew regulation was coming, but at this conference, it stood out. It's pretty ironic that at a conference named "Permissionless," so many people were addressing the problems that arise when blockchains are - well... permissionless.

This sparked my curiosity, as compliance was not an area I was deeply familiar with before. I spent a lot of time talking to people and asking questions to understand how compliance works today, and I gained a lot of insights into the compliance industry, the competitive landscape, and the business models driving various compliance initiatives.

One key takeaway is that the days of blockchain compliance being a regulatory grey area are limited. As the technology matures, institutional adoption continues, and regulators and lawmakers gain a better understanding of blockchains, companies operating in this young industry will receive clearer guidelines on their reporting obligations and the operational safeguards they must have to remain compliant. Whether we like it or not, compliance is here to stay. These conversations also got me thinking about how we could improve compliance in the future.

Transforming Compliance Through Cryptography

After reflecting on all of this, I've gained significant conviction that there is a way we can transform how blockchain compliance works and is enforced. By leveraging a combination of cryptographic data structures like sparse Merkle trees, execution node extensions, and zero-knowledge proof-powered verifiable compute solutions like the Herodotus Data Processor, we can build a compliance solution that solves many of the problems current compliance solutions have.

Today, the de facto way to perform compliance checks is by making API requests to centralized compliance companies. This usually happens in a B2B manner, can be expensive, and often requires significant effort to integrate into a company's systems. Additionally, compliance is mainly offered as an off-chain service/product to centralized businesses that, by now, usually have clarity on what their legal compliance requirements are. Fully on-chain projects are often left in open waters, with high-risk categories like mixers and smaller lending protocols at risk of being targeted by deposits of tainted funds and being accused of non-compliance for things like money laundering and accepting deposits from sanctioned sources.

Understanding the Compliance Landscape

From my discussions, I observed that companies in compliance fall into two main categories:

Operators

Operators are the frontline entities in the blockchain ecosystem that interact directly with users and handle digital assets. This category includes centralized exchanges (CEXs), decentralized exchanges (DEXs), Automated Market Makers (AMMs), on-ramps, off-ramps, wallet providers, lending platforms, and other services facilitating transactions.

These entities face risks of non-compliance due to their role in transferring and managing assets across borders. They must navigate a complex web of laws and regulations, including Anti-Money Laundering (AML) policies, Know Your Customer (KYC) requirements, sanctions enforcement, and various financial regulations specific to each jurisdiction in which they operate.

Operators are tasked with ensuring that their platforms are not used for illicit activities such as money laundering, terrorist financing, or evading economic sanctions. This responsibility is compounded by blockchain's global nature, where users from any part of the world can access their services. Failure to comply can lead to legal consequences, fines, loss of licenses, and irreparable damage to their reputation.

Moreover, operators often struggle with the balance between adhering to regulatory requirements and maintaining the principles of decentralization and user privacy inherent in blockchain technology. Implementing compliance measures without compromising these core values is a delicate challenge that operators face.

Facilitators

Facilitators fall into two subcategories:

• Data Providers: They obtain high-quality compliance data from publicly available sources such as OFAC sanctioned lists, on-chain interactions with smart contracts like Tornado Cash, social media posts, or privately obtained non-public sources like law enforcement and centralized exchanges.

• Infrastructure Providers: They offer infrastructure aimed at facilitating compliance checks and investigative on-chain forensics.

When speaking to operators, especially small to medium-sized companies, I noticed that the majority of compliance measures taken were reactive to regulation and often the bare minimum required. This makes sense due to the genuine cost associated with maintaining compliance; going above and beyond is a privilege only well-funded, established companies tend to have.

Facilitators typically verify compliance after the fact—after transactions have already taken place. Their clients usually come with clearly defined criteria for their platform's user requirements, which can vary. For example:

• Users cannot be sanctioned addresses in the USA.

• Users cannot have received funds from a sanctioned address in the USA.

• Users cannot have interacted with Tornado Cash anytime after OFAC sanctioned it in August 2022. Source: https://home.treasury.gov/news/press-releases/jy0916

For centralized operators like onramps, offramps, and exchanges, facilitators provide APIs and investigative services to process such requests based on how in-depth the checks the client requires. Pricing can vary, but the proprietary non-public data these platforms have is very valuable, allowing them to have a continuous inbound flow of requests.

For decentralized operators, things get tricky. There's little point in spending funds on compliance checks after the fact, as there's nothing you can really do to stop a user from interacting with your permissionless application. As a developer, I have zero say on who chooses to interact on-chain with my deployed smart contract. My intentions are good, but if someone from a sanctioned country uses my smart contract, or stolen funds get deposited into it, I could potentially be held accountable for the actions of others. This debate has been longstanding, gathering a lot of publicity when Tornado Cash developer Alexey Pertsev was arrested and charged. Source:

https://www.coindesk.com/policy/2024/05/14/tornado-cash-developer-alexey-pertsev-found-guilty-of-money-laundering/

Transaction-Level Compliance

As a developer, I should have the ability to take preventative measures that restrict others' ability to interact with my application. Permissionless blockchains do not necessarily have to mean permissionless smart contracts. Here's my proposed design:

Building Compliance Accumulators

Posting all the sanctioned addresses on-chain to perform checks would be impractical since assets could simply be moved to another account controlled by a sanctioned entity. Currently, off-chain compliance providers keep track of fund movements and evaluate risk based on transaction histories.

At Herodotus, we've been working with on-chain accumulators like our Historical Block Accumulator for over a year now. This accumulator includes all proven historical blocks. Due to the sheer size of data, it would be very expensive to store the whole accumulator on-chain. However, since it's built in a cryptographically provable way, we can simply post the root of this accumulator on-chain and utilize zero-knowledge proofs to show that a historical block hash exists within it.

To enable smart contract-level compliance, we could start operating accumulators for different kinds of compliance criteria. For simplicity, let's see how this could look if the criteria for my application are to prevent anyone who:

• Is a sanctioned address in the USA.

• Has received funds from a sanctioned address in the USA.

First, we collect a list of sanctioned addresses, which is straightforward since we can obtain this from the OFAC website.

Next, we need to identify accounts that have interacted with or obtained funds from these sanctioned addresses—one transaction away, two transactions away, and so on.

In order to track which accounts are sanctioned, flagged, or identified as high-risk, medium-risk, or low-risk addresses, we can append such addresses to an accumulator. These account accumulators can be built using different data structures depending on how they are intended to operate. For example, Merkle Mountain Ranges can be an effective solution for account sets that are to be blacklisted forever since they are cheap to append items to; however, they are not ideal for use cases where an address needs to be removed from the blacklist in the future. Alternatively, a data structure such as a Sparse Merkle Trie could be used to keep track of addresses that have an affiliation with a blacklisted address but whose reputations could change, meaning they would have to be removed from the Sparse Merkle Trie. Sparse Merkle Tries are particularly a good fit for this use case as they can be used to create proofs of non-inclusion. These proofs could allow users to prove that they are not part of accumulators. Such accumulators could be used to build lists of accounts with different risk profiles off-chain, and the roots of these accounts could be committed on-chain as needed.

We could build a large cryptographic data structure, such as a sparse Merkle tree, that contains every account covered by a specific criterion. We compute the root of this accumulator and post it on-chain, allowing smart contracts to perform compliance pre-checks using zero-knowledge proofs.

bool isNonCompliant = compliancePreCheck(0xf453...845f).has(msg.sender);

Here, 0xf453...845f is the smart contract address where we store the root of our OFAC-sanctioned account accumulator.

Tracking Fund Movements

To track the movement of assets and grow these accumulators as transfers happen, we could maintain additional accumulators for accounts based on their distance from the original sanctioned accounts:

1. Master OFAC Account Accumulator

2. OFAC Account Accumulator - 1 tx away

3. OFAC Account Accumulator - 2 txs away

4. OFAC Account Accumulator - 3 txs away

5. Etc… (as needed)

Managing these accumulators and the flow of funds would be a burden, but thankfully, we can automate the construction using execution node extensions like Nethermind plugins and Reth ExEx (Execution Extensions). Shoutout to @0xMarcello for this idea! We can implement a post-execution hook to monitor all transactions in real-time and keep track of updates needed to relevant account accumulators.

Including these updated accumulator roots in each block would be very expensive, especially on Layer 1, so the frequency of posting them on-chain would vary based on budget and risk profile.

Compliant Layer 2s

This approach could be particularly effective on Layer 2s. Imagine a Layer 2 that prioritizes both user safety and regulatory compliance. To bridge onto such a compliant Layer 2, the bridge smart contract would reference the latest available accumulator root. Users would need a low-risk score to bridge assets in or out. Even if a user initially bridges in with a low-risk score, their score could change based on new information added to the accumulator (e.g., verified hacks, thefts, or new associations with sanctioned addresses). Once funds are bridged, updates to our Layer 1 OFAC accumulators could be posted on the compliant Layer 2 on a block-by-block basis, meaning that users' funds would automatically be frozen if they become non-compliant.

Once funds are bridged, updates to our Layer 1 OFAC accumulators could be posted on the compliant Layer 2 on a block-by-block basis, meaning that users' funds would automatically be frozen if they become non-compliant. The Layer 2 could require a compliance pre-check prior to any transaction, and when bridging out, ensure that transactions occur in the same block as accumulator updates, enforcing compliance at the protocol level.

Given the increasing popularity of applications deploying their projects as app-chains, operators running centralized sequencers can be perceived or accused of being intermediaries that facilitate asset transfers of non-compliant assets. By being able to restrict deposits, activity, and withdrawals from such non-compliant sources at a transaction level, they could remain compliant or at least demonstrate that they have taken reasonable precautions to prevent non-compliant activity.

Such a Layer 2 could serve as a day-to-day consumer chain, prioritizing user safety and compliance. Users maintain full custody of their assets, and if control is restricted due to a high-risk score, a formal appeal process can review and potentially restore full control—similar to how credit agencies handle disputes.

On-Chain Risk Scores with the Herodotus Data Processor

To handle more complex compliance criteria beyond simple inclusion/exclusion checks, we can leverage the Herodotus Data Processor (HDP). The HDP is a powerful zero-knowledge-powered runtime for defining extensive sets of on-chain data and running complex computations over them in a fully sound and proven environment.

Data Processor Modules

HDP comes with standard modules for common compute tasks and supports custom modules written in languages like Cairo 1 for tailored computations. Each module is identified by a unique code hash for integrity and reuse. This allows developers to create modules where the inputs, such as the roots of various accumulators, can be openly disclosed, but their individual weights and impact on a user's compliance score can remain private.

The output could be a numerical risk score from 0 to 10, where 0 means no risk detected and 10 is very non-compliant. Smart contracts could then utilize this risk score when conducting their compliance pre-checks, essentially gatekeeping users by requiring a specific compliance condition. For example:

uint8 riskScore = getRiskScore(msg.sender);
require(riskScore < 4, "Compliance check failed");

Cross-Chain Access

The Herodotus Data Processor's ability to access and process data across multiple blockchains allows for a comprehensive view of address interactions, even if they happen on other chains.

It accounts for circumventing detection since a malicious actor could bridge assets via a non-compliant bridge to a Layer 2 network, transfer funds to another account, and bridge back to avoid detection. This capability effectively enables the smart contract to maintain awareness across layers, since normally, a smart contract on the Layer 1 network would not be aware of this asset transfer on the Layer 2. Storage Proofs and the Herodotus Data Processor can be used to bridge the latest state of a supported Layer 2 accumulator back to Layer 1, or vice versa, accounting for cross-chain activity.

This means that the logic defined in a custom risk score module could also take into account an account's activity on Layer 2s and even app chains.

Better UX for End Users

1. Seamless Interaction: Users interacting with compliance pre-check-enabled smart contracts would not even be aware that these checks are performed unless they do not fulfill the compliance criteria. In such cases, the transaction would simply revert.

2. Proactive Compliance: This approach offers significant benefits for centralized services like exchanges. Deposit addresses could be smart contracts that trigger compliance pre-checks, preventing non-compliant funds from ever entering the exchange. This proactive compliance reduces the burden on compliance departments and avoids situations where users' funds are frozen pending investigation.

3. No Money, No Problem: Since funds are never sent to the exchange without passing compliance checks, non-compliant funds never become the exchange's problem.

4. On-Chain Off-Ramps and Spending Products: This approach is also highly beneficial for on-chain off-ramp and spending products like crypto debit cards. These types of products are difficult to operate because the traditional finance industry has stringent regulatory requirements and needs to ensure that the funds used for purchases are from compliant origins. For example, crypto debit card providers such as those offered by Argent on Starknet could leverage the fact that Starknet has account abstraction. Such operators could enforce that a compliance pre-check occurs at the smart contract level to verify that the user is compliant and that their computed risk score fulfills the card operator's required minimum score requirements given the most up-to-date accumulators and risk score available at the time of the transaction.

It would probably become hard to justify non-compliance with such an approach being available. The simplicity of integration—just a few lines of code added to your smart contract—means that developers could no longer claim that compliance is too burdensome or that their smart contracts are permissionless. Ignoring these measures could be seen as negligence. How can you defend against that?

Conclusion

Privacy does not necessarily have to mean non-compliance; it's possible to have the best of both worlds.

Unsurprisingly, the permissionless nature of blockchains has prompted governments and regulators to impose rules and regulations. However, this " after-the-fact " compliance can be challenged with cryptographically verifiable, transaction-level compliance.

I believe that developers with good intentions should be able to sleep at night, knowing that their applications have measures in place that enforce the regulatory requirements imposed by their countries of residence and those of their users.

By leveraging the Herodotus Data Processor's ability to verifiably process massive amounts of on-chain data efficiently, using private custom Data Processor Modules that define custom risk score conditions, we can enforce compliance for decentralized applications directly at the transaction level without requiring any protocol-level changes.

The blockchain can remain permissionless, but the applications on it can enforce compliance at the transaction level, making the applications themselves permissioned.

While the core focus of this post is on the compliance use case, other criteria could be used as well. For example, restricting transactions to accounts that have an age of more than one month and have made more than five transactions or own an ENS name all pave the way for developing a framework that fundamentally enables smart contracts to become permissioned based on arbitrary logic. Logic that can be cryptographically proven using a combination of Merkle inclusion proofs, Merkle non-inclusion proofs, and zero-knowledge proofs in both publicly transparent or private manner, depending on an application's requirements.

If you're interested in working on such a product or have an interesting use case for it, please reach out, and maybe we can collaborate on this!