Overview

1. ZK proof generation takes several seconds to tens of seconds, making it difficult to deliver a good UX.
2. It takes hundreds of thousands of gas to verify ZK proof onchain, which limits the throughput to tens of TPS.
3. Checking balances and transaction history requires onchain event scanning and decryption, which may take several seconds to several minutes depending on the environment.
4. Existing protocols only support pre-filtering-based AML, making it difficult to support regulatory-friendly structures such as auditability and selective disclosure.
5. They require ZK-friendly signature schemes (e.g. BabyJubjub-based EdDSA), which are not compatible with existing EOA wallets.

​

Design Principles

1. Low-latency for end users: Structural acceleration of proof generation and indexing Existing application-based privacy systems generate ZK proofs directly on user devices (browser/mobile). In this structure, a single ZK proof may take several seconds to tens of seconds to generate, which falls far short of the real-time performance expected in modern financial services. Moreover, each user must scan and decrypt contract events on their own, a process that can also take several seconds to minutes, accumulating delay and computational load. Consequently, despite ensuring privacy, such architectures suffer from practical UX limitations. Privacy Boost addresses these structural bottlenecks by introducing a server-side high-speed proof generation and indexing model.
   • ZK proof generation is performed in a TEE environment in parallel, reducing single-proof generation time to under 500ms.
   • The TEE indexer securely indexes all user balances and transaction history.
   • Through ZK proof aggregation, the onchain verification cost is amortized, significantly reducing gas fees while maintaining the same security level.
   As a result, the protocol achieves a high-performance private transfer layer free from user-side bottlenecks.
2. High Throughput: Onchain efficiency through proof aggregation and batch updates Privacy Boost can achieve 500+ TPS even within current blockchain scalability limits. This is made possible by reducing onchain gas costs through proof aggregation. Verifying a Groth16 proof inside the EVM—used by systems such as Tornado Cash, Privacy Pools, and Railgun—typically costs around 200–300K gas. When additional operations like Merkle tree insertion and Poseidon hash are included, a single transaction can consume over 1M gas. Because these ZK proofs must be generated per user transaction, existing privacy solutions are fundamentally constrained to under ~40 TPS, assuming a 30MGas per second as a baseline (the current gas target on Base). Privacy Boost aggregates multiple Groth16 proofs into a single Groth16 proof and performs Merkle tree batch insertions, significantly reducing the on-chain gas cost per transaction. Under the same conditions described above, this approach enables Privacy Boost to target throughput of 500+ TPS.
3. Self-custodial asset ownership
   • Asset ownership is secured solely by the user’s private key. Users generate ZK proofs based on signatures derived from their private keys to avoid exposing sensitive information onchain, and such proofs are required to perform transfers. All spending authority derives only from the user-held private key; even if a TEE or indexer node is compromised, control over the assets remains intact. Thus, even in scenarios involving physical attacks on TEEs such as TEE.fail, assets remain in a self-custody state.
   • TEE and its remote attestation provides compliance features while protecting users’ privacy Users send transaction data to a TEE environment, where it is stored and processed securely to provide advanced features such as high-throughput, low-latency, and compliance features. User data never leaves the enclave, preventing any privacy leakage during indexing or computation. Moreover, all TEE instances undergo remote attestation, allowing users to cryptographically verify that the enclave is running the expected machine configuration and code hash. This ensures that proofs and indexing are performed only inside an audited and unmodified execution environment. Privacy Boost TEEs are deployed on infrastructures such as Azure Confidential Computing, where the physical hardware is protected against access, making attacks extremely difficult even for privileged adversaries.
4. Programmable Compliance and Auditability AML/Compliance consists of two pillars: “prevention” and “auditability.” Existing protocols such as Railgun (Proof of Innocence) and Privacy Pools (Association Set Provider) focus primarily on pre-verification, but do not provide auditability, which is one of the core requirements of real-world regulation. Privacy Boost aims to achieve the following:
   • A programmable policy engine inside the TEE indexer, enabling selective disclosure.
   • Users can selectively provide transaction records for specific scopes or time periods when requested by regulators or auditors.
   • Audit logs can be generated when an auditor accesses the system.
   • Even with auditing capabilities, asset ownership remains protected by the ZK-based self-custody model, so any audit capabilities cannot affect fund.
   As a concrete example of this “programmable privacy,” Privacy Boost can leverage an onchain Access Control List (ACL) that explicitly defines which auditor or regulator public keys are authorized to request data from the TEE indexer. When an authorized key accesses user data through this interface, the TEE automatically triggers an onchain access-log event (e.g., Accessed()), producing a tamper-proof, publicly visible record of auditor activity. Importantly, only the fact of access—not the underlying data—appears onchain, preserving user privacy while ensuring full transparency and accountability. This architectural pattern demonstrates how Privacy Boost can meet real-world regulatory expectations without compromising its core privacy guarantees, thereby bridging the gap between privacy-preserving technology and compliance requirements.
5. Compatibility with Existing Ecosystem A key UX problem of existing privacy protocols is their “isolation from the ecosystem.” To reduce ZK inefficiency, privacy protocols typically rely on ZK-friendly curves such as BabyJubjub for signatures, which introduces the following issues:
   • Users must generate a new key pair incompatible with existing ECDSA-based EOAs.
   • Integration with existing wallets becomes difficult, requiring dedicated wallet stacks or separate mnemonic management.
   • Account fragmentation worsens UX.
   Since high-performance TEE instances amortize the cost of ZK proof generation for ECDSA signature verification, Privacy Boost enables:
   • Users to continue using their existing ECDSA-based EOA keys.
     • Modular verification contracts also allow other signature algorithms, enabling support for multisig and passkey-based smart wallets.
   • No need to generate new wallets or adopt separate signature schemes.
   • Full compatibility with the existing wallet ecosystem.
   This results in a seamless user experience without ecosystem fragmentation.