Introducing Essential: We Are Intents

Essential is building intent-based infrastructure & tooling to accelerate the transition from value extraction to intent satisfaction.

Introducing Essential: We Are Intents

Introducing Essential.

We are building intent-based infrastructure & tooling to accelerate the transition from value extraction to intent satisfaction.

We believe intents are a superior format for structuring and executing user preferences. With our products, we aim to minimize extractive behavior and maximize user satisfaction.

Our Philosophy: From Value Extraction to Intent Satisfaction

The idea to build intent-centric infrastructure came from our experiences designing and building cutting-edge blockchain protocols. We had spent years attempting to solve the problems of speed and scalability, but we realized something was missing: a focus on user outcomes.

The blockchain space has become increasingly extractive, with parties at every point in the transaction supply chain clipping the ticket, leading to worse outcomes for end users. The technology that was supposed to remove the need for middlemen has evolved into an ecosystem based on the systemic exploitation of end users, with sophisticated intermediaries leveraging their outsized capital and insider knowledge to extract value.

The current transaction supply chain. Left-to right: users; mempool; searchers; builders; relayers; block producer; block of transactions.
Every intermediary between the user and the inclusion of their transaction in a block acts in their own self-interest and takes a cut, reducing the ultimate value received by the user (image source: Chainlink)

Seeing this, we decided that no matter how much we worked on protocols that optimized for throughput or scalability, we weren’t making a positive difference if users were being actively disempowered by the hierarchies and power structures within those systems.

With this motivation in mind, we started working on an MEV-focused project, with the goal of building infrastructure to mitigate the centralizing threat posed by the existence of MEV - specifically, the ongoing transfer of control, influence, and value to players at the top of the transaction supply chain (validators, builders, searchers, and so on).

After researching the pitfalls in the current transaction supply chain and the design flaws that incentivize MEV extraction, we realized that most efforts to minimize the negative effects of MEV - while noble and well-intentioned - have only led to the introduction of more and more intermediaries, most of which need to take an additional cut to sustain their existence. However, to their credit, they have also spurred a technological arms race, incentivizing teams like ours to pursue innovative new solutions.

Our research and ideation revealed what we believe to be the most promising alternative solution: intent-based architectures. This new paradigm is the key to solving many of the above problems, while also opening up several additional avenues for improving user outcomes. Inspired by the possibility of reviving the foundational values that drew us to the blockchain movement, we came together to start Essential.

Our mission is to accelerate the transition from value extraction to intent satisfaction.

Essential: Our mission is to accelerate the transition from value extraction to intent satisfaction.

What Are Intents?

Intents vs. Transactions

An intent is a message signed by a user to express a desired outcome. It contains information about certain parameters, and a solution is only valid if the conditions relating to those parameters are met. Unlike a transaction, an intent describes an ideal end state, rather than a set of instructions to be executed.

A transaction specifies the journey, while an intent specifies the destination.

Intents are journey-agnostic. As long as the desired outcome is reached according to the rules set by the user, the path to that destination is inconsequential to the user.

Who creates the journey? Transactions and intents both require the user to delegate construction of the ultimate computational path (the "journey") to a third party. The core differentiator is who gets to define this path. Currently, transactions are constructed on behalf of users by applications, which consider the user’s preferences in isolation, rather than in the context of the market as a whole.

When a transaction is constructed by a user-facing application, its on-chain "journey" is partly based on explicit user inputs (e.g. swap Asset A for Asset B), but also enshrines many implicit “preferences” that may not reflect the user's actual goals. For example, users visiting the website of a specific DEX will be limited to liquidity in that protocol's smart contracts. Such pre-defined factors are usually invisible to users, and significantly limit the possible solution space.

Explicit vs. implicit user preferences: example transaction on Uniswap. Explicit preferences: Swap 0.05 ETH for USDC. Implicit preferences (customizable if desired): Allow Uniswap to auto-set slippage percentage. Accept as little as 92.66 USDC for swap. Revert transaction after 30 minutes. Implicit preferences (not customizable): Use liquidity from Uniswap ETH/USDC pool.Pay $3.80 network fee to LPs.
The above example uses a simple Uniswap trade to illustrate the possible "preferences" imposed on an unsophisticated user, which are then enshrined in the transaction this application creates on the user's behalf

Products such as DEX aggregators aim to mitigate this limitation, but are only abstracting the problem up a layer, as they still limit potential computational paths to services and liquidity pools that they support. The real solution lies in delegating transaction construction to specialized entities that can consider the totality of available information and opportunities to find the best outcome for the user. This is the purpose of intents.

Understanding Intents: An Analogy

A simple yet intuitive analogy for understanding intents is getting a taxi to the airport for an early flight. Let’s say a user has the following conditions as part of their set of preferences:

  • Origin: Hotel
  • Destination: Airport
  • Arrival time: 6:30am
  • Capacity: 6 people + suitcases

With these preferences in mind, we can examine the difference between intent-based and transaction-based systems:

  • An intent-based system is like a rideshare app. The user specifies the above conditions, and the app takes care of finding a suitable driver, determining the best route to avoid traffic, etc. Because the app has access to a wealth of information about factors like driver availability and traffic conditions, it can provide the user with the best possible solution. If the user pre-orders through the app the night before, sure enough, they can expect a 6-person van to show up at 6am to get them to the airport on time - or, if there are no large vehicles available, two regular cars instead.
  • A transaction-based system is like hailing a taxi in an era before smartphones existed. Instead of ordering through a specialized service, the user has to calculate what time they need to leave in order to arrive on time, and then walk out onto the street early, say at 5:45am, to find a taxi that is available and large enough for their group. Once they manage to hail a taxi, the driver must then figure out the best route to get to the airport by 6:30am - all without access to GPS or live traffic data. If either the user or the driver planned imperfectly, the user can get a poor outcome (arriving late and having to rush through the airport), or completely fail (missing their flight).

In both cases, the user specifies the same set of preferences (get 6 people from the hotel to the airport by 6:30am). However, in one situation, the user can express their conditions in one place with the peace of mind that it will be taken care of by a specialized service provider, whereas in the other situation, the user must exert additional effort to plan ahead and find someone to fulfill their conditions while still facing a higher chance of getting a worse outcome.


To extend the analogy, now imagine that instead of a rideshare request only being sent to a single app, it is sent to all possible providers, such as Uber, Lyft, Bolt, Cabify, etc. These entities - analogous to solvers in an intent-based system - must now compete to offer the best outcome to the user.

They all specialize in finding the best ride for end users, but have different information sources and strategies that are geared toward specific conditions. One provider may find a way to offer the user a faster trip by, for example, sending two smaller cars instead of one large van. Another may be able to offer a lower price by combining several compatible intents and leveraging a shared shuttle service. While both of these solutions may satisfy the user’s intent, the winning solution will be the one that provides the best solution, based on the weight placed on the various parameters by the user (e.g. whether to prioritize price over journey time).

In an intent-based blockchain system, a network of specialized solvers ingests batches of user intents and competes to find the best solution - namely, one that a) satisfies as many intents as possible, b) to as great an extent as possible, c) as efficiently as possible. As such, the final solution does not necessarily include state transitions that are one-to-one traceable to the composite intents. In fact, one of the core benefits of an intent-based system is that solvers can leverage coincidences of wants, off-chain liquidity sources, and other methods to reach an end state that maximally satisfies user intents with as little on-chain computation as possible, reducing overall costs.

Implications for MEV

As an added benefit, participating as a solver in an intent-based system requires very similar skills and resources as running an MEV searcher. We aim to leverage this synergy to convert searchers into solvers and usher in a new paradigm: “Compute to Satisfy”. Rather than finding ways to extract value, we want searchers to use their knowledge and power to find optimal solutions for users while still making a profit.

In a competitive solver network, the criterion for winning is to provide the highest level of user satisfaction. Because inclusion is predicated on proposing the best possible solution for users, solvers are incentivized to bid value back to users. By design, any solver that attempts to extract value from users will be out-competed by those that optimize for user satisfaction.

Essential Technologies

To achieve our mission to accelerate the transition from value extraction to intent satisfaction, we are building several products that will drive the blockchain ecosystem toward an intent-centric future.

1. DSL for Intent Expression

Currently, there is no standard mechanism for expressing, composing, and parsing intents. To aid ecosystem-wide composability and encourage widespread development of intent-based applications and infrastructure, we are building a universal domain-specific language (DSL) for intents.

This DSL will not just be a standardized format for intents, but will also be optimized for solving, meaning solvers can reason about intents using the same language they are expressed in.

The spec will be shared with the community when ready, and we will encourage comments, contributions, and the adoption of the DSL across intent-based projects.

2. Intent-Centric Account Abstraction Standard for Ethereum and EVM

To bring intent functionality to as many users as possible, we are developing an Ethereum standard for intent-centric account abstraction. In order to support intents within a transaction-based system, solvers will need permission to execute on-chain operations on behalf of end users, thus requiring account abstraction.

The new standard will introduce many of the benefits enabled by ERC-4337, but will delegate to solvers the job of constructing valid transactions to satisfy intents. The end result will be that users can access the benefits of an intent-based system on existing EVM chains, via websites and wallets they are already familiar with.

We are currently in the later stages of specifying the standard and building the necessary smart contracts. The next step will be consulting with the Ethereum community, so interested readers should stay tuned for opportunities to contribute to the development of this standard.

3. Modular Intent Layer

The constraints imposed by transaction-centric architectures mean that our proposed Ethereum-compatible intent standard will inherently require workarounds and design sacrifices in order to be compatible with the underlying architecture. These limitations can be avoided at the outset by designing a protocol with native support for intents.

With this in mind, after bringing intents to existing ecosystems, our next step will be to build a modular intent layer. Building a protocol from the ground up to be intent-centric brings a number of benefits:

  • Intent-Only Architecture - The protocol is designed to ingest only intents, with no notion of user-submitted transactions. Intents are solved in batches, such that each state transition (i.e. new block) is entirely a solution to a batch of intents. This differs from the Ethereum-compatible standard mentioned above, which needs to also consider the impact of user-submitted transactions on state. With an intent-only protocol, the absence of user-submitted transactions means solvers can provide solutions much more efficiently without having to reason about potential state drift or overlapping dependencies between intents and user-submitted transactions.
  • Orderflow Aggregation - Orderflow is one of the most powerful forces in both on-chain and off-chain markets. MEV itself is made possible due to certain parties’ outsized ability to foresee and control orderflow. Our intent-based protocol flips this information asymmetry on its head by ensuring that the benefits of transparent and aggregated orderflow go back to the users. All orderflow is routed through the same network of solvers, giving them the maximum possible information and control in order to leverage multiple liquidity sources, identify coincidences of wants, and ultimately optimize for the best user outcomes.
  • MEV Resistance - Because solvers are competing to provide the best outcomes for users, they are incentivized to bid value back to users rather than extracting it for themselves. In addition to this core mechanic, we are developing methods for differentiating between genuine user transactions and searcher activity, in part by leveraging the ordering capabilities of modular DA layers. Front-running and sandwiching will be impossible by design within this protocol.
  • Modularity - Leveraging a modular design means we can focus on optimizing the innovative aspects of intent-based execution first and foremost. It also enables our protocol to be deployed across a number of different stacks and ecosystems, paving the way for eventual cross-chain intent execution.

As with our other product efforts, a specification for this intent-centric protocol is underway and will be made available to the community as we make further progress.

The Intent-Centric Future is Essential

At Essential, we believe that blockchains are not inherently more virtuous than any other type of infrastructure, but are a means to an end: empowering individuals and decentralizing power structures. As an industry and a movement, we have the opportunity to manifest this potential by building a world in which end users are not exploited by intermediaries, but instead reap the value they generate.

To join us on this journey and contribute to the intent-centric future, follow us on Twitter and stay tuned for future updates.

Follow Essential

Follow Us on Twitter