Spiko Amundi Overnight Swap Fund (EUR) EURSAFO

Claim: No public cryptographic inventory or quantum threat model has been published by Spiko for EURSAFO.

Coverage basis: Absence of any quantum-focused assessment from the project; cryptographic mechanisms are inferable from public code and host-chain specifications but not inventoried for quantum risk.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: No public cryptographic inventory. Readiness & Risk Cap: 10.

Assurance: Cryptographic dependencies (ECDSA secp256k1 on EVM, Ed25519 on Stellar) are well-known and verifiable from host-chain specifications and public code, but Spiko has not formally documented or acknowledged these as quantum-vulnerable surfaces.

The project's technical blog post (2025-05-04) describes the smart contract architecture in detail but makes no mention of quantum threats, PQC, or cryptographic agility. The absence of a cryptographic inventory is the primary factor triggering the Readiness & Risk Cap of 10.

• https://github.com/spiko-tech/contracts
• https://www.spiko.io/spiko-euro
• https://tech.spiko.io/posts/spiko-smart-contracts/

Claim: No quantum-specific evidence record (code references, specs, audits, reproducible analytics) has been published by Spiko for quantum risk evaluation.

Coverage basis: Absence of quantum-focused evidence from the project.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: While classical audits (Trail of Bits, Halborn) and open-source code exist, none address quantum-critical properties. The evidence record for quantum purposes is absent.

Claim: All token-holder spend authorization relies on host-chain classical signatures: ECDSA (secp256k1) on Ethereum/Polygon/Arbitrum/Base and Ed25519 on Stellar. No PQC or hybrid-PQC path exists.

Coverage basis: Token inherits host-chain signature schemes per QRI Section 7.2 (Token Inheritance). All five host chains use classical ECC for transaction signatures.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Active production spend authorization remains entirely ECDSA/Ed25519-only.

Assurance: Host-chain signature schemes are well-known and independently verifiable. The Token.sol contract uses standard OpenZeppelin ERC-20 with ERC-2612 (Permit) which also relies on ECDSA. ERC-2771 (meta-transactions) uses the same classical trust assumptions.

EURSAFO holders sign transactions using standard EVM wallet ECDSA or Stellar Ed25519 keys. There is no token-level mechanism to accept PQC or hybrid signatures.

• https://etherscan.io/token/0x0990b149e915cb08e2143a5c6f669c907eddc8b0
• https://app.rwa.xyz/assets/eurSAFO
• https://github.com/spiko-tech/contracts/blob/main/contracts/token/Token.sol

Claim: EVM accounts that have sent transactions have exposed secp256k1 public keys (long-exposure attack window). Stellar accounts use Ed25519 public keys. No PQ/hybrid account or address format exists.

Coverage basis: Standard host-chain account models. EVM EOAs reveal public keys on first spend; Stellar accounts expose Ed25519 public keys. No protocol-level mitigation for key exposure.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Well-known property of EVM and Stellar account models. All active EURSAFO holder addresses on EVM chains with outbound transactions have exposed public keys vulnerable to offline Shor attacks.

The KYC-gated nature means holder addresses are known to Spiko, which could aid off-chain recovery but does not protect against on-chain quantum key recovery.

• https://app.rwa.xyz/assets/eurSAFO
• https://etherscan.io/token/0x0990b149e915cb08e2143a5c6f669c907eddc8b0

Claim: EURSAFO is a token, not a blockchain network. It has no consensus mechanism of its own.

Coverage basis: N/A — token has no consensus layer.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: Token state integrity depends on host-chain execution and admin key control. The UUPS proxy and Permission Manager allow the multisig super-admin to change token logic and state. No PQC protection for state integrity.

Coverage basis: Token state (balances, allowances, supply) is secured by host-chain consensus and the token contract's access control. Admin keys can override state through upgrades or privileged functions.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Admin multisig keys are ECDSA/Ed25519-only and can compromise state integrity via upgrade, mint, burn, or permission changes.

Assurance: The Permission Manager and UUPS upgrade path are well-audited for classical security (Trail of Bits). The quantum vulnerability is in the ECDSA keys that authorize these privileged operations, not in the contract logic itself.

No KZG commitments, pairings, or zero-knowledge proof systems are used in the token contracts. The NAV oracle (Chainlink) is purely informational and does not affect token state integrity.

• https://github.com/spiko-tech/contracts/blob/main/contracts/permissions/PermissionManager.sol
• https://github.com/spiko-tech/contracts/blob/main/contracts/token/Token.sol

Claim: EURSAFO has no privacy or shielded-transaction features.

Coverage basis: N/A — token has no privacy layer.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: EURSAFO is a token, not a network. It has no P2P layer of its own.

Coverage basis: N/A — token has no P2P network.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: Admin/treasury wallets use Dfns MPC with classical threshold ECDSA/EdDSA. No production PQC path for admin signers. Token holders use standard classical wallets (MetaMask, Ledger, etc.).

Coverage basis: Dfns MPC wallets (classical), multisig super-admin (classical ECDSA/Ed25519), and standard holder wallets all lack PQC support in production for EURSAFO.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Dfns MPC wallets use classical threshold ECDSA/EdDSA. No confirmed PQC deployment for Spiko's production infrastructure.

Assurance: Dfns has Post-Quantum TSS research and Securosys HSM PQC capabilities, but no evidence confirms Spiko has deployed or tested these in production. The MPC architecture distributes key shares but does not change the underlying classical elliptic curve assumptions. ISO 27001 and SOC 2 Type II certifications apply to Dfns operational security but not to quantum resistance.

The super-admin multisig, daily-operator relayer, oracle-operator, allowlister, and burner role all rely on classical ECDSA/Ed25519 keys. These are all single points of quantum failure for the token's administrative lifecycle.

• https://www.dfns.co/labs
• https://docs.dfns.co/core-concepts/dfns-security-model
• https://tech.spiko.io/posts/spiko-smart-contracts/

Claim: 0% of ~$422M total value is protected. All value resides on classically-vulnerable host chains with no migration or protection mechanism.

Coverage basis: Total value ~$422M across five chains (Stellar: ~$241M, Polygon: ~$52M, Arbitrum: ~$50M, Ethereum: ~$14M, Base: ~$4M). No PQC protection, no migration, no hybrid signing. All holder and admin keys are classically vulnerable.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Material long-exposure quantum-vulnerable value (~$422M) exists with no migration, freeze, deprecation, burn, recovery, or policy path.

Assurance: Value figures from RWA.xyz as of 2026-06-06. The regulated fund structure provides off-chain recoverability (CACEIS depositary, Spiko transfer agent, AMF authorization, KYC-gated holders) but this does not constitute on-chain quantum protection or migration coverage per QRI Section 10.1.

All EURSAFO holders are KYC-verified, which means Spiko knows the identity of every token holder. This facilitates off-chain recovery (e.g., freezing contracts, re-issuing shares via legal process) but does not prevent a quantum adversary from stealing tokens on-chain before a freeze can be executed.

• https://app.rwa.xyz/assets/eurSAFO

Claim: No critical wallets (treasuries, admin multisig, Dfns MPC, relayer accounts, exchanges, custodians) have been migrated or protected with PQC.

Coverage basis: All known critical wallets use classical ECDSA/Ed25519. No migration has occurred.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The super-admin multisig address, daily-operator relayer, and Dfns-managed treasury addresses are not publicly enumerated in the evidence dossier, but the architecture is confirmed by Spiko's own technical blog and the Pharos analysis. All are ECDSA/Ed25519-based by design of the host chains.

• https://tech.spiko.io/posts/spiko-smart-contracts/
• https://pharos.watch/stablecoin/eursafo-spiko/

Claim: No identification, measurement, deprecation, or freeze of quantum-vulnerable accounts has been performed. All holder accounts on all chains are vulnerable by default.

Coverage basis: No legacy identification process exists. All current accounts are vulnerable.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The KYC-gated structure means all holder addresses are known to Spiko, which could facilitate future identification. However, no quantum-vulnerability-specific identification or measurement has been published.

Claim: No public quantum migration roadmap exists for EURSAFO or Spiko's tokenization infrastructure.

Coverage basis: Absence of any roadmap document, proposal, or public statement addressing quantum migration.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: The UUPS upgradeability of token contracts technically provides a mechanism for future migration, but without a published roadmap, timeline, or activation criteria, this does not constitute a migration plan per the QRI specification.

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

Coverage basis: Absence of any migration accessibility features.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: EURSAFO holders interact through standard ERC-20/Stellar wallets (MetaMask, Rabby, Ledger, etc.) that have no PQ capabilities. No token-level migration prompt or user education exists.

Claim: No enforcement mechanisms exist for quantum migration. The contract has a pause function (controlled by the classical multisig) but no quantum-specific deprecation, freeze, or mandatory migration enforcement.

Coverage basis: The Token.sol `pause()` function exists but is controlled by classical keys and is not designed for quantum migration enforcement.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The pause function could theoretically be used as an emergency brake in a quantum incident, but the key authorizing the pause is itself quantum-vulnerable (classical ECDSA). No automated or proactive enforcement mechanism exists.

• https://github.com/spiko-tech/contracts/blob/main/contracts/token/Token.sol

Claim: No quantum-specific incident-response plan, disclosure process, or governance mechanism has been published by Spiko.

Coverage basis: Absence of quantum-specific emergency processes.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: Spiko has a security contact ([email protected]) referenced in their smart contracts, and the regulated fund structure provides legal frameworks for incident response. However, no quantum-specific playbook, disclosure timeline, or governance process has been published. This is classified as an assurance-only caveat because, while the absence of a formal quantum IR plan is a gap, it does not independently create a quantum attack path — the classical signature vulnerability is the primary quantum-critical issue.

The regulated UCITS structure (AMF oversight, CACEIS depositary, PwC auditor) provides institutional-grade operational governance. The absence of a published quantum-specific IR plan reduces confidence but does not independently create a quantum-enabled attack path.

Claim: No PQC or hybrid-PQC algorithms are used anywhere in the EURSAFO token infrastructure. All cryptographic operations use classical ECDSA (secp256k1) on EVM chains and Ed25519 on Stellar.

Coverage basis: Absence of any PQC algorithm deployment.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Verifiable from contract source code (OpenZeppelin ERC-20, ERC-2612 ECDSA permits, ERC-2771 meta-transactions) and host-chain protocol specifications. No NIST PQC algorithms (ML-DSA, SLH-DSA, FN-DSA, ML-KEM) are referenced or implemented.

• https://github.com/spiko-tech/contracts
• https://etherscan.io/token/0x0990b149e915cb08e2143a5c6f669c907eddc8b0

Claim: No independent audit covers quantum-critical properties. Trail of Bits (EVM, 2025) and Halborn (Stellar, 2025) audits are classical-only in scope.

Coverage basis: Existing audits are scope-mismatched for quantum purposes.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Trail of Bits and Halborn audits provide strong classical-security assurance for the token contracts, Permission Manager, UUPS proxy, and Stellar Smart Account contracts. However, they did not evaluate quantum-critical properties because no PQC implementation exists to audit. This is classified as an assurance-only caveat — it does not independently create a quantum attack path, and the absence of a quantum-scope audit is expected when no quantum-critical implementation exists.

• https://tech.spiko.io/posts/spiko-smart-contracts/
• https://github.com/spiko-tech/contracts

Claim: The token contracts are open-source (MIT license) on GitHub and verified on Etherscan. However, no quantum-critical implementation exists to be open-source.

Coverage basis: Classical implementation is open-source and verifiable. Quantum-critical implementation does not exist.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: The classical codebase is well-structured, audited, and open-source. Source code is verified on Etherscan for the Ethereum deployment. This supports general security assurance but does not contribute to quantum readiness since no PQC implementation exists.

The open-source nature of the classical contracts is a positive general-security property but does not earn QRI points under the Algorithm & Implementation Assurance category, which measures quantum-critical algorithm assurance.

• https://github.com/spiko-tech/contracts
• https://etherscan.io/token/0x0990b149e915cb08e2143a5c6f669c907eddc8b0

Claim: The UUPS proxy pattern provides technical upgradeability, but no quantum-specific parameter agility or upgrade path has been documented.

Coverage basis: UUPS upgradeability exists but is undocumented for quantum migration purposes.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The UUPS upgradeability (via `_authorizeUpgrade` restricted to the super-admin) provides a technical mechanism to deploy new implementations, which could theoretically include PQC signature verification. However, no quantum-specific parameter agility documentation, upgrade plan, or cryptographic agility strategy has been published. This is note-only because the upgrade path exists but the quantum-critical implementation and documentation are absent.

The super-admin multisig that authorizes upgrades is itself ECDSA/Ed25519-based, creating a circular dependency: migrating admin keys to PQC requires the (currently vulnerable) admin keys to authorize the upgrade.

• https://github.com/spiko-tech/contracts/blob/main/contracts/token/Token.sol
• https://tech.spiko.io/posts/spiko-smart-contracts/

Claim: No stateful signature schemes (XMSS, LMS, SLH-DSA stateful variants) are used. Subfactor is N/A.

Coverage basis: N/A — no stateful signatures in use.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: No PQ signatures are deployed, so no performance analysis exists or is required.

Coverage basis: N/A — no PQ signatures in production.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable