Particle's Confidential zkStack: Private Social Logins and Transactions for dApps

Particle's Confidential zkStack: Private Social Logins and Transactions for dApps

Table of Contents:

Web3 was founded upon the principle that each person should be the ultimate owner of their data, having the choice of who to share it with and when. However, in its development, it has been common to see trade-offs that compromise these tenets to create friendlier solutions or find alternatives to infrastructure constraints (such as scalability issues, user experience, etc.)

On the other hand, Wallet-as-a-Service (WaaS) tools are uniquely poised to bootstrap Web3’s adoption via friendlier user experiences in handling and creating wallets. They allow users to create and access wallets through Web2 accounts, and embed wallets directly in-app for a seamless experience. WaaS tools, however, do not currently offer any privacy for their users. When interacting with them, end-users make two privacy trade-offs:

  • To connect to dApps via their Web2 identities, they reveal (some) personal information to WaaS providers and the dApps integrating them. This can result in their WaaS-created wallets being linked to their Web2 social identities.
  • WaaS tools give their users access to the most popular L1 and L2 blockchains, most of which are transparent by default. As such, the wallet addresses created by users can also potentially be linked to their other existing on-chain wallet addresses. In this scenario, all of the user's on-chain and off-chain identities, which might include CEX accounts, are completely bound and can be tracked.

By integrating zero-knowledge (ZK) technology into its product mix, Particle is introducing a first-of-its-kind product: a Confidential zkStack working on top of Particle's WaaS. This article will explore the advances of Particle Network’s upcoming v2 in the field of user privacy, tackling both issues above. We’ll also discuss how our Confidential zkStack meets present and future data management needs of both end-users and developers.

Solving privacy trade-offs via zero-knowledge technology

Although (when properly executed) WaaS tools can be fully self-custodial, meaning that users’ assets are always safe, the fact that they reveal personal information along the process is most definitely not ideal. In the wrong hands, this information could easily be extrapolated to understand which other wallets, CEX accounts, or funds are owned by any given user, resulting in a considerable vulnerability.

It’s worth pointing out now that the field of blockchain privacy is ridden by issues of its own. Blockchains’ verifiability and reliability can be at least partly credited to their transparency, as anyone can verify information at any time. Creating smart contract blockchains that are private by default, efficient, scalable, and are also verifiable and reliable has proven near-impossible. The few solutions aiming to do this have struggled to drive much adoption, as they also tend to be fundamentally incompatible with the existing ecosystem, further fragmenting its liquidity and interoperability. 

Among these constraints, Zero-Knowledge (ZK) technology has emerged to provide a much-needed solution, allowing for privacy tools that are fully compatible and can be integrated into the existing ecosystem. Succinctly put, ZK technology works by enabling an entity (the prover) to prove its knowledge of a fact (such as its identity, holdings, etc) to another (the verifier) without revealing underlying or related information. An example of such information is how, by sending an Ethereum transaction, the sender indirectly reveals their entire holdings, transaction history, and sometimes identity to the recipient. ZK tech is used in scalability solutions, such as zkEVMs, to improve blockchain throughput. Similarly, privacy-focused projects (like ZCash) also use it to and obfuscate users’ balances and transaction history.

In the case of WaaS tools, introducing zero-knowledge technology means that users can link their social identities to a given wallet without any observer learning about them, let alone knowing which wallets belong to whom. ZK-tech also provides additional benefits, such as:

1. Performance and efficiency, making it an industry standard in this regard.

2. Regulatory friendliness. The privacy protection offered by ZK technology, with its voluntary disclosures scheme and exclusionary privacy sets, is building momentum towards its adoption as a regulatory standard.

As such, we’re left with two questions:

Let’s now look at how our zkStack makes this possible, as well as its implications and ramifications.

Benefits of the Confidential zkStack

Released as a part of Particle Network’s v2, Confidential zkStack achieves two goals: 

  • To protect users’ identities so that their personal information is never exposed during the process of creating a wallet, and wallets cannot be linked to their owners.
  • To operate in synergy with other components of Particle’s v2, such as Omnichain Account Abstraction, for private transactions.

Besides the obvious perks of private transactions and users’ identities being known only by themselves, it’s important to consider some of the other equally positive side-effects of our zkStack’ privacy:

  • For developers and projects, having an underlying reliable system that does not handle user data can save many headaches. Regulations like the European GDPR have made considerable progress regarding user data management and privacy. And while these regulations are primarily good, complying with them might incur time, effort, and, therefore, costs for projects. By having complete plausible deniability of ever handling user data, projects can save themselves considerable time and effort.
  • For end-users, conducting transactions without being observed means that their strategies cannot be leaked, copied, arbitraged, or directly copied.
  • Similarly, end-users can have the peace of mind that their data cannot be sold, stolen, leaked, or otherwise mishandled by good- or ill-meaning service operators.

While the above is not an exhaustive list (privacy has many benefits!), it should now be clear that, in this context, privacy is a net improvement for all participants of the WaaS framework. Let’s now dive deeper into the inner workings of the Confidential zkStack.

How the Confidential zkStack works

Particle's v2 design introduces different components that, together, constitute our Confidential zkStack. For confidential logins, the system uses JWT (JSON Web Tokens) as the private witnesses in a zero-knowledge circuit that verifies the provider’s digital signature and user information. Particle’s system also uses the Particle Chain, a proprietary zkEVM powered by the network’s native universal gas token, to generate ZK-proofs. This is complemented by confidential Paymasters that pay for transactions on behalf of users to protect their privacy. Although with key differences, the overall design derives inspiration from Sui’s zkLogin.

Now, let’s dive deeper into how the Confidential zkStack achieves its two goals.

Goal #1: Identity privacy

To onboard users while protecting their privacy, our zkStack uses a system where users first generate an ephemeral keypair while simultaneously going through a verification process. Then, they use their verified credentials to generate a ZK-proof through the Particle Chain, which they submit to a verifier to conclude the process. 

This is diagrammed below:

Confidential Login user flow.

Elaborating further, confidential logins work as follows: 

A) Set Up

To create the common reference string (CRS) for the Confidential Login circuit, Particle uses Groth16  –but may consider zkSTARK in the future. The trusted setup generates a proving key and a verifying key for the OAuth provider. Particle is currently also working towards a non-trusted setup. 

B) Signing

  1. Ephemeral key generation: When a user accesses their wallet, an ephemeral KeyPair is generated. The user then chooses a max epoch, which defines the keypair’s expiration date.
  2. The app prompts the user to authenticate through an OAuth provider sign-in using a custom nonce constructed using randomness, the ephemeral key, and the max epoch (decided by the user, which determines how long before the ephemeral keys expire and they need to be generated again). 
  3. This process returns a JWT containing a header and payload.
  4. The JWT is sent to a salt service, which returns a unique salt –a random numeric string– upon validating the JWT.
  5. The JWT, salt, and ephemeral public key are sent to the Particle Chain, which uses them to generate a ZK-proof of the complete claim and sends it to the on-chain verifier.

The claim states that:

i) The nonce is correctly formed, and includes the public key.

ii) The key claim is consistent with the JWT.

iii) The Particle address is consistent with the key claim and salt.

iv) The OAuth provider's signature is correct.

Along with the zk-proof, the address seed, claims, and header are sent to the dApp.

Note that the circuit generates a zk-address for the user. The user creates a transaction and signs it to get an ephemeral signature. They also send other information, including the ephemeral public key, signature, proof, address seed, claims, and header.

C) Verification

Two types of verifications are possible:

1. Smart contract verification on the Particle Chain.

2. Decentralized verification by the Particle Chain’s validators, who are rewarded by the system in Particle Network’s tokens.

Verification process:

The verifying entity receives the users’ information. They then conduct the following checks:

1. Verify the transaction's sender: Ensure that the transaction's sender is derived from the address seed and matches the revealed claims.

2. Verify the signing user against the user’s public key.

3. Verify the ZK-proof.

4. Retrieve the public key and check whether it is the same one used in the ZK proof.

D) Storage

Once the user is authenticated, a map is stored on-chain for automatic logins until the user’s selected epoch expires.

Goal #2: Transactional privacy

Particle leverages ERC-4337 account abstraction (AA) to protect users’ privacy when transacting. The system uses a confidential Paymaster to send users’ transactions for them, breaking public on-chain links. Particle also uses a Stealth Smart Account mechanism to keep the receiver private. Additionally, Particle also implements Guardian accounts and self-controlled social recovery.

Particle’s v2 private transaction system is diagrammed below:

Full Private Transaction system. On the left, V. Buterin's proposed stealth address design (click to expand.)

The process can be described as follows:

  1. Dynamic stealth address calculation: At the initiation of a transaction, Alice, the sender, dynamically calculates Bob's stealth address by utilizing Bob's meta-stealth data. This calculation is a pivotal step in ensuring the privacy and security of the subsequent transaction.
  2. Smart stealth address computation: Building upon the dynamically calculated stealth address, Alice further computes what is referred to as the Stealth Smart Account. This specialized address serves as the destination for the asset transfer, introducing an additional layer of privacy and complexity to the transaction.
  3. Secure stealth address retrieval: On the receiving end, Bob systematically scans for his stealth address within the incoming transaction data. Once located, Bob generates a spending key, providing him with the means to access and manage the received assets securely.
  4. Confidential gas fee deposit: To facilitate the transaction and cover its associated gas fees, Bob employs any address to deposit the requisite gas fee into the Confidential Paymaster. This confidential deposit ensures the integrity and privacy of the transaction.
  5. Flexible transaction signing: Armed with the spending key, Bob can now sign a signature for the UserOperation linked to the Stealth Smart Account for his convenience. The flexibility in timing adds an extra layer of security, allowing Bob to strategically execute the signing process.
  6. Proof submission to Confidential Paymaster: Following the signing of the UserOperation, Bob submits the generated proof to the Confidential Paymaster. This proof acts as a confirmation, enabling the Paymaster to sponsor the necessary gas for the transaction. This final step ensures that the transaction proceeds seamlessly while maintaining the highest privacy standards.

In essence, this intricate and multifaceted process not only safeguards the privacy of individual transactions but also establishes a robust foundation for secure and confidential smart contract interactions. Particle Network's commitment to transactional privacy is exemplified through the seamless integration of ERC-4337 AA, stealth addresses, and Confidential Paymaster.

Parting thoughts

In the past, we've written extensively about the need for decentralized applications to compete with Web2 alternatives. This is only possible by leveraging the unique advantages of Web3 –such as self-ownership, self-custodianship near-instant settlements, and many more– while retaining a similar user experience. However, it's important to recognize that full transparency also creates problems that Web2 solutions do not typically face. For example, while a user trusting a FinTech (Paypal, Venmo) needs to relinquish control of their assets temporarily, others cannot scrutinize their data, even upon interaction.

By enabling transactional and identity privacy, our zkStack presents a straightforward solution to the transparency problem while further empowering users to become the sole controllers and owners of their data. Developers can then use this powerful tool to create more attractive products for end-users, regardless of whether the latter are interested in actively protecting their privacy or just relieved that no information leak or malicious observer can take advantage of their data.

Once again, it's also worth pointing out that the Confidential zkStack will be released as a part of Particle Network's v2. By combining it with other key infrastructural components –such as Intent-centric modules, a token-centric ecosystem, and Omnichain Account Abstraction– Particle aims to improve development flow, facilitating the creation of highly advanced decentralized applications with a great user experience. The interactions among the three pillars of v2 (Omnichain AA, Intent-centric modules, and the Confidential zkStack) open the possibility for developers to also create brand-new products and services, ultimately driving Web3 innovation.


Particle Network's Modular Smart Wallet-as-a-Service solutions are 100% free for developers and teams. If you have any inquiries about integrating with us, feel free to book a meeting with one of our agents!


About Particle Network

Particle Network Logo

Particle Network is building the Intent-Centric Access Layer of Web3. Particle's Modular Smart Wallet-as-a-Service tools allow developers to tap into MPC-TSS and social logins to enable self-custodial, dApp-embedded wallets accessible through users' Web2 accounts. This also allows them to leverage ERC-4337 account abstraction, enabling a seamless experience with maximum flexibility. Similarly, Particle Network has already released the first-ever account abstraction protocol for the Bitcoin ecosystem, BTC Connect. Particle's next evolutionary steps include the introduction of Omnichain Abstraction, a Confidential zkStack, and the Intent Fusion Protocol, elevating users' experience within dApps and paving the way for mass Web3 adoption.

Website | Docs | Discord | Twitter

Share this article

About the author(s)

Peter Pan

Peter Pan

Co-Founder and CTO of Particle Network.
Vijay Singh

Vijay Singh

ZK Tech Lead at Particle Network.
Carlos Maximiliano Cano

Carlos Maximiliano Cano

Particle's Content Manager. He's been in Web3 since 2017, collaborating with technical and marketing teams in crowdfunding, research, DeFi, privacy, and zero-knowledge proofs.