# ElizaOS Weekly Newsletter (Apr 5 – Apr 11, 2026)

## 1) Executive Summary

This week was all about *making agents more dependable in the real world*—financially, operationally, and socially:

1. **A stronger “agent economy” foundation landed in core.** The new **Agent Wallet plugin** enables agents to check balances, swap tokens, and move assets **across EVM + Solana**, pushing ElizaOS further toward practical, non-custodial agent operations.

2. **Core runtime got a major hardening + observability upgrade.** A large merged PR brought **provider timeouts**, **memory-creation controls**, improved **logging**, and bootstrap/runtime refinements—making deployments easier to debug and safer to operate.

3. **Eliza v3 momentum accelerated (testing phase).** The team confirmed v3 work is active, new agents are being tested, and the code is already in the `develop` branch—release/announcement will follow once testing wraps.

---

## 2) Development Updates (Technical)

### Core runtime + developer experience improvements
- **Merged: “Bring Odi logging, Memory lock down, banner, other core enh”**  
  This is a broad upgrade across the TypeScript runtime and bootstrap layer:
  - **Per-provider timeouts** (notably a 30s per-provider limit in state composition) to prevent a single slow provider from stalling a turn.
  - **Memory controls:** `DISABLE_MEMORY_CREATION` and `ALLOW_MEMORY_SOURCE_IDS` give operators tighter control over what gets persisted (useful for privacy, compliance, and debugging).
  - **File-based logging** (opt-in) to make prompt/response tracing and incident debugging much easier.
  - **Bootstrap polish** including a startup banner and additional runtime safeguards.

  *Why it matters:* as more agents handle money, identity, and real integrations, predictable timeouts + clear logs + controllable memory behavior are foundational.

### New local “agent harness” workspace (for booting the repo)
- **Merged: “add agent/ like starter in develop”**  
  Adds an `agent/` workspace that functions as a simple REPL-style harness for spinning up the repo locally, loading characters, and running runtimes with SQL-backed configuration. This should lower the barrier for contributors who want to test core behavior without wiring a full connector stack.

### Reliability fix in progress: TOON action parameters + async task continuation loops
- **Open PR: #6709 “Fix/toon action params”**  
  This is a practical fix for teams using “TOON encapsulation” connectors (Discord/Milady, etc.):
  - Ensures TOON schema actually requests **action params**, so required fields like `RUN_IN_TERMINAL.command` get populated.
  - Prevents repeated “continuation loops” for async task actions (e.g., `CREATE_TASK`, `SPAWN_AGENT`) that previously could spam filler responses while PTY work ran in the background.

### Group chat sanity: addressee routing & anti-loop guidance
- **Open PR: #6712 “group addressee routing and anti-loop prompt guidance”**  
  Adds deterministic (non-LLM) routing for group rooms using a name-variation registry and reply-thread metadata to better decide when the agent should respond—or stay quiet—when messages are aimed at someone else. Also tightens prompt templates to reduce ping-pong loops and encourage closure.

### Strategic direction: moving beyond messaging protocols
- The weekly project summary notes a deliberate shift away from “standalone messaging protocol” focus toward **AgentID**—a cryptographic identity and trust framework—plus capability-based authorization discussions. This aligns closely with the community’s safety concerns around what agents should/shouldn’t be allowed to do.

---

## 3) Community Spotlight (Discord)

### Socket.IO integration breakthrough (ElizaOS v2)
A standout developer thread came from **@shah0406**, who debugged ElizaOS v2 Socket.IO behavior while building a custom dashboard:

- The working pattern is:
  - `socket.emit('message', { type: 1, payload: ... })` for **ROOM_JOINING**
  - `socket.emit('message', { type: 2, payload: ... })` for **SEND_MESSAGE**
- Authentication requires passing `{ entityId: UUID }` in Socket.IO options.
- Their setup: `@elizaos/plugin-openai`, local **Qwen3.5 via Nosana GPU** (port 3001), plus a dashboard on port 8080 with Socket.IO and HTTP polling fallback.

**What the community asked for next:** canonical docs for *all* message types, required vs optional payload fields, and how to programmatically create/discover DM channels without the official UI.

### Deployment tooling: “no-code serverless agents”
**Hatcher.host** was shared as a free-beta, no-code deployment option for Eliza/Milady agents—interesting for non-ops folks who want agents running without managing servers.

### Ecosystem chatter: elizabao_ai + multichain clarification
- elizabao_ai drew interest; community members asked what it is and what can be done today. The response: still in development, with plans for elizacloud integration and prediction-market agents.
- A separate thread clarified (again) that **ElizaOS is multichain**, not moving exclusively from one chain to another.

### Support friction: Collab.land wallet verification
A wallet verification issue surfaced and wasn’t resolved in-channel—worth flagging as a recurring onboarding pain point.

---

## 4) Token Economics (AI16z token + auto.fun)

### AI16z / ElizaOS token sentiment this week
Discussion centered on fundamentals: **token utility, buybacks, airdrops, and “Jeju gas fee” timing**. Core guidance shared publicly:

- **Airdrops:** confirmed as *planned*, but **no details yet** (eligibility, timing, mechanics not announced).
- **Buybacks / Jeju gas fees:** no new specifics beyond prior statements; timing remains unconfirmed.

Community sentiment was mixed: excitement about progress, but clear frustration about the lack of concrete timelines.

### auto.fun
No concrete auto.fun development updates were present in this week’s aggregated notes. If there are ongoing changes, they weren’t captured in the provided data for Apr 5–11.

---

## 5) Coming Soon

Here’s what to watch over the next couple of weeks:

- **Eliza v3 release path:** new v3 agents are actively testing; expect an announcement once stabilized.
- **AgentID + capability-based authorization:** more design movement here would directly address “agent safety” concerns raised in Discord (preventing unsafe actions).
- **Docs upgrades requested by builders:**
  - v2 Socket.IO message type enum + payload schema reference
  - DM channel creation/discovery guidance
- **Group-room behavior improvements** (addressee routing / anti-loop prompts) could materially improve multi-agent + multi-human rooms—especially Discord-style environments.

---

## 6) Resources (Links)

### Discord threads & references
- ElizaOS docs (recommended for Socket.IO digging): https://docs.elizaos.ai  
- Socket.IO integration discussion summary (Apr 10): ROOM_JOINING / SEND_MESSAGE types + `entityId` auth requirement (see Apr 10 #coders notes)

### GitHub highlights (Apr 5–11)
- **Merged PR:** feat hardening/logging/memory controls — `elizaos/eliza#6562`  
- **Merged PR:** new local agent harness workspace — `elizaos/eliza#6702`  
- **Open PR:** TOON params + async task continuation fix — `elizaos/eliza#6709`  
- **Open PR:** group addressee routing + anti-loop prompts — `elizaos/eliza#6712`

### Notable issues / proposals
- Agent economy + incentives: **AIGEN Protocol** — `elizaos/eliza#6708`  
- Capability token enforcement proposal: `elizaos/eliza#6707`  
- macOS CLI create failure (“Bun postinstall not run”): `elizaos/eliza#6704`  
- Marketplace + compute + swaps plugin proposal (MAXIA): `elizaos/eliza#6700`  
- Token safety checks plugin proposal (SafeAgent): `elizaos/eliza#6706`  
- Delegation chains & scoped authority proposal: `elizaos/eliza#6711`  
- MCP server security grade (“A”): `elizaos/eliza#6710`