BlackRock USD Institutional Digital Liquidity Fund BUIDL

Claim: No public cryptographic inventory or quantum threat model has been published by BlackRock or Securitize for BUIDL.

Coverage basis: Project-published inventory; none exists

Implementation score: 0 · Evidence confidence: None

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

Quantum blocker: No public cryptographic inventory; applies Readiness & Risk Cap at QRI 10

Assurance: Third-party inventories exist (EternaX, StablePQC) and are credible but are not project-published. BlackRock has acknowledged quantum risk in its Bitcoin ETF (IBIT) prospectus (May 2025) but this does not constitute a BUIDL-specific assessment.

BUIDL is not PQ-native; it started out as quantum-vulnerable. Section 9.1 full credit for PQ-native projects does not apply.

• https://eternax.com/post-quantum-exposure-map-2026 (third-party assessment identifies BUIDL as 5/5 quantum risk but is not a project-published inventory)
• https://stablepqc.com/ (third-party analysis lists BUIDL admin keys as EXPOSED)

Claim: Code is publicly verified on Etherscan and other explorers, and classical security audits exist, but no quantum-specific evidence record has been assembled by the project.

Coverage basis: Public code, classical audits, third-party quantum analysis

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: Classical smart-contract audits are current (Halborn Sep 2025) but have zero quantum-specific scope. Code is publicly verifiable. Third-party quantum analyses fill some gaps but are not project-endorsed.

Implementation Score of 0.25 reflects 'Public design, draft specification, roadmap, proposal, or research plan' — the code and audits exist as a partial evidence base but no quantum-specific evidence record has been curated by the project.

• https://etherscan.io/address/0x7712c34205737192402172409a8f7ccef8aa2aec (BUIDL proxy contract, verified)
• https://www.halborn.com/audits/securitize/dstoken-e07b34 (Halborn audit, Sep 2025)
• https://www.coinfabrik.com/blog/securitize-smart-contract-audit/ (CoinFabrik audit)
• https://forum.arbitrum.foundation/t/securitize-markets-buidl-step-application/23658 (confirms CertiK audit)

Claim: BUIDL token transfers rely entirely on host-chain ECDSA/EdDSA signatures (Ethereum secp256k1, Solana Ed25519, etc.). No PQC or hybrid-PQC spend authorization exists.

Coverage basis: Token inheritance from host chains

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All spend authorization remains ECC/EdDSA-only across all host chains

Assurance: Evidence is definitive: BUIDL is a standard ERC-20 token with no custom signature scheme. All host chains (Ethereum, Solana, Avalanche, etc.) use classical ECDSA or Ed25519 for transaction signing as of June 2026.

Per Token Inheritance rule (Section 7.2), BUIDL shares the host-chain QRI score for spend authorization.

• https://etherscan.io/token/0x7712c34205737192402172409a8f7ccef8aa2aec (standard ERC-20, no custom crypto)
• https://securitize.io/learn/press/blackrock-launches-first-tokenized-fund-buidl-on-the-ethereum-network (confirms standard token issuance)
• https://eternax.com/post-quantum-exposure-map-2026 (confirms classical cryptography dependence)

Claim: BUIDL holders use standard Ethereum addresses (and equivalents on other chains). Public keys are permanently exposed for any address that has sent a transaction. The BUIDL proxy admin key public key is permanently exposed on-chain.

Coverage basis: Host-chain address model + token-specific admin key exposure

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Admin key public key permanently exposed; all transacted holder addresses have exposed public keys (long-exposure, at-rest attack surface)

Assurance: The BUIDL proxy owner address (Securitize) has sent transactions, permanently revealing its ECDSA public key. This is a long-exposure (at-rest) attack surface per Section 7.3. Google Quantum AI's March 2026 paper estimates <500,000 physical qubits could crack such a key.

The permissioned whitelist model limits the number of holder addresses with exposed public keys, but the admin key exposure is singular and catastrophic.

• https://etherscan.io/address/0x7712c34205737192402172409a8f7ccef8aa2aec (proxy owner address has transacted; public key is permanently exposed)
• https://stablepqc.com/ (lists BUIDL Token Admin / Transfer Agent as EXPOSED with ~$1.9B AUM)
• https://eternax.com/post-quantum-exposure-map-2026 (identifies long-exposure quantum risk)

Claim: BUIDL is a token without its own consensus mechanism but depends on host-chain consensus, all of which use quantum-vulnerable validator authentication.

Coverage basis: Host-chain consensus dependency

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All host chains use quantum-vulnerable consensus mechanisms

Assurance: Applicable via host-chain dependency per QRI applicability rules: 'Token depends on an L1 or bridge security model → Host-chain or bridge dependency is applicable, not N/A.'

BUIDL has no native consensus; the subfactor is scored on host-chain inheritance.

• https://eternax.com/post-quantum-exposure-map-2026 (confirms host-chain validator key vulnerability)
• https://defillama.com/protocol/blackrock-buidl (documents multi-chain deployment)

Claim: BUIDL relies on Chronicle Proof of Assets oracle for on-chain verification of Treasury holdings. Chronicle's Scribe oracle uses Schnorr signatures on secp256k1, which are quantum-vulnerable. Token contract state integrity also depends on admin keys which are quantum-vulnerable.

Coverage basis: Oracle dependency + admin key dependency

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Chronicle oracle attestations rely on quantum-vulnerable Schnorr (secp256k1) signatures

Assurance: Chronicle's Scribe oracle source code is public (GitHub: chronicleprotocol/scribe). The Schnorr signature verification in Scribe.sol explicitly uses secp256k1 curve operations via ecrecover. There is no PQC path for this oracle dependency.

A quantum attacker who breaks the Schnorr signature scheme could forge Proof of Assets attestations, misrepresenting the fund's underlying Treasury holdings.

• https://cryptorank.io/news/blackrocks-buidl-fund-embraces-chronicle-for-unprecedented-verification-of-tokenized-treasury-assets (Chronicle Proof of Assets integration)
• https://github.com/chronicleprotocol/scribe/blob/main/docs/Schnorr.md (Chronicle uses Schnorr on secp256k1 — quantum-vulnerable)
• https://www.businesswire.com/news/home/20260326402329/en/BUIDL-tokenized-by-Securitize-is-now-verified-onchain-by-Chronicle-Proof-of-Asset (confirms Chronicle integration, $2.1B AUM)

Claim: BUIDL has no privacy layer; all token balances and transfers are publicly visible on standard blockchains.

Coverage basis: No privacy architecture exists

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: BUIDL is a smart-contract token with no P2P network layer of its own.

Coverage basis: Token architecture — no P2P layer exists

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: Admin key custody uses Fireblocks MPC (ECDSA-based) with Intel SGX enclaves. No PQC signing path exists for Fireblocks-custodied keys in production. No hardware wallet or HSM workflow supports PQ signatures for BUIDL.

Coverage basis: Custody infrastructure supporting admin keys

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Fireblocks MPC uses ECDSA-based threshold signing; no PQC production path exists

Assurance: Fireblocks has publicly stated PQC is a 'strategic priority' and is 'actively building our roadmap' (March 2026 blog post), but no production PQC signing path is available today. MPC key shares are protected by Intel SGX enclaves, which provide hardware isolation but do not change the underlying ECDSA quantum vulnerability.

The MPC architecture distributes key shares but the underlying signature scheme remains ECDSA on secp256k1. A quantum attacker who can break ECDSA can forge signatures regardless of how key shares are distributed.

• https://www.fireblocks.com/blog/securitize-integrates-fireblocks-to-improve-its-security-in-the-tokenization-of-real-world-assets (Fireblocks MPC for Securitize)
• https://www.fireblocks.com/blog/google-quantum-research-institutional-crypto-security (Fireblocks PQC research; no production PQC signing)
• https://github.com/stakingrewards/defi-risk-rating/blob/master/ratings/BlackRock-BUIDL.md (confirms single owner address via Fireblocks MPC; no on-chain multisig)

Claim: Zero percent of BUIDL's ~$2.5B AUM is protected from quantum key-recovery attacks. All value is held through quantum-vulnerable host-chain accounts, admin keys, oracle dependencies, and bridge infrastructure.

Coverage basis: Total AUM across all chain deployments

Implementation score: 0.05 · Evidence confidence: Medium

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

Quantum blocker: <25% coverage: ~$2.5B AUM entirely quantum-vulnerable with no protection or migration path

Assurance: AUM data from T2/T3 sources (DefiLlama, CryptoRank, Eco, RWA.xyz); no T1 real-time verification available. Specific allocation across chains is not publicly disclosed in real time. Exact figure is estimated at $2.1-2.9B depending on source and date. All sources agree the value is substantial and none indicate any quantum protection.

Coverage threshold <25% maps to score 1 out of 20 per Section 9.3.1. BUIDL is not PQ-native; all native value exists through quantum-vulnerable paths. Off-chain assets at BNY Mellon provide a legal backstop but the tokenized on-chain ownership representation remains fully quantum-vulnerable.

• https://defillama.com/protocol/blackrock-buidl (TVL and chain distribution)
• https://cryptorank.io/news/blackrocks-buidl-fund-embraces-chronicle-for-unprecedented-verification-of-tokenized-treasury-assets ($2.1B AUM as of March 2026)
• https://eco.com/support/en/articles/15254013-buidl-deep-dive-2026 (~$2.5B AUM as of May 2026 across six+ chains)
• https://eternax.com/post-quantum-exposure-map-2026 (5/5 quantum risk rating)

Claim: The BUIDL proxy admin wallet (Securitize) is not migrated or protected. It uses Fireblocks MPC with ECDSA on secp256k1.

Coverage basis: Admin/upgrade key custody

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Admin wallet not quantum-protected; single point of failure for ~$2.5B AUM

Assurance: The on-chain owner address is known and has transacted, permanently exposing its ECDSA public key. Fireblocks MPC distributes key shares across three environments (customer server, Fireblocks server, disaster recovery) with Intel SGX enclaves, but the underlying signature scheme remains ECDSA — quantum-vulnerable.

No on-chain multisig or timelock exists. The proxy's setTarget() and setOwner() functions are restricted to onlyOwner, which on-chain is a single address.

• https://etherscan.io/address/0x7712c34205737192402172409a8f7ccef8aa2aec (single owner address; no multisig on-chain)
• https://www.fireblocks.com/blog/securitize-integrates-fireblocks-to-improve-its-security-in-the-tokenization-of-real-world-assets (Fireblocks MPC integration)
• https://github.com/stakingrewards/defi-risk-rating/blob/master/ratings/BlackRock-BUIDL.md (score S-KM-01: single owner, 1/9 rating)

Claim: No identification, measurement, deprecation, or migration of quantum-vulnerable accounts or contracts has been published.

Coverage basis: Project-published identification; none exists

Implementation score: 0 · Evidence confidence: None

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

Assurance: No public work product from BlackRock or Securitize addresses legacy vulnerable account identification for BUIDL. The whitelist model means the set of holder addresses is known to Securitize but has not been published in a quantum-risk context.

BUIDL is not PQ-native and was not designed to prevent quantum-vulnerable ownership paths. The whitelist is known to the administrator but no public quantum-vulnerability analysis of those addresses exists.

Claim: No public migration or protection roadmap exists for BUIDL. No PQC transition plan has been published by BlackRock or Securitize.

Coverage basis: Project-published roadmap; none exists

Implementation score: 0 · Evidence confidence: None

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

Assurance: Third-party confirmation of absence of roadmap. BlackRock and Securitize have made no public statements about PQC plans for BUIDL.

BUIDL is not PQ-native so Section 7.1 roadmap exemption does not apply. A roadmap is expected but absent.

• https://eternax.com/post-quantum-exposure-map-2026 (notes 'No end-to-end post-quantum roadmap has been disclosed for the BUIDL institutional programme')

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, or migration prompts exist for BUIDL.

Coverage basis: None implemented

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No PQ migration accessibility exists for any BUIDL holder or administrator

Assurance: BUIDL onboarding is gated through Securitize's institutional portal with KYC/AML and whitelisting. Wallet options (Fireblocks, Anchorage Digital, BitGo, self-custody) all use classical ECDSA-based signing. No PQ wallet option is available.

BUIDL is not PQ-native; the absence of PQ migration accessibility is a genuine gap, not a note-only caveat.

• https://etherscan.io/token/0x7712c34205737192402172409a8f7ccef8aa2aec (standard ERC-20; no PQ features)
• https://eco.com/support/en/articles/15254013-buidl-deep-dive-2026 (documents whitelist-based onboarding through Securitize with no PQ options)

Claim: No enforcement mechanisms exist for quantum-safe migration. No coordination framework with exchanges, custodians, bridges, or wallets has been established.

Coverage basis: None implemented

Implementation score: 0 · Evidence confidence: High

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

Assurance: No public evidence of any coordination activity. The multi-party architecture (BlackRock, Securitize, Fireblocks, Chronicle, Wormhole, BNY Mellon, multiple L1/L2 foundations) means migration coordination would be extraordinarily complex.

Claim: BlackRock operates a Vulnerability Disclosure Program on HackerOne but no quantum-specific incident-response plan has been published. No governance process specific to quantum vulnerabilities exists.

Coverage basis: General VDP only; no quantum-specific IR

Implementation score: 0 · Evidence confidence: Low

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

Assurance: BlackRock's VDP is a general corporate program, not BUIDL-specific or quantum-specific. Under QRI v3.1 Note-Only Caveat Rule, the absence of a formal quantum-specific IR playbook is a note-only caveat since it does not create a new quantum-vulnerable path beyond what already exists. The score is 0.00 because there is no quantum-specific process, not because the absence of one creates a new vulnerability.

This is scored as 0.00 because no quantum-specific process exists, but per v3.1 rules this is treated as an assurance-only caveat (does not independently cap or reduce the score beyond the already-applied 0.00).

• https://hackerone.com/blackrock (general BlackRock VDP)
• https://www.blackrock.com/us/individual/compliance/responsible-disclosure (responsible disclosure policy)

Claim: No PQC or hybrid-PQC algorithms are used anywhere in the BUIDL stack.

Coverage basis: No PQC implementation exists

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No NIST-standardized PQC algorithms in use across any layer

Assurance: NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. None are used in BUIDL's architecture.

• https://etherscan.io/address/0x7712c34205737192402172409a8f7ccef8aa2aec (standard Solidity contract; no PQC)
• https://github.com/chronicleprotocol/scribe/blob/main/docs/Schnorr.md (Chronicle uses Schnorr on secp256k1, not PQC)

Claim: Multiple classical smart-contract audits exist (Halborn, CoinFabrik, CertiK) but none cover post-quantum cryptography or quantum threat models.

Coverage basis: Classical audits only; no quantum-specific audit

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Audits are current for classical security (Halborn Sep 2025 covers the current DSToken framework). However, they have zero quantum-specific scope. Under v3.1, stale or scope-mismatched audits affect confidence, not the QRI Score, unless they make a quantum-critical property unverifiable. Here, the score is 0.00 because no quantum-critical implementation exists to audit, not because audits are missing.

Implementation Score of 0.00 reflects that no quantum-specific audit exists. The classical audits are noted for confidence context. Per v3.1, audit gaps that don't affect quantum-attack readiness verification are primarily confidence/assurance issues.

• https://www.halborn.com/audits/securitize/dstoken-e07b34 (Halborn audit, Sep 2025 — classical scope only)
• https://www.coinfabrik.com/blog/securitize-smart-contract-audit/ (CoinFabrik audit — classical scope only)
• https://forum.arbitrum.foundation/t/securitize-markets-buidl-step-application/23658 (confirms CertiK audit — classical scope only)

Claim: BUIDL smart contracts are verified on Etherscan and other chain explorers with public source code.

Coverage basis: Publicly verified contracts on block explorers

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Source code is publicly available and verifiable on Etherscan and other block explorers. The implementation is a standard OpenZeppelin-based upgradeable proxy pattern. This full score reflects code availability, not quantum security.

Open-source code availability is scored independently of quantum readiness. The contracts are verifiable and reproducible.

• https://etherscan.io/address/0x7712c34205737192402172409a8f7ccef8aa2aec (verified Solidity source code, v0.8.13)
• https://github.com/stakingrewards/defi-risk-rating/blob/master/ratings/BlackRock-BUIDL.md (confirms contracts verified across chains, score O-DT-06: 9/9)

Claim: No documented parameter agility or PQC upgrade path exists for BUIDL or its dependent infrastructure.

Coverage basis: No PQC upgrade documentation

Implementation score: 0 · Evidence confidence: None

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

Assurance: No public documentation addresses how BUIDL's smart contracts, admin keys, oracle dependencies, or bridge infrastructure could be upgraded to PQC. The proxy upgrade pattern (setTarget) provides a technical mechanism for contract upgrades but no PQC-specific plan exists.

The proxy pattern provides a theoretical upgrade path but without any documented PQC plan, parameter choices, or migration sequence.

Claim: No PQC stateful signatures (XMSS/LMS) are in use, so stateful-signature safety considerations are not applicable to current production.

Coverage basis: No stateful PQC signatures deployed

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

This subfactor would become applicable if BUIDL or its dependencies adopt XMSS/LMS-style stateful hash-based signatures.

Claim: No performance or resource-impact analysis for PQC deployment has been published for BUIDL.

Coverage basis: No PQC performance analysis

Implementation score: 0 · Evidence confidence: None

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

Assurance: Per v3.1 Note-Only Caveat Rule, the absence of a formal performance benchmark is normally a note-only caveat unless it prevents safe use of PQ controls. Here, the score is 0.00 because no PQC work exists at all, not because a benchmark is missing. If PQC work existed, missing benchmarks would be a confidence/assurance note only.

BUIDL's multi-chain architecture means PQC signature sizes (ML-DSA: ~2.4 KB vs ECDSA: 64 bytes) would have significant gas cost implications on Ethereum and other chains. No analysis of this exists.