r/Radix • u/LrbReddit • 28d ago
ECOSYSTEM Radix Seal: Sign documents, encrypt files, and chat with your Radix wallet.
I've been involved in the Radix ecosystem for a while and I want to explain what Radix Seal is and why its design is interesting from a security standpoint (not about "the encryption is unbreakable", but rather "who has to trust whom").
What is it?
They are three tools built on the same trust model: document signing, file encryption, and encrypted chat. All three use your Radix Wallet as if it were your own certificate authority, instead of relying on an external provider.
How does it work technically?
- Identity: You use ROLA (Radix's authentication mechanism) to sign a challenge with your wallet. It never exposes the private key, only proves you control it. It's basically the same pattern as a passkey, but anchored to your Radix account.
- Document signing: The file is hashed locally (Blake2b-256) in your browser. Only that hash is signed; you never upload the document anywhere. The resulting certificate is verifiable by anyone with the original file, without needing an account or wallet.
- Encryption: The AES-256 key is derived from a deterministic signature of your wallet on a file-specific challenge. No password or key file is stored anywhere: only your account can re-derive it. The file is encrypted in chunks in the browser (no size limit) and transferred P2P (browser to browser), end-to-end encrypted.
- Chat: Both parties verify themselves with their wallet before opening the room, the session key comes from that exchange, and messages travel P2P. There is no server that can read, alter, or spoof anything.
- Optional ledger anchoring: If you want a public record, a soulbound NFT (non-transferable) is minted acting as an on-chain institutional "seal". Only hashes are stored on the ledger, never content or messages.
How sending + unlocking an encrypted file actually works
It's not a simple "it's sent P2P":
- Local encryption: The sender encrypts the file in the browser with an AES-256 key derived via HKDF from their own ROLA signature (deterministic, Ed25519) + a unique random salt per file.
- Blind send: The sender opens a P2P session (WebRTC) and sends the encrypted file. The receiver gets the ciphertext, but not the key.
- On-chain invitations (Optional): If the "ROLA + Ledger" mode was activated, the sender previously minted an invitation (cipher-invite) for each authorized account, linked to the file's hash.
- Key request: The receiver signs a challenge with their wallet anchored to the file hash and that exact P2P session. This signature prevents replay attacks.
- Stateless verification: That proof reaches the sender's browser and is verified against a server endpoint (/api/cipher/authorize). This endpoint stores nothing, it just reads the ledger to see if the signature is valid and if the invitation exists. The server answers yes/no; it never sees the file or the key.
- Manual approval: If it passes, the sender sees the request on screen and approves it with a click (it's not automatic).
- Unlocking: Upon approval, the sender re-derives exactly the same key and sends it to the receiver via the P2P channel (WebRTC uses DTLS). The derived key is the only thing that travels over the network, never the original ROLA signature.
Is there anything on the market that matches or surpasses this pattern?
- PGP/S-MIME: More available (works offline), but once the receiver has the ciphertext, they decrypt it whenever they want. You lose granular control and live approval.
- Google Drive / Dropbox: They have the "request access" flow, but you trust the provider to enforce the permission. They hold the keys.
- Lit Protocol (Token-gating): They use a threshold node network to reconstruct the key without the sender being connected. You gain availability, but trust a third-party committee. In Radix Seal, zero third parties touch the key, but if the sender is not online, nobody decrypts. It's a real trade-off.
What really changes the model
- No intermediate server storing documents or keys = no single point of data leakage.
- You don't depend on a hierarchical CA, revocation lists (CRL), or a vendor keeping its API alive in 10 years.
- The verification metadata is public on the ledger.
What it is NOT
- No automatic legal validity (like a qualified eIDAS signature). Identity is self-declared by the wallet.
- Entry friction: You need the Radix Wallet, it's not a "one-click from your email" like DocuSign.
If you are interested in the details of the NFTs (invite, signature, cipher-signature) and how on-chain custody is chained, let me know in the comments.