Janus Henderson Anemoy Treasury Fund JTRSY

Claim: No public cryptographic inventory or quantum threat model has been published by Janus Henderson, Anemoy, or Centrifuge for JTRSY.

Coverage basis: Project-published assessment

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No public cryptographic inventory published; quantum-vulnerable surfaces are not formally identified by the project.

Assurance: Third-party research (BMIC, EternaX) identifies quantum vulnerabilities in Centrifuge, but the project itself has published no inventory. Centrifuge's CP87 roadmap (2023) and all subsequent governance proposals contain zero references to quantum security, PQC, or cryptographic migration.

Extensive search of Centrifuge governance forum, GitHub CPS repository, Anemoy documentation, and Janus Henderson press releases found no quantum-related content. The Centrifuge Protocol Engineering Group roadmap process (CP32) does not include quantum security as a criterion.

• https://github.com/centrifuge/cps/blob/main/cps/CP87.md
• https://gov.centrifuge.io/t/rfc-roadmap-process-protocol-engineering-group-mandate/5136

Claim: Third-party research provides evidence of quantum vulnerabilities but no project-published evidence record exists.

Coverage basis: Third-party research + on-chain code

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: BMIC and EternaX research are independent analyses, not project-commissioned assessments. Etherscan verified contract code and Code4rena audit provide reproducible evidence of the ECDSA-based admin architecture but are not quantum-specific evidence records.

The project has not assembled or published a quantum-specific evidence record. External researchers have done this work but the project has not acknowledged or incorporated it.

• https://bmic.ai/research/rwa-quantum-security
• https://eternax.ai/reports/post-quantum-financial-infrastructure
• https://etherscan.io/token/0x8c213ee79581ff4984583c6a801e5263418c4b86
• https://code4rena.com/reports/2023-09-centrifuge

Claim: JTRSY inherits host-chain ECDSA-based spend authorization with no PQC or hybrid-PQC protection.

Coverage basis: Token inheritance from host chains (QRI Section 7.2)

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All JTRSY holder spend authorization relies on host-chain ECDSA (secp256k1 on Ethereum/EVM chains). Public keys of accounts that have sent transactions are exposed on-chain and vulnerable to Shor's algorithm.

Assurance: Tranche.sol extends ERC20.sol which uses standard ECDSA-based permit signatures (SignatureLib.isValidSignature). No PQC or hybrid signature scheme is implemented. Ethereum's PQ roadmap (Lean Ethereum, target ~2029+) would eventually improve host-chain protection, but this is not yet production.

Under QRI Section 7.2 Token Inheritance, JTRSY inherently shares the base-layer QRI score of its host chains. Ethereum's spend authorization is currently ECDSA-only with no production PQ protection.

• https://etherscan.io/token/0x8c213ee79581ff4984583c6a801e5263418c4b86
• https://github.com/centrifuge/liquidity-pools/blob/main/src/token/Tranche.sol

Claim: JTRSY inherits host-chain address/key-derivation design with no PQ/hybrid controls.

Coverage basis: Token inheritance from host chains

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Host-chain accounts using standard Ethereum address derivation expose public keys on first spend. No PQ-safe key derivation or address format is available.

Assurance: Standard Ethereum account model: addresses are keccak256 hashes of public keys. Public keys are exposed on first transaction, creating long-exposure quantum vulnerability.

JTRSY holders use standard Ethereum/EVM accounts. Any holder who has transferred tokens has an exposed, quantum-vulnerable public key.

• https://etherscan.io/token/0x8c213ee79581ff4984583c6a801e5263418c4b86

Claim: JTRSY is a token and has no independent consensus mechanism.

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

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

N/A per QRI Section 11.7 (Tokens and Application Assets). Token has no consensus layer to evaluate.

Claim: Centrifuge admin keys (wards, Root, Guardian, Safe multisig) that control JTRSY token state integrity are ECDSA-based and quantum-vulnerable.

Coverage basis: Token-specific admin/governance keys

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Centrifuge admin keys use ECDSA-based Ethereum addresses. A quantum attacker compromising admin signer keys can mint, burn, upgrade hooks, reassign wards, and update vaults — fully compromising ~$1.33B in tokenized Treasury value.

Assurance: The Tranche.sol contract uses an Auth pattern with `wards` mapping and `auth`/`authOrHook` modifiers. Admin functions include: mint(), burn(), file() (update hook address), updateVault(), setHookData(), rely()/deny() (manage wards). Centrifuge docs confirm Root → ProtocolGuardian/OpsGuardian → Safe multisig → 48-hour timelock. Particula report (May 2025) confirms the multisig architecture. Code4rena audit (2023) documents the DelayedAdmin/PauseAdmin/Root architecture.

The 48-hour timelock provides a window for detection but does not prevent a quantum attack — once admin keys are compromised, the attacker can wait out the timelock and execute malicious transactions.

• https://etherscan.io/token/0x8c213ee79581ff4984583c6a801e5263418c4b86
• https://github.com/centrifuge/liquidity-pools/blob/main/src/token/Tranche.sol
• https://code4rena.com/reports/2023-09-centrifuge
• https://docs.centrifuge.io/developer/security/guardian

Claim: JTRSY has no privacy or ZK proof layer.

Coverage basis: N/A — no privacy features

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

N/A — no privacy layer exists in the JTRSY token design.

Claim: JTRSY is a token and has no independent P2P network layer.

Coverage basis: N/A — token has no P2P layer

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

N/A — token has no P2P layer.

Claim: Centrifuge admin multisig signers use standard ECDSA-based wallets with no PQ/hybrid support.

Coverage basis: Token-specific admin key custody

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: The Safe multisig signers controlling ~$1.33B in JTRSY value use standard ECDSA wallets. No evidence of HSM, MPC, or PQ-safe signing workflows for admin key operations.

Assurance: Centrifuge docs describe ProtocolGuardian and OpsGuardian controlled by Safe multisigs. Particula report documents the multisig architecture but does not describe the signing technology (HSM, MPC, hardware wallet, or software wallet) used by signers. The 48-hour timelock provides an operational safety margin but does not protect against quantum key recovery.

Admin signer public keys may be exposed on-chain from deployment transactions or governance operations, making them vulnerable to long-exposure quantum attacks.

• https://docs.centrifuge.io/developer/security/guardian

Claim: 0% of JTRSY's ~$1.33B circulating value is quantum-protected. All value is held in ECDSA-based accounts with quantum-vulnerable admin key control.

Coverage basis: Circulating supply across 8 chains

Implementation score: 0.05 · Evidence confidence: Medium

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

Quantum blocker: ~$1.33B in tokenized Treasury value with 0% quantum protection. All holder accounts and admin keys are ECDSA-based with no migration path.

Assurance: Stableregistry reports ~$1.33B circulation as of April 2026. The coverage score of 1 (minimum) reflects <25% protection per QRI Section 9.3.1 coverage thresholds. Implementation score of 0.05 = 1 point earned / 20 subfactor weight.

JTRSY has only ~10 holders (per IQ.wiki as of March 2026), meaning the value is highly concentrated. A compromise of any major holder's key or an admin key would affect a very large percentage of total value.

• https://stableregistry.com/stablecoins/jtrsy/
• https://etherscan.io/token/0x8c213ee79581ff4984583c6a801e5263418c4b86

Claim: No critical wallets (admin multisig signers, treasury, issuer) have been migrated to PQ-safe schemes.

Coverage basis: Token-specific admin and treasury wallets

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: The Safe multisig and all associated ward addresses remain on standard ECDSA-based Ethereum accounts with no PQ migration.

Assurance: No evidence of any PQ migration activity for any JTRSY or Centrifuge-related wallet. The Particula report (May 2025) describes the multisig architecture in standard Ethereum terms with no mention of PQ or hybrid schemes.

Critical wallets include: the Root contract ward address, ProtocolGuardian/OpsGuardian Safe multisig signers, Anemoy operational wallets, and any treasury/issuer-controlled addresses.

• https://docs.centrifuge.io/developer/security/guardian

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

Coverage basis: Token-specific vulnerable surface identification

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No vulnerable account inventory, deprecation policy, freeze mechanism, or migration path exists for quantum-vulnerable JTRSY holder accounts or admin keys.

Assurance: The JTRSY token contract has no freeze function (per Stableregistry), meaning individual vulnerable accounts cannot be frozen to prevent quantum theft. The hook mechanism could theoretically restrict transfers but is itself controlled by quantum-vulnerable admin keys.

The off-chain legal fallback (replacement of tokenized shares with traditional shares via fund administrator) is a reactive recovery mechanism, not a proactive identification/deprecation of vulnerable on-chain accounts.

Claim: No quantum migration or PQC protection roadmap exists for JTRSY or Centrifuge.

Coverage basis: Project-published roadmap

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No quantum/PQC roadmap exists. Centrifuge's published roadmap (CP87) and all subsequent proposals contain zero mention of post-quantum cryptography.

Assurance: Extensive search of Centrifuge CPS repository, governance forum, and all CP proposals from CP1 through CP143+ found no quantum-related content. The Protocol Engineering Group mandate (CP32) does not include quantum security as an evaluation criterion.

Ethereum's Lean Ethereum PQ roadmap (~2029+ target) would improve host-chain protection but does not address Centrifuge-specific admin key migration.

• https://github.com/centrifuge/cps/blob/main/cps/CP87.md
• https://gov.centrifuge.io/t/rfc-roadmap-process-protocol-engineering-group-mandate/5136

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

Coverage basis: Token-specific migration tooling

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No PQ account creation, wallet tooling, or migration prompts are available for JTRSY holders or admin signers.

Assurance: JTRSY has only ~10 holders (mostly institutional). Migration tooling for such a concentrated holder base would be relatively straightforward compared to retail tokens, but no tooling exists.

JTRSY's small holder count (~10 per IQ.wiki) means migration coordination is operationally simpler than for widely-held tokens, but this does not mitigate the absence of any migration infrastructure.

Claim: No enforcement mechanisms exist for quantum migration. No exchange, custody, bridge, or infrastructure coordination for PQ migration.

Coverage basis: Token-specific enforcement mechanisms

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No deprecation, freeze, disabled legacy signing, or mandatory migration deadline exists for quantum-vulnerable JTRSY accounts or admin keys.

Assurance: The Centrifuge admin architecture includes a 48-hour timelock and Safe multisig which provide operational security but are not quantum-migration enforcement mechanisms. The lack of a token freeze function limits enforcement options.

Under QRI Section 9.4, migration enforcement mechanisms include deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking, and mandatory migration deadlines. None of these exist for JTRSY.

Claim: No quantum-specific incident response or disclosure process exists.

Coverage basis: Project-published processes

Implementation score: 0 · Evidence confidence: High

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

Assurance: Per QRI, lack of a formal quantum-specific IR playbook is a note-only caveat when it does not create a current quantum-vulnerable path. However, the absence of any quantum-aware governance process means there is no established mechanism to respond to quantum threats, contributing to the overall readiness gap.

The Centrifuge DAO governance process (CP32) includes emergency mechanisms for protocol changes but has never been exercised for quantum-related issues. The off-chain legal fallback (traditional share replacement) could serve as an emergency recovery mechanism but is not formalized as a quantum incident response process.

Claim: No PQC or hybrid-PQC algorithms are used anywhere in the JTRSY token or Centrifuge admin infrastructure.

Coverage basis: NIST PQC standards (FIPS 203, 204, 205)

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All cryptographic operations in JTRSY and Centrifuge admin infrastructure use classical algorithms (ECDSA secp256k1, keccak256) with no PQC integration.

Assurance: The Tranche.sol contract uses Solidity's ecrecover-based signature verification (via SignatureLib.isValidSignature) for ERC20 permits. All admin authentication uses standard Ethereum ECDSA via the `auth` modifier checking `wards[msg.sender] == 1`.

NIST finalized three PQC standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA/Dilithium), FIPS 205 (SLH-DSA/SPHINCS+). None are used in JTRSY or Centrifuge.

• https://etherscan.io/token/0x8c213ee79581ff4984583c6a801e5263418c4b86
• https://github.com/centrifuge/liquidity-pools/blob/main/src/token/Tranche.sol

Claim: No quantum-focused audit exists. Code4rena 2023 audit covers Centrifuge protocol but predates quantum-awareness and does not evaluate PQC readiness.

Coverage basis: Existing audits

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The Code4rena audit (2023-10) documents the admin architecture (Root, DelayedAdmin, PauseAdmin, wards) but does not evaluate quantum security. No PQC implementation exists to audit. The audit is ~2.7 years old. Per the Particula report, Anemoy's specific JTRSY contracts have no separately published audit.

The absence of a PQC implementation means there is nothing quantum-specific to audit. This subfactor is scored 0 because no quantum-critical audit scope exists; the assurance gap is recorded as note-only per QRI Section 6.4.

• https://code4rena.com/reports/2023-09-centrifuge

Claim: JTRSY's Tranche.sol and ERC20.sol contracts are verified on Etherscan and available on GitHub. No PQC implementation exists to be open-source.

Coverage basis: On-chain verified contracts + GitHub

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: The existing classical contracts are open-source and verified, which supports auditability. However, the subfactor evaluates the quantum-critical implementation — which does not exist. Score 0 reflects absence of PQC implementation, not lack of open-source practices.

Centrifuge liquidity-pools repository (31 stars) contains the Tranche.sol source. Contracts are verified on Etherscan and Arbiscan with matching bytecode.

• https://github.com/centrifuge/liquidity-pools/blob/main/src/token/Tranche.sol
• https://etherscan.io/token/0x8c213ee79581ff4984583c6a801e5263418c4b86

Claim: No documented parameter agility or PQC upgrade path exists.

Coverage basis: Project documentation

Implementation score: 0 · Evidence confidence: High

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

Assurance: The Centrifuge admin architecture supports upgrading the hook contract (`file("hook", newAddress)`) which could theoretically be used to migrate to PQ verification. However, this capability is itself controlled by quantum-vulnerable ECDSA admin keys, making it a circular dependency. No documented plan exists for how this upgrade path would be exercised for PQC migration.

The `file()` function in Tranche.sol allows updating the hook address, and the `auth` modifier controls access. While the architecture supports upgrades, there is no documented parameter agility strategy for cryptographic algorithm migration.

Claim: No PQC signatures are in use, making stateful-signature safety assessment not applicable.

Coverage basis: N/A — no PQC signatures deployed

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

N/A — subfactor only applies when stateful hash-based signatures (XMSS, LMS) are in production use.

Claim: No performance or resource-impact analysis exists for PQC deployment in JTRSY or Centrifuge.

Coverage basis: N/A — no PQC deployment planned or analyzed

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

N/A — no PQC deployment exists to analyze. If Centrifuge were to adopt PQC for admin keys, gas cost analysis for on-chain PQ signature verification would become relevant.