In recent work from Mysten Labs, the team behind the Sui blockchain, Kostas Chalkias and collaborators introduced a new authentication primitive: the Zero-Knowledge Authenticator (zkAt). This mechanism aims to address a problem that remains unaddressed in most public blockchains, including Sui itself: how to authenticate transactions without revealing the authentication policy to the entire network.

In Sui and similar smart contract platforms, verification logic is public. This transparency benefits auditability but comes with trade-offs, particularly when authentication rules themselves are sensitive. For example, revealing that an account only needs 2 of 3 keys to approve a transaction tells an attacker exactly how many keys to target. zkAt proposes to preserve verification correctness while removing this leakage.

Q1: What is zkAt?

zkAt is a cryptographic construction that allows a user to prove to the blockchain that a transaction satisfies a specific authentication policy without revealing the policy itself. The policies can be arbitrarily complex—anything that can be represented as an NP statement. Unlike threshold signatures, zkAt can handle mixed signature schemes, conditional logic based on transaction data, or contextual rules (e.g., more signers required for large amounts).

The central technical ingredient is a form of designated-prover NIZK proof system with a property called verification key equivocation, which ensures that the verifier’s public key contains no information about the underlying relation (the policy).

Q2: Why does policy privacy matter?

In current practice, policy disclosure can serve as a blueprint for targeted compromise. Threshold multi-signature schemes reveal the exact access structure (n, t), while account abstraction wallets on Ethereum, Sui, or Solana openly publish policy logic in smart contracts. This transparency allows adversaries to optimise their attack strategies.

zkAt eliminates that visibility. The verifier—whether a blockchain node or a smart contract—only learns that the submitted proof is valid for the hidden policy. It does not learn whether that policy is a fixed threshold, time-based rotation, or a combination of different signature schemes.

Q3: How is zkAt different from existing authenticators?

Threshold signature systems hide some information, but only within a predefined anonymity set (e.g., “some t-out-of-n policy”). Smart-contract wallets support rich policies but offer no privacy. Traditional zero-knowledge proofs can hide inputs to a policy but not the policy structure itself.

zkAt, by contrast, achieves both: general policy expressiveness and full policy privacy. The verification key and proof reveal nothing about the policy, and the proof size is constant regardless of policy complexity.

Q4: How does it work?

The key innovation is modifying Groth16 SNARKs so that the verification key becomes independent of the policy circuit. This is done by interpolating new QAP polynomials that evaluate identically to the originals on constraint points but are randomised at the trapdoor evaluation point. The verifier can still use standard Groth16 verification, but the link between key and policy is broken.

The zkAt+ variant extends this further. It uses recursive NIZKs: an inner proof enforces the actual policy, while an outer proof checks both the validity of the inner proof and a signature on the inner CRS. With this structure, the policy issuer can change the policy by generating a new inner CRS and signing it with a persistent update key, without altering the on-chain verification key.

Q5: How does zkAt fit into Sui or other blockchains?

For integration, the blockchain must support on-chain verification of the chosen NIZK scheme. Since Groth16 is already supported in many ecosystems, zkAt can be deployed without altering consensus rules—only the authenticator contract logic changes. Public inputs to the proof must be carefully standardised to avoid indirect policy leakage (e.g., exposing transaction fields that implicitly reveal rules).

Q6: What about performance?

In a proof-of-concept implemented using the gnark library, the authors evaluated a policy that required 1-of-3 signatures for transactions below 1000 units and 2-of-3 otherwise. The zkAt proof took about 51ms to generate and under 1ms to verify. Compared to a 2-of-3 threshold signature, proving time is higher but verification remains fast and independent of policy complexity.

Q7: What kinds of policies become possible?

While zkAt supports generic NP-expressible policies, the paper illustrates cases such as:

• Threshold schemes with hidden parameters (t, n, and signer identities remain secret).
• Conditional thresholds based on transaction fields like amount or timestamp.
• Mixed signature schemes—e.g., one ECDSA key or one EdDSA key suffices.
• Policies relying on Web2-issued credentials, such as JWTs from OpenID providers.

In all cases, neither the access structure nor the credential sources are revealed on-chain.

Conclusion

zkAt and zkAt+ represent an incremental but significant shift in blockchain authentication models. From a purely cryptographic perspective, the novelty lies in the explicit formalisation and realisation of verification key equivocation, and in adapting Groth16 to achieve it without sacrificing verification compatibility. From a systems standpoint, the construction closes a gap between privacy-preserving transactions (which hide amounts or participants) and private authentication policies, a domain that has remained largely exposed in public ledgers.

However, adoption hinges on two practical considerations. First, blockchains must support the relevant NIZK verifiers natively or via precompiles—this limits deployment to ecosystems already optimised for succinct proof verification. Second, operational trust assumptions, especially around the trapdoor in Groth16 and the update key in zkAt+, must be acceptable to stakeholders. In single-user or organisational custody scenarios, this may be straightforward; in open, multi-party contexts, secure multi-party setup protocols or trusted execution environments may be required.

If integrated carefully into platforms like Sui, zkAt could unify the flexibility of account abstraction with the privacy guarantees of modern ZK systems, reducing the attack surface associated with public policy disclosure. The challenge will not be in proving that it works—it already does—but in convincing infrastructure providers and application developers that hiding the rules is as valuable as hiding the data.