verus.cx/dev
VerusIDHubHome

Privacy on Verus

Connecting...
Actions:

How Encrypted KYC Works on Verus

This demo stores real KYC data on the Verus blockchain with per-field encryption. Each field is independently encrypted and can be selectively disclosed to different parties without revealing the rest.

The Technology Stack

VerusID
Self-Sovereign Identity
Your VerusID (midnight.bitcoins@) is a blockchain-native identity with its own key hierarchy, capable of holding encrypted data in its contentmultimap.
Encryption
ChaCha20-Poly1305 + Sapling
Each field is encrypted using ChaCha20-Poly1305 via the identity's Sapling z-address. Each field gets its own ephemeral key pair (EPK), enabling per-field decryption.
Opaque Keys
HMAC-Derived VDXF Keys
Field names are hidden using HMAC-SHA256(walletSecret, fieldName) to derive opaque i-addresses. An observer cannot tell what fields exist or what they represent.
MMR
Salted Merkle Mountain Range
signdata with createmmr: true builds an MMR where each field is a leaf with its own salt. This enables Merkle proofs for selective disclosure.

The Four Panels

Panel 1: Identity Owner
You — the person who owns the VerusID. You can see all your data because you hold the spending key. You encrypt and store data on-chain.
Panel 2: Public Chain View
What anyone sees when they run getidentity. Opaque key names and encrypted blobs. No field names, no values — just ciphertext.
Panel 3: Service Provider
Receives only Name, Email, and age verification (Over 16: Yes/No derived from DOB). All other fields remain encrypted. This is selective disclosure.
Panel 4: Exchange / Regulator
Receives ALL fields decrypted — full KYC disclosure with attestation signature and audit trail. Required for regulated entities.

What Makes This Different

No central server holds your data. The encrypted data lives on a decentralized UTXO blockchain secured by Bitcoin merge-mining. The identity owner controls all disclosure through cryptographic key sharing — not API permissions that a platform can revoke or leak.

Field-level granularity. Unlike all-or-nothing disclosure, each field has its own encryption envelope. Share your name without revealing your SSN. Prove you're over 16 without revealing your date of birth.

Verifiable attestations. Every disclosure includes a cryptographic signature from the identity owner, creating an immutable audit trail on-chain.

Panel 1

Identity Owner

Upload & Manage KYC Data

You are the identity owner (midnight.bitcoins@). Select values for each field below. Data will be encrypted and stored on-chain under HMAC-derived opaque VDXF keys.

[ ]
Click "Update Encrypted KYC Details" to begin
Panel 2

Public Chain View

What anyone sees

Raw getidentity output. Field names are HMAC-derived opaque i-addresses. Values are ChaCha20-Poly1305 encrypted blobs.

[ ]
No data on-chain yet
Panel 3

Service Provider

Partial Disclosure

Service provider receives Name, Email, and age verification only. All other fields remain encrypted.

[ ]
Store KYC data first
Panel 4

Exchange / Regulator

Full Disclosure

Regulated exchange receives ALL fields decrypted, plus attestation signature and audit trail.

[ ]
Store KYC data first
Viewing as: Disclosure tier controls what data is visible

How Private Social Media Works on Verus

A social media profile where you control exactly who sees what — enforced by cryptography, not platform policies. No database to breach, no admin override, no terms of service loopholes.

Tiered Encryption

Public Tier
Unencrypted — Anyone Can Read
Display name, bio, public posts. Stored in cleartext in the identity's contentmultimap. Equivalent to a public profile on any social platform.
Follower Tier
Shared Viewing Key
Email, Telegram, follower-only posts. Encrypted to a dedicated z-address. When someone follows you, they receive the incoming viewing key (ivk) for this address, letting them decrypt follower-tier content.
Close Friends
Separate Viewing Key
Real name, phone, private posts. Encrypted to a different z-address. Only people you explicitly trust receive this viewing key. A follower cannot escalate to this tier.
Only Me
Spending Key Required
Private notes, recovery phrase, address. Only your wallet can decrypt this tier. Not even someone with all viewing keys can access owner-only data.

How Images & Media Work

The contentmultimap has a size limit (~4KB per value) — images don't fit on-chain. Instead, we split storage between the chain and IPFS:

Step 1
Encrypt the Image
The image is encrypted locally using encryptdata with the tier's z-address. The result is a ciphertext blob — not a valid image file.
Step 2
Upload to IPFS
The encrypted blob is uploaded to IPFS (e.g. Pinata). Anyone can download the CID, but they get meaningless ciphertext without the viewing key.
Step 3
Store Metadata On-Chain
The post data (text + IPFS CID + image hash) is encrypted together and stored in the contentmultimap. Even the existence of the image is hidden.
Step 4
Viewer Decrypts
A viewer with the tier's viewing key decrypts the post → gets the CID → fetches the encrypted blob from IPFS → decrypts it → renders the image in-browser. The decrypted image only exists in memory.

Double protection: Without the viewing key, you can't find the IPFS link (it's inside the encrypted post). Even if you guessed the CID, the image itself is encrypted. And the on-chain hash of the original image lets viewers verify it hasn't been tampered with.

Public-tier images can skip encryption and be uploaded directly to IPFS — they're meant to be seen by everyone. The CID is stored in cleartext in the contentmultimap.

Key Rotation = Access Revocation

To remove a follower's access, generate a new z-address for that tier and share the new viewing key only with current followers. The old key stops working for all new posts. This is cryptographic access revocation — no server needed.

What Makes This Different

The platform never has your private data. On traditional social media, the platform stores everything in plaintext and enforces access via software. A breach, a rogue employee, or a government request exposes everything. With Verus, the data is encrypted on a public blockchain — the "platform" is just a viewer that decrypts what the user's keys allow.

Posts are immutable and censorship-resistant. Content is stored on a merge-mined UTXO blockchain. No platform can delete your posts or deplatform you. Your identity and content persist regardless of any single service.

Portable identity. Your VerusID works across any application. Switch social media clients without losing followers, posts, or reputation. Your identity is not locked to any platform.

Vault: Unlocked via VerusID Your identity IS the master key — no password to remember

How the Password Manager Works on Verus

Your VerusID is your master password. Passwords are derived deterministically from your identity's secret spending key — they are never stored anywhere. The same identity always produces the same passwords.

Derivation Chain

Step 1
Extract Secret Key
The identity's Sapling secret spending key (sk) is extracted locally via z_exportkey. This 256-bit key is the root of all password derivation. It never leaves your device.
Step 2
Derive Vault Master
vaultMaster = HMAC-SHA256(sk, "verus.vault.v1") — a purpose-specific subkey so the raw spending key is never used directly in password generation.
Step 3
Generate Site Password
siteKey = HMAC-SHA256(vaultMaster, "site.com.1") — each site + counter pair produces a unique 256-bit key. The counter enables password rotation.
Step 4
Encode to Password
The raw bytes are encoded into a password string matching the site's requirements: uppercase, lowercase, digits, symbols — with guaranteed character class coverage.

Password Policy Profiles

Full A-Z a-z 0-9 !@#$%
Maximum entropy. Used for sites that accept special characters. Default for most entries.
Alphanumeric A-Z a-z 0-9
For sites that don't allow special characters. Still high entropy at 20+ characters.
PIN 0-9
Numeric-only for banking PINs or apps that require digit-only codes.

On-Chain Storage

Only metadata is stored in the contentmultimap — site name, username, counter, length, and charset policy. All encrypted under an opaque VDXF key. The password itself is never stored anywhere — it is recomputed from the spending key every time.

What Makes This Different

No master password to forget. Your VerusID is the master key. As long as you control your identity (or have your wallet seed), you can regenerate every password. No cloud sync, no encrypted vault file to lose.

No server to breach. 1Password, LastPass, and Bitwarden store your encrypted vault on their servers. A breach means attackers get your vault (they just need your master password). With Verus, there is no vault — passwords are derived on-demand from a key that only exists in your wallet.

Password rotation is trivial. Increment the counter from 1 to 2 — you get a completely new password. The old one cannot be derived from the new one.

Cross-device. Any device with your VerusID wallet generates identical passwords. No sync needed.

Your identity IS the master key.
Passwords are derived deterministically — never stored. The same identity + site always produces the same password.
Step 1 walletSecret = signmessage(identity, salt).hash
Step 2 siteKey = HMAC-SHA256(walletSecret, "vault." + site)
Step 3 password = base64url(siteKey).slice(0, length)
Only metadata is stored on-chain (site name, username, counter) — encrypted under an opaque VDXF key. The password itself is never stored — it's recomputed from the wallet secret every time.
[ ]
Click an entry to see details