Carry: Verifiable Agent Answers, Built on Walrus Memory
Carry adds a proof and access layer on top of Walrus Memory, so every answer carries a verifiable receipt of what an agent remembered and whether it was authorized to use it.
Carry is an accountability layer for AI agent memory, built on Walrus Memory, Seal, and Sui. Every memory-based answer an agent gives comes with a verifiable receipt recording what memory was used, what was blocked, and whether the agent was authorized to access it. The access policy lives on Sui, while the memory itself is encrypted with Seal and stored on Walrus as real blobs. Carry was one of the winning projects in the Walrus track at the Sui Overflow hackathon.
Key takeaways
- Carry is a proof and access layer built on Walrus Memory – it checks an agent's access before any memory is retrieved, so blocked memory never reaches the model.
- Every answer comes with an Answer Receipt showing which memories were used, which were blocked, and whether each one still resolves to a real Walrus blob – and refusals get receipts too, so a denial is as verifiable as a recall.
- The receipt isn't trusted on Carry's word: anchoring it makes a Sui Move contract recompute the verdict against the onchain policy, so a receipt that claims access to a revoked area is rejected by consensus.
This is the third build from the Walrus track at Sui Overflow we've taken apart, after Suize put website publishing in an agent's hands and Kraterion turned object storage into something you own. Carry goes after a different problem: not where an agent's memory lives, but whether you can trust what it remembered.
With Carry, you don't have to trust that an agent used the right memory. The receipt shows it: which memories it pulled in, which it was blocked from, and whether it was ever cleared to see them. We talked to the Carry team about the rule that shaped the whole architecture: check access before the memory is ever retrieved.
When you can't see what your agent remembered
When an assistant tells you it remembered something from an earlier conversation, you usually can't check any of the things that matter. What exact memory was retrieved. Where it came from. Which agent stored it. Whether this agent was supposed to have access. Whether something was blocked. Whether that memory actually shaped the answer.
It gets harder the moment more than one agent is involved. Once several agents, possibly running on different models, share the same user context, memory stops being one app's private state and becomes something passed between systems, still with no way to inspect the path that led to a given result. Carry starts from a simple position: if memory is going to influence what an agent does, there should be a way to inspect and verify how it got there.
What Carry is, and who it's for
Carry sits between an agent and its long-term memory. When an agent wants to recall something, Carry checks that agent's access policy first; if the check passes, the memory is fetched and added to the model context, and if it fails, the protected memory never reaches the model. Because the memory lives underneath the models rather than inside one assistant, it is cross-model by design: teach a fact to an agent running on GPT-4o, and another agent on Claude can recall it later with the proof still attached.
Carry is designed for developers building AI agents, especially systems where multiple agents or models need to share long-term memory without turning that memory into a black box.
Inside the build
Carry is built on Walrus Memory, Seal, and Sui, and it keeps a clean split between the parts that orchestrate memory and the parts that have to be independently verifiable. The memory itself lives in Walrus Memory: each memory is encrypted with Seal and written to Walrus as a real blob, addressed by its blob ID and validated live against the relayer. Carry handles retrieval and orchestration on top, while Sui holds and evaluates the authorization state and anchors the proof. Only the parts that matter for verification go onchain, so they live somewhere Carry itself can't silently rewrite later.
Two things make "verified" mean something. First, when an answer is generated Carry re-checks each memory's blob through the Walrus aggregator, so a receipt that says a memory was used is pointing at something that actually resolves, not a label in a UI. Second, the access gate is enforced onchain: Carry deploys a Sui Move package, carry::access, where the agent-by-area policy lives as a shared object. Granting or revoking access is a Sui transaction, the OwnerCap stays in the organization's wallet, and anchoring a receipt makes the chain recompute the verdict, checking that every memory used was actually allowed for that agent.
Carry isn't locked inside its own app, either. It ships an MCP server, so agents in Cursor, Claude Code, or Claude Desktop get the same gated, receipted memory: a recall returns the memory plus proof of what was used and what was blocked, and revoking access means the agent truthfully can no longer reach it.
Two things that shaped the build
Check access before you retrieve. Carry runs the steps in order: a request comes in, access is checked, only the allowed memory is retrieved, the context is built, the answer is generated, and a receipt is created – rather than retrieving everything and filtering later. Once something is inside the model context, it is too late to pretend it was never exposed, so the permission check has to come before the memory is fetched.
Don't treat your own backend as the final word. When a receipt is anchored, the Sui contract recomputes the verdict against the onchain policy instead of accepting Carry's result. A receipt that claims an agent still had access that was already revoked comes back from consensus as not authorized. The chain catches the lie, rather than trusting Carry's server that it was true.
Where Walrus fits
Walrus is where the memory actually lives. Through Walrus Memory, each memory is encrypted with Seal and written to Walrus as a real blob, and that is what gives a receipt something concrete to point back to. Instead of asserting that some memory existed somewhere inside Carry, the receipt is tied to an actual Walrus blob and re-checked through the aggregator when the answer is produced, so "verified" means the memory resolves, not that Carry says so. Receipts themselves can be anchored on Walrus too, which makes the history of an answer tamper-evident. Walrus and Walrus Memory hold the memory and artifacts, Sui holds the policy and recomputes the verdict, and Carry orchestrates how agents use the memory.
Lessons learned
The subtle part of building on Walrus wasn't uploading data; it was making sure that when Carry points to something on Walrus, the reference actually contributes to a proof rather than becoming another URL Carry happens to store. That pushed the team to think much more carefully about what belongs in a receipt and what an independent verifier should be able to reconstruct from it.
The biggest lesson was that an audit log and a proof are not the same thing. You can build a very detailed audit log, but if the app controls the database, generates the log, and decides what the user sees, there is still a trust assumption underneath it. That is why the receipt points back to the Walrus blob instead of only an internal ID, and why the onchain path recomputes the verdict instead of accepting Carry's claim. The second lesson was simpler: if you are protecting memory, authorization has to happen before that memory gets anywhere near the model.
What's next for Carry
Carry is already live at UseCarry.xyz. Anyone can sign up, create an organization, mint that organization's access policy on Sui mainnet, create agents, and issue scoped API keys. The focus now is less about launching the basic system and more about getting the first design partners using it in real agent workflows, working directly with those teams to find where integration is still awkward before pushing the self-serve side harder.
Build with Walrus
Walrus is the data platform built for the demands of AI: the foundation to store and manage your data. And when your agents need memory that travels with them, Walrus Memory is the portable memory layer built on top of it, keeping context persistent across apps, sessions, and model providers. Start with the Walrus quickstart, add memory with Walrus Memory, or bring questions to the Discord.
FAQs
How is Carry related to Walrus Memory?
Carry is built on Walrus Memory with two things added on top: an access gate that runs before any memory is retrieved, and an Answer Receipt that proves what was used and whether it was authorized. So Carry isn't a memory store or a replacement for one, it's the proof and policy layer you put around a memory layer to make it accountable.
How is a verifiable receipt different from an audit log?
An audit log is generated by the same application you are being asked to trust, so it still rests on a trust assumption. A Carry receipt points back to the actual blob stored on Walrus, and when it is anchored, a Move contract on Sui recomputes the verdict against the onchain policy. That means the claim can be checked independently, including a claim that access was blocked.
How do I build on Walrus and Walrus Memory?
Start with the Walrus docs and GitHub to build on Walrus itself: programmable storage where your data stays persistent, portable, and under your control across apps, providers, and agents. If you specifically want portable, persistent memory for your agents, Walrus Memory is the dedicated layer for it, with drop-in SDKs for Python and TypeScript and native MCP support. Its getting-started guide walks through connecting an agent and running remember and recall.
About Walrus Memory
Walrus Memory is a portable memory layer for AI agents. It enables agents to operate reliably across apps and sessions without losing context – portable, verifiable, and fully under builders' control. Walrus Memory lets agents handle complex, long-running workflows and coordinate using data they can trust.
