HN Explorer

I designed a post-quantum blockchain architecture alone over 3 years

4 points by _9u0i ↗ HN
Hi everyone,

I'm an independent researcher and founder of the : project, a blockchain architecture I've been designing alone over the past 3 years. The goal was to build something that truly prepares for the next era of blockchain security and scalability — not just another token.

[name-redacted] integrates:

- Post-Quantum Cryptography (Kyber + Dilithium hybrid) - zk-Rollup for scalability and zero-knowledge privacy - DAG-based sharding for parallelism - Modular AI layer for gas tuning and anomaly detection

The entire system is documented here on GitHub: [link-redacted]

I'm not launching a token yet, and this isn't a pump project. I’m just now starting to engage with the global developer and cryptography community — would love any feedback or criticism on the architecture, assumptions, or tradeoffs.

Thanks for reading. – [name-redacted]

3 comments

[ 2.9 ms ] story [ 18.1 ms ] thread
_9u0i
Open to any technical critique — especially around the PQC (Kyber + Dilithium) integration, zk-Rollup performance, or the modular AI layer. Would really appreciate honest feedback from cryptography/blockchain devs.
3np
What's the client interoperability story look like in practice for EVM? Ie how much work if any is required to start using an existing Eth wallet implementation with [name-redacted] (using the "compatibility ECC layer" I assume?) besides pointing an RPC URL with the right networkID? Are semantics and API for smart contracts similar enough that this would even make sense?
_9u0i
Great question — we're still in the pre-MVP phase, but client interoperability is a key part of our architecture.

[name-redacted] includes a compatibility ECC layer designed specifically to support existing Ethereum wallet infrastructure (like MetaMask) with minimal friction. In practice, the idea is that users can connect via standard RPC by setting the appropriate networkID, just as they would for an Ethereum testnet or L2.

Under the hood, [name-redacted] uses a hybrid cryptographic design: post-quantum signatures (e.g., Dilithium) are primary, but ECDSA remains fully supported for compatibility. This ensures existing wallet libraries, signing tools, and dApp frameworks can interact with our chain during the transition phase.

Regarding smart contract compatibility: our VM is not EVM, but the API design is meant to be semantically close. We're aiming for Solidity-like interoperability via WASM (Ink! / CosmWasm compatible), so existing contracts would need light adaptation, but core logic and interfaces can be reused.

We're releasing more details on our architecture soon — your interest means a lot!