Skip to main content
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.