> ## Documentation Index
> Fetch the complete documentation index at: https://docs.privacyboost.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Auditability

> How authorized auditors query shielded pool data with onchain accountability

Most privacy tools are all-or-nothing: they hide activity from everyone, leaving no way to satisfy an auditor or regulator. Privacy Boost is built differently.

For regulated deployments (stablecoin networks, RWA platforms, payment systems), Privacy Boost provides **scoped disclosure**: authorized auditors get precise, account-level visibility where they need it, while every other user stays private by default. Every data-access query leaves an immutable onchain trail.

***

## What This Enables

**For regulators:** Verified, account-level access with cryptographic identity binding (EIP-712 signatures). No way to query without leaving a trail.

**For users:** Privacy by default. Only explicitly authorized auditors can access your data, and you can verify onchain exactly who accessed what and when.

***

## How It Works

The audit system combines three components:

1. **AuditGateway contract**: An onchain registry of authorized auditors. Only registered addresses can query.
2. **Audit API**: Server-side endpoints that return account-specific data to verified auditors.
3. **Onchain audit log**: Every data-access query (transaction history and balances) is logged immutably onchain.

Every authorized query produces a permanent, publicly verifiable onchain record. Logging is submitted in the background so auditors get fast responses, with the record typically settling onchain within seconds of the query.

### Access Control

Audit requests pass through three verification layers:

| Layer                 | Mechanism                                                      | Rejects if                            |
| --------------------- | -------------------------------------------------------------- | ------------------------------------- |
| **Server-level key**  | Infrastructure secret header                                   | Missing or invalid                    |
| **EIP-712 signature** | Auditor signs the target account and action with their EOA key | Signature invalid or address mismatch |
| **Onchain registry**  | Contract checks auditor registration                           | Address not registered as auditor     |

***

## What Auditors Can Access

Auditors can query two things for a specific account:

### Transaction History

Paginated list of all transactions (deposits, transfers, withdrawals) for a given account, including:

* Transaction type and direction (in/out)
* Token ID and amount
* Counterparty (account ID for shielded transfers, Ethereum address for deposits/withdrawals)
* Timestamp

### Current Balances

Aggregated token balances for a given account, including the number of unspent notes per token.

***

## Auditors Hold No Keys

Auditors get answers, not access. They never touch viewing keys or onchain ciphertexts. The attested TEE decrypts transaction metadata during its normal indexing and serves only the one account a verified, signed query is scoped to. Even a compromised auditor key cannot read the pool.

Here's what happens:

1. The TEE server has already decrypted all transaction metadata as part of its normal indexing process. This data is stored inside the TEE's encrypted database, organized by account.
2. When an auditor submits a signed query for a specific account, the TEE verifies their authorization.
3. If authorized, the TEE returns only the requested data for the specified account, such as its history or balance.
4. The query is logged onchain asynchronously.

The auditor never sees encryption keys, other accounts' data, or anything beyond the specific account they queried.

***

## Hard Limits on Auditor Power

Auditor access is constrained by the protocol itself, not by policy or trust. Auditors can view only the accounts they are authorized to access. They cannot move funds under any circumstances, and every account-data query creates an onchain record.

| Can                                             | Cannot                                           |
| ----------------------------------------------- | ------------------------------------------------ |
| View transaction history for a specific account | Access private keys or viewing keys              |
| View current balances for a specific account    | Move funds or modify pool state                  |
| Filter transactions by type                     | Query without leaving an onchain audit trail     |
|                                                 | Perform blanket surveillance across all accounts |
|                                                 | Decrypt onchain ciphertexts directly             |

***

## Onchain Audit Log

After every data-access query, the server logs an immutable onchain record that:

* **Cannot be deleted or modified** by anyone
* **Is publicly verifiable**: anyone can check the audit trail
* **Holds auditors accountable**: excessive or unauthorized access is permanently recorded

The AuditGateway contract is standalone. It has no connection to the shielded pool and cannot affect fund storage or movement.

***

## Auditor Lifecycle

| Action                 | Who                | How                                  |
| ---------------------- | ------------------ | ------------------------------------ |
| **Add auditor**        | Contract owner     | Register address in AuditGateway     |
| **Remove auditor**     | Contract owner     | Remove address from AuditGateway     |
| **Query data**         | Registered auditor | Sign EIP-712 request, call audit API |
| **Review audit trail** | Anyone             | Read audit events from the contract  |

Audit queries use EIP-712 typed data signatures, so the auditor's wallet displays structured, human-readable fields instead of opaque hex. The domain separator prevents cross-chain replay.

***

## Why This Matters for Regulated Deployments

Privacy Boost lets you offer users real onchain privacy while giving your legal and risk teams a verifiable, account-scoped audit path, where every authorized access is permanently recorded onchain, so disclosure is provable rather than promised. You get the user-facing privacy of a shielded pool and the verifiable accountability regulators look for, in one protocol.

***

## Next Steps

* [Trust & Security](/product/trust-and-security): Full trust model and TEE guarantees
* [Protocol Deep Dive](/technical-explainer/protocol): How the shielded pool works
* [Glossary](/technical-explainer/glossary): Technical terminology reference