AI network token
Render RENDER
Render (RENDER) is a standard SPL token on Solana, migrated from Ethereum (RNDR) in November 2023 via a Wormhole-powered one-way upgrade bridge. Under the QRI Token Inheritance rule (Section 7.2), RENDER inherits Solana's cryptographic posture: all spend authorization uses Ed25519 elliptic-curve signatures, which are vulnerable to Shor's algorithm. The Render Network Foundation has published no cryptographic inventory, no quantum risk assessment, and no post-quantum migration plan. Governance multisigs controlling node emissions and burns use classical Ed25519. The Wormhole bridge dependency introduces additional quantum-vulnerable Guardian signatures (ECDSA secp256k1). Solana L1 has active quantum research (Falcon implementations on GitHub, Blueshift Winternitz Vault, Jump Crypto migration analysis) but nothing in production. RENDER's QRI Score of 1.00 reflects near-total absence of quantum readiness: ~$1B+ in market cap is entirely secured by quantum-vulnerable cryptography with no protection, no migration path, and no assessment at the token-project level.
Token InheritanceRoadmap OnlyQuantum Risk Assessed
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
- Active production spend authorization remains entirely Ed25519 (ECC) on Solana — all RENDER transfers and governance actions are quantum-vulnerable.
- No public cryptographic inventory or quantum risk assessment published by the Render Network Foundation.
- Governance multisigs (Node Emissions ATA: DUAv3AyTzJhDuPexKTJSj82wgb7X6AghjifbVC8NYQCd; Burn ATA: GqE7wcwRw86xxMz4pNq5cV3BkM64h3bvajQRQbigYqTX) use classical Ed25519 signatures.
- Wormhole upgrade bridge Guardian network (19 Guardians, 13-of-19 threshold) uses ECDSA secp256k1 signatures — quantum-vulnerable bridge dependency for legacy RNDR-to-RENDER migration path.
- Material long-exposure quantum-vulnerable value (~$1B+ market cap) exists with no migration, freeze, deprecation, burn, recovery, or policy path at the token level.
Key Risks
- All RENDER spend authorization depends on Solana's Ed25519 signatures — a quantum attacker recovering private keys from on-chain public keys could steal any RENDER balance.
- Governance takeover risk: token-weighted voting on Nation.io uses classical signatures. A quantum attacker could forge votes or compromise the Foundation's multisig keys to push malicious protocol upgrades.
- Wormhole Guardian compromise: the 19-Guardian network uses ECDSA secp256k1. A quantum attacker compromising 13 of 19 Guardians could forge cross-chain messages affecting the integrity of locked/burned RNDR during upgrades.
- Long-exposure public keys: every Solana address that has signed a transaction has exposed its Ed25519 public key on-chain. Over 60% of funded Solana addresses have made at least one outgoing transaction (per Solana Beach data cited in secondary analysis), meaning most RENDER holders have exposed public keys vulnerable to offline quantum attack.
- Legacy RNDR on Ethereum remains tradable on some exchanges with exposed ECDSA public keys — bifurcated exposure across two quantum-vulnerable chains.
- No freeze, deprecation, burn, or emergency migration mechanism exists at the token level to address quantum-vulnerable value if a cryptographically relevant quantum computer emerges.
- Dormant unmigrated RNDR on Ethereum and Polygon represents quantum-vulnerable value with no enforced upgrade deadline and no policy mechanism to address it.
Assurance Notes
- RENDER is a standard SPL token on Solana and inherits the base-layer cryptographic posture of Solana (Ed25519), which is currently entirely classical and vulnerable to quantum attacks.
- The 2017 OpenZeppelin audit applies only to the legacy RNDR ERC-20 crowdsale contracts on Ethereum and is completely scope-mismatched for the current Solana SPL token or any quantum-critical evaluation.
- No formal quantum-specific incident-response playbook, migration roadmap, or threat model exists for the Render Network Foundation or the RENDER token.
- Protocol treasuries, node emissions, and governance multisigs rely on classical Solana multisig programs, exposing critical value-at-risk to long-exposure quantum key-recovery attacks.
- Solana L1 has active quantum research (Falcon implementations, Blueshift Winternitz Vault, Jump Crypto migration analysis) but nothing in production that provides protection for RENDER transactions.
Non-Scoring Caveats
- The 2017 OpenZeppelin audit is stale and scope-mismatched for current production — this is an assurance-only caveat (recorded in audit_freshness and assurance notes, not score-reducing).
- Solana L1 quantum readiness work (Falcon implementations, Winternitz vault, SIMD proposals) exists at research/testnet stage but does not constitute token-level production protection. This is context, not a scoring factor.
- The Render upgrade bridge is one-way (ETH→SOL only); value cannot flow back from RENDER to RNDR. The bridge dependency risk is about the Wormhole Guardian signature scheme securing the locked/burned RNDR on Ethereum, not about two-way flow.
- No formal performance benchmark exists for PQC on Solana — this is an assurance-only caveat since no PQC is deployed.
- Legacy RNDR on Ethereum and Polygon remains tradable on some exchanges but is no longer maintained by the Render Foundation. This creates a bifurcated exposure surface, but the foundation's primary support is RENDER on Solana.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
Claim: Render has not published a cryptographic inventory or quantum threat model.
Coverage basis: No evidence found in official documentation, GitHub RNPs, knowledge base, or monthly reports (through April 2026). The Nov 2025 RenderCon conversation between Jules Urbach and Raj Gokal briefly acknowledges quantum threats but does not constitute an evidence-backed risk assessment or cryptographic inventory.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No public cryptographic inventory published by Render Network Foundation
Assurance: Solana Foundation has published quantum readiness information (solana.com/news/quantum-readiness) and Jump Crypto published detailed migration path analysis (April 2026), but these are L1-level, not Render-token-specific assessments.
The 2025 RenderCon conversation is the only Render-specific acknowledgment of quantum threats. It is informal and does not inventory specific vulnerable cryptography, affected assets, or attack assumptions.
Production Cryptographic Protection
Spend authorization / transaction signatures PQC or hybrid-PQC on mainnet
Claim: All RENDER spend authorization uses Solana's native Ed25519 signature scheme — entirely classical, no PQC.
Coverage basis: RENDER is a standard SPL token. Token transfers require Ed25519 signatures verified by the Solana runtime. Confirmed by SPL token contract address rndrizKT3MK1iimdxRdWabcF7Zg7AR5T4nud4EkHBof on Solana mainnet, Solana protocol documentation, and Render Network official channels.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Active production spend authorization remains entirely Ed25519 (ECC) on Solana
Assurance: Solana has Falcon PQC implementations on GitHub (Anza, Firedancer) and a 3-step quantum roadmap, but nothing is deployed on mainnet. SIMD-0416 proposes a Falcon signature verification syscall for smart contracts but is not yet live.
As a standard SPL token, RENDER's spend authorization is entirely dependent on Solana's Ed25519 signature verification. There is no token-level custom signature scheme.
Production Cryptographic Protection
Account/address/key-derivation design prevents long-exposure quantum-vulnerable ownership paths
Claim: Solana accounts expose Ed25519 public keys on first transaction. No PQ/hybrid controls exist at the RENDER token level.
Coverage basis: Solana's account model derives addresses from Ed25519 public keys. Once an account signs a transaction, the public key is visible on-chain. Over 60% of funded Solana addresses have broadcast at least one transaction (per Solana Beach data cited in secondary sources). RENDER inherits this exposure model.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Material long-exposure quantum-vulnerable value exists with exposed public keys on-chain
Assurance: Blueshift's Winternitz Vault provides an opt-in quantum-resistant custody path on Solana, but it is a separate application and not integrated with standard RENDER token transfers. Jump Crypto notes that Solana's Ed25519 key derivation (SHA-512 seed protection) enables a migration path via ZK-proofs, but this is not implemented.
The Solana account model means every RENDER holder who has ever sent tokens has an exposed Ed25519 public key vulnerable to offline quantum key-recovery attacks.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected from quantum key-recovery
Claim: 0% of RENDER value-at-risk is protected. All ~$1B+ market cap is on quantum-vulnerable Solana (Ed25519) with legacy exposure on Ethereum (ECDSA).
Coverage basis: Market cap ~$1.05-1.12B, circulating supply ~518.7M RENDER (CoinMarketCap/CoinGecko, June 2026). No PQC protection exists for any RENDER holdings. Solana has no production PQC. Legacy RNDR on Ethereum is also quantum-vulnerable.
Implementation score: 0.05 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: ~$1B+ market cap entirely secured by quantum-vulnerable Ed25519/ECDSA with no migration path
Assurance: Implementation Score 0.05 reflects <25% coverage per Section 9.3.1 thresholds. Even this minimum score may overstate protection since truly 0% of value has quantum-resistant protection. The 0.05 floor is a structural artifact of the scoring table.
Coverage calculation is straightforward for a transparent token: 0% protected. The <25% threshold yields the minimum Implementation Score of 0.05 (= 1/20 subfactor weight).
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: No quantum-specific migration roadmap exists for RENDER. The Solana L1 roadmap exists but is not activated and has no token-specific provisions.
Coverage basis: Solana Foundation's 3-step quantum roadmap (research → adopt PQC for new wallets → migrate existing wallets) has no activation criteria, timeline, or token-specific coordination plan. No RNP addresses quantum migration. The Render monthly reports through April 2026 contain zero quantum references.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Solana's roadmap includes: 1) continue Falcon research, 2) adopt PQC for new wallets if quantum becomes credible, 3) migrate existing wallets. No dates, no activation criteria defined. Jump Crypto's April 2026 analysis provides detailed technical migration paths but these are research, not an activated plan.
The absence of a token-level roadmap is particularly concerning given RENDER's ~$1B market cap and the governance/treasury multisig exposure.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit for quantum-critical scope
Claim: No independent audit exists for PQC implementation at the RENDER token level. The only identified audit is a 2017 OpenZeppelin review of the legacy RNDR ERC-20 contract.
Coverage basis: OpenZeppelin audit (September 2017) covers the original RNDR crowdsale contract on Ethereum — stale (9 years old) and scope-mismatched (ERC-20, not SPL; classical, not PQC). Otter Security reviewed the Wormhole bridge code for the upgrade portal, but this is a bridge audit, not a token cryptographic audit.
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Audit is absent for the current production scope. The 2017 audit is stale and scope-mismatched. Even if PQC were deployed, no audit would exist for it. This is classified as assurance-only because the absence of an audit does not independently create a quantum-attack path — the vulnerability (no PQC deployed) is captured by Category 2 subfactors.
Score is 0.0 because no PQC implementation exists to audit, not because the audit is absent. If PQC were deployed and unaudited, this would affect Confidence, not the QRI Score (per Section 6.4).
Report metadata