Intents Aren't Real - Intents Day Recap

Comparative Architecture
1

Intents Aren’t Real

1454×994 261 KB

HackMD with working TOC

Intents Day 0: A New PsyOp

Intents day brought together some of the leading thinkers and builders working on intents or intent like protocols.

944×186 30.2 KB

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.

tl;dr

It’s all a huge PsyOp. Intents aren’t real.

834×846 678 KB

Table of Contents

Intents: Past, Present and Future

940×540 69.1 KB

The morning started with a presentation by Christopher Goes from Heliax. Christopher began with a brief discussion on the history of intents.

Etymology and conceptual history of intents

938×306 38 KB

Activity

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?’

Intents for Blockchains

968×674 479 KB

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.

934×304 33.9 KB

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.

MANTIS

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

Architecture

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.

Roadmap

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 and Typhon

Next up, 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 Chimera Chains.

Intent Lifecycle simplified

  • 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

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.

Chimera Chains

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.

Intents, Based Rollups and 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.

Intents

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.
  • 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 & 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.”

926×336 39.9 KB

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.

PBS and PEPC Whiteboard Session

Alex Stokes and Barnabé Monnot from the Ethereum Foundation discussed proposer builder separation (PBS) & protocol enforced proposer commitments (PEPC).

PBS

First Alex broke down PBS by explaining the motivations, current design of MEV-Boost, and then shifting to ePBS briefly.

Motivations

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-Boost

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

ePBS, is the enshrined (protocol aware) version of proposer builder separation. There is ongoing discussion about the ideal implementation.

  • The original 2 slot version
  • The new proposals with Payload-timeliness committees (PTC)

PEPC

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.

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.

Diet PEPC

There are different flavors of Diet PEPC which can exist without protocol changes.

Intents for Users

926×920 449 KB

Objective: Paint a picture of how intents are being understood and treated across wallets and directly user-facing software.

940×280 38.8 KB

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.

RFQs

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 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.

Intents

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.

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.

  • JavaScript Smart Contracts - Use your existing language knowledge
  • 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
  • Unique Safety Properties Offer - safety, payout liveness, secure partitions

What’s wrong with the UX?

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?

Offer safety

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
  • JavaScript contract function for the invitation is executed

Offer Legibility?

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.

Extensions

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

Conclusion

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.

User facing Intents with Permissions

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.

Web 2

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.

Transactions

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.

Wallets Are Doing too Much

Core Responsibility Description
User Interfaces Everything before an app is wallet aware
Authentication Ownership attestations for addresses that sign tx
Tx Formation What contract and parameters? How much gas to pay?
Tx Verification Is this Safe? Is this correct?
Tx Signing Approve
Node Infrastructure Submit a tx on-chain

Enter Programmable MPC

Programmable 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.

Open Questions

Mapping Intent(s) <> Transaction(s)

  • How can a user verify that their intent has been optimally solved?

Upgradeability

  • The ability for valid “intent solutions” to quickly change is a feature - how are those changes best reflected?

Wallets

  • What are the features of a wallet in a post-intents paradigm?
  • Are standalone wallets necessary at all vs. apps directly?

The Case for Curation

In the final segment of Intents for Users, Sean Braithwaite from Mekatek discussed how curation plays a key role in the intent supply chain.

Intents

Intents are 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.

The Curation Flywheel

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.

The New Intents Supply Chain

Stage Description Interacting Agent
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)

2

Intents for Solvers

976×962 117 KB

Objective: for this segment of the day was to paint a picture of how solvers are thinking about intents and how intents will change solver economics.

942×180 30.2 KB

Accountability along the Transaction supply chain

Next Sam Hart from Skip laid out an accountability framework for solvers, how to make off-chain actors more accountable. See Sam’s recap for a more detailed explanation.

Problem Statement

Intents introduce a degree of freedom for solvers to improve efficiency, UX and other conditions of satisfaction. Here we introduce a principal-agent problem (PAP) with solvers.

Options to deal with this problem

  1. Reintroduce constraints
  2. Change the information structure
  3. Change the payoff structure
  4. Turn into a repeated game

Accountability framework

There is a notion of accountability that exists in institutional theory literature.

A is accountable to B when A is obliged to inform B about A’s (past or future) actions and decisions, to justify them, and to suffer punishment in the case of eventual misconduct.

  • Answerability - Justify behavior, attribute actions
  • Enforcement - Prevent abuse via credible threat, reward adherence punish deviation

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.

Modeling Accountability

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 the help of 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.

Conclusion

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.

Solvers, LSTs and Meme Coins

Sun Raghupathi from Seven Seas spoke next. Seven Seas operates a strategist solver in the Sommelier ecosystem.

Solvers

A solver is a catch-all for an actor that leverages off-chain infrastructure to improve on-chain user experience. Searchers are solvers.

Intent System

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).

There are two primary on-chain markets today, Meme coins and LSTs.

Meme Coins

  • 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

LSTs

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

Conclusion

We want to live in a world where primary liquidity is on-chain. Intent systems create the UX to make this possible.

Intents for Mathematicians

916×520 523 KB

Objective: Paint a picture of how intents can be mathematically formalized and understood, and how they relate to MEV.

940×212 30.4 KB

Completing the Intents Picture

The first talk of the Theory of Intents section was presented by Quintus Kilbourne from Flashbots, Completing the Intents Picture.

Part 1: Intents Letting Go

In Part one Intents were described as:

  • 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.

938×154 21.1 KB

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

Intents and Network Congestion Whiteboard Session

K Kulkarni from Berkley 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, the paper 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:

max_x​∑_i​U_i​(x_i​)

Subject to:

∑_ix_i≤C

  • 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 a decision variable, considering the cost of violating constraints

The Lagrangian:

L(x,λ)=∑_i​U_i​(x_i​)+λ(∑_i​x_i​−C)

Where:

  • 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.

Intent Machines

The final talk of this section was given by Christopher Goes titled Intent Machines which introduced a candidate formalism for Intent Machines, selection functions, and distribution.

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.

Formalism

  • 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 all i in processed . i prior = 1

Decomposition

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

Constraints

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 Function

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

Function Description
Pure Chaos Select a validator return pair at random
Pareto-Efficient Chaos Select the return pair which satisfies the most intents
Utility Maximization Select the return pair which maximizes some scalar function
Profit Maximization Utility maximization with a utility function that calculates the balance of a specific token owned by the operator’s address
Welfare Maximization 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
Optimistic preferred If both selection functions agree, return that, else use the solution chosen by one of them
Optimistic Random If both selection functions agree, return that, else choose randomly between options the Pareto frontier
Weighted welfare Select the return pair which maximizes some scalar function

Distribution

Anoma (& 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!

  • State
  • Computation
  • Enumeration
  • Selection
  • Verification

Distributed Composition

One could understand cryptoeconomic mechanism design as trying to set incentives to provide a particular composed selection function. This is where MEV happens.

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.

Memes

Closing Remarks

Awa Sun Yin, builder of public goods, thanked everyone for attending the event and then closed with a reflection.

946×376 45.4 KB

The Sequel

970×646 575 KB

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

Acknowledgements

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 all attendees who asked some great questions. Special thanks to Awa Sun Yin, Christopher Goes, Zaki Manian, Kobi Gurkan and Nick White for helping with coordination.

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.

Slides and Whiteboards

918×596 429 KB

Intents for Blockchains

Intents for Users

Intents for MEV extractors good-guy Solvers

Theory of Intents