Why Non-Interactive ZK Is the Right Backbone (and How It Works in Practice)
TL;DR: We use non-interactive ZK so sites get a private YES/NO - no issuer call-backs, no cross-site linkability.
Missed Part I?
Read: Part I - The Web After Bots and AI: How We Keep It Human - Without Surveillance
If a website only needs to know whether a visitor is 18+, in a given country, or one human behind a pseudonym, why should it see that person’s name, address, or a trail of where they’ve been?
The right answer is: it shouldn’t. That’s the promise of zero-knowledge proofs (ZK) - a way for a user’s wallet to prove a fact is true while revealing nothing else. The site receives a cryptographic yes/no, the user keeps their identity to themselves, and the issuer who created the credential isn’t pinged in the background every time it’s used.
This is the cryptographic foundation beneath the “verify the attribute, not the person” pattern we introduced in the main article. Today we’ll go deeper: what kinds of ZK exist, why non-interactive proofs are the right fit for the web, what actually prevents “phone-home” and cross-site linkability, and how all of this shows up in real products like AesirX CMP with Concordium ID.
A quick mental model: what ZK actually buys you
Think of verification as a question with a single, narrow answer. A site asks, “Is this user over 18?” A wallet replies with a proof – not with a document – and the site verifies that proof locally. If the proof checks out, the site learns only that the statement is true. It does not learn the user’s name, date of birth, credential number, or where that credential came from. Properly designed, the proof also doesn’t tip off the issuer that it was used. That’s the difference between compliance theater (“send me your ID”) and privacy engineering (“prove the exact property I need, nothing more”).
Interactive vs. non-interactive ZK: the distinction that changes everything
There are two broad ways to deliver these proofs:
- Interactive proofs involve a back-and-forth with the verifier – a kind of cryptographic Q&A. They’re useful in some protocols but imply a live session between the parties.
- Non-interactive proofs (often abbreviated NIZK) are a single, self-contained message that the verifier can check on its own. No conversational round-trips are required.
For web-scale verification (especially on mobile), non-interactive proofs are the better fit. They make the experience fast and resilient: a site (or an edge worker/CDN) can verify a proof without contacting anyone else. This is the practical root of no phone-home. If verification doesn’t require a callback to the issuer, there’s no covert telemetry trail each time a user proves something about themselves.
This is exactly the model we implement: Concordium ID issues credentials the user holds in a wallet; AesirX CMP requests non-interactive proofs of specific attributes; and the site verifies those proofs locally. The outcome is a binary verdict the application can act on, plus a timestamp for auditability without harvesting identity or notifying the issuer.
“No phone-home” and unlinkability are architectural, not just cryptographic
It’s tempting to believe ZK alone guarantees privacy. In reality, the whole design must cooperate:
- Verification happens locally. The verifier checks a proof against public parameters; no hidden calls are made to the issuer during verification. If you must refresh revocation or status, you fetch anonymous status lists or accumulators on a schedule – not per user.
- Proofs are pairwise and context-scoped. A well-designed wallet generates proofs that are unique to each site or relying party. Even if two sites collude, they can’t correlate the same person across properties simply by comparing proofs.
- Everything runs first-party. Consent and verification sit on your own domain, not behind third-party scripts or pixels. Users, auditors, and regulators can see what’s happening, and there’s no silent data exhaust.
With those rules in place, non-interactive ZK becomes the engine of private outcomes: fast checks, no issuer beacons, and unlinkability by construction.
If you’re wondering what this looks like in a production stack, here’s how Concordium implements the private YES/NO we’ve been talking about.
How Concordium’s ZK Works (and why it fits a private, human-only web)
Concordium’s identity layer is built so that a site can ask a narrow question - “13+?”, “18+?”, “resident in Denmark?” - and receive a cryptographic YES/NO without seeing the credential itself and without quietly pinging the issuer. The wallet holds the credential; the site receives a non-interactive zero-knowledge proof (NIZK) that can be verified locally. That “non-interactive” part is what enables no phone-home and fast, cacheable flows at web scale.
In practice, Concordium supports two proof patterns you’ll actually use in products:
- Range proofs for things like age (e.g., “date of birth implies ≥ 13” or “≥ 18”).
- Membership / non-membership proofs for policy checks (e.g., “country ∈ {DK, SE, NO, FI, IS}” or “not on a restricted list”).
Under the hood, these are constructed from well-known building blocks – commitments (e.g., Pedersen commitments) and sigma-protocol style proofs – with Bulletproofs used for efficient range and set proofs. The whole thing is made non-interactive via the Fiat–Shamir transform, so the verifier doesn’t need a live back-and-forth to check the proof. Result: quick verifies on the server or at the edge, and no issuer telemetry at proof time.
What the flow looks like: your backend states the question and challenge; the dApp asks the wallet; the wallet returns a presentation that contains the proof; your backend verifies it and applies your policy. The credential never leaves the wallet. What you log is a verdict with a timestamp – useful for audits and rate-limits, useless for profiling.
Why this preserves privacy in practice: verification is local (no callbacks to issuers), proofs are pairwise and context-scoped (unlinkable across relying parties), and revocation is handled via privacy-preserving status lists/accumulators fetched generically rather than per-user lookups. You get up-to-date checks without turning verification into a locator beacon.
Finally, Concordium couples privacy with due-process accountability. Day-to-day use is pseudonymous and private; in cases of credible fraud or harm, identity disclosure is possible only through a lawful, narrowly governed procedure. That governance lives beside the mathematics and keeps the system legitimate for communities, platforms, and policymakers.
“Concordium’s NIZK stack proves the fact, not the person - local verification, no phone-home, unlinkable by design - and backs it with a lawful path to accountability.”
With Concordium’s practical pattern in mind, let’s zoom back out to the broader toolkit – SNARKs, STARKs, and selective-disclosure schemes – and how to choose what fits your UX and governance.
SNARKs, STARKs, and selective disclosure: choosing a flavor without the hype
Once you choose the non-interactive route, you’ll encounter a zoo of acronyms. Here’s how to think about them without getting lost.
zk-SNARKs produce very small proofs that verify quickly – great for phones and for running verification at the edge. Many SNARK systems use a “trusted setup” or a universal setup, which needs to be handled with care: who ran it, how keys were managed, and how you rotate if needed. In return, you get tiny proofs and snappy UX.
zk-STARKs avoid trusted setup entirely and rely on transparent, hash-based assumptions that are often cited as stronger against prospective quantum attacks (with larger proofs as the trade-off). The trade-off is larger proofs and more bandwidth. For some applications, that’s perfectly acceptable; for others (low-end mobile on bad networks), you’ll want to measure carefully.
There are also selective-disclosure schemes such as BBS+ signatures and Bulletproofs. These are especially good when your credential contains many fields, but the site only needs to see that one property holds, say, “age ≥ 18” or “country = DK.” They typically sit between SNARKs and STARKs in proof size and performance. Many real systems combine these approaches: credentials that support selective disclosure, paired with a SNARK/STARK-style proof system where it makes sense.
The point isn’t to join a cryptography tribe; it’s to choose the tool that meets your UX and governance constraints. On the UX side, measure proof generation time on a mid-range Android phone, bandwidth on a bad connection, and verification latency at the edge. On the governance side, decide whether you prefer transparent, setup-free systems or whether a well-run universal setup is acceptable for the gains you get in proof size and speed. The technology lets you fine-tune those dials; your product and regulatory context decide where to set them.
In short: pick the scheme your users’ phones can handle, and the governance your risk team can defend.
Revocation without surveillance: the quiet make-or-break
A common pitfall in otherwise private designs is revocation – the need to invalidate a credential that’s expired or has been withdrawn. If the verifier has to ask the issuer, “Is this user still valid?” you’ve rebuilt a tracking system. The privacy-preserving pattern is to distribute status lists or cryptographic accumulators that can be fetched anonymously and cached. Verifiers learn the current status in general, not the status of a specific person, and users aren’t located at the moment of verification. Combined with short proof validity windows, you get up-to-date checks without pinging anyone about a specific user at a specific time.
How it feels in a real product
Imagine a teen joining a study forum that’s strictly 13+. The forum prompts, “Prove 13+.” The wallet constructs a non-interactive proof from a credential the teen already holds. The forum verifies the proof instantly – no calls to the issuer – and admits the user under a pseudonym. The forum logs only that a valid “13+” proof was presented at a particular time. No name. No school. No dossier. If someone later causes real harm, there is a separate, court-supervised process to unmask the pseudonym; that’s governance, not the default behavior.
Now transpose that flow onto marketplaces, messaging surfaces, and payment triggers. You gate the riskiest actions – new listings, bulk DMs, payouts – behind attribute proofs. You keep regular participation effortless. Spam and scams fall, moderator load declines, and you never built a surveillance stack to get there.
This is precisely how AesirX CMP integrates with Concordium ID. We request the narrow proof the context requires (age, country, or “one human”), verify it locally, and store a verdict – not an identity. Because the proofs are non-interactive and context-scoped, neither the issuer nor other sites learn anything from their use.
Local verify, issuer-silent, pairwise-unlinkable - by design.
Accountability that respects rights
Privacy by default does not mean abuser-proof. The architecture keeps users pseudonymous day-to-day, but if there’s credible evidence of fraud, harassment, or predatory behavior, a lawful, narrowly defined process exists to unmask the real-world identity behind a pseudonym. That unmasking is gated by due process – court supervision – not by moderator discretion or corporate backdoors. It’s the balance that convinces policymakers and communities to support privacy-preserving verification: power for good actors, consequences for bad ones.
What to test when you pilot
When you run your first pilot, measure the things that matter in practice rather than debating cryptography in the abstract. Watch proof generation time on mid-tier phones; watch verification latency at the edge; watch bandwidth impact the first time versus subsequent, cached visits. Track the operational deltas after you gate a surface: spam attempts, fake accounts, chargebacks, and moderator hours. If those numbers improve without collecting identity, you’ve proven the model in your environment.
Why we chose non-interactive ZK for AesirX CMP + Concordium ID
Our use cases – age, country, and “one human” checks at web scale – demand proofs that are fast, cacheable, and verifiable without contacting the issuer. That’s what non-interactive ZK delivers. We combine it with pairwise pseudonyms for unlinkability, status-list-based revocation for privacy, and first-party execution so consent and verification never leak to third parties. The result is simple: sites get a yes/no answer and an audit timestamp; users keep their privacy; issuers aren’t silently notified when credentials are used.
Most importantly, the pattern is deployable today. If you operate a community or a marketplace, start with one high-abuse surface – sign-ups, DMs, listings, or payments – gate it with attribute proofs, and store verdicts rather than identities. Expand after you see the drop in spam and fraud. You’ll reclaim your product from bots and bad actors without turning your users into data points.
Private by Default, Accountable by Due Process
Zero-knowledge proofs are the mathematics that let you prove a fact without exposing a person. Non-interactive proofs make that promise practical for the web: fast, private, and verifiable without phone-home. But the maths isn’t the whole story. Privacy comes from the complete design – pairwise, context-scoped proofs; revocation that doesn’t track; first-party execution; and a clear, narrow path for due-process unmasking when things go wrong.
That is the architecture we’ve chosen with AesirX CMP and Concordium ID. It’s how you keep communities safe, markets honest, and youth spaces truly youth-only, and keep the web human, even as automated traffic rises.
Ready to pilot? Gate one surface this week with AesirX CMP v2.0.0. You’ll feel the difference fast, and you won’t have to compromise on privacy to get there.
Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO, AesirX.io
