Where Zero-Knowledge Is Actually Used: zkLogin, Coprocessors and ID Checks

2026-08-12

Zero-knowledge systems are easiest to understand when each proof is tied to a specific claim. A proof can hide a credential field, certify an off-chain computation, or show that an identity rule was satisfied without publishing the underlying document. It does not make every component trustless, and it does not turn a login into a universal identity. This article, checked against the cited documentation on August 10, 2026, follows the boundary from a ZK proof to zkLogin, ZK coprocessors and identity checks.

What a zero-knowledge proof actually hides

A zero-knowledge proof is a way for a prover to convince a verifier that a statement is true while keeping selected witness data private. The statement might be that a signed token contains a particular relationship, that a program produced a claimed output, or that a credential satisfies a rule. The proof is not the statement itself. It is evidence that a specified relation between public inputs and private inputs was satisfied by a specified circuit or program.

That distinction matters because privacy is selective. A verifier may learn a Boolean result, a public commitment, a network identifier, a program identifier or a timestamp while not learning the private input. A proof of an age threshold can hide a birth date, but it does not by itself prove who issued the underlying credential, whether the issuer is legitimate, or whether the verifier used the right policy.

The practical question is therefore not whether a product uses ZK. Ask what is public, what is private, who produces the witness, which keys or setup parameters are trusted, and who verifies the result. A system can use a sound proof and still depend on an OAuth provider, a salt service, an indexer, a data availability layer, a credential issuer or an application that chooses a weak rule.

How zkLogin binds a web login to an address

Readers searching for zk login explained should start with the identity binding rather than with the word wallet. Sui zkLogin uses an OpenID Connect login to obtain a signed JSON Web Token. The application also creates a short-lived ephemeral key pair. The nonce in the token is constructed from the ephemeral public key, randomness and an expiry epoch, so the later transaction session is tied to the login flow.

Sui documentation describes a salt service and a proving service as separate backend roles. The salt is used with the issuer, application audience and subject claim to derive an address seed that is unlinkable from the OAuth identifier when the salt remains private. The proving service receives the token and relevant inputs and produces a Groth16 proof. The proof checks relationships such as the validity of the provider signature, the nonce construction, the claim value and the address derivation.

The address and the session key have different lifetimes. The address can remain stable while the ephemeral key expires at the configured epoch. A new login can produce a new session key and proof for the same address when the underlying issuer, audience, subject and user salt remain the same. Validators then verify the proof and the ephemeral signature before executing the transaction. This is a protocol-specific flow, not a general claim that every social login creates a self-custodied identity.

The trust boundary is visible in the details. The OAuth provider authenticates the account and signs the token. The application controls the frontend and ephemeral key. The salt service can see sensitive inputs if it is designed to serve them, and the proving service processes the token and proof inputs. Sui notes that these services can link identity and salt in their own view, even though the JWT is not published onchain. The privacy result depends on these assumptions and on protecting the user salt and session key.

What a ZK coprocessor computes

The phrase zk coprocessor explained is best treated as an architecture question. A coprocessor moves a data-heavy or computation-heavy task away from the application chain, then returns a result together with evidence that the task used authenticated inputs and followed the declared computation. In a pure ZK design, a verifier contract can check the proof and consume the result without repeating the whole computation.

ZK proof flow from private input to a verifiable application result

Brevis documentation illustrates the pattern with three stages: data access, application computation and result use. The application requests historical chain data, an off-chain prover runs custom logic, and the result plus proof is submitted for onchain verification. The same shape can support a threshold over historical activity, a membership rule, a reward calculation or a risk flag. The proof does not automatically certify that the data source was appropriate; it certifies the relation that the system actually proved.

This is different from simply asking an indexer for an answer. An unproved indexer response asks the contract or user to trust the party that selected and computed the data. A ZK coprocessor can reduce that trust by tying the result to authenticated chain data and a circuit. The cost is that the circuit, data commitments, proof system, verifier and update process become part of the system that must be reviewed.

The model is also not one fixed product feature. Brevis describes a pure ZK mode and a coChain or optimistic mode with different latency, cost and challenge assumptions. RISC Zero describes verifiable computation more generally as pairing a program output with a receipt that a verifier can check without rerunning the original computation or seeing private inputs. Those descriptions support the concept, but each deployment still needs its own statement, input authentication and failure policy.

Where an ID check stops proving identity

An ID check can be represented as a statement about a credential, not as a magical proof of a person. For example, a verifier may ask whether an issuer signed a credential, whether it is within a validity period, whether a subject is over a threshold age, or whether a document identifier is on a revocation list. A ZK circuit can hide the document fields that are not needed for that statement while exposing the minimum result required by the application.

The phrase zero knowledge identity verification should therefore be unpacked into issuer, holder and verifier roles. W3C Verifiable Credentials describe a credential as claims made by an issuer, held by a subject or holder and presented to a verifier with mechanisms for checking authenticity and integrity. W3C DIDs describe identifiers and verification methods, but neither standard guarantees that a real-world person, organization or document is truthful merely because a DID or credential format is present.

Consider an age check. A proof can show that a signed date of birth is earlier than a policy cutoff without revealing the date. It cannot decide whether the issuer performed a reliable document check, whether the credential was issued to the current holder, whether the policy cutoff is lawful in a particular jurisdiction, or whether the credential has been revoked unless those facts are represented and checked. Those are issuer, binding, policy and lifecycle questions.

The same boundary applies to sanctions, residency, accreditation and account uniqueness. A circuit can encode a predicate such as issuer equals an approved set and claim satisfies a rule. It cannot silently repair a weak issuer registry, a stolen credential, a compromised wallet, a false source record or an incomplete revocation feed. A result of true means that the encoded predicate verified against the supplied inputs, not that every real-world fact behind the inputs is true.

Privacy is a design choice, not a proof output

ZK can reduce disclosure, but privacy depends on the full flow. The verifier may still observe a public address, timing, network, application audience, proof frequency or the fact that a particular policy was attempted. Repeated presentations can be linkable if the application reuses identifiers or public commitments. Metadata can reveal more than the private witness that the circuit hides.

zkLogin makes this visible through the salt and the OpenID claims. The salt helps unlink the OAuth identifier from the onchain address, but losing it can remove access to the address and exposing it can make the subject claim linkable. The OAuth provider, frontend, salt service, proving service and validators each see different parts of the flow. A privacy review should map those views instead of treating the proof as a single privacy switch.

For coprocessors, privacy also depends on where the raw data and witness are processed. A proof may let an onchain verifier check a result without seeing private inputs, while the off-chain prover or data provider saw them during computation. The application may publish the result, query identifier, block range or commitment. A system that needs confidentiality from the prover may require additional techniques such as private proving, secure execution or encrypted computation, not just a public ZK verifier.

The minimum disclosure principle is useful: prove only the predicate needed by the application, use a purpose-specific audience or domain separator, rotate session material where the protocol expects it, and document retention and correlation risks. These controls do not eliminate trust. They make the remaining trust and disclosure paths reviewable.

What the trust model must name

Start with the statement and its public inputs. Write down exactly what a verifier accepts, which data is committed, how chain state or a credential is authenticated, and what software or circuit version produced the proof. If a result can be consumed by a contract, identify the verifier code, upgrade authority, emergency path and handling of stale data.

Then name the actors. For zkLogin, this includes the OpenID provider, application, ephemeral key holder, salt service, proving service and Sui validators. For a coprocessor, add the data source, indexer or light client, prover, verifier and any challenge or staking mechanism. For an ID check, add the issuer, holder, wallet or presentation layer, verifier and revocation or status service. A diagram with missing actors is a risk signal.

Next separate correctness from availability and recovery. A valid proof may not arrive on time. A provider may rotate keys. A salt service may be unavailable. A credential may expire. A chain reorganization or data finality rule may change the input set. A coprocessor may offer an optimistic path whose security depends on an honest challenge window. These are operational properties, not failures that a mathematical proof silently fixes.

Finally inspect the setup and upgrade assumptions. Sui documents a Groth16 common reference string ceremony for zkLogin. Other systems may use transparent proof systems, a zkVM receipt, a trusted setup, a committee, a staking layer or a combination. Ask who can change the circuit, verifier, issuer registry, provider list, data source or policy. A proof can be perfectly verified against yesterday's policy and still be the wrong answer for today's policy.

How to read a ZK identity claim

When documentation says a feature is private, translate the claim into a table: private from whom, visible to whom, for how long and under what correlation method. When it says trustless, ask which party is removed and which parties remain trusted for inputs, keys, availability, recovery and governance. When it says verifiable, ask which exact computation or credential relation is covered.

Use a five-part review for this article's sequence. First, inspect the proof statement and witness. Second, trace the identity binding from the provider token or credential to the application address or presentation. Third, identify any off-chain computation and its authenticated data source. Fourth, list the issuer, policy, revocation and holder assumptions behind an ID check. Fifth, test privacy leakage through metadata, repeated use and service visibility.

This review keeps three ideas separate. zkLogin can bind a short-lived transaction key to claims from an OpenID flow while hiding selected claim data from the chain. A ZK coprocessor can make an off-chain computation verifiable against declared data. An ID check can prove that a defined credential predicate was satisfied. None of these statements alone proves that the user is honest, that the issuer is trustworthy, that the data is current or that the surrounding services are harmless.

That is where zero knowledge is actually used: in a carefully scoped relation between inputs, computation and verification. The useful output is not a promise of invisible identity. It is a smaller, auditable claim with explicit privacy and trust assumptions. Those assumptions should be recorded with the protocol version, source date and policy so that a later change can be noticed rather than mistaken for a permanent guarantee.

Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of August 2026; refer to the latest official information.