Privacy Boost’s shielded transactions are expressed as a single Groth16 ZK SNARK proof, and the onchain contract verifies the validity of this proof to process the transaction. This proof claims, in zero knowledge, that “the prover actually owns the specific input UTXO, spends the note without duplication, and correctly generates a new output note.” In this process, all of the user’s sensitive information is used only as private input inside the circuit and is not exposed onchain.Below, we first define the input structure used by the circuit, then describe how the circuit constraints operate, and finally introduce the execution model of the TEE-based prover.
The ZK circuit of Privacy Boost uses two major types of inputs:
Private Input – sensitive information known only to the user and which must not be exposed
Public Input – information publicly revealed for onchain verification
Private InputsThe prover running inside the TEE receives the following information from the user as private inputs:
Token information
Sender SpendingPublicKey
ECDSA signature generated using the sender’s spending key
Merkle proof (Merkle path and leaf index)
NullifierSecretKey
CommitmentPublicKey generated for this transaction
Input and output value
Input and output random value
These pieces of information include sensitive data such as the user’s asset ownership, balance, and transaction details, and are used only for ZK proof generation.Public InputsThe public inputs required for the contract to verify the proof are as follows:
Merkle root
Metadata hash
Nullifiers
Output UTXO commitments
All of these values are pseudonymous data; even if they are made public, the user’s sensitive information is not revealed.In other words, the public input is necessary for onchain verification but is structured not to affect privacy.Private inputs are “provided” to the prover, but the prover runs only inside a TEE verified through remote attestation, and these inputs cannot be read or extracted from outside the enclave.Thanks to the execution isolation of the TEE, even the prover operator cannot directly access this data, and all sensitive information is processed only inside the enclave.
The circuit verifies the following four constraints to prove that the given transaction is valid according to the protocol rules.First, the circuit verifies that the user actually agreed to this proof request. Prior to proof generation, the user leaves an ECDSA signature with their spending key on the hash of this transaction’s metadata (encrypted transaction details). This signature and the sender public key used to generate the signature are included as private inputs to the circuit, and the circuit verifies that this signature corresponds to the metadata hash, which is one of the public inputs.Through this process, the system ensures that the transaction was not arbitrarily constructed by a prover or TEE, but explicitly approved by the actual owner.Second, the circuit verifies that the UTXO used as input is currently a valid note. The user provides a Merkle proof for the UTXO they own as a private input, and the circuit reconstructs the Merkle root using this proof and the leaf value (UTXO commitment). The reconstructed root must match the Merkle root given as a public input. Through this, the circuit ensures that “the UTXO that the user claims to own is actually included in the onchain Merkle tree.”The leaf index from this process is also used later in nullifier generation. In this step, the circuit also recomputes the input UTXO that the user claims to own (see Section 3.1 for detailed computation).Third, the circuit verifies whether the nullifier has been correctly computed. The user provides their NullifierSecretKey and the leaf index of the UTXO as private inputs so that the circuit can compute the nullifier (see Section 3.4 for detailed computation). The value computed by the circuit must match the nullifier provided as a public input for the proof to hold.Through this constraint, the contract can confirm that the nullifier was correctly computed.Fourth, the circuit verifies that the input and output amounts are conserved. The circuit compares the sum of the input note values and the sum of the output note values provided as private inputs, and checks that the two values match exactly.
During the proof generation process, the TEE prover naturally comes to know the structural information of the transaction (sender, recipient, token, transfer value, etc.) based on the private inputs provided by the user. Privacy Boost is designed so that this information is shared only between attested TEE instances.The TEE prover sends the summary information required for transaction processing to the TEE indexer, and the indexer safely stores it in an enclave-internal database. This information is used to provide per-user UTXO query functionality or to provide data to auditors. All of these processes occur inside the TEE, and the data is not exposed outside the enclave under any other circumstances.Communication between the prover and indexer running in different instances, or communication between multiple indexer instances (indexer ↔ indexer) for fault tolerance purposes,3 is carried out through a TLS protocol with attestation features such as RA-TLS (Remote Attestation–enabled TLS). RA-TLS includes TEE attestation evidence in a normal TLS handshake and enables the following two checks:
Whether the other party is a valid TEE instance, and
Whether that instance has loaded a specific code image.
Both sides mutually verify the attestation evidence to confirm that “each party is running only the designated code inside a trustworthy enclave.” The TLS session is established only if this verification succeeds, and any data transmitted thereafter benefits from TLS confidentiality and integrity guarantees.Thanks to this structure, sensitive transaction information derived during the proof generation process is safely transmitted and processed only among attested TEE instances, and arbitrary protocol operators or external observers cannot access this data. This allows Privacy Boost to provide fast indexing and query functionality without compromising its privacy model.