Pre-testnet development preview

Public network, benchmarks and independent audit not yet available.

Status
Hash stack clarity: why Poseidon2 stays scoped after Ethereum’s L1 pivot
Back to Engineering
September 6, 2026
Zeqron Protocol

Hash stack clarity: why Poseidon2 stays scoped after Ethereum’s L1 pivot

Z
Zeqron Protocol

Context

Public Ethereum Foundation research in 2026 is moving Ethereum L1 away from Poseidon toward mature hashes such as SHA / BLAKE, enabled by binary-field proving designs (“hash-friendly SNARKs”). That signal matters. It is not identical to Zeqron’s proving stack.

What Zeqron uses today

| Surface | Primitive | Role | |---------|-----------|------| | Protocol IDs / contracts | ParallelHash (SP 800-185) | Domain-separated protocol hashing | | DID / QronId | BLAKE3 | Identity display and related surfaces | | STARK / Hologram / PQ-VRF | Poseidon2 (BabyBear, width=32 per RFC-STARK-001) | Circuit-native commitment hash | | Storage MAC | KMAC256 | Authenticated storage | | QronHandshake KDF | HKDF-SHA3-256 | Session key derivation |

Poseidon2 is not a universal protocol hash on Zeqron.

Decision

Retain Poseidon2 for scoped STARK paths while monitoring hash-friendly STARK migrations and EF binary-field progress. Substitution is tracked via crypto-agility (RFC-CRYPTO-PQ-005). Replacing Poseidon2 requires a proving-path migration, not a one-line swap.

Non-claims

  • ::We do not claim Ethereum is “wrong.”
  • ::We do not claim Poseidon2 has SHA/BLAKE-class public cryptanalysis maturity.
  • ::Transparent STARKs do not, by themselves, prove end-to-end post-quantum security of the whole L1.

Full decision text and maturity grids: Security Profile.

Join the conversation

Have questions about our cryptographic implementation? Discuss this post on our community forum.

Standard interface restored.