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

This week’s signal is primarily from developer Discord discussions (limited GitHub telemetry available in the provided dataset). Key themes: **v2 runtime maturity/branch selection**, **plugin breakage in 1.7.2**, **autonomy/cron patterns**, and early work on **prediction-market integrations**.

Relevant threads:
- Discord (general): https://discord.com/channels/1253563208833433701/1253563209462448241  
- Discord (coders): https://discord.com/channels/1253563208833433701/1300025221834739744  

---

## 1) Core Framework

### v2 maturity and “which branch should I build on?”
Developers flagged confusion around **ElizaOS v2.0.0 (alpha)** vs a more stable line of development on **`v2-develop`**. The emerging guidance from maintainers/community is:

- **`v2.0.0` is alpha** and is experiencing frequent breaking changes (including runtime-level differences and dependency issues).
- **`v2-develop` is currently the recommended baseline** if you want “more mature 1.x-compatible” behavior while still tracking forward progress.

Context (Discord, 2026-02-27/28): reports that multiple plugins are **broken out-of-the-box on 1.7.2**, and that v2.0.0 is in active rollout.

### “Plugins creeping back into core”
Concern was raised that plugins may be re-entering the core codebase via **PR #6531** (mentioned in Discord). If you maintain downstream forks or internal platform distributions, keep an eye on core/plugin boundaries and build size/regression risks:

- PR reference (as cited): https://github.com/elizaos/eliza/pull/6531

> Note: The dataset did not include the PR diff/details, so treat this as a watch-item rather than a confirmed architectural change.

---

## 2) New Features

### Prediction markets: Polymarket plugin integration (Milady custom v2)
A custom **ElizaOS v2.0 integration with the Milady project** is in progress, featuring **Polymarket plugin integration** (developer “ElizaBAO” offered to share a working version privately).

What this likely means for developers building agents around prediction markets:
- A new plugin surface for **market discovery**, **order placement**, **position tracking**, and **settlement/resolve workflows**
- Tighter coupling to **oracle / verification** narratives (also referenced in discussion as “Prediction Market L2” and “Verifiable Oracle Thesis”)

No public repo/PR link was provided in the dataset; treat as **in-development**.

#### Suggested plugin shape (example)
If you’re implementing your own prediction-market plugin, keep the contract minimal and composable: “tools” for read/write + optional guards for risk/HITL.

```ts
// Example-only: illustrative tool interfaces for a Polymarket-like plugin
export interface MarketInfo {
  id: string;
  question: string;
  outcomes: string[];
  volumeUsd?: number;
  closesAt?: string;
}

export interface CreateOrderInput {
  marketId: string;
  outcome: string;
  side: "buy" | "sell";
  size: number;
  limitPrice?: number;
}

export interface PredictionMarketTools {
  listMarkets(query?: string): Promise<MarketInfo[]>;
  getMarket(id: string): Promise<MarketInfo>;
  createOrder(input: CreateOrderInput): Promise<{ orderId: string; status: string }>;
  getPositions(): Promise<Array<{ marketId: string; outcome: string; size: number }>>;
}
```

**Implementation note:** For safety, route `createOrder` through a **human-in-the-loop confirmation** step (see “Bug Fixes / Safety” and “Breaking Changes” sections for why this is becoming table-stakes in v2-era deployments).

---

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

### Broken plugins on ElizaOS 1.7.2 (field reports)
Developers reported that several commonly used plugins are **broken out-of-the-box on 1.7.2**, requiring manual patching:
- `plugin-linear`
- `plugin-rolodex`
- `plugin-memory`

While no specific patch PRs were included in the dataset, the recurring root causes in fast-moving agent stacks are typically:
- runtime interface drift (tool/skill registration signatures)
- config schema changes
- dependency mismatches (ESM/CJS boundaries, node version constraints, transitive updates)

**Action for maintainers:** publish a compatibility matrix (runtime version → known-good plugin versions) and pin/lockfile guidance.

**Action for developers:** if you need stability this week, prefer `v2-develop` guidance from core contributors over 1.7.2 (per Discord consensus).

### v2.0.0 bcrypt issue (known problem, patch required)
A bcrypt-related issue in **v2.0.0** was mentioned as requiring patches. Without the PR/issue details, treat it as:

- If your deployment uses bcrypt for credential hashing, token signing adjuncts, or encrypted storage bootstrapping, validate:
  - native module builds in your target OS/container
  - node ABI compatibility
  - fallbacks (e.g., `bcryptjs`) where appropriate

**Mitigation checklist (generic):**
```bash
node -v
npm ls bcrypt
# If native builds fail in CI:
# - ensure build-essential/python are present
# - consider replacing with bcryptjs temporarily for non-production auth paths
```

---

## 4) API Changes

No concrete API diffs were included in the provided GitHub dataset for this week. However, developers should expect **practical API instability** across the following surfaces based on discussion:

- agent runtime autonomy hooks (v2 built-in vs plugin-provided)
- tasks/cron-style scheduling APIs (1.x tasks system vs newer autonomy systems)
- plugin lifecycle and tool registration signatures across runtime versions

If you publish plugins, assume **minor runtime updates can break you** unless you pin versions.

---

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

### Cross-platform posting automation (in progress)
Work was mentioned toward automating bot/agent posting across **Discord / X (Twitter) / Telegram** (no PR link provided).

If you are building this internally, a robust approach is to isolate each network behind an “outbox” queue so your agent runtime never blocks on rate limits:

```ts
// Example-only: push to an outbox and let per-network workers deliver
await outbox.enqueue({
  channel: "twitter",
  payload: { text, mediaUrls },
  idempotencyKey: `${agentId}:${sha256(text)}`,
});
```

### Discord security: scam bot pressure affecting onboarding
Ongoing scam bot targeting of new Discord users is materially impacting developer onboarding (support impersonation, fake “ticket links”, DMs). While not a code change, it *does* affect your integration/support posture:

- Do not distribute secrets, install scripts, or wallet instructions via DMs
- Prefer signed release artifacts and pinned official docs
- Consider adding “first-message” friction and auto-moderation rules in community servers

---

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

No model provider integration changes were present in the provided dataset for this week.

(Last known provider-facing change in the dataset is older: “Opus 4.5 support” mentioned in the Feb 15–21 weekly summary, not this week.)

---

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

### v2.0.0 is alpha: expect breakage, especially across plugins
Developers repeatedly flagged that:
- there are “many different versions of the runtime”
- “almost every release contains a breaking change”
- multiple plugin sets do not run cleanly on older 1.x versions (e.g., 1.7.2)

**Migration guidance (pragmatic):**
1. If you need near-term stability, align on **`v2-develop`** rather than v2.0.0 alpha (per community guidance).
2. Pin *everything*:
   - core runtime revision
   - plugin versions
   - node version
3. Introduce a compatibility gate in CI that boots an agent with your plugin set and executes a smoke test.

```bash
# Example-only CI smoke test idea
npm ci
npm run build
npm run agent:smoke -- --profile ci --timeout 60000
```

### Autonomy/cron behavior differs across versions and implementations
Three autonomy paths were identified in discussion:
- `plugin-autonomous` (periodic “thinking” / looped execution)
- v2.0.0 built-in autonomy system (“Shaw’s autonomous system”)
- Milady’s more comprehensive autonomy approach (OpenClaw-like)

**Breaking-change risk:** if you previously relied on 1.x “tasks” behaving like cron, you may need to re-implement scheduling explicitly or standardize on one autonomy layer per deployment.

#### Safer cron-like polling pattern (example)
For enterprise workflows (Linear/GitHub/Meet minutes), a safe pattern is **poll + propose + confirm**:

```ts
// Example-only: hourly poll that only drafts actions, never executes silently
scheduler.every("60m", async () => {
  const blocked = await linear.listBlockedIssues({ updatedWithinHours: 24 });

  const proposals = await agent.reason({
    prompt: `Suggest next actions for these blocked issues:\n${JSON.stringify(blocked)}`,
  });

  await humanInbox.sendForApproval({
    title: "Blocked issue triage proposals",
    body: proposals,
  });
});
```

---

## Links & References Mentioned This Week
- Core PR watch-item: https://github.com/elizaos/eliza/pull/6531  
- Community project: zeitgaist (VPS orchestration): https://github.com/NewSoulOnTheBlock/zeitgaist  
- Conway.tech integration plugin: https://github.com/NewSoulOnTheBlock/plugin-conway  

---