Frequently Asked Questions

Why do agents need private transactions?

In a world of autonomous agents, every transaction reveals strategy.

Consider a competitive scenario: Agent A needs market research from Agent B. Without privacy:

• Agent B sees how much A is willing to pay (pricing intelligence)
• Observers see that A is researching this market (competitive intelligence)
• A's transaction history reveals business priorities

ZKA lets agents transact, prove capabilities, and build reputation without revealing sensitive information to counterparties or observers.

Isn't this just for cryptocurrency use cases?

No. ZKA uses zero-knowledge proofs for three distinct purposes:

1. Private payments (ZKA/Pay): Value transfer with hidden amounts and parties — settlement is pluggable across Aztec, EVM chains, and more.
2. Coordination proofs (ZKA/Coord): Prove that a multi-agent workflow was executed correctly without revealing the intermediate steps or methodology.
3. Capability attestation (ZKA/Attest): Prove you have a certification without revealing which specific credentials you hold.

Privacy-preserving computation is valuable even without cryptocurrency.

What about regulatory compliance and auditing?

ZKA supports progressive disclosure and integrates with ZKC (Zero-Knowledge Credentials) for user-controlled compliance. Privacy is the default, but agents can selectively reveal information when needed:

• Viewing keys: Grant auditors read access to specific transactions
• Balance proofs: Prove a payment was within compliance limits without revealing the exact amount (Noir circuit)
• Credential binding: Prove regulatory credentials are held without revealing identity (ZKC integration)

This is "privacy by default, transparency when required" — not "secrecy at all costs."

Why Noir?

Noir is a domain-specific language for writing zero-knowledge circuits, developed by Aztec Labs. ZKA chose Noir for several key properties:

ZKA was originally designed for Halo 2 (Pallas/Vesta, no trusted setup). Noir's ACIR abstraction means the Halo 2 backend can be added later when it matures — circuits don't change, only the backend.

Why Aztec as the primary deployment target?

Aztec is the only L2 with native private composability — which is exactly what ZKA/Coord needs. Specific advantages:

• Kernel circuits: Automatically handle recursive proof composition for ZKA/Coord steps
• Note/nullifier model: Aztec's indexed Merkle tree is a direct match (and upgrade) of ZKA's design
• Key hierarchy: Aztec's keys are a superset of ZKA's, with app-siloed key isolation as a bonus
• Ethereum settlement: Largest ecosystem, already integrated
• Client-side proving: Efficient on consumer hardware via Honk + Goblin Plonk

ZKA is not Aztec-exclusive — the Solidity verifier works on any EVM chain, and Noir's backend portability enables future targets — but Aztec is the primary deployment for its unique private composability.

What happened to the trusted-setup-free property?

ZKA's original Halo 2 design used Pallas/Vesta curves with IPA commitments — no trusted setup required. The move to Noir/Barretenberg (UltraHonk) uses BN254/Grumpkin with KZG commitments, which requires a universal trusted setup (SRS).

This is a deliberate trade-off:

• Gained: Largest ecosystem (EVM-native), Aztec composability, faster verification, smaller proofs
• Lost: Setup-free property
• Mitigated: Universal SRS (one ceremony for all circuits), well-established BN254 ceremonies
• Future: When the Halo 2 backend for Noir matures, ZKA circuits can target it without changes — restoring setup-free deployment

Where can ZKA proofs be verified?

Thanks to Noir's ACIR compilation, ZKA proofs can be verified on multiple targets:

• Aztec L2 (primary): Native private execution with kernel circuits
• Any EVM chain: Auto-generated Solidity verifier — Ethereum, Arbitrum, Base, Optimism, etc.
• Starknet: Via Garaga SDK → Cairo verifier
• zkVerify: Native UltraHonk verification pallet
• Cosmos/IBC: Feasible via CosmWasm verifier
• Solana: Feasible via BPF verifier program

What protocols are in the ZKA family?

How does ZKA/Coord work?

ZKA/Coord uses recursive proof composition to verify multi-agent workflows:

1. Agent A completes step 1, generates Noir proof P1
2. Agent B completes step 2, generates proof P2 that recursively verifies P1
3. Agent C completes step 3, generates proof P3 that recursively verifies P2
4. Final verifier checks P3 — confirms entire chain without seeing intermediate steps

On Aztec, this is even simpler: each coordination step is a private function call. Aztec's kernel circuit handles all recursive verification automatically via Goblin Plonk.

What's the circuit architecture?

ZKA is structured as a Noir workspace with modular circuit packages:

noir/
├── zka_lib/              # Shared primitives (Poseidon2, keys, Merkle)
├── zka_transfer/         # Transfer circuit (ZKA/Pay)
├── zka_withdrawal/       # Withdrawal circuit
├── zka_balance/          # Balance proof circuit
├── zka_coordination/     # Coordination circuit (ZKA/Coord)
├── zka_credential/       # ZKC credential binding
├── zka_bridge_namada_*/  # Namada import/export
└── zka_bridge_penumbra_*/# Penumbra import/export

How fast are ZKA proofs?

Browser-based proving via NoirJS + Barretenberg WASM is also supported, enabling client-side proof generation without a server.

Who maintains ZKA?

ZKA is developed by Pyramidal as part of the Pyramidal ZK protocol family. The specification is open (Apache 2.0), and all circuits are open-source Noir code.