Rain RAIN

Claim: No public cryptographic inventory, quantum threat model, or PQC migration roadmap exists in any Rain Protocol primary source.

Coverage basis: Absence of evidence across whitepaper, documentation, GitHub, and audit reports.

Implementation score: 0 · Evidence confidence: High

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

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

Assurance: Exhaustive search of primary sources (whitepaper, official site, GitHub repositories, Hacken audit) confirms zero quantum-related documentation.

The whitepaper (v2.0, March 2026) details tokenomics, governance plans, and Hacken audit results but contains no mention of cryptography, signatures, quantum risk, or PQC.

• https://whitepaper.rain.one/
• https://rain.one/
• https://hacken.io/audits/rain/

Claim: No evidence record (code references, specs, audits, transaction examples) supporting a quantum risk assessment exists.

Coverage basis: Absence of evidence.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The archived rain-protocol GitHub repo (last push Oct 2023) predates the current Arbitrum deployment and contains no quantum-related content.

The rainlanguage/rainlang repo describes an on-chain EVM smart contract language with no cryptographic primitives beyond standard EVM operations.

• https://whitepaper.rain.one/
• https://github.com/rainlanguage/rain-protocol

Claim: All RAIN token transactions and admin operations use ECDSA/secp256k1 signatures inherited from Arbitrum/Ethereum. No PQC or hybrid-PQC signature support exists.

Coverage basis: Inherited from Arbitrum L2 host chain; confirmed by token contract verification on Arbiscan and Hacken audit.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Active production spend authorization remains entirely ECC-only — Readiness & Risk Cap 40

Assurance: Hacken audit (Aug 2025) confirms Solidity/UUPS implementation on Arbitrum with standard ECDSA transaction authorization. Audit scope is classical security only.

Account abstraction (ERC-4337 via Alchemy smart accounts) is used for gas sponsorship but the underlying signature verification remains ECDSA/secp256k1. The RainAA SDK manages Alchemy smart accounts but does not introduce PQC signature verification.

• https://arbiscan.io/token/0x25118290e6A5f4139381D072181157035864099d
• https://hacken.io/audits/rain/sca-rain-token-aug2025/
• https://whitepaper.rain.one/

Claim: Standard EVM externally-owned accounts (EOAs) with ECDSA/secp256k1 keys. Public keys are revealed on-chain for any address that has sent a transaction (long-exposure risk). No PQ or hybrid key management.

Coverage basis: Inherited from Arbitrum/Ethereum EVM account model.

Implementation score: 0 · Evidence confidence: High

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

Assurance: All RAIN token holders and the single admin/owner key use standard Ethereum EOAs. Transacted EOAs have exposed public keys vulnerable to future quantum key-recovery.

The token owner address controls minting, oracle configuration, treasury updates, and proxy upgrades. This single admin key represents a high-value quantum target.

• https://arbiscan.io/token/0x25118290e6A5f4139381D072181157035864099d
• https://whitepaper.rain.one/

Claim: RAIN token has no independent consensus layer. Consensus is inherited from Arbitrum (optimistic rollup) and Ethereum (PoS with BLS validator signatures).

Coverage basis: Token architecture — no validator set, VRF, or finality signatures at the token level.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Arbitrum uses optimistic rollup with fraud proofs; Ethereum PoS uses BLS signatures for validators — both quantum-vulnerable but outside token-specific scope.

Whitepaper section H.4 confirms RAIN operates on Arbitrum which inherits Ethereum PoS consensus.

• https://whitepaper.rain.one/

Claim: No custom state-integrity or data-availability mechanisms beyond Arbitrum's inherited rollup data posting to Ethereum.

Coverage basis: Token architecture — standard ERC-20 with no custom commitments, nullifiers, or proof systems.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Arbitrum posts transaction data to Ethereum L1 for data availability; this inherited mechanism is outside token-specific evaluation scope.

• https://arbiscan.io/token/0x25118290e6A5f4139381D072181157035864099d

Claim: No privacy layer exists. All RAIN token balances and transactions are publicly visible on Arbiscan.

Coverage basis: Token architecture — standard ERC-20 with transparent on-chain state.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://arbiscan.io/token/0x25118290e6A5f4139381D072181157035864099d

Claim: No independent P2P layer. Network communication is inherited from Arbitrum node infrastructure.

Coverage basis: Token architecture — ERC-20 tokens do not operate independent P2P networks.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: Standard EVM wallet ecosystem (MetaMask, WalletConnect, etc.) with ECDSA-only signing. No PQC or hybrid-PQC wallet support for RAIN token operations.

Coverage basis: Inherited from Ethereum/Arbitrum wallet ecosystem.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The Rain SDK (rain1-labs/rain-sdk) uses standard viem/wagmi wallet clients and Alchemy smart accounts with ECDSA signing. No PQC key management or signature verification is implemented.

The RainAA class manages Alchemy smart accounts for gas-sponsored execution but relies entirely on the underlying EOA's ECDSA signature for authorization.

• https://github.com/rain1-labs/rain-sdk

Claim: 0% of RAIN token value-at-risk is protected from quantum key-recovery attacks. No PQC migration, protection, or native PQ namespace exists.

Coverage basis: No migration or protection mechanism exists. All value is held in ECDSA-controlled accounts.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Circulating supply approximately 478 billion RAIN per Arbiscan (June 2026). Market cap approximately $3.4B per CoinMarketCap. All holdings are in ECDSA-vulnerable accounts.

Total supply is 1.15 trillion RAIN with controlled inflation via daily minting ($50,000 USD equivalent). No freeze, deprecation, burn, or recovery policy for quantum-vulnerable value is documented.

• https://arbiscan.io/token/0x25118290e6A5f4139381D072181157035864099d
• https://whitepaper.rain.one/
• https://coinmarketcap.com/currencies/rain/

Claim: No critical wallets (treasury, foundation, exchange holdings, admin keys) have been migrated to PQC or protected by any quantum-resistant mechanism.

Coverage basis: No evidence of any wallet migration.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Whitepaper mentions multisig governance for protocol upgrades and treasury actions, but multisig keys are ECDSA-based and provide no quantum protection.

Token allocations include 20% marketing/development, 20% reserve/treasury (18-month cliff), 15% ecosystem/staking, 10% team (24-month vesting) — all held in ECDSA-vulnerable addresses.

• https://whitepaper.rain.one/

Claim: No identification, measurement, deprecation, migration, or freeze of legacy quantum-vulnerable value pools has been performed or documented.

Coverage basis: No evidence of any legacy pool analysis.

Implementation score: 0 · Evidence confidence: High

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

All RAIN token holdings are in standard ERC-20 accounts on Arbitrum. Any address that has sent a transaction has an exposed public key (long-exposure risk). No policy to address dormant or unmigratable holdings exists.

Claim: No public migration roadmap, sequencing, activation criteria, or dependencies for PQC migration exist.

Coverage basis: Absence of evidence across all primary sources.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Whitepaper mentions future DAO governance activation and protocol audit completion as upcoming milestones, but no quantum-specific milestones or migration plans are referenced.

The whitepaper's upcoming milestones include: protocol audit completion, additional blockchain network integration, oracle/dispute framework enhancement, incentive mechanism expansion, and DAO governance implementation — none address quantum readiness.

• https://whitepaper.rain.one/
• https://rain.one/

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

Coverage basis: Absence of evidence.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The Rain SDK provides standard EVM transaction building and Alchemy smart account management with no PQC features, quantum warnings, or migration prompts.

• https://github.com/rain1-labs/rain-sdk

Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking) exist for quantum migration. No exchange, custody, bridge, or wallet coordination for PQC transition.

Coverage basis: Absence of evidence.

Implementation score: 0 · Evidence confidence: High

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

Assurance: RAIN is listed on MEXC, BingX, and Gems Trade. No exchange has published PQC migration attestations for RAIN custody.

The upgradeable proxy pattern allows the owner to change contract logic, but this does not constitute a quantum migration enforcement mechanism.

Claim: No quantum-specific emergency disclosure, incident-response, or governance process is documented.

Coverage basis: Absence of evidence.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Hacken audit recommends automatic emergency actions for critical activities but this is a general security recommendation, not quantum-specific.

DAO governance is planned but not yet activated. Once active, it could theoretically serve as a governance mechanism for quantum emergency response, but no such capability is currently documented or planned.

Claim: No PQC or hybrid-PQC algorithms are used. All cryptographic operations rely on classical ECC (secp256k1) and standard EVM hash functions (keccak256).

Coverage basis: Confirmed by token contract source code, Hacken audit, and absence of any PQC claims.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Token contract uses OpenZeppelin ERC-20 upgradeable patterns with standard EVM cryptographic primitives. No NIST PQC algorithms (ML-DSA, SLH-DSA, ML-KEM) or hybrid constructions are present.

The 'Rain' symmetric-key primitive (CCS 2022) used in the Rainier post-quantum signature scheme is an entirely separate academic project with no connection to Rain Protocol or the RAIN token.

• https://arbiscan.io/token/0x25118290e6A5f4139381D072181157035864099d
• https://hacken.io/audits/rain/sca-rain-token-aug2025/

Claim: Hacken audit (Aug 2025) covers classical ERC-20 smart contract security. No quantum-specific audit exists.

Coverage basis: Hacken audit report confirms scope limited to Solidity smart contract security assessment.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Hacken audit is recent (Aug 2025) and covers the RainToken.sol contract at commit f439c92. Audit found 7 findings (1 medium, 6 observations), 5 resolved, 1 accepted, 1 mitigated. Test coverage was 33.33% branch coverage. Audit scope is explicitly classical smart contract security — no PQC algorithm review, quantum threat assessment, or cryptographic inventory validation.

A protocol-level audit is described as 'underway' in the whitepaper but has not been published as of the evaluation date.

• https://hacken.io/audits/rain/sca-rain-token-aug2025/

Claim: The RAIN token contract is verified on Arbiscan and the SDK is open source. However, no PQ or hybrid-PQC implementation exists to be open-source or reproducible.

Coverage basis: Classical code is open-source; no PQ code exists.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Token implementation (v0x47716e35...) is verified on Arbiscan. Rain SDK (TypeScript) is publicly available on GitHub under rain1-labs.

The subfactor is applicable per QRI rules: it cannot be marked N/A merely because the project has not implemented PQ features. The project has open-source classical code but no open-source PQ implementation.

• https://arbiscan.io/token/0x25118290e6A5f4139381D072181157035864099d
• https://github.com/rain1-labs/rain-sdk

Claim: No parameter agility or PQ upgrade path is documented. The token's proxy architecture enables contract upgrades, but no quantum-aware upgrade plan or cryptographic agility design exists.

Coverage basis: No agility documentation or PQ upgrade plan.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The ERC-1967 UUPS proxy pattern enables implementation upgrades, which could theoretically support future PQ migration at the contract level. However, no plan, specification, or design for cryptographic agility exists, and the underlying ECDSA transaction-signing dependency on Arbitrum cannot be resolved at the token-contract level.

Token-level upgradeability cannot address the fundamental ECDSA dependency of the Arbitrum/Ethereum transaction layer. Any meaningful PQ migration for RAIN requires base-layer (Arbitrum/Ethereum) changes beyond the token contract's control.

• https://whitepaper.rain.one/
• https://hacken.io/audits/rain/sca-rain-token-aug2025/

Claim: No stateful PQC signature schemes (XMSS, LMS, or similar) are used in any Rain Protocol component. All signatures are stateless ECDSA.

Coverage basis: No stateful signatures in use.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

This subfactor is N/A for the current classical-only implementation. It would become applicable if stateful PQ signatures were adopted in a future migration.

• https://arbiscan.io/token/0x25118290e6A5f4139381D072181157035864099d
• https://github.com/rain1-labs/rain-sdk

Claim: No PQ performance or resource-impact analysis exists. No assessment of how PQC signature sizes, verification costs, or key sizes would affect Arbitrum gas costs, block space, or user experience for RAIN transactions.

Coverage basis: No performance analysis performed.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Per the Note-Only Caveat Rule (Section 7.4), a missing formal performance benchmark is normally note-only unless resource constraints prevent safe use of PQ/hybrid paths. Here, no PQ path exists at all, so there are no resource constraints to evaluate. Score is 0.00 because no PQ implementation exists, not because the benchmark is absent.

If a PQ implementation existed but lacked a performance benchmark, this subfactor would be scored on the implementation and the missing benchmark would be a confidence/assurance note only.

• https://whitepaper.rain.one/
• https://rain.one/