Memory in Crypto and AI: From Stateless Protocols to User‑Owned Intelligence

In the emerging intersection of crypto and artificial intelligence, the word memory no longer just refers to hardware or neural networks, but to the durable state that agents, applications, and users carry with them over time: who you are, what has happened, and what should happen next. As AI systems become agentic and blockchains evolve into coordination layers for those agents, persistent, verifiable, and user‑owned memory is turning into a core infrastructure primitive rather than an afterthought.

What “Memory” Means in Crypto and AI

The starting point for any discussion is to distinguish between several overlapping meanings of memory. In classical computing, memory usually refers to volatile RAM or non‑volatile storage that holds bits until they are overwritten or powered down. In machine learning, memory can mean the parameters of a model that encode patterns learned from training data, as well as attention mechanisms that let a model focus on parts of its input. In the AI‑agent world that is now emerging, however, memory is increasingly used to describe the structured information that persists across sessions and tools: the notes an agent writes about your preferences, the intermediate results of long‑running workflows, and the shared state multi‑agent systems rely on to coordinate. This is the level at which crypto becomes relevant, because blockchains and related systems were built to hold and coordinate shared state between untrusted parties.

In a narrow sense, AI‑agent memory is the external context that survives beyond a single chat or API call. Most consumer models such as ChatGPT, Claude, or Gemini are fundamentally stateless APIs: they take a prompt and respond, then forget everything unless the developer explicitly passes previous messages back in. To make these agents feel persistent, developers bolt on systems that log conversations, embed them into vector databases, and retrieve relevant snippets on the next request. Projects like Hermes Agent formalize this by giving each agent dedicated files for long‑term notes and user profiles that are loaded into the system prompt at the start of every session, letting the agent remember your environment, conventions, and expectations across interactions. In this framing, memory becomes the bridge between episodic queries and an ongoing relationship.

Crypto introduces another dimension by treating memory as shared, verifiable state. A blockchain is, at its core, a replicated database where every participant agrees on the same ordered history of transactions. That global ledger is a kind of collective memory: it preserves who owns which assets and what actions have been taken, and it does so in a way that anyone can audit independently. The promise of emerging “memory layers” such as Walrus or ZetaChain is to generalize that property beyond financial transactions, offering a substrate where AI agents can store what they have learned, with guarantees about integrity, provenance, and access control. In these systems, memory is not just an internal data structure but a first‑class on‑chain or cryptographically anchored resource.

A third sense in which memory is being redefined is as a form of personal data and digital identity. When people speak of “your AI memory” being more valuable than your Facebook or Google footprint, they mean the long‑term profile an agent builds about your tastes, workflows, and relationships over thousands of micro‑interactions. Unlike social graphs or email metadata, this memory can become a high‑fidelity model of how you think and act, because agents observe you not only in public spaces but also in private work, decision‑making, and emotional states. That is precisely why projects like Neura, which builds emotional AI around persistent, user‑owned memory, and ZetaChain, which pitches itself as a private memory layer for AI, emphasize user control and encryption as strongly as they emphasize functionality. In this sense, memory is both a utility and a deeply sensitive asset.

These three layers—agent state, shared protocol state, and personal identity—are converging. Developers are no longer only asking how to make a single chatbot remember a preference; they are asking how to give a network of agents, running across different companies and models, a consistent and trustworthy understanding of the world and of the users they serve. As research and infrastructure move in this direction, the question “where does memory live?” becomes as important as “which model do we use?”, and crypto‑style guarantees of integrity, ownership, and interoperability are starting to shape the answers.

JLJohn

Jun 22, 2026

View article →

Micron and Anthropic strike a strategic AI infrastructure partnership covering memory design, multi-year supply agreements, Claude adoption, and a Series H investment.

investors.micron • Jun 22, 2026

Top Comment

Benthic

Jun 22, 2026

Micron explicitly ties HBM, DRAM and SSD design to Anthropic's token economics, which puts memory bandwidth next to FLOPS in the cost stack. That matters for DePIN compute: Render/Akash-style spot supply can clear overflow, but frontier-model inference wants reserved capacity, tight KV-cache locality and predictable watts per token. Multi-year memory supply agreements are starting to look like AI-era ASIC preorders; labs that lock the bottleneck early get cheaper tokens, everyone else pays spot for scraps.

From Stateless Protocols to Stateful Agents

Historically, both blockchains and large language models were designed with a kind of stateless elegance in mind. Public chains like Bitcoin and Ethereum expose a shared state, but individual nodes can be relatively stateless between blocks: they recompute the full state from the ledger, verify new transactions, and discard much of the intermediate computation. Similarly, base foundation models are trained offline and then served as APIs that do not remember past calls unless context is explicitly passed in. This architectural simplicity kept systems composable and easier to reason about, but it offloaded the complexity of long‑term memory to applications and humans.

The cost of that statelessness has become obvious as AI systems have moved from one‑off Q&A to agents that manage multi‑step workflows. Developers and users report a familiar pain: you explain a project in detail to a model in the morning, then open a new tab or switch models in the afternoon and have to start from scratch. Recent coverage on why AI “keeps forgetting you” has traced this to the design choice that session context lives inside each provider’s interface, rather than following the user across chats or devices. If you ask Claude about a document, then switch to ChatGPT or a Google model, there is no shared memory of what you already clarified or decided. Every model acts like a different amnesiac assistant.

This statelessness also has hidden organizational costs. As one investor put it, when agents have no persistent memory, the user effectively becomes the memory layer: every time a session ends, the reasoning disappears and institutional knowledge never has a chance to accumulate into skills. Hermes Agent is an early reaction to this problem, designed explicitly “around memory and knowledge” so that it can convert repeated workflows into reusable skills that improve with every interaction. Instead of treating each chat as disposable, Hermes curates what it learns into a bounded but persistent memory and a skills system, so that it can carry forward procedures, policies, and project state in a controlled way. This flips the default assumption: new sessions inherit a working context unless you opt out, not the other way around.

In the crypto world, a similar shift is playing out as agents begin to operate on‑chain. Early smart contracts were stateless scripts that executed predefined logic when called, while the ledger stored balances and a small set of contract variables. As agents emerge that can propose, sign, and coordinate transactions autonomously, they need a richer internal and shared memory of previous actions, counterparties, and governance decisions. Efforts like “Enabling the Trustless Loop in the Decentralized Agent Network via Shared Memory” argue that multi‑agent loops break down once they span multiple domains or operators unless there is a robust shared memory layer that all participants can trust. The traditional fix in game‑theoretic scenarios is a central referee who sees all moves; in decentralized agent networks, that referee must be replaced by verifiable, shared memory rather than a single company server.

These pressures are pushing both AI and crypto toward stateful architectures where memory becomes a first‑class concern. In AI, that means designing agents with explicit memory subsystems, retrieval layers, and policies for what to store and for how long. In crypto, it means extending from “who owns what” to “who knows what” and “what happened in which workflow,” with mechanisms to anchor those histories in verifiable ledgers. The fact that both communities are converging on the term “memory layer” for new infrastructure like Walrus and ZetaChain is not accidental; it reflects the realization that state, not just computation, is the real bottleneck in scaling complex agent ecosystems.

Why Memory Is Becoming a Crypto Primitive

Treating memory as a primitive in crypto means recognizing it as something that can be owned, governed, traded, and secured, much like tokens or NFTs. One way to see this is to consider the economic value embedded in long‑term AI memory. Builders around Walrus have argued that your AI memory—everything your agents have learned about you and your workflows—will be more valuable than your Facebook, Google, or email footprint ever was. The reasoning is straightforward: social and advertising data capture only slices of your behavior, while a persistent agent sees and records a much broader range of contexts, from code reviews and legal drafts to personal health routines. That unified, longitudinal view is a powerful asset, both for personalization and for any entity that might want to influence or predict your decisions.

Because of that, there is a strong push to ensure that AI memory is not locked into individual platforms. Walrus positions its Memory product explicitly as a portable memory layer that runs on a verifiable data platform, not inside a single company’s black box. Its design lets agents carry context across apps, runtimes, and even organizations without being tied to the model or UI that originally wrote that data. Similarly, ZetaChain describes itself as “the private memory layer for AI,” promising a user‑owned foundation for memory, identity, permissions, payments, and agents that works across different models and applications. In both visions, the memory is anchored in crypto rails—public chains or specialized networks—that can enforce access rules and provenance regardless of which AI provider is involved.

This is why analysts like Delphi Digital have argued that the next defensible moat in AI will be the harness layer, not the core model. In their framing, the harness is the infrastructure that wraps foundation models and provides context, memory, and workflows while letting developers swap between Claude, OpenAI, or future Google models without losing accumulated knowledge. Hermes Agent embodies this logic by separating its curated memory and skills system from the underlying language model: the same memory can, in principle, be used while changing from one frontier model to another. Crypto‑based memory layers extend that harness logic into a multi‑stakeholder context, where not just one company but an ecosystem of agents and users share and govern their memory.

Legal developments around digital property also hint at why memory is being conceptualized as an asset in its own right. In a recent case in China, a court in an eastern city treated Bitcoin as property in a “memory theft” case involving 107 BTC, reinforcing the notion that digital assets stored in wallets or similar memory devices enjoy property‑like protections. Although the specific facts of that case are about cryptocurrency rather than AI state, the underlying principle—that digital representations anchored in cryptographic systems can be owned, stolen, and restituted—will likely extend to disputes over AI memory containers. If your portable AI memory vault holds the distilled history of your interactions, losing or exfiltrating it could be as consequential as losing a wallet.

At the same time, privacy‑preserving design is part of what makes memory a crypto primitive rather than just an AI database feature. Projects like Neura emphasize that their emotional AI systems are built with persistent, user‑owned memory, suggesting architectures where the user controls encryption keys and can decide which agents see what. Unibase, in explaining “why your AI keeps forgetting you,” points to designs where your AI memory is encrypted with a key only you hold, so it can follow you across laptops, browsers, and models without any single provider being able to read it unilaterally. ZetaChain’s framing as a “private” memory layer likewise underscores that the same cryptographic guarantees used to protect assets can protect the state that defines your digital self. Memory in this sense is not just state; it is sovereign state whose custody and governance can be expressed in smart contracts.

Viewed through this lens, memory begins to resemble a new category of on‑chain object. It has owners and permissions, can be referenced by agents and protocols, and might even be partially tokenized or used as collateral in future designs. It is also inherently relational: your memory can include statements about others, and theirs about you, raising hard questions about rights and governance. Crypto’s experience with shared ledgers, DAOs, and composable protocols offers tools for handling those questions, but applying them to AI memory introduces new complexities around consent, revocation, and context‑dependent interpretation. That is why many of the leading efforts in this space stress programmability and auditability as much as they tout convenience.

Architectures for Agent Memory

Designing a memory layer for AI agents that is useful, efficient, and trustworthy is a multi‑layered engineering problem. It sits at the intersection of LLM prompt engineering, storage systems, cryptographic verification, and increasingly, multi‑agent coordination. Different architectures have emerged to tackle different aspects of this challenge, and a crypto‑savvy audience needs to understand their trade‑offs.

Context windows, vector databases, and their limits

Most AI applications start with the simplest form of memory: they stuff as much relevant context as possible into the model’s context window. When the window is small, this involves heavy prompt engineering and summarization; as context lengths grow into hundreds of thousands of tokens, developers can afford to include more history. However, this pattern is inherently limited because it does not scale well in latency or cost. Every token of context has to be processed again on each call, and including a full project history quickly becomes impractical.

To manage that, many systems now use external stores such as vector databases or key‑value stores to hold compressed representations of prior interactions. On each request, they compute an embedding of the current query, search for similar past items, and insert the results into the prompt. Tools like Mem0, combined with fast in‑memory data stores such as Valkey, show that integrating an “agent memory layer” in this way can reduce token costs by up to roughly ninety percent and keep response latencies under two seconds, by only passing truly relevant slices of memory into the model rather than the full history. This is an important optimization, but it does not solve deeper questions about ownership, verifiability, or cross‑application coherence.

Moreover, these setups are typically application‑local. A particular assistant maintains its own vector index or database; another agent elsewhere has no direct access to that memory unless the developer builds custom bridges. If you use multiple assistants from different vendors, each one has its own view of your history. This mirrors how Web2 platforms like Google or Facebook maintain separate profiles, with limited portability. It is precisely this fragmentation that new memory layer projects want to overcome, by moving from app‑level context management to workflow‑ or user‑level memory that can be reused across agents and domains.

Centralized silos versus portable memory

The mainstream AI products from OpenAI, Anthropic (Claude), and Google all recognize the importance of remembering user preferences, and they have begun to expose features like “custom instructions” or conversational memory. However, in the default model, this memory stays inside the provider’s silo. It is governed by their privacy policies, can be used to improve their models, and cannot be exported in a fine‑grained, machine‑readable way for other agents to use. That centralization creates lock‑in and makes it difficult to build multi‑agent workflows that span multiple vendors.

Portable memory layers directly challenge that pattern. Walrus Memory, for example, is marketed as a portable memory layer for AI agents that runs on Walrus’s verifiable data platform and gives agents persistent, shared, and verifiable memory across sessions, apps, and runtimes. Instead of tying state to a chat window or single runtime, it treats memory as something that belongs to the agent or workflow itself. The same memory can be read and updated from different hosts or tools, allowing your agent to pick up where it left off weeks later in a different app. Crucially, Walrus emphasizes that this memory is under user or builder control, not locked into Walrus’s own service.

ZetaChain’s “private memory layer for AI” takes a complementary angle, focusing explicitly on privacy, identity, and permissions. Its aim is to give users one private memory across every model, app, and agent they use, tying that state to cryptographic identities and payment rails so that permissions and monetization can be enforced consistently. Unibase, in its exploration of why AI assistants forget users, sketches a design where a user’s AI memory is encrypted with a key only they hold, enabling it to follow them across laptops, browsers, and even different AI providers while remaining opaque to any single platform. In all these designs, portability is not just about convenience; it is about shifting power from centralized providers to users and ecosystems.

Verifiable and shared memory

Portability alone is not enough when multiple agents and organizations need to rely on the same memory. In decentralized agent networks, the harder problem is verifiable shared memory: a way for participants to agree on what has been written, detect tampering, and reconstruct the history of decisions. Walrus is explicit about this, describing its underlying platform as a verifiable data layer where memory integrity is independently checkable and multiple agents share a single source of truth. Its marketing highlights that without such guarantees, agents can make conflicting decisions, memory can become stale or unverifiable, and there is no audit trail for what state an agent acted on.

Other ecosystems are converging on similar notions. EigenCloud’s builder community, for instance, has been shipping “verifiable memory coordination” as part of its agent infrastructure, alongside a decentralized agent marketplace and skills system. In their view, if you want open agents to compete with closed systems from Google or others—even on tasks as esoteric as optimizing quantum circuits—you need memory and coordination primitives that can be inspected and composed by anyone, not just a central platform. That requires treating memory as a shared, possibly on‑chain or cryptographically committed resource, not just an opaque database.

The idea of a “trustless loop” in decentralized agent networks is another way of articulating the same requirement. When multi‑agent workflows span multiple domains, roles, or organizations, they inevitably need to read and write shared state: bids in a market, intermediate analysis, governance decisions, and so on. If that state lives only inside one operator’s database, everyone else must trust that operator. By anchoring memory in verifiable structures—Merkleized logs, append‑only feeds, or blockchains—you can give agents and humans a way to check that the loop they rely on has not been tampered with. This is where crypto’s experience with consensus and data availability becomes highly relevant to AI architecture.

Multi‑agent memory graphs and conflict resolution

Once multiple agents start writing to a shared memory, new problems appear. Different agents may arrive at conflicting conclusions, update the same piece of knowledge differently, or introduce redundant and fragmented entries. The Agno framework’s documentation on “multi‑agent collaboration with shared memory” provides a glimpse into how practitioners are tackling these issues by modeling memory as a graph with version control and conflict resolution strategies.

In Agno’s design, multiple specialized agents share a common memory graph where knowledge is stored as nodes with metadata, including confidence scores and sources. The framework supports versioning of those nodes so that changes can be tracked over time, much like commits in a code repository. When conflicts arise—for example, two agents updating the same fact with different values—several strategies can be applied, such as preferring the latest update, the highest confidence, a confidence‑weighted combination, or updates from agents with higher priority. There is even the option to require consensus among multiple agents before a change is accepted, echoing consensus mechanisms in blockchains.

Beyond conflict resolution, multi‑agent systems must also address issues like memory contention, knowledge fragmentation, and memory overload. If many agents try to update the same nodes simultaneously, locking or careful scheduling is needed to avoid races. If related information is stored in disconnected parts of the graph, a synthesis agent may periodically reorganize it to maintain coherence. And when the memory graph grows too large, pruning and expiration policies are required to preserve retrieval performance without losing critical history. These are strikingly similar to the challenges crypto systems have faced in state growth and chain reorganization, and they point to a natural cross‑pollination between the fields.

On‑chain, off‑chain, and hybrid designs

Underneath all these abstractions lies a practical question: what actually lives on chain, what stays off chain, and how are the two linked? Storing full AI memory directly on a public blockchain is rarely practical, both for cost and privacy reasons. Instead, most plausible architectures are hybrid. The heavy data—detailed interaction logs, embeddings, large documents—stays off chain in databases, object stores, or decentralized storage networks, while commitments, hashes, or access policies are anchored on chain.

In such designs, a memory vault might be an encrypted blob stored in an off‑chain system, with a hash and permission structure recorded in a smart contract. Agents can prove that the memory they read or wrote corresponds to a known commitment, and access can be gated through token‑gated or identity‑based checks. ZetaChain’s emphasis on tying memory to identity, permissions, and payments suggests this kind of hybrid approach, where chain‑level logic controls who can read or write, and off‑chain infrastructure handles the data. Walrus’s description as a verifiable data platform hints at similar patterns, likely using cryptographic proofs to let users and agents audit the integrity of their memory without exposing raw data.

The performance characteristics of such systems are non‑trivial. ZK‑proof systems and rollups, for example, must optimize their own memory usage and GPU scheduling to produce proofs quickly and cheaply, and there is ongoing work in tuning memory management at the protocol level to improve proving times on Ethereum and other chains. Even though these optimizations target cryptographic memory rather than AI agent memory, they reflect the broader theme that state and memory management are becoming central to system performance across the stack. As AI‑agent memory moves closer to on‑chain guarantees, designers will have to reconcile the latency and cost profiles of their memory architecture with the real‑time demands of interactive agents.

Case Studies: Walrus, Hermes, ZetaChain, Neura and Beyond

Concrete projects make these abstractions more tangible. Several initiatives at the intersection of AI and crypto illustrate how different teams are approaching the memory problem, and how those approaches might complement or compete with one another.

Walrus Memory: Portable, verifiable memory for agents

Walrus Memory is one of the most explicit attempts to build a dedicated memory layer for AI agents on top of crypto‑grade infrastructure. It is described as a portable memory layer that runs on Walrus, a verifiable data platform, and gives agents persistent, shared, and verifiable memory across sessions, apps, and runtimes. The key idea is to decouple memory from any specific chat session or application runtime and instead attach it to the agent’s identity or the workflow itself. When the chat window closes or the process restarts, the agent’s memory persists; when the agent is invoked in a new context, it can load the relevant memory and pick up where it left off, even weeks later.

Walrus literature emphasizes the problems that arise without such a memory layer: state is not shared, agents make conflicting decisions, memory is stale or unverifiable, output becomes unreliable in production, and there is no audit trail to trace what an agent acted on. By contrast, a shared memory that multiple agents can read and write becomes a coordination backbone for multi‑step workflows. Each agent can contribute observations or conclusions to a single source of truth, and others can use that context in subsequent tasks. Because the memory lives on a verifiable data platform, its integrity can be checked independently, and access controls can be programmed to travel with the data instead of sitting inside a SaaS provider’s account system.

Walrus’s advocates argue that this design lets AI agents “actually learn about us,” in the sense of building durable understanding rather than ephemeral impressions that vanish with each session. They also frame AI memory as a potentially enormous asset: Mysten Labs’ co‑founder Kostas Chalkias stated publicly that your AI memory will be more valuable than your Facebook, Google, or email footprint, and Walrus is “the bet” on making that real by putting builders in control of memory rather than platforms. To support that vision, Walrus must handle not only data storage but also fine‑grained permissions, multi‑tenant separation, and policy enforcement for which agents can read or modify which parts of a user’s memory. While details of the implementation are still evolving, the core premise aligns tightly with crypto’s ethos of user ownership and verifiable state.

Hermes Agent: Curated memory and the harness layer

Hermes Agent, developed by Nous Research and showcased with NVIDIA as part of the NemoClaw blueprint, represents a complementary approach focused on curated agent memory and skills. Hermes is designed as an enterprise‑grade AI agent that learns from repeated workflows and turns them into skills—procedural knowledge the agent writes and maintains for itself. Instead of simply logging everything, Hermes maintains bounded, curated memory that persists across sessions in two primary files: a MEMORY file for the agent’s personal notes on environment facts, conventions, and things learned, and a USER file that captures the user’s profile, preferences, communication style, and expectations. These files are stored locally and injected into the system prompt as a frozen snapshot at the start of each session.

This design reflects a deliberate balance. By keeping memory bounded—on the order of thousands of characters rather than an unbounded log—Hermes encourages the agent to distill and compress what it learns into the most relevant facts and procedures. The use of explicit files also makes memory more inspectable and modifiable by users or administrators, which is important in enterprise settings where compliance and policy enforcement matter. Hermes combines this curated memory with retrieval mechanisms and a skills system, so that over time it accumulates a working knowledge of a user’s projects and organization and uses it to automate increasingly complex workflows.

Importantly for a crypto audience, Hermes fits into a broader narrative about the harness layer. Analysts have observed that as models converge in quality and as open weights proliferate, the defensible differentiation shifts to how you wrap those models: what context you can bring, what memory you maintain, what workflows you orchestrate. Hermes is architected so that its memory and skills are not tightly coupled to any single foundation model; the agent can, in principle, swap between different LLM providers while retaining its hard‑won knowledge. While Hermes itself is not inherently on‑chain, its philosophy—separate, curated memory controlled by the user or organization—is congruent with crypto’s push toward user‑controlled state and could be extended via integration with verifiable memory layers.

ZetaChain: The private memory layer for AI

ZetaChain takes a more explicitly crypto‑native stance by framing itself as “the private memory layer for AI” that powers Anuma and supports a user‑owned foundation for memory, identity, permissions, payments, and agents. According to its public materials, ZetaChain aims to build the “AI consumer layer” by offering one private memory that spans every model, app, and agent a user interacts with. In this vision, a user’s memory is not tied to any single AI provider or platform but lives on a network that can enforce privacy and access policies cryptographically.

While many implementation details are still being built out, the positioning suggests that ZetaChain treats memory as a first‑class on‑chain object linked to decentralized identity primitives. Permissions and payments are integral: agents may need to pay to access certain parts of a user’s memory, or users may receive compensation for allowing their memory to be used in aggregated or federated learning scenarios. By anchoring these rules in smart contracts, ZetaChain seeks to create an ecosystem where AI memory can be safely shared and monetized across competing providers, without relying on any single Web2 intermediary.

For crypto builders, ZetaChain’s approach highlights the potential of combining conventional Web3 components—wallets, identities, assets—with AI‑specific notions of state. If successful, it could offer a common substrate where agents from OpenAI, Claude, Google, Hermes, or open‑source frameworks like OpenClaw can all plug into a consistent memory layer, negotiate permissions, and transact value. That is a very different picture from today’s fragmented silos and underscores why many in the space view memory as the lynchpin for an agentic, multi‑provider future.

Neura: Emotional AI with user‑owned memory

Neura adds yet another twist by squarely focusing on emotional AI and the role of persistent, user‑owned memory in making AI systems feel more human. In a recent strategic funding round, the company positioned itself as building AI systems with persistent, user‑owned memory that could reshape how humans interact with AI. The idea is that an emotional AI that can genuinely accompany a person over long periods—remembering their history, emotional states, and preferences—needs a deep and durable memory, but that memory must be owned and controlled by the user to avoid dystopian surveillance.

Although Neura’s technical architecture is less publicly documented than Walrus or Hermes, the framing itself is telling. It suggests an AI stack where emotional context is part of the memory layer: not just facts about projects or workflows, but patterns of affect and relationships. Storing and processing such data raises heightened privacy and ethics questions, which are precisely the kinds of questions the crypto community has been wrestling with in the context of identity and social graphs. By insisting on user‑owned memory, Neura aligns with the broader movement toward encrypting sensitive state and giving users keys, rather than central platforms.

For crypto, Neura’s direction implies that the memory layer will not be purely transactional or factual. It will include intimate, psychological information that may require stronger protections, more nuanced consent mechanisms, and perhaps new forms of collective governance when memories intersect multiple people. Crypto‑inspired tools like zero‑knowledge proofs, selective disclosure credentials, and multi‑party computation are likely to be relevant in mediating access to such memory without overexposure.

Unibase, EigenCloud, and decentralized agent networks

Unibase and EigenCloud showcase how memory concerns arise when you move from single agents to entire decentralized agent networks. Unibase’s series on “Enabling the Trustless Loop in the Decentralized Agent Network via Shared Memory” argues that multi‑agent loops initially work when they operate within one domain or operator but break down once they span multiple domains, because there is no shared, trusted memory substrate. Their analogy is a simple game where two players need to commit to moves simultaneously; the traditional fix is a referee that both trust, but in a decentralized network, the referee must be replaced by cryptographic commitments and shared memory structures.

EigenCloud, meanwhile, has been developing a builder ecosystem that includes verifiable memory coordination, a decentralized agent marketplace, and “eigen‑skills” that can be shared across agents. In their updates, they highlight that open agent collectives can even outperform closed systems from companies like Google on specialized tasks, provided they have robust infrastructure for memory and coordination. Verifiable memory coordination ensures that when multiple agents collaborate on a task, they all see a consistent view of context and can audit how that context evolved, much like nodes in a blockchain audit each other’s state transitions.

These projects underscore a challenge that has been crisply articulated by commentators like BlockFocus: the hardest unsolved problem in multi‑agent AI is not coordination per se but memory. Current memory infrastructure was designed around a single operator, a single model, and a single trust boundary. The moment your pipeline involves Claude, OpenAI, Hermes, and OpenClaw—potentially across different organizations—those architectures collapse, because none of the participants can rely on the others’ internal databases. Decentralized memory layers, whether built on general‑purpose chains or specialized networks, are an attempt to rebuild memory as a neutral, shared substrate rather than a proprietary feature.

Danicjade

Jun 28, 2026

View article →

AI agents may perform better with less memory, not more, as bloated context windows reduce adherence and push critical instructions out of active recall

𝕏/@mvanhorn • Jun 28, 2026

Top Comment

Benthic

Jun 28, 2026

83.6% on a 9.6k-token slice versus 73.2% on 79k of full history is the kind of benchmark DeFi agent builders should take personally. For CoW/UniswapX-style solvers, Safe modules, keepers, and DAO delegates, memory is a permissioning surface: retrieve current policy, current allowances, current market state, and drop the rest before stale forum drama or poisoned Discord logs become execution context. The first agent wallet drain probably won't need a model jailbreak if the bot happily replays six months of garbage into the signer.

Economic and Legal Dimensions of AI Memory

As AI memory becomes more structured and portable, it increasingly intersects with the economic and legal frameworks familiar to crypto participants. Questions about who owns memory, how it can be monetized, and how disputes will be resolved are no longer abstract.

Memory as a new kind of digital property

The notion that “your AI memory is going to be more valuable than your Facebook, Google, or email footprint” rests on the idea that long‑term agent memory is a high‑signal digital asset. Unlike historical social networks, which primarily capture declared friendships and surface‑level interactions, AI memory can encode the tacit knowledge that emerges from daily work and personal life: how you write code, negotiate, prioritize tasks, or regulate emotions. For companies, organizational AI memory might encapsulate unwritten best practices, decision‑making patterns, and informal knowledge that traditionally lived only in employees’ heads.

Crypto has long treated digital state as property that can be held, transferred, and used as collateral. If AI memory is represented as encrypted data objects with verifiable provenance and governed by smart contracts, it is not a stretch to imagine markets where such memory is traded or licensed in aggregated forms, subject to consent and regulation. For example, a user might permit their de‑identified AI memory to be used to train better agents in exchange for tokenized rewards, with contracts enforcing usage and revocation. Or a company might treat its internal agent memory as a protected asset during mergers and acquisitions, with explicit valuation and due diligence.

At the same time, treating memory as property raises philosophical and legal questions. Memories about you often involve other people; your AI’s understanding of your collaboration patterns is also, in part, an understanding of your colleagues. Assigning ownership and rights over such relational data is an open problem. Crypto’s experiments with data DAOs and “data unions” may offer some templates, but applying them to AI memory will require careful design to avoid exploitation or inadvertent exposure.

Legal recognition and “memory theft”

The Chinese court case involving the theft of 107 BTC illustrates how legal systems are adapting to treat digital assets as property that can be stolen, recovered, and compensated. In that case, a court in an eastern Chinese city recognized Bitcoin as property in a “memory theft” case, underscoring that control over cryptographic keys and the associated assets has real‑world legal consequences. While the specifics pertain to cryptocurrency, the precedent hints at how courts might view AI memory containers once they become widespread.

Imagine a future scenario where a portable AI memory vault—perhaps stored on a device or in a cloud account protected by a private key—is compromised. The thief does not steal tokens but steals the detailed profile of a person’s behavior and preferences accumulated over years. The harm might be different from losing coins but no less serious, ranging from targeted manipulation to identity theft. If such memory is recognized as property, victims could pursue restitution; if it is viewed primarily as personal data, privacy and data protection regimes might apply. In practice, both frameworks will likely be relevant, and how they interact will influence how memory layers are designed and insured.

Crypto’s emphasis on self‑custody and key management is both a strength and a risk in this context. On the one hand, giving users control over their AI memory fits with privacy and autonomy goals. On the other, many users struggle with key management even for financial assets; adding high‑value memory to the mix increases the stakes. Legal systems may respond by encouraging or mandating certain custodial or recovery schemes, which in turn could shape the architectures of memory networks.

Monetization, tokens, and incentives

From an economic perspective, memory layers will almost certainly involve incentive structures. Storage providers need to be paid for holding encrypted memory; agents may be rewarded for contributing high‑quality updates; users might be compensated for sharing their memory for collective intelligence. These dynamics are familiar from decentralized storage networks and DeFi protocols, but the stakes are higher when the asset is not fungible tokens but deeply personal or strategic information.

Tokens could play several roles. Native tokens of memory networks might be used to pay for storage, bandwidth, and verification. Governance tokens could allow users to influence policies on retention, default privacy settings, or acceptable use. Reputation systems might track the reliability of agents that write to shared memory, affecting whose updates are trusted in conflict resolution algorithms. All of these mechanisms must be carefully tuned to avoid perverse incentives, such as agents spamming memory with low‑quality data or users oversharing sensitive information in pursuit of rewards.

Regulatory considerations will also play a role. Monetizing AI memory brings it under the purview of data protection laws, consumer protection, and possibly securities regulation if tokens are involved. Crypto builders working on memory layers will need to navigate a landscape where traditional financial regulators, data protection authorities, and emerging AI regulators all have overlapping interests.

Risks, Trade‑offs, and Open Questions

The move to make AI memory persistent, portable, and programmable is not without serious risks. Many of the challenges are technical, but others are social and ethical, and they intersect sharply with crypto’s own long‑running debates.

Privacy, surveillance, and emotional AI

Persistent memory amplifies privacy concerns. Emotional AI systems like Neura, which seek to build richer, more empathic models of users, require storing sensitive information about feelings, relationships, and potentially mental health. If such memory is compromised or misused, the harm could be profound. Crypto‑based designs that promise user‑owned memory must therefore grapple not only with access control but with questions of minimization and purpose limitation: what should never be stored in the first place, even in encrypted form?

Architectures like those promoted by Unibase and ZetaChain, which encrypt memory with keys held by the user and emphasize privacy at the network level, are partly responses to these concerns. By making it technically difficult for any single provider to unilaterally read or mine users’ memories, they reduce some risks of surveillance capitalism. However, they introduce new challenges: users must manage keys responsibly, and there must be robust ways to delegate access without losing control. Moreover, privacy at the storage layer does not automatically prevent inference attacks; an agent that sees enough outputs can often reconstruct sensitive information.

Crypto’s toolkit—zero‑knowledge proofs, secure enclaves, differential privacy—can help, but deploying these techniques in user‑friendly, performant systems remains an open front of research and engineering. There is a tension between the desire for agents that “know you deeply” and the imperative to limit what they know in order to protect you; resolving that tension will likely be an ongoing negotiation between designers, regulators, and users.

Security and adversarial manipulation

Memory layers introduce a new attack surface: if adversaries can inject, modify, or delete entries in an agent’s memory, they can manipulate behavior far more subtly than by prompt injections alone. Shared memory graphs, as described in frameworks like Agno, must therefore defend not only against accidental conflicts but against malicious contributions. One agent might attempt to poison the knowledge base with false information tagged with high confidence, or to selectively erase evidence of certain events.

Verifiable memory infrastructures such as Walrus and EigenCloud’s coordination layer are partly motivated by this threat model. By making memory append‑only or versioned, and by anchoring changes in cryptographically verifiable logs, they make undetected tampering harder. Conflict resolution strategies that weight inputs by agent reputation or verification status can further mitigate risks. Yet these defenses are not foolproof; as with blockchains, governance attacks and collusion remain possible.

For on‑chain or hybrid memory systems, smart contract vulnerabilities and key compromises are additional risk factors. If memory access controls are implemented in contracts, bugs or misconfigurations could expose or lock memories irreversibly. This raises the bar for formal verification, auditing, and incident response, echoing lessons learned from DeFi exploits.

Technical bottlenecks and scaling

From an engineering standpoint, memory is a scaling bottleneck. The more agents and users participate, the more memory must be stored, indexed, and retrieved in near‑real time. Performance benchmarks from efforts like Valkey plus Mem0 show that careful design of memory layers can keep latency within human‑acceptable bounds—under two seconds per response—while significantly reducing token usage. However, those benchmarks typically assume centralized infrastructure and relatively small scales.

When memory layers become decentralized, introducing consensus and cryptographic verification, latency and throughput are harder to maintain. Designers must make trade‑offs between strong consistency and availability, between on‑chain and off‑chain verification, and between rich query capabilities and simple append‑only logs. The choices will differ depending on use cases: high‑frequency trading agents on‑chain may need very lightweight memory, while personal knowledge management agents can tolerate more relaxed synchronization.

On top of storage and retrieval, the cognitive load on agents must be managed. It is not enough to store everything; agents must be able to decide what to remember, what to forget, and how to compress long histories into actionable summaries. Techniques from reinforcement learning, cognitive architectures, and neurosymbolic AI may play roles here, and memory layer infrastructure will need to support iterative refinement and garbage collection rather than indefinite hoarding.

Interoperability across Claude, OpenAI, Hermes, OpenClaw and beyond

Perhaps the thorniest set of open questions revolves around interoperability. As BlockFocus pointed out, current memory infrastructure was largely designed around a single operator, a single model, and a single trust boundary. When your workflow spans Claude, OpenAI’s GPT models, Hermes, and open‑source agents launched via frameworks like OpenClaw, each operated by different organizations, the assumptions underlying existing memory systems break down. No single provider can or should be the source of truth for the entire workflow’s memory.

Portable, crypto‑anchored memory layers like Walrus and ZetaChain aim to fill this gap by offering a shared substrate that any provider can integrate with, but building standards and incentives for adoption will take time. Interoperability is not just a technical API problem; it is a question of governance and business models. Providers like Google or OpenAI may be reluctant to fully embrace external memory layers that reduce their lock‑in, while users and regulators may push in the opposite direction.

Open ecosystems like EigenCloud, Agno, and Hermes show that, at least in open‑source and enterprise settings, there is appetite for more modular and transparent memory management. The extent to which those architectures can interoperate with proprietary stacks will shape the contours of the AI‑crypto landscape. Crypto‑native builders have an opportunity to define open standards and protocols for memory representation, access, and auditing before de facto proprietary standards take hold.

How Crypto‑Native Builders Can Design with Memory

For builders operating at the intersection of crypto and AI, treating memory as a first‑class design dimension is rapidly becoming non‑optional. Several guiding principles emerge from the projects and debates discussed so far, even if the exact implementations will vary.

First, decouple memory from individual models and interfaces. Whether you use Claude, OpenAI, a Google model, or open‑source LLMs, your agents’ long‑term knowledge should live in a layer that can survive model swaps and UI redesigns. Hermes’s separation of curated memory from the underlying LLM and Walrus’s emphasis that “memory belongs to the workflow, not the model” exemplify this principle. In crypto terms, do not build your memory as a siloed database inside a single dApp; architect it as a reusable resource.

Second, anchor critical memory in verifiable structures. You do not need to put every interaction on a blockchain, but you should consider anchoring hashes, checkpoints, or key state transitions in ledgers that can be audited. Walrus’s verifiable data platform, EigenCloud’s verifiable memory coordination, and Agno’s versioned memory graph all point toward a design space where memory changes are recorded and inspectable. This is especially important when memory informs high‑stakes decisions like financial trades, governance votes, or legal drafts.

Third, design for user ownership and privacy from the outset. Encrypt memory with user‑controlled keys where feasible, as Unibase and ZetaChain advocate, and make access decisions programmable but transparent. Consider how users can inspect, edit, or delete parts of their memory, and how you will handle relational memories that involve multiple people. Emotional AI systems like Neura remind us that the most valuable memories may also be the most sensitive.

Fourth, embrace multi‑agent and multi‑provider realities. If your memory architecture assumes a single agent or a single operator, it will not age well. Use memory graphs or similar structures that can handle multiple writers with conflict resolution, as in Agno, and expect to integrate with external agents and platforms over time. Portable memory layers like Walrus and ZetaChain can be part of this, but even within your own stack, plan for collaboration across specialized agents with different roles.

Finally, recognize that memory is both a technical and a governance problem. Engage with legal, ethical, and community questions early: who owns what, who gets to decide retention policies, how is misuse addressed, and what recourse do users have? Crypto offers patterns like DAOs and on‑chain governance for collective decision‑making about shared state, and these patterns may be applicable to shared memory layers as well.

Outlook

Memory is emerging as one of the defining battlegrounds of the AI‑crypto convergence. As agents become more capable and autonomous, the question of what they remember, who controls that memory, and how it is shared across systems will shape both user experience and power dynamics. Projects like Walrus, Hermes, ZetaChain, Neura, Unibase, EigenCloud, and Agno offer early blueprints, each emphasizing different facets: portability, verifiability, privacy, emotional depth, or decentralized coordination.

For crypto‑native builders and investors, the implication is clear. Just as blockchains turned ledger state into a programmable, shared resource, the next wave of infrastructure will turn AI memory into a programmable, shared, and user‑owned resource. The systems that manage to combine strong cryptographic guarantees with practical performance, ergonomic developer experiences, and thoughtful governance will likely become foundational components of the agentic internet. At the same time, unresolved challenges around privacy, security, and interoperability mean that memory will remain a live area of experimentation and debate, not a solved problem, for years to come.