Security Architecture
The website orchestrates. The extension handles secrets.
Nythera is designed so the website does not need to see seed phrases, private keys, passwords, or recovered plaintext.
The website manages wallet connection, metadata, trusted contacts, CDR writes, and recovery orchestration. The browser extension handles secret entry, encryption, recovery decryption, and temporary display.
System boundary
What each part is allowed to do
Nythera uses clear trust boundaries. The website is useful, but it is not trusted with plaintext secrets. The extension is the trusted plaintext boundary.
Step 1
Website
Metadata, wallet actions, access checks, CDR orchestration
Step 2
Extension
Secret entry, TDH2 encryption, recovery decryption, display
Step 3
Story CDR
Encrypted storage and access-controlled recovery
Core invariant
Plaintext should not enter the website
For text secrets, Nythera avoids putting plaintext into website React state, DOM nodes, website storage, or website postMessage responses.
The website can display status, errors, and vault metadata. It should not display or receive the secret itself.
Technical response boundary
Allowed website-facing data includes ciphertext, success, error, vault IDs, transaction hashes, and metadata.
Disallowed website-facing data includes secret, plaintext, decryptedData, fileBytes, AES keys, or recovered file payload bytes.
Security posture
What Nythera improves
Nythera does not make self-custody risk disappear. It narrows where plaintext can exist and makes recovery possible without handing a seed phrase to a website or another person upfront.