tokenized asset
Spiko EU T-Bills Money Market Fund EUTBL
Spiko EU T-Bills Money Market Fund (EUTBL) is a ~$1B regulated tokenized RWA deployed across 7 chains with zero post-quantum cryptographic protection. All transaction authorization, admin key operations, bridge signing, and permit signatures rely entirely on classical ECDSA (EVM chains) or Ed25519 (Stellar). No PQC features exist in production, testnet, roadmap, or proposal form. The project has not published a quantum risk assessment or cryptographic inventory. However, as a KYC-gated UCITS fund with centralized issuer control (freeze, upgrade, reissue capabilities), EUTBL qualifies for the PQ-Recoverable tag: the issuer can legally reconstruct the ledger off-chain and re-deploy on a quantum-secure infrastructure after an attack. This recoverability is a meaningful mitigant but does not constitute quantum resistance—it does not prevent quantum-enabled theft, unauthorized minting, or bridge compromise in the current production system. Score: 6.33/100 (Stage 1: Quantum Risk Assessed, Medium confidence).
PQ-RecoverableToken InheritanceClassical OnlyCentralized IssuerTokenized RWA
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
3.33 / 20
Migration Mechanism, Governance & Ecosystem Coordination
0 / 15
Migration Status & Value-at-Risk
1 / 25
Production Cryptographic Protection
0 / 35
Security Assessment & Evidence Preparedness
2 / 5
Critical Quantum Blockers
- Active production spend authorization is entirely ECDSA/EdDSA-only across all deployed chains. All ~$1B in token value is controlled by quantum-vulnerable classical signatures with no PQC or hybrid migration path deployed, proposed, or roadmapped.
- Token admin keys (super-admin multisig, daily-operator, exceptional-operator) rely on classical ECC and control minting, burning, pausing, upgrading, and permission management. Compromise by a quantum adversary enables unauthorized minting and supply inflation.
- Chainlink CCIP bridge for cross-chain transfers relies on classical threshold signatures/multisigs; bridge authorities represent a high-value quantum target.
- No public cryptographic inventory, quantum threat model, or quantum risk assessment has been published by the project.
- StarkNet deployment introduces additional classical cryptographic dependencies through the StarkNet L2 architecture.
Key Risks
- QUANTUM-CRITICAL: All ~$1B in EUTBL token value across 7 chains is secured exclusively by ECDSA/EdDSA signatures. A Cryptographically Relevant Quantum Computer (CRQC) capable of breaking secp256k1 or Ed25519 can forge spend authorization for any EOA that has ever sent a transaction, or any Stellar account with a revealed public key.
- QUANTUM-CRITICAL: The super-admin multisig (governing UUPS upgrades, permission management, minting, burning, pausing) is classical-ECC-based. Quantum compromise enables infinite unauthorized minting and supply inflation across all chains.
- QUANTUM-CRITICAL: The Chainlink CCIP bridge signer set uses classical threshold signatures. Quantum compromise of the bridge allows unauthorized cross-chain minting of EUTBL on destination chains.
- QUANTUM-CRITICAL: ERC-2612 permit signatures (gasless approvals) use ECDSA and are quantum-vulnerable, enabling unauthorized spending approvals.
- QUANTUM-CRITICAL: ERC-2771 meta-transaction forwarder relies on classical ECDSA signatures.
- QUANTUM-CRITICAL: StarkNet deployment adds L2-specific classical cryptographic dependencies (StarkNet's own bridging and proof system).
- ASSURANCE: The Trail of Bits audit (2023) predates any potential PQC considerations and provides no quantum-security assurance. The Halborn Stellar audit (2025) is current for classical code but similarly quantum-unaware.
- OPERATIONAL: No public quantum migration plan, cryptographic inventory, or quantum threat model exists. The regulated entity structure provides legal recovery pathways but no technical quantum protection.
Assurance Notes
- Trail of Bits audit (October 2023) is stale but relevant for classical smart-contract code quality; it does not address quantum security at all.
- Halborn Stellar contracts audit (October 2025) is more current but also limited to classical code review with no quantum scope.
- No independent quantum-specific cryptographic audit exists for any component.
- The UUPS proxy was deployed April 2024 with a single upgrade event; the implementation contract behind the proxy is verified on Etherscan.
- The super-admin multisig configuration (signer count, threshold, key custody) is not publicly documented in detail.
- No formal quantum-specific incident-response playbook or disclosure process exists, though the project publishes a security contact (security@spiko.tech) and is a regulated financial institution under AMF supervision.
- As a regulated UCITS fund with KYC-gated allowlisting, the issuer has strong off-chain legal and operational recoverability—this does not constitute quantum resistance but is a meaningful mitigant noted in tags.
- Multi-chain deployment across 7 networks expands the quantum-vulnerable attack surface and coordination complexity for any future migration.
- Chainlink CCIP bridge dependency introduces classical threshold signature risk for cross-chain transfers.
Non-Scoring Caveats
- The stale Trail of Bits audit (2023) does not reduce the QRI Score because the classical-only nature of the implementation is independently verifiable from public code and block explorers; the audit age affects Confidence, not the cryptographic readiness score.
- The absence of a formal quantum-specific incident-response playbook is an operational gap recorded in Assurance & Review Notes; it does not create a new quantum-attack path beyond those already identified.
- Future roadmap uncertainty (possible future PQ upgrade) does not reduce the current score because no current production protection exists to evaluate.
- The centralized KYC-gated recoverability model is noted as a meaningful mitigant (PQ-Recoverable tag) but does not earn production-protection credit because it does not prevent quantum-enabled theft—it only enables post-attack recovery.
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 Spiko. The project's cryptographic mechanisms are inferable from open-source code (ECDSA on EVM chains, Ed25519 on Stellar) but have not been formally inventoried or assessed in a quantum context.
Coverage basis: Open-source code and verified contracts reveal the cryptographic primitives but no structured inventory or quantum threat model document exists.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: No public cryptographic inventory or quantum threat model published by the project.
Assurance: Cryptographic primitives are clearly identifiable from open-source Solidity code and Etherscan-verified contracts. Absence of a formal inventory is confirmed by searching all official Spiko channels.
EUTBL is not PQ-native; Section 7.1 full-credit rule does not apply. The project must earn these points through published assessment work, which does not exist.
Security Assessment & Evidence Preparedness
Public evidence record supporting assessment
Claim: Supporting technical evidence exists in the form of open-source code on GitHub, verified contracts on Etherscan/Polygonscan/Arbiscan, two third-party audit reports, and official technical blog posts describing the architecture.
Coverage basis: Public code repositories, block explorers, audit PDFs, and official documentation collectively describe the system architecture and cryptographic dependencies.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Evidence is comprehensive for classical implementation assessment but entirely silent on quantum security. The evidence record supports an evaluator-performed quantum risk assessment even though the project itself has not published one.
- https://github.com/spiko-tech/contracts
- https://github.com/spiko-tech/stellar-contracts
- https://github.com/trailofbits/publications/blob/master/reviews/2023-10-spiko-securityreview.pdf
- https://etherscan.io/token/0xa0769f7a8fc65e47de93797b4e21c073c117fc80
- https://tech.spiko.io/posts/spiko-smart-contracts/
Production Cryptographic Protection
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: All EUTBL transactions across all chains use classical ECDSA (secp256k1 on EVM chains) or Ed25519 (Stellar). ERC-2612 permit signatures and ERC-2771 meta-transactions also use ECDSA. No PQC or hybrid signature support exists.
Coverage basis: Inherited from host chains (Ethereum, Polygon, Arbitrum, Base, StarkNet use ECDSA; Stellar uses Ed25519). Token-level permit and meta-tx functions add additional ECDSA dependency.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All spend authorization is entirely ECDSA/EdDSA-only. No PQC or hybrid path exists in production, testnet, or roadmap.
Assurance: The classical-only nature of transaction signing is independently verifiable from Ethereum/Stellar protocol specifications and the token contract source code.
Host-chain inheritance rule applies (QRI Section 7.2). Token-specific ERC-2612 permit and ERC-2771 meta-transaction features add independent ECDSA attack surface beyond base-layer transaction signing.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design
Claim: EUTBL inherits the standard Ethereum address model (EOA addresses derived from keccak256 of ECDSA public key) and Stellar's Ed25519 key model. All ~3,500+ holder addresses that have transacted have exposed public keys. No PQ/hybrid address scheme or key-derivation controls exist.
Coverage basis: Standard EVM and Stellar address derivation. Public keys are exposed on first transaction for all holder EOAs.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All transacted holder addresses have long-exposure public keys with no PQ/hybrid address scheme or migration path.
Assurance: RWA.xyz reports ~3,532 holders across chains; all that have transacted have exposed public keys vulnerable to offline quantum attack (harvest-now, decrypt-later).
Long-exposure at-rest attack window applies: public keys visible on-chain can be attacked offline with no time constraint once a CRQC exists.
Production Cryptographic Protection
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: EUTBL is a token, not a blockchain. It has no validator set, consensus mechanism, VRF, or block certification of its own.
Coverage basis: Token-only architecture with no consensus layer.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Production Cryptographic Protection
State-integrity and data-availability mechanisms are quantum-safe where applicable
Claim: EUTBL token state (balances, allowances) is maintained by the ERC-20 contract on each host chain. No custom state-integrity commitments, nullifiers, accumulators, or KZG/pairing-based mechanisms are used at the token level.
Coverage basis: Standard ERC-20 storage model; state integrity is inherited from host-chain consensus and execution.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Production Cryptographic Protection
Privacy and proof layers are quantum-safe where applicable
Claim: EUTBL has no privacy features, shielded pools, ZK proofs, stealth addresses, or note encryption. All balances and transfers are publicly visible on-chain.
Coverage basis: Standard transparent ERC-20 token with no privacy layer.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Production Cryptographic Protection
P2P transport, node identity, and peer authentication
Claim: EUTBL is a token without its own P2P network, node discovery, or peer authentication layer.
Coverage basis: Token-only architecture.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Production Cryptographic Protection
Critical wallet, custody, HSM, and hardware-wallet workflows support the production PQ/hybrid path
Claim: No PQ/hybrid wallet, custody, HSM, or signer workflows exist for EUTBL. The super-admin multisig, daily-operator relayer, allowlister, and all permission-group signers use classical ECDSA keys. No evidence of any PQC-compatible signing infrastructure.
Coverage basis: All admin and operational keys rely on classical ECC; no PQ-compatible signing infrastructure is documented or deployed.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Super-admin multisig and all permission-group signers use classical ECDSA keys with no PQC-compatible signing infrastructure.
Assurance: The exact multisig configuration (Gnosis Safe or equivalent, signer count, threshold, key custody practices) is not publicly documented in detail. Evidence confidence is Medium due to incomplete operational transparency.
As a centralized regulated issuer, Spiko can theoretically upgrade these keys through the UUPS proxy. However, no PQ-compatible upgrade has been proposed or implemented.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected
Claim: 0% of EUTBL's ~$1B market cap (~783M tokens across 7 chains) is protected by PQC or hybrid cryptography. All value is controlled by quantum-vulnerable classical signatures across all attack windows. No migration has occurred.
Coverage basis: Total circulating supply of ~783M tokens at ~$1.23/token ≈ $963M total value. All on-chain token control paths are ECC-only.
Implementation score: 0.05 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: <25% value-at-risk protected (effectively 0%); all ~$1B in token value is quantum-vulnerable with no migration coverage.
Assurance: Market data from RWA.xyz, CoinStats, and Kraken corroborate the ~$1B market cap figure. The KYC-gated model provides centralized recoverability but does not constitute cryptographic protection for coverage calculations.
Coverage threshold: <25% → Implementation Score 0.05 (1/20). The centralized issuer can recover from an attack (PQ-Recoverable) but this is not counted as active protection under QRI Section 10.1.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: No critical wallets have been migrated to PQC. The super-admin multisig, daily-operator, oracle-operator, allowlister, and exceptional-operator all use classical ECDSA keys. No PQ-native or protected wallet infrastructure exists.
Coverage basis: All seven permission groups documented in the Spiko tech blog rely on classical ECC addresses.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No critical admin/operational wallet has been migrated to PQC; all permission-group keys are classical ECC.
Assurance: Confidence is Medium because the exact multisig addresses and signer configurations are not publicly enumerated. The existence of classical-only admin keys is well-evidenced from the architecture documentation.
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts/UTXOs/contracts identified, measurable, deprecated, migrated, frozen
Claim: No legacy vulnerable pool identification, deprecation, or migration program exists. All ~3,500+ holder addresses across chains are quantum-vulnerable with no tracking or deprecation mechanism.
Coverage basis: No evidence of any vulnerability inventory, deprecation policy, or migration tracking for EUTBL holders.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No identification, measurement, deprecation, or migration of legacy vulnerable holdings exists.
Assurance: All holders are KYC-verified, which gives the issuer the operational ability to contact and coordinate migration if needed. This capability is not yet leveraged for quantum readiness.
The KYC-gated allowlist provides a unique advantage for holder identification and coordinated migration compared to permissionless tokens, but no quantum-specific program has been initiated.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: No quantum migration or PQC protection roadmap exists. No public proposal, timeline, activation criteria, or dependency analysis has been published by Spiko.
Coverage basis: Comprehensive search of all official Spiko channels (website, blog, GitHub, documentation) reveals zero quantum-migration content.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: No public migration roadmap exists. The absence of any planning documentation leaves quantum readiness entirely unaddressed.
Assurance: Absence of a roadmap is confirmed by searching all known official publication channels. The project is not PQ-native so Section 7.1 does not apply.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, migration prompts
Claim: No PQ/hybrid account creation, wallet tooling, custody paths, user-facing warnings, or migration prompts exist. Users cannot create PQ-secure EUTBL accounts because no such capability exists on any host chain.
Coverage basis: Standard ERC-20/Stellar token interaction with no PQ-aware tooling or user education.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Zero PQ/hybrid account or transaction paths exist; all user-facing tooling is classical-only.
The centralized issuer model means migration could theoretically be enforced through the UUPS proxy and permission manager, but no such mechanism has been built or proposed.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination: enforcement mechanisms, exchange/custody/bridge/wallet coordination, unsafe-path blocking
Claim: No quantum-specific enforcement mechanisms exist. However, the centralized architecture provides latent enforcement capability: the super-admin can upgrade contracts, freeze tokens, and the allowlister controls who can hold tokens. These capabilities are not currently directed at quantum migration.
Coverage basis: UUPS proxy + Permission Manager architecture provides technical enforcement levers, but none are configured for quantum migration.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No quantum-specific enforcement mechanisms are deployed or planned, despite the existence of technical enforcement levers.
Assurance: The centralized architecture provides latent capability for coordinated migration (contract freeze, upgrade, reissue) that is stronger than most permissionless tokens. This capability is not yet operationalized for quantum readiness.
The existence of enforcement levers (proxy upgrade, pause, allowlist control) is a double-edged sword: it enables recovery but the admin keys controlling these levers are themselves quantum-vulnerable.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: No quantum-specific emergency disclosure or incident-response process exists. The project has a general security contact (security@spiko.tech) and is a regulated financial institution with operational resilience obligations under AMF supervision. A GitHub security policy exists.
Coverage basis: General security processes exist as part of regulatory compliance; no quantum-specific IR playbook.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: As an AMF-regulated UCITS fund, Spiko has operational resilience and business continuity obligations. The existence of a security contact and GitHub security policy provides a baseline. No quantum-specific IR playbook exists, but this is an assurance note rather than a new quantum-attack path.
General security processes exist but no quantum-specific incident response has been designed. Implementation score 0.00 reflects absence of quantum-specific planning.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: EUTBL uses zero PQC algorithms. All cryptography is classical: ECDSA (secp256k1) on EVM chains and Ed25519 on Stellar. No NIST PQC standards (FIPS 203/204/205) or stateful hash-based signatures (XMSS/LMS) are used anywhere in the token stack.
Coverage basis: Full source code review confirms absence of any PQC primitives.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Zero NIST-standardized or broadly reviewed PQC algorithms are used in any component.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: Two audits exist: Trail of Bits (October 2023) for EVM contracts and Halborn (October 2025) for Stellar contracts. Neither audit addresses quantum security or reviews PQC implementations because none exist. Both are classical code-quality audits.
Coverage basis: Both audits are classical-only in scope. The Trail of Bits audit is stale (2.5+ years). The Halborn audit is current for Stellar classical code.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: Score is 0.00 because there is no quantum-critical implementation to audit. The existing audits provide classical code-quality assurance but zero quantum-relevant findings. The Halborn audit (2025) is current for Stellar classical scope; Trail of Bits (2023) is stale but the classical code design remains verifiable from public sources.
This subfactor measures audit coverage of quantum-critical scope. Since there is no PQC implementation, there is nothing quantum-critical to audit. Score reflects absence of PQC code, not audit deficiency.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: EUTBL smart contracts are fully open-source under MIT license on GitHub. Source code is verified on Etherscan and other block explorers. The Solidity code can be compiled and reproduced using standard tooling (Hardhat, pnpm).
Coverage basis: Public GitHub repository with build instructions and verified on-chain bytecode.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Contracts are verified on Etherscan, Polygonscan, Arbiscan, and Basescan. Build and test instructions are provided in the README.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path are documented
Claim: The UUPS upgradeable proxy pattern provides a technical upgrade path for the token contract. However, no cryptographic parameter agility is documented—there is no specification for how signature algorithms, key sizes, or cryptographic primitives could be swapped. The upgrade path is designed for general contract evolution, not cryptographic agility.
Coverage basis: UUPS proxy enables contract upgrades but no crypto-agility documentation exists.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: The UUPS proxy provides a technical mechanism for future cryptographic upgrades, but the absence of documented crypto-agility planning means there is no design for how algorithm transitions would be handled. Score 0.00 reflects absence of documented crypto-agility.
Token-level signature algorithm changes on EVM chains are constrained by the host chain's transaction authentication model. EUTBL cannot independently change its transaction signing algorithm without host-chain support. The upgrade path can modify contract-level logic (permit, meta-tx) but not base-layer transaction signatures.
Algorithm & Implementation Assurance
Stateful-signature safety, side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks
Claim: No stateful PQC signatures (XMSS/LMS) are used, so state-management risks do not apply. Classical ECDSA signatures used by EUTBL have well-understood side-channel and custody profiles, but these are not evaluated for quantum relevance.
Coverage basis: No stateful signatures in use; classical ECDSA/Ed25519 side-channel risks are outside quantum scope.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Algorithm & Implementation Assurance
Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment
Claim: No PQC performance or resource-impact analysis exists because no PQC features are deployed or planned. The large signature sizes and verification costs of PQC algorithms (particularly for on-chain verification) are unaddressed.
Coverage basis: No analysis exists.
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: This is scored 0.00 because no PQC performance analysis exists. However, this is an assurance-only caveat rather than a quantum-critical vulnerability: the absence of a performance benchmark does not create a new quantum-attack path beyond those already identified.
PQC signature size and verification gas costs would be a significant consideration for an ERC-20 token with on-chain permit verification, but this analysis cannot be performed until PQC features are proposed.
Report metadata