Collect subscribers privately.
Encrypt email addresses for the project owner. The owner can decrypt the list locally; the stored record does not need to reveal the email.
Open infrastructure.
Private information.
ITZA separates access from confidentiality. Your app decides who can do what. Encryption decides who can read sensitive content.
The network stores it.
Your keys open it.
Sensitive fields can be encrypted in the user’s browser before they enter a transaction. The network stores ciphertext. The intended recipients hold the keys to read it.
- On the device
Encrypt for the recipient’s wallet.
- On the network
Store and replay the ciphertext.
- With the recipient
Decrypt using their own keys.
Keep the useful part public.
Keep the personal part private.
Share with the right merchant.
Keep listings searchable. Encrypt a delivery address for the buyer, then share a separately encrypted copy with the seller at purchase.
Give each person their copy.
Share messages and documents using recipient encryption. Search private information on the user’s device after decryption.
Protect the content.
Control the release.
Use opt-in post-quantum encryption and signatures. Combine encrypted content with time- or contract-controlled release for documents, media and future events.
PayloadPost-quantum encryptionBLS release layer
How the layers work
In the layered construction, BLS protects a post-quantum ciphertext. After BLS release, the recipient still needs the appropriate key to decrypt the content. BLS itself is not post-quantum; its versioned release mechanism can support a future replacement. Post-quantum signatures are available separately for verification.
Clear boundaries.
Better choices.
What does contract-scoped SQL protect?
Only the owning WASM contract can query its SQL database directly. Other contracts and RPC endpoints cannot issue arbitrary queries against it. Your app’s contract decides what its query functions return and which callers are authorized.
What is visible on a public network?
Public-cluster transactions, ledger snapshots and stored SQL data are available to node operators and through ledger data. Plaintext fields and exposed metadata are therefore public. Encrypt sensitive content on the client before sending it; access checks alone do not hide ledger data.
Can SQL search encrypted fields?
Public fields can be searched using SQL. Encrypted private fields are decrypted and searched on the user’s device. ITZA does not run ordinary plaintext SQL over ciphertext.
What if my app needs sensitive plaintext SQL?
A private cluster can keep validators inside an owner-controlled boundary with an encrypted ledger. This is a different privacy model from client-side encryption on public infrastructure.
Which encryption options are available?
Wallets support standard encryption using keys derived for X25519 from their Ed25519 identity. Users can opt in to additional post-quantum keys. Apps choose the appropriate encryption and signature functions through itza.js.