SDK — “Continue with Lethe”

Lethe is a primitive, not a destination. The same vault one person owns is a read surface any Sui app can build on — memory becomes shared infrastructure the user controls, not a moat each app rebuilds from zero. One app is one demand source; a primitive is a demand category.

Apps integrate Lethe to warm-start their users with memory the user already owns: your new trading app doesn’t start from zero — it asks for a grant and already knows the user is a no-leverage momentum trader. @lethe/sdk wraps the same paths the Pulse demo runs in production.

Status: in-repo, not on npm yet. Install from the workspace — packages/sdk on GitHub.

Read a vault in ~10 lines

import { LetheClient, GrantDeniedError } from "@lethe/sdk";

const lethe = new LetheClient(); // testnet defaults
const vault = await lethe.getVaultByOwner("0x4bf2…8077");
console.log(vault.entries.length, "memories ·", vault.authorized.length, "apps granted");

try {
  const { entries } = await lethe.requestReadAsGrantee({ ownerAddress: vault.owner });
  console.log(entries.map((e) => e.text)); // decrypted, grant-gated
} catch (e) {
  if (e instanceof GrantDeniedError) console.log("user revoked — you know nothing");
}

Runnable version: cd packages/sdk && pnpm example — it reads a real testnet vault and prints live Suiscan/Walrus links.

Surface

• getVaultByOwner(address) / listEntries(vaultId)— the vault’s public on-chain metadata (entry refs, authorized apps), straight from a fullnode.
• requestReadAsGrantee({ ownerAddress }) — decrypted entries through the server-mediated grant gate; throws GrantDeniedError on a revoked or never-given grant (HTTP 403), enforced against the live on-chain list.

Why server-mediated today

Seal key servers evaluate decryption policies by dry-running them on-chain, and dry-runs reject address-owned objects for senders that don’t own them — so a third-party app cannot yet run its own decrypt session against a user’s owned vault. Today decryption happens in the owner’s browser session or through a grant-enforcing endpoint like the one this SDK calls. Independent app decrypt sessions arrive with the shared-registry policy — roadmap. The grant/revoke enforcement itself is already on-chain and machine-verified (19/19, including deny-universality of seal_approve).