ZK Email Recovery: How Zero-Knowledge Proofs Restore Lost Crypto Wallets

ZK email recovery is a decentralized account recovery protocol that verifies DomainKeys Identified Mail (DKIM) signatures inside zero-knowledge proofs (zk-SNARKs). It allows users to recover protected wallet assets using standard email authentication without revealing their email address, message body, or private metadata on-chain, and without trusting centralized custodians.

1. The Operational Failure of Seed Phrases in Self-Custody

Self-custody eliminates counterparty risk from centralized exchanges, but it concentrates operational risk onto the user. If recovery credentials are lost, funds become permanently inaccessible.

According to Chainalysis, between 18% and 20% of all Bitcoin (more than $140 billion) sits permanently stranded in lost addresses. Across Ethereum, Stellar, Solana, and layer-2 networks, tens of billions in tokens and stablecoins remain locked for the same reason. These losses rarely involve protocol exploits or compromised private keys. Most occur because users lose written seed sheets, suffer hardware failures, or forget passphrase combinations.

Existing recovery approaches force painful tradeoffs:

• Centralized exchanges: Simple password resets, but the platform holds custody and can freeze withdrawals or become insolvent.
• Seed phrases: Complete user ownership, but single-point-of-failure vulnerability with zero safety net.
• Social recovery: Relies on designated friends or family who often lose their own keys, rotate devices, or lose contact.
• Cloud backups: Ties wallet recovery to centralized cloud providers, exposing keys to account suspensions, SIM swaps, and server-side leaks.

SwiftEx is developing ZK Email Recovery to eliminate this tradeoff. By pairing standard email authentication with zero-knowledge proofs and smart accounts, users can recover lost wallets without paper phrases and without custodial intermediaries.

2. How ZK Email Recovery Operates

Email is the most battle-tested identity rail on the web, used by over four billion people and secured by hardware keys, passkeys, and multi-factor authentication.

ZK Email Recovery uses this existing identity layer as a decentralized recovery trigger. The protocol verifies that a legitimate recovery authorization was delivered to a user's inbox without publishing personal identifying information (PII) to a public blockchain.

The architecture rests on three mechanisms:

1. DKIM as a cryptographic witness: Standard digital signatures applied by email servers prove message authenticity without proprietary servers or oracles.
2. Zero-knowledge privacy: A zk-SNARK proves the DKIM signature is valid and matches the on-chain email commitment, while keeping the sender address, email body, and private metadata shielded from public ledgers.
3. Smart Contract Asset Sweep: The recovery contract does not restore or transmit a lost private key. Instead, upon valid zero-knowledge verification, the smart contract executes an authorized asset sweep, transferring 100% of protected balances into a freshly generated destination wallet under your control.

3. Email Authentication via DKIM Signatures

Email-based wallet recovery relies on DomainKeys Identified Mail (DKIM, RFC 6376), the core security standard used across the web to prevent address spoofing.

When a major mail provider (such as Google Workspace, Microsoft Outlook, ProtonMail, or Apple iCloud) dispatches an email:

1. The mail server calculates a SHA-256 hash of the email headers and body.
2. The server signs this hash using its private RSA key (typically RSA-2048).
3. The server inserts the cryptographic signature into the email header as DKIM-Signature.
4. The sending domain publishes its RSA public key in public DNS TXT records.
5. Any receiving server fetches the public key from DNS to verify that the email originated from that domain and arrived unaltered.

Verifying DKIM directly on a public blockchain is impractical for three reasons:

• Privacy leaks: Submitting raw email headers exposes the user's email address, subject line, and timestamps on an immutable public ledger.
• Address linking: Publishing email metadata permanently links real-world identities to public wallet balances and DeFi transactions.
• Computational expense: Parsing MIME strings and computing 2048-bit RSA modular exponentiations directly in smart contracts requires prohibitive gas fees.

Zero-knowledge circuits resolve all three constraints.

4. Circuit Constraints, Arithmetic Limits, and Privacy Guarantees

In ZK Email Recovery, an arithmetic circuit verifies email validity off-chain and produces a concise cryptographic proof (under 300 bytes) that can be verified cheaply on-chain.

Building zero-knowledge circuits for standard internet protocols presents significant engineering hurdles. Because web standards were not designed for zero-knowledge arithmetic, proving DKIM signatures requires specialized constraint systems:

• Big-Integer RSA-2048 Verification: Standard pairing-friendly elliptic curves such as BN254 operate over a 254-bit scalar field. Verifying an RSA-2048 signature requires computing modular exponentiation on 2048-bit integers. The circuit splits the 2048-bit modulus into 17 distinct limbs of 121 bits each, performing non-native multiplication and reduction constraints across approximately 140,000 arithmetic gates.
• SHA-256 Preimage and Block Hashing: The email header includes bh=, the SHA-256 hash of the canonicalized body. The circuit processes 512-bit message blocks to compute the SHA-256 compression function, mathematically confirming that the body text was not altered after the mail provider signed the message.
• Regex String Matching via Deterministic Finite Automata (DFA): To extract the 56-character Stellar destination address from the email subject line without exposing surrounding message metadata or private user details, the circuit compiles a regular expression into a DFA state machine. The extracted destination bytes are packed into public field inputs (payout_0, payout_1, payout_2), while the sender email identity, message body, and personal metadata remain shielded as private witness inputs.

Prover Infrastructure vs. On-Chain Verifier

• The prover service: SwiftEx routes proof generation to a dedicated prover service (/api/v1/recovery) that ingests the raw signed MIME payload, executes the 140,000-gate circuit, and outputs the Groth16 proof with public inputs. Client-side browser WebAssembly (WASM) proving remains on the technical roadmap as browser compilers for large arithmetic constraint systems mature.
• The on-chain verifier: A lightweight Soroban smart contract on Stellar (SpareKey) that validates the Groth16 proof, DKIM public key hash, nullifier, and payout destination address in milliseconds.

Data Visibility and Privacy Separation

• Private and shielded (processed locally and off-chain):
  • Sender email address: Checked against an on-chain Poseidon hash commitment without exposing the plain-text address.
  • Email body and private headers: Kept off-chain and discarded during proof generation.
  • IP and routing headers: Stripped during MIME processing.
• Public on-chain signals:
  • Sender domain: Verified against the public DKIM DNS registry (such as google.com).
  • Destination payout address: Packed as public signals (payout_0, payout_1, payout_2) directly into the Soroban smart contract.
  • Nullifier: Cryptographic hash recorded on-chain to prevent proof replay.
  • Salt and commitment: Mathematical roots ensuring the proof matches the original registration.

5. Non-Custodial Vault Recovery: Why Balances Are Swept, Never Transmitted

A frequent misconception is that email recovery sends the user's seed phrase or private key to their inbox.

Sending private keys or seed phrases over SMTP or IMAP is fundamentally insecure:

• Any inbox compromise or malicious extension would immediately expose the private key.
• Mail servers and network relays log transit data, creating permanent vulnerability.
• Phishing attacks could trick users into forwarding plaintext credentials.

SwiftEx uses an autonomous on-chain smart contract sweep instead of key transmission or custodian storage:

1. Setup: When enabling email protection, the user's connected wallet establishes pre-authorized allowances on the SpareKey Soroban smart contract for selected tokens (such as XLM and USDC). The user's recovery email is hashed with a secret salt into an on-chain Poseidon commitment.
2. Fresh Keypair Generation: When initiating recovery from any new browser or device, the user generates a brand-new, independent Stellar wallet address (G...).
3. Cryptographic Authorization: The recovery email securely proves inbox ownership and passes the new destination address in the email subject.
4. On-Chain Execution: Once the ZK proof is verified and the safety delay elapses, the smart contract sweeps 100% of protected balances into the new wallet address. The abandoned wallet is drained of protected assets, ensuring the user regains complete control without exposing prior credentials.

6. The 5-Step Recovery Flow: Technical Execution Architecture

The complete recovery process takes five discrete operational steps:

1. Recovery Initiation and Destination Selection: The user opens the SwiftEx Recovery portal on a new device and specifies their lost Stellar wallet address. They generate or connect a brand-new Stellar wallet (G...) that will serve as the recipient destination.
2. Subject-Bound Authentication Email: The user dispatches a recovery email from their registered email provider. The email's subject line contains the new 56-character Stellar destination address. The sending mail server automatically signs the headers and subject with its RSA private key (DKIM).
3. Zero-Knowledge Proof Generation: The raw signed email (.eml MIME file) is processed through the ZK prover. The circuit validates the DKIM RSA-2048 signature, matches the Poseidon email commitment, extracts the destination address from the subject, and outputs a succinct Groth16 proof (< 300 bytes) along with public inputs (pubkey_hash, commitment, payout chunks, nullifier, and salt).
4. On-Chain Submission: The proof and public signals are submitted to the SpareKey Soroban contract on Stellar. The contract validates the Groth16 proof against the on-chain verifier, verifies the DKIM public key, and sets an on-chain pending recovery record.
5. Mandatory Safety Timelock and Sweep Execution: The recovery enters an on-chain 7-day safety delay. If the original wallet holder does not cancel the request, anyone can trigger execute_recovery once the timelock expires, safely transferring all protected asset balances into the new destination wallet.

. Threat Model and Security Safeguards

A production recovery system must defend against compromised inboxes, network eavesdropping, and mail provider updates.

1. Compromised Email Inboxes

• Vector: An attacker gains access to the user's email account and attempts an unauthorized wallet recovery.
• Mitigation: SwiftEx enforces a mandatory 7-day on-chain timelock. During this window, the legitimate wallet owner can cancel the recovery attempt at any time using their existing active key (cancel_recovery). Multi-guardian multi-email thresholds are on the technical roadmap for high-net-worth accounts.

2. Replay Attacks

• Vector: An attacker intercepts an old recovery email and attempts to replay it to hijack the wallet.
• Mitigation: Every recovery proof computes an on-chain nullifier derived from the DKIM signature and salt: hash(DKIM_signature, account_address). Once processed, the contract marks the nullifier as spent. Future attempts using the same email signature revert automatically.

3. Phishing and Parameter Tampering

• Vector: A malicious actor intercepts a recovery email or tricks the user into signing an authorization.
• Mitigation: Recovery emails contain no secrets. Every challenge nonce is cryptographically bound to the target wallet address and the newly generated public key. An authorization cannot be redirected to a different wallet.

4. Mail Provider DKIM Key Rollovers

• Vector: Email providers rotate their RSA signing keys in DNS, breaking verification for valid emails.
• Mitigation: SwiftEx uses a decentralized DKIM key registry smart contract that archives active and historical RSA public keys alongside cryptographic DNSSEC proofs.

5. Subdomain Spoofing and Selector Pinning

• Vector: An attacker sets up a malicious mail server on a lookalike domain or unauthorized subdomain to generate fake DKIM signatures.
• Mitigation: The on-chain DKIM registry enforces strict selector pinning (e.g., 20230601._domainkey.google.com). Proofs generated from unindexed selectors or unverified subdomains fail validation at the smart contract level.

6. Relayer and Spam Protection

• Vector: Automated bots submit malformed proofs to deplete user balances or flood on-chain verifier contracts.
• Mitigation: The Soroban verifier contract checks nullifiers and commitment hashes atomically before state execution. In addition, transactions are throttled through rate-limited relayer endpoints and standard network reserve fees (0.001 XLM), preventing denial-of-service spam.

8. Comparing Wallet Recovery Methods

• Centralized Exchanges (CEX): Custodial model. Offers simple password resets, but users surrender private keys, undergo KYC identity verification, and face platform insolvency or withdrawal freeze risks.
• Paper Seed Phrases: Self-custodial model. Maintains complete user sovereignty and on-chain privacy, but concentrates total risk on a physical paper sheet with zero safety net if lost or destroyed.
• Social Recovery (Guardians): Self-custodial model. Distributes recovery authority across trusted contacts, but introduces social coordination friction, risks guardian key loss or collusion, and requires managing three or more independent parties.
• Cloud Backups: Hybrid or custodial model. Synchronizes across devices, but ties wallet security to centralized cloud accounts, leaving assets vulnerable to SIM swaps, server-side data leaks, and account suspensions.
• SwiftEx ZK Email Recovery: 100% self-custodial model. Restores protected balances through standard inbox authentication without exposing personal identity or private keys on-chain, defended by a mandatory 7-day on-chain timelock, spent nullifiers, and direct wallet cancellation.

9. Development Roadmap

ZK Email Recovery is currently under active development:

• Circuit optimization: Profiling arithmetic circuits for DKIM parsing, SHA-256 compression, and RSA signature verification to reduce proving times to under 15 seconds on mobile browsers.
• Multi-chain smart contracts: Deploying on-chain verifiers for Soroban on Stellar and modular ERC-7579 / ERC-4337 smart accounts on EVM networks.
• Formal verification and audits: Scheduling third-party security audits covering circuit constraints, timelock logic, and nullifier management.
• Testnet deployment: Launching public testnet trials with test assets prior to mainnet release.

10. Frequently Asked Questions (FAQ)

How does ZK email recovery keep my email address private?

The recovery email is verified by a zero-knowledge circuit against the email's cryptographic DKIM signature and an on-chain Poseidon hash commitment without exposing the plain-text address. Only the mathematical proof, nullifier, and public signals (including destination payout chunks) are submitted to the Soroban contract. The sender address, email body, and private headers remain off-chain and shielded.

What happens if an attacker hacks my email inbox?

Even if an attacker breaches your email and submits a valid recovery proof, they cannot immediately drain your assets. SwiftEx enforces a mandatory 7-day on-chain timelock delay. You have full visibility and 7 complete days to cancel the recovery request directly from your wallet (cancel_recovery) before any funds can be moved. Multi-guardian multi-email thresholds are on the technical roadmap for high-net-worth accounts.

Does SwiftEx hold master keys or custody of my funds?

No. SwiftEx is non-custodial. SwiftEx has no master keys, admin backdoors, or access to your assets. The recovery contract executes autonomously on Stellar via Soroban smart contracts. Allowances are established directly by the user, and recovery sweeps execute on-chain only after a valid zero-knowledge proof verifies and the mandatory 7-day timelock elapses.

Does ZK email recovery work across different blockchains?

SwiftEx's live production recovery protocol is deployed natively on Stellar using Soroban smart contracts (SpareKey). The ZK circuit architecture is chain-agnostic: modular verifier extensions for EVM networks (ERC-4337 and ERC-7579 on Ethereum, Arbitrum, Base) are currently under development on our multi-chain roadmap.

How does ZK email recovery compare to WebAuthn Passkeys?

Passkeys are engineered for everyday transactional signing, using biometric authenticators (Touch ID, Face ID, Windows Hello) to sign operations without exposing seed phrases. However, if a user loses all synchronized biometric devices, passkeys cannot be restored without an alternative recovery mechanism. ZK email recovery serves as the decentralized disaster-recovery fallback, restoring account authority when all local hardware credentials are lost.

Can I recover my wallet from a completely new device or browser?

Yes. Recovery does not depend on access to your old hardware. You navigate to the SwiftEx recovery portal on any modern browser, generate or connect a brand-new Stellar wallet (G...), dispatch the authentication email with the destination address in the subject, and process the proof via the ZK prover. Once the on-chain 7-day timelock elapses, anyone can trigger execute_recovery to safely transfer 100% of your protected token balances into your new destination wallet.

Key Takeaways

• The seed phrase dilemma: Over $140 billion in crypto is permanently inaccessible due to lost seed phrases and hardware failures.
• Zero-knowledge DKIM verification: Uses existing email infrastructure as a decentralized identity witness without leaking personal data.
• Complete on-chain privacy: Email addresses, message bodies, and routing headers remain off-chain and shielded.
• Asset sweep, not key transmission: Sweeps 100% of protected balances into a fresh destination wallet via Soroban smart contracts; private keys are never transmitted over email.
• Multi-layered defense: 7-day on-chain timelocks, cryptographic nullifiers, and active wallet cancellation prevent unauthorized takeovers.
• Fully non-custodial: Managed by autonomous SpareKey smart contracts on Stellar, with modular EVM support on the roadmap.

About SwiftEx

SwiftEx is a non-custodial trading platform and wallet ecosystem engineered for cross-chain trading and decentralized asset security:

• Non-Custodial Decentralized Exchange: Intent-based solver routing and native Stellar SDEX integration for transparent swaps with front-running protection.
• SwiftEx Wallet: Self-custodial smart wallet eliminating seed phrase vulnerabilities through biometric Passkey authentication, clear-signing previews, and ZK email recovery.
• Bridge-Less Cross-Chain Swaps: Direct trading across Stellar, Ethereum, Solana, and layer-2 networks without wrapped token bridge vaults.
• Real-World Assets: Access to tokenized US Treasuries, yield instruments, and cross-border stablecoin rails.

Official SwiftEx Links

• Official Website: swiftexchange.io
• SwiftEx Wallet: swiftexwallet.com
• SwiftEx Trading App: app.swiftexchange.io
• Official X / Twitter: @swiftex_wallet
• Official Blog: swiftexchange.io/blog

Primary External Sources

• ZK Email Protocol Documentation: zk.email
• Privacy and Scaling Explorations Research: pse.dev
• DomainKeys Identified Mail Specification (RFC 6376): datatracker.ietf.org/doc/html/rfc6376
• ERC-4337 Account Abstraction Standard: eips.ethereum.org/EIPS/eip-4337
• ERC-7579 Modular Smart Accounts Specification: erc7579.com
• Stellar Soroban Smart Contract Documentation: developers.stellar.org
• Chainalysis Cryptocurrency Forensic Research: chainalysis.com