# ElizaOS Developer Update (2026-03-18 → 2026-03-24)

This update summarizes **public development signals** observed across Discord discussions and the available aggregated project data for the week. **No GitHub PR/issue activity for this week was included in the provided dataset**, so the “Core Framework / Bug Fixes / API Changes” sections focus on confirmed architecture clarifications and integration proposals discussed by developers/community members.

Relevant discussion source:
- Discord (#discussion): https://discord.com/channels/1253563208833433701/1253563209462448241

Reference docs repeatedly shared this week:
- Roadmap (source of truth in lieu of a “token whitepaper”): https://github.com/elizaOS/roadmap  
- Research paper (arXiv): https://arxiv.org/abs/2501.06781  

---

## 1) Core Framework

### Ecosystem layering clarified: ElizaOS vs Milady vs OpenClaw
Core contributors clarified a common misconception about “Milady replacing ElizaOS”:

- **ElizaOS** is the foundational **agent OS/runtime + plugin ecosystem**.
- **Milady** is an **application built on top of ElizaOS**, not a competing framework.
- **OpenClaw agents can exist within Milady**, implying compatibility rather than replacement.

Why it matters to developers:
- If you are building plugins/agents, you should treat Milady as **a client/application surface** that may impose UX/product constraints, while **ElizaOS remains the underlying integration/runtime contract**.
- Expect Milady to consume ElizaOS primitives (agent runtime, memory, tool/plugin calls) rather than redefining them.

(Discord context: 2026-03-21 discussion summary)

---

## 2) New Features

### Proposal/Announcement: Autonomous agent monetization plugin (Base + on-chain marketplace)
A community developer (TraderTomson) announced a plugin concept enabling:
- Agents to **register themselves** on an **on-chain marketplace (Base)**
- Agents to **post services**, be **hired by other agents**, and **receive payment in AGT**
- “Season 1” incentives: **50M AGT pool** for early adopters

No PR/repo link was included in the provided data this week, so treat this as an **integration announcement** rather than a merged feature.

#### Suggested plugin design pattern (example)
If you’re implementing a similar marketplace plugin, keep the agent runtime boundary explicit: on-chain writes should be performed by a narrow adapter with clear idempotency + replay protection.

```ts
// Example only — adapt to ElizaOS plugin interfaces used in your branch.
export const marketplacePlugin = {
  name: "plugin-marketplace-base",
  actions: [
    {
      name: "marketplace.registerAgent",
      description: "Registers this agent in the on-chain marketplace",
      schema: {
        type: "object",
        properties: {
          metadataURI: { type: "string" },
          serviceTags: { type: "array", items: { type: "string" } }
        },
        required: ["metadataURI"]
      },
      async handler(ctx, input) {
        // 1) Resolve agent identity (signer/wallet) from runtime config
        const signer = await ctx.wallet.getSigner();

        // 2) Construct tx with nonce + chainId to prevent replay
        const tx = await ctx.marketplaceContract.registerAgent({
          metadataURI: input.metadataURI,
          tags: input.serviceTags ?? [],
          nonce: await ctx.nonceStore.next("marketplace.registerAgent")
        });

        // 3) Submit + wait for confirmation (or return pending tx hash)
        const receipt = await signer.sendTransaction(tx).then(r => r.wait(1));
        return { txHash: receipt.transactionHash };
      }
    }
  ]
};
```

Operational guidance:
- Prefer **async confirmation handling** (return txHash immediately; reconcile later) to avoid blocking agent loops.
- Add **budget controls** (max gas per action, daily spend caps) to prevent tool-call induced fund loss.
- Log both **intent** (tool call) and **chain outcome** (receipt) to support incident response.

(Discord context: 2026-03-22 summary)

---

## 3) Bug Fixes

### No confirmed code-level fixes in the provided dataset
This week’s provided data does not include merged PRs, issue closures, or patch notes. If you have internal PRs or CI artifacts to include, append them to the next report so we can document:
- root cause
- affected versions
- remediation
- regression tests added

---

## 4) API Changes

### No documented API modifications this week
No runtime/plugin API diffs or version bumps were included in the dataset for 2026-03-18 → 2026-03-24.

---

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

### No integration changes landed (per available data)
No new commits/PRs were provided related to:
- Twitter/X plugin
- Telegram bot/plugin
- Discord plugin changes
- Farcaster integration

Note: there was general discussion about communication channels (weekly “cronjob” video + daily updates channel), but this is **ops/comms**, not a plugin integration update.

---

## 6) Model Provider Updates (OpenAI / Anthropic / DeepSeek / Local)

### Community project: multi-agent trading stack using a 200–500B local model
A community member (naman) described an external build:
- **Multi-agent autonomous crypto trading**
- Powered by a **local 200–500B parameter LLM**
- Seeking an AI/ML partner for **optimization, fine-tuning, and performance monitoring**

This is not a confirmed ElizaOS core integration change, but it’s a relevant signal for developers running large local inference.

If you are attempting similar deployments in ElizaOS, ensure you have:
- **token/latency budgets** per agent loop
- **streaming + cancellation** support to prevent tool-call pileups
- **observability** (per-agent latency, provider errors, queue depth)

(Discord context: 2026-03-23 summary)

---

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

### No new breaking changes reported in this week’s dataset
However, two ongoing risk areas remain relevant:

1) **App vs OS boundary confusion (Milady vs ElizaOS)**  
   If you ship agents/plugins assuming Milady-specific behavior, you may create accidental coupling. Treat Milady as **one consumer** of ElizaOS capabilities.

2) **Token migration / supply discussions are not runtime migrations**  
   Community conversation referenced token migration and supply outcomes, but **no corresponding ElizaOS runtime migration steps** (config/schema/tooling changes) were provided here. Don’t conflate economic events with framework API stability.

---

## Appendix: Milady App Status (Delivery Signal)
- Milady app is in **active development**, with the team reporting weekend work and direct engineering involvement.
- **No release date** was provided publicly (“launch when it’s ready”).

(Discord context: 2026-03-23 summary)

---