lethedocs

Concepts

Memory

A memory is one durable fact (“sizes positions by volatility, never by conviction”) with a kind (trading-style, holding, market-view, preference, fact) and a timestamp. Facts are extracted from chat or derived from your on-chain activity — and only saved when you confirm.

The vault object

Your vault is a memory::Memory object on Sui, owned by your address. It holds the list of blob references and the list of authorized app addresses. The Move package:

Writes (add_entry, remove_entry, grant, revoke) are owner-only — machine-checked, not just tested (see Security). All writes are gasless through Enoki sponsorship.

Because the vault is a Sui object and not a row in a database, its authorization state lives on-chain — which means other Move contracts can be written to compose against it, not just off-chain apps. Today Lethe ships the off-chain read path (the SDK); on-chain composition is a roadmap direction unique to the object model.

Grant / revoke

Granting an app appends its address to the vault’s authorized vector; revoking removes it. Both are owner-only transactions you can verify on Suiscan. Apps read through a grant-gated path: revoked means zero entries, immediately.

01
grant
02
app reads
03
revoke
04
key servers stop approving

Walrus blobs

Each memory’s ciphertext lives on Walrus, fetchable from any public aggregator — storage is verifiable, not a claim. Example (ciphertext, as it should be): GbB45iJxmH5F8Si_78GG_macC6WeLS64jXjx7x852Eg. Forgetting an entry removes the on-chain reference; the orphaned ciphertext on Walrus stays undecryptable.

Seal identity format

Blobs are encrypted under the identity [package id][vault object id][nonce] using Seal threshold encryption. The package id namespace is the ORIGINAL package id; decryption requires the key-server committee to dry-run memory_policy::seal_approve and see the caller as the vault owner or a currently-granted app for that exact vault. Wrong vault prefix → denied, revoked app → denied.