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

# On-Chain Verification and Gas Economics

> Explains how Abyss verifies zero-knowledge proofs on-chain efficiently, and why verification cost is predictable, bounded, and economically sustainable.

The Abyss protocol deliberately separates **proof generation** from **proof verification**. Proof generation is computationally expensive and occurs off-chain, under the control of the user or wallet software. On-chain contracts are responsible only for **verification**, which is designed to be fast, deterministic, and gas-bounded.

This separation ensures that privacy does not impose systemic costs on the network and that verification remains viable under adversarial conditions.

***

#### VII.3.1 Verification Contract Responsibilities

The verifier contract performs a narrow and explicitly defined set of actions:

```
1. Validate Merkle root freshness
2. Check nullifier uniqueness
3. Verify the ZK-SNARK proof
4. Execute value transfer
5. Persist minimal state updates
```

All logic beyond this scope is intentionally excluded to minimize attack surface.

A representative verification flow:

```
require(validRoot[root], "INVALID_ROOT");
require(!nullifierUsed[nullifier], "NULLIFIER_SPENT");
require(verifyProof(proof, publicInputs), "INVALID_PROOF");

nullifierUsed[nullifier] = true;
transferV(recipient, amount);
```

Each step is atomic. If any check fails, the entire transaction reverts.

***

#### VII.3.2 Bounded Gas Costs

ZK-SNARK verification has **constant-time complexity** with respect to anonymity set size. This is critical. Verification cost does not grow as the pool grows, which prevents privacy from becoming economically prohibitive at scale.

Gas usage is therefore a function of:

* The chosen proof system
* The number of pairing checks
* The size of public inputs

It is *not* a function of:

* Number of deposits
* Number of withdrawals
* Pool size
* Historical activity

This makes Abyss economically stable under high adoption.

***

#### VII.3.3 State Minimalism

On-chain state is intentionally minimal:

```
State :=
{
  MerkleRoots[],
  NullifierSet
}
```

There are:

* No per-user balances
* No per-account histories
* No per-deposit records

This reduces storage growth, lowers long-term gas burden, and prevents state-based privacy leakage.

***

#### VII.3.4 Root Management

To support asynchronous proof generation, Abyss accepts a bounded window of recent Merkle roots:

```
validRoot[root] == true if
  root ∈ {latest N roots}
```

This allows users to generate proofs without racing block production, while preventing replay against obsolete states.

***

#### VII.3.5 Economic Fairness

Users who demand privacy bear the cost of proof generation and verification. There is no global subsidy that forces non-users to pay for privacy overhead. This aligns incentives cleanly and avoids socialized costs.

***

#### VII.3.6 Denial-of-Service Resistance

Verification contracts are resistant to DoS vectors:

* Proof verification fails fast on invalid inputs
* Nullifier checks are constant-time
* No loops over dynamic sets

Invalid proofs cost the sender gas but do not burden the system.

***

#### VII.3.7 Summary

On-chain verification in Abyss is:

* Deterministic
* Bounded in cost
* Independent of anonymity set size
* Resistant to manipulation

This ensures that strong privacy remains practical, not theoretical, even under real-world load.

***