Pre-release notice:
The Quantum Readiness Index is still being reviewed and refined. Reports may include rough edges, including incomplete and/or incorrect coverage.

tokenized asset

Blockchain Capital BCAP

BCAP is a tokenized security (ERC-20) representing fractional interest in Blockchain Capital III Digital Liquid Venture Fund, issued via Securitize and now operating on ZKsync Era. It has no independent cryptographic layers, consensus, P2P, or privacy mechanisms. Per QRI Section 7.2 (Token Inheritance), BCAP inherits the base-layer QRI posture of its host chain (ZKsync Era, Migration Stage 1 / QRI 28 per LayerQu v3.1.0). The token-specific quantum-critical risks are: (1) admin/issuer keys controlled by Securitize/Blockchain Capital with mint, freeze, and unfreeze powers — presumed ECDSA-secured with no PQC protection; (2) custody keys at Anchorage Digital Bank and Coinbase Custody — similarly vulnerable; and (3) complete dependence on ZKsync Era, which has no production PQC transaction protection and relies on pairing-based SNARK wrappers for L1 settlement. Neither Blockchain Capital nor Securitize has published a quantum risk assessment, cryptographic inventory, or migration plan for BCAP. The project scores 1/100 (Stage 1: Quantum Risk Assessed), reflecting zero production PQ protection across all applicable layers and negligible migration coverage (score of 1/20 from the <25% coverage tier for the small protected value-at-risk from hash-based components of the host chain's STARK core).

Not AssessedToken InheritanceRoadmap OnlyAdmin-Key Dependent
Stage 1
Confidence Medium
Urgency [Migration Required]
Review Status Draft
Evaluated 2026-06-01
Scope Tokenized security (ERC-20) representing economic interest in Blockchain Capital III Digital Liquid Venture Fund, issued via Securitize. Token-specific admin/governance keys and custody arrangements evaluated alongside host-chain (ZKsync Era / Ethereum) cryptographic inheritance per QRI Section 7.2.
AI-generated report. This report was produced by the evaluator and synthesis pipeline. Review status: draft.

Category breakdown

QRI Factors

Algorithm & Implementation Assurance 0 / 20
Migration Mechanism, Governance & Ecosystem Coordination 0 / 15
Migration Status & Value-at-Risk 1 / 25
Production Cryptographic Protection 0 / 35
Security Assessment & Evidence Preparedness 0 / 5

Critical Quantum Blockers

  • No public cryptographic inventory or quantum threat model published for the BCAP token by Blockchain Capital, Securitize, or any affiliated entity.
  • Token admin/issuer keys (freeze, unfreeze, mint) controlled by Securitize/Blockchain Capital are presumed ECDSA-secured with no evidence of PQC or hybrid-PQC protection. Compromise would enable unlimited token minting, global freeze, and fund seizure.
  • Institutional custody keys at Anchorage Digital Bank and Coinbase Custody are presumed ECDSA-secured with no production PQC deployment evidenced for BCAP.
  • Host chain ZKsync Era has no production PQC protection for user transaction signatures; its on-chain verification depends on pairing-based SNARK wrappers (BN254) vulnerable to Shor's algorithm.

Key Risks

  • Admin key compromise: The tokenIssuer address (controlled by Securitize/Blockchain Capital) can mint unlimited tokens, freeze any holder, and unfreeze accounts. If secured by standard ECDSA keys, a quantum attacker could derive the private key from on-chain transaction signatures and gain full control over the token supply and transfer restrictions.
  • Custody key compromise: Anchorage Digital Bank and Coinbase Custody hold BCAP in custody for institutional holders. Both use ECDSA-based key management with no production PQC deployment evidenced. Compromise of custody keys could enable theft of custodied BCAP.
  • Host chain dependency: ZKsync Era's security depends on (a) ECDSA transaction signatures, (b) pairing-based SNARK wrappers (BN254) for on-chain proof verification, and (c) Ethereum L1 settlement. All three layers are quantum-vulnerable. A break in any layer could compromise BCAP token state integrity, transaction authorization, or bridge/withdrawal security.
  • Legacy Ethereum exposure: The original BCAP contract on Ethereum (0x1f41e42d0a9e3c0dd3ba15b527342783b43200a9) may still hold value or be interactable. Unmigrated tokens on Ethereum face the full quantum vulnerability of Ethereum's ECDSA account model.
  • No migration path: There is no public plan, mechanism, or timeline for migrating BCAP admin keys, custody keys, or token contracts to post-quantum cryptography. In a Q-day scenario, BCAP holders would depend entirely on Securitize, Anchorage, and Coinbase executing an unplanned emergency migration.
  • Concentration of control: BCAP's compliance-driven centralized admin powers (mint, freeze, unfreeze) mean a single quantum-compromised key could affect the entire token supply. This is a higher-impact attack surface than decentralized tokens where compromise affects only individual holders.

Assurance Notes

  • The only independent audit is a 2017 OpenZeppelin review of the original Ethereum ERC-20 contract (Solidity v0.4.25). It predates the 2024 ZKsync migration and does not cover the current production contract on ZKsync Era. The audit confirmed centralized admin controls (tokenIssuer with freeze/unfreeze/mint powers) and recommended multisig and key-escrow protection.
  • No quantum-specific audit, cryptographic inventory, or threat model has been published by Blockchain Capital, Securitize, or any affiliated entity for the BCAP token.
  • Custody is provided by Anchorage Digital Bank and Coinbase Custody. Neither has publicly confirmed production deployment of post-quantum signature schemes for BCAP custody as of the evaluation date. Anchorage published a research paper (Quantum Turnstile, March 2026) describing a STARK-based migration mechanism for hash-committed key systems; this is research only and does not apply to BCAP's admin key architecture where public keys are already exposed. Coinbase confirmed a multi-year PQC program (May 2026) but has no production PQ custody deployment.
  • BCAP inherits ZKsync Era's quantum security posture. ZKsync Era is assessed at Migration Stage 1 (Acknowledged, Architected substrate) / QRI 28/100 by LayerQu v3.1.0 (ratified 2026-05-01). ZKsync's Boojum proof system uses a STARK-oriented core but wraps with a pairing-based SNARK for on-chain Ethereum L1 verification; the on-chain verifier sits behind an upgradeable proxy with multisig governance.
  • The original Ethereum BCAP contract at 0x1f41e42d0a9e3c0dd3ba15b527342783b43200a9 remains deployed on-chain. The migration status of all legacy token holders to ZKsync is not publicly verified. No public freeze or deprecation policy for legacy tokens has been published.
  • Google Quantum AI's March 2026 research paper identified approximately 70 of the top 500 Ethereum smart contracts by ETH balance as vulnerable to quantum key derivation through admin keys using industry-standard patterns including OpenZeppelin's Ownable and ERC-1967 proxy standards. BCAP's admin controls fall within this class of vulnerability.

Non-Scoring Caveats

  • The 2017 OpenZeppelin audit is stale (9+ years old) and covers the original Ethereum deployment, not the current ZKsync Era deployment. Per QRI Section 6.4, a stale but relevant audit does not reduce the QRI Score by itself when quantum-critical properties are independently verifiable from token design and host-chain properties.
  • Legacy Ethereum BCAP tokens at 0x1f41e42d0a9e3c0dd3ba15b527342783b43200a9 may still exist with unmigrated holders. No public freeze, deprecation, or migration attestation confirms complete migration.
  • ZKsync Era's roadmap includes protocol upgrades (Atlas upgrade, Gateway migration) but none address post-quantum migration of the proof system or L1 settlement contracts. This is a host-chain operational note, not a BCAP-specific scoring factor.
  • Anchorage Digital's Quantum Turnstile research (March 2026) proposes a STARK-based migration mechanism for hash-committed key systems. It is research only and does not apply to BCAP's admin key architecture where public keys have already been exposed through on-chain transactions.
  • Coinbase's multi-year PQC program (confirmed May 2026) is in early stages with no production PQ custody deployment. Timeline is unspecified.
  • BCAP is a regulated security token with transfer restrictions, KYC/AML requirements, and compliance infrastructure (Securitize DS Protocol). These compliance layers add operational constraints that may slow any quantum migration but are outside QRI scope.
  • Market capitalization estimates vary across sources (~$19M–$25M). Value-at-risk assessment uses the full market cap as all tokens are on quantum-vulnerable chains with no protection.
  • ZKsync Era's Boojum proof system has a STARK-oriented core that is architecturally favorable for PQ migration, but the SNARK wrapper for L1 settlement carries Shor-vulnerable pairing-based assumptions. The on-chain verifier's upgradeable proxy provides a theoretical upgrade path, but no concrete PQ migration timeline has been published.

Evidence record

Claims and Caveats

Security Assessment & Evidence Preparedness

Public cryptographic inventory and quantum threat model

Claim: No public cryptographic inventory or quantum threat model has been published by Blockchain Capital, Securitize, or any affiliated entity for the BCAP token.

Coverage basis: Absence of quantum-specific assessment; confirmed by exhaustive web search across blockchaincapital.com, securitize.io, GitHub, and primary sources.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: No public cryptographic inventory; project has not acknowledged or assessed quantum risk for BCAP.

Assurance: Absence of evidence confirmed via search of official websites, GitHub, and secondary sources. BCAP is not PQ-native; the token was launched on Ethereum in 2017 with standard ECDSA security.

Security Assessment & Evidence Preparedness

Public evidence record supporting assessment

Claim: No public evidence record (code references, specs, audits, transaction examples, or reproducible analytics) supporting a quantum assessment for BCAP exists.

Coverage basis: Absence of quantum-specific evidence record.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: No quantum-specific evidence record exists because no quantum assessment has been conducted for BCAP.

Production Cryptographic Protection

Spend authorization / transaction signatures

Claim: BCAP token transfers are authorized via ZKsync Era transaction signatures, which are ECDSA-based (secp256k1). No PQC or hybrid-PQC spend authorization exists.

Coverage basis: Token inherits host-chain transaction signing; ZKsync Era has no production PQC signature support.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All BCAP transaction authorization relies on ECDSA via ZKsync Era; no PQC path exists.

Assurance: ZKsync Era QRI confirmed by independent LayerQu assessment at 28/100 (Stage 1). ECDSA-only spend authorization is a well-established fact for ZKsync Era mainnet.

Production Cryptographic Protection

Account/address/public-key exposure design

Claim: BCAP inherits ZKsync/Ethereum account model. EOAs that have sent transactions have permanently exposed ECDSA public keys on-chain. No PQ/hybrid account controls exist.

Coverage basis: Host-chain account model; ZKsync Era inherits Ethereum's EOA design where public keys are revealed on first transaction.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The Ethereum/ZKsync account model is well-documented. EOAs reveal public keys on first spend; this is a permanent, harvestable attack surface. Admin key addresses (Securitize/Blockchain Capital) have certainly transacted, exposing their public keys permanently.

Production Cryptographic Protection

Consensus-critical authentication

Claim: BCAP is a token with no consensus mechanism. Subfactor is not applicable.

Coverage basis: N/A

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Host-chain consensus vulnerability is captured under token inheritance and host-chain dependency risk. Token-specific scoring excludes this layer.

Production Cryptographic Protection

State-integrity and data-availability mechanisms

Claim: BCAP token state (balances, allowances) is stored in standard ERC-20 contract storage. No custom state-integrity, commitment, nullifier, accumulator, or data-availability mechanism exists at the token level.

Coverage basis: Standard ERC-20 storage; all state-integrity guarantees are inherited from ZKsync Era's execution and proof system.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Host-chain state integrity (ZKsync Era) depends on Boojum proof system with SNARK wrapper using pairing-based cryptography (BN254). This is captured as a host-chain dependency risk rather than a token-specific subfactor.

Production Cryptographic Protection

Privacy and proof layers

Claim: BCAP has no privacy layer, shielded transactions, ZK proofs, note encryption, viewing keys, or stealth addresses.

Coverage basis: N/A

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Production Cryptographic Protection

P2P transport, node identity, and peer authentication

Claim: BCAP is a token with no P2P network layer.

Coverage basis: N/A

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Production Cryptographic Protection

Critical wallet, custody, HSM, and hardware-wallet workflows

Claim: BCAP custody is provided by Anchorage Digital Bank and Coinbase Custody. Neither has publicly confirmed production deployment of PQC or hybrid-PQC signature schemes for BCAP custody. Custody keys are presumed ECDSA-secured.

Coverage basis: Custody providers use classical ECDSA/EdDSA key management with no production PQC deployment evidenced.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Custody keys at Anchorage Digital Bank and Coinbase Custody are presumed ECDSA-secured with no production PQC deployment.

Assurance: RWA.xyz confirms custody providers. Anchorage published a research paper (Quantum Turnstile, March 2026) proposing a STARK-based migration mechanism for hash-committed keys, but this is research only and does not apply to exposed-key scenarios like BCAP admin addresses. Coinbase confirmed a multi-year PQC program in May 2026 but has no production PQ custody deployment.

Migration Status & Value-at-Risk

Percentage of value-at-risk protected

Claim: Approximately 0% of BCAP's ~$19M–$25M market capitalization is protected from quantum key-recovery attacks. All tokens exist on quantum-vulnerable infrastructure with no PQC protection at any layer.

Coverage basis: Full market cap remains on ZKsync Era (ECDSA transaction signatures, pairing-based SNARK wrappers, Ethereum L1 settlement). No PQ-protected value pool exists.

Implementation score: 0.05 · Evidence confidence: Medium

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

Quantum blocker: 0% of BCAP value-at-risk is quantum-protected. All value resides on quantum-vulnerable infrastructure.

Assurance: Market cap estimates vary across sources (~$19M at STO Market, ~$25M reported elsewhere). BCAP is not PQ-native; it was launched on Ethereum in 2017 with classical ECDSA and has no native PQ ownership namespace. Coverage <25% maps to Implementation Score 0.05 per QRI Section 9.3.1.

Migration Status & Value-at-Risk

Critical wallets migrated or protected

Claim: No critical BCAP wallets (treasury, issuer, custody, exchange) have been migrated to PQC or hybrid-PQC. The tokenIssuer admin address, Securitize operational keys, Anchorage custody keys, and Coinbase Custody keys all remain on ECDSA.

Coverage basis: All critical wallets use classical ECDSA/EdDSA with no evidence of PQC migration.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Admin key (tokenIssuer) controls mint, freeze, and unfreeze; Anchorage and Coinbase custody keys control institutional holdings. None have PQC protection.

Assurance: The 2017 audit explicitly recommended multisig and key-escrow for the tokenIssuer address. Whether this was implemented is unknown but does not change quantum vulnerability — multisig of ECDSA keys remains quantum-vulnerable.

Migration Status & Value-at-Risk

Legacy vulnerable pools identified and addressed

Claim: No identification, measurement, deprecation, freezing, or migration of legacy vulnerable BCAP pools has been published. The original Ethereum contract (0x1f41e42d0a9e3c0dd3ba15b527342783b43200a9) may still hold tokens or be interactable.

Coverage basis: No evidence of legacy pool identification or deprecation.

Implementation score: 0 · Evidence confidence: Low

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

Quantum blocker: Legacy Ethereum BCAP tokens may remain unmigrated and vulnerable; no inventory or deprecation policy exists.

Assurance: The 2018 Securitize upgrade and 2024 ZKsync migration suggest most tokens should have been migrated, but no public attestation confirms 100% migration or freezing of legacy tokens.

Migration Mechanism, Governance & Ecosystem Coordination

Public migration or protection roadmap

Claim: No public quantum migration or protection roadmap exists for BCAP. Neither Blockchain Capital, Securitize, nor any affiliated entity has published a quantum-readiness plan for the token.

Coverage basis: Absence of any quantum migration roadmap.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: BCAP is not PQ-native; a migration roadmap is expected. Per QRI Section 7.2, token-specific admin/governance keys require independent evaluation. No roadmap exists.

Migration Mechanism, Governance & Ecosystem Coordination

Migration accessibility and defaults

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

Coverage basis: No migration tooling or user-facing migration support.

Implementation score: 0 · Evidence confidence: High

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

Assurance: No migration tooling exists because no quantum migration has been planned or implemented for BCAP.

Migration Mechanism, Governance & Ecosystem Coordination

Migration enforcement and coordination

Claim: No enforcement mechanisms, deprecation timelines, legacy signing disablement, withdrawal restrictions, unsafe-path blocking, or exchange/custody coordination exist for BCAP quantum migration.

Coverage basis: No enforcement or coordination mechanisms.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The centralized nature of BCAP (Securitize admin controls, compliance infrastructure) could theoretically enable faster enforcement than decentralized tokens, but no such enforcement has been planned or announced.

Migration Mechanism, Governance & Ecosystem Coordination

Emergency disclosure and incident-response process

Claim: No quantum-specific vulnerability disclosure, incident-response, or governance process has been published for BCAP.

Coverage basis: Absence of quantum-specific incident-response process.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Per QRI Section 8.2, the absence of a formal quantum-specific incident-response playbook does not create a Readiness & Risk Cap by itself. It is recorded as an assurance caveat. However, the absence is notable given BCAP's reliance on centralized admin keys.

Algorithm & Implementation Assurance

Uses NIST-standardized or broadly reviewed PQC algorithms

Claim: BCAP uses no PQC or hybrid-PQC algorithms. All token security relies on classical ECDSA via the host chain and classical key management by custodians.

Coverage basis: No PQC algorithms in use at any layer of the BCAP token ecosystem.

Implementation score: 0 · Evidence confidence: High

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

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

Algorithm & Implementation Assurance

Independent cryptographic and implementation audit

Claim: The only audit is the 2017 OpenZeppelin/Manuel Araoz audit of the original Ethereum BCAP token contract. No audit covers the current ZKsync deployment or any quantum-critical implementation (none exists).

Coverage basis: Stale audit (2017) of Ethereum contract only; no quantum-critical implementation to audit.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The 2017 audit identified centralized admin controls and recommended multisig/key-escrow. It did not address quantum threats. Per QRI Section 6.4, a stale but relevant audit does not reduce the QRI Score by itself when quantum-critical properties are independently verifiable.

Algorithm & Implementation Assurance

Open-source, reproducible implementation

Claim: The original Ethereum BCAP token contract is open-source and verified on Etherscan. The ZKsync deployment is accessible via block explorer. However, no PQC implementation exists to be open-source.

Coverage basis: Token contract is open-source; no PQC implementation exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: This subfactor measures openness of quantum-critical implementation. Since no PQC implementation exists, the score is 0.00. The token's standard ERC-20 code is open-source but quantum-irrelevant.

Algorithm & Implementation Assurance

Parameter agility and future upgrade path

Claim: No documented parameter agility or cryptographic upgrade path exists for BCAP. The token contract includes proxy/upgrade patterns (noted in Etherscan) but no quantum-specific upgrade planning.

Coverage basis: No quantum-specific upgrade path documented.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: The token uses a proxy pattern (noted on Etherscan), which provides upgrade capability. However, no quantum-specific upgrade path has been documented.

Algorithm & Implementation Assurance

Stateful-signature safety and side-channel considerations

Claim: No PQC signatures are in use; stateful-signature safety considerations are not applicable to current BCAP production scope.

Coverage basis: N/A — no PQC signatures deployed.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Algorithm & Implementation Assurance

Performance and resource-impact analysis

Claim: No PQC signatures are deployed; performance analysis of PQ signature/verification costs is not applicable to current BCAP production scope.

Coverage basis: N/A — no PQC deployed.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Report metadata

Generation Details