Naoris Protocol NAORIS

Claim: Project knowledge base discusses quantum threats and post-quantum cryptography concepts including Dilithium and KEM, but does not provide a formal, structured cryptographic inventory of all critical public-key mechanisms in the production system or a public quantum threat model covering attack assumptions and affected assets.

Coverage basis: PQ/hybrid usage claimed but not formally inventoried

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: Knowledge base articles discuss PQ concepts at a high level but lack structured cryptographic inventory, key dependency mapping, or formal threat model documentation.

Project claims PQ-native design for the L1, which per Section 7.1 would make formal ECC inventory partially moot for the native asset. However, the ERC-20 token (classical) is the primary production asset and has no formal quantum threat assessment.

• https://knowledgebase.naorisprotocol.com/naoris-protocol/technical-guide/post-quantum-blockchain-infrastructure-naoris-protocol
• https://knowledgebase.naorisprotocol.com/naoris-protocol/introduction/what-is-a-post-quantum-sub-zero-blockchain

Claim: Limited public evidence: ERC-20 token code on GitHub, Etherscan token contract, testnet statistics on official website, knowledge base articles, and secondary media reports. No on-chain mainnet evidence, no cryptographic specifications, no independent audits of PQ implementation.

Coverage basis: Evidence exists for ERC-20 component only; L1 evidence is self-reported

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: Hashlock audit (2025) covers token contracts only. CertiK Skynet insight exists but scope unclear. No audit covers PQ L1 implementation.

Evidence for native L1 is entirely self-reported; no independent verification path exists.

• https://github.com/Naoris-Protocol/naoris-token
• https://etherscan.io/token/0x1b379a79c91a540b2bcd612b4d713f31de1b80cc
• https://www.naorisprotocol.com/

Claim: Project claims all native L1 transactions use NIST ML-DSA (FIPS 204 / Dilithium-5) signatures. ERC-20 token transactions on Ethereum use standard ECDSA. Testnet reportedly processed 106M+ PQ transactions.

Coverage basis: ERC-20: classical ECDSA. Native L1: testnet evidence only, mainnet unverifiable.

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: ERC-20 NAORIS token spend authorization is entirely ECDSA-based on Ethereum; ~$54M circulating value is quantum-vulnerable. Native L1 PQ spend authorization cannot be independently verified on mainnet.

Assurance: No public mainnet transaction evidence, no block explorer, no open-source L1 node software. Testnet statistics are self-reported.

The Decrypt article quotes CGO stating ML-DSA (FIPS 204) is used with an 'irreversible security transition' mechanism. This is a credible technical claim but unverifiable in production.

• https://etherscan.io/token/0x1b379a79c91a540b2bcd612b4d713f31de1b80cc
• https://www.naorisprotocol.com/
• https://www.naorisprotocol.com/blog/naoris-protocol-deploys-post-quantum-mainnet-to-secure-global-digital-infrastructure

Claim: Native L1 claims PQ-native account design from genesis with ML-DSA keys. ERC-20 token uses Ethereum's EOA model with exposed public keys upon transaction.

Coverage basis: ERC-20: classical exposed-key model. Native L1: claimed PQ-native, unverifiable.

Implementation score: 0.25 · Evidence confidence: Very Low

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: No address format specification, key derivation documentation, or account model details are publicly available for the native L1.

For the ERC-20 token, Ethereum EOAs that have sent transactions have exposed public keys — a long-exposure quantum vulnerability.

• https://knowledgebase.naorisprotocol.com/naoris-protocol/introduction/what-is-a-post-quantum-sub-zero-blockchain

Claim: Project claims dPoSec consensus uses post-quantum signatures for validator nodes. dPoSec combines PoS and BFT elements with an Oracle for Chain Health.

Coverage basis: Testnet evidence claimed for PQ consensus; mainnet unverifiable. ERC-20 inherits Ethereum consensus.

Implementation score: 0.25 · Evidence confidence: Very Low

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: No documentation of the exact cryptographic signature scheme used for BFT voting. Dilithium is known to be challenging for BFT aggregation/threshold use cases due to large signature sizes and lack of native aggregation. Mainnet validators are invite-only, preventing independent verification.

The dPoSec documentation describes BFT integration but does not specify how validator votes are cryptographically signed or aggregated. This is a gap for quantum attack surface analysis.

• https://knowledgebase.naorisprotocol.com/naoris-protocol/technical-guide/dposec-consensus-mechanism
• https://www.naorisprotocol.com/blog/naoris-protocol-deploys-post-quantum-mainnet-to-secure-global-digital-infrastructure

Claim: Project claims validation results are recorded as immutable events on the Post-Quantum Sub-Zero Blockchain Layer. No KZG/pairing dependencies identified.

Coverage basis: ERC-20 inherits Ethereum state integrity. Native L1 state integrity claims are unverifiable.

Implementation score: 0.25 · Evidence confidence: Very Low

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: No public specification of state commitment scheme, Merkle tree construction, or data availability mechanism for the native L1.

No evidence of pairing-based commitments (KZG) that would create additional quantum vulnerability. However, the absence of documentation means this cannot be confirmed.

• https://knowledgebase.naorisprotocol.com/naoris-protocol/technical-guide/overall-architecture

Claim: No privacy layer or ZK proof system identified for the Naoris Protocol ecosystem.

Coverage basis: N/A

Implementation score: 0 · Evidence confidence: Not assessed

Issue classification: none · Score treatment: not applicable

Claim: No evidence of PQ-secured P2P networking, node identity, or peer authentication for either the ERC-20 (inherits Ethereum) or the native L1.

Coverage basis: No PQ P2P evidence for native L1

Implementation score: 0 · Evidence confidence: None

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: No documentation of P2P layer cryptography for the native L1. The forked go-ethereum repository in the GitHub organization is unmodified from standard Ethereum, offering no PQ P2P enhancements.

P2P is generally a lower-risk layer for quantum attacks compared to spend authorization, but remains an unaddressed surface.

Claim: No evidence of PQ wallet, custody, HSM, or hardware wallet support for ML-DSA signatures in the Naoris ecosystem.

Coverage basis: No PQ wallet/custody support evidenced

Implementation score: 0 · Evidence confidence: None

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: No evidence of any wallet supporting ML-DSA for Naoris Protocol. The testnet used a browser extension wallet; PQ capabilities of production wallets unknown.

Even if the native L1 supports PQ signatures at protocol level, the absence of wallet support means users cannot practically use PQ signing paths.

Claim: The ERC-20 NAORIS token (~$54M circulating market cap, ~599M tokens) is 100% on Ethereum and entirely quantum-vulnerable. Native L1 value is unknown/unverifiable. Project claims native L1 is PQ-native with no classical namespace, but ERC-20 is the publicly verifiable value.

Coverage basis: ERC-20 value 100% quantum-vulnerable; native L1 value unmeasurable

Implementation score: 0.05 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: ~$54M circulating ERC-20 token value is 100% exposed to Ethereum's ECDSA vulnerability. Native L1 value coverage cannot be measured.

Assurance: Circulating supply and market cap data from CoinCarp and Etherscan as of evaluation date. Native L1 token balances are not publicly verifiable.

Coverage <25% (experimental/negligible protection) when considering total publicly verifiable value. If the native L1 has meaningful value, it cannot be measured.

• https://etherscan.io/token/0x1b379a79c91a540b2bcd612b4d713f31de1b80cc
• https://www.coincarp.com/currencies/naorisprotocol/

Claim: ERC-20 token has admin keys (upgradeable UUPS proxy, pausable, minting controls) all on Ethereum secured by ECDSA. No evidence any critical wallets have migrated to native L1 PQ protection.

Coverage basis: No critical wallet migration evidenced

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: ERC-20 token admin keys (upgrade, pause, mint) are ECDSA-secured on Ethereum. Quantum compromise of admin keys could affect the entire token supply.

Assurance: ERC-20 contract is an ERC1967Proxy with admin-controlled upgrade capability. No timelock or multisig details confirmed.

Treasury, foundation, and exchange wallets holding NAORIS are on Ethereum and quantum-vulnerable.

• https://github.com/Naoris-Protocol/naoris-token
• https://etherscan.io/token/0x1b379a79c91a540b2bcd612b4d713f31de1b80cc

Claim: The ERC-20 token supply (~599M circulating, 4B max) is entirely on Ethereum and represents a legacy vulnerable pool. No deprecation, freeze, or burn plan for the ERC-20 token is publicly documented.

Coverage basis: ERC-20 supply identified as legacy vulnerable pool but not addressed

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The ERC-20 supply and holders are visible on Etherscan (2,409 holders). No migration or deprecation mechanism for these tokens is documented.

The project website has a 'Bridge tokens' button but no public documentation of the bridge mechanism, its security model, or whether it can handle the full ERC-20 supply.

• https://etherscan.io/token/0x1b379a79c91a540b2bcd612b4d713f31de1b80cc

Claim: Project blog describes phased mainnet rollout starting with invite-only validators, followed by community access, then developers. An 'irreversible security transition' is described where accounts adopting PQ keys cannot revert to classical signatures.

Coverage basis: Roadmap exists at high level; sequencing details for ERC-20 migration absent

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: Roadmap is described at high level in blog posts. No detailed technical migration specification, activation criteria, or timeline for ERC-20 to native L1 migration.

The 'irreversible security transition' is described for native L1 accounts but does not address how ERC-20 holders migrate.

• https://www.naorisprotocol.com/blog/naoris-protocol-deploys-post-quantum-mainnet-to-secure-global-digital-infrastructure
• https://decrypt.co/363207/naoris-launches-post-quantum-blockchain-bitcoin-ethereum

Claim: Native L1 claims PQ-native account creation from genesis. ERC-20 token holders must bridge to access native L1. No public wallet tooling, custody paths, or migration prompts evidenced for the bridge process.

Coverage basis: No accessible migration tooling for ERC-20 holders

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: Website has 'Bridge tokens' button but no public documentation of the bridge, its security model, supported wallets, or migration process.

No public wallet software, browser extension, or CLI tool for native L1 interaction is available. SDKs are described as future releases.

• https://www.naorisprotocol.com/
• https://knowledgebase.naorisprotocol.com/naoris-protocol/technical-guide/post-quantum-blockchain-infrastructure-naoris-protocol

Claim: Project claims 'irreversible security transition' on native L1: once an account adopts PQ keys, classical signature attempts are blocked. No evidence of exchange, custody, or bridge coordination. ERC-20 bridge path remains unrestricted.

Coverage basis: Enforcement claimed for native L1 only; no ERC-20 coordination evidenced

Implementation score: 0.5 · Evidence confidence: Low

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Two-way bridge between ERC-20 (quantum-vulnerable Ethereum) and native L1 (claimed PQ) is unrestricted and undocumented, creating a quantum-critical vulnerability pathway.

Assurance: The 'irreversible security transition' is described in media interviews but its implementation and enforcement on mainnet cannot be verified. No bridge security documentation exists.

If the bridge permits unrestricted two-way flow, value can always flow back to quantum-vulnerable Ethereum, undermining any PQ protection on the native chain.

• https://decrypt.co/363207/naoris-launches-post-quantum-blockchain-bitcoin-ethereum
• https://crypto.news/naoris-launches-first-nist-approved-quantum-resistant/

Claim: No public evidence of a formal quantum-specific incident response process, vulnerability disclosure program, or emergency governance procedure for quantum-related threats.

Coverage basis: No quantum-specific IR/disclosure process evidenced

Implementation score: 0 · Evidence confidence: None

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Per QRI v3.1 Note-Only Caveat Rule, absence of a formal quantum-specific IR playbook is a note-only caveat unless it leaves a current quantum-vulnerable path unresolved.

This is a note-only caveat per Section 7.4. However, given the ERC-20 token's quantum exposure, a quantum-specific IR process would be valuable.

Claim: Project claims use of NIST ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) at Security Level 5 for transaction signatures. The CGO has explicitly distinguished ML-DSA from pre-standardization Dilithium in public statements.

Coverage basis: Algorithm selection is NIST-standardized; implementation unverifiable on mainnet

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: score-reducing

Assurance: ML-DSA (FIPS 204) is a NIST-standardized algorithm, which is positive. However, the implementation cannot be independently verified. The CGO's public statements show awareness of the ML-DSA vs Dilithium distinction, which is a positive signal.

Score of 0.50 reflects that the algorithm choice is verified (NIST-standardized) and testnet evidence exists, but mainnet implementation is unverifiable.

• https://decrypt.co/363207/naoris-launches-post-quantum-blockchain-bitcoin-ethereum
• https://www.naorisprotocol.com/blog/naoris-protocol-deploys-post-quantum-mainnet-to-secure-global-digital-infrastructure

Claim: Hashlock audit (2025) covers ERC-20 token contracts only. CertiK Skynet shows Code Security score of 63.12 with unclear scope. No independent audit of the native L1 PQ cryptography, consensus, or node implementation exists.

Coverage basis: Audits cover classical ERC-20 only; PQ L1 is unaudited

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Hashlock audit is stale (2025) relative to April 2026 mainnet and scope-mismatched (ERC-20 only, not PQ L1). CertiK scope unclear. No PQ-specific audit exists. Per QRI v3.1, audit gaps are confidence-reducing but do not independently cap the QRI Score unless they make a quantum-critical property unverifiable.

The CertiK Code Security score of 63.12 is relatively low. Without knowing the audit scope, this may indicate implementation quality concerns.

• https://www.naorisprotocol.com/mica-compliance-white-paper
• https://skynet.certik.com/projects/naoris-protocol

Claim: Only the ERC-20 token and governance Solidity contracts are open-source on GitHub. The native L1 node software, consensus implementation, and PQ cryptography integration are not publicly available.

Coverage basis: Partial open-source: ERC-20 contracts only

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: The Naoris-Protocol GitHub organization has 25 repos, but most are forks of Hyperledger/Ethereum projects. No native L1 node implementation is public. The go-ethereum fork appears unmodified from upstream.

Without open-source L1 node software, the PQ claims are inherently unverifiable by external parties.

• https://github.com/Naoris-Protocol/naoris-token
• https://github.com/Naoris-Protocol

Claim: No public documentation of parameter agility, algorithm upgrade path, or cryptographic agility mechanisms for the native L1. The ERC-20 token is upgradeable via UUPS proxy.

Coverage basis: No documented agility for native L1

Implementation score: 0 · Evidence confidence: None

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Per QRI v3.1, future PQ-to-PQ upgrade uncertainty is a note-only caveat for the current production scope. However, the absence of any documented upgrade path is notable.

This is treated as a note-only caveat per Section 7.4 since it concerns future upgrades from one claimed-PQ system to another. However, the absence of documentation for the current system's parameter management is concerning.

Claim: No public analysis of side-channel resistance, fault-injection countermeasures, state management for ML-DSA, or hardware wallet/HSM implementation considerations.

Coverage basis: No side-channel or implementation security analysis evidenced

Implementation score: 0 · Evidence confidence: None

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: ML-DSA is not a stateful signature scheme (unlike XMSS/LMS), so state-management risks are lower. However, side-channel and fault-injection considerations for Dilithium/ML-DSA implementations are real and unaddressed.

Treated as note-only per Section 7.4. Not score-reducing because the absence of a side-channel analysis does not itself create a quantum-enabled attack path; however, it represents a real-world implementation risk.

Claim: Project website claims 'up to 70,000 TPS' on testnet with Dilithium-5 signatures. No formal performance benchmark, gas/fee analysis, or resource-impact study is publicly available.

Coverage basis: Self-reported TPS figure; no formal benchmark

Implementation score: 0.25 · Evidence confidence: Very Low

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: The 70,000 TPS claim is self-reported with no independent verification. ML-DSA signatures are significantly larger (~2.5-4.5 KB) than ECDSA (~64-72 bytes), which has real implications for block size, propagation, and storage. No analysis of these impacts is available.

Treated as note-only per Section 7.4 (missing formal benchmark). However, ML-DSA's large signature size is a well-known challenge for blockchain deployment that deserves attention.

• https://www.naorisprotocol.com/