Threat Model

Last updated: 2025-01-08?Audience: Users, engineers, and security reviewers?Contact: [email protected]

This document explains what we protect, who we defend against, and how. It covers the PRC web wallet (wallet.prc.network) and related services that the wallet directly uses.

Purpose & Scope

In Scope

� Key generation, storage, backup, import/export
� Transaction signing & submission
� dApp connections & permissions (EVM/Vite)
� Update/download integrity
� Network communication with PRC services and public RPCs

Out of Scope

� Custodial services, CEX accounts, KYC of partners
� User's OS/hardware integrity and non-PRC browser extensions
� Chain protocol bugs or validator collusion

Assets We Protect

Private keys & seed phrases (including optional passphrase)

Transaction integrity & intent (prevent signing something the user didn't mean)

Wallet state privacy (addresses, balances, activity where feasible)

Software update integrity (you're running what PRC shipped)

Account connections & approvals (dApp permissions)

Adversaries & Assumptions

Adversaries

� Phishers/social engineers tricking users into revealing seeds or approvals
� Malware (clipboard hijack, keyloggers, browser injectors)
� Network attackers (MitM, DNS spoof, BGP hijack)
� Supply-chain attackers (malicious dependencies, CI/CD compromise, CDN tamper)
� Infrastructure intruders (API/server compromise)

Assumptions

� User's device can be kept reasonably free of malware
� Users can securely store offline backups
� The underlying chains are functioning as designed

Security Architecture

We avoid unverifiable claims. Items tagged (Planned) will link to changelog when shipped.

Key generation & recovery

� Keys/seed are generated client-side; never sent to PRC servers
� Deterministic wallet (BIP-39/44) for portability across wallets
� Optional passphrase derives a distinct wallet (advanced users)
� Backup is offline-first; no cloud/screenshot prompts

Local protection (web wallet)

� Seed/private keys are held in memory only during critical operations and never written to localStorage
� Encrypted at rest in IndexedDB with a key derived from user secret (PIN/biometric) via strong KDF
� Auto-lock after inactivity; clipboard clears for sensitive data (Planned)

Network communication

� All traffic over TLS 1.2+; HSTS enforced on prc.network subdomains
� RPC endpoints chosen for reliability; user-selectable custom RPCs (with warnings)
� WalletConnect (if used) via official libraries; session data minimized

dApp permissions

� Clear permission prompts; per-site approvals; easy revocation
� Warnings on risky approvals (unlimited spend, blind signing)
� Phishing URL heuristics and known-bad lists (Planned)

Build & release integrity

� Reproducible build targets (Planned); content-hashed assets
� Code signing/checksums + PGP for downloads; hashes listed on /download
� Subresource Integrity (SRI) for critical scripts (Planned)
� Release provenance record (e.g., Sigstore/cosign) (Planned)

Threats & Mitigations

This matrix shows our defense-in-depth approach across different attack vectors:

Threat Category	Example Attacks	Our Mitigations	Residual Risk
Client-side	Fake sites, seed harvesters, clipboard swaps, malicious extensions	HSTS, anti-phishing education, domain hints, clipboard checksum preview	If device compromised, keys can be stolen. Use hardware wallets for large funds.
Network-level	MitM, DNS spoofing, BGP hijacking	TLS everywhere, HSTS, DNS monitoring, user-pinned RPCs	Sophisticated network attacks still possible; always verify domain
Infrastructure	Server/CDN/CI compromise, malicious builds	Limited CI permissions, signed releases, integrity checks, SRI	Time-window before detection; users should verify download hashes
Cryptographic	Weak RNG, KDF errors, key extraction, side-channels	WebCrypto CSPRNG, strong KDF (Argon2id/PBKDF2), memory-safe handling	Implementation bugs possible; publish audits and fixes promptly
Physical	Lost/stolen device, shoulder surfing	App lock (PIN/biometric), auto-lock, masked seed views, re-auth for critical ops	If attacker has seed/passphrase, funds at risk�move to fresh wallet

User Responsibilities

Shared security: Self-custody requires active participation from users to maintain security.

Back up seed (and passphrase if used) offline in 2 separate secure places

Never share seed/passphrase; PRC will never ask

Verify domain (prc.network) and beware look-alikes

Keep device OS/browser up to date; avoid untrusted extensions

Use small test sends to new addresses; verify on a block explorer

Consider hardware wallet for significant balances

Audits & Testing

We commission independent security assessments and publish results on /security/audits.

Planned Assessments

� Client application: code review & penetration testing
� Infrastructure: configuration & CI/CD review
� Cryptography review: implementation review of keygen/KDF/encryption

We do not list auditors or badges until contracts are completed and reports are public.

Incident Response & Disclosure

Report Vulnerabilities

[email protected] (PGP available)

� Acknowledgment within 48 hours
� Coordinated disclosure
� Safe-harbor language available

Emergency Response

� Security notices on /status
� Release notes on /support/changelog
� Keys at risk? Immediate fund migration recommended

Trust Boundaries

User device?Web UI?PRC services/RPCs?Blockchain nodes

Key principle: Private keys must never cross from device to network. RPCs see signed transactions, not secrets.

Security Roadmap

Strict CSP & SRI for static assets

Hardware wallet support for cold signing

Reproducible builds + public build provenance

Phishing protection (blocklists/heuristics)

Formal crypto review and published report

Disclaimers

Crypto is inherently risky. PRC is non-custodial; only you control recovery materials.

This document describes current design and intent. Some controls are Planned and will be linked to changelog entries when released.

We will revise this page as implementations evolve and audits complete.

Security Architecture Audits Responsible Disclosure Changelog Account Recovery Status Page

Threat Model FAQs

Do you store private keys?

No. PRC is non-custodial. Keys are generated and stored encrypted on the user device.

How do you mitigate phishing?

Education, domain hints, safe UI patterns, and planned blocklists/heuristics. Always verify the domain.

Can PRC recover my wallet?

No. Recovery requires the user mnemonic (and optional passphrase).

Where are secrets stored?

Encrypted vault in IndexedDB secured by Argon2id-derived keys (with device-appropriate parameters).

Where is incident status published?

See /status for incidents and maintenance.