Confidential Stablecoin Transfers on Plasma: A zk-SNARK-Based Shielded Pool Design
A Research paper proposing a zk-SNARK based shielded pool for the Plasma team
Abstract
This paper explores designing confidential token transfers (USD₮) in Plasma by integrating zero-knowledge (ZK) proof modules. We consider using zk-SNARKs to implement a “shielded pool” for stablecoins. The goal is to allow private transfers of USD₮ within Plasma while maintaining interoperability with Plasma’s broader economy.
Introduction
Plasma is a purpose-built blockchain optimized for stablecoin transfers, specifically USD₮. It overcomes the limitations of general-purpose chains like Ethereum and Tron, which face issues of high costs, complexity, and centralization risks. Unlike these chains, Plasma is designed for high-frequency, low-margin transactional throughput, tailored to the unique demands of stablecoin transfers.
Stablecoin usage is predominantly driven by individual accounts and custodial wallets, rather than smart contract interfaces, raising significant privacy concerns. Plasma addresses this gap by planning to introduce a nascent mechanism called shielded transactions, which pushes for a privacy-preserving financial system.
We propose building a confidential transfer module specifically for token (USD₮) transfers using ZK proofs. The idea is to have a smart-contract-based shielded pool for a given stablecoin: users deposit coins into the pool, perform private transfers by presenting ZK proofs, and optionally withdraw back to normal accounts. Such shielded transfers could be enabled by a transaction flag or by using a parallel block layer (a “shielded transfer block”) that isolates private transactions.
Plasma Stablecoin Architecture
Plasma’s architecture overcomes the limitations of general-purpose Layer 1 blockchains like Ethereum and Tron through PlasmaBFT, a streamlined consensus mechanism derived from the HotStuff protocol. PlasmaBFT employs a two-phase commit process to minimize latency and boost throughput, utilizing Quorum Certificates (QCs) for rapid, provable finality and Aggregated QCs for swift leader recovery. By implementing pipelining, PlasmaBFT supports concurrent consensus rounds, ensuring robust handling of high transactional volumes critical for stablecoin transfers. Additionally, Plasma anchors its security to Bitcoin by periodically publishing Merkle roots of finalized blocks as state commitments on Bitcoin’s blockchain, creating immutable checkpoints that bolster censorship resistance and enable external verification, aligning Plasma’s security with Bitcoin’s battle-tested trust model.
Plasma ensures full Ethereum Virtual Machine (EVM) compatibility via the Reth execution layer. This modular Rust-based client enables the seamless deployment of Ethereum-compatible contracts, such as USD₮-focused ERC-20 contracts, leveraging Ethereum’s dominant stablecoin liquidity. Its innovative split-block architecture separates fee-paying general-purpose transactions (processed in the Execution Block) from zero-fee USD₮ transfers (handled in the Transfer Block), reducing computational overhead for simple transfers by bypassing EVM execution. This design, currently under research, supports zero-fee USD₮ transfers while generating revenue through fee-based DeFi and contract activities. Furthermore, Plasma’s exploration of shielded transactions aims to enable confidential USD₮ transfers, striking a balance between privacy and regulatory compliance.
Shielded Pools and Privacy
Plasma’s documentation on shielded transactions is sparse, offering limited implementation details, which motivates our design to enhance its privacy-preserving capabilities. Our solution introduces a smart-contract-based shielded pool for USD₮, enabling users to deposit funds, perform private transfers that obscure sender, recipient, and amount, and optionally withdraw to standard accounts. To implement this shielded pool, we propose using zero-knowledge proof systems, specifically zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge).
SNARK-Based Transfers
In our research, we propose a SNARK-based shielded pool design for enhancing privacy in USD₮ (USDT) transfers on the Plasma blockchain. This design draws inspiration from established privacy protocols like ZCash and Aztec.
Transaction Flow
When a user deposits public USD₮ into the shielded pool contract, the contract generates a note representing this deposit. This note is a cryptographic commitment to the deposited amount, typically utilizing a Pedersen hash, ensuring the value is hidden yet verifiable. The contract then adds this note to a Merkle tree that maintains a record of all active notes, facilitating efficient proof generation and verification. This approach mirrors ZCash’s use of commitments for privacy, ensuring that the deposited amount remains confidential while still being part of the blockchain’s state.
Using the Pedersen Hash to show an example of how a USD₮ deposit into a shielded pool could be represented.
A user deposits a total of 40 USDT into the shielded pool with a recipient public key, pk of 7, and a random blinding factor, r of 3. These inputs are then collected together and used to generate a note that is added to a Merkle tree for inclusion into the shielded pool.
USDT = 40, receipent_public_key = 7, and random_blinding_factor =3
For the scope of this paper, we decided to use scalar values (integers) for generator points (e.g., G1=5, G2=9, G3=13) to simplify the Pedersen hash calculation. This preserves the conceptual structure of the Pedersen hash—binding, hiding, and randomness.
Then, using the Pedersen Hash formula.
When these values are calculated, we are given a note of 302. What, then, does this mean?
When a user deposits 40 USD₮ into Plasma’s shielded pool, the smart contract generates a Pedersen commitment, resulting in a note value of 302. This cryptographic commitment conceals the deposited amount, ensuring privacy while allowing the note to be inserted as a leaf node in the Merkle tree. Later, the user can prove ownership of this note in zero knowledge, without revealing any details, or transfer it to another user by generating a zk-SNARK proof that validates the transaction’s integrity while keeping the amount hidden. This design leverages the efficiency of zk-SNARKs and Plasma’s architecture to enable secure and private stablecoin transfers.
The security of this mechanism stems from the note’s public value, 302, which reveals nothing about the underlying 40 USD₮ deposit. A randomness factor, r = 3, blinds the note, ensuring that only the user who knows the tuple (amount, public key, randomness) can open or spend it. This prevents actors from deducing the transaction’s details, even though the note is stored publicly in the Merkle tree. By combining Pedersen commitments with zk-SNARKs, Plasma’s shielded pool guarantees confidentiality and integrity, aligning with its goal of providing a privacy-preserving stablecoin ecosystem.
To prevent double-spending, each note is linked to a unique nullifier, derived from a private key associated with the note. When a note is spent, its nullifier is published on-chain, ensuring that the same note cannot be spent again. This mechanism is crucial for maintaining the integrity of the shielded pool, as it prevents malicious actors from reusing notes, a common attack vector in privacy-preserving systems. The nullifier’s publication ensures that all subsequent transactions can check against previously spent notes, leveraging Plasma’s consensus for validation.
To execute a private USDT transfer, a user initiates a “join-split” transaction, a process central to our SNARK-based design. The user selects some of their existing notes as inputs and creates new output notes, ensuring that the total value of the input notes equals that of the output notes, accounting for any fees or public amounts. The user then generates a zk-SNARK proof that certifies knowledge of the input notes' values and secret keys, and confirms that the outputs balance without disclosing any specific amounts. This proof, along with the commitments for the output notes and the nullifiers of the input notes, is submitted to the pool contract. The contract verifies the proof using an on-chain SNARK verifier, such as Groth16 or Plonk. If the proof is valid and the nullifiers have not been used before, the contract marks the input notes as spent and registers the new output notes. This process closely follows AZTEC’s model, where users hold encrypted “notes” and spend them via zero-knowledge proofs of balanced outputs, and resembles ZCash, where inputs and outputs are hidden, with only nullifiers and Merkle roots being public.
To withdraw USDT from the shielded pool, a user creates a special output note designated for public withdrawal of a specified amount, N USDT. This is achieved through a modified join-split transaction where one of the outputs is directed to a transparent address, ensuring compatibility with Plasma’s EVM compatibility via the Reth execution layer. The user provides proof that the sum of their hidden notes is at least N, allowing the contract to publicly transfer N USDT and mark the corresponding note as spent. Alternatively, withdrawal could be facilitated through a separate public API where the user reveals the secret associated with the note, offering flexibility in implementation. This dual approach ensures users can exit the shielded pool while maintaining privacy for their remaining balances.
Illustrative Example: Shielded Transfer & Withdrawal in Plasma’s Shielded Pool
This example demonstrates the practical feasibility of our proposed design in a real-world setting. We explore the streamlined process flow for transfers and withdrawals within our shielded pool, emphasizing how it ensures robust privacy while maintaining efficiency.
Transfer Scenario
Alice holds a note representing 100 USD₮ in Plasma’s shielded pool, and she wishes to send 30 USD₮ to Bob while retaining 70 USD₮ for herself. This transfer must obscure the sender, recipient, and transaction amount, aligning with the privacy goals of our shielded pool design. The process involves creating cryptographic commitments, generating a zk-SNARK proof, and updating the Merkle tree, all while preventing double-spending through nullifiers.
Alice possesses a note for 100 USD₮, represented by a Pedersen commitment C_1, stored as a leaf in the shielded pool’s Merkle tree. The commitment is defined as.
When this is computed, we get a commitment of 628, which conceals the amount of 100 USD₮ while binding it to Alice’s public key and blinding factor. This commitment is referred to as the Input note (the old or source of the transaction process).
For the Output note, which is a new note being generated by Alice, and is spendable. Here, Alice creates two notes: the first for Bob for 30 USD₮ ( C_2) and a balance note after the execution of the transaction, 70 USD₮ ( C_3).
A note for Bob for 30 USD₮, with commitment, C_2
A balance note for herself for 70 USD₮, with commitment, C_3
After Alice generates the notes, she proceeds with cryptographic steps to ensure a private and valid transfer. First, Alice generates a zk-SNARK proof to demonstrate three key properties:
She knows the secret values for C_1 and generator points and hence can prove ownership.
The input amount equals the output amounts (100 = 30 + 70); and
The output commitment for C_2 and C_3.
This proof, computed off-chain using Plasma’s publicly available SNARK proving key, leverages the homomorphic properties of Pedersen commitments to hide all sensitive data while confirming transaction validity, ensuring robust privacy.
To prevent double-spending, Alice computes a nullifier for C_1, derived from her secret key (skAlice) as.
Where ( H ) is a cryptographic hash function (e.g., SHA-256) and rho is a unique randomness factor tied to the note. This nullifier is published on-chain, allowing the shielded pool smart contract to check that C_1 has not been spent previously, a mechanism aligned with Zcash’s approach to invalidating spent notes. Alice then submits the zk-SNARK proof, the nullifier of C_1, and the new commitments C_2 = 301 and C_3 = 491 to the shielded pool smart contract. This submission initiates the on-chain verification process, maintaining confidentiality by revealing only the nullifier and commitments, which obscure the transaction’s amounts and participant identities.
The smart contract verifies the zk-SNARK proof using an on-chain verifier (Plonk), ensuring the transaction is valid and balanced, and confirms the nullifier’s uniqueness to prevent double-spending. Upon successful verification, the contract updates the Merkle tree by removing the leaf for C_1 = 628 and adding leaves for C_2 = 301 and C_3 = 491, reflecting the updated state of the shielded pool. With verification complete, the transaction is finalized and goes through, as PlasmaBFT’s consensus mechanism, utilizing Quorum Certificates, ensures rapid and provable finality. This process integrates seamlessly with Plasma’s architecture, including its Ethereum Virtual Machine (EVM) compatibility via the Reth execution layer, delivering a secure and efficient private USD₮ transfer while maintaining complete confidentiality of transaction details.
Withdrawal Scenario
In Plasma’s shielded pool, withdrawing funds is a straightforward process that keeps your privacy intact while meeting legal requirements. Imagine you have 100 USD₮ in a shielded note and want to withdraw 50 USD₮ to a public address, keeping the rest private. You start by selecting your note, represented by the formula.
The user then creates a public output for the 50 USD₮ withdrawal and a new shielded note for the remaining 50 USD₮.
A special proof (zk-SNARK) ensures you own the note and the amounts add up, all without revealing details. You also calculate a "nullifier" to prevent reusing the old note. After submitting this to the smart contract, it checks everything, processes the withdrawal, and updates the system, making the 50 USD₮ visible for regulators while keeping your remaining funds private.
Implementation
Our SNARK-based confidentiality scheme takes inspiration from Aztec’s architecture, which has demonstrated production-grade privacy for ERC20 tokens on Ethereum. By adapting this proven model, we bring similar confidential transaction guarantees to Plasma without compromising scalability or composability. At the core of this design is the integration of a zk-SNARK verifier contract, either based on Groth16 or Plonk, deployed on the Plasma chain.
Groth16 is favored for its succinctness, offering proof sizes as small as ~200 bytes and sub-10ms verification times, making it ideal for chains targeting high throughput and low-latency confirmation. Its drawback is the requirement for a circuit-specific trusted setup. Plonk, on the other hand, introduces a universal and updatable trusted setup, which simplifies developer workflows and supports multiple applications with a single setup ceremony, making it well-suited for extensible systems like Plasma that may support multiple confidential asset types or evolving privacy schemes.
To facilitate user-side proof generation, we propose publishing the proving keys derived during the trusted setup ceremony. These keys allow clients to construct zero-knowledge proofs off-chain, reducing computational burden on Plasma nodes. On-chain, the smart contract verifier can then efficiently verify the correctness of the confidential transfer without revealing any sensitive metadata—such as sender, receiver, or transfer amount.
This architecture is made feasible by Plasma’s full EVM compatibility, which is enabled through its use of the Reth execution layer. Reth, developed in Rust, is a modular Ethereum execution client that offers enhanced performance and flexibility compared to legacy implementations. Its modularity allows for tight integration with zero-knowledge circuits, including precompiles or custom opcodes for SNARK verification in future upgrades.
Overall, this SNARK integration does not only preserve the privacy of stablecoin (USD₮) transfers but also complements Plasma’s scalability goals, as verification costs are low and constant: irrespective of transaction complexity. In future iterations, additional features such as account abstraction or recursive SNARKs could be layered on to support more advanced privacy-preserving protocols and batched verification.
Advantages & Possible Challenges
SNARK proofs are notably compact, typically ranging from a few hundred bytes, and their verification within the Ethereum Virtual Machine (EVM) is relatively inexpensive for systems like Plonk. This efficiency helps maintain low on-chain costs, crucial for Plasma’s goal of zero-fee USD₮ transfers. Furthermore, SNARK technology is well-established, with mature implementations such as Plonk, and there is a proven track record of using SNARKs for ERC20 token confidentiality, as demonstrated by Aztec. The compact proof size and low verification cost make SNARKs suitable for Plasma’s high-frequency, low-margin transactional throughput, ensuring scalability without significant block bloat.
For example, Plonk achieves a prover time of over 4.7 seconds for Pedersen hash-based circuits, demonstrating its efficiency in generating zero-knowledge proofs.
Despite these advantages, several challenges must be addressed. A significant security consideration is the trusted setup required for SNARKs. If the secret parameters from this setup are leaked or improperly generated, it could enable an attacker to undetectably mint or double-spend tokens, a risk highlighted in cryptographic discussions. Additionally, generating SNARK proofs is computationally intensive, although this process occurs off-chain, mitigating on-chain performance impacts. To ensure that transaction amounts are positive and within specified limits, range proofs must be integrated, which increases the complexity and cost of the circuit, potentially affecting gas usage. Moreover, incorporating SNARK verification into Plasma’s consensus mechanism, such as PlasmaBFT, necessitates meticulous gas budgeting to prevent block bloat and maintain efficiency, especially given Plasma’s pipelining for concurrent consensus rounds.
In the context of zk-SNARKs, the worst-case scenario involves a compromised trusted setup, where an attacker gains access to the secret parameters. This could allow them to generate false proofs, enabling undetected token minting or double-spending within Plasma's shielded pool, thereby undermining the system's integrity. For instance, an attacker could exploit this vulnerability to create new notes out of thin air or spend notes they do not own, disrupting the shielded pool's confidentiality and security. To prevent this, multi-party computation (MPC) ceremonies, such as ZCash's Powers of Tau, are employed. These ceremonies involve numerous participants contributing to the setup generation, distributing trust, and reducing the risk of a single point of failure. By leveraging such robust MPC processes, Plasma can ensure the security of its zk-SNARK-based shielded pool while maintaining the efficiency and privacy benefits of the technology.
Compliance Mechanism
To ensure regulatory compliance while maintaining privacy, Plasma's shielded pool design allows for withdrawals to transparent addresses, making these transactions publicly verifiable. Regulators can monitor these public withdrawals to track the flow of funds out of the shielded pool, ensuring adherence to anti-money laundering (AML) and know-your-customer (KYC) regulations. Additionally, Plasma can provide a public API or dashboard specifically for regulatory bodies to query and analyze these withdrawal transactions, facilitating efficient oversight without compromising the privacy of shielded transfers within the pool. This approach balances the need for privacy with regulatory requirements, as the entry and exit points of funds remain transparent while internal shielded transfers remain confidential.
Conclusion
In summary, by adopting zk-SNARKs, Plasma achieves modern, verifiable privacy with a proven track record in protocols like ZCash and Aztec, ensuring robust confidentiality for stablecoin transfers. The use of Plonk’s universal trusted setup mitigates setup risks through audited, transparent ceremonies, balancing security and practicality. This approach maintains EVM compatibility via Plasma’s Reth execution layer and supports regulatory compliance by allowing optional public withdrawals. zk-SNARKs’ efficiency, maturity, and alignment with Plasma’s architecture make them the optimal choice for delivering a scalable, private, and cost-effective USD₮ ecosystem.
Side Notes
In the illustrative example of USD₮ deposits using a Pedersen hash, integers were employed to simplify the explanation and avoid the complexity of elliptic curve mathematics. In a real cryptographic implementation, the G1 values would represent distinct, fixed points on an elliptic curve, and operations would utilize point addition and scalar multiplication to ensure robust security and privacy.
References
Plasma Documentation. https://docs.plasma.to/
Plasma: The Stablecoin Singularity. Kairos Research.
Plasma: Stablecoin Infrastructure & The Trillion Dollar Opportunity. Delphi Digital. https://members.delphidigital.io/reports/plasma-stablecoin-infrastructure-the-trillion-dollar-opportunity
Aztec Network. https://docs.aztec.network/
Gonna read it soon