# ElizaOS Developer Update (2026-03-11 → 2026-03-17)

This week focused on **ElizaOS v2.0.0 runtime architecture decisions**, **EVM/onchain data plugin improvements**, and several **ecosystem integration proposals** (human-in-the-loop task markets, DeFi transaction guardrails, on-chain identity signaling).

---

## 1) Core Framework

### v2.0.0 runtime refactor: skills folder structure
A v2.0.0 pull request introduces a **first-class `skills/` folder structure** in the core runtime, kicking off a broader redesign of how reusable agent capabilities are packaged and distributed.

- PR: **Skills folder structure** — https://github.com/elizaos/eliza/pull/6597  
- Discussion context (Discord, `#xfn-framework`): https://discord.com/channels/1253563208833433701/1377726087789940836

#### Architectural motivation
The team is explicitly trying to avoid a repeat of the 0.x era “default plugin/skill bloat” problem (uncontrolled submissions into a de facto “official” bundle). The proposed direction is:

- **Ship v2.0.0 with *zero* default skills**
- Encourage **decentralized skill discovery** via `https://<your-domain>/skills.md`
- Keep core runtime lean while enabling community distribution without central curation bottlenecks

**Open decision:** whether this “0 default skills + decentralized discovery” model becomes the official v2.0.0 posture (community feedback requested).

---

## 2) New Features

### A) Decentralized skill discovery via `skills.md` (proposed distribution model)
While the runtime change is landing via PR #6597, the **distribution/discovery** model is being discussed in parallel: each publisher hosts a `skills.md` that tools/registries/crawlers can index.

Community prototypes already exist (external to core):
- `https://lightningprox.com/skills.md`
- `https://solanaprox.com/skills.md`  
(Shared in Discord discussions; intended as an existence proof for the approach.)

#### Suggested `skills.md` layout (example)
No canonical schema has been finalized yet; below is a **practical, machine-parseable pattern** that works well for discovery tooling (and aligns with the “domain-owned listing” idea):

```md
# ElizaOS Skills

- name: evm-onchain-data
  description: EVM onchain data lookups via Goldrush
  source: https://github.com/<org>/<repo>
  version: 0.1.0
  entrypoint: skills/evm-onchain-data/index.ts
  license: MIT
  tags: [evm, onchain, data]
  checksum: sha256:<artifact-or-repo-tree-hash>
```

**Implementation guidance (recommended):**
- Treat `skills.md` as **an index**, not the payload.
- Fetch skill source from `source`, then verify integrity via `checksum`.
- Prefer signed manifests over time (future hardening), especially if skills can execute code inside agent runtimes.

---

### B) plugin-evm: expanded onchain data support (Goldrush)
Community work is underway to integrate **100+ onchain data endpoints** via **goldrush.dev** into the EVM plugin and to resolve existing `plugin-evm` issues.

- Mentioned by: `dinesh`
- Discord threads:  
  - `#discussion`: https://discord.com/channels/1253563208833433701/1253563209462448241  
  - `#coders`: https://discord.com/channels/1253563208833433701/1300025221834739744

Because PR/issue IDs weren’t shared in the captured log, treat this as **active development work** pending upstream references.

#### Expected developer impact
Once merged, developers should be able to build agents that can query a much broader set of EVM chain data (transactions, tokens, contracts, balances, potentially decoded events) with fewer bespoke RPC/indexer integrations.

---

### C) Human-in-the-loop tasks: Effect AI integration proposal
Effect AI proposed an integration where ElizaOS agents can **post tasks to a decentralized human worker marketplace** when the agent “hits a wall” (e.g., data labeling, image annotation, content review, translation).

- Discussion: https://discord.com/channels/1253563208833433701/1300025221834739744

This is not merged functionality yet, but it has clear architectural implications for v2:
- Tooling needs **async job lifecycles** (create task → wait/poll/subscribe → retrieve result)
- Agents need a **budgeting + approvals** story (especially if payment is on-chain)

**API sketch (non-final; for discussion):**
```ts
// PSEUDOCODE: illustrative interface only (not yet in core)
const task = await runtime.tools.effectAI.createTask({
  type: "content_review",
  payload: { text, policy: "no-personal-data" },
  maxCost: "5.00",
  currency: "USDC",
  deadlineSeconds: 3600,
});

const result = await runtime.tools.effectAI.awaitResult(task.id, { timeoutMs: 55_000 });
if (result.status === "completed") {
  // consume verified human output
  memory.store("review", result.output);
}
```

---

### D) DeFi safety layer: x402Guard plugin (announced)
A security proxy called **x402Guard** was presented as an upcoming open-source plugin to protect autonomous DeFi agents from:
- prompt-injection-driven transfers
- unauthorized contract interactions
- overspending

Key technical traits shared:
- **per-step evaluation** (not whole-strategy simulation)
- **layered limits**: permanent guardrails + temporary session keys
- **immutable audit logs**
- mentions **EIP-7702 session keys**
- networks mentioned: **Base + Solana**
- implementation language: **Rust**

Discussion:
- 2026-03-14 thread: https://discord.com/channels/1253563208833433701/1253563209462448241 (captured summary references; see daily logs)

---

## 3) Bug Fixes

### plugin-evm: resolving open issues (in progress / partial fixes)
Work is reported to be addressing existing `plugin-evm` issues alongside the Goldrush expansion. While specifics (stack traces, failing endpoints, regression tests) weren’t included in the weekly logs, the reported focus implies fixes in areas typically associated with EVM data plugins:

- provider/indexer response normalization
- pagination/rate-limits/timeouts
- chain ID / network config mismatches
- ABI decoding edge cases

**Action needed for maintainers:** please link the concrete PR(s)/issue(s) when available so downstream developers can pin versions and understand behavioral changes.

---

## 4) API Changes

### v2 runtime: introduction of a `skills/` loading surface (PR #6597)
PR #6597 effectively introduces a new **packaging boundary**: “skills” become a first-class artifact (separate from the legacy plugin sprawl patterns).

- PR: https://github.com/elizaos/eliza/pull/6597

**What developers should anticipate:**
- A conventional filesystem location (e.g., `./skills`) that the runtime can load/resolve at startup
- A likely shift toward **explicit skill enablement** (rather than implicit “bundled defaults”)
- Discovery moving out-of-tree (domain-hosted listings)

Because the final API contracts aren’t in this data dump, treat the following as **migration planning guidance** rather than guaranteed signatures:

```bash
# Expected developer workflow (conceptual)
# 1) Place skill packages under ./skills
# 2) Configure your agent/runtime to load specific skills
# 3) (Optional) publish a skills.md on your domain for discovery
```

---

## 5) Social Media Integrations

### Memelord plugin (ecosystem): meme generation + live X/Twitter demo
A community plugin integrating **Memelord.com** was released, with a demo agent running on X/Twitter (“Memelordicus”).

This is an ecosystem expansion rather than a core merge this week, but it signals continued investment in:
- content generation pipelines
- social posting workflows
- “agent as a brand” automation

(Repository link wasn’t included in the captured logs; if you maintain the plugin, consider submitting it to the official registry/discovery flow once v2 skill distribution patterns settle.)

---

## 6) Model Provider Updates

No model provider integration changes (OpenAI/Anthropic/DeepSeek/etc.) were surfaced in the provided GitHub/Discord activity for this week.

If you’re tracking provider churn, this was a relatively quiet week on that axis compared to the architecture + plugin discussions above.

---

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

### v2.0.0 “zero default skills” direction may break implicit behavior
If v2 ships with **no bundled/default skills**, any v1 projects relying on “it works out of the box” behaviors (demo agents, starter templates that assume certain built-ins) will need explicit configuration.

**What to do now:**
- Audit your agents for assumptions like “skill X exists by default”
- Plan to vendor/pin required skills in-repo or via a trusted `skills.md` publisher
- Prepare an internal skill allowlist (security) instead of enabling arbitrary community skills

### Decentralized discovery increases supply-chain responsibility
Moving discovery to `https://<domain>/skills.md` is architecturally clean, but it shifts risk to developers/operators:
- you must decide which domains are trusted
- you should validate checksums/signatures
- you should sandbox or permission skills (capabilities, network, wallet access)

---

## References / Threads (for follow-up)

- PR #6597 (skills folder / v2 runtime refactor): https://github.com/elizaos/eliza/pull/6597  
- Discord `#xfn-framework` (skills architecture): https://discord.com/channels/1253563208833433701/1377726087789940836  
- Discord `#coders` (Goldrush/plugin-evm; Effect AI proposal): https://discord.com/channels/1253563208833433701/1300025221834739744  
- Discord `#discussion` (plugin updates; token migration concerns; Z1N protocol): https://discord.com/channels/1253563208833433701/1253563209462448241  

---