# ElizaOS Developer Update (2026-02-17 → 2026-02-23)

## 1) Core Framework

### V2 migration strategy tightening: removing legacy auto-migrations
Work this week continued to harden the **v2.0.0** upgrade path by deleting legacy migration logic that attempted to auto-upgrade older schemas.

- **PR:** “Align RLS isolation with v1 patterns” (also removes ~2,600 LOC of legacy migration code) — https://github.com/elizaos/eliza/pull/6521  
- Rationale discussed in `#core-devs`: the team is assuming production users have already moved past **v1.4.x**; direct “v1.4.x → v2.0.0” auto-migration is no longer supported. A follow-up idea is to **fail fast with a targeted error** instructing users to migrate to **v1.6.x** first.

**Developer impact:** if you maintain forks/installs that may still be on v1.4.x-era databases, you should plan an explicit **intermediate migration to v1.6.x** before v2.

### Runtime wrapping / HTTP server pattern (reference implementation)
In Discord discussion, the team confirmed a lightweight HTTP server wrapper around the runtime is **not newly added by core this week**, but exists with multiple examples in the **Milady v2.0.0** codepath (useful as a reference if you want an embedded control-plane around the runtime).

## 2) New Features

### Safer SQL isolation context + RLS alignment (plugin-sql)
The biggest practical change for developers is the **RLS/isolation context plumbing** in `plugin-sql`, aligned back to established v1 patterns and hardened against SQL injection.

Highlights from **PR #6521** (plugin-sql):
- Replaces `application_name`-based server context with **parameterized `set_config(...)`** calls.
- Renames `withEntityContext` → **`withIsolationContext`** (see API changes below).
- Keeps Row Level Security (RLS) isolation semantics intact while making the mechanism safer.

**Example: using the new isolation wrapper (TypeScript)**
```ts
import { createSqlPlugin } from "@elizaos/plugin-sql";

const sql = createSqlPlugin(/* ... */);

// Previously: sql.withEntityContext(...)
await sql.withIsolationContext(
  { entityId: "ent_123", userId: "usr_456" },
  async (db) => {
    // All queries in here run under the configured isolation context
    const rows = await db.query("select * from memories where entity_id = $1", ["ent_123"]);
    return rows;
  }
);
```

**Example: the safer DB-side context approach (conceptual)**
```sql
-- Instead of relying on application_name string parsing:
select set_config('eliza.entity_id', $1, true);
select set_config('eliza.user_id',   $2, true);
```

This approach is both **more explicit** and **less prone to injection** than embedding context into connection metadata.

### Base wallet safety guide (x402 diagnostics)
A new developer-facing safety doc was added for Base Network wallet flows, including **x402 diagnostic** guidance.

- **PR:** https://github.com/elizaos/eliza/pull/6523

This is particularly relevant as more plugins start incorporating payment/trust rails (x402 shows up frequently when debugging “wallet safety” and transaction gating UX).

### Ecosystem: SolCex autonomous BD agent plugin (v2)
A new third-party plugin shipped for v2.0.0 that implements an autonomous business development agent for exchange listings.

- **npm:** `@buzzbd/plugin-solcex-bd` (v2.0.0)
- **Registry PR:** https://github.com/elizaos-plugins/registry/pull/263  
- Integrates **8 services**, a **100-point token scoring** system, and aggregates from **16 intelligence sources** (per developer announcement in Discord).

**Developer note:** if you’re building “agent commerce” / “dealflow” style systems, this plugin is a concrete reference for composing multiple external intel providers into a single scored recommendation pipeline.

## 3) Bug Fixes (with technical context)

### SQL injection hardening in isolation context
While framed as refactoring, the shift to **parameterized `set_config`** is effectively a security bug fix:
- Prior approach used connection metadata (`application_name`) as a transport for context.
- New approach uses DB parameters, reducing risk that untrusted strings can pollute isolation state.

- **PR:** https://github.com/elizaos/eliza/pull/6521

### Dependency maintenance (risk reduction)
Two dependency bump PRs landed in the v2 surface area (reducing supply-chain and runtime breakage risk across Rust + TS tooling):

- **PR:** npm/yarn group bumps — https://github.com/elizaos/eliza/pull/6478  
- **PR:** cargo group bumps — https://github.com/elizaos/eliza/pull/6479  

## 4) API Changes (developer-facing)

### `withEntityContext` renamed to `withIsolationContext` (plugin-sql)
If you were calling the old helper, you must update imports/usages:

```diff
- await sql.withEntityContext(ctx, fn)
+ await sql.withIsolationContext(ctx, fn)
```

- **PR:** https://github.com/elizaos/eliza/pull/6521

### Isolation context no longer uses `application_name`
If you were relying on connection-level introspection (e.g., debugging context via `SHOW application_name;`), that mechanism may no longer reflect entity/user isolation state. Prefer logging the explicit isolation inputs at the boundary where you call `withIsolationContext`.

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

No core social-plugin merges were recorded in the provided GitHub activity for this specific week, but a few integration-adjacent notes surfaced:

- Team communications are split: **AI/dev updates on Twitter (X)** and **crypto updates on Farcaster** (Discord note from Odilitime). If you ship agents that react to announcements, you may need to ingest both feeds.
- X account recovery was noted as unblocking partner/creator collaboration (ecosystem-facing).

If you’re actively developing social integrations, also track the open issues around MCP enhancements:
- Twitter MCP enhancements (issue) — https://github.com/elizaos/eliza/issues/6516  
- Google MCP enhancements (issue) — https://github.com/elizaos/eliza/issues/6517  

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

### Performance pressure: 200k token contexts from plugin-heavy agents
Core-dev discussion highlighted repeated hits to **~200k token limits** when many plugins/providers/evaluators are enabled, with **bootstrap providers + evaluations** identified as major contributors. Work is ongoing to reduce baseline prompt bloat.

Practical guidance until optimizations fully land:
- Minimize enabled providers/evaluators for production agents.
- Prefer relevance filtering (where available) to avoid “dump all tools into prompt” patterns.

Related architectural direction (already in-flight in v2): action/tool filtering to reduce prompt size:
- **PR (Action filtering via vector search + BM25):** https://github.com/elizaos/eliza/pull/6475

### OpenAI-compatible endpoint configurability (requested)
A developer request remains open to support **custom OpenAI base URLs** (for OpenAI-compatible providers like SiliconFlow):

- **Issue:** https://github.com/elizaos/eliza/issues/6490

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

### 1) Database upgrade path: do not jump from v1.4.x directly to v2
Auto-migration code (v1.4.x → v1.6.x) has been removed as part of the v2 refactor work.

- **PR:** https://github.com/elizaos/eliza/pull/6521  
- **Expected behavior going forward:** installs attempting **v1.4.x → v2.0.0** may need to:
  1. Upgrade to **v1.6.x**
  2. Run migrations / validate schema
  3. Then upgrade to **v2.0.0**

### 2) `plugin-sql` helper rename
`withEntityContext` → `withIsolationContext` (compile-time break for TypeScript users).

### 3) V2 branch is the recommended direction (docs still catching up)
Discord guidance this week reiterated: **v2.0.0 branch is recommended**, but has less documentation than older versions. Track ongoing docs work and be prepared to reference examples (including Milady’s v2 implementations) for patterns not yet fully documented.

**Reference docs (core concepts / architecture):**
- https://github.com/elizaos/eliza/pull/6356