# ElizaOS Developer Update (2026-03-23 → 2026-03-29)

This update aggregates **developer Discord** activity from 2026-03-26 through 2026-03-28 plus referenced GitHub items. **No additional core-repo PR/issue activity was included in the provided dataset for this week**, so items below focus on ecosystem/plugin work and integration patterns surfaced in community discussions.

---

## 1) Core Framework

### Runtime / deployment topology: “single Spartan” staging consolidation (planned)
Core maintainers discussed collapsing **production + development into a single staging environment** to simplify operations: “one Spartan to manage with all customer data” (Discord, 2026-03-26). This is an operational architecture change that affects how developers should think about:

- **Environment separation**: fewer environment-specific behaviors; staging becomes the primary integration surface.
- **Data boundaries**: stricter multi-tenant isolation expectations if staging becomes the unified environment.
- **Release flow**: expect more emphasis on feature flags and progressive rollout (even if not yet codified in PRs this week).

No PR link was provided in the dataset; treat as **upcoming** work.

---

## 2) New Features

### A) TaskBounty: autonomous task execution + crypto payouts via REST (USDC/ETH/SOL)
TaskBounty shipped an integration surface that enables Eliza agents to:
- Browse open tasks
- Submit work
- Receive crypto payouts **directly to the agent wallet**
- Post tasks (enabling **agent-to-agent delegation** / “agent economy” loops)

**Docs / specs**
- OpenAPI 3.1: https://task-bounty.com/api/v1/openapi.json  
- Agent docs: https://task-bounty.com/for-agents

**Integration pattern (Eliza plugin-side outline)**
1) Pull the OpenAPI spec to generate a typed client (recommended).
2) Implement an ElizaOS plugin toolset:
   - `taskbounty.listTasks`
   - `taskbounty.claimTask`
   - `taskbounty.submitWork`
   - `taskbounty.getPayoutStatus`
   - `taskbounty.createTask` (for delegation)

Example: minimal fetch-based client (replace endpoints/fields with those defined in the OpenAPI spec):

```ts
// taskbountyClient.ts
const TASKBOUNTY_BASE = "https://task-bounty.com/api/v1";

export async function listTasks(apiKey: string) {
  const res = await fetch(`${TASKBOUNTY_BASE}/tasks?status=open`, {
    headers: { Authorization: `Bearer ${apiKey}` },
  });
  if (!res.ok) throw new Error(`TaskBounty listTasks failed: ${res.status}`);
  return res.json();
}

export async function submitWork(apiKey: string, taskId: string, payload: unknown) {
  const res = await fetch(`${TASKBOUNTY_BASE}/tasks/${taskId}/submissions`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(payload),
  });
  if (!res.ok) throw new Error(`TaskBounty submitWork failed: ${res.status}`);
  return res.json();
}
```

**Bounty Scout referral mechanic (agent-native growth loop)**
TaskBounty introduced **Bounty Scout**:
- Agents earn **$20 credits** when referred clients post funded tasks
- Referred users receive **$60 signup credits** (vs standard $50)

This is best modeled as a plugin tool that can:
- Generate a referral code/link
- Attribute funded task creation events
- Query credit balances (if exposed in API)

(Discord, 2026-03-28)

---

### B) Orbis: “self-subscribe to APIs” without browser/OAuth (3-fetch flow)
Orbis was shared as an agent-friendly API onboarding layer:
- Agents can obtain API keys via **three fetch calls**: **browse → register → subscribe**
- Provides access to **65+ APIs** (text/data/encoding/finance/validators), often with free tiers
- Includes an MCP server option for Claude-based agents
- Agent discovery flow endpoint: https://orbisapi.com/api/agents/discovery

**Typical agent onboarding flow**
```ts
// orbisFlow.ts (conceptual; confirm exact request/response shapes in Orbis docs)
const ORBIS_BASE = "https://orbisapi.com/api";

export async function browseCatalog() {
  return fetch(`${ORBIS_BASE}/agents/discovery`).then(r => r.json());
}

export async function registerAgent(agentProfile: unknown) {
  const res = await fetch(`${ORBIS_BASE}/agents/register`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(agentProfile),
  });
  return res.json(); // expect agentId / token depending on API
}

export async function subscribeToApi(agentToken: string, apiSlug: string) {
  const res = await fetch(`${ORBIS_BASE}/agents/subscribe`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${agentToken}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ api: apiSlug }),
  });
  return res.json(); // expect apiKey credentials
}
```

**Why this matters for ElizaOS developers**
- Reduces friction for tool acquisition inside agents (no interactive OAuth).
- Encourages dynamic tool provisioning patterns (agent discovers + subscribes at runtime).

(Discord, 2026-03-28)

---

### C) xProof.app plugin: on-chain decision provenance (MultiversX anchoring)
A new plugin was announced to anchor agent decisions on-chain **before execution**, providing immutable timestamps and verifiable provenance via MultiversX.

**Install**
```bash
npm install @elizaos/plugin-xproof @xproof/xproof
```

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

**Operational concept**
- Before executing a high-impact action (trade, payment, governance post), the agent:
  1) hashes/serializes the decision record
  2) requests an on-chain anchor
  3) proceeds only after receiving an anchor/timestamp proof

No code sample was provided in the dataset; consult the package README once merged.

(Discord, 2026-03-26)

---

### D) Trading flow plugin (community WIP): plug-and-play trading integration
A developer (meowww404) is building a **trading flow plugin** intended to integrate with trading infrastructure “plug-and-play”. Maintainers requested the **registry PR or plugin name** for evaluation.

No PR link was provided in the dataset.
(Discord, 2026-03-27)

---

## 3) Bug Fixes

**No critical bug-fix PRs were included in the provided GitHub dataset for 2026-03-23 → 2026-03-29.**

However, one recurring operational issue surfaced in community support:

### AI16Z → ElizaOS migration support gap (user-impacting)
Multiple users asked for help after **missing the migration window** (Discord 2026-03-26, 2026-03-28). While this isn’t a code bug, it is a **system-level reliability issue** (onboarding + account state recovery). Recommended engineering actions:

- Publish a deterministic migration-state checker (address/token eligibility → status).
- Add a self-serve “missed migration” workflow (even if it ends in “cannot recover”).
- Centralize this in docs + CLI output to reduce repeated support load.

No resolution was recorded in the dataset this week.

---

## 4) API Changes

### TaskBounty (external): OpenAPI 3.1 available for client generation
The key “API change” this week is external but developer-relevant: TaskBounty now provides a formal **OpenAPI 3.1 spec** for automated integration:
- https://task-bounty.com/api/v1/openapi.json

Recommended developer workflow:

```bash
# example: generate a TS client (choose your generator)
npx openapi-typescript https://task-bounty.com/api/v1/openapi.json -o taskbounty.d.ts
```

No ElizaOS core API signature changes were provided in this week’s dataset.

---

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

No new merges or specific plugin changes for Twitter/Telegram/Discord/Farcaster were provided in the dataset for this week.

Notes:
- A trading-oriented plugin discussion may later intersect with “social trading” or posting hooks, but nothing concrete landed this week.

---

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

No model provider integration updates, new model IDs, or breaking provider changes were included in the dataset for this week.

---

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

### No new V1→V2 breaking changes reported in this week’s provided data
There were **no documented** runtime/plugin API breaking changes or migration notices between framework versions included in the dataset.

### Important adjacent migration risk: AI16Z → ElizaOS
While not “V1→V2”, this continues to produce developer/support friction. If your app’s onboarding references AI16Z-era assets or flows:
- Add explicit migration-status checks and user messaging.
- Ensure wallet/address-based eligibility is validated early to avoid “silent failure” onboarding.

---

## Links & References

- TaskBounty OpenAPI 3.1: https://task-bounty.com/api/v1/openapi.json  
- TaskBounty agent docs: https://task-bounty.com/for-agents  
- Orbis agent discovery: https://orbisapi.com/api/agents/discovery  
- xProof registry PR: https://github.com/elizaos-plugins/registry/pull/266  
- Discord threads (source):
  - 2026-03-26 / 2026-03-27 / 2026-03-28 (elizaOS Discord summaries provided in dataset)