ZK Proofs
Generate zero-knowledge proofs of financial statements for trustless verification without revealing underlying data.
Overview
Axiomatic includes a zero-knowledge proving system that generates cryptographic proofs of financial statements. These proofs allow any third party — auditors, counterparties, regulators, or smart contracts — to verify that your books are correct without seeing the underlying transactions.
The system uses a custom prover built on Halo2 (PLONK-based) that operates on account-level aggregates rather than individual journal lines, keeping encrypted data private while proving aggregate correctness.
Proof Types
| Type | What It Proves | Use Case |
|---|---|---|
| Period Close | Total debits = total credits for a period; Merkle root of account balances | Period-end attestation |
| Solvency | Total assets ≥ total liabilities | Proof of solvency for creditors or investors |
| NAV | Net asset value computation is correct | Fund reporting to LPs |
| Waterfall | Distribution waterfall follows the declared tier structure | LP/GP distribution verification |
| Settlement | A settlement was executed correctly | Cross-entity settlement attestation |
| IC Reconciliation | Two entities' intercompany balances match (using Poseidon commitments) | Multiparty reconciliation without revealing balances |
| Consolidation | Parent-subsidiary consolidation is correct, composing subsidiary proofs | Group audit |
How It Works
1. Witness Building
When a proof is requested, the system builds a witness from your ledger data. The witness contains the values the circuit needs to verify — aggregated account balances, Merkle roots, and hashed identifiers. No plaintext financial data leaves the encryption boundary.
For a period close proof, the witness includes:
- Account-level debit and credit totals (from aggregated, decrypted journal lines)
- Account role hashes (SHA-256 of account IDs)
- A Merkle root over all account balances
- Period and entity identifiers (hashed)
2. Proof Generation
The witness is passed to the axiomatic-prover binary, which runs the appropriate circuit:
| Command | Circuit |
|---|---|
prove-period | Period close balance verification |
prove-solvency | Asset ≥ liability check |
prove-ic | Intercompany reconciliation with blinded commitments |
prove-consol | Consolidation proof composing subsidiary proofs |
The prover outputs a proof blob and public inputs. The proof is stored in the database and the status transitions from GENERATING to VALID (or INVALID / FAILED).
3. Verification
Proofs can be verified independently using the same prover binary's verify command. Verification checks the proof against the public inputs without needing access to the original witness data.
4. Onchain Anchoring
Verified proofs can be anchored onchain to the Base network via two smart contracts:
SnapshotAnchor — Stores a hash of the trial balance snapshot with the entity hash and period end date. Any third party can verify that a snapshot was anchored at a specific time.
ProofRegistry — Registers the full proof onchain with its type, entity hash, and proof bytes. This enables fully onchain verification — a smart contract or external verifier can check the proof without trusting Axiomatic's servers.
Proof Statuses
| Status | Meaning |
|---|---|
| Generating | Proof is being computed by the prover |
| Valid | Proof generated and verified successfully |
| Invalid | Proof generated but verification failed (indicates a data inconsistency) |
| Failed | Prover encountered an error during generation |
Using ZK Proofs
Via the UI
Navigate to Verify → ZK Proofs to view all proofs for the current entity and book.
From this page you can:
- View proof details including public inputs and metadata
- Generate new proofs (requires a closed period for period close proofs)
- Verify existing proofs
- Download proof files
- See onchain anchoring status
Via the API
Generate a proof:
POST /api/proofs
{
"action": "generate",
"entityId": "your-entity-id",
"bookId": "your-book-id",
"periodId": "period-id",
"type": "PERIOD_CLOSE"
}Verify a proof:
POST /api/proofs
{
"action": "verify",
"proofId": "proof-id"
}List proofs:
GET /api/proofs?entityId=...&bookId=...&type=PERIOD_CLOSEAutomatic Generation
Period close proofs are automatically generated when a period is hard-closed. The proof is created in the background and linked to the closed period.
Consolidation Proofs
For parent-subsidiary structures, a consolidation proof composes the individual subsidiary period close proofs into a single proof that attests to the correctness of the consolidated trial balance.
The consolidation proof verifies:
- Each subsidiary has a valid period close proof for the same period
- Intercompany eliminations are correctly applied
- The consolidated balances are the sum of subsidiary balances minus eliminations
This enables a group-level audit where each subsidiary's proof can be independently verified, and the consolidation proof ties them together.
Privacy Properties
- Account IDs are hashed (SHA-256) before entering the circuit — the verifier sees hashes, not account names or codes
- Individual transactions are never part of the proof — only aggregated account-level balances
- Encrypted data stays encrypted — the prover operates on decrypted aggregates in memory, but the proof itself reveals only public inputs (totals, counts, Merkle roots)
- IC reconciliation proofs use Poseidon commitments with random blinding factors, so neither party's balance is revealed to the other — only whether they match