OKB OKB

Claim: OKX has published educational articles about quantum threats to blockchain/Ethereum but has not published a cryptographic inventory specific to OKB or X Layer.

Coverage basis: Published educational content only; no formal inventory exists

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No public cryptographic inventory exists for OKB or X Layer (Readiness & Risk Cap: 10).

Assurance: OKX has published 3+ educational articles on quantum threats (2025–2026), demonstrating organizational awareness. However, none constitutes a formal cryptographic inventory identifying specific public-key mechanisms, attack assumptions, affected assets, or affected layers for OKB or X Layer. Articles discuss Ethereum and Bitcoin generally.

The absence of a cryptographic inventory is the most restrictive Readiness & Risk Cap (10). OKX's articles are general educational content, not an OKB-specific inventory.

• https://www.okx.com/learn/how-ethereum-is-preparing-for-the-quantum-computing-era
• https://www.okx.com/learn/quantum-computing-blockchain-cryptographic-threat
• https://www.okx.com/en-us/learn/layer-ethereum-quantum-preparation

Claim: No structured public evidence record (code references, specs, audits, transaction examples, reproducible analytics) exists to support an OKB-specific quantum risk assessment.

Coverage basis: No structured evidence record; token contract code is public on Etherscan but no quantum analysis exists

Implementation score: 0 · Evidence confidence: High

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

Assurance: The OKB token contract source code is publicly verifiable on Etherscan and GitHub, confirming standard ERC-20 with OwnedUpgradeabilityProxy. However, no quantum-specific analysis, audit, or evidence record has been published by OKX.

The raw contract code is available but has not been analyzed or presented by OKX in a quantum-risk context.

• https://etherscan.io/address/0x75231f58b43240c9718dd58b4967c5114342a86c#code
• https://github.com/okx/okberc20token/blob/master/OKb.sol

Claim: OKB transactions on both X Layer (OP Stack) and Ethereum use exclusively ECDSA secp256k1 signatures. No PQC or hybrid-PQC signature support exists.

Coverage basis: X Layer is an EVM-equivalent OP Stack L2 using standard Ethereum account model; Ethereum ERC-20 OKB uses standard ECDSA

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All spend authorization is ECDSA-only. Shor's algorithm breaks ECDSA, enabling key recovery from public keys and unauthorized spending.

Assurance: X Layer docs confirm EVM equivalence with standard Ethereum account model. OP Stack PQ roadmap (Jan 2026) confirms current ECDSA dependency and targets 2036 for deprecation. No hybrid-PQC or PQC signature path exists in production on X Layer or Ethereum for OKB.

This is the most fundamental quantum vulnerability. Every OKB transfer, trade, and authorization relies on cryptography broken by quantum computers.

• https://web3.okx.com/xlayer/docs/developer/build-on-xlayer/about-xlayer
• https://www.okx.com/xlayer/docs
• https://etherscan.io/token/0x75231f58b43240c9718dd58b4967c5114342a86c
• https://www.optimism.io/blog/a-post-quantum-roadmap-for-the-superchain

Claim: OKB uses standard Ethereum account model where public keys are exposed on first transaction. All transacted EOAs, admin keys, bridge signers, and sequencer keys have publicly visible public keys vulnerable to offline quantum attack.

Coverage basis: Standard EVM account model; all OKB transactions reveal sender public keys in ECDSA signatures

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Long-exposure public keys from transacted EOAs, admin keys, and bridge signers enable offline quantum key-recovery attacks with no time constraint.

Assurance: The Ethereum account model inherently exposes public keys in ECDSA signatures. No key-derivation design change, stealth addressing, or PQ address scheme has been implemented for OKB on either chain.

Long-exposure (at-rest) attack surface is the most dangerous: attackers can compute private keys offline with no time pressure once quantum capability matures.

• https://etherscan.io/token/0x75231f58b43240c9718dd58b4967c5114342a86c
• https://web3.okx.com/xlayer/docs/developer/build-on-xlayer/about-xlayer

Claim: X Layer uses a trusted sequencer (OP Stack) with ECDSA authentication. L1 settlement relies on Ethereum consensus (BLS validator signatures, classical). No PQC consensus authentication exists.

Coverage basis: OP Stack trusted sequencer model; Ethereum L1 BLS-based validator signatures; AggLayer ZK proof verification

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: X Layer sequencer authentication is ECDSA-based. Ethereum consensus uses BLS signatures (quantum-vulnerable). Both create paths to consensus compromise.

Assurance: OP Stack PQ roadmap acknowledges need to migrate sequencer keys off ECDSA and Ethereum validators off BLS, but no timeline for production deployment. AggLayer ZK proof verification adds another quantum-vulnerable dependency (pairing-based proofs).

OKB as a token inherits this vulnerability from X Layer. Sequencer compromise could enable transaction censorship, reordering, or malicious state transitions affecting all OKB on X Layer.

• https://web3.okx.com/xlayer/docs/developer/build-on-xlayer/about-xlayer
• https://www.optimism.io/blog/a-post-quantum-roadmap-for-the-superchain
• https://web3.okx.com/learn/x-layer-architecture-migration-from-polygon-zkevm-to-op-stack

Claim: OKB token contract state integrity depends on Ethereum L1 and X Layer OP Stack security. The Ethereum proxy contract has ECDSA-secured admin keys. Bridge contracts (OP Stack bridge + AggLayer) use classical multisigs.

Coverage basis: Ethereum L1 state integrity; OP Stack optimistic rollup with 7-day challenge window; AggLayer ZK proofs for cross-chain settlement

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: ECDSA-secured proxy admin key can upgrade the OKB contract. Bridge multisigs are ECDSA-based. KZG commitments (Ethereum blobs) and ZK proofs (AggLayer) rely on pairing-based cryptography vulnerable to quantum attack.

Assurance: The Ethereum proxy admin key (OwnedUpgradeabilityProxy) allows the owner to call upgradeTo() and upgradeToAndCall(). A quantum attacker recovering the admin private key could deploy a malicious implementation. Bridge contracts (forked from Polygon zkEVM, now OP Stack bridge) use similar classical multisig patterns.

The August 2025 contract upgrade removed mint/burn but did not change the proxy admin pattern. The admin key remains a single point of quantum failure.

• https://etherscan.io/address/0x75231f58b43240c9718dd58b4967c5114342a86c#code
• https://github.com/okx/xlayer-bridge-service
• https://github.com/okx/xlayer-contracts
• https://web3.okx.com/xlayer/docs/developer/build-on-xlayer/contracts

Claim: OKB has no privacy layer. The AggLayer ZK proof system uses pairing-based cryptography (potentially Groth16/PLONK) which is quantum-vulnerable, but this is an infrastructure dependency, not an OKB-specific privacy feature.

Coverage basis: No privacy layer exists for OKB; AggLayer ZK proofs are inherited infrastructure

Implementation score: 0 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: While X Layer/AggLayer ZK proofs may be quantum-vulnerable (pairing-based), this is captured under state-integrity (subfactor 4) rather than privacy.

N/A by architecture. OKB has no privacy-specific cryptographic dependencies beyond what is captured in other subfactors.

• https://web3.okx.com/xlayer/docs/developer/build-on-xlayer/about-xlayer

Claim: OKB as a token does not have P2P transport or node identity. These are properties of X Layer infrastructure, not the OKB token.

Coverage basis: Token-level evaluation; P2P is an infrastructure concern

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Marked N/A for token-scope evaluation. P2P quantum vulnerabilities of X Layer and Ethereum are captured indirectly through host-chain inheritance.

Claim: No PQ-supporting wallet, custody, HSM, or hardware-wallet workflows exist for OKB. All OKB custody (exchange, personal wallets, institutional) relies on classical ECDSA keys.

Coverage basis: No PQ wallet/custody infrastructure exists for OKB

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No PQ-compatible custody path exists. Exchange-held OKB, institutional custody (BitGo), and hardware wallet OKB (Ledger) are all secured by ECDSA keys with no PQ migration option.

Assurance: BitGo supports OKB/X Layer custody with standard ECDSA key management. Ledger supports OKB via standard Ethereum app. Neither offers PQ signature support for OKB. No HSM vendor has published OKB-specific PQ integration.

This is particularly critical given that the majority of OKB volume and value is held on centralized exchanges (OKX, MEXC, etc.) under ECDSA custody.

• https://developers.bitgo.com/docs/okbxlayer
• https://www.ledger.com/coin/wallet/okb

Claim: 0% of OKB value is protected. All ~21M OKB (~$1.8B at ~$88/OKB) is secured exclusively by ECDSA keys vulnerable to Shor's algorithm.

Coverage basis: 100% of OKB supply relies on ECDSA; no PQ-protected value exists; coverage <25%

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: All OKB value is quantum-vulnerable. No migration, freeze, deprecation, burn, or recovery mechanism exists. Coverage <25% → 1 point earned of 20 weight.

Assurance: Value-at-risk includes: circulating OKB on X Layer, OKB held on OKX and other exchanges, residual ERC-20 OKB on Ethereum (pre-August 2025 migration), bridge-escrowed OKB, and OKB in DeFi protocols. All categories use ECDSA exclusively.

Coverage threshold <25% maps to 1 earned point (of 20 subfactor weight) per QRI 9.3.1. This is the only subfactor contributing positive points to the QRI Score (1.00 of 25 category points).

• https://etherscan.io/token/0x75231f58b43240c9718dd58b4967c5114342a86c
• https://www.okx.com/price/okb-okb
• https://www.coingecko.com/en/coins/okb

Claim: No critical OKB wallets (treasuries, exchanges, custodians, bridges, foundation) have been migrated to PQ protection. All use classical ECDSA.

Coverage basis: No wallet migration exists; all critical wallets are ECDSA-only

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: OKX exchange hot/cold wallets, MEXC OKB custody, BitGo institutional custody, bridge multisigs, and the Ethereum proxy admin are all ECDSA-secured with no migration path.

Assurance: The burn of 65.26M OKB and contract upgrade (August 2025) affected supply but did not migrate any critical wallet to PQ protection. The proxy admin key remains ECDSA-secured.

Exchange-held OKB represents the largest concentration of quantum-vulnerable value. OKX exchange custody security is opaque but relies on standard ECDSA key management.

• https://etherscan.io/address/0x75231f58b43240c9718dd58b4967c5114342a86c#code
• https://www.okx.com/help/announcement-on-the-pp-upgrade-of-x-layer-and-optimisation-of-the-okb-gas

Claim: No identification, measurement, deprecation, or migration of legacy quantum-vulnerable OKB holdings has been performed.

Coverage basis: No legacy pool identification or deprecation exists

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No mechanism exists to identify, deprecate, freeze, or burn quantum-vulnerable OKB. Residual ERC-20 OKB on Ethereum with exposed public keys is permanently vulnerable.

Assurance: The Ethereum L1 OKB phase-out (August 2025) stopped new withdrawals to Ethereum but did not address existing vulnerable balances. Holders were advised to migrate to X Layer via OKX Exchange, but this was an operational migration, not a quantum-security measure. Dormant Ethereum OKB with exposed public keys remains quantum-vulnerable indefinitely.

This is a permanent vulnerability for any OKB that remains on Ethereum in addresses that have sent transactions (exposed public keys).

Claim: No OKB-specific quantum migration roadmap exists. The OP Stack Post-Quantum Roadmap (January 2026) provides an infrastructure-level plan with a 10-year timeline for ECDSA EOA deprecation, but this is Optimism's roadmap, not OKX's, and does not address OKB-specific concerns.

Coverage basis: OP Stack PQ roadmap exists at infrastructure level; no OKB-specific adaptation published

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: The OP Stack PQ roadmap (Jan 2026) is a credible, published infrastructure plan committing to deprecate ECDSA EOAs by 2036, migrate sequencers to PQ signatures, and coordinate with Ethereum on validator-level changes. As X Layer runs on OP Stack, it would inherit these upgrades. However, OKX has not published its own adaptation, timeline, or commitment. The roadmap explicitly states 'Users don't need to take any action today' — confirming zero current protection. Also, the roadmap does not address OKB-specific proxy admin keys or bridge governance.

Scored at 0.25 (roadmap/proposal level) because the OP Stack PQ roadmap exists and is directly applicable to X Layer infrastructure. This is the only subfactor in Category 4 earning non-zero points.

• https://www.optimism.io/blog/a-post-quantum-roadmap-for-the-superchain
• https://www.okx.com/learn/how-ethereum-is-preparing-for-the-quantum-computing-era

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, warnings, or migration prompts exist for OKB users.

Coverage basis: No migration accessibility features exist

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: OKB holders have no mechanism to migrate to quantum-safe keys, accounts, or custody. Users are locked into ECDSA with no opt-in PQ path.

Assurance: OKX Wallet, Ledger, BitGo, and other OKB-supporting wallets all use standard ECDSA. No PQ wallet integration, account abstraction path, or migration prompt exists. The OP Stack PQ roadmap envisions EIP-7702 account abstraction for migration but this is years away from production.

Even if a user wanted to protect their OKB against quantum attack today, no mechanism exists to do so.

• https://web3.okx.com/xlayer
• https://www.okx.com/price/okb-okb

Claim: No quantum-specific enforcement mechanisms, coordination, or unsafe-path blocking exists for OKB.

Coverage basis: No enforcement or coordination mechanisms exist

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No deprecation, freeze, disabled legacy signing, restricted withdrawals, or mandatory migration deadline exists for quantum-vulnerable OKB paths.

Assurance: While OKX demonstrated coordination capability during the August 2025 OKB migration (Ethereum→X Layer) and the October 2025 X Layer architecture migration (Polygon CDK→OP Stack), these were non-quantum operational migrations. No quantum-specific enforcement infrastructure exists.

The operational migrations of 2025 show organizational capability for coordination but do not address quantum security.

Claim: No public quantum-specific emergency disclosure, incident-response, or governance process exists for OKB or X Layer.

Coverage basis: No quantum-specific incident response process exists

Implementation score: 0 · Evidence confidence: High

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

Assurance: No quantum-specific incident response playbook, vulnerability disclosure process, or emergency governance procedure has been published. This is recorded as an assurance caveat rather than score-reducing because the absence of a process does not itself create a quantum-attack path — the attack paths already exist through unprotected ECDSA. However, the lack of a process means response to a quantum emergency would be ad-hoc.

Note-only caveat per Section 7.4: the absence of a formal quantum-specific IR playbook does not create a new attack path. The underlying ECDSA vulnerability is already captured in other subfactors.

Claim: OKB uses no PQC or hybrid-PQC algorithms. All cryptographic operations use classical ECDSA secp256k1.

Coverage basis: No PQC algorithms in use

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No NIST-standardized PQC algorithms (ML-DSA/Dilithium, SLH-DSA/SPHINCS+, FN-DSA/Falcon) or hybrid constructions are used anywhere in the OKB ecosystem.

Assurance: The OP Stack PQ roadmap has not yet selected a specific PQ signature scheme, stating: 'We don't yet know whether the NIST-standardized lattice-based signatures are the best long-term choice.' This indicates the infrastructure-level algorithm selection is still in early evaluation, not implementation.

Algorithm selection is a prerequisite for any migration. No selection has been made at either the OKB or OP Stack level.

• https://etherscan.io/address/0x75231f58b43240c9718dd58b4967c5114342a86c#code
• https://github.com/okx/okberc20token/blob/master/OKb.sol

Claim: No independent cryptographic or implementation audit exists for any quantum-critical scope of OKB or X Layer, as no PQC implementation exists to audit.

Coverage basis: No PQC implementation, therefore no audit

Implementation score: 0 · Evidence confidence: High

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

Assurance: No quantum-specific audit can exist when no PQC implementation exists. This subfactor will become relevant only after a PQC implementation is deployed.

Scored 0.00 because there is nothing to audit. This is a consequence of the absence of any PQC implementation rather than an independent failure.

Claim: The OKB token contract is open-source on Etherscan and GitHub, but no PQC implementation exists to evaluate for openness or reproducibility.

Coverage basis: Classical contract is open-source; no PQC code exists

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: OKX maintains public GitHub repositories for the OKB token contract, X Layer bridge service, and X Layer contracts. These are open-source but contain only classical cryptography. No PQC implementation exists to benefit from open-source review.

The classical implementations being open-source is positive for transparency but irrelevant to quantum readiness without PQC code.

• https://etherscan.io/address/0x75231f58b43240c9718dd58b4967c5114342a86c#code
• https://github.com/okx/okberc20token
• https://github.com/okx/xlayer-bridge-service
• https://github.com/okx/xlayer-contracts

Claim: The OKB token contract uses an upgradeable proxy pattern enabling future upgrades, but no parameter agility or PQC upgrade path has been documented.

Coverage basis: Proxy pattern exists but no documented PQC upgrade path

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The OwnedUpgradeabilityProxy pattern on Ethereum technically allows contract upgrades, which could theoretically support future PQC integration. However, no PQC-specific upgrade path, parameter agility design, or migration specification has been documented. The OP Stack PQ roadmap discusses hardfork-based upgrades for the infrastructure layer but does not address token-level parameter agility.

While the proxy pattern provides technical upgrade capability, the absence of documentation means there is no verifiable plan. The proxy admin key itself is quantum-vulnerable, creating a circular dependency.

• https://etherscan.io/address/0x75231f58b43240c9718dd58b4967c5114342a86c#code

Claim: No PQC signatures are in use, so no stateful-signature safety considerations apply. No analysis of side-channel, fault-injection, or HSM risks for PQC has been performed.

Coverage basis: No PQC signatures in use; no analysis performed

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: This subfactor is marked applicable because the spec requires it to be scored even when no PQC implementation exists ('A subfactor may not be marked N/A merely because the project has not secured, implemented, documented, measured, audited, or migrated it'). Score is 0.00 due to absence of any PQC implementation to analyze.

Will become relevant if/when stateful PQC signatures (XMSS/LMS-style) are adopted. Currently no analysis exists because no PQC signatures are deployed.

Claim: No performance or resource-impact analysis for PQC deployment on X Layer or for OKB transactions has been published.

Coverage basis: No PQC performance analysis exists

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: Marked applicable per spec requirements. No PQC performance benchmarks, gas cost analysis, block validation impact assessment, mempool policy analysis, or node hardware requirement evaluation exists. The OP Stack PQ roadmap does not include performance analysis for its proposed PQ migration.

PQC signatures (particularly ML-DSA/Dilithium and SLH-DSA/SPHINCS+) have significantly larger signature sizes and verification costs than ECDSA. Without analysis, the feasibility and cost of deployment are unknown.