How the ZK Audit System works

Step 1

Capture every write, from every source.

On replica sets and sharded clusters, a change stream listener watches for every insert, update, delete, drop, rename, and index operation, regardless of whether it came from the shell, the app, or an external client. On standalone MongoDB, where change streams aren't available, an operation interceptor hooks into the driver as a fallback.

Each captured operation is encoded with an unambiguous, length-prefixed binary format, immune to delimiter-injection, and derived into a leaf as a keyed Poseidon vector commitment: leaf = Poseidon(key, opHash, dbHash, collHash, ts, docHash, salt). The key is generated at setup and shared only with authorized auditors, so an attacker who only sees the public leafsignal in a proof can't guess payloads and confirm what happened by brute force. The leaf is then inserted into a 20-level Merkle tree that can hold up to a million entries per epoch. Nothing but the commitment ever leaves the write path.

Step 2

Seal a batch. Publish the fingerprint.

Once 100 events accumulate (or a time threshold passes), the epoch manager freezes the current Merkle root. Optionally, the audit system also reads MongoDB's own oplog directly, the real source of truth, and builds a second SHA-256 Merkle tree over every majority-committed entry in that range. That proves nothing was skipped.

Before leaving the machine, the sealed batch is encrypted with age (XChaCha20-Poly1305, X25519 multi-recipient envelopes) so only the operator and authorized auditors can read it. The ciphertext, never the plaintext, is what gets pinned to IPFS (or via Pinata in dev mode) for decentralized storage.

Alongside the global root, the epoch also computes a super-root over every per-domain root in the batch (see audit domains below). The 32-byte Merkle root, the oplog completeness root, and the domain super-root are all committed to a Soroban smart contract on the Stellar blockchain. That's the entire on-chain footprint: three hashes, an epoch number, and a content identifier — never the raw data.

Step 3

Segment the log. Disclose one tenant, not everyone.

Beyond the single global Merkle tree, events are segmented into domains — each the pair (deployment, database), for example rs:rs0 · sales. Every domain gets its own secondary Merkle root, computed deterministically from that domain's leaves in the tamper-verified global log, so you can prove one tenant's record exists without revealing anything about any other domain.

A second aggregation tree is built over every domain root in the batch, one leaf per domain. Its super-rootcommits to the entire set of domains and is written straight into the epoch's on-chain commit metadata — no contract redeploy required. A short authentication path proves a given domain was part of the committed state, the same way a leaf proves its place in any Merkle tree.

A domain can be placed under legal hold, blocking pruning until it's lifted, or logically pruned for retention: its live event metadata drops out of view, but a compact retained commitment — root, count, last index, timestamp — keeps it verifiable and still folded into the super-root. The append-only global tree and on-chain anchor are never touched, so anchored history always stays complete. Integrity and inclusion are guaranteed per domain today; completeness (no writes omitted) remains a global guarantee via the oplog protocol below.

Step 4

Disclose a claim. Reveal nothing else.

For any event, NoSQLBuddy can generate an Audited-Action Disclosure proof — a Groth16 zero-knowledge proof (via a Circom circuit compiled with ark-circom and ark-groth16) that opens the leaf's keyed Poseidon commitment in-circuit and proves predicates over its still-private fields: a claimed operation, collection, and time range. Everything else about the event — the document, the database, the exact timestamp, any sibling record — stays private.

Anyone, including someone with no access to your database, can call verify_disclosure on the Soroban contract and get back a yes or no, backed by a BN254 pairing check over Stellar's native host functions. Verification is permissionless and runs as a free, read-only simulation — no funded account, no fee, nothing submitted to the ledger. Calling verify_and_record_disclosure instead appends an on-chain, verifier-attributed record — who checked which claim, and when — turning a one-off verification into citable evidence.

Reader mode compares the local audit log against the roots actually committed on-chain to catch tampering after the fact. And because a single publisher could in theory omit writes, independent attesters on separate replica members recompute the oplog hash themselves and submit signed attestations. The contract only accepts a batch as complete once a K-of-N threshold of attesters agree — a disclosure proof is existential (it shows a matching event exists), while K-of-N attestation is what makes the log exhaustive.

What you get

Four guarantees, backed by math, not policy.

Dev mode runs the full stack locally via Docker on Stellar testnet. Production mode signs natively with your own keypair, stored in your OS keychain, on testnet or mainnet.