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

> Data sources available this week: ElizaOS Developer Discord (Mar 23–25). No GitHub PR/issue/event feed was included in the provided dataset for this date range, so this update focuses on community-shared implementations, integration patterns, and security considerations surfaced in Discord.

Relevant threads:
- Discord #coders (autonomous trading agents + NFT agent workspaces): https://discord.com/channels/1253563208833433701/1300025221834739744  
- Discord #discussion (onboarding + milady token support question): https://discord.com/channels/1253563208833433701/1253563209462448241  

---

## 1) Core Framework

### Runtime patterns emerging: “Trading agent” as a first-class workload
Multiple builders are converging on a common ElizaOS runtime shape for autonomous trading:

- **Signal ingestion layer** (market data, on-chain oracle data, social/news)
- **Stateful memory** (short-term conversation context + mid-term scratchpad + long-term portfolio/strategy memory)
- **Action layer** (DEX/CEX execution, alerts, journaling, risk controls)

This week’s discussion highlighted two concrete approaches to the “signal ingestion” layer:

1) **Off-chain API pipeline injection** (CoinGecko/DeFiLlama/DexScreener) directly into agent sessions (community project below).  
2) **On-chain oracle indicators via MCP** (Pythia MCP server using Chainlink on Polygon), removing API-key and rate-limit dependencies for certain indicators.

### MCP as the integration boundary for market indicators
The **Pythia MCP server** release (community) is effectively a plug-in style “tool server” that can be mounted into an agent’s toolset to query indicators in a deterministic, verifiable way (oracle-backed). This is a strong fit for ElizaOS’ tool-driven agent architecture, especially for DeFi agents where provenance matters.

**Install (community package):**
```bash
pip install pythia-oracle-mcp
```

**What it provides (per Discord):**
- Chainlink oracle-backed indicators on Polygon
- 13 tokens × 4 timeframes
- EMA, RSI, VWAP, Bollinger Bands, volatility metrics
- No API keys required

---

## 2) New Features (Builder Ecosystem)

### A) NFT → Deterministic agent personality + workspace export (The Undesirables)
A substantial community build was shared by **sailorpepe.eth**: *The Undesirables* — **4,444 NFT-backed agent workspaces** where NFT visual traits deterministically map to an agent “personality vector” across **7 dimensions** (Big Five + trading scores). The system includes:

- **ElizaOS V1 spec compatibility**
  - YAML frontmatter support
  - `character.json` export
- **3-tier MemGPT-style memory architecture**
- **Live market data injection** into sessions from:
  - CoinGecko
  - DeFiLlama
  - DexScreener
- “Soul viewer” + downloadable workspaces

Project link shared: https://the-undesirables.com/

**Practical takeaway for ElizaOS devs:** deterministic personality mapping is a scalable way to generate large agent fleets while preserving reproducibility (important for debugging, evaluation, and compliance).

**Example: V1-style YAML frontmatter concept (illustrative)**
```yaml
---
name: "Undesirable #1842"
persona:
  big5:
    openness: 0.72
    conscientiousness: 0.41
    extraversion: 0.18
    agreeableness: 0.33
    neuroticism: 0.61
  trading:
    riskTolerance: 0.77
    patience: 0.22
memory:
  strategy: "memgpt-3-tier"
tools:
  - marketData.coingecko
  - marketData.defillama
  - marketData.dexscreener
---
```

**Example: injecting market snapshots into the session (pattern)**
```ts
// Pseudocode: normalize multiple providers into a single "market snapshot"
const snapshot = await aggregateMarketData({
  symbol: "ETH",
  sources: ["coingecko", "defillama", "dexscreener"],
});

agent.runtime.memory.append({
  type: "context.market_snapshot",
  timestamp: Date.now(),
  payload: snapshot,
});

// The model then reasons over a stable, structured payload rather than raw API text.
```

### B) Nosana × ElizaOS partnership: Builders’ Challenge enablement
A community announcement from **Denis (Nosana ecosystem)**: partnership launch for the **Nosana Builders’ Challenge** (starting Mar 25) with workshops scheduled **Mar 26** and **Apr 2**. This is not a framework code change, but it *is* a material developer-enablement event, and likely to produce short-lived forks/plugins and new “agent templates” oriented around shipping quickly.

---

## 3) Bug Fixes (Critical)

### No core bug-fix PRs were provided in this dataset
No GitHub PRs/issues or changelog entries for Mar 20–26 were included, so this update cannot enumerate merged fixes in `elizaos/eliza` or official plugins.

### “Bug-class” issue surfaced: supply chain attack awareness (litellm-pypi)
A critical security warning was raised in Discord regarding a **supply chain attack on `litellm-pypi`** (acknowledged by Odilitime). Even when this is not an ElizaOS bug per se, it is a **high-severity operational risk** for agents that execute tools, handle secrets, or trade.

**Recommended immediate mitigations for ElizaOS builders:**
- Pin and hash Python dependencies for production agents:
```bash
pip-compile --generate-hashes -o requirements.txt pyproject.toml
pip install --require-hashes -r requirements.txt
```
- Audit dependency trees:
```bash
pip install pip-audit
pip-audit
```
- Prefer allowlisted tool execution and scoped API keys (especially for trading keys).

---

## 4) API Changes

No official ElizaOS API changes were referenced in the provided Discord logs, and no GitHub API diffs were available.

**Note for plugin authors:** if you are depending on community MCP servers (like Pythia), treat them as external APIs:
- version-pin the server package
- define a strict request/response schema
- fail closed on schema mismatch (don’t “best-effort parse” indicator payloads for trading decisions)

---

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

No new merges or releases for official social plugins were included in this week’s dataset.

**Developer interest signal:** onboarding chatter continues, but the strongest pull is around *autonomous trading agents*. If you’re building “trading agent + social presence,” consider:
- posting execution summaries to Discord/Telegram
- gating sensitive tool calls behind confirmations in social channels
- journaling trades to an append-only channel/thread to support later evaluation

---

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

No provider integration changes were referenced in the provided data for this week, and no GitHub diffs were available.

**Operational note for local-model traders:** a builder (Naman) discussed running a **200–500B local model** for 24/7 trading and seeking an AI/ML partner for optimization/monitoring. If you run local providers:
- measure *latency variance* and *tool-call error rate* as first-class metrics (missed fills often correlate more with tail latency than average latency)
- implement “safe mode” fallbacks when the model is degraded (reduce position size, disable new entries, alerts-only)

---

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

### Community projects are explicitly targeting **ElizaOS V1 spec compatibility**
The Undesirables workspace format and exports were called out as V1-compatible (YAML frontmatter + `character.json`). If you are migrating to (or starting on) V2-era agent definitions, watch for these common breaking edges:

- **Character definition schema drift**
  - Field names and nesting may differ (e.g., `persona`, `style`, `tools`, `memory` blocks)
  - Validation strictness may increase (unknown keys rejected rather than ignored)

- **Memory subsystem expectations**
  - A MemGPT-like 3-tier memory strategy may require explicit adapters in V2 if the runtime expects different memory providers or message types.

- **Tooling / plugin interfaces**
  - If your agent relies on “market snapshot injection” as raw text, a newer runtime may require structured tool outputs (JSON schema) instead of free-form strings.

**Migration guidance (practical):**
1) Keep `character.json` exports under version control and add a schema-version tag.
2) Add a translation layer:
```ts
function v1ToV2Character(v1: any): V2Character {
  // Map known fields, drop/flag unknowns, and produce deterministic output.
  // Fail closed for trading agents.
  return {
    name: v1.name,
    traits: v1.persona?.big5,
    toolchain: normalizeTools(v1.tools),
    memoryPolicy: normalizeMemory(v1.memory),
  };
}
```
3) Run golden-test conversations on both runtimes before enabling live keys.

---

## Open Questions / Action Items

- **Autonomous trading agent templates:** Ape Ape | KairoGuard requested feedback/review of their setup; consider sharing minimal reproducible repos/configs in #coders to establish best practices.
- **Milady app token support clarification:** a question was raised about base Milady vs SOL milady.ai token support; no authoritative answer was posted in the thread. If this impacts integrations, publish a single source of truth in docs/FAQ.
- **Security response posture:** given the `litellm-pypi` incident, it’s worth standardizing a dependency-pinning + audit recommendation in ElizaOS docs for production agents (especially trading agents).