# Issue Triage — 2026-03-17

## 1) Token migration transparency gap (ai16z → elizaOS) — *Tracking issue needed (no GitHub ID yet)*
**Current Status:** Reported on Discord; no official response captured; not yet tracked in GitHub.  
**Impact Assessment:**
- **User Impact:** **Critical** (potentially ~100k addresses affected; confusion impacts a large portion of token holders/community)
- **Functional Impact:** **No** (doesn’t block framework runtime, but blocks ecosystem trust/participation)
- **Brand Impact:** **High** (perceived opacity around supply/distribution is reputationally damaging)
**Technical Classification:**
- **Category:** Documentation / Governance (Project Ops)
- **Component Affected:** Tokenomics / Communications
- **Complexity:** **Moderate effort** (data gathering + clear comms + publishing verifiable details)
**Resource Requirements:**
- **Required Expertise:** On-chain analytics, treasury ops, communications (clear, auditable reporting)
- **Dependencies:** Access to official migration contracts, treasury addresses, and any custodial/escrow wallets
- **Estimated Effort:** **3/5**
**Recommended Priority:** **P0**
**Specific Actionable Next Steps:**
1. Create a public GitHub issue in the main repo (or governance repo) titled “Publish ai16z→elizaOS migration status + post-migration supply breakdown”.
2. Publish **official addresses** (migration contract, treasury, any multisigs) and **methodology** for calculating migrated vs. unmigrated supply.
3. Provide a **current snapshot**: % migrated, remaining eligible supply, and timeline/cutoffs (if any).
4. State policy for **unmigrated allocation** (burn, reclaim to treasury, extend window, redistribute, etc.) with rationale and dates.
5. Post a pinned Discord + website note linking to the canonical report (avoid fragmented answers).
**Potential Assignees:** Odilitime (project lead comms), core treasury/ops signer(s) (not named in dataset), community analyst volunteers to reproduce numbers (e.g., otse finam as reporter, Cryptologos as prior asker).

---

## 2) v2.0.0 Skills architecture decision: prevent “uncontrolled skill submissions” + ship with zero default skills — PR **#6597** (elizaos/eliza)
**Current Status:** PR opened; architectural question unresolved; community feedback requested.  
**Impact Assessment:**
- **User Impact:** **High** (affects all v2 adopters; determines discovery/onboarding experience)
- **Functional Impact:** **Partial** (core can ship, but skill distribution/discovery impacts real usability)
- **Brand Impact:** **High** (quality/perception of v2 ecosystem hinges on clean, safe distribution model)
**Technical Classification:**
- **Category:** Architecture / UX / Governance
- **Component Affected:** Core Framework (skills loading), Plugin/Skill ecosystem
- **Complexity:** **Architectural change**
**Resource Requirements:**
- **Required Expertise:** Core runtime architecture, package/distribution design, security review (supply-chain risk)
- **Dependencies:** Decision on skills discovery standard (skills.md), validation/signing model (if any), registry strategy
- **Estimated Effort:** **4/5**
**Recommended Priority:** **P1**
**Specific Actionable Next Steps:**
1. In PR #6597 discussion, document the decision options:
   - A) ship with **0 skills** + external discovery
   - B) ship with curated “core skills” set
   - C) hybrid with strict curation + opt-in community feeds
2. Define an MVP **skills.md spec** (fields, versioning, compatibility, integrity metadata like checksums/signatures).
3. Decide whether elizaOS will provide:
   - an **official aggregator index** (read-only) vs.
   - purely decentralized user-provided lists.
4. Add guardrails: allowlist/denylist capability, provenance display, and safe install prompts.
5. Merge PR once acceptance criteria + migration notes are added (what changes for v1/v0 users).
**Potential Assignees:** Odilitime (author), maintainers familiar with plugin pain points (registry maintainers), lightningprox (already implemented skills.md pattern externally; can provide feedback from real deployment).

---

## 3) plugin-evm: “100+ onchain data support” via goldrush.dev + fix open issues — *Tracking issues needed (no GitHub IDs provided)*
**Current Status:** In progress per Discord; unspecified open issues; integration underway.  
**Impact Assessment:**
- **User Impact:** **Medium–High** (EVM builders benefit; scope suggests broad utility for Web3 agents)
- **Functional Impact:** **Partial** (not core runtime-blocking, but blocks key plugin capability)
- **Brand Impact:** **Medium** (plugin reliability influences ecosystem credibility)
**Technical Classification:**
- **Category:** Feature + Bug
- **Component Affected:** Plugin System (plugin-evm), Data integrations
- **Complexity:** **Moderate effort**
**Resource Requirements:**
- **Required Expertise:** TypeScript/Node, EVM data indexing, API integration, plugin packaging/testing
- **Dependencies:** goldrush.dev API stability/keys, CI tests, plugin release pipeline
- **Estimated Effort:** **3/5**
**Recommended Priority:** **P1**
**Specific Actionable Next Steps:**
1. Open a GitHub epic issue in plugin-evm repo: “Goldrush integration + 100+ datasets support” with checklist.
2. Enumerate “open issues” being fixed and link/close them via commits.
3. Add integration tests (mock responses) + rate-limit/backoff handling.
4. Publish minimal docs: supported chains/data types, configuration, examples.
5. Cut a versioned release and announce upgrade notes.
**Potential Assignees:** dinesh (implementer), plugin-evm maintainers/reviewers, CI/test contributor from community.

---

## 4) Skills discovery standardization: skills.md format + hosting guidelines — *Docs task (no GitHub ID yet)*
**Current Status:** Proposed; at least one community implementation exists (lightningprox.com / solanaprox.com).  
**Impact Assessment:**
- **User Impact:** **High** (directly affects discoverability and safety of skills in v2 model)
- **Functional Impact:** **Partial** (without docs/spec, fragmentation and incompatibility likely)
- **Brand Impact:** **Medium–High** (poor discoverability feels “unfinished”)
**Technical Classification:**
- **Category:** Documentation + UX
- **Component Affected:** Ecosystem / Distribution
- **Complexity:** **Moderate effort**
**Resource Requirements:**
- **Required Expertise:** Technical writing, schema design, security considerations (supply chain)
- **Dependencies:** Outcome of PR #6597 decision
- **Estimated Effort:** **2/5**
**Recommended Priority:** **P1**
**Specific Actionable Next Steps:**
1. Publish a versioned JSON schema (or frontmatter spec) for skills.md entries.
2. Provide examples: single-skill file, multi-skill index, compatibility fields.
3. Add guidance on hosting (CORS, content-type, caching) and integrity (hashes, signatures).
4. Document recommended UI/CLI display: provenance, publisher, warnings.
**Potential Assignees:** Odilitime (owner), lightningprox (field experience), docs contributors.

---

## 5) Human-in-the-loop integration proposal (Effect AI marketplace API) — *Feature exploration (no GitHub ID yet)*
**Current Status:** Proposal on Discord; community feedback unanswered; API in development by Effect AI.  
**Impact Assessment:**
- **User Impact:** **Medium** (valuable for production/enterprise agents; not every builder needs it)
- **Functional Impact:** **No** (optional capability)
- **Brand Impact:** **Medium** (adds “production readiness” credibility if executed well)
**Technical Classification:**
- **Category:** Feature Request
- **Component Affected:** Plugin System / Agent Task Orchestration
- **Complexity:** **Complex solution** (task lifecycle, payments, verification, safety, UX)
**Resource Requirements:**
- **Required Expertise:** API/plugin development, job orchestration, security, payments/on-chain settlement understanding
- **Dependencies:** Effect AI API readiness, authentication/payment model, moderation policies
- **Estimated Effort:** **4/5**
**Recommended Priority:** **P2**
**Specific Actionable Next Steps:**
1. Create a design doc issue: task schema, states (posted/accepted/delivered/disputed), SLAs.
2. Collect 5–10 concrete “agent hit a wall” scenarios from community (content review, translation QA, data labeling, etc.).
3. Decide whether integration is:
   - a standalone plugin, or
   - a generic “HumanTaskProvider” interface with multiple backends.
4. Run a small pilot with one agent workflow and measure cost/latency/failure modes.
**Potential Assignees:** Miguel | Effect AI (external partner), core plugin architects, workflow automation contributors (e.g., lightningprox).

---

## 6) On-chain agent identity / continuity proposal (Z1N Protocol on Polygon) — *Feature exploration (no GitHub ID yet)*
**Current Status:** Concept shared; no technical follow-up captured.  
**Impact Assessment:**
- **User Impact:** **Low–Medium** (niche but strategically aligned with identity/persistence themes)
- **Functional Impact:** **No**
- **Brand Impact:** **Low–Medium**
**Technical Classification:**
- **Category:** Feature Request
- **Component Affected:** Identity / Integrations
- **Complexity:** **Complex solution**
**Resource Requirements:**
- **Required Expertise:** Web3 identity, indexing, security, protocol integration
- **Dependencies:** Alignment with existing identity work (e.g., prior SAID protocol work referenced in historical summary)
- **Estimated Effort:** **3/5**
**Recommended Priority:** **P3**
**Specific Actionable Next Steps:**
1. Request a concise technical spec from Z1N: how keys/signals map to agent instances, threat model, indexing approach.
2. Compare/contrast with existing identity primitives used by elizaOS (avoid parallel competing standards).
3. If aligned, prototype as an optional plugin with minimal footprint.
**Potential Assignees:** Z1N (protocol author), identity-focused maintainers, security reviewer.

---

## 7) Production readiness gaps: UI trust signals, error handling, context persistence, localization (Arabic RTL) — *Docs/roadmap item (no GitHub ID yet)*
**Current Status:** Discussed on Discord as adoption blocker; not yet decomposed into trackable issues.  
**Impact Assessment:**
- **User Impact:** **High** for enterprise/SME adoption; **Medium** for hobbyists
- **Functional Impact:** **Partial** (agents work, but fail “autonomous trust” threshold)
- **Brand Impact:** **High** (polish and reliability shape perception more than features)
**Technical Classification:**
- **Category:** UX + Reliability + Documentation
- **Component Affected:** GUI (if applicable), Core runtime ergonomics, Persistence layer
- **Complexity:** **Architectural change** (for persistence) + **moderate effort** (UX/error handling/docs)
**Resource Requirements:**
- **Required Expertise:** Product UX, frontend, i18n/RTL expertise, state management, observability
- **Dependencies:** Clarify current UI surface areas shipped by elizaOS; persistence strategy in v2
- **Estimated Effort:** **5/5**
**Recommended Priority:** **P2**
**Specific Actionable Next Steps:**
1. Create an “Enterprise readiness” epic with sub-issues (error taxonomy, retry strategy, user-visible logs, i18n/RTL).
2. Define a minimal “trust bar” checklist for agent deployments (health checks, audit logs, safe mode).
3. Prioritize persistence primitives (session restore, conversation state versioning).
**Potential Assignees:** Caesar ⚔️ (problem framing), core maintainers for persistence, frontend/i18n contributors.

---

## 8) Security hardening for DeFi agents via x402Guard proxy plugin — *Upcoming plugin (no GitHub ID yet)*
**Current Status:** Announced; planned open-source plugin within weeks; early testers requested.  
**Impact Assessment:**
- **User Impact:** **Medium** today; potentially **High** as DeFi agents grow
- **Functional Impact:** **Partial** (doesn’t block core, but blocks safe DeFi automation)
- **Brand Impact:** **High** if a wallet-draining incident happens without recommended guardrails
**Technical Classification:**
- **Category:** Security
- **Component Affected:** Plugin System / Wallet transaction pipeline
- **Complexity:** **Complex solution**
**Resource Requirements:**
- **Required Expertise:** Rust (proxy), EVM/Solana transaction semantics, threat modeling, plugin interfaces
- **Dependencies:** Plugin interface expectations; test environments; clear security disclaimers
- **Estimated Effort:** **4/5**
**Recommended Priority:** **P2**
**Specific Actionable Next Steps:**
1. Ask dzik pasnik to publish a prerelease repo or draft spec for integration points (how agent routes tx requests).
2. Define security baseline docs: spend limits, whitelists, audit log expectations.
3. Recruit 3–5 DeFi builders for pilot testing; capture attack simulations (prompt injection → tx attempt).
**Potential Assignees:** dzik pasnik (author), security-minded maintainers, DeFi community testers.

---

## 9) Linux embedding failures in plugin-ollama — Issue **#17** (elizaos-plugins/plugin-ollama)
**Current Status:** Previously identified as under investigation (from latest available weekly summary).  
**Impact Assessment:**
- **User Impact:** **Medium** (Linux is common for self-hosting; embeddings are core for RAG)
- **Functional Impact:** **Yes** for affected users (RAG/semantic search broken)
- **Brand Impact:** **Medium** (self-host reliability)
**Technical Classification:**
- **Category:** Bug
- **Component Affected:** Model Integration (Ollama embeddings)
- **Complexity:** **Moderate effort**
**Resource Requirements:**
- **Required Expertise:** Linux environment debugging, Ollama API behavior, embedding model config
- **Dependencies:** Repro steps, versions (Ollama, model, libc/cuda), CI matrix
- **Estimated Effort:** **3/5**
**Recommended Priority:** **P1**
**Specific Actionable Next Steps:**
1. Ensure issue #17 has a reproducible template filled (OS, kernel, Ollama version, model, logs).
2. Add a minimal Linux CI job (or containerized repro) running an embedding call.
3. Identify whether failure is due to model availability, endpoint mismatch, or binary deps; ship fix + release notes.
**Potential Assignees:** plugin-ollama maintainers, a Linux-focused community contributor, model integration maintainer.

---

## 10) Plugin registry contribution pipeline previously blocked — Issue **#259** (elizaos-plugins/registry) *(verify current status)*
**Current Status:** Reported as fixed historically; confirm no regression as v2 skills/discovery evolves.  
**Impact Assessment:**
- **User Impact:** **Medium** (blocks ecosystem growth when broken)
- **Functional Impact:** **Partial** (doesn’t break runtime, but blocks contributions)
- **Brand Impact:** **Medium** (contributor experience)
**Technical Classification:**
- **Category:** Bug / DevEx
- **Component Affected:** Plugin Registry / Automation
- **Complexity:** **Simple fix** if regression; otherwise monitoring
**Resource Requirements:**
- **Required Expertise:** GitHub Actions, automation, registry policy
- **Dependencies:** CI health, permissions model
- **Estimated Effort:** **1/5**
**Recommended Priority:** **P2**
**Specific Actionable Next Steps:**
1. Add a periodic CI canary for fork PR validation (ensure the “fixed” state stays fixed).
2. Align registry flow with upcoming skills.md decentralized model (avoid two competing pathways).
**Potential Assignees:** registry maintainers, CI/devex contributor.

---

# Highest-Priority Summary (Top 5–10 to address now)
1. **P0:** Token migration transparency gap (publish auditable migration %, supply breakdown, policy for unmigrated tokens).  
2. **P1:** **PR #6597** v2 skills folder + decision on shipping **0 default skills** vs curated set (architecture + governance).  
3. **P1:** plugin-evm goldrush.dev integration + close/track “open issues” with a proper GitHub epic.  
4. **P1:** skills.md **spec + hosting guidelines** (reduce fragmentation; enable safe discovery).  
5. **P1:** plugin-ollama Linux embedding failures — **Issue #17** (RAG blocker for self-hosters).  
6. **P2:** Effect AI human-in-the-loop integration exploration (design doc + pilot).  
7. **P2:** x402Guard DeFi security proxy plugin (pilot testers + integration spec).  
8. **P2:** Confirm plugin registry automation remains healthy — **Issue #259** (regression guard).  
9. **P3:** Z1N on-chain signaling/identity exploration (only after identity strategy alignment).  
10. **P2:** Production readiness epic (error handling, persistence, RTL/i18n) scoped into tractable issues.

---

# Patterns / Themes Indicating Deeper Architectural Problems
- **Ecosystem distribution governance is the bottleneck:** Skills/plugins previously suffered from uncontrolled submissions; v2 is at risk of repeating the same problem unless there’s a clear discovery + trust + provenance model.
- **Trust, safety, and transparency dominate perceived quality:** Token migration opacity (non-code) and DeFi agent security (x402Guard) both show that “agent capability” is secondary to *trust infrastructure*.
- **Fragmentation risk across “identity” initiatives:** SAID (historical), Z1N proposal, and other on-chain identity ideas may diverge without a single endorsed abstraction layer.
- **Production adoption blocked by non-model concerns:** Error handling, persistence, UI polish, and localization are repeatedly cited as what separates demos from deployable systems.

---

# Process Improvement Recommendations
1. **Create “Discord → GitHub intake” rules:** any P0/P1 surfaced on Discord must become a GitHub issue within 24 hours (owner + checklist + acceptance criteria).
2. **Add lightweight RFC process for ecosystem-wide decisions** (skills distribution, identity standards): 1-page RFC, 72-hour comment window, explicit decision log.
3. **Publish a monthly “trust report”** covering: security posture changes, tokenomics updates (if applicable), and ecosystem policy changes—single canonical link to reduce rumor loops.
4. **Introduce compatibility + provenance standards early:** versioned specs (skills.md schema), signed manifests/hashes, and UI/CLI provenance display to reduce supply-chain risk.
5. **Test matrix discipline for self-hosting integrations:** ensure Linux CI coverage for core model integrations (e.g., Ollama embeddings) and add reproducible bug templates.