# Delegatable as An Intents Framework
Contents
1. Introduction
1. Searching for a Better Tomorrow
2. Where We Stand Today
2. Defining Intents
1. Spectrum of Capabilities
2. Explicit Intents
3. Implicit Intents
4. User Consent
3. Intents Across Discrete Time Ranges
1. Bounded Risk
2. Unbounded Risk
3. Expressing Complex Desires
4. Formalizing Implicit Intents
1. EVM State Mutation Snapshots
2. Succinct Zero-Knowledge Proofs
3. Elastic Discrete Time Range Inputs
5. Preparing for the Future
1. Delegatable - An Intents Framework
2. How It Works
3. What is an Enforcer
4. Explicit Enforcers
5. Implicit Enforcers
6. Conclusion
# Introduction
As mentioned in [Intent-Based Architectures and Their Risks](https://www.paradigm.xyz/2023/06/intents) article published by [Quintus Kilbourn](https://twitter.com/0xQuintus/) and [Georgios Konstantopoulos](https://www.paradigm.xyz/team/gakonst) of Paradigm, intents are quickly becoming an important topic in the world of blockchains.
For the last year I've been contributing to the Delegatable framework with [Dan Finlay](https://twitter.com/danfinlay), [Ryan McPeck](https://twitter.com/McOso_), and others. At the core of the framework is a system for managing delegations, intents and event driven access controls. Up until this point we've focused primarily on explicit intents. But I believe much more is possible.
This article aims to establish a shared language for formally describing and acting out user intents. While also outlining a strategy for using succint proofs to enforce intent exeuction.
I'll do my best to formally describe what I have observed as being 4 [axioms](https://en.wikipedia.org/wiki/Axiom) of intents.
- Explicit
- Implicit
- Bounded
- Unbounded
And make the case for why blockchain protocols will radically evolve in the coming years due to [succinct zero-knowledge proofs](https://en.wikipedia.org/wiki/Non-interactive_zero-knowledge_proof#:~:text=Zero%2DKnowledge%20Succinct%20Transparent%20Arguments,truth%20of%20the%20statement%20itself.). And why we should think of succinct proofs as elasitic discrete time range inputs for expansive multi-chain protocols. Eliminating the need for centralized oracles, while still giving protocol engineers access to the complete EVM state history on all execution layers: 1, 2, 3, etc...
And how frameworks, like [Delegatable](https://delegatable.org), will allow users to articulate abstract desires as formally described intents -- radically transforming what we consider average user transaction in the next 1-5 years.
Let's start with the why. *A better tomorrow.*
Offering users super powers -- no matter their technical capabilities.
## Searching for a Better Tomorrow
Let's imagine a hypothetical universe.
A universe with advanced computer technology catering to billions of users all around the world. It's a future where people choose only to interact with advanced computer technology with strong cryptographic guarantees.
If X happens it can be cryptographically verified using Y proving method.
Users love this approach. They don't have to sit around a computer all day clicking buttons.
Instead they can express intents about how they want the computer to act on the their behalf. User describe what future they want an let this advanced computer technology acting out these requests.
What's matter is results. Cryptographically provable results.
This is the default user experience of the Internet in the year 2035. A combination of machine learning and cryptographically verifiable distributed compute powers this future Internet.
The Internet is alive. It's emergent. And it responds to people's wants and needs.
It's a tomorrow that will exist. We simply have to keep building.
## Where We Stand Today
Let's talk about right now. The problems we can solve today.
I want my ETH deposited into the highest earning [liquid staking dervivative protocol](https://www.datawallet.com/crypto/what-are-liquid-staking-derivatives), but I don't want my ETH deposited in the largest LSD protocol. I'm motivated by profit, driven by values of decentralization and want my ETH staking to reflect that.
**My intents are clear.**
The **implicit intent** is I want my ETH deposited in highest yield vault possible.
The **explicit intent** is I don't want my ETH deposited in the largest LSD protocol.
Keep this example in mind as you continue to read. We're going to expand its scale and scope.
But for now what's a basic fact we can take away from this hypothetical example? One take-away is the natural tension between implicit and explicit intents.
**Intents undoubtedly live on a spectrum.**
Some intents are very explicit in nature and easily acted upon. And other intent are so implicit they're unsolvable in practice. For example an intent can range from execute this transaction between these two block numbers or execute infinite transactions that make me the most profitable trader in history of cryptocurrencies.
The explicit, time restricted intent is an easy to solve problem.
The implicit and infinitely complex intent is not an easily solvalable problem.
And somewhere in the middle is a range of products that will transform how we interact with future Internet native communication, commerce and coordination systems.
# Defining Intents
First, let's take a moment to define "intents" as they're understood today.
Let's start with the informal definition of intents provided by Paradigm in the [# Intent-Based Architectures and Their Risks](https://www.paradigm.xyz/2023/06/intents) post.
> Informally, **an intent is signed a set of declarative constraints which allow a user to outsource transaction creation to a third party without relinquishing full control to the transacting party.**
And a more formal definition of intents.
> **Signed messages which allow for a set of state transitions from a given starting state, a special case of which is a transaction which allows for a unique transition**.
## Spectrum of Capabilities
Starting with the ["declarative programming"](https://twitter.com/CannnGurel/status/1663292583550803969) example referenced in the Paradigm article let's explore a few of the axioms the immediately present themselves.
Imperative - What we have today
> (imperative): hop on to ur scooter, go to Domino's around the corner, order item#4, and bring it. here is your 20 bucks; 18 for pizza, and 2 for gas.
Declarative - What we want
> intent (declarative): I will pay 20 bucks for a Hawaiian pizza at my door by 8pm.
The example is perfect -- including a combination of explicit and implicit intents.
The **explicit intent** is "pizza at my door by 8pm" which states very clearly the user expects the pizza to arrive by 8pm... today.
And the **implicit intent** is "pay 20 bucks for a Hawaiian pizza" which loosely describes what the user wants. Even though we as humans take it for granted, because it happen automatically, the following questions have to be formally answered in a way that a machine understands:
- what is a buck?
- what is a pizza?
- what makes it hawaiian?
- will the pizza include standard ingredients? (i.e. wheat dough vs cauliflower dough)
A clear axiom presents itself. User intents live on a spectrum -- from highly explicit to vaguely implicit. And where intents lives on this spectrum deeply impacts how engineers can approach the problem of "acting out" user intents.
Spectrums can be hard to formally describe, but let's do our best.
## Explicit Intents
Explicit intents are clear instructions for how a declarative transaction should be executed.
> Explicit: stated clearly and in detail, leaving no room for confusion or doubt.
Examples:
- Execute the intent between Timestamp A and Timestamp B elapses
- Execute the intent if Governance Proposal A or Z passes.
- Execute tge intent if a pair on the Uniswap protocol has X time-weighted average price.
A maximally explicit intent is describing a transaction conditional that can be enfroced in a single execution cycle without requiring past/future state references.
## Implicit Intents
Implicit intents are vague instructions.
> Implicit: something is understood although not clearly or directly expressed or conveyed
Where and what statements tend to implicit
- Execute the intent if the average price of an asset is X on 3 or more independent protocols.
- Execute the intent if the total volume locked is greater than 100 million in multiple L2 environments.
- Execute the intent if 50,000 unique accounts deposited into the protocol.
# Intents Across Time
Things start to get intersting when we **introduce time** as a variable in the intents equation.
A simple example of an intention is a token swap. Trade token X for token Y in a single epoch. The risk is contained because the intention can be fulfilled and measured in a single block.
*But what about more complex intentions?* Intentions measured across time?
**What if I want to deposit X token in Y vault with the highest yield?**
On what time scale do I measure highest yield? **1 day? 4 years? 52 weeks?** Does observation length depend on other health factor signals? What are those other health factor signals?
Or what if I want to change my exposure risk? Split my X token deposit into low/high tranches?
Can that be expressed as an intent?
How do we measure risk? Isn't that different for everyone?
These are hard problems to solve in adversarial blockchain environments.
Intents live on a minimum of two spectrums.
- Implicit <=> Explicit
- Unbounded <=> Bounded
Implicit intents will naturally have more unbounded risk.
Explicit intents will naturally have more bounded risk.
Risk can be entirely bound to a single execution cycle. Which is to say there is no continued exposure to risk or second order effects that can be derived from fullfilling the intent beyond the "block" it was executed in. Intents that are comprised of explicit statements are more likely to have bounded risk exposure, because it's easier to formally describe intent execution paths.
An intent that is entirely unbound is exposed to *infinite* amounts of risk and second order effects, because we are dealing with infinite observation and probability space.
An example of an implicit intent with large unbounded risk is "Make me the most profitable cryptocurrency trader in history" and is accompanied with a delegation for 1 billion USDC on Ethereum mainnet. Theoretically this is a solvable intent. But it's not an intent the free markets are going to solve anytime soon.
## Bounded Risk
**Bounded risk** is when an intent can be 100% fulfilled in a single block. Examples of this include token swaps or depositing in specific vault after X amount of time has elapsed.
The intent is either fulfilled or it isn't.
The risk of the intent is bounded to single execution cycle i.e. a finalized block. No future state changes will alter the outcome of the intent, and no historical state references, besides what was available during runtime, is required to satisfy the intent.
## Unbounded Risk
**Unbounded risk** is when intent can NOT be reliably fulfilled in a single execution cycle. The intent outcome or execution prerequisites is measured across time.
Any intent which includes time as a variable will always have unbounded risk. A simple example of an intent with unbounded risk is depositing a token into the highest yield vault, because how you measure "highest yield" is dependent on how you sample data across discrete time ranges.
Any intention that requires observation of historical data to optimally satisfy an intent, is always met with the problem of unbounded risk. The first major problem is an infinite range of potential observation points that can be measured. You have to know where to even begin looking when time is introduced a factor in the intention equation.
Unbounded risk can be summarized as ***"You know what you know. You know what you don't know. But you don't know what you don't know."*** which is an another way of saying we need to know what history is worth observing if we're going to make accurate predictions about how the future will unfold.
If we require 2 or more blocks to accurately compute an optimal path for intention execution, we are immediately exposed to second order risks and **potential failure of intention fulfillment.** and therefore need to make sure we have the a fairly accurate map of the world.
And the only way to minimize unbounded risk is by defining explicit future state positions and/or using historical data sampling to constrict intent execution pathways.
## Bounded vs Unbounded Intent Execution
Most onchain protocols today only have access to the EVM state available during execution.
For example the Uniswap automated liquidity protocol is powered by a constant product formula. The simple formula `x * y = k` is how prices are derived between token pairs in the Uniswap protocol. And the `x` and `y` variables are updated every time an order is fulfilled.
<img width="100%" alt="simple-intention" src="https://github.com/delegatable/research/assets/3408362/6d41b031-d353-4ad8-a48a-fce2b5bc8ce3">
Either your token swapping order gets fulfilled or it doesn't.
Arguably this is what blockchains are great at and why people love them. But what if we could maintain cryptographic guarantees, while using historical EVM state mutations that are no longer available during execution runtime, to inform how our token swapping order should be fulfilled?
What if I want use the average price of a basket of assets, to determine if my order should be automatically filled? But that average price data isn't available at runtime?
<img width="100%" alt="complex-intention" src="https://github.com/delegatable/research/assets/3408362/967688da-b81c-4612-ba06-e57f6734d45b">
I need look into the past to determine what outcome is likely in the future.
## Managing Unbounded Risk
**What is risk?** Risk is uncertainty about a specific chain of events occuring over time.
A time tested strategy for **predicting the future** is by **observing the past**.
Hence observation of history is an optimal strategy for reducing risk in the future.
### Measuring EVM State Mutations Across Time
**DISCLAIMER:** I consider traditional "oracles" to be insufficient for powering an onchain future. Relying on data oracles is NOT the best method for powering a future with 1,000's of rollups, and therefore won't consider it to be a potential long-term solution for the use case I am about to describe.
Today most onchain protocols only observe state that is available during runtime.
When swapping X token for Y token you only care about the price of each asset during execution -- even though you're probably using historical trading data to determine if you want to make that swap to begin with, but that's besides the point.
We can't expect all protocols to behave in this simplistic manner. If we want Internet scale for blockchain technologies, we need to solve Internet scale engineering problems.
It doesn't make sense to ignore 99.99% of the previous EVM state if want to introduce more advanced feedback loops into protocols. More specifically if we want to evolve into more advanced Open Finance protocols like a "flat coin" that use global economic indicators to track signals for inflation and deflation, we need to introduce novel methods for re-introducing historical onchain data in cryptographically verifiable artifacts.
You might be asking right now...
*How can we access historical onchain data during transaction execution and block building?*
**Great question!**
**Storage proofs** and **non-interactive succint zero-knowledge proofs**.
*That's it.* And by combining these two technologies we can manage unbounded risk inherit in implicit intentions, by using snapshots of EVM state mutations to create predictions about future outcomes in the form of succint proofs.
**Keyword being succint.**
By compressing long-running computations of historical EVM state mutations into cryptorgaphically verifiable artifacts that enable us (users) to make truthful observations about measurable patterns across discrete time ranges, we can craft implicit intents with minimal obounded risk by using the past to inform what's possible in the future.
What does "discrete time range" mean in this context anyways?
> **Discrete time** views values of variables as occurring at distinct, separate "points in time", or equivalently as being unchanged throughout each non-zero region of time ("time period")—that is, time is viewed as a [discrete variable](https://en.wikipedia.org/wiki/Discrete_variable).
>
> A **discrete signal** or **discrete-time signal** is a [time series](https://en.wikipedia.org/wiki/Time_series "Time series") consisting of a [sequence](https://en.wikipedia.org/wiki/Sequence "Sequence") of quantities.
>
> Unlike a continuous-time signal, a discrete-time signal is not a function of a continuous argument; however, it may have been obtained by [sampling](https://en.wikipedia.org/wiki/Sampling_(signal_processing) "Sampling (signal processing)") from a continuous-time signal. When a discrete-time signal is obtained by sampling a sequence at uniformly spaced times, it has an associated [sampling rate](https://en.wikipedia.org/wiki/Sampling_rate).
>
> [Discrete time and continuous time - Wikipedia](https://en.wikipedia.org/wiki/Discrete_time_and_continuous_time)
EVM blockchains measure computation in explicit discrete time ranges -- blocks. Blocks contain uni-directional functional cryptographic operations, known as transactions, roughly every 14-20 human seconds.
***Why is this important?***
# Expressing Complex Desires
Let's go back to our original example.
> I want my ETH deposited into the highest earning liquid staking vault, but I don't want my ETH deposited in the largest liquid staking vault. I'm motivated by profit (within reason) and driven by values of decentralization.
The intention is complex, abstract and most likely abused if we don't add explicit conditions.
The intention is complex and abstract because it implies observation across a potentially infinite* range of EVM state mutations storage slots. For starters we need to know which liquid staking derivative protocols are even worth observing?
We can't possibly sample and measure every single address in the EVM universe. We need to know where to start looking. Where do we tell the searchers to start observing and data sampling?
We know we need to go from an infinite observation sppace to a few finite points. *How can we do this?*
**Thankfully humans are great at generalized observations.** We have natural "intuition" about where to begin complex analysis. We are great at filtering the initial noise. And solving the problem of knowing what questions are even worth asking.
Realistically a [token curated registry](https://medium.com/hackernoon/token-curated-registry-tcr-design-patterns-4de6d18efa15) is a simple and effective solution for creating a general proxy for curation of the top [1...N] liquid staking derivative protocols. And it's easy to imagine a world where a simple economic incentive can be created for the curation of a full range of Open Finance protocols.
A social layer is arguably the most optimal (lowest cost and highest value) method for narrowing EVM state observation areas with 99.9 efficiency -- going from a nearly infinite observation range to a much more manageable and finite observation area. Offloading from machine to human, the challenge of formally defining what EVM state is worth observing.
<img width="100%" alt="high-value-storage-slots" src="https://github.com/delegatable/research/assets/3408362/f956e069-298b-43f2-834c-3cbdd59fc3f3">
Once we can identity the top 10 liquid staking derivative protocols we can answer the question "What is the second highest earning liquid staking vault?" using cryptographically verifiable zero-knowledge succinct proofs that measure EVM state mutations via storage proofs.
## EVM State Mutation Snapshots
When I look at the spectrum of intents. From explicit to implicit. One thing becomes clear to me.
Explicit intents have minimal state conditions.
Implicit intents have maximal state conditions.
If I want to limit my transaction execution between two timestamps I only need 2 data points.
If I want to find the highest yield vault for stake ETH, there is N data points, relative to the number of actors/entities providing yield for ETH that are worth observing. Accurately and regularily execute implicit intents will require snapshots of EVM state mutations across discrete time ranges, represented as succinct proofs, which can than be used as cryptographically verifiable smart contract function inputs, that verify the output of long-running computations, not suitable for executing in compute bound blockchain environments.
<img width="100%" alt="tvl-apy-samples" src="https://github.com/delegatable/research/assets/3408362/5a7b6583-1c41-4cf2-a11c-2266759b6042">
The question becomes... *How can we generate these succinct proofs?*
## Succinct Zero-Knowledge Proofs
A succinct proof is a way to provide evidence or verification of a statement or claim using a relatively small amount of data or computational resources. It is a compact representation that allows someone to check the validity of the claim without having to reproduce the entire process that led to the claim. In the context of blockchain and cryptography, succinct proofs are often used to demonstrate the correctness of computations or transactions without revealing sensitive information or requiring extensive computational resources.
Succinct proofs are cryptographically verifiable artifacts of long-running computations.
For example let's say I want to cryptographically prove the average price of stETH for last 90 days across 3 of the biggest money market protocols on 10 of the largest rollups. That's a lot of data. No smart contract **ever** will be able to consume that amount of raw data. It's simply not how blockchains and smart contracts are designed.
But what if we could compress that data? What if we could make it succinct?
> **Succinct:** briefly and clearly expressed
A succinct zero-knowledge proof is the probably the answer we're looking for.
Vitalik Buterin recently [outlined](https://vitalik.ca/general/2023/06/20/deeperdive.html#what-kinds-of-proof-schemes-can-we-use) types of proofs that can be used for managing cross-chain keystores, for when Account Abstraction wallets are the default onchain user experience.
- **Merkle proofs**
- **General-purpose ZK-SNARKs**
- **Special-purpose proofs (eg. with KZG)**
- **[Verkle proofs](https://vitalik.ca/general/2021/06/18/verkle.html)**, which are somewhere between KZG and ZK-SNARKs on both infrastructure workload and cost.
While Vitalik states he believes these types of proofs aren't suitable for Decentralized Finance, due to the speed.
> Some of these speeds for trustless cross-chain operations are unacceptably slow for many defi use cases; for those cases, you do need faster bridges with more imperfect security models. For the use case of updating wallet keys, however, longer delays are more acceptable: you're not _delaying transactions_ by hours, you're delaying _key changes_.
The counter-argument could also be made most of today's DeFi protocols won't last another couple of years, and the Open Finance protocols of tomorrow, will use elastic discrete time range inputs as protocol feedback loops (e.x. [RAI PID Controller](https://medium.com/reflexer-labs/summoning-the-money-god-2a3f3564a5f2)) and slowness is actually a desirable property for most global open finance protocols of the future.
And in a world with 100's or 1,000's of rollups, all with highly-valuable economic signals, the only reasonable answer is to accommodate for this complexity is via succinct proofs.
If you're not familiar with storage proofs Laconic offers a great introductory to storage proofs in [# What Is a Proof and Why Do You Need One?](https://www.laconic.com/blog/what-is-a-proof) which includes code samples and a user journey.
Described succinctly a succinct proof is a cryptographic construct that enables efficient verification of a claim or statement by succinctly representing the evidence or computation underlying the claim. It leverages advanced mathematical techniques and cryptographic primitives such as zero-knowledge proofs, succinct non-interactive arguments of knowledge (SNARKs), or bulletproofs to achieve its objectives.
Succinct proofs are particularly useful in situations where the computation required to verify a claim is resource-intensive, time-consuming, or involves sensitive information. By providing a compact representation of the proof, they allow third parties to efficiently verify the claim without needing to reproduce the entire computation or access the underlying data.
Applied at the application layer it means we can use succinct proofs to represent historical analysis of EVM chain state mutations as logic operator conditionals for event driven transactions i.e. safeguards to bound risk inherit to implicit intentions.
### Real-World Example
The Lido protocol generates Merkle Patricia proofs ( i.e. elastic discrete time range inputs) from Curve protocol EVM state mutations.
[https://github.com/lidofinance/curve-merkle-oracle](https://github.com/lidofinance/curve-merkle-oracle "https://github.com/lidofinance/curve-merkle-oracle")
We are still early in the zero-knowledge computation meta, but the proof is in the pudding. Succinct proofs are going to change the course of blockchains, wallets and protocols.
## Elastic Discrete Time Range Inputs
Let's talk about "elastic discrete time range inputs" as the foundation for implicit intents.
We've informally established implicit intents require context. Context meaning large amounts of data. But blockchains aren't good at processing large amounts of data. However they're great at validating cryptographic artifacts.
Succinct proofs can be thought of as complex state (mutations occurring in elastic discrete time ranges) represented as optimally compressed cryptographically verifiable artifacts.
As referenced above, Lido uses Merkle Patricia proofs to generate cryptographically verifiable artifacts to proving the average cost of stETH using EVM state mutations happening in the Curve protocol.
If we extrapolate out this trend/pattern you end up in a world with a rich ecosystem of Open Finance protocols using elastic discrete time range inputs to represent complex EVM state mutation snapshots as maximally compressed succinct proofs.
For example if I want to create a better fiat currency, I may want to aggregate data samples from multiple open finance protocols as proofs. And use those major economic activity state mutation snapshots as fiat protocol inputs. Using those succinct proofs as cryptographically verifiable signals for adjusting a digitally native fiat currency.
But for simplicities sake let's start with a more tangible example.
Let's say I want the average price of stETH for last 90 days, using state mutation snapshots from 3 of the biggest protocols, on 10 of the largest rollup. Why? To create the world's biggest synthetics ETF marketplace without relying on centralized oracles.
And the only way to achieve this at scale, without the potential for abuse and capture, is to build financial algorithms that take raw state inputs from sibling money market protocols, to determine the spot price of our algorithmically generated synthetics.
But blockchains are limited in their capacity to process that level of information. We simply can't express high-fidelity representations of reality (digital or physical) as raw smart contract protocol inputs.
Let's start with the naive example of how me implement our hypothetical synthetic ETF protocol.
<img width="100%" alt="naive-approach" src="https://github.com/delegatable/research/assets/3408362/7a26f494-e98f-4c8b-9e15-82fd6026e647">
If we continue to build blockchain protocol like we have been for the last several years, our architecture diagrams might look something like the above. Our hypothetical synthetics ETF protocol is taking artificial inputs from external money markets through oracle feeds.
Arguably a naive way to build Open Finance protocols, when the alternative is cryptographically verifiable succinct proofs generated using historical blockchain state mutations.
<img width="100%" alt="succinct-approach" src="https://github.com/delegatable/research/assets/3408362/a437bc67-f0d9-4a36-a83c-60ff96da3784">
If one wants to build an elegant, robust and autonomous Open Finance protocol that will stand the test of time, the only viable long-term strategy is blockchain mutation snapshots represented as elastic discrete time range inputs in the form of succinct zero-knowledge proofs.
# Preparing for The Future
Blockchains are evolving. Advancing into more complex systems -- capable of Internet scale.
The future is exciting. But a lot of work still remains.
We need a better way for users to express their preferences and desires in this future world powered by cryptography. A simple and elegant way to capture the wants, needs and preferences of people that can be processed by advanced computer technology. And we need a framework for developers and engineers to formally express these human desires. Humans aren't robots. We don't speak in code. Our desires are abstract and multi-faceted.
But we have to operate in a mechanistic world. A universe represented as succinct proofs. A universe with long running operations.
But that doesn't mean we have to sacrifice user experience, while maintaining decentralization.
## Delegatable -- An Intents Framework
Delegatable is an EVM smart contract framework for composing intents.
More precisely, up until this point in time, it's been a framework for defining and composing explicit intents. But it's unique approach to intent composition, means implicit intents are also possible.
#### What Makes Delegatable Unique?
Delegatable has a unique approach to rules enforcement.
Unlike other EVM rules frameworks, [Uniswap V4 hooks](https://github.com/Uniswap/v4-periphery) and [Safe Modules](https://docs.safe.global/learn/safe-core/safe-core-protocol/modules), delegatable doesn't require new functionality to be installed at the runtime layer. Whenever a new Enforcer is deployed on a blockchain, it instantly becomes available to any smart contract inheriting the Delegatable framework, though counterfactual statements and offchain intent signatures.
## How It Works
When a user decides to construct an "intent based transaction" they first decide what type of rules they want to include. Explicit intents includes statements like only execute the transaction between these blocknumbers or timestamps. Implicit intents are more abstract representations of past and future EVM state mutations represented as succinct.
Whether the intent is implicit or exlicit the behavor the result is the same.
The conditional operators will be contained in a Delegatable Enforcer.
And users can decide what enforcers are most relevant to them.
## What is an Enforcer?
Enforcers are onchain modules that constrain EVM runtime execution.
Enforcers are referenced during the transaction signature signing process. And it's what allows them to be composable, while also not requiring any additional onchain actions once an enforcer once has been deployed -- giving users the ultimate power for selecting transaction enforcement pattern that match their intents, without relying on a third-parties to upgrade core smart contract logic.
For example the `BlockNumberAfterEnforcers` enforcer limits when a transaction can be executed using the block number as the operation comparator. A user can sign an offchain invocation referencing the BlockNumberAfterEnforcers module and create a statement like "I only want this transaction to be valid after block 420."
The `BlockNumberAfterEnforcers` could also be used in combination with the `DistrictUniswapV3TwapAboveEnforcer` to create a statement like "I only want this transaction to be valid after block 420 and if the time-weighted average price of X token is above Y value."
Enforcers can be thought of as boxes that contain rules for how and when a transasction can be executed. The boxes can be stacked together. And users have full control over how the boxes are stacked for them. In other words users pick Enforcers that match their transaction execution requirements and intents.
## Explicit Enforcers
Explicit enforcers are Delegatable modules that constrict execution runtime to explicit intents.
Examples of explicit enforcer modules:
- [BlockNumberAfterEnforcer](https://github.com/delegatable/delegatable-sol/blob/main/contracts/enforcers/BlockNumberAfterEnforcer.sol)
- [BlockNumberBeforeEnforcer](https://github.com/delegatable/delegatable-sol/blob/main/contracts/enforcers/BlockNumberBeforeEnforcer.sol)
- [TimestampAfterEnforcer](https://github.com/delegatable/delegatable-sol/blob/main/contracts/enforcers/TimestampAfterEnforcer.sol)
- [TimestampBeforeEnforcer](https://github.com/delegatable/delegatable-sol/blob/main/contracts/enforcers/TimestampBeforeEnforcer.sol)
- [DistrictUniswapV3TwapAboveEnforcer](https://github.com/district-labs/delegatable-enforcers/blob/main/contracts/DistrictUniswapV3TwapAboveEnforcer.sol)
- [OZGovernorProposalStateEnforcer.sol](https://github.com/district-labs/delegatable-enforcers/blob/main/contracts/OZGovernorProposalStateEnforcer.sol)
Each enforcer is responsible for measuring a specific EVM state position. User select what enforcers they want to use when creating an intent based transaction. Any contract inheriting `Delegatble.sol` can interact with any existing or future enforcer module deployed on the same blockchain or execution envrionment.
Timestamp enforcers measure time, governance enforcers measure proposal outcomes, and finance enforcers measure time-weighted average prices.
Below is an example of a `TimestampBeforeEnforcer` module.
```solidity
pragma solidity 0.8.15;
import "../CaveatEnforcer.sol";
contract TimestampBeforeEnforcer is CaveatEnforcer {
function enforceCaveat(
bytes calldata terms,
Transaction calldata transaction,
bytes32 delegationHash
) public override returns (bool) {
uint64 timestampThreshold = BytesLib.toUint64(terms, 0);
if (timestampThreshold > block.timestamp) {
return true;
} else {
revert("TimestampBeforeEnforcer:expired-delegation");
}
}
}
```
It's incredibly simple. And that's by design. Enforcers should be easy to reason about. When systems are built using independent building blocks it allows for composability.
### Proof of Concept - Giftee Cards
[Giftee Cards](https://www.giftee.cards/) proof of concept demonstrates how to use timestamp and spending enforcers.
Users can generate "digital gift cards" for friends by creating an ERC20 delegation that can be limited by time and/or transfer destination. Under the hood what's happening an ERC20 transfer delegation is generated and the `TimestampAfterEnforcer` and `TimestampBeforeEnforcer` enforcers limit when the delegation can be executed.
The intents are very explicit.
The receipient of the ERC20 delegation can only execute the transfer between two timestamps and/or to a specific Ethereum address.
## Implicit Enforcers
Implicit enforcers are not yet part of the [Delegatable framework](https://delegatable.org/) experience. But they can be. We can give Web3 Experience Architects super powers. We can unlock a new Era of compute. We can answer the question... ***"What's possible?"***
Here is how I would define and construct implicit enforcers.
Implicit enforcers are Delegatable modules that constrict execution to risk unbounded intentions.
Referencing our original example...
> I want my ETH deposited into the highest earning liquid staking vault, but I don't want my ETH deposited in the largest liquid staking vault. I'm motivated by profit (within reason) and driven by values of decentralization.
Let's explore how we could solve this problem using the Delegatable framework with implicit enforcers.
For starters we have to think about how we can formally describe our intentions as enforcers.
<!-- <img width="100%" alt="delegable-implicit-enforcers" src="https://github.com/delegatable/research/assets/3408362/211488c3-c41b-4f3f-b678-b3962346db9c"> -->
The enforcers would use succinct proofs to constrain the EVM execution runtime.
Instead of using live EVM state, snapshots of historical blockchain state mutations are represented as zero-knowledge succinct proofs. And limit when the user's intent can be acted upon. If certain conditions aren't met, which are measure over time, than the intent will never be fulfilled.
What are the steps to generating these proofs for users?
- Identify observable EVM state mutation boundaries e.x. token curation registry
- Normalize EVM state mutation artifacts e.x. average yield represented in 18 decimals
- Incentivize provers to create standardized succinct proofs e.x. average APY every 24 hours
- Delegatable enforcer consuming succinct proofs and user intentions e.x. only deposit my assets in vaults with an average APY median above 5% on a 182 day spread.
In practice that might look something like the diagram below.
<img width="100%" alt="implicit-enforcer" src="https://github.com/delegatable/research/assets/3408362/7636c61b-2f6e-4771-9092-615006e93411">
We can use an token curation registry to identify the protocols worth observing, apply data normalization operations, generate predictable storage proofs and create a new Delegatable enforcer that consumes those proofs to limit when a transaction intent can be executed.
At minimum we require two implicit enforcers for intention thought experiment:
- Total Volume Locked Enforcer
- Average Yield Enforcer
We need to know the **average yield** generated by each liquid staking protocol protocol, so the we can deposit our ETH into highest average yield protocol and fulfill the intention "I want my ETH deposited into the highest earning liquid staking vault." because at the end of the day I'm still motivated by profit.
And we also need to know the **total volume locked** in each observable liquid staking derivative protocol is, so we can derive which operator is the most "centralized" and satisfy the intent conditions of "I don't want my ETH deposited in the largest liquid staking vault" because I want to support minority LSD operators.
In short we need to compress two historical EVM state mutations snapshots into transaction execution conditionals (i.e. elastic discrete time range inputs) represented as succint zero-knowledge proofs, so we can use them as inputs into future `TotalVolumeLockedEnforcer.sol` and `AverageYieldEnforcer.sol` enforcer modules.
# Conclusion
As recognized by many, blockchain technology is quickly evolving and we need to re-imagine the Web3 user experience.
> "Despite the challenges, achieving scalability, wallet security, and privacy for regular users is crucial for Ethereum's future. It is not just about technical feasibility but about actual accessibility for regular users. We need to rise to meet this challenge."
>
> Vitalik Buterin - [The Three Transitions](https://vitalik.ca/general/2023/06/09/three_transitions.html)
We are moving towards more complex abstractions. Abstractions that will help the Ethereum ecosystem scale to millions and billions of users.
*But we're not there yet.*
We still have to find the patterns that scale technically and are also approachable by developers, engineers and users.
Intents, succinct proofs and zero-knowledge proofs are a part of that future.
If the default user experience of the Internet in the year 2035 is actually going to be a combination of machine learning and cryptographically verifiable distributed compute, we first need to start with the basics. We need to establish shareable patterns and formalize language about constructing safe user experience journeys in the form of explicit and implicit intents.
The [Delegatable framework](https://delegatable.org) offers a path towards that future.
Zero-knowledge succinct proofs have been mainly discussed in relation to how they will transform blockchain scalability. But we still have yet to explore how these technologies will also transform onchain protocols and accompanying user experiences.
In addition to scaling the infrastructure layer we need to start talking about scaling user experience layer while maintaining the highest level of security and cryptographic guarantees.
Sign in with Wallet
Connect another wallet