# ElizaOS Weekly Newsletter (2026-03-15 → 2026-03-21) ## 1) Executive Summary **Babylon shipped (and brought tokenomics with it).** This week’s biggest ecosystem milestone was the **Babylon game launch**: a market-simulation experience where players command AI agents to research, share intel, and make trades/predictions. Importantly, the team reiterated that Babylon is not “just a demo”—it’s tied to **a planned community airdrop** and a mechanism intended to **drive ElizaCloud token buybacks**. **A big leap in “agent persistence” landed via the Ensoul plugin.** Community builder **DiamondRock (JD)** introduced `@ensoul-network/plugin-elizaos`, a persistence layer designed to keep an agent’s “consciousness” and identity durable across time using **encrypted, decentralized storage** and validator-backed redundancy. If you’ve been asking “how do agents remember reliably without centralized risk?”, this is a serious new option to test. **The plugin ecosystem expanded (and got cleaner).** Two parallel moves happened: a new on-chain raffle plugin (“Moltraffle”) was announced for Base, while framework/registry work standardized confusing plugin names (e.g., `plugin-form` vs `plugin-forms`). Together, these reflect a push toward a registry that’s easier to navigate—and easier to build on. --- ## 2) Development Updates (Technical) ### Babylon: gameplay + ecosystem integration Babylon launched as an agent-driven market simulation. Mechanics were shared publicly (notably via Shaw on Twitter), and Discord discussion focused on how Babylon ties into the broader ElizaOS ecosystem rather than living as a standalone mini-app. **What matters technically:** Babylon is being positioned as a demand-driver for ElizaCloud usage (compute + deployments), which becomes relevant for the buyback narrative (see Token Economics). ### ElizaCloud deployment & reliability issues Several developers reported friction deploying to Eliza Cloud: - **Long Docker build/upload times** (expected in some cases, but painful when iterating). - A **blocking runtime error** after configuring Discord via GUI: `Cannot find module '@elizaos/plugin-discord'` The suspicion is that the container image/build context may be missing the `plugin-discord` package directory, but it was not fully resolved in-channel this week. - A **missing “reload container” workflow in the GUI** was called out—once a container gets stuck, the recovery loop isn’t obvious. Separately, a **disk image upload bug** was identified: images appear to send from the client but **never arrive server-side**. The current stack referenced was **elizaos 1.x CLI + ElizaCloud**, and investigation is ongoing. ### Milady app: progress visible, release timing not Milady continues to advance with testable releases available on GitHub, but the team message stayed consistent: it’s **not yet polished enough for a marketing push**, and the timeline remains **“ready when ready.”** Two concrete technical concerns were surfaced: - **GPG key issues** - **SHA256 checksum problems** These are the kind of release-integrity details that matter a lot once broader distribution begins, so it’s good they were spotted early—even if it delays “big launch” messaging. ### Plugin ecosystem: new capability + naming cleanup - **Moltraffle plugin (Base):** A permissionless on-chain raffle plugin was announced featuring five core actions: `LIST_RAFFLES`, `GET_RAFFLE`, `JOIN_RAFFLE`, `CREATE_RAFFLE`, `DRAW_WINNER` Highlights: **USDC-based**, randomness via **Chainlink VRF**, up to **10% creator commission**, and a **calldata-based design** compatible with any Base wallet. Community guidance was to submit this into the **elizaOS plugin registry** via PR. - **xfn-framework naming standardization:** Plugin naming was refactored to reduce confusion: - `plugin-form` → `plugin-form-chain` - `plugin-forms` → `plugin-form` Registry updates were made accordingly—small on paper, but meaningful for developer experience (and fewer “wrong package name” installs). --- ## 3) Community Spotlight (Discord) ### Product + leadership communication: candid (and intense) conversations This week continued a tough but important thread: community members voiced frustration about **token performance**, **unclear utility**, **marketing/visibility**, and **limited leadership presence in Discord**. Odilitime was frequently the point of contact, balancing defense of progress with acknowledgments that some messaging landed poorly (including references to Shaw’s prior “gamblers” comment being unpopular internally and externally). While sentiment was heated, the signal is valuable: the community is explicitly asking for **more predictable updates**, clearer **utility milestones**, and communication that feels less adversarial when investors raise concerns. ### Builders stepping up: collaboration offers & new ideas - **Z1N** proposed an **agentic identity protocol** concept exploring AI consciousness, identity, and social structures—looking for collaborators inside the ecosystem. - **Peace** offered to help teams ship: full-stack Web3 + AI dev across **EVM/Sui/Solana**, with Rust/Solidity/Python/React/Next.js and DeFi/NFT experience. - In #coders, a simple but telling moment: when asked “anyone builds trading agents here?”, the answer was an immediate “yes”—interest remains strong in real, deployable agent workflows. ### Process improvement: feedback cadence A notable operational change: **jin** mentioned shifting user feedback collection from **quarterly to weekly**, aiming for tighter iteration loops and fewer “we found out too late” surprises. --- ## 4) Token Economics (AI16z / $ELIZA) + auto.fun ### Where things stand The community openly discussed the token reaching new lows and questioned utility, exchange support, and the migration experience. The clearest “mechanism-level” update this week was: - **Babylon → ElizaCloud buybacks**: Babylon is expected to help drive **ElizaCloud buybacks of the token**, and a **community airdrop** is planned alongside the launch. That’s concrete: it ties product activity to token flows. What remains missing (and repeatedly requested) is **implementation detail**—timelines, transparency on sizing/frequency, and how buybacks are executed and reported. ### auto.fun update No specific, verifiable **auto.fun** development updates were captured in this week’s Discord summaries. If auto.fun is part of your thesis, this is a good week to ask for (or draft) a short public status note: what shipped, what’s blocked, and what’s next. --- ## 5) Coming Soon - **Babylon airdrop details + execution:** Expect follow-ups on eligibility, timing, and distribution mechanics. - **ElizaCloud buyback implementation clarity:** Community is explicitly asking for timelines and proof-of-execution reporting. - **Milady app stabilization:** Focus areas include release integrity (GPG/SHA256), plus the polish bar needed before a marketing push. - **ElizaCloud deployment UX fixes:** Particularly a GUI-based recovery/reload path and the `@elizaos/plugin-discord` packaging/import issue. - **Hyperscape timing:** Community asked if it’s “next week”; expectation set in chat was **likely not**. --- ## 6) Resources (Links) - **Babylon & community discussion (Discord):** https://discord.com/channels/1253563208833433701/1253563209462448241 - **Milady app repository (progress + releases):** https://github.com/milady-ai/milady - **Plugin registry (submit your plugin PRs here):** https://github.com/elizaos-plugins/registry - **Ensoul persistence plugin + docs:** Explorer: https://explorer.ensoul.dev Quickstart: https://ensoul.dev/docs/quickstart.html GitHub: https://github.com/suitandclaw/ensoul --- *If you’re building this week: consider picking one “painkiller” issue (Cloud deploy reliability, plugin packaging, or release verification) and posting a short write-up in #coders—several threads are waiting for someone to turn investigation into a repeatable fix.*