# ElizaOS Developer Update (2026-04-14 → 2026-04-21)

This week emphasized runtime stability (memory + routing), dependency hygiene across the monorepo, and early traction on **agent monetization primitives** (marketplace + commerce standardization) ahead of the upcoming **ElizaOS v3** push.

---

## 1) Core Framework

### In-memory DB correctness: `roomId` migration in `updateMemories`
A critical consistency bug was fixed in the TypeScript runtime’s in-memory DB adapter: when a memory’s `roomId` changed, the adapter updated the memory object but **did not move it between per-room indexes**, leaving the memory “stranded” in the old room list and missing from the new room list.

- Fix: properly remove from the old room list and insert into the new one.
- PR: **Fix roomId changes in `InMemoryDatabaseAdapter.updateMemories`** ([elizaos/eliza#6965](https://github.com/elizaos/eliza/pull/6965))

**Why this matters:** Any agent that relies on room-scoped context (Discord channels, Telegram chats, multi-thread inboxes) can silently lose retrieval accuracy after room reassignment (e.g., thread merges, channel mapping changes, cross-channel routing).

---

### LifeOps runtime: Discord routing reliability
Routing issues in `app-lifeops` were addressed to improve cross-channel message delivery and reduce “lost message” scenarios.

- PR: **lifeops discord routing + submodule bumps** ([elizaos/eliza#6971](https://github.com/elizaos/eliza/pull/6971))

This aligns with ongoing work to make orchestration and multi-channel service mixins behave deterministically under load.

---

### Background task & concurrency unification: shared `batch-queue`
Core TypeScript now includes a shared concurrency and batching substrate (`utils/batch-queue`) to unify high-concurrency internal workflows (embeddings drains, indexing, prompt batching affinity tasks, bounded knowledge embedding work).

- PR: **shared batch-queue drains and bounded knowledge embeddings** ([elizaos/eliza#6722](https://github.com/elizaos/eliza/pull/6722))
- Docs: Background tasks guide (see repo docs updates in [#6722](https://github.com/elizaos/eliza/pull/6722))

**Developer takeaway:** if you previously implemented bespoke queues/semaphores inside plugins for embedding/indexing, you should consider migrating to the shared queue primitives to match runtime scheduling and backpressure behavior.

---

## 2) New Features

### Elisym marketplace integration: turn any v1 agent into a paid provider (SOL settlement)
Elisym Labs released a new plugin that bridges **ElizaOS v1 agents** into the **Elisym decentralized AI-agent marketplace**, enabling paid job execution with capability discovery over Nostr and payments on Solana.

- Package announced: `@elisym/plugin-elizaos` (renamed per registry convention to **plugin-elizaos-elisym**)
- Registry PR (review requested): **Add Elisym plugin** ([elizaos-plugins/registry#346](https://github.com/elizaos-plugins/registry/pull/346))
- Discord thread (coders channel, release announcement + rename request):  
  https://discord.com/channels/1253563208833433701/1300025221834739744

**How it works (per Elisym spec):**
- Publishes capability cards over Nostr using **NIP-89**
- Accepts encrypted job requests via **NIP-90**
- Executes jobs via:
  - agent model execution, or
  - SKILL.md tool-use loop
- Collects **SOL** payments on Solana
- Supply-chain posture: signed with **GitHub Actions provenance**, includes **110 tests**, CI on every PR

**Minimal integration sketch (conceptual)**
> Exact API surfaces may differ; follow the plugin repo/docs once registry PR lands.

```ts
import { createAgent } from "@elizaos/core";
import { elisymPlugin } from "@elisym/plugin-elizaos-elisym";

const agent = await createAgent({
  character: "./characters/provider.character.json",
  plugins: [
    elisymPlugin({
      nostr: {
        relays: ["wss://relay.damus.io", "wss://nos.lol"],
        capabilityNip: 89,
        jobNip: 90,
      },
      payments: {
        chain: "solana",
        settlementToken: "SOL",
      },
    }),
  ],
});

await agent.start();
```

**Why this is strategically important:** it’s the first “real” end-to-end path discussed this week where an ElizaOS agent can act as a **commercial service endpoint** with decentralized discovery + encrypted tasking + on-chain settlement—consistent with the community direction that **v3 will enable agent revenue generation** (see Discord note from `satsbased`).

---

### Commerce standardization direction (proposal shift)
A new proposal was opened to **standardize agent commerce** (tool/service payments). In parallel, three earlier proposals related to Merxex agent-to-agent commerce were reviewed and closed, signaling consolidation around a more general commerce protocol shape rather than single-vendor integration.

- Mentioned in daily digest: https://elizaos.github.io/api/summaries/overall/day/2026-04-20.json  
- (If you’re tracking Merxex issues) See April issue activity around **#6961 / #6966 / #6967** in `elizaos/eliza` (proposal lifecycle referenced in the digest).

---

## 3) Bug Fixes (critical/impactful)

### Memory index corruption (room moves) — fixed
As described above: [elizaos/eliza#6965](https://github.com/elizaos/eliza/pull/6965)

**Impact:** fixes incorrect context retrieval after room reassignment; prevents “phantom” memories appearing in the wrong room and missing in the correct room.

---

### Discord routing regressions in LifeOps — fixed
As described above: [elizaos/eliza#6971](https://github.com/elizaos/eliza/pull/6971)

**Impact:** improves message delivery reliability across Discord-connected LifeOps flows.

---

### Dependency/security maintenance (selected highlights)
Multiple dependency PRs landed or were queued to reduce known-risk surfaces and keep build tooling current. Notable updates mentioned in the daily digest include:
- `@coral-xyz/borsh` update ([elizaos/eliza#6958](https://github.com/elizaos/eliza/pull/6958))
- Capacitor monorepo update ([elizaos/eliza#6957](https://github.com/elizaos/eliza/pull/6957))
- `gymnasium` update for OSWorld benchmark harness ([elizaos/eliza#6952](https://github.com/elizaos/eliza/pull/6952))
- Rust wasm-bindgen monorepo update ([elizaos/eliza#6949](https://github.com/elizaos/eliza/pull/6949))

---

## 4) API Changes (developer-facing)

### Plugin registry naming convention enforcement (ecosystem-facing)
A minor but important ecosystem convention surfaced this week: registry entries and package naming are being tightened. The Elisym integration was renamed promptly after review feedback.

- Registry PR to review: [elizaos-plugins/registry#346](https://github.com/elizaos-plugins/registry/pull/346)
- Discord request + rename confirmation: https://discord.com/channels/1253563208833433701/1300025221834739744

**Action for plugin authors:** ensure your published package name and registry slug match the expected `plugin-<vendor>` / `plugin-<integration>` conventions to reduce install-time confusion and improve discoverability.

---

### Runtime composition surface evolving (watchlist)
Recent work in the v2 line introduced changes around runtime composition and character loading (e.g., `loadCharacters` accepting file paths/options), which can affect CLI tooling and scaffolds.

- PR: **add agent/ like starter** ([elizaos/eliza#6702](https://github.com/elizaos/eliza/pull/6702))

If you’re building custom launchers that previously passed in-memory character objects only, validate against the updated runtime-composition tests introduced alongside this change.

---

## 5) Social Media Integrations (Twitter/X, Telegram, Discord, Farcaster)

### Discord
- LifeOps Discord routing fixes: [elizaos/eliza#6971](https://github.com/elizaos/eliza/pull/6971)
- Ongoing community security concern: phishing/scam messages impersonating staff and fake airdrops. Moderators reiterated that Discord “airdrop tags” are scams.
  - Discord recap: 2026-04-18 → 2026-04-20 summaries  
    https://discord.com/channels/1253563208833433701/1253563209462448241

### Telegram
No new Telegram plugin PRs were discussed in the provided logs this week; however, developers were directed to the official examples for correct build patterns:
- Examples directory (v2.0.0 branch tag referenced in support):  
  https://github.com/elizaOS/eliza/tree/v2.0.0/examples

### Twitter/X
Community noted inactivity on the main account while engineering prioritizes ongoing development (Milady + v3 readiness). No plugin-specific X changes were surfaced in the provided data.

### Farcaster
No Farcaster plugin updates were raised in Discord this week.

---

## 6) Model Provider Updates

### Anthropic / OpenRouter / provider stack dependency drift
Provider-related dependency updates were part of the ongoing maintenance stream:
- `@anthropic-ai/sdk` bump (watch for behavior changes in streaming/tooling semantics depending on SDK internals):  
  [elizaos/eliza#6845](https://github.com/elizaos/eliza/pull/6845)
- `@openrouter/ai-sdk-provider` major bump to v2 (potential breaking surface depending on your provider adapter expectations):  
  [elizaos/eliza#6920](https://github.com/elizaos/eliza/pull/6920)

**Recommended developer action:** if you ship a custom provider plugin or pin provider dependencies, run your streaming + tool-call regression tests against these bumped versions before upgrading.

---

## 7) Breaking Changes / V1 → V2 Migration Warnings

### V1 agents + new marketplaces: interoperability exists, but mind the runtime generation gap
The Elisym plugin explicitly targets **ElizaOS v1 agents**; if you are on v2, confirm whether you’re:
- running v1-compatible agent runtime,
- or using v2’s runtime composition APIs and plugin loading behavior.

Until a native v2-compatible Elisym adapter is documented, treat the integration as a v1 bridge with explicit compatibility testing.

---

### Tooling + examples: stop relying on outdated scaffolds
Support requests this week again highlighted that developers should use the maintained examples rather than legacy scaffolding paths.

- Official examples (referenced in Discord support):  
  https://github.com/elizaOS/eliza/tree/v2.0.0/examples

If you’re migrating from v1 tutorials/blog posts, expect differences in:
- character loading,
- plugin discovery,
- runtime composition,
- and multi-package workspace layout.

---

### Security process gap (non-code but operationally breaking)
Security vulnerabilities were reported privately in Discord; there is **no formal bug bounty** and maintainers requested private disclosure rather than public issues/PRs for security findings.

**If you operate production agents:** assume elevated phishing/social-engineering risk in public channels; validate release artifacts, prefer provenance-signed builds where available, and avoid “support ticket” flows initiated by unsolicited DMs.

---

## References / Links (quick index)

- InMemory DB roomId fix: https://github.com/elizaos/eliza/pull/6965  
- LifeOps Discord routing fix: https://github.com/elizaos/eliza/pull/6971  
- Shared batch-queue: https://github.com/elizaos/eliza/pull/6722  
- Agent starter / runtime composition changes: https://github.com/elizaos/eliza/pull/6702  
- Elisym registry PR: https://github.com/elizaos-plugins/registry/pull/346  
- Discord discussion (general): https://discord.com/channels/1253563208833433701/1253563209462448241  
- Discord coders (Elisym plugin announcement): https://discord.com/channels/1253563208833433701/1300025221834739744  
- Examples (v2.0.0): https://github.com/elizaOS/eliza/tree/v2.0.0/examples