In the real world, laws govern behavior, but the enforcement of these laws is bound by several practical constraints: the availability of evidence, jurisdictional boundaries, and the capacity of enforcement mechanisms. Courts rely on data to make judgments, data that needs to be somehow obtainable and accessible in their jurisdiction. Similarly, law enforcement bodies like regulatory agencies, police, or the military, are limited by personnel and resources, creating practical boundaries on what can be achieved, even with the clearest laws in place.
On-chain, we face parallel challenges. Smart contracts are often described as systems where “code is law,” but this is an incomplete analogy. While they are excellent at executing predefined logic, their capacity to enforce “on-chain law” is constrained by practical limitations: Availability of data, State Fragmentation and Capacity for Enforcement.
The framework I aim to outline in this post addresses these limitations. It introduces the concept of transaction level criteria enforcement, which I have come to visualize and think of as Sentinels: programmable entities acting as on-chain enforcers. Conceptual guardians for blockchain-based protocols.
These Sentinels would be included in smart contracts or embedded in other levels of the blockchain stacks to enforce rules of engagement defined by their creators - developers who write and deploy smart contracts.
These rules(essentially highly specific criteria), could be used in smart contract execution to determine whether an interaction should proceed or revert.
Currently, transactions are executed directly by smart contracts based on available on-chain data and predefined logic. If the contract’s conditions are satisfied, the transaction proceeds; otherwise, it reverts. This straightforward execution model limits the ability to enforce complex, multi-criteria rules that require extensive data and computational resources.
Under the Sentinel Framework, transactions would first undergo a “pre-check” by a Sentinel. The Sentinel evaluates the transaction against detailed criteria using both on-chain and off-chain data. If the criteria are met, the transaction executes; otherwise, it is reverted.
This improved execution flow enables more sophisticated and granular rule enforcement, allowing transactions to comply with complex and dynamic criteria beyond the capabilities of traditional smart contracts.
Here is an example of what the code for this could look like:
The intent is for this framework to enable developers to write smart contracts that would trigger rules of engagement prior to the execution of logic, function, apply various rules of engagement to different functions, or on the system-level as a core part of layer 1s, or rollups.
To ensure that the Sentinels we task with the enforcement of rules of engagement can do their jobs, we need to give them the blockchain equivalent of what real world law enforcement has access to: the availability of evidence to make judgements on, a way to navigate and enforce laws across jurisdictional boundaries, and the capacity to enforce laws.
Sentinels tasked with very intricate, multi-criteria, compute heavy rules of engagement cannot be confined to data they can access natively within their virtual machine execution environment. Thus we need to address their data hungry needs by giving them access to historical, cross-chain, and off-chain data. Making them self aware and able to read beyond their currently isolated “jurisdictions”.
Finally, once we solve the data limitation, we need to ensure Sentinels have the capacity to make judgements over gigantic amounts of “evidence” - data relevant to enforcing the criteria defined in their rules of engagement. Sentinels need to be able to do this all while being efficient with compute resources available to them on their respective execution environments. Accounting for the fact that these resources (block space and gas limitations) need to be shared with the protocols they watch over, and other applications that live on their respective blockchains.
Availability of Data, State Fragmentation, and Capacity for Enforcement are well-known challenges, and various approaches to tackle them exist. The approaches I will outline below are adaptable and intended to serve as a foundation that can be refined in the future.
Smart contracts have always been capable of enforcing rules through constructs like require() or conditional logic. However, the effectiveness of these mechanisms is limited by the data available to the contract at runtime. This limitation restricts developers from building applications with more complex, dynamic rules of engagement.
Sentinels will requires data to execute any logic. Since decisions need to be made based on data, we need to address the fact that smart contracts are data-starved.
On-chain data is expensive to store and often incomplete. Historical data, off-chain inputs, and external states are typically inaccessible.
This challenge can be addressed with off-chain cryptographic accumulators. Off-chain accumulators are cryptographic data structures that efficiently represent large sets of data or criteria off-chain. They maintain a compact commitment to the dataset, known as the accumulator root, which can be posted on-chain. Examples include Merkle Trees, Sparse Merkle Trees, and Merkle Mountain Ranges.
For example, we could construct a Merkle Tree containing entities that are whitelisted (not-prohibited) from utilizing your application. This image can help you visualize what this accumulator growth would look like:
The type of data structure used to construct the accumulator would depend on the nature of the data that will be utilized as part of your Sentinel criteria checks. For example, Merkle Trees can be used to generate simple inclusion proofs, Sparse Merkle Trees extend this capability by enabling both inclusion and non-inclusion proofs through demonstrating leaf presence or absence at specific positions, making them ideal for allowlists and blocklists. Merkle Mountain Ranges provide inclusion proofs while optimizing for append operations and historical root verification, suitable for accumulating data that won’t change over time.
Such accumulators can be operated by:
Trusted Operators
In this approach, known and trusted entities maintain and update the accumulator roots off-chain, then periodically post them on-chain. This allows for efficient updates, relying on some form of trust that the operator is honest. If a malicious or incorrect root is posted, on-chain dispute resolution mechanisms can be triggered, potentially slashing the operator’s stake or imposing penalties. This model is relatively straightforward to implement and cost-effective, making it a practical starting point, though it does rely on trust and the existence of incentive structures to keep the operator honest.
Operators Building Accumulators in Provable Environments
A more trust-minimized approach involves off-chain validation of accumulator construction within provable runtimes, like the Herodotus Data Processor (HDP). Here, all off-chain computations that lead to a final accumulator root are verified using zero-knowledge proofs, ensuring correctness without relying on a trusted operator. Once proven correct off-chain, the final accumulator root can be posted on-chain with confidence. This approach offers the strongest security guarantees, however currently it’s more expensive and is still maturing.
By choosing between trusted operators or provable runtimes, developers and projects can tailor their criteria enforcement strategy to match their security needs, complexity requirements, and cost constraints.
Regardless of the operator type, the final outcome is the same as accumulator roots are posted on-chain and made available for smart contracts to be referenced during criteria enforcement.
Much like jurisdictional boundaries in the real world, blockchains operate in silos. A contract on Ethereum cannot natively access the state of popular Layer 2s like Optimism, limiting its ability to enforce rules spanning multiple environments.
To address state fragmentation, accumulator roots can be posted on-chain or across multiple chains.
Defining rules is only part of the solution; enforcing them poses significant challenges. Evaluating complex criteria, such as aggregating data from multiple sources or applying computationally intensive algorithms, is often infeasible within the gas limits of a single transaction. Building upon the previously covered approaches to tackle the availability of data and fragmentation, our Sentinels are equipped with all the data they need thanks to off-chain cryptographic accumulators, which can be posted on any required chains.
To give Sentinels the necessary compute capacity, we leverage zk-coprocessors like the Herodotus Data Processor. With off-chain computation supported by zk-coprocessors, Sentinels can evaluate even the most complex rules without being constrained by the computational limits of a blockchain. Logic that normally would not be possible to perform on-chain can be offloaded to zk-coprocessors off-chain, while the required computations are securely handled within Provable Runtimes like the Herodotus Data Processor, a concept we touched upon earlier in the discussion on operators building accumulators in provable environments.
Now armed with the resources and the capacity to make judgments, Sentinels unlock the ability to enforce arbitrary criteria over static, dynamic, and hybrid data or data sets. Lets explore how the developer experience of deploying Sentinels and enforcing criteria could realistically look like.
When thinking about different use cases for criteria enforcement, and places they could fit in, I've identified two distinct architectural approaches. Smart Contract Level and System-Level Enforcement, each offering different trade-offs.
Factors like tolerance for accumulator update latency, cost considerations, enforcement strictness requirements, project scope, and even things like long-term maintenance can all play a role in determining the most suitable approach.
The application layer presents the most straightforward path for implementing dynamic criteria enforcement through smart contracts. This approach would be particularly elegant for scenarios where flexibility and rapid iteration are important.
Consider a platform that gates access based on NFT ownership or reputation scores:
This approach can be applied to other types of smart contracts and even pave the way for new categories of tokens that could enable the creation of wrapped versions of existing tokens that maintain their original functionality and features while also allowing for the enforcement of additional criteria.
For instance, we could create a compliant ERC-20 stablecoin, such as “compliant USDC,” where USDC could be wrapped to become “compliant USDC.” This would preserve its core functionality and feature parity while also adding an additional pre-check to prevent transactions by performing pre-checks against accumulators that track known prohibited on-chain applications or accounts in the jurisdiction of their residence. These pre-checks can be added at any level of granularity, from the sender to the recipient or even transaction-specific logic. The wrapper rules and referenced criteria accumulators can be updated independently of the underlying token being wrapped, making it easy to adapt to new requirements.
Wrapping and unwrapping could be permissionless, without requiring any on-chain accumulator root (to address the liveness issue or prevent anyone from restricting their ownership of the wrapped asset). However, any transferTo event would be prohibited and reverted on-chain if attempted because it would require a criteria pre-check against the root of the accumulator keeping track of prohibited accounts.
This example illustrates why this framework should not be interpreted as one that makes permissionless blockchains permissioned. Instead, it should be viewed as one that gives developers and users control such that there’s a way to opt-into criteria enforcement to ensure you comply with the requirements in your jurisdiction. Wrapped tokens can inherit additional validation capabilities while preserving their original functionality and ownership, allowing users to unwrap them whenever they want.
This mock wrapped USDC code snippet demonstrates how existing tokens can inherit additional validation capabilities while preserving their core functionality:
Certain scenarios require stronger guarantees than smart contract-level enforcement can provide. After all, there’s a genuine financial cost associated with maintaining criteria accumulators, verifying their correctness on-chain, storing them in state so they’re accessible for smart contracts to reference and then finally validate proofs against.
This led me to explore ways to enable integration at the system level, embedding criteria enforcement directly into various levels of the blockchain stack. This would be beneficial if we want to enforce that highly dynamic criteria (changing block by block) hold true across all transactions while maintaining extremely low tolerance for failure and demanding strong synchronization guarantees.
For instance, consider how a Layer 2 protocol could enforce that accumulators are updated atomically within the same block as critical operations, such as bridging funds to another chain.
The exploration of both approaches reveals crucial trade-offs that shape their suitability for different use cases:
Both of these approaches demonstrate how criteria enforcement can be adapted to different requirements and constraints. The framework's flexibility allows for both lightweight integrations and more deeply embedded implementations, with the choice between enforcement levels ultimately depending on specific trade-offs that need to be made.
To illustrate the broad possibilities enabled by criteria pre-checks, consider the following use cases where Sentinels could be used:
Many of these use cases address challenges that have historically limited institutional adoption of public blockchains. Institutions often require the ability to enforce specific criteria to meet regulatory standards and internal risk assessments. With Sentinels, they could deploy services on public blockchains and simultaneously operate within their regulatory boundaries while benefiting from the advantages of public blockchain infrastructure, knowing they can enforce necessary rules. From compliant token standards to secure access control systems, the framework can be customized to fit their needs.
One of the most significant challenges public blockchains and those building on top of them face today is finding a balance between their openness and permissionlessness with the practical need for control and various types of criteria enforcement. This balance is essential for the broader adoption of blockchains across various industries, particularly those that are heavily regulated.
However, even when this balance is defined, it needs to be effectively enforced. The notion that “code is law” holds true only when the enforcers of that law - smart contracts, are equipped with everything needed to execute it effectively. Just as courts and enforcement bodies in the real world depend on evidence, resources, and jurisdiction, on-chain enforcers require data, compute, and state access to uphold the rules given to them.
By providing Sentinels with the resources to make judgments, we can expand the scope of what’s possible on-chain. Developers can build criteria-bound applications with unprecedented granularity, enabling rules that can evolve dynamically, integrate external data, and operate across fragmented states. Ultimately, this can pave the way for a new generation of protocols to operate with the sophistication and accountability of their real-world counterparts.
In this vision, code remains law, but it becomes law that is more adaptable, tailored to developer and end-user needs, and ultimately more useful for the complex requirements of our globally interconnected world.