Intent-Centric Design: Repackaging Account Abstraction, or Evolving It Further?

“Intent-centric” as an approach to architecture or product design has recently sparked many discussions, some of them questioning the term’s significance. The skepticism towards the term primarily comes from two perspectives:

1. Some argue that it feels abstract and narrative-driven, making it challenging to implement in practice. People in this camp argue that it doesn’t seem like a technological advancement, but rather a product design philosophy.
2. Others argue that it is merely a new term for account abstraction. At first glance, many feel that intent-centric design and account abstraction are related, as they both share the goal of reducing onboarding friction and enhancing user experience.

This article will analyze the coexistence, evolution, and competitive relationship between intent-centric design and account abstraction. We’ll also look at their key differences, usual components, and future.

TL;DR

Account abstraction centers on developers changing the way a user interacts with the network, lowering entry barriers. (Onboard-Express).

Intent-centric design focuses on users expressing their needs to have them solved for them (Express-Outcome).

A brief look at the origins of account abstraction

Overall, Web3 is shifting. The conversation has gone from creating crypto-punk solutions with an engineer-centric approach to creating consumer-oriented user-friendly products.

One significant step in this direction has been Ethereum’s account abstraction. Early discussions in 2016–2017 pushed this idea to solve common developer problems, focusing on simplifying creating and interacting with contracts while providing flexibility for complex transaction structures. Additionally, there was a hope to address some of the complexities involved in smart contract and dApp development through account abstraction. The essence of account abstraction during this phase was a generalization of the account model.

As discussions around account abstraction progressed, the community realized that some common demands of regular end-users in application-level business scenarios (like private key recovery, obtaining specific services at 0 gas costs, and batching authorizations) could neither be directly met from the account structure, nor the chain’s native structure.

Central to the development of account abstraction was the introduction and maturation of EIP-4337. As a supplement to the previous explorations of account abstraction, EIP-4337 was proposed by Ansgar Dietrichs. It aimed to offer greater functionalities by upgrading the account structure itself. This introduced the concept of “user operation”, allowing users to transact more flexibly without worrying about nonces or complex transaction fee issues.

The chart below introduces a timeline for the different protocols proposed in the field of account abstraction.

Current status of the account abstraction ecosystem, its core values and limitations

As you will see through the examples listed in this section, the account abstraction ecosystem is nearing maturity. For clarity, it can be roughly divided (in order of closeness to the user), into:

1. Public chain layer
2. Private key management layer
3. AA Stack layer (mainly including Paymaster and Bundler)
4. Functionality layer
5. Application layer

The private key management layer has multiple mature solutions, such as hosted solutions based on AWS’s KMS like Magic.link, and the MPC-TSS scheme that we at Particle Network use. The AA Stack currently has over a hundred providers, including leading start-ups like Stackup, ZeroDev, Pimlico, infrastructure companies like Alchemy, and leading wallet companies like Safe, all of which have provided feasible solutions. On the application layer, we have already seen leading projects like CyberConnect and dYdX apply account abstraction to their specific use cases.

Without a doubt, account abstraction has been a significant step towards consumer-readiness. However, the actual results at this stage clearly have not produced the paradigmatic improvement in user experience that account abstraction promised.

This is because the essence of AA lies in addressing UX issues from the supply side, providing developers with more choices at the account structure level. At the same time, the combination of account abstraction and the private key management layer has, to some extent, lowered the threshold for new users to enter Web3 products and services, thanks to new features like social/Web2 logins, among others.

However, looking at the accelerated adoption of account abstraction and feedback from end-users, there are no “a-ha!” moments. It seems like the full potential of this technology hasn’t been unleashed.

Of course, one reason is that the projects in the application layer are still iterating, trying to find Product-Market Fit. But we believe another reason is that account abstraction has optimized the user experience from onboarding to expression, while still not addressing the path from expression to outcome.

Optimizing expression-to-outcome: the core value of intent-centric design

The need for intent-centric design mainly stems from two reasons:

1. One of the cornerstones of the crypto industry, which is cemented in the foundational design of the blockchain, is to empower users. This includes giving them autonomy over assets, data, and information. However, this autonomy leads to a scenario where every minor on-chain operation behind accomplishing a goal needs to be actively managed by the user.
2. In the early days of the industry, business scenarios were relatively straightforward, with simpler execution logic and minimal interactivity between chains. At the time, user authorizations weren’t abundant, and the points requiring active user judgments were rare. As such, the experience wasn’t too demanding of users. However, as more L2 solutions emerge and businesses start to interplay and combine, situations arise where a user’s demand remains singular, yet the frequency of required authorizations escalates. This process often involves numerous subjective judgments, such as setting gas fees or adjusting slippage, creating additional friction.

The core logic behind the introduction of intent-centric design is to extricate the user from the process of actively managing and monitoring underlying services without compromising their autonomy. This includes having them specify only the starting and ending points of their requirements. This approach shifts the user’s perspective from transaction-based to demand-based.

Let’s illustrate this with a simple example

One of the most common on-chain operations could be expressed as “I have 10 ETH, and I want to lend it on Compound at a 2% annual yield.”

Is this expression truly “your” requirement?

In reality, it’s not. Your actual need is: “I have 10 ETH; and want to use them to access the highest possible yield in a secure protocol.” The phrase “lend it on Compound at a 2% annual yield” represents a transaction aiming to solve the need (intent).

At present, it’s easier to think in terms of transactions, and not requirements, because the current crypto industry is broken down into individual transactions and states. All demands are currently deconstructed into transactions, with statuses monitored to realize them. This creates a mental constraint in approaching Web3 operations that gets in the way of making the most out of two of Web3’s greatest features: its openness and permissionless composability.

Thus, what intent-centric design solves is finding the optimal path from expression to desired outcome.

This is valuable because only by addressing the pathway problem from expression to outcome can the vast demands of end-users truly be unleashed.

To achieve such a goal, intent-centric design needs to approach product development and research from various angles. Based on the approach we discussed earlier, we’ve segmented the entire intent-centric ecosystem into four layers:

1. User Expression Interface Layer
2. Translation Layer (from Expression to Intent)
3. Vertical Demand Integration Layer
4. Composite Demand Coordination Layer

• The User Expression Interface Layer is designed to collect genuine user needs.

Key Metric: Completion rate.

• The Translation Layer serves to translate genuine user needs into a language that can facilitate unified communication between machines, developers and machines, and even among developers.

Key Metrics: Response time and accuracy.

• The Vertical Demand Integration Layer focuses on assimilating specific category demands and matching them with the appropriate Solvers to address these demands.

Key Metric: Matching efficiency.

• The Composite Demand Coordination Layer decomposes complex demands into specific categories of demands and coordinates various specific category solvers to respond based on a specific objective or logic.

Key Metrics: Decomposition efficiency and demand coverage rate.

When all these four facets reach a certain level of maturity, it results in the following user journey:

1. A user expresses their needs at any User Expression Entry point.
2. The Translation Layer interprets their need as an intent described in a universally coordinated machine language.
3. The intent is then broken down by the Coordination Layer, and solvers from the Vertical Demand Integration Layer compete to execute these intents efficiently and safely.
4. Finally, the outcomes of the user’s specific intents are integrated by the Coordination Layer into the outcome of a complex intent.

To put this into perspective, let’s consider a practical example:

A user of Coinbase, upon learning about the launch of the Base Chain, wishes to experience a gaming application on Base. He knows that he needs to mint an NFT of this game to start the process.

Skipping the wallet registration process (which is already quite complex) and assuming he has played Web3 games in the Polygon ecosystem and already holds Polygon’s MATIC tokens, to participate in the game, he would have to:

1. Find a third-party cross-chain bridge to transfer his MATIC tokens to the Ethereum Mainnet.
2. Use a DEX to exchange his MATIC for native ETH.
3. Use Base’s bridge to transfer ETH tokens onto the Base chain.
4. Mint the NFT.
5. Start playing the game.

Currently, even with the assistance of account abstraction-based batch transactions or gasless transactions, the entry barrier remains significantly high. We are aware of the user’s intent (to mint an NFT on Base to start playing the game). The user knows precisely what they aim to achieve; however, the process is overly complex.

If the intent-centric field matures, its solutions could structure, decompose, and execute user intents with ease. From an end-user experience perspective, users would interact with wallets or apps that are compatible with the intent-centric protocol, or express their intentions in an LLM UI similar to ChatGPT. The developer-integrated intent-centric framework would automatically structure the intent. Subsequently, the intent Bidders and Solvers would handle the final decomposition and execution. For the user, the experience would be as simple as clicking a button or uttering a phrase.

Hopefully at this point the answer to the question poised in the title of this article starts to become obvious. Intent-centric design, besides being considerably different to AA, shines as an optimal evolutionary choice in comparison. The table below aims to summarize the key differences between both areas.

Summarizing: Account abstraction vs. intent-centric design

From the comparison across the dimensions above, we can clearly answer: Intent-Centric is not just a repackaging of Account Abstraction, but rather another option for optimizing the user journey experience.

However, whether the account abstraction track will become a foundational infrastructure for the implementation of specific operations in the intent-centric field as it matures remains to be seen. We need more mature protocols and products in the intent-centric domain to make that judgment.

Particle Network’s perspective and role in the intent-centric domain:

Particle Network debuted in the market with a wallet-as-a-service product based on MPC-TSS and account abstraction. As such, our v1 had a value position intrinsically linked to the account abstraction domain.

The picture below shows the fundamental work revolving around v1’s Key Management layer based on MPC-TSS and the provision of a social login feature layer:

Essentially, Particle did two things:

1. Simplified the users’ entry into Web3 products through social login.
2. Computed multi-chain signatures and directly completed the signature within various products that incorporated Particle’s Wallet-as-a-Service, enhancing transaction efficiency.

As we conceptualize and prepare to launch our v2, we’re introducing products in the intent-centric domain mainly for two reasons:

1. The core function of intent-centric design aligns perfectly with the essence of our v1: abstracting user needs and improving transaction efficiency.
2. Working through the B2B2C model, and in collaboration with our partners, in the past 10 months we’ve introduced a substantial user base to our products. Consequently, our focus has naturally shifted from user onboarding to user expression and outcome.

We also believe that within the intent-centric domain, and considering the layered logic mentioned above, there’s a clear value priority order, with the “expression-to-intent translation layer” being the most crucial as the only layer that can drive a flywheel effect on its own. Next in importance is the “compound requirements coordination layer,” followed by the “vertical requirements integration layer,” and lastly, the “user entry expression layer.”

Particle’s unique positioning in the intent-centric domain

Particle’s greatest strength lies in the accumulation of abstracting user demands in combination with multi-chain, multi-action signature computation. Moreover, the collaboration with partners from all tracks of Web3 gives us a unique advantage in carrying out this mission.

Our v2 product in the intent-centric realm receives the name of the Intent Fusion Protocol. It fundamentally encompasses:

• A unified language and framework for the expression-to-intent translation layer.
• A development kit for the compound requirement coordination layer.
• Particle Network’s proprietary zkEVM itself for full-chain account abstraction management and computation.

With the Intent Fusion Protocol, we aim for users to engage with application layer products empowered by Particle Network’s zkWaaS. As an early use case, users will be able to access through a zero-knowledge login, enjoying the convenience of social logins without revealing any Web2 identity privacy. They then will be able to easily commit their ETH to any on-chain yield product on any L1/L2 to optimize their earnings. Moreover, when the returns reach a specific amount, they can be automatically redeemed and staked in Lido to gain risk-free earnings.

v2’s Intent Fusion Protocol will prioritize users’ needs and expectations over providing a plethora of complex functions and settings. This ensures that users can achieve their real intentions with minimal understanding, friction and operational costs, achieving our ultimate goal –to establish an intent-centric, modular Web3 access layer, accelerating Web3’s transformation from an engineer-centric financial industry to a user-friendly consumer-grade sector for the masses.

About Particle Network

Particle Network powers chain abstraction, addressing Web3's fragmentation of users and liquidity. This is enabled by Particle's Universal Accounts, which give users a unified account and balance across all chains.

Website | Docs | Discord | Twitter