Skip to main content
Privacy Boost adopts a hybrid privacy architecture in which UTXO-based ZK state transitions are performed onchain, while sensitive data processing and proof generation are accelerated offchain through a TEE. At onchain, a user’s balance is represented not as a single account balance, but as a collection of multiple UTXOs. Each UTXO is inserted as a leaf in an append-only Merkle tree maintained by the contract, and when a transaction is executed, existing UTXOs are not deleted—only new UTXOs are added. To prevent double spending, the protocol assigns a one-time-use identifier (nullifier) to each UTXO, and the contract blocks reuse of the same UTXO by checking this nullifier. If a user submits a transaction directly, the gas-payer address can reveal their identity. To avoid this, Privacy Boost uses a submission model that assumes a relayer. The user requests a ZK proof, and the prover (who also acts as the relayer) generates the proof offchain. The prover then submits the data onchain on the user’s behalf, effectively separating the transaction sender from the gas payer and preserving the user’s privacy. At offchain, there exist a prover and indexer running inside the TEE. The TEE prover receives the user’s sensitive inputs, generates the ZK proof, and constructs the transaction; the TEE indexer indexes the user’s UTXOs, balances, and transaction history based on onchain events and makes them queryable. All operations on sensitive data is processed only inside attested TEE environments while the data is stored inside the encrypted DB, and only minimal information such as UTXO commitments and nullifiers is exposed externally. Below, we describe each component that constitutes Privacy Boost in more detail.

Shielded Pool Contract

The Shielded Pool contract is the core component that manages the onchain state of Privacy Boost and performs the following functions.
  • Merkle Tree Management: It maintains a LeanIMT-based incremental Merkle tree, where each leaf consists of a UTXO commitment. Whenever a user performs a deposit or transfer, a new UTXO is inserted into the Merkle tree.
  • Nullifier Registry: It maintains a nullifier mapping to mark UTXOs that have already been used. If the same nullifier is submitted again, the corresponding transaction is rejected.
  • ZK Proof Verification: It verifies the Groth16 proof generated by the TEE prover and checks that the prover actually owns the UTXO and that a valid state transition has been requested.

SDK

The Privacy Boost SDK provides an integrated interface that abstracts all interactions between the onchain Shielded Pool contract and the offchain TEE infrastructure (TEE prover, TEE indexer) at the application layer. Through this, wallet and application developers can naturally integrate Privacy Boost functionality while maintaining the existing EOA-based key system, and users do not need to manage privacy-specific keys or a new wallet stack. The key functions provided by the SDK are as follows.
  • Deterministic Key Derivation Using a signature generated from the user’s EOA key as deterministic entropy, it automatically derives:
    • Viewing Key
    • Nullifier Key
    This process is separated from the existing key management system, and users do not need to manage additional mnemonics or new seeds.
  • Input Aggregation and TEE Request Handling It collects user inputs (Merkle proofs, value, nullifier key, etc.) and securely sends them to the TEE prover. The SDK encapsulates TEE attestation verification, error handling, response parsing, authentication, and similar processes, allowing applications to request proof generation with simple function calls.
  • Balance and State Query API It provides a high-level API to query user state (owned UTXOs, balances, transaction history, nullification status, etc.) maintained by the TEE indexer. Developers therefore do not need to implement complex logic such as event scanning or ECDH decryption.
  • Zero-trust API The SDK enforces a zero-trust communication model by requiring remote attestation verification while interacting with backend TEE services. This guarantees that requests are served only by the intended TEE instance running the correct code, eliminating the need to trust offchain infrastructure operators or intermediaries. By handling attestation verification transparently within the SDK, Privacy Boost enables applications to safely transmit sensitive user data without exposing it to untrusted environments, while allowing developers to rely on hardware-backed guarantees without introducing operational complexity.
The SDK is designed with the goal of offloading all complex operations—ZK proof generation, nullifier management, encryption/decryption of UTXOs—to the offchain side while exposing only a simple API surface to clients. This enables any wallet or application to integrate Privacy Boost’s privacy functionality with minimal modifications.

TEE Indexer

The TEE indexer identifies information such as the sender, recipient, and transfer amount for all transactions occurring within Privacy Boost, and maintains the user’s balance state and transaction history offchain. This serves 2 purposes:
  1. To achieve instant UX by eliminating the need for users to scan all blockchain events each time.
  2. To securely store detailed transaction data (e.g. sender, recipient, token, amount) generated by the prover for regulatory audits and selective disclosure.

TEE Prover

The TEE prover generates a Groth16 proof based on the input provided by the user. The prover performs the following:
  • Verification of user signatures
  • Full ZK proof generation, including Merkle proof verification, balance checks, nullifier calculation, etc.
  • Delivery of transaction data to the indexer
  • Onchain transaction submission on behalf of the user
Thanks to this structure, user devices can enjoy instantaneous transaction experiences without performing any ZK computation.