Chainlink LINK

Claim: Chainlink has published an educational article on quantum-safe cryptography (Feb 2026) acknowledging the threat and discussing NIST PQC standards, but has not published a formal cryptographic inventory or project-specific quantum threat model.

Coverage basis: Educational article and technical documentation collectively describe cryptographic primitives used in OCR, CCIP, and VRF

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: The quantum-safe article is LLM-assisted per its own disclaimer. No formal CBOM, cryptographic inventory, or quantum threat model covering affected assets and layers has been published.

The OCR3 protocol paper (2025) explicitly states use of EdDSA and ECDSA, and documentation describes VRF and CCIP cryptography. This constitutes a partial implicit inventory but lacks the structure, completeness, and quantum-specific threat analysis required for a formal assessment.

• https://chain.link/article/quantum-safe-cryptography
• https://research.chain.link/ocr3.pdf
• https://docs.chain.link/architecture-overview/off-chain-reporting
• https://docs.chain.link/ccip/architecture
• https://docs.chain.link/vrf

Claim: Chainlink's documentation, open-source code, and OCR3 protocol paper provide technical details on cryptographic primitives, but no quantum-specific evidence record exists.

Coverage basis: Open-source repositories, protocol specifications, and documentation

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: Code and documentation are publicly available but contain no PQC implementations, quantum-security tests, migration tooling, or quantum-specific evidence artifacts.

The open-source nature of the codebase allows third-party verification that no PQC code exists, which is itself evidence, albeit negative.

• https://github.com/smartcontractkit/chainlink
• https://research.chain.link/ocr3.pdf
• https://docs.chain.link/architecture-overview/off-chain-reporting

Claim: LINK token transfers rely on host-chain (Ethereum) ECDSA for transaction authorization. Oracle node operational transactions use classical secp256k1/Ed25519. No PQC or hybrid-PQC spend authorization exists.

Coverage basis: LINK is a standard ERC-677/ERC-20 token; node transactions are classical

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: LINK token transfers are secured exclusively by Ethereum ECDSA. All LINK spend authorization is quantum-vulnerable.

LINK inherits the host chain's QRI score for basic token transfers. Token-specific admin/governance keys may have additional risk but are not separately assessed here.

• https://etherscan.io/token/0x514910771af9ca656af840dff83e8264ecf986ca
• https://docs.chain.link/resources/link-token-contracts
• https://github.com/smartcontractkit/chainlink

Claim: LINK token uses standard Ethereum EOAs with exposed public keys upon transaction broadcast. No PQ/hybrid address schemes or key-derivation controls exist.

Coverage basis: Standard Ethereum account model with ECDSA key pairs

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Any LINK address that has sent a transaction has an exposed ECDSA public key vulnerable to long-exposure quantum key-recovery attacks.

Long-exposure (at-rest) public keys are the most immediate quantum risk. Addresses that have only received LINK (never sent) have only the address hash exposed, providing partial protection.

• https://etherscan.io/token/0x514910771af9ca656af840dff83e8264ecf986ca
• https://docs.chain.link/resources/link-token-contracts

Claim: OCR oracle report signing uses EdDSA (internal) and ECDSA (attestations). VRF uses classical ECC. No PQC or hybrid-PQC consensus authentication exists.

Coverage basis: OCR3 protocol specification and VRF documentation confirm exclusive use of classical ECC

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: OCR quorum signatures and VRF proofs are verified on-chain using classical ECC. A quantum attacker could forge oracle reports and VRF outputs, compromising all dependent DeFi protocols.

OCR uses a threshold quorum (n=3f+1) where signatures are aggregated. A quantum attacker only needs to forge a quorum's worth of signatures (f+1) to inject arbitrary data. The on-chain aggregator contract verifies classical signatures.

• https://research.chain.link/ocr3.pdf
• https://docs.chain.link/architecture-overview/off-chain-reporting
• https://docs.chain.link/vrf

Claim: On-chain aggregator contracts verify classical signatures for OCR reports. CCIP bridge verification relies on classical signature verification across DONs and the Risk Management Network.

Coverage basis: Aggregator contracts and CCIP architecture documentation confirm classical signature verification

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: CCIP bridge verification uses classical signatures. A quantum attacker could forge cross-chain messages and mint unbacked bridged assets.

Chainlink does not have a native blockchain state-integrity layer (no native ledger). However, the on-chain verification of oracle reports and cross-chain messages constitutes a critical state-binding function that is quantum-vulnerable.

• https://docs.chain.link/architecture-overview/off-chain-reporting
• https://docs.chain.link/ccip/architecture

Claim: Chainlink's core protocol (OCR, CCIP, VRF) does not have a native privacy layer requiring ZK proofs. Confidential Compute (TEE-based) and DKG are application-layer privacy services.

Coverage basis: No native ZK proof system or shielded state in the core oracle protocol

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Application-layer privacy services (TEE-based Confidential Compute) are not assessed for quantum safety in this evaluation.

• https://blog.chain.link/how-chainlink-is-bringing-privacy-to-blockchains/

Claim: Chainlink nodes use classical cryptography (secp256k1, Ed25519) for P2P identity and peer authentication in the OCR P2P network.

Coverage basis: Core node repository confirms classical key management with no PQC alternatives

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Node P2P identity uses quantum-vulnerable classical cryptography. While node identity compromise alone does not directly enable asset theft, it enables man-in-the-middle attacks on OCR data aggregation and could facilitate consensus-level attacks.

OCR documentation states connections between oracle nodes are authenticated and encrypted. The specific transport encryption protocol is not publicly detailed but is presumed to use TLS or similar classical mechanisms.

• https://github.com/smartcontractkit/chainlink
• https://docs.chain.link/architecture-overview/off-chain-reporting

Claim: No evidence of PQ/hybrid wallet, custody, or HSM support for Chainlink node operators or LINK token holders.

Coverage basis: No PQC wallet documentation, no hardware wallet PQC support for Chainlink operations

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Node operators and LINK holders lack any PQC-enabled wallet, custody, or HSM workflow for protecting keys against quantum attacks.

Assurance: Chainlink node operators use institutional-grade key management, but all current HSM/MPC solutions rely on classical cryptography.

• https://github.com/smartcontractkit/chainlink

Claim: 0% of Chainlink-secured value and LINK token market cap is protected by PQC. No migration has occurred.

Coverage basis: No PQC protection exists in any Chainlink component; LINK token inherits host-chain vulnerability

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Chainlink secures ~$90B+ in DeFi value with zero quantum protection. LINK token market cap (~$9B+) is entirely quantum-vulnerable.

Assurance: Value-at-risk figures are approximate market estimates. The systemic value-at-risk through dependent DeFi protocols far exceeds the LINK token market cap alone.

Per QRI 9.3.1, <25% coverage scores 1 (out of 20). Chainlink is at effectively 0% coverage. The coverage score of 1 reflects the minimum floor for acknowledging the category exists.

• https://etherscan.io/token/0x514910771af9ca656af840dff83e8264ecf986ca
• https://chain.link/article/quantum-safe-cryptography

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) have been migrated to or protected by PQC.

Coverage basis: No evidence of any PQC migration for any Chainlink-related wallet or custody path

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Chainlink node operator keys, CCIP signer keys, and LINK treasury/governance wallets remain quantum-vulnerable.

Assurance: No public data on wallet migration status. Absence of evidence is treated as evidence of absence for PQC migration given the complete lack of any PQC infrastructure.

Claim: No identification, measurement, deprecation, or migration of quantum-vulnerable pools has occurred.

Coverage basis: No evidence of any legacy pool identification or deprecation process

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: No quantum-vulnerable pool inventory, measurement methodology, or deprecation policy exists.

For LINK token, all addresses that have ever sent a transaction have exposed public keys. No process exists to identify, notify, or migrate these holders.

Claim: No PQC migration roadmap exists for Chainlink. The quantum-safe article discusses crypto-agility conceptually but provides no sequencing, activation criteria, or dependencies.

Coverage basis: The quantum-safe article is educational, not a roadmap; no Chainlink-specific migration plan exists

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No PQC migration roadmap exists for any Chainlink component (OCR, CCIP, VRF, Data Feeds, node software).

The quantum-safe article mentions 'crypto-agility' and 'future-proof' design but these are aspirational statements without concrete plans, timelines, or technical specifications.

• https://chain.link/article/quantum-safe-cryptography

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist.

Coverage basis: No PQC migration tooling or user-facing migration support exists

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No migration tooling, wallet support, or user education exists for quantum-safe migration.

Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals) exist. No exchange, custody, bridge, wallet, or infrastructure coordination for PQC migration has occurred.

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 enforcement or coordination mechanisms exist to prevent unsafe fallback into quantum-vulnerable systems.

Chainlink's multi-DON architecture and cross-chain deployment make migration coordination particularly complex. Hundreds of node operators across multiple chains would need to coordinate key rotation.

Claim: Chainlink has a general bug bounty program (HackerOne, Immunefi) and security team, but no quantum-specific incident-response process is documented.

Coverage basis: General security processes exist but lack quantum-specific procedures

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: The bug bounty program and security team provide a foundation for incident response, but the absence of quantum-specific procedures is a gap.

This subfactor receives partial credit (0.25) because Chainlink's existing security infrastructure (bug bounty, security team, SOC 2 certifications) provides a baseline capability that could be extended for quantum incidents, even though no quantum-specific process is documented.

• https://chain.link/security

Claim: Chainlink uses no PQC algorithms in any production component. All cryptography is classical (ECDSA, EdDSA, secp256k1).

Coverage basis: No PQC algorithms are used anywhere in the Chainlink stack

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No NIST-standardized or standards-track PQC algorithms are used in any Chainlink production component.

• https://research.chain.link/ocr3.pdf
• https://github.com/smartcontractkit/chainlink

Claim: No PQC implementation exists to audit. Existing audits (Code4rena, NDSS, Deloitte SOC 2) cover classical security only.

Coverage basis: Existing audits do not address quantum security or PQC implementation

Implementation score: 0 · Evidence confidence: High

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

Assurance: Existing audits are high-quality for their classical scope but provide zero quantum-security assurance. Code4rena (March 2026) covers Payment Abstraction V2 smart contracts. NDSS (Feb 2026) analyzes Byzantine price manipulation in OCR. Deloitte SOC 2 (April 2026) validates operational controls. None address PQC or quantum threats.

The absence of any quantum-specific audit is expected given there is no PQC implementation to audit. This score reflects the current state: no quantum-critical scope exists to be independently reviewed.

• https://github.com/code-423n4/2026-03-chainlink
• https://www.ndss-symposium.org/wp-content/uploads/2026-f458-paper.pdf
• https://chain.link/security

Claim: Chainlink's core node software and smart contracts are open-source, but no PQC implementation exists within them.

Coverage basis: Open-source repositories contain classical cryptography only

Implementation score: 0.25 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Partial credit (0.25) reflects that the codebase is open-source and reproducible for its classical cryptography, but contains no PQC implementation to evaluate.

• https://github.com/smartcontractkit/chainlink

Claim: The quantum-safe article discusses crypto-agility conceptually, but no documented upgrade path or parameter agility specification exists for Chainlink components.

Coverage basis: Conceptual discussion of crypto-agility in the educational article only

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: The crypto-agility discussion is aspirational and not backed by technical specifications, upgrade mechanisms, or migration tooling.

Partial credit (0.25) for conceptual acknowledgment of crypto-agility as a design principle, even though no concrete upgrade path is documented.

• https://chain.link/article/quantum-safe-cryptography

Claim: No PQC signatures are used, so stateful-signature safety is not applicable.

Coverage basis: No PQC signatures deployed

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

This subfactor will become applicable if/when Chainlink deploys stateful hash-based signatures such as XMSS/LMS or SLH-DSA.

Claim: No PQC performance or resource-impact analysis exists for Chainlink's oracle networks, on-chain verification, or CCIP messaging.

Coverage basis: No PQC performance analysis has been published

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: PQC signatures are significantly larger than classical (ML-DSA-65: ~3.3KB vs ECDSA: ~72 bytes). On-chain verification costs and data availability requirements will increase substantially. No analysis of these impacts exists for Chainlink's multi-chain deployment.

This is a forward-looking gap. On-chain PQC signature verification on Ethereum and other host chains will require precompile support, which currently does not exist in production. Gas cost modeling for aggregated PQC oracle reports across EVM and non-EVM chains is an unresolved challenge.