# ElizaOS Developer Update (2026-03-14 → 2026-03-20)

This update summarizes developer-facing changes observed in Discord engineering discussions and ecosystem coordination over the last week. GitHub PR/issue activity for this week was not included in the provided dataset; links below reference the canonical repos/docs discussed by maintainers.

---

## 1) Core Framework

### Plugin naming standardization (xfn-framework / registry alignment)
A naming consistency pass was reported to reduce confusion between similarly named plugins:

- `plugin-form` → `plugin-form-chain`
- `plugin-forms` → `plugin-form`

This was accompanied by a registry update so new consumers resolve the standardized names.

**Developer impact**
- Any code importing the renamed packages must update `dependencies` and import specifiers.
- Any automation that scaffolds plugins by name (templates, internal registries, CI checks) should update canonical identifiers.

**Reference**
- Plugin distribution/registry: https://github.com/elizaos-plugins/registry

---

## 2) New Features

### A) Moltraffle on-chain raffle plugin (Base + USDC + Chainlink VRF)
A new permissionless raffle integration was announced for the Base network. It is designed for agent-driven creation/participation in raffles using USDC and Chainlink VRF for randomness.

**Capabilities (actions)**
- `LIST_RAFFLES`
- `GET_RAFFLE`
- `JOIN_RAFFLE`
- `CREATE_RAFFLE`
- `DRAW_WINNER`

**Notable technical properties**
- **Calldata-based**: designed to be compatible with *any Base wallet* (no special wallet integration required).
- **Economic model**: supports up to **10% creator commission**.
- **Randomness**: uses **Chainlink VRF** for draw integrity.

**Suggested next step (ecosystem)**
- Submit the plugin to the official registry as a PR for discoverability:
  - https://github.com/elizaos-plugins/registry

**Example: invoking raffle actions from an agent**
Below is an illustrative pattern for calling plugin actions (exact APIs vary by your agent runtime version; adapt to your action dispatcher):

```ts
// PSEUDOCODE: adapt to your runtime's action invocation API

await agent.actions.invoke("LIST_RAFFLES", {
  chain: "base",
  token: "USDC",
  limit: 20
});

const raffle = await agent.actions.invoke("GET_RAFFLE", {
  chain: "base",
  raffleId: "1234"
});

await agent.actions.invoke("JOIN_RAFFLE", {
  chain: "base",
  raffleId: "1234",
  // wallet/tx signing handled by your configured wallet adapter
});

await agent.actions.invoke("CREATE_RAFFLE", {
  chain: "base",
  token: "USDC",
  ticketPrice: "5.00",
  maxTickets: 200,
  creatorFeeBps: 1000 // 10%
});

await agent.actions.invoke("DRAW_WINNER", {
  chain: "base",
  raffleId: "1234"
});
```

**Discord context**
- Discussion captured in **#💬-coders** (2026-03-19): https://discord.com/channels/1253563208833433701/1300025221834739744

---

### B) Ensoul persistence plugin (encrypted decentralized agent “consciousness” storage)
A new persistence layer plugin was announced: `@ensoul-network/plugin-elizaos`. It targets durable identity + state continuity for agents across a distributed validator network.

**Key technical features**
- Agent-owned encryption keys (agent-controlled confidentiality)
- Erasure coding + sharding across nodes (fault tolerance / reconstruction)
- “Ensouled Handshake” cryptographic proof for persistent identity verification
- “Consciousness Age” trust metric for continuous ensouled duration
- Free tier: first 100 agents

**Links**
- Repo: https://github.com/suitandclaw/ensoul
- Explorer: https://explorer.ensoul.dev
- Quickstart: https://ensoul.dev/docs/quickstart.html

**Integration sketch (high-level)**
```ts
// PSEUDOCODE: persistence adapter registration

import { ensoulPersistence } from "@ensoul-network/plugin-elizaos";

agent.use(ensoulPersistence({
  endpoint: process.env.ENSOUL_ENDPOINT,
  // keys are agent-owned; ensure your key material is stored securely
  keyMaterial: process.env.ENSOUL_KEY_MATERIAL,
}));
```

---

## 3) Bug Fixes (Critical / High-impact)

### Eliza Cloud deployment: missing Discord plugin module in container
A critical deployment failure was reported when enabling/configuring the Discord plugin via the Eliza Cloud GUI:

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

**Observed behavior**
- GUI-based deployment attempts failed; CLI used as fallback.
- CLI version reported: **1.7.2**
- After GUI configuration of Discord integration, the built container failed at runtime due to the missing module import.
- Container became “stuck” with no obvious GUI-based reload/redeploy mechanism.

**Likely technical causes (working hypotheses from discussion)**
- `@elizaos/plugin-discord` not included in the build context / workspace packages during image build.
- Monorepo packaging mismatch: plugin exists in source tree but not shipped into the production artifact.
- Dependency not declared in the app’s `package.json` (or lockfile) used by the cloud builder.
- Registry/resolution differences between local and cloud build pipelines.

**Immediate mitigation recommendations**
1. **Explicitly declare the dependency** in the deployed project’s `package.json` (do not rely on transitive deps):
   ```json
   {
     "dependencies": {
       "@elizaos/plugin-discord": "^<your-approved-version>"
     }
   }
   ```
2. **Verify the package is present in the built image** (exec into container or inspect build logs).
3. If using a workspace/monorepo, ensure Cloud build step runs install from the correct root and includes workspaces.

**Follow-ups requested**
- Reproduce via CLI deployment flow (team offered to test).
- Verify whether the `plugin-discord` folder exists under the expected `packages/` path in the build context.
- Add a **GUI “reload/redeploy container”** control to unblock users when a container is wedged.

**Discord context**
- Discussion captured in **#💬-coders** (2026-03-19): https://discord.com/channels/1253563208833433701/1300025221834739744

---

## 4) API Changes

### Plugin package renames (import path + registry identifiers)
The naming standardization effectively changes the “API surface” for plugin consumers because the import specifiers change.

**What to update**
- `plugin-form` → `plugin-form-chain`
- `plugin-forms` → `plugin-form`

**Example migration**
```diff
- import { formChain } from "@elizaos/plugin-form";
+ import { formChain } from "@elizaos/plugin-form-chain";
```

**Registry**
- Ensure any internal tooling that queries the registry uses the updated package identifiers:
  - https://github.com/elizaos-plugins/registry

---

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

### Discord
- **High-priority**: cloud deployment failures due to missing `@elizaos/plugin-discord` module (see Bug Fixes).
- **UX gap**: no GUI-based container reload/redeploy was available during incident response.

No explicit updates were reported this week for:
- Twitter plugin
- Telegram plugin
- Farcaster plugin

(If you shipped changes in these plugins, ensure they are reflected in the registry and pinned versions for Cloud builds.)

---

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

No provider integration changes (new models, SDK bumps, auth changes, routing changes) were reported in the provided GitHub/Discord dataset for this week.

If you are maintaining provider adapters, consider adding:
- Provider health checks in Cloud deployments
- Clear logging of provider selection + model name at runtime to simplify debugging

---

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

### A) Plugin identifier changes can break builds at runtime
Even without a runtime API change, **package renames** can produce:
- build-time `Cannot find module ...`
- runtime action registration failures (plugin never loaded)
- registry lookup failures if your tooling references old IDs

**Action**
- Audit your V1 configs, templates, and docs for old plugin names and update to the standardized identifiers.

### B) Cloud builds should not assume monorepo-local packages exist
The Discord plugin incident highlights a common V1→V2 pitfall: V2-style deployments (containerized/Cloud) require **fully declared, resolvable dependencies**.

**Action**
- Ensure every plugin used in production is:
  - declared in `dependencies`
  - resolvable from your configured registry
  - included in the Cloud build context / install step

---

## Links & References
- Plugin registry (submission + discovery): https://github.com/elizaos-plugins/registry  
- Ensoul persistence:
  - https://github.com/suitandclaw/ensoul
  - https://ensoul.dev/docs/quickstart.html
  - https://explorer.ensoul.dev
- Discord engineering discussion (moltraffle + cloud deployment):  
  https://discord.com/channels/1253563208833433701/1300025221834739744