# ElizaOS Weekly Newsletter (2026-03-16 → 2026-03-22) ## 1) Executive Summary This week was a blend of real product momentum and honest community pressure—both useful signals as ElizaOS matures. **Milady beta shipped (playable + running).** After a round of build fixes, the team announced the **Milady beta release on March 21**, marking an important “hands-on” milestone for a major app built *on top of* ElizaOS. **Babylon integration moved from “headline” to “mechanism.”** Community discussion clarified that Babylon is expected to deliver **a community airdrop** and—more importantly—help drive **ElizaCloud token buybacks**, putting a concrete tokenomics lever on the roadmap. **Ecosystem building continued despite market noise.** A new permissionless on-chain raffle plugin (**moltraffle**, on Base using USDC + Chainlink VRF) was announced, and developers clarified the ElizaOS → Milady → OpenClaw relationship, resolving a recurring architecture misunderstanding. --- ## 2) Development Updates ### Milady App: Beta out, polish still in progress - **Status:** Beta released (March 21), described as “playable and running,” but the team has been consistent that it’s **not yet polished enough for a big marketing push**. - **Known build/release hygiene issues:** Community flagged **GPG key** and **SHA256 checksum** problems that should be addressed to improve release verifiability and trust in distributed binaries. - **Takeaway for builders:** If you’re tracking Milady as a reference implementation, it’s now useful for experimentation, but expect ongoing iteration before “mainstream-ready” UX. ### ElizaCloud / deployment reliability: several sharp edges surfaced Two infrastructure issues became focal points: 1) **Disk image upload failure** - Symptom: Images appeared to upload but **never arrived server-side**. - Context: Stack mentioned as **elizaos 1.x CLI + ElizaCloud**. - Next step: Root-cause investigation is ongoing; treat disk-image workflows as “verify end-to-end” until a fix lands. 2) **Discord plugin import error in deployed containers** - Symptom: Deployment failed with: `Cannot find module '@elizaos/plugin-discord'` after configuring the Discord plugin in the GUI. - Additional friction: Container became “stuck,” and users asked for a **GUI-based reload/redeploy mechanism**. - Community debugging hypothesis: The `plugin-discord` package/folder may be missing from the deployment build context (e.g., not present under `packages/` in the container image). - Suggested improvement: Add a **container reload** button and tighter preflight checks that validate selected plugins exist before build/upload. ### New plugin: Moltraffle (Base / USDC / Chainlink VRF) A community release introduced **moltraffle**, a permissionless on-chain raffle plugin on Base: - Core actions include: `LIST_RAFFLES`, `GET_RAFFLE`, `JOIN_RAFFLE`, `CREATE_RAFFLE`, `DRAW_WINNER` - **USDC-based raffles** with **Chainlink VRF** randomness - **Creator commission up to 10%** - Designed to work with **any Base wallet** via calldata-based interactions - The path to “official” discovery: contributors were encouraged to open a PR to the **elizaOS plugins registry** for inclusion. ### Process note: tighter feedback loop A practical ops change was mentioned: user feedback collection frequency shifting **from quarterly to weekly**, which should help surface and prioritize developer pain faster—especially around Cloud deployment. --- ## 3) Community Spotlight (Discord) ### The big conversation: communication, expectations, and token utility A lot of discussion centered around **token performance**, perceived gaps in **token utility**, and what “good communication” should look like in a builder-heavy project. - **Team perspective (via Odilitime):** Weekly video updates (“cronjob”) plus daily posts in a dedicated updates channel exist, but the community’s complaint is that these updates **don’t address the core concerns** (utility, catalysts, and accountability). - **Community perspective:** Repeated direct questions—“What is one use case of this token?” / “Why should anyone buy the token?”—went **unanswered** in the captured discussions, amplifying frustration. This is a valuable signal: communication cadence is not the same as communication *coverage*. The community is asking for a tighter link between (1) what’s being built and (2) how the token participates. ### Architecture clarity: ElizaOS vs Milady vs OpenClaw One of the most productive moments this week was a crisp clarification in the coders channel: - **ElizaOS** is the foundational **operating system for agents** (base layer). - **Milady** is built **on top of ElizaOS** (not a replacement). - **OpenClaw agents can exist within Milady**, indicating complementary—not competing—paths. If you’re building integrations or choosing a framework layer, this hierarchy matters: treat ElizaOS as the substrate, and Milady as an application ecosystem leveraging it. ### Builder energy: new initiatives and offers - A community member proposed an **agentic identity protocol** concept and looked for collaborators. - Another developer offered **full-stack Web3 + AI** support across multiple chains, a good reminder that ecosystem capacity exists—coordination is the bottleneck. --- ## 4) Token Economics (AI16Z token + auto.fun) ### AI16Z token: community sentiment and concrete levers Key points discussed this week: - **Migration status:** Migration completed; **1B tokens minted post-migration**. Some community members criticized the “40% community token allocation” as a cash grab (sentiment noted, not adjudicated). - **Price recovery lag:** Even as broader markets recovered, the token appeared to lag, with the team acknowledging “something isn’t right” (cause unclear in discussion). - **Market-structure asks:** Community repeatedly pointed to **stronger CEX listings** and **perpetual futures** as potential liquidity/price-discovery upgrades. - **Most actionable tokenomics update:** Babylon integration is expected to drive **ElizaCloud buybacks** and includes a **planned airdrop**—this is the clearest “utility-adjacent” mechanism mentioned this week. ### auto.fun No concrete product or token-mechanism updates for **auto.fun** were captured in this week’s dataset beyond community roles/interest. If there were releases or parameter changes, they weren’t surfaced in the logged discussions. --- ## 5) Coming Soon Here’s what to watch next based on this week’s threads: - **Milady beta hardening:** Fix release integrity issues (GPG/SHA256), reduce friction, and move toward a “marketing-ready” build. - **ElizaCloud reliability improvements:** - Resolve disk image upload failures - Fix/validate plugin packaging so `@elizaos/plugin-discord` is present when selected - Add a **GUI redeploy/reload** capability for stuck containers - **Babylon follow-through:** More details on **airdrop timing/eligibility** and how **buybacks** are triggered (volume-based? revenue-based? scheduled?). - **Registry inclusion for moltraffle:** Expect a PR into the plugins registry if the author follows through; reviewers should be ready to help standardize metadata and docs. - **Token utility narrative (the big one):** The community is explicitly asking for product-linked utility; expect continued pressure until a clear, shippable mechanism is announced. --- ## 6) Resources **Key Discord threads (context + discussion)** - 💬 discussion (token sentiment, comms expectations, migration concerns): https://discord.com/channels/1253563208833433701/1253563209462448241 - 💬 coders (architecture clarification: ElizaOS vs Milady vs OpenClaw): https://discord.com/channels/1253563208833433701/1300025221834739744 **Repos / build tracking** - Milady repository (progress + releases): https://github.com/milady-ai/milady - ElizaOS plugins registry (submit new plugins like moltraffle): https://github.com/elizaos-plugins/registry **Media shared in community** - Ecosystem map post (ElizaOS core + cross-chain + ElizaCloud + plugins): https://cdn.elizaos.news/elizaos-media/2035216158333575275_09e02bd0.mp4