XION's Protocol-Level ZK Verification and On-Chain Email Authentication: A Technical Deep Dive
XION's ZK Module and DKIM Module are live on testnet. Protocol-level proof verification using GNARK. On-chain email authentication keys with permanent historical records. No DNS dependencies. No smart
Every email verification system in crypto has the same dirty secret. They all phone home to DNS.
When a zkEmail proof verifies that you received an email from Gmail, the DKIM public key used for that verification gets fetched from a centralized DNS server controlled by Google. When Google rotates that key and removes the old one (which they do regularly), any proof generated against the old key becomes unverifiable. The key is gone from DNS. No archive. No fallback. If you didn’t verify before the rotation, you’re out of luck.
Every chain dealing with DKIM faces key rotation. That’s unavoidable since email providers control their own keys. The question is what happens to the old ones. On DNS, they disappear. On XION, they’re preserved permanently on-chain, so historical proofs remain verifiable forever while new keys get added as providers rotate.
Here’s how, and what it means for what you can build.
The Architecture
XION shipped two protocol-level modules that work as a single verification stack: the ZK Module and the DKIM Module. Both live in the chain’s core state machine as native SDK modules, not smart contracts.
This distinction matters. Verification logic executes as compiled protocol code, not interpreted bytecode running inside a VM. The performance and cost implications of that difference are significant, and we’ll get into the numbers. But first, the design.
ZK Module
The ZK Module is a general-purpose zero-knowledge proof verifier embedded at the protocol level. It does one thing well: given a proof, public inputs, and a verification key (VKey), it tells you whether the proof is valid.
Right now it supports Groth16, the most battle-tested and widely deployed proof system in production. Barretenberg is actively in development, with Halo2 on the roadmap after that. New proof systems get added through governance proposals as they mature.
The module’s state stores verification keys that anyone can upload permissionlessly. Once a VKey is on-chain, any application can reference it to verify proofs against it. The verification flow is straightforward:
A transaction includes a ZK proof and specifies which VKey to use
The protocol retrieves the VKey from chain state
Native verification code executes the proof check
The transaction succeeds or fails based on the result
State updates only proceed after successful verification
No smart contract calls. No VM overhead. No gas-heavy execution loops. The chain itself is the verifier.
What makes this different from ZK implementations on other chains?
Most chains that support ZK verification do it at the application layer. You deploy a verifier contract, pay execution gas for every verification, and accept the overhead of running cryptographic operations through a virtual machine that wasn’t designed for them. Some L2s bake specific proof systems into consensus, but that’s purpose-built for rollup verification, not general-purpose application use.
XION’s approach is to make proof verification a protocol primitive. Any Groth16 proof (and soon Barretenberg and Halo2) can be verified natively. You upload your VKey permissionlessly, point your transactions at it, and the chain handles the rest. The module is also fully IBC-compatible, which means any Cosmos SDK chain can submit proofs to XION for verification through Inter-Blockchain Communication.
The performance edge comes from a specific technical decision. XION’s protocol-level implementation uses Go’s GNARK library for ZK-SNARK proof verification, which is significantly faster than the Rust-based arkworks library that most smart contract verifiers rely on. The internal benchmarks show roughly 10x efficiency gains over equivalent smart contract verification on the same chain. At consumer scale with millions of verifications, that gap determines whether your application is economically viable or not.
DKIM Module
The DKIM Module is an on-chain registry of email provider public keys, tightly coupled to the ZK Module. You cannot use the DKIM Module without the ZK Module, and that’s by design. The DKIM Module is, in a real sense, the first production use case built on top of XION’s ZK infrastructure.
Here’s the problem it addresses.
DKIM (DomainKeys Identified Mail) is the standard that email providers use to cryptographically sign outgoing emails. When Gmail sends you an email, it signs it with a private key. Anyone can verify that signature using Gmail’s public key, which Gmail publishes via DNS TXT records.
Every zkEmail implementation in existence fetches those public keys from DNS at verification time. This creates three problems:
Key rotation breaks historical proofs. Gmail rotates DKIM keys periodically. When the old key gets removed from DNS, it’s gone. Any proof generated against that key becomes unverifiable because the key needed to check it no longer exists anywhere.
DNS is centralized infrastructure. The entire verification chain depends on ICANN, domain registrars, and the DNS hierarchy. It’s subject to government censorship, registrar policies, and outages. Calling this “trustless” is generous.
No deterministic lookups. DNS resolution involves caching layers, TTLs, propagation delays, and geographic variance. Two nodes querying the same key might get different results depending on timing and location.
XION’s DKIM Module stores provider keys directly in chain state with Poseidon hashing for efficiency. Applications query keys from chain state with deterministic, instant lookups.
An important nuance: key rotation still happens. Email providers control their own keys, and when they rotate, XION needs to add the new keys through a governance proposal so that new emails can be verified. What XION changes is that old keys are preserved permanently on-chain. On DNS, a rotated key vanishes and every proof tied to it becomes uncheckable. On XION, old keys stay in state, so proofs generated against them remain verifiable indefinitely. Old keys verify old emails. New keys verify new emails. Nothing falls through the cracks.
Launching with support for:
Gmail (1.8 billion users)
Apple email/iCloud (2+ billion devices)
That’s roughly 90%+ of global email covered at launch. Additional providers (Outlook, ProtonMail, Fastmail) are under research. Each provider implements DKIM differently, with unique parameters, key rotation schedules, and signature formats, so adding support requires provider-specific validation before keys can safely enter the registry.
Keys are currently added through governance proposals. The roadmap includes transitioning to permissionless key additions once the governance process has been validated and security patterns are well established.
How They Work Together
The relationship between the two modules is hierarchical. The ZK Module is the general-purpose foundation. The DKIM Module is a specific, high-value application built on top of it.
Here’s the complete verification flow for email-based authentication:
User receives an email (for example, a recovery confirmation email)
User replies to confirm (the backend handles circuit execution, proof generation, and submission)
The application submits the ZK proof to XION along with the email provider identifier
The DKIM Module retrieves the provider’s public key from on-chain state
The ZK Module verifies the proof using that key at the protocol level
The transaction succeeds or fails based on cryptographic verification
From the end user’s perspective, they get an email and reply “confirm.” Everything else is abstracted. No downloading .eml files. No pasting Ethereum addresses. No interacting with circuits or proofs. The backend handles proof generation and submission entirely.
This is a deliberate design choice. Unlike some zkEmail implementations that require users to grant inbox access or manually export email files, XION’s approach asks for a single reply to a confirmation email. No broad permissions. No data exposure beyond the specific claim being proved.
What the DKIM Module Actually Proves
Let’s be precise here, because this matters for how you architect applications.
The DKIM Module proves one thing: that you have access to a specific email address. That’s it. It does not parse email contents. It does not extract data fields. It does not prove claims about what’s inside your emails.
This makes it ideal for:
Account and authenticator recovery. If a user loses access to their XION authenticators (passkey, hardware key, whatever they were using), they can use their email to prove identity and add new authenticators. This is the primary use case. Your users never lose access to their accounts as long as they have access to their email. No seed phrases. No centralized recovery service. No support tickets.
Domain-based identity verification. Prove you have a @harvard.edu or @company.com email address without revealing which specific address. Gate access, airdrops, or features based on verified institutional affiliation. Eliminate sybil farming by requiring domain-backed identity.
Email-triggered on-chain transactions. Because the proof verifies email access, it can authorize on-chain actions. This turns email into an authenticator for blockchain transactions.
For use cases that require proving specific claims from email content (bank balances, purchase receipts, booking confirmations), you’re looking at custom ZK circuits built on the ZK Module directly. The DKIM Module’s scope is deliberately narrow because that narrow scope is what makes it reliable and secure as an authentication primitive.
Building on the ZK Module: Beyond DKIM
The ZK Module is the general-purpose tool. If DKIM is the first application built on it, here’s what else becomes possible.
Custom verification circuits. Write a Groth16 circuit that proves any computation, upload the VKey through governance, and any application on XION can verify proofs against it. The team is already building reusable circuits for common patterns (shuffle verification, encryption/decryption) that developers can compose rather than writing from scratch.
Private credential verification. Build circuits that prove attributes (age > 21, salary > threshold, degree from accredited institution) without revealing the underlying data. The ZK Module handles verification natively. You focus on the circuit logic.
On-chain gaming with provable fairness. Card games, random number generation, shuffle verification. Circuits handle the cryptography. The protocol verifies the proofs. Players get provable fairness without trusting a server.
Cross-chain verification via IBC. Any Cosmos SDK chain can submit proofs to XION for verification and receive cryptographic confirmation back through IBC messages. If your application lives on another chain but needs ZK verification, XION serves as shared infrastructure.
Computation verification. Prove that off-chain computations were performed correctly without re-executing them on-chain. Validate AI model outputs, verify data processing pipelines, confirm complex calculations.
The Developer Experience
Both modules follow standard Cosmos SDK module architecture with a keeper pattern. If you’ve built on Cosmos before, the mental model is familiar.
For the ZK Module:
Upload VKeys permissionlessly
Submit proofs in transactions, specifying the target VKey
The module returns verification results at the protocol level
Standard query interfaces for key lookups
For the DKIM Module:
Keys added through governance proposals (transitioning to permissionless)
Applications query keys directly from chain state
Deterministic lookups, no external dependencies
Historical keys preserved permanently
Documentation covers integration guides, code examples in JavaScript, Python, and Rust, proof generation guides, and testing frameworks. Testnet is live with endpoints and faucets available.
If you’re coming from the zkEmail ecosystem, the key difference is that you never touch DNS. Your application queries DKIM keys from chain state with the same reliability and determinism as any other on-chain data read. When providers rotate keys, old keys remain on-chain. Your proofs don’t break.
What’s on the Roadmap
Proof systems: Barretenberg (in active development), Halo2 (next after Barretenberg). Each added through governance as implementations are validated.
Provider coverage: Outlook/Microsoft 365, ProtonMail, Fastmail, and community-requested providers. Each requires provider-specific research and testing before keys can enter the registry safely.
Reusable circuit library: Pre-built, compiled circuits for common patterns that developers can compose into applications without writing circuits from scratch. Shuffle, encryption/decryption, and more coming from the team.
DKIM key governance: Transition from governance-based to permissionless key additions once security patterns are validated through the governance process.
Getting Started
Both modules are live. The fastest path to building:
Read the module documentation for ZK and DKIM integration
Hit the testnet endpoints and faucets
For DKIM-based applications: query existing Gmail/Apple keys from chain state and build authentication flows
For custom ZK applications: write your Groth16 circuit, upload the VKey, and submit proofs
Join the developer Discord for technical support and weekly office hours
If you’ve been building email verification and wrestling with DNS dependencies, this eliminates that problem. If you’ve been building ZK applications and paying smart contract gas for every verification, this changes the economics. If you’ve been looking at consumer-scale verification and wondering how to make it work, the infrastructure is here.
Build something. Break something. Tell us what’s missing.
ABOUT XION
XION is the Trust Layer for the Internet.
It is the only L1 that rebuilds trust between people, brands, and platforms through verification, turning verified data into programmable value. From ad waste to reputation portability, loyalty programs, and private data monetization, XION solves these issues with a cutting-edge zero-knowledge verification infrastructure built atop a complete abstraction layer.
The platform is already leveraged by over 150 brands, including Uber, Amazon, and BMW. The project has raised over $36 million from top-tier investors, including Multicoin, Animoca, Circle, Hashkey, Arrington Capital, Spartan, and more.