engram.
$engram
memory layer on solana · specimen 001
your agent's memory,
owned by your wallet.

any framework, one wallet — the memory follows. append-only on solana: nothing rewritten, nothing lost.

see it remember read the program
fig. 01 — scripted session

two frameworks, one memory.

agent a (chat) commits three facts to the vault. agent b (cli) recalls them through the same wallet — different framework, same memory.

step 0/10
framework a · chatremember ×3
7xNd…3kQm
same wallet
same memory
framework b · clirecall ×3
scripted session · every tx is real
fig. 02 — memory explorer

the lab journal.

every commit the program writes, streamed from mainnet. append-only — rows are only ever added, never edited.

1,482 commits
specimenwallettaghashslotsig
showing last 12 commits program EnGr…w1S ↗
fig. 03 — proof of work

all of it is ours.

one anchor program, one sdk, one mcp server. read the code, verify the build, run it yourself.

program EnGrm4kQ9vTzXcR2mWyBhNfLdUjP7oAeK3sHqD8pVw1S solscan ↗
verified build solana-verify · hash matches repo osec.io ↗
sdk npm i @engram/sdk
mcp server npx engram-mcp
repo github.com/engram-sol/engram github ↗
CA · $engram revealed at launch
fig. 04 — lab notes

how it holds.

01how is memory private?+
content is encrypted client-side — the key derives from a wallet signature (signMessage → hkdf). only hashes and ciphertext ever touch the chain; the site never asks for token approvals.
02why append-only?+
memory you can't rewrite is memory you can audit. there is no edit and no delete instruction — history reconstructs from transaction logs, at zero rent per write.
03what moves between frameworks?+
everything. the vault belongs to the wallet, not the app — any framework that speaks mcp gets remember / recall / list_memories with one command: npx engram-mcp.
04what are the v1 limits?+
inline payloads up to 256 bytes — anything bigger stores off-chain (arweave uri on-chain). semantic search stays local in v1; the chain keeps hashes, tags and order.
connect wallet