In this report, you will find a summary of the speaker presentations from Intents Day 0 along with some memes.
Intents Day 0: A New PsyOp
Intents day brought together a group of leading thinkers and builders working on intents or intent like protocols.
Each of the speakers presented for approximately fifteen minutes, with a ten-minute open discussion following each presentation. The participants asked good questions, and often the presenters had open dialogue during the presentation. In addition, there were three whiteboard sessions.
In this report, you will find a summary of the speaker presentations from Intents Day along with some memes. Additional references are linked for context. The words that follow are mostly not mine (they belong to gigabrains), I simply aggregated the information for your consumption and perhaps enjoyment. The errors are my own.
It's all a huge PsyOp. Intents aren't real.
Table of Contents
(0) Intents: Past, Present & Future
The morning started with a presentation by Christopher Goes from Heliax. Christopher began with a brief discussion on the history of intents.
To finish up the introductory session, Christopher picked up and read index cards out of a glass bowl which guests filled out upon arriving. The cards were filled with answers to the question 'what is an intent?'
(1) Intents for Blockchains
Objective: Paint a picture of how intents are being understood and treated across blockchain ecosystems.
This was the first segment of the session. We had great representation from different projects including Cosmos, Ethereum, Celestia & Anoma.
(1.1) A Vertically Integrated Intent Supply Chain
This track kicked off with a presentation by 0xbrainjar who re-introduced Composable Finance as the processing engine for user intents. Their thesis is simple; execution of transactions on blockchains should be ecosystem-agnostic, free, and private.
Composable's proposed solution to this problem is called MANTIS which stands for multi-chain agnostic normalized trust-minimized intent settlement. This solution consists of:
X-domain communication (IBC everywhere)
Language for execution
The proposed architecture is instantiated as cosmos chain, Centari , which attempts to satisfy user preferences with programmable solutions. In particular, some of the solutions include Cows, RFQs, & CFMM routing.
Users send their intents to solvers who compete to find the optimal solution for various domains, which when identified is turned into a program in the composable VM. Multiple solutions are then bundled into portions of blocks for a specific domain. After exposing these blocks to searchers for the right to back run and further conditioning, Composable outputs a bundle with these tips in native tokens to that domain’s block builder via IBC.
Finally, the presentation concluded with an exploration of credible commitment schemes such as MEV-Boost ++ and PEPC-Boost. Composable seeks to build a new relay that would allow for partial block building. This was proposed to use Eigen Layer re-staking to make this incentive compatible for various agents in the supply chain.
Intents are transmitted to one or more solvers, who try to match them up and find solutions
These solutions are called transactions, which need to be sent off to make state changes
Somewhere, someone maintains the official state that all of these intents are about, and they need to commit those transactions, resolving any conflicts
Anoma's P2P layer
Anoma's P2P layer is built on an architecture we call P2P Overlay Domains with Sovereignty, or PODS. The core idea is that any group of nodes can operate as a mostly independent overlay network, called a domain, using whatever broadcast or neighbor-selection protocols they like. Domains can be used by solvers or users interested in specific topics.
A chimera chain is a type of side chain that allows atomic transactions to be carried out on objects from the base chains. It carries an additional consensus mechanism, that is dependent on the consensus of the base chains.
Eventually, the Anoma framework will allow people to build cosmos blockchains using Typhon, and enable chimera chains. Chimera chains are something no one has done before. We have a full spec proposal coming soon - see the RFC announcement for more details on how to get involved.
(1.3) Intents, Based Rollups & Preference Expression
John Adler & C-Node from Celestia held a whiteboard session. John discussed intents, solving, risks, and intent languages. C-Node discussed based rollups and preference expression on Celestia.
Typically, transactions constrain inputs and the initial part of the state transition function. Placing some constraints on the outputs of the STF is the defining characteristic of intents.
There exist many possible inputs that can lead to outputs, given some constraints on initial state along with the rest of the constraints.
There needs to be some mechanism for constraining the search space.
It's okay if solvers must do a lot of work, but not okay if verification is expensive.
There maybe exactly one and only one solution to satisfy these constraints.
You may have a situation with hotel and train, and you are possibly okay with certain suboptimal solutions
In an intent protocol, there should be a component which allows users and solvers to understand the satisfaction score of an intent.
Issues to watch out for with intents is DOS attack vectors for solvers.
Ideally, you want a unified expression language for intents because you don't want to assume intents are only for a specific architecture. You would like intents to be able to revolutionize Ethereum as well, with a design such that an application that opts into intents is composable with an application that does not.
Based Rollups & Preference Expression
Based rollups don't use any sequencers. These kinds of rollups inherit the liveness and full decentralization of L1. A rollup is based when the next L1 proposer can permissionlessly include the next rollup block as part of the next L1 block.
How do you pick which blobs to select from Celestia as a rollup?
You can do something simple like select the block that burns the most gas. This mechanism might waste DP layer tokens on blocks that don't win.
Instead, you may prefer a system where you say, "this is my block submission, and you can only charge me if my submission is included."
When you have preference expression for the data publication layer, (nee-data availability) there is no concern of submitting a submission that loses. This mitigates invalid blocks. These rollups leak all MEV to the DP layer. In Celestia, there is one leader who decides on ordering like any CometBFT chain.
(1.4) PBS & PEPC Whiteboard Session
Alex Stokes and Barnabé Monnot from the Ethereum Foundation discussed proposer builder separation (PBS) & protocol enforced proposer commitments (PEPC).
First Alex broke down PBS by explaining the motivations, current design of MEV-Boost, and then shifting to ePBS briefly.
The motivation for PBS is to counter the centralizing force of MEV by keeping validators decentralized.
Firewall off the proposer from the builder. By doing so, the validator role can remain "dumb" and not have to run complex MEV search algorithms.
Improve access to MEV for validators who only need to accept the highest bid from a block builder.
Push centralization to specialized actors which can be leveraged for more efficient block construction, data availability sampling, statelessness and extra builder services
Remove the reliance on a trusted relay, though one may still exist in some designs
MEV-Boostis the out of protocol version of PBS built by Flashbots which has been live since the Merge. MEV-Boost introduced the role of the relay and the Builder into the supply chain. Optimistic relaying is a recent innovation.
ePBS, is the enshrined (protocol aware) version of proposer builder separation. There is ongoing discussion about the ideal implementation.
The new proposals with Payload-timeliness committees (PTC)
Next, Barnabé took over and discussed PEPC which can be loosely described as intents for block proposers. PEPC (“pepsi”) is intended as an enshrined protocol gadget which allows block proposers to enter into binding commitments over the blocks they produce.
The goals of PEPC:
Generalize PBS, allow fair exchange between the proposer and some builders for any item; e.g., whole block, partial blocks, inclusion lists
Move some use cases of Eigen Layer from an optimistic failure mode to a pessimistic failure mode; e.g., Block validity is dependent on commitment satisfaction vs. a slashing condition for deviating
How PEPC relates to ABCI++
There are some similarities between PEPC and Skip's x/builder module which is enabled by ABCI++. Though, the latter is general in that it sets global preferences for all blocks of a given chain, while PEPC is a system of local decisions made by proposers of each block.
There are different flavors of Diet PEPC which can exist without protocol changes.
Objective: Paint a picture of how intents are being understood and treated across wallets and directly user-facing software.
(2.1) Intents ≠ RFQs
Khushi Wadhwa began the second session of the day with a presentation discussing (RFQ) request for quote auctions, Intents, and how they relate.
An RFQ price auction is a swap price discovery system. It uses signed messages and contract code to execute swaps. White-listed market makers provide liquidity, and the best price wins the bid. For example, in the 0x protocol, the flow of messages would look like this.
Users request a quote from the application interface
API requests pricing info from on-chain AMMs and market makers
Market makers can choose to respond with a signed quote
User receives a quote, which can include multiple sources of liquidity
The user then signs and submits the transaction on-chain
Some of the common advantages for users include guaranteed prices, gas inclusion in the price quote, and front-running protection.
Typically, RFQs can optimize for one thing. As intents evolve, we will see more types of preferences that can be expressed. Outlining all the details or defining what you want before every request may lead to a bad UX. Two possible solutions are:
Multi-tiered requests - with context-based Intents, you could use on-chain history to determine what a users' ideal preference is. This is hard.
Post creation-filtration - similar to Google Flights. Solvers Find the best possible execution paths that satisfy an intent and allow the user to filter and choose their preference.
RFQs ⊆ Intents
While it's now evident that every RFQ can be considered an intent, it should also be clear that not all intents are RFQs.
(2.2) The Intents of Offers
Dean Tribble from Agoric presented the next portion of the workshop. Dean's presentation focused on what's wrong with the user experience and how we can fix it with Offer Safety.
What is Agoric?
Agoric is building a platform for the world's developers to solve the world's problems individually without orchestration- in a permissionless and collaborative fashion.
Best-In-Class Component Model - Framework for innovation across all skill levels
Integrated Economy - Economic services & native IST stable token for fees to grow a rich economy
The current user experience with wallets and applications is untenable for most people. For example, users don’t know anyone named 0x69e2..e108. This makes it easy to make mistakes when sending funds to an address or interacting with a smart contract.
In addition, the status quo is unsafe for everyone, which limits adoption. Users do not understand what they agree to when they sign a message in their Metamask or Keplr wallet. The smart contract that a user interacts with controls what happens to their funds - contracts shouldn’t need that responsibility.
As long as humans are habituated to approving transactions that they cannot understand, they are not protected from endpoint compromise (hidden risks). Is there a better approach?
Zoe is Agoric's smart contract framework which guarantees offer safety. Offer Safety ensures that users receive desired payouts or refunds regardless of the behavior of the contract. When a user makes an offer, it is escrowed with Zoe, which guarantees that the user either gets back what they wanted or what they originally offered and escrowed.
An offer proposal is a statement about what you want and what you're willing to offer. Offers are a structured way of expressing user intent.
Proposal contains give and want amounts
Offer contains an invitation for a specific entry point in a specific contract, the proposal, payments, and custom arguments
Offer validation - proposal has properties required by invitation, payments match
Provided assets get escrowed asynchronously
Offer legibility is "can the user understand what the proposal is they are approving?"
Offer legibility is partly about the structure of offers and intents in general. It's also partly about a good user experience - presenting the offer correctly to the user.
More Safety Properties of Zoe
Payout liveness - the user must give Zoe a proposal to enforce when and how they can exit the contract.
Secure partitioning - separates escrowing and reallocating assets from deciding the reallocation via constraints.
What can offers do for you?
Sign-mode textual - enables wallets to provide a human-readable description of what a given contract interaction will perform
Want patterns - allows users to define specific conditions they want in a potential offer
Multiples - multiple forms of behaviour to wrap around a single bundle of state
Piecewise linear preference curve - capture user preferences at different points
Synthetic combined offers
Offers increase usability and safety by better representing user intent, and making their interactions with the system legible to them so they know what they are agreeing to. Offers also systematically improve safety because the framework escrows offered assets so users get what they want or their assets back, can exit in a timely fashion, etc. all no matter what the correct contract code does. Thus, users are protected from large classes of bugs, rug-pulls, upgrades, etc.
In the web 2 world, users push buttons and things happen. You can express desires for action (intents!) without specifying what computation is getting executed. Also, users don't care where the execution happens- GCP, AWS or Azure it doesn't matter. Take Slack, for example, where you can click a button and make a post. You can schedule a post for later or even write a bot that posts on your behalf.
In the crypto world, users have complicated interaction schemes where they need to be aware of which chain a specific asset is on.
Users have assets on many different chains.
Users need to physically inspect transactions and hope for the best.
Wallets Are Doing too Much
Everything before an app is wallet aware
Ownership attestations for addresses that sign tx
What contract and parameters? How much gas to pay?
Is this Safe? Is this correct?
Submit a tx on-chain
Enter Programmable MPC
ProgrammableMPC keeps user funds safe and ensures keys can only authorize transactions they’re meant to. Users can do things like create a wallet with an e-mail address and use a single sign-on (SSO) style verification to perform signing in the background.
Programmable MPC enables simple and secure transaction signing, but also a variety of features like permissioning, autonomous transactions, and fraud prevention, while maintaining a noncustodial design along with developer flexibility.
Users don't need to write down seed phrases because they can do key recovery.
Separate the signing of a transaction from ownership of the full key, which therefore would allow unilateral access.
Allow many different applications to propose transactions and gate-keep with permissions.
Mapping Intent(s) <> Transaction(s)
How can a user verify that their intent has been optimally solved?
The ability for valid “intent solutions” to quickly change is a feature - how are those changes best reflected?
What are the features of a wallet in a post-intents paradigm?
Are standalone wallets necessary at all vs. apps directly?
Intents arereal. There are several live productsthat improve user experience. These products provide routing, bundling, and aggregation as services that abstract away infrastructure details. Users will no longer have to care about gas, bridging, and other leaky abstractions.
Intents are pathological. They allow the expression of preferences over future states of the system. What informs users' preferences? Users often don’t know what they want.
Answerability substantiates enforcement, while enforcement obliges answerability. Much of the mechanism design we focus on in crypto focuses on enforcement. The answerability portion is under-explored.
If a user is interacting directly with a system, there is no PAP. When a user delegates to a solver, they must establish an accountability system to safely delegate decision-making.
An accountability system is a two-sided contract with a combination of formal and informal rules, whereby terms of satisfaction require answerability and enforcement from both ends.
In Cosmos, chains can be thought of to have agency which they can delegate to;
Solvers - the capacity to complete some computation that would otherwise be performed by the state machine.
Users - ability to enforce, only sign messages to release funds that satisfy the desired intent.
dYdX's Accountability System
dYdX uses an order-book discrepancy metric built and monitored with Skip to measure validator P&L vs. expected. The statistical view of this behavior provides a basis for answerability which can be used to build an accountability system
Cosmos's Reputation System
Validators in Cosmos are great candidates for delegating certain tasks due to their reputational network across the ecosystem.
Keplr's new product "Comment on Validator Reviews" will improve the ability of validators to get feedback from their delegators and for delegators to hold validators to account.
What are we holding validators, solvers, or relayers, accountable to?
As protocol designers and community members, we should think carefully about what kind of system behavior we want to elicit 2, and how to surface the correct information such that behavior is measurable and answerable.
Only then can we create networks that overcome extractive behavior and take on this special property of organically generating value surplus.
A solver is a catch-all for an actor that leverages off-chain infrastructure to improve on-chain user experience. Searchers are solvers.
In intent systems todayCEX-DEX arbitrage dominates RFQ systems. Direct on-chain routing is disadvantaged because of increased costs in taking on-chain liquidity. To counter this, the next wave of DEX innovation is about providing better prices to uninformed order flow (retail).
Meme coin trading provides the most adversarial experience for users.
Institutional capital will rarely touch these assets, so it's likely that the solver landscape for long-tail assets will remain distributed.
This makes a Strong case for the existence of AMMs e.g., 99.9% of all tokens have price discovery on-chain.
It’s possible that RFQ systems will capture order flow here as well. Actors who are willing to take inventory risk will have an edge; e.g., jaredfromsubway.eth
Liquid staking tokens (LSTs) are the Largest on-chain market. They are highly inefficient and suffer from extreme de-pegs in times of volatility. The majority of the liquidity for LST tokens is passive LPs in AMMs. There is almost no liquidity in RFQ systems.
What can we learn from LST markets?
The solver landscape is still relatively immature
There is a shortage of on-chain infrastructure for solvers
Specialized knowledge of DeFi primitives is an edge
We want to live in a world where primary liquidity is on-chain. Intent systems create the UX to make this possible.
(4) Intents for Mathematicians (Theory of Intents)
Objective: Paint a picture of how intents can be mathematically formalized and understood, and how they relate to MEV.
Intents loosely: “messages which need not be executable in isolation”
Intents are messages which require aggregation
Intents reduce friction for an ecosystem of intermediaries (agents' challenges)
The term "intents" arose not because we have new tech, but because we have accepted the existence of the intermediary.
Part 2: MEV Regaining Control
In part two, the talk focused on how to regain control by restricting the intermediary with integrity, provision of information, and privacy. Quintus further discussed the challenges of maintaining the balance amidst:
Latency overhead from proof generation time
Loss of counterparty discovery with too much privacy
DoS risks for the intermediary
(4.2) Intents and Network Congestion Whiteboard Session
K Kulkarni from Berkeley and Gauntlet led the next whiteboard session. He presented the ideas of Frank Kelly which explore internet packet routing and congestion control. Kelly proposed a framework for managing network congestion, in the paper titled, Charging and rate control for elastic traffic.
The paper presents a model of charging, routing and flow control, where the system consists of users with utility functions and a network with capacity constraints.
Standard results from convex optimization problems indicate that the optimization of the system can be decomposed into subsidiary optimization problems, one for each user and one for the network, by using price per unit flow as a Lagrange multiplier that mediates between the subsidiary problems.
The optimization problem:
For each constraint, there's an associated price or cost for violating that constraint
By minimizing the Lagrangian, you're finding the best value for the decision variable, considering the cost of violating constraints
$U_i(x_i)$ represents the utility of user $i$ for transmitting at rate $x_i$.
$x_i$ is the rate at which user $i$ transmits data packets.
$λ$ is the Lagrange multiplier, which can be interpreted as the price or penalty for violating the network's capacity constraint $C$.
How does this relate to Intents?
Efficient packet routing is a convex optimization problem. When the network is overloaded it gets congested which can lead to packet loss and latency.
An intent refers to the desire of the user to transmit data packets at a certain rate. The System has to decide how to fulfill these intents given network constraints.
A typical objective function can be used to maximize the welfare of all users.
(4.3) Intent Machines
The final talk of this section was given by Christopher Goes which introduced a candidate formalism for Intent Machines.
The goals of an intent formalism are to capture commonalities of intent systems, capture structure not implementation details, and to aid in the analysis of similarities/differences, conditions for behavior of composition, and relationship to other concepts like MEV of intent systems.
Fix a state type T
An intent is a function of type - T -> T -> 0|1
An intent machine is a potentially non-deterministic function of type
- (T, Set I) -> (T, Set I) - First tuple: prior state and candidate intents - Second tuple: posterior state and processed intents
Key property: intent adherence - for alliin processed.iprior= 1
Without loss of generality, this function can be decomposed into two steps:
Enumeration: computing a set of (candidate state, processed) tuples which satisfy intent adherence.
Selection: choosing one of the tuples to return
This function may additionally constrain which state transitions are considered to be valid. This can be modelled as a “system intent” which must always be satisfied. Examples include;
Interior EVM state transition function satisfied
Resource linearity & logics satisfied
Selection picks one pair from the set of valid options. All the interesting structure lies here.
choose :: Set (T, Set I) -> (T, Set I)
Types of Selection Functions
Select a validator return pair at random
Select the return pair which stisfies the most intents
Select the return pair which maximizes some scalar function
Utility maximization with a utility function that calculates the balance of a specific token owned by the operator’s address
Utility maximization with a utility function set to the welfare function of some community.
Expected Utility Maximization
Select the return pair which maximizes expected future utility, given some probability distribution over future intents conditional on the posterior state
If both selection functions agree, return that, else use the solution chosen by one of them
If both selection functions agree, return that, else choose randomly between options the Pareto frontier
Select the return pair which maximizes some scalar function
Anoma and many others, effectively implement a distributed intent machine which is composed of other intent machines with different select functions.
Different parties performing enumeration and selection.
Consensus to agree on which new state will be chosen.
Everything is distributed!
One could understand cryptoeconomic mechanism design as trying to set incentives to provide a particular composed selection function. This is where MEV happens.
(4.4) State Your Intents (take 2)
Thereafter, Christopher, Quintus and K participated in a light panel to discuss memes selected by myself. Indeed, the title takes inspiration from the original State Your Intents panel at MEVday Paris. This was a fun discussion.
How to prevent MEV dystopia from walking in through the front door?
What would your goals for an intent formalism be?
Do you think this option makes sense?
Which parts are clear / unclear?
Are there other compelling candidate formalisms?
(5) Closing Remarks
Awa Sun Yin, builder of public goods, thanked everyone for attending the event and then closed with a reflection.
(5.1) The Sequel
Thanks for reading. If you have FOMO, and you're interested in participating in the sequel, don't worry, there will be one. If you would like to present at the next Intents day, reach out on X- preference for FUD.
Coming Soon - Intents Day 1: FUDent Xmas
Thank you to all attendees, you asked some great questions. Thank you to all the speakers for presenting, reviewing the summaries of your talks and providing feedback;
0xbrainjar, Isaac Sheff, John Adler, C-Node, Alex Stokes, Barnabé Monnot, Khushi Wadhwa, Dean Tribble, Nitya Subramanian, Sean Braithwaite, Sam Hart, Sun Raghupathi, Quintus Kilbourn, K Kulkarni, & Christopher Goes.
Thank you to Awa Sun Yin, Christopher Goes, Zaki Manian, Kobi Gurkan, Tarun Chitra and Nick White for helping with coordination. Special thanks to Zaki for hosting dinner.
Shout out to the meme lords; Jon Charb, Daniel Marzec, SxySun1, Velvet Milkman, and FrankieIsLost
Shoutout to everyone at Heliax building public goods. We have a remarkable team.