lethedocs

Security

Formally verified
19/19

sui-prover checks on the vault’s invariants, including I5 deny-universality.

cd contracts/memory_specs && sui-prover

Seal threshold encryption

Memories are encrypted in your browser with Seal — Mysten infrastructure, like Walrus and zkLogin. Decryption keys are released by a decentralized committee of key servers, and only after the committee dry-runs our on-chain policy memory_policy::seal_approve and it approves the caller. Lethe runs none of the key servers.

What servers can and cannot see

Can see

The chat messages you send to the LLM during a conversation (that is how any hosted model works), your address, and your vault’s public on-chain metadata — entry count, authorized apps — visible to everyone on Suiscan.

Cannot see

Your memories. The store route pins ciphertext to Walrus; plaintext and key material never reach a Lethe server in Seal mode. Decryption happens in your browser under a session key you sign.

Honest caveat: entries written before the Seal upgrade (legacy mode) were encrypted server-side with AES; those remain readable by the legacy path until re-written. New entries are Seal-encrypted end-to-end. A manual provider flag keeps the legacy mode available as a fallback.

Formally verified — 19/19

The vault’s invariants are machine-checked with sui-prover: owner-only writes, append/remove exactness (universal quantification, not sampling), grant/revoke never touch the log, fresh vaults start empty — and I5, deny-universality: seal_approve provably aborts for every sender that is neither the vault owner nor currently granted, for all identities. Reproduce:

brew install asymptotic-code/sui-prover/sui-prover
cd contracts/memory_specs && sui-prover   # 19/19

Policy privacy vs cryptographic privacy

Most private AI services offer policy privacy: a commitment, written in a privacy policy, that the operator will not read your data — while the infrastructure still could. Lethe is built for cryptographic privacy: memories are encrypted before they leave your browser, the decryption keys sit with a decentralized key-server committee, and the release policy is enforced by on-chain code whose deny-side is machine-proven (19/19, I5 deny-universality). The difference is verifiable: one model asks for trust, the other removes the need for it. Venice promises not to look. Lethe can’t look.

Revoke = the key servers stop approving

Revocation is not a soft delete. The policy reads the live authorized vector on-chain at decryption time, so the moment your revoke transaction lands, the committee stops releasing keys for that app — by proof (I5), not by promise.

Known limits, stated plainly

  • Third-party apps read through a server-mediated grant gate today; independent app decrypt sessions need the grant state in a shared object (key servers reject owned-object dry-runs for non-owner senders) — that registry is on the roadmap.
  • Message size is not concealed by encryption; entry counts are public on-chain.
  • Testnet infrastructure (public Walrus publisher/aggregator) has no SLA.