# ElizaOS Developer Update (Week of 2026-03-16 to 2026-03-22)

> Data sources for this update: ElizaOS Discord discussions (Mar 19–21, 2026) and referenced repositories. No GitHub PR/issue deltas for the week were included in the provided dataset; where applicable, this update links to the repos or Discord threads that surfaced the work.

---

## 1) Core Framework

### Ecosystem layering clarified (ElizaOS ↔ Milady ↔ OpenClaw)
Developers clarified the intended architecture boundary in **💬-coders**:

- **ElizaOS** remains the *foundational agent operating system/runtime* and is not being “replaced”.
- **Milady** is an application/framework **built on top of ElizaOS** (consumer-facing product surface), not a competing runtime.
- **OpenClaw agents** can exist within Milady, indicating composability rather than a forked ecosystem.

Links:
- Discord: **💬-coders** clarification thread (Mar 21)  
  https://discord.com/channels/1253563208833433701/1300025221834739744

Implication for developers:
- Treat Milady as a downstream product consuming ElizaOS primitives (agents, plugins, providers, runtime), not as a separate OS with divergent plugin APIs.
- When building reusable components, target ElizaOS plugin interfaces first; Milady should consume them via configuration rather than bespoke integrations.

---

## 2) New Features

### Permissionless on-chain raffles plugin (Base) announced: “moltraffle”
A community plugin release was announced for **Base** supporting USDC raffles with Chainlink VRF-based randomness and a calldata-based approach compatible with any Base wallet.

**Exposed actions (per announcement):**
- `LIST_RAFFLES`
- `GET_RAFFLE`
- `JOIN_RAFFLE`
- `CREATE_RAFFLE`
- `DRAW_WINNER`

Next step for publication:
- Suggested path is submitting a PR to the ElizaOS plugin registry for discoverability.

Links:
- Registry repo (submission target): https://github.com/elizaos-plugins/registry
- Discord context (Mar 19): https://discord.com/channels/1253563208833433701/1253563209462448241

**Example: wiring a custom plugin action into an agent (illustrative)**
```ts
// agent.config.ts (illustrative - align to your ElizaOS version)
export default {
  name: "raffle-agent",
  plugins: [
    // once published/installed, e.g.:
    // "@elizaos/plugin-moltraffle"
  ],
  actions: {
    // Pseudocode: the agent runtime routes tool invocations to plugin actions
    CREATE_RAFFLE: { enabled: true },
    JOIN_RAFFLE: { enabled: true },
    DRAW_WINNER: { enabled: true },
  },
};
```

**Operational note:** Since this plugin executes on-chain actions, ensure your runtime wallet management is hardened (key handling, RPC reliability, chain ID pinning, and idempotency protections for retries).

---

## 3) Bug Fixes (and critical issues under active investigation)

> The week’s Discord logs emphasize operational incidents and release-blocker fixes; only some are confirmed fixes vs ongoing investigations.

### Milady build fixes (beta release unblocked)
Milady beta was announced as “playable and running” after “wrapping up some build fixes”.

Links:
- Milady repository: https://github.com/milady-ai/milady
- Discord announcement (Mar 21): https://discord.com/channels/1253563208833433701/1253563209462448241

**Release engineering follow-ups noted by devs/community:**
- GPG key and SHA256 checksum issues were flagged as needing resolution (important for supply-chain verification and reproducible distribution).

### ElizaCloud disk image upload failure (investigating)
A deployment/storage incident was reported: disk images appear to upload but **do not arrive server-side** (“no image received on server end”).

Context:
- Current stack mentioned: **elizaos 1.x CLI + elizacloud**
- Investigation ongoing; root cause unknown from provided data.

Discord context (Mar 20):
https://discord.com/channels/1253563208833433701/1253563209462448241

**Suggested debugging checklist (developer-side)**
```bash
# 1) Capture HTTP traces (if CLI supports verbose output)
elizaos cloud upload-image --verbose

# 2) Verify artifact size locally (catch zero-byte / truncation)
ls -lh ./your-image.tar.gz
shasum -a 256 ./your-image.tar.gz

# 3) Confirm endpoint + auth are correct (env vars / config)
env | grep -E 'ELIZA|CLOUD|TOKEN|AUTH'
```

### Critical deployment error: `Cannot find module '@elizaos/plugin-discord'` (investigating)
A user reported a cloud deployment failing after enabling the Discord plugin in the GUI, with the runtime error:

- `Cannot find module '@elizaos/plugin-discord'`

This indicates a packaging/installation mismatch between:
- what the UI enables, and
- what the container image actually includes (monorepo workspace install, registry resolution, or build step omission).

Discord context (Mar 19):
https://discord.com/channels/1253563208833433701/1253563209462448241

**Immediate mitigations (until fixed upstream)**
1) If building custom images, explicitly add the plugin dependency:
```bash
# inside your agent repo / image build context
pnpm add @elizaos/plugin-discord
# or npm/yarn equivalent based on your lockfile strategy
```

2) Ensure the plugin is included in the runtime’s plugin load list (config) and that your build step installs production deps (not dev-only).

3) If using a managed GUI toggler, verify it also mutates the underlying dependency graph (not just runtime config). This is the likely integration gap.

### Missing “container reload” control in GUI (feature request)
A related operational issue: after a bad deployment, the container became “stuck” with no apparent GUI-based reload mechanism. This is flagged as an infra UX gap impacting iteration speed and recovery from misconfigurations.

---

## 4) API Changes

No explicit API signature changes were provided in the week’s dataset (no PRs/commits attached).

**However, a practical compatibility warning emerged:**
- Cloud UI plugin toggles may not guarantee corresponding dependency availability in the built artifact (see plugin-discord module resolution incident). Treat “API” here as the *contract between UI configuration and image contents*—it currently appears leaky.

Recommendation:
- Pin your agent images to explicit dependencies and treat UI toggles as configuration only, unless the platform documents and guarantees dependency injection.

---

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

### Discord plugin: deployment packaging incident (high priority)
The most significant social integration signal this week is negative: the Discord plugin failed to resolve in ElizaCloud deployments for at least one user.

Action item for maintainers/platform:
- Validate that `@elizaos/plugin-discord` is included in the default image set (if intended), or that the deployment pipeline installs plugin packages when enabled via GUI.

No updates were provided this week for:
- Twitter/X plugin
- Telegram plugin
- Farcaster plugin

---

## 6) Model Provider Updates (OpenAI / Anthropic / DeepSeek / etc.)

No provider integration changes were present in the provided weekly dataset (no PRs/issues referenced; no Discord technical threads on model providers).

---

## 7) Breaking Changes (V1 → V2 migration warnings)

### Runtime/Cloud: V1 CLI + ElizaCloud coupling risks
The platform is explicitly referenced as running **elizaos 1.x CLI + elizacloud**. Even without an announced V2 in this dataset, developers should assume the following migration hazards if/when V2 lands:

- **Plugin resolution model may change** (workspace packages vs registry installs vs bundled defaults).
- **Deployment artifacts may shift** (disk image format, signing/checksum expectations, server-side ingestion).
- **Config schema drift** is likely (plugin enablement, provider blocks, secrets management).

**Practical steps to reduce migration pain now**
```bash
# Pin versions in CI/CD
elizaos --version
node --version
pnpm --version

# Export a “known-good” resolved dependency tree
pnpm list --depth 2 > deps.snapshot.txt
```

### Token migration confusion is impacting developer onboarding (docs gap)
While not a runtime breaking change, Discord feedback indicates migration complexity is confusing new entrants and creating support load. Developers shipping apps on ElizaOS should:
- link to canonical migration docs (if/when published), and
- avoid ambiguous naming across “Milady” vs “ElizaOS” assets and environments.

---

## References / Links

- Discord **💬-discussion** (Mar 19–21 context):  
  https://discord.com/channels/1253563208833433701/1253563209462448241
- Discord **💬-coders** (architecture clarification):  
  https://discord.com/channels/1253563208833433701/1300025221834739744
- Milady repository: https://github.com/milady-ai/milady
- ElizaOS Plugin Registry: https://github.com/elizaos-plugins/registry