HackMD with working TOC
Intents day brought together some of the 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 along with some memes. Additional references are
linked for context. The words that follow are mostly not mine (they belong to the galaxy brains who presented), 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.
- Intents: Past, Present and Future
- Intents for Blockchains
- Intents for Users
- Intents for Solvers
- Intents for Mathematicians
- Closing Remarks
- Slides and Whiteboards
The morning started with a presentation by
Christopher Goes from Heliax. Christopher began with a brief discussion on the history of intents.
- March 2009 & Earlier - beginning with
A commitment folk theoremmodeling conditional commitments in strategic games. Earlier alludes to the
Agoric Open Systems Papersand
Program Equilibrium literature
- February 2018 -
The Wyvern protocol- where the protocol’s job is to match buyer and seller intent on-chain such that the asset transfer and payment happen atomically.
- March 2019 - Virgil Griffith’s idea of
Ethereum is game-changing technology, literally- a credible commitment device which turns non-cooperative games into cooperative games. Send him Mail.
- August 2022 -
The Anoma white paperintroduced Anoma’s intent-centric architecture and described an intent as an off-chain signed message that encodes which state transitions a user wants to achieve.
- May 2023 -
Research Dayin New York was the coming out party for intents in the broader research community.
- August 2023 -
Intents Day 0and beyond.
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?’
Objective: Paint a picture of how intents are being understood and treated across blockchain infra ecosystems.
This was first segment of the session. We had great representation from different projects including Cosmos, Ethereum, Celestia & Anoma.
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 multichain agnostic normalized trust-minimized intent settlement. This solution consists of:
- X-domain communication (IBC everywhere)
- Multi-domain auctions
- Language for execution
- Verifiable settlement
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.
Isaac Sheff from Heliax presented Typhon, Anoma’s universal ordering machine which consists of the mempool (
Heterogeneous Narwhal-Rider), consensus (
Heterogenous Paxos), and execution engine. The presentation focused on the intent lifecycle,
p2p layer and
- Users produce (and sign off on) intents
- 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 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. Chimera chains are something no one has done before.
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
- Its 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 maybe 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 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.
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
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.
Next, Barnabé took over and discussed PEPC which can be loosely described as intents for block proposers.
PEPC (pronounced “pepsi”) is intended as an enshrined protocol gadget which allows block proposers to enter into binding commitments over the blocks they produce.
- 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
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.
Khushi Wadhwa began the second session of the day with a presentation discussing (RFQ) request for quote auctions, Intents, and how they relate.
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 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.
While it’s now evident that every RFQ can be considered an intent, it should also be clear that not all intents are RFQs.
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
ISTstable token for fees to grow a rich economy
- Unique Safety Properties Offer - safety, payout liveness, secure partitions
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.
- Payout liveness - the user must give Zoe a
proposalto enforce when and how they can exit the contract.
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 behavior to wrap around a single bundle of state
- Piecewise linear preference curve - captures 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 agree 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.
Nitya Subramanian from
Capsule presented next. Capsule is a toolkit (SDK) for transaction signing and permissioning that enables developers to build custom wallets with a variety of
highly functional capabilities.
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 be physically inspect transactions and hope for the best.
|User Interfaces||Everything before an app is wallet aware|
|Authentication||Ownership attestations for addresses that sign
||What contract and parameters? How much gas to pay?|
||Is this Safe? Is this correct?|
|Node Infrastructure||Submit a
MPC 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 non-custodial 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.
- 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?
real. 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.
Discovery ⇒ Commitment ⇒ Execution ⇒ Settlement ⇒ Discovery
- Intents should be informed by a discovery stage.
- Consumers aggregate over public data to bootstrap initial constructions.
- Each iteration informs and refines preferences.
|Curation||Discover user preferences with historical on-chain data and LLMs||LLMs, Data Profiles|
|Origination||User interface for constructing intents||Wallets, dApps|
|Matching||Counterparty discovery, dissemination of intents to interested parties||Mempool, Gossip Network, OFA|
|Execution||The required action for fulfilling intents||Solvers, Builders, Executors|
|Settlement||Use predicates and materialized state to demonstrate fulfillment of the intent whereby the solver can receive its payment||Verification, Payments|
Intents are insufficient to inform users in a world of abundance. As such, a discovery process driven by the curation
flywheel can help. Curation should be part of the supply chain the user owns.
Part 2 Below (Discourse Length limit reached)