# ElizaOS Developer Update (2026-03-09 → 2026-03-15)

## 1) Core Framework (Architecture / Plugin System / Agent Runtime)

### Runtime refactor proposal (in review)
A runtime refactor proposal was circulated (HackMD; link not included in the weekly data dump) with a focus on **making runtime infrastructure registration explicit** and **eliminating implicit side-effects during plugin initialization**.

#### Problem: plugin initialization race condition
A concrete issue was highlighted in current architecture:

- `plugin-sql` registers its database adapter as a **side-effect** during `init()`
- `init()` runs **in parallel** with other plugins
- This allows downstream plugins (e.g., `plugin-personality`) to execute before the adapter exists → **non-deterministic startup behavior**
- `milaidy` currently mitigates by **manually pre-registering** `plugin-sql` before calling `initialize()`, which is acknowledged as treating the symptom, not the root cause

#### Proposed direction: dependency injection over side effects
Instead of relying on “plugin X happens to run first”, the adapter becomes a **required constructor argument** (or runtime-required dependency), forcing explicit wiring.

**Illustrative “before/after” (conceptual):**
```ts
// BEFORE: adapter appears as an init() side-effect (racy if init is parallel)
await runtime.initialize({
  plugins: [
    sqlPlugin(),          // registers adapter during init()
    personalityPlugin(),  // may run before adapter exists
  ]
});
```

```ts
// AFTER: adapter is explicit and must exist before runtime/plugin wiring
import { createSqlAdapter } from "@elizaos/plugin-sql";

const db = await createSqlAdapter({ url: process.env.DATABASE_URL });

await runtime.initialize({
  infrastructure: { db },         // or runtime.setDb(db)
  plugins: [
    personalityPlugin({ db }),    // no implicit dependency on init ordering
  ]
});
```

**Developer impact:** plugin authors should expect a move toward:
- explicit runtime “infrastructure” objects (db, queues, schedulers, wallets)
- predictable initialization order (or dependency graph validation)
- fewer global registries / side-effect registration patterns

### Scheduling / wake-up mechanism
A note from Discord indicates **cron triggers** are being used for agent “wake-up” functionality. If you are building scheduled agents, align your design with externally-triggered wakeups rather than assuming continuous runtime presence.

**Example (conceptual CLI + cron):**
```bash
# every 5 minutes, wake an agent (endpoint is deployment-specific)
*/5 * * * * curl -fsS https://your-agent-host.example.com/wake?id=milady-oracle
```

## 2) New Features (Capabilities + Examples)

### Workflows-as-a-Service (AIProx): scheduled multi-agent pipelines + receipts
`lightningprox` shipped “Workflows-as-a-Service” on AIProx, enabling:
- chaining multiple agents into scheduled pipelines
- pay-per-execution pricing
- execution receipts for transparency/auditing

While this is not a core ElizaOS merge this week, it’s a notable emerging orchestration pattern: **agents as callable services** with **verifiable run logs**.

If you design agents meant to be orchestrated externally, ensure you provide:
- stable HTTP interfaces
- deterministic inputs/outputs (schema)
- idempotency where possible (for retries)
- receipt-friendly logging (run id, timestamps, tool calls)

### Agent discovery via `skill.md`
Following Odilitime’s recommendation, `lightningprox` deployed `skill.md` on:
- https://lightningprox.com/skill.md
- https://solanaprox.com/skill.md

This enables discovery by registries/crawlers such as agentskills.io (and mentioned consumers: OpenClaw, Hermes-agent).

**Minimal `skill.md` example (pattern):**
```md
---
name: SolanaProx
version: 1.0.0
capabilities:
  - slug: solana.tx.simulate
    description: Simulate Solana transactions and return risk summary
  - slug: solana.market.signal
    description: Aggregate market indicators and return a trading signal
pricing:
  rail: solana
  price_per_call: 0.02
endpoint:
  url: https://solanaprox.com/api
---

# SolanaProx Skills
This agent provides Solana simulation and market signal endpoints for orchestrators.
```

### Memelord plugin released (creative generation tool)
A new community plugin integrates Memelord.com for automated meme generation:

- Repo: https://github.com/NewSoulOnTheBlock/plugin-memelord
- Demo agent on X/Twitter: “Memelordicus” (shared in Discord)

**Developer takeaway:** This expands the “content tool” class of plugins—useful for social agents, growth loops, and automated brand/content pipelines.

### Milady prediction market integration (multi-source aggregation)
`ElizaBAO` announced an ongoing “Milady Prediction” system integrating:
- dflow + Kalshi
- Jupiter + Polymarket
- predictdotfun
- Limitless

The key architectural pattern discussed: **aggregate real-world probability signals → decide thresholds → execute on-chain actions**. A pending design decision is the **accuracy/trigger threshold** for execution.

## 3) Bug Fixes (Critical Issues + Technical Context)

### Plugin init race condition (known issue; mitigation in milaidy)
This is the week’s most critical technical issue surfaced: **parallel plugin init + side-effect registration** can break startup determinism.

- **Status:** not confirmed merged/fixed this week (discussion + proposal phase)
- **Current mitigation:** manual pre-registration/order forcing in milaidy
- **Risk:** intermittent failures, environment-dependent boot behavior, hard-to-reproduce startup bugs

**Recommended short-term mitigation for developers (until runtime refactor lands):**
- avoid registering critical infrastructure as a plugin `init()` side-effect
- if unavoidable, enforce ordering explicitly in your app bootstrap (single-thread init or staged init)
- add health checks that verify adapter availability before enabling dependent plugins/tools

### Token migration scam (security incident handling)
A scam attempt was reported: a fake support bot directed users to a site requesting seed phrases. Community guidance reiterated:
- migration window is closed (see below)
- never share seed phrases
- treat “late migration help” DMs as high-risk

While not a code patch, this is a **developer ops** issue: if you run public agents/bots, ensure your official support flows are cryptographically verifiable (signed announcements, pinned messages, verified domains).

## 4) API Changes (Developer-Facing Modifications)

No merged API diffs were included in the provided GitHub activity for this week. However, the runtime refactor proposal implies likely upcoming API changes:

### Likely upcoming change: runtime infrastructure injection
Expect changes along these lines:
- runtime initialization requiring explicit infrastructure objects (e.g., `db`, `wallet`, `scheduler`)
- plugins receiving dependencies via constructor/options rather than reading global registries

**Action for plugin authors:**
- audit your plugin for implicit dependencies (globals, registries, “some other plugin initializes X”)
- plan to expose explicit configuration points:
  - `pluginFoo({ db, logger, signer })`
  - `createFooTool({ provider })`

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

- **Twitter/X:** Memelord plugin was demonstrated live via an agent posting meme outputs to X (plugin-level expansion rather than core Twitter plugin changes).
- **Discord/Telegram/Farcaster:** no core plugin changes were reported in the supplied weekly data.

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

No provider integration changes (new models, API migrations, SDK upgrades) were surfaced in the week’s Discord summaries or the provided GitHub snippets.

If you maintain custom providers, this week’s main runtime topic (dependency injection) is still relevant: provider clients should be explicitly wired rather than implicitly discovered at init-time.

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

### Runtime refactor may introduce breaking changes to plugin initialization
If the proposal lands, expect breaks for plugins that:
- rely on init-time side effects (registering adapters/providers globally)
- assume a particular plugin init order
- assume parallel init won’t affect availability of shared infra

**Migration guidance (prepare now):**
- move shared infrastructure creation to app bootstrap
- pass dependencies into plugins/tools explicitly
- add runtime validation: fail fast if required infra is missing

### Token migration (ai16z → elizaOS) is closed; beware “migration helpers”
Discord confirmed:
- migration window permanently closed on **2026-02-04** (3-month window)
- late migration requests are a common scam vector

**Open questions raised (documentation needed):**
- migration completion rate (% migrated)
- fate of unmigrated tokens (burn vs redistribution)

## Links (PRs / Issues / Repos / Docs Mentioned This Week)

- Memelord plugin: https://github.com/NewSoulOnTheBlock/plugin-memelord  
- Docs PR (pending merge mention): https://github.com/elizaos/elizaos.github.io/pull/243  
- AIProx registry endpoints discussed (from Discord):
  - `POST /api/agents/register`
  - `GET /api/agents` (query/filter for capability, rating, payment rail)