Cross-Chain Identity:
Unified Credentials Across Blockchains

You have an Ethereum wallet, a Solana wallet, a Polygon address, and an Arbitrum account. Each one knows you authenticated on its chain. None of them know you are the same person. This is the identity fragmentation problem -- and it is one of the most persistent failures in the multi-chain ecosystem. Bridging tokens across chains is now routine. Bridging identity is an entirely different challenge, one that demands cryptographic primitives most bridge protocols were never designed to carry.

Why Identity Bridging Is Harder Than Token Bridging

Token bridges operate on a simple accounting principle: lock an asset on the source chain, mint a synthetic on the destination chain. The underlying math is fungible. One USDC is interchangeable with another, so all the bridge needs to verify is that the lockup occurred.

Identity does not work this way. A credential is bound to a specific subject. It carries claims -- age verification, KYC status, organizational membership, biometric enrollment -- that cannot be decomposed into a fungible unit. When you bridge a credential from Ethereum to Solana, you need to prove three things simultaneously:

• Authenticity: The credential was legitimately issued by a trusted authority
• Binding: The credential belongs to the entity presenting it, not a replay or theft
• Freshness: The credential has not been revoked since issuance

Cross-chain messaging protocols like LayerZero, Wormhole, and Axelar can relay arbitrary payloads between chains, but they offer no native mechanism for verifying that a credential is still valid at the moment of relay. A token lockup is a point-in-time event. A credential is a continuous assertion. That distinction breaks most existing bridge architectures.

Current Approaches and Their Limitations

The identity community has converged on a few standards, each solving part of the problem:

The fundamental gap: none of these approaches solve all three requirements (authenticity, binding, freshness) in a single cross-chain operation. DIDs give you the identifier but not the proof. VCs give you the proof but lock you to one signature scheme. SBTs give you on-chain representation but cannot move. Cross-chain messaging can move data but cannot interpret it.

The Privacy Paradox: Proving Without Revealing

There is an additional constraint that makes cross-chain identity fundamentally different from cross-chain finance: privacy. When you bridge a token, the amount and destination are necessarily visible to the bridge validators. When you bridge an identity credential, revealing the underlying claims defeats the purpose. A protocol that requires you to expose your full KYC record to every chain you authenticate on is not a privacy-preserving identity system -- it is a surveillance system with extra steps.

This is precisely where zero-knowledge proofs become essential. A ZKP allows a user to prove a statement about their credential ("I am over 18," "I passed KYC with an approved provider," "I am a member of this DAO") without revealing the credential itself. The chain receives a cryptographic proof that the statement is true, verifiable in constant time, without ever seeing the underlying data.

Post-Quantum Attestations: Chain-Agnostic by Design

H33's approach treats identity attestations as standalone cryptographic objects that are independent of any specific chain's signature scheme. Instead of issuing credentials signed with secp256k1 (Ethereum) or Ed25519 (Solana), H33 produces attestations using CRYSTALS-Dilithium (ML-DSA), the NIST-standardized post-quantum digital signature algorithm.

This matters for two reasons:

1. Chain neutrality. A Dilithium signature is not native to any blockchain, which means it is equally foreign -- and equally verifiable -- on all of them. Verification requires only the signature, the public key, and a hash function. Any chain that supports custom precompiles or smart-contract-level signature verification can validate it.
2. Quantum resistance. Classical signature schemes (ECDSA, Ed25519, Schnorr) will be broken by Shor's algorithm on a sufficiently large quantum computer. Dilithium's security rests on the Module Learning With Errors (MLWE) lattice problem, which has no known quantum speedup. Credentials issued today with Dilithium remain valid in a post-quantum future.

How the Attestation Pipeline Works

The H33 attestation flow produces a credential bundle that can be deployed to any chain in a single API call:

// 1. Authenticate user (FHE-encrypted biometric or OTP)
const authResult = await h33.authenticate({
  method: "biometric",
  template: encryptedTemplate,  // BFV-encrypted, never leaves ciphertext
});

// 2. Generate cross-chain attestation
const attestation = await h33.attest({
  subject: authResult.userId,
  claims: ["kyc_passed", "age_over_18"],
  chains: ["ethereum", "solana", "polygon"],
  signatureScheme: "dilithium5",
});

// 3. Deploy to target chains
// Returns tx hashes for each chain deployment
const deployments = await h33.deploy(attestation);

Under the hood, each attestation bundle contains three components: a SHA3-256 digest of the credential claims, a Dilithium-5 signature over that digest, and a ZKP that the claims were derived from a valid authentication event -- without revealing the authentication data itself. This entire pipeline computes on encrypted data end to end. The bundle is approximately 4.6 KB (dominated by the Dilithium signature at ~4.6 KB for security level 5).

On-Chain Verification Architecture

Deploying a Dilithium-signed attestation on-chain requires a verification contract or program on each target chain. The verification logic is identical across chains -- only the deployment wrapper changes:

Once verified, the attestation is stored as a Soulbound Token (SBT) or an on-chain credential record linked to the user's chain-native address. The critical distinction: the Dilithium signature is the root of trust, not the chain-specific address. This means the same attestation can be verified on multiple chains without re-authentication.

Revocation and Freshness

Attestations include a validUntil timestamp and a revocation anchor -- a commitment published to a Merkle tree that the issuer can update. Verifier contracts check both conditions: the timestamp must be in the future, and the revocation anchor must not appear in the issuer's revocation set. This gives relying parties confidence that the credential is both unexpired and unrevoked, without requiring a real-time callback to the issuer.

Getting Started

Implementing cross-chain identity with H33 requires three integration steps:

1. Enroll users via the /api/enroll endpoint with FHE-encrypted biometric templates or standard OTP. Enrollment produces a user ID and a Dilithium public key pair.
2. Request attestations via the /api/attest endpoint, specifying the claims to include and the target chains. The API returns a signed attestation bundle with embedded ZKP.
3. Deploy verifier contracts on each target chain. H33 provides reference implementations for Solidity (EVM chains), Rust/BPF (Solana), and CosmWasm (Cosmos ecosystem). Each verifier is under 500 lines of code.

The free tier includes 10,000 attestations per month -- enough to prototype a cross-chain identity system before committing to a production plan. Every attestation is post-quantum secure from day one, ensuring that credentials issued today will not need to be re-issued when quantum computers arrive.