Technical Deep Dive: The Access Layer of Open Web Built by Particle Network
TechFlow Selected TechFlow Selected
Technical Deep Dive: The Access Layer of Open Web Built by Particle Network
Taking Particle Network as an example, this article elaborates on the current user experience issues in Web3 products and how to design a comprehensive technical solution accordingly.
Navigating Web3 tides with focused insightsAuthor: Wuyue, Geeker Web3
Introduction: Although account abstraction (AA) wallets have significantly lowered user entry barriers by enabling gas sponsorship and Web2-style account logins, designs related to mass adoption—such as private login, private transactions, omnichain unified AA accounts, and intent-specific architectures—still require further development on top of AA.
While we see many UX improvement solutions like ZenGo’s MPC wallet or Argent’s smart contract wallet that effectively reduce user friction, they only solve part of the above challenges and do not comprehensively address overall product usability.
Clearly, most current AA wallets or similar products are still insufficient to support mass adoption of Web3. From an ecosystem perspective, developer-side support is crucial. A product may attract end users but fail to gain traction among developers, making large-scale growth difficult. The increasing emergence of developer experience optimization solutions underscores the importance of developer adoption for ecosystem success.
We will use Particle Network as a case study to analyze existing user experience issues in Web3 products and how to design a comprehensive technical solution addressing them—such holistic approaches may be essential for mass adoption. Meanwhile, Particle's B2B2C business strategy offers a valuable model for other projects to learn from.
Full Breakdown of Particle's Product Architecture
At its core, Particle Network focuses on lowering user barriers through a B2B2C approach, proposing an integrated solution for Web3 mass adoption. Its system consists of three key components:
zkWaaS — Wallet-as-a-Service based on zero-knowledge proofs. Developers can integrate smart wallet modules into their dApps via Particle’s SDK. This is a keyless smart contract wallet built on account abstraction, supporting not only basic AA features like gas sponsorship but also Web2-style OAuth private login and private transactions.
Particle Chain — A dedicated Omnichain Account Abstraction solution, aiming to resolve cross-chain deployment, maintenance, and invocation issues for smart contract wallets. It includes a Unified Gas Token to simplify multi-chain transactions requiring different native gas tokens.
Intent Fusion Protocol — Featuring a concise DSL (Domain Specific Language), intent framework, and Intent Solver Network, forming a Web3 interaction framework based on user intents. Users declare what they want to achieve rather than executing each detailed step, freeing them from complex path planning and reducing the need to understand underlying infrastructure.
zkWaaS — Smart Wallet-as-a-Service with ZK Integration
On the wallet side, Particle provides SDKs to dApp developers in the form of WaaS (Wallet-as-a-Service), enabling them to integrate into its full Web3 mass adoption framework. This B2B2C model has several advantages from commercial and ecosystem perspectives:
C-end wallet competition is already saturated, with largely identical functionality—making it no longer a viable entry point. Meanwhile, dApp developers increasingly prefer embedding wallets directly within their apps to avoid UX friction caused by external wallet connections and switching, while enabling greater customization.
Customer acquisition costs are high on the C-end, unlike the B-end. Growth for WaaS primarily comes from dApps integrating the SDK. With strong BD and developer relations, this enables an “urban encirclement of rural” expansion across the ecosystem.
Current C-end wallets mainly focus on finance and assets—but this may not represent the future main use cases of Web3. To achieve true mass adoption, someone must abstract fundamental capabilities—user identity (accounts) and user operations (sending transactions)—into foundational services, leaving richer upper-layer scenarios to dApps.
Historically, one could observe a tight coupling between wallets and dApps at the connection layer. Gaining wallet market share within dApps is therefore critical—and the B2B2C model enjoys a first-mover advantage here.
Building a WaaS solution that meets user needs, lowers entry barriers, and is easy for developers to adopt is another pillar of success. Particle’s zkWaaS rests on three core pillars:
1. Private Login: Enables traditional Web2 login methods such as Twitter, Google, WeChat OAuth on contract wallets, completely freeing users from private key management using familiar and simple access. Zero-knowledge proofs are used to conceal user identities.
2. Private Transactions: Achieves general-purpose peer-to-peer private transfers via Smart Stealth Address mechanisms, with ERC-4337 Paymaster enabling gasless usage of assets held in stealth addresses (via gas sponsors).
3. Full AA Wallet Functionality: Particle’s wallet module fully complies with ERC-4337 requirements, including Bundler, EntryPoint, Paymaster, and Smart Wallet Account—providing a one-stop solution for all smart wallet functional needs of dApps or users.
Private On-Chain Wallet Login via Web2 Accounts
Particle’s private login solution leverages JWT (Json Web Token) to perform Web2 identity verification and wallet operations directly within smart contracts.
JWT is widely used in traditional internet applications as a credential issued by servers to clients, which the client presents during interactions for authentication purposes.
(Image source: FlutterFlow Docs)
Several key fields in JWT serve as the basis for contract-based identity verification:
-
"iss" (Issuer): Indicates the issuer of the JWT—i.e., the service provider such as Google or Twitter.
-
"aud" (Audience): Specifies the service or application where the JWT applies. For example, when logging into Medium using Twitter, Twitter sets "aud" to indicate Medium as the target.
-
"sub" (Subject): Refers to the user receiving the JWT, typically represented by a UID.
In practice, "iss" and "sub" rarely change, as doing so would cause major internal and external system disruptions. These parameters can thus be used by contracts to determine user identity, eliminating the need for users to generate or manage private keys.
The counterpart to JWT is JWK (JSON Web Key), a set of public-private key pairs held by the server. The server signs JWTs with the private key, while the public key is openly available for third parties to verify the signature.
For instance, when Medium uses Twitter login, it verifies the JWT using Twitter’s publicly disclosed JWK public key to confirm authenticity—that it was indeed issued by Twitter. Contracts also rely on JWK for JWT validation.
Particle’s private login flow is illustrated below:
We’ll skip the specific ZK circuit details for now and highlight key points in the process:
-
The Verifier contract responsible for validating login data only receives a ZK proof related to the user’s JWT and a harmless ephemeral public key (eph_pk). It cannot directly access the wallet’s public key or JWT content, protecting user privacy so that on-chain data does not reveal the user’s identity.
-
eph_pk (ephemeral key pair) is used temporarily within a single session and is unrelated to the wallet’s actual key pair—users don’t need to manage it.
-
This system also supports off-chain verification, applicable to contract wallets using MPC or similar logic.
Since this is a truly Web2-native contract verification scheme, users can designate social contacts as guardians to recover access in extreme cases such as account deactivation.
Privacy-Preserving Transactions Based on Diffie-Hellman Key Exchange
Before discussing Particle’s privacy transaction solution, let’s examine how to achieve receiver anonymity—i.e., hiding the recipient’s address—within the existing EVM framework.
Assume Alice is the sender and Bob the recipient, both sharing some common knowledge:
1. Bob generates a root spending key m and a stealth meta-address M. M is derived from m via cryptographic computation: M = G * m.
2. Alice obtains Bob’s stealth meta-address M through any means.
3. Alice generates a temporary private key r, then uses the function generate_address(r,M) to compute a stealth address A. This becomes Bob’s dedicated stealth address, over which Bob gains control upon receiving assets.
4. Alice derives a temporary public key R from r and sends it to a public registry contract (or any mutually agreed location accessible to Bob).
5. Bob periodically scans the registry contract for newly added temporary public keys. Since the registry is public and contains entries from multiple senders, Bob doesn’t yet know which one belongs to him.
6. Bob processes each new record by computing generate_address(R,m). If the resulting address holds assets, it was created and authorized by Alice; otherwise, it’s irrelevant.
7. Bob computes the spending key for this stealth address via generate_spending_key(R,m), i.e., p = m + hash(A), thereby gaining control over address A.
The above description simplifies many complex mathematical operations. The entire information exchange resembles two spies writing coded messages on a public bulletin board—only they possess the secret data needed to decode them, even though the encoding/decoding method is public knowledge.
This exchange closely mirrors the famous Diffie-Hellman (DH) key exchange protocol, allowing both parties to compute a shared secret—the stealth address A—without revealing their individual secrets (Bob’s root key m and Alice’s temporary key r). For those unfamiliar with DH, the color mixing analogy below offers intuitive understanding.
One additional step beyond standard DH: after independently deriving the shared secret A, it cannot be used directly as a private key since Alice also knows A. Instead, define the spending key as p = m + hash(A), treating A as a public key. Since only Bob knows the root spending key m, he becomes the sole controller of the stealth address.
Under this scheme, every time a recipient receives a new transaction, funds go to a fresh EOA address. The recipient uses their root spending key to iteratively compute potential spending keys until finding one matching incoming funds.
However, there remains an issue: the newly generated stealth address starts as an EOA without ETH or gas tokens, so Bob cannot initiate transactions. Gas sponsorship via a smart contract wallet’s Paymaster is required to enable private transactions. Thus, modifications are needed to the recipient address:
Use the CREATE2 opcode during contract deployment—with appropriate parameters (e.g., setting stealth address A as owner)—to calculate a Counterfactual address. This is a precomputed contract address that hasn't been deployed yet and remains an EOA.
Alice sends funds directly to this Counterfactual address. When Bob wants to use the funds, he deploys the contract at that address, enabling access to gas sponsorship (this step can also be proactively completed by Alice or the Particle network).
We refer to this Counterfactual address as a smart stealth address. Bob anonymously accesses assets under this smart stealth address as follows:
Deposit funds into Paymaster from any of his addresses; Paymaster returns a ZK-verified deposit receipt.
Using AA mechanics, submit a UserOperation from any address (even one with zero balance) to the Bundler node, invoking assets under the stealth address. Bob simply presents the ZK receipt from a new address to Paymaster, which covers the transaction fee paid to the Bundler.
This works similarly to Tornado Cash, where a ZK-verified receipt proves prior inclusion in a Merkle tree leaf without revealing which specific leaf was spent, thereby breaking the link between depositor and spender.
In summary, Particle combines AA and stealth addressing to elegantly achieve private transfers through smart stealth wallets.
Particle Chain & Omnichain Account Abstraction
Particle Chain is a POS blockchain designed specifically for Omnichain Account Abstraction. Given that neither present nor future landscapes favor single-chain dominance, enhancing user experience across multiple chains is vital.
Current ERC-4337 account abstraction systems face certain challenges in multi-chain environments:
-
A user’s address may differ across chains depending on contract design.
-
Managing contract wallets across chains requires manual repetition of operations (e.g., updating admins). Worse, if admin permissions are updated and old verification methods discarded on one chain, recovery becomes impossible on others.
-
Users must hold native gas tokens on each chain or maintain pre-funded balances in Paymasters. For developers, enabling zero-cost user experiences or custom features requires deploying and funding custom Paymasters on every chain—an operational burden.
Particle Chain’s Omnichain Account Abstraction addresses these pain points:
-
Create the AA wallet on Particle Chain.
-
Use cross-chain protocols like LayerZero or other AMBs (Arbitrary Message Bridges) to synchronize operations—creation, upgrades, permission changes—across all chains. Wallets on other chains act as references to the primary wallet; modifying the original automatically updates all copies.
-
Ensure consistent wallet addresses across chains using Deployer Contracts with identical parameters.
-
Cross-chain calls between wallets aren’t limited to originating from Particle Chain.
-
Issue a Unified Gas Token serving as universal gas currency across chains. Leveraging Paymaster, ERC-20 tokens can cover gas fees. Even without native gas or pre-funded Paymaster balance, users can initiate cross-chain transactions consuming Unified Gas Token on eligible chains.
Beyond these uses, Particle Chain may eventually serve as:
-
A decentralized network for generating zkWaaS proofs and salts.
-
An incentive layer for Bundlers across chains, promoting better decentralization.
-
The Solver network for Intent Fusion Protocol.
Within Particle Chain’s narrative, the Unified Gas Token serves as the central value capture mechanism:
-
Paying gas fees represents a repeatedly validated, strong demand and value capture mechanism in crypto.
-
The Unified Gas Token introduces the concept of abstracting the gas layer from existing public chain ecosystems, an abstraction unachievable without Particle Chain and its wallet infrastructure. Hence, the token embodies intrinsic value within the Particle ecosystem. Once established, user engagement, growth across chains, and the token’s value become mutually reinforcing.
-
Unified gas is also a driver toward Chainless experiences. Using a single token drastically simplifies user workflows and cognitive load. In the future, even in multi-chain settings, users may remain oblivious to underlying infrastructure—just as today’s Web2 users interact with servers without knowing their location, specs, programming languages, or databases.
-
Users brought in by dApps directly empower the Unified Gas Token, creating rich utility scenarios.
Intent Fusion Protocol
Typically, using various dApps requires constant path planning:
-
If liquidity is missing on one DEX, you must check another.
-
Uncertain which同类 dApp best fulfills your transaction needs.
-
Need to approve before using many functions—what even is “approve”?
-
Wallet dust cleanup—converting small amounts of various tokens into one—is tedious.
-
Complex multi-step goals: e.g., high-leverage borrowing involving swap → stake → borrow → swap again → stake → borrow…
These represent just the tip of the iceberg in today’s DeFi world. As dApp diversity grows in the era of Web3 mass adoption, interaction complexity could become overwhelming.
Thus, replacing explicit steps with user intent makes a world of difference in UX. Intents versus operations resemble declarative programming versus imperative programming. Declarative statements feel simpler—you state what you want without worrying about implementation details, which are handled by layered underlying imperative code.
Likewise, using intents requires supporting infrastructure. Let’s walk through the full flow:
1. Users express their intent—via natural language or other forms—as a Request For Solver (RFS) submitted to the Solver network. Solvers interpret intents. Common examples include aggregators like 1inch, which find optimal DEX routes, but these are not yet sufficiently generic or powerful for broader vision.
2. Multiple Solvers respond competitively. Responses are written in Intent DSL and parsed by the client into human-readable formats. They include Input Constraints and Output Constraints defining acceptable input/output ranges. Users can also set custom constraints. A simple example: during a swap, the minimum output shown is a type of constraint. Users choose among responses.
3. Sign the selected intent.
4. The Solver specifies an Executor contract and submits the intent to a Reactor response contract.
5. Reactor collects required inputs (e.g., assets) from the user’s account, forwards the intent to Executor, which invokes relevant logic contracts and returns the result to Reactor. Reactor checks constraints and, if valid, delivers output to the user.
Imagine telling ChatGPT your needs—no matter how complex—and receiving a ready-to-use outcome. As long as you’re satisfied with the result, you can proceed without understanding the internal process.
Conclusion
Particle Network proposes a holistic solution: a triad of zkWaaS, Particle Chain, and Intent Fusion Protocol that together deliver Web2-style private OAuth login, private transactions, omnichain account abstraction, and intent-driven transaction paradigms. Each feature targets a segment of Web3’s current friction points, laying the groundwork for future mass adoption in both product design and technology. From an ecosystem and business standpoint, its B2B2C model uses WaaS as an entry point to scale and standardize the entire product stack, co-building the ecosystem with dApp developers to create a low-barrier, high-experience Web3 environment for users.
Of course, different projects have varying visions for achieving Web3 mass adoption. Beyond evaluating individual projects, we hope diverse approaches spark deeper reflection on current onboarding frictions, user needs and pain points, and the collective evolution of the broader ecosystem.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
