O Walrus acaba de se tornar a camada de memória padrão para o elizaOS v2, que é exatamente o tipo de movimento "infraestrutura real encontra agentes reais" que quero ver. O elizaOS conecta o @WalrusProtocol ao onboarding (com créditos limitados no tempo) para que novos desenvolvedores tenham memória persistente e verificável desde o primeiro dia. Li o post de integração e verifiquei os primitivos: cada upload resolve-se em uma Prova de Disponibilidade on-chain na Sui, um certificado assinado que seu blob está ativo e sob custódia; este é o âncora que transforma a "memória do agente" em um ativo programável em vez de um cache de melhor esforço. Para fluxos sensíveis, o Seal adiciona criptografia de limiar + controle de acesso on-chain para que os agentes possam compartilhar memória sem espalhar texto em claro. ❯ Para operações: você pode até acompanhar anúncios no feed de notícias do Walruscan enquanto configura sua própria telemetria. ❯ Por que isso é importante: enxames de agentes precisam de contexto verificável e de longa duração; recibos de PoA + armazenamento programável tornam "quem viu o quê, quando" auditável em fluxos de trabalho. ❯ Bônus: isso é agnóstico em relação à cadeia na camada de aplicativo, construído sobre Solana/EVM, mantenha a memória no Walrus, liquide as provas na Sui. Nota para desenvolvedores: envie um pequeno conjunto de dados via CLI, busque o evento BlobCertified da transação Sui, depois faça dois agentes lerem/adicionarem via o SDK TS, um público, um com Seal-gated e compare latências + caminhos de autenticação nos logs. (Publique seus números; estou coletando um banco de tempos de leitura/adicionamento.) Resultado: a pilha de agentes finalmente tem um primitivo de memória que você pode verificar, precificar e compor. Agora vamos ver quem transforma esses recibos de PoA em fluxos de trabalho reais de IA.