# ElizaOS Developer Update (2026-03-22 → 2026-03-28)

## 1) Core Framework

### Platform/hosting topology (ElizaCloud / DegenAI)
Discussion this week focused on operational consolidation rather than runtime-level code changes:

- **Environment consolidation plan:** production + development environments are being collapsed into **a single staging environment** (“one Spartan instance”) to reduce operational overhead while retaining all customer data in one managed plane. This is primarily a deployment/infrastructure change, but developers running managed agents should expect:
  - fewer environment-specific divergences,
  - a stronger emphasis on staging parity,
  - potential changes to how you request test vs. production rollouts (watch for forthcoming ElizaCloud comms).

Reference: Discord notes (2026-03-26) in community discussion.

### Project governance clarification (impacts expectations, not APIs)
A heated community thread clarified that **Hyperscape is incubated by Eliza** and is *not* an official “Eliza Labs product launch,” described as somewhere between a JV and a Shaw-led project. This matters for developers because:
- Hyperscape roadmap/release cadence should not be treated as a guaranteed core-framework dependency.
- Use it as an integration target/reference app, but avoid coupling production requirements to Hyperscape timelines.

Context: Discord (2026-03-27)  
Link: https://discord.com/channels/1253563208833433701/1253563209462448241

## 2) New Features

### `@elizaos/plugin-xproof`: On-chain decision provenance (MultiversX)
A new plugin, **xProof.app**, was announced and submitted to the official plugin registry. The plugin’s purpose is to provide **decision provenance** by anchoring an agent’s decision to the **MultiversX** blockchain *before* execution:

- Creates **immutable timestamps** for decisions.
- Timestamp is written by the chain (reducing “agent says it did X at time Y” ambiguity).
- Offers **10 free certificates** without requiring a wallet (useful for evaluation and demos).

Registry PR:
- https://github.com/elizaos-plugins/registry/pull/266

Install (as shared in Discord):
```bash
npm install @elizaos/plugin-xproof @xproof/xproof
```

Integration pattern (high-level; exact wiring depends on your runtime bootstrap):
```ts
// Example only: adapt to your agent/runtime initialization.
// Goal: register the plugin and call it at "decision -> action" boundary.

import { xproofPlugin } from "@elizaos/plugin-xproof";

const runtime = await createRuntime({
  plugins: [
    xproofPlugin({
      // config is plugin-specific; consult plugin docs once merged/published
      // e.g. network, certificate mode, project key, etc.
    }),
  ],
});

// Pseudocode: anchor a decision prior to execution
runtime.on("beforeAction", async (ctx) => {
  // ctx.decision could include tool name, arguments, and model output hash
  await runtime.plugins.xproof?.anchorDecision({
    agentId: ctx.agentId,
    decision: ctx.decision,
  });
});
```

Action item for maintainers:
- Review/merge registry submission: https://github.com/elizaos-plugins/registry/pull/266

### Trading “flow” plugin (WIP): plug-and-play trading infrastructure
Developer **meowww404** is building a **trading flow plugin** intended to let Eliza agents integrate with external trading infrastructure in a plug-and-play manner. Maintainer response requested the **registry PR or plugin name** to start evaluation for inclusion/distribution support.

Status:
- Not yet linkable (registry PR/name not provided in the captured logs)
- Next step: contributor to submit registry entry PR to `elizaos-plugins/registry`

Context: Discord (2026-03-27)  
Link: https://discord.com/channels/1253563208833433701/1253563209462448241

### Community architecture spotlight: NFT-personality mapped agent workspaces (V1-compatible)
A community project described an NFT-driven agent system:
- 4,444 agent workspaces
- deterministic personality mapping (7 dimensions; Big Five + trading scores)
- **ElizaOS V1 spec compatibility** (YAML frontmatter + `character.json` export)
- MemGPT-style 3-tier memory architecture
- live market data injection (CoinGecko / DeFiLlama / DexScreener)

This is not merged into core, but it’s a useful reference design for:
- deterministic persona generation,
- memory tiering,
- real-time data feeds inside sessions.

Context: Discord (2026-03-25)

## 3) Bug Fixes

No core-framework or first-party plugin bug fixes were surfaced in the provided GitHub/Discord data for this week.

If you are blocked on a critical issue, include:
- runtime version,
- plugin list,
- model provider,
- minimal reproduction character/config,
and post in `#💬-coders` or open an issue in the relevant repository.

## 4) API Changes

No API changes were identified in the provided activity for 2026-03-22 → 2026-03-28.

Notable “process API” change request (docs/process, not code):
- Contributors asked for clearer guidance on **plugin submission + distribution support** (what gets accepted into the main registry, expected timelines, and any promotion channels).

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

- A **Babylon Demo Day** was broadcast live on X (Twitter). No plugin-level changes were recorded, but if you maintain social integrations, consider documenting:
  - recommended streaming announcement flows,
  - rate-limit safe posting patterns,
  - and event-driven triggers (e.g., “demo-day live” notifications).

Context: Discord (2026-03-27)  
Link: https://discord.com/channels/1253563208833433701/1253563209462448241

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

No model provider integration changes were present in this week’s provided data.

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

No new breaking changes were reported in the provided logs this week.

However, V1 compatibility continues to matter in the ecosystem:
- Community projects are explicitly targeting **ElizaOS V1 spec compatibility** (YAML frontmatter + `character.json` export). If you are migrating to (or already on) V2 semantics, ensure your tooling can still:
  - import/export V1-style characters, or
  - provide a deterministic conversion step.

Recommendation (until official migration notes are published/updated):
- Treat character schema and plugin loading as versioned interfaces in your own apps (e.g., `character.schemaVersion`), and gate transforms accordingly.

---

### Links referenced this week
- Plugin registry PR (xProof): https://github.com/elizaos-plugins/registry/pull/266
- Discord discussion (plugin inclusion + Hyperscape clarification): https://discord.com/channels/1253563208833433701/1253563209462448241