> For the complete documentation index, see [llms.txt](https://void-protocol-2.gitbook.io/void-protocol-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://void-protocol-2.gitbook.io/void-protocol-docs/security/security-model.md).

# Security Model

## Security & Trust

VOID Protocol is **non-custodial**.

Funds can only leave the private pool when a valid proof is produced for an unspent note.

{% hint style="info" %}
VOID does not custody user funds or hold user private keys.
{% endhint %}

### Core Protections

<table data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Zero-Knowledge Proofs</strong></td><td>Every private spend requires a valid proof that is verified on-chain.</td></tr><tr><td><strong>Nullifiers</strong></td><td>Prevent the same private note from being spent twice.</td></tr><tr><td><strong>Asset Registry</strong></td><td>Only registered assets are accepted by the protocol.</td></tr><tr><td><strong>Trade Protection</strong></td><td>Trades use slippage controls, a <strong>3% maximum price impact</strong> and <strong>120-second quotes</strong>.</td></tr><tr><td><strong>Encrypted Notes</strong></td><td>Private notes are stored encrypted in the browser.</td></tr></tbody></table>

### Admin Powers on Testnet

A **2-of-3 Safe** controls key protocol settings on Robinhood Chain Testnet.

The Safe can:

* manage supported assets
* manage supported trading pairs
* manage protocol fee settings
* receive the **0.5% VOID trade fee**
* control the association-set registry
* publish and revoke association-set roots
* control the pool pause function

{% hint style="success" %}
Pausing the pool does **not block withdrawals**.

The pause can stop deposits, Private Sends and trades. Withdrawals cannot be paused, so users can still exit existing private positions.
{% endhint %}

#### Current Operational Keys

The **deployer wallet** currently operates the relayer and mints faucet tokens on testnet.

Before mainnet, operational responsibilities are planned to be separated from the deployer wallet and moved into the finalized production governance and key-management structure.

{% hint style="warning" %}
Association sets are not yet enforced.

The current testnet association root is a placeholder, and the circuits do not yet verify association-set membership.
{% endhint %}

### What Admins Cannot Do

Protocol administrators cannot:

* spend user notes
* change note ownership
* create a valid spend without the required proof
* reuse an already-recorded nullifier

### Trust Assumptions

VOID reduces trust requirements, but the current testnet still includes several trust assumptions.

#### Hosted Proof Service

The hosted proof service receives the prover inputs required to generate each proof.

It does not control user spending keys and cannot independently authorize a spend.

See **Proof Service** for the full model.

#### Relayer

The VOID relayer can:

* submit supported private transactions
* pay gas for relayed transactions
* delay or refuse submission

The relayer cannot:

* alter a valid signed private action into a different transaction
* spend user notes independently
* take control of user funds

#### Asset Issuers

Some supported tokens retain issuer-level controls.

For example, **USDG can be frozen by its issuer**, including USDG held inside the VOID contract.

{% hint style="warning" %}
Protocol privacy does not remove control mechanisms built into the underlying asset.
{% endhint %}

#### Note Creators

Whoever creates a note chooses its nullifier secret. A sender can therefore potentially recognise when a note they created for someone else is later spent. They cannot spend it. Recipient-private nullifier derivation is planned.

### Audit Status

{% hint style="danger" %}
VOID is currently **unaudited testnet software**.

Use testnet tokens only.
{% endhint %}

A full external security review is required before mainnet launch.

An external security review by **Cyberscope** is in progress and is not complete. It covers the testnet launch contracts:

* VOID token
* Uniswap v4 launch hook
* LP lockers

Before mainnet, a further audit is **planned** to cover:

* the mainnet protocol contracts
* the Noir circuits and verifier integration
* production deployment configuration
* permissions and admin roles

Mainnet operational controls are also being finalized, including:

* key separation
* multisig governance
* monitoring
* emergency procedures
* production deployment verification

### Mainnet Security Gate

Mainnet is planned only after:

1. final production contracts are deployed
2. deployed code and configuration are verified
3. the external security review is completed
4. launch contracts and permissions are confirmed
5. final operational checks are passed
6. trading is explicitly opened

The following must also be in place before mainnet:

* local browser proving
* association-set enforcement in the circuits
* selective disclosure
* note backup and recovery
* relayer funding and abuse protection
* paid RPC infrastructure
* a published privacy and threat-model review
* a bug bounty
* production key separation and monitoring

{% hint style="info" %}
Security and deployment verification take priority over launch timing.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://void-protocol-2.gitbook.io/void-protocol-docs/security/security-model.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.