Walrus Sessions 8: Building chatbots that actually remember you ($2,500 in prizes, ends Oct 9)

Imrankhan — Thu, 24 Sep 2026 02:19:07 +0000

Most chatbots forget everything the second a conversation ends. Ask it
something on Monday, come back Tuesday, and you're a stranger again.

Walrus Sessions 8: "Chatbots That Remember" is a live hackathon
session tackling exactly that — building (or retrofitting) a chatbot
that uses Walrus Memory to persist context across sessions, users,
and devices.

The challenge

Build or retrofit a chatbot that:

Stores and recalls context with Walrus Memory (on mainnet)
Gets deployed somewhere real and used for a few days
Gets written up — what it does, how memory was integrated, before/after, real evidence it works

Any use case counts: customer support, onboarding, tutoring, sales,
community bots, even game NPCs.

Why I got interested

I spent a few days going deep on the underlying open-source SDK
(MemWal) — not just building with it, but actually reading through the
codebase: the auth layer, the on-chain contract, the sample apps. It's
a genuinely well-built system (constant-time auth checks, on-chain
delegate-key verification, careful quarantine/replay protection), and
digging into how persistent memory is implemented securely taught me
more than most tutorials do. Ended up finding and reporting a couple of
real bugs along the way, which the maintainers fixed fast.

The details

Dates: Sept 18 – Oct 9, 2026
Prizes: $2,500 in WAL total
- Best Chatbot: $500 / $250 / $150
- Beyond the Big Two (non-Claude/GPT): 2 × $150
- Best Article: 3 × $100
- Bug Bounty (no chatbot required, just a reproducible bug on GitHub): 5 × $100
Repo: https://github.com/MystenLabs/MemWal
Full rules & submission: [https://walform.wal.app/f?formId=0x09b022796f9cb7ce24247e3097c5c8ae2b414317c90c8aeb6ce335e7caf31ff5]

If you've ever wanted an excuse to actually understand how persistent,
encrypted agent memory works under the hood instead of just calling an
API — this is a good one to dig into, whether you build the full
chatbot or just go bug-hunting in the SDK.

What I learned auditing an open-source AI-memory SDK (and the bug I found in it)

Imrankhan — Thu, 24 Sep 2026 02:05:46 +0000

Most chatbots forget everything the moment a conversation ends. I spent
a few days digging into an open-source project (MemWal / Walrus Memory)
that tries to fix that — persistent, cross-session memory for AI agents
— and ended up doing a full security review of the codebase along the
way. Here's what actually stood out.

## The interesting part wasn't the AI

Everyone talks about embeddings and semantic recall when they talk about
"AI memory." The part that actually breaks in production is much more
boring: ownership checks.

Any system where User A's data must never leak into User B's session
lives or dies on a handful of WHERE user_id = ? clauses. Get one of
them wrong, and no amount of good embedding quality saves you.

## The bug

While reviewing a sample chatbot app built on this SDK, I found a vote
endpoint with a subtle but real bug:

The "does a vote already exist?" check only looked up rows by messageId.
The actual UPDATE was scoped by messageId AND chatId.

Any user who could see a message in a public chat (message IDs are
rendered right in the UI) could submit a vote using their own chat
ID but a stranger's message ID. Since no vote existed yet for that
message, it silently inserted a mismatched row.

The nasty part: the next time the actual message owner tried to vote
on their own message, the lookup found the attacker's row (again,
scoped only by messageId), the UPDATE matched zero rows because the
chatId didn't match, and the API returned 200 "Message voted" —
while silently doing nothing. The real owner could never vote on that
message again, and had no way of knowing why.

Zero errors thrown. Zero logs. Just a permanently broken feature for
one specific user, triggered by any other logged-in user.

I filed it, the maintainers confirmed and shipped a fix within days:
scope the existence check the same way as the update.

## The bigger lesson

The core SDK, the auth layer, the on-chain contract — all of it was
extremely well hardened. Constant-time comparisons, quarantine states,
counter-based replay protection, the works. The bug wasn't in any of
that. It was in a sample app that gets far less scrutiny than the
"real" infrastructure around it.

If you're reviewing (or building) a system like this, the example apps
and demos are usually where the actual bugs hide — not the core library
everyone stares at.

## A second, quieter finding
**
I also found a spot where one sibling app (a login flow) had an
on-chain verification step that its near-identical twin app was
missing entirely — same function available in the codebase, just never
called on one specific path. Lower severity (the affected app is
explicitly demo-only and the riskiest downstream action was already
disabled), but the same underlying lesson: **when you fix a security
issue in one place, check every place that duplicates that logic.
Copy-pasted auth code doesn't get security fixes for free.

If you're building anything with persistent memory/state across
sessions for an AI agent, happy to talk through what to watch for.
This was part of a hackathon bug-bounty track, but the lessons apply
to basically any multi-tenant app.

This was part of Walrus Sessions 8

If any of this sounds interesting, Walrus Sessions 8: "Chatbots That
Remember" is a live hackathon session running Sept 18 – Oct 9, 2026,
with $2,500 in WAL prizes. The challenge: build (or retrofit) a
chatbot that uses Walrus Memory to remember context across sessions,
users, and devices — any use case counts (support, onboarding, tutoring,
game NPCs, community bots).

There's also a standalone Bug Bounty track (5 × $100) if finding
bugs like the one above is more your thing than building a full chatbot
— no chatbot required, just a reproducible bug filed on GitHub.