## Issue Triage — 2026-03-07

### 1) Late ai16z → elizaOS Migration: missed deadline, eligibility + remediation process unclear (Discord)
- **Issue Title & ID:** Late token migration support & governance eligibility criteria — **DISCORD-2026-03-05-MIGRATION**
- **Current Status:** Active community incident; team creating a list of affected users; criteria not finalized.
- **Impact Assessment:**
  - **User Impact:** **High** (multiple holders missed the 90-day window; some sold before learning)
  - **Functional Impact:** **No** (not core runtime) / **Partial** (governance + ecosystem participation)
  - **Brand Impact:** **High** (trust + fairness perception; public disputes likely)
- **Technical Classification:**
  - **Issue Category:** UX / Documentation / Process (governance ops)
  - **Component Affected:** Governance, Token migration operations, Community support
  - **Complexity:** **Architectural change** (policy + tooling + comms + potential smart-contract/ops constraints)
- **Resource Requirements:**
  - **Required Expertise:** Token ops, governance policy, on-chain verification, community support moderation
  - **Dependencies:** Snapshot data availability; on-chain verification method; decision on “held at snapshot” rule
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish an **official migration remediation RFC**: who is eligible, evidence required, timeline, appeal path.
  2. Define the rule explicitly (e.g., **“tokens physically held at snapshot time”**) and document edge cases (custodial, LP, bridges, OTC).
  3. Create a **public tracking issue/board** (redacted where needed) with statuses: submitted → verified → approved/denied → executed.
  4. Add a **Migration FAQ**: deadlines, official contract addresses, “what if I sold,” “what if I bridged,” etc.
  5. Assign a single “migration ops” point-person and publish response SLAs.
- **Potential Assignees:**
  - **Odilitime** (already leading clarifications + list creation)
  - **Not Magicyte** (governance fairness proposal)
  - **Biazs** (community coordination / comms support)

---

### 2) Scam / phishing activity warnings in Discord (coders channel)
- **Issue Title & ID:** Scam link / impersonation risk in Discord — **DISCORD-2026-03-06-SCAM**
- **Current Status:** Reported by community (satsbased; prior scam warning by Mylord.eth); no documented mitigation plan in logs.
- **Impact Assessment:**
  - **User Impact:** **Critical** (potential wallet loss / account compromise)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (security posture perception)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** Community infrastructure (Discord), social engineering surface area
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/mod tooling, security best practices, incident response
  - **Dependencies:** Moderator availability; bot configuration; channel permission policies
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Enable/verify Discord **AutoMod** rules: block common phishing domains, new-account link posting limits, mention-spam throttling.
  2. Pin an **“Official Links & Safety”** post; add `/report-scam` instructions and a standard mod escalation path.
  3. Add a lightweight **security incident log** (date, channel, action taken) to improve follow-through.
  4. Consider a “links only allowed for trusted roles” policy in high-risk channels (e.g., coders).
- **Potential Assignees:**
  - **Server moderators / admins**
  - **Mylord.eth** (previously identified scam link)
  - **satsbased** (reporting; can help validate filters)

---

### 3) Babylon chain delivery repeatedly delayed (“couple weeks” since December)
- **Issue Title & ID:** Babylon chain release slippage / roadmap credibility risk — **DISCORD-2026-03-04-BABYLON**
- **Current Status:** Ongoing delay noted; no updated ETA or scoped milestone in provided logs.
- **Impact Assessment:**
  - **User Impact:** **Medium** (users waiting on promised deliverable)
  - **Functional Impact:** **Partial** (blocks dependent initiatives if Babylon is a dependency)
  - **Brand Impact:** **High** (promise fatigue; reputational drag)
- **Technical Classification:**
  - **Issue Category:** Process / Delivery (could include Engineering/Infrastructure)
  - **Component Affected:** Platform roadmap / chain integration (unspecified in logs)
  - **Complexity:** **Complex solution** (unknown technical blockers)
- **Resource Requirements:**
  - **Required Expertise:** Chain/devops/release management; stakeholder communication
  - **Dependencies:** Unknown—must be surfaced (spec gaps, audits, infra, funding, etc.)
  - **Estimated Effort (1–5):** **3** (to triage + re-plan; engineering effort may be higher)
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a **status update**: what’s done, what’s blocked, revised ETA, and contingency plan.
  2. Break work into **public milestones** with owners and acceptance criteria.
  3. If blocked externally, document the dependency and propose an interim alternative.
- **Potential Assignees:**
  - **Biazs** (raised the concern; can coordinate comms)
  - **Core maintainers responsible for chain roadmap** (not named in provided logs)

---

### 4) Embedding failures on Linux in Ollama plugin
- **Issue Title & ID:** Embeddings failing on Linux — **elizaos-plugins/plugin-ollama#17**
- **Current Status:** Reported; “investigating” per weekly summary; no resolution recorded here.
- **Impact Assessment:**
  - **User Impact:** **High** (Linux is common for self-hosting)
  - **Functional Impact:** **Partial** (breaks RAG/semantic search and any embedding-dependent flows)
  - **Brand Impact:** **Medium** (plugin reliability perception)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** Plugin System / Model Integration (Ollama embeddings)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Node/runtime + Linux env debugging, Ollama API specifics, embedding model configuration
  - **Dependencies:** Repro steps, OS/package versions, Ollama version matrix, CI environment to reproduce
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a minimal **repro script** + collect environment matrix (distro, CPU/GPU, Ollama version, model name).
  2. Confirm whether failure is in **binary discovery**, **API route**, **model pull**, or **vector format**.
  3. Add CI coverage (or nightly) that runs an embedding call on Linux.
  4. Document known-good versions and required Ollama flags.
- **Potential Assignees:**
  - **plugin-ollama maintainers**
  - **Stan ⚡** (infra-oriented; can help with CI/repro harness)
  - **Magicyte** (testing progress shared; can extend into plugin regression tests)

---

### 5) xproof plugin added to registry awaiting maintainer review (on-chain audit trails + compliance gating)
- **Issue Title & ID:** Review/merge xproof plugin PR — **elizaos-plugins/registry PR #266**
- **Current Status:** CodeRabbit approved; no conflicts; awaiting maintainer review/merge.
- **Impact Assessment:**
  - **User Impact:** **Medium** (adds optional compliance/audit capability; valuable for regulated users)
  - **Functional Impact:** **No** (new plugin)
  - **Brand Impact:** **Medium** (ecosystem momentum; responsiveness to contributors)
- **Technical Classification:**
  - **Issue Category:** Feature / Plugin Integration
  - **Component Affected:** Plugin Registry
  - **Complexity:** **Simple fix** (assuming registry checks pass; main work is review)
- **Resource Requirements:**
  - **Required Expertise:** Registry standards, security review for on-chain interactions, plugin metadata validation
  - **Dependencies:** Maintainer availability; confirm plugin meets registry policies (licensing, docs, safety notes)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Perform a quick **maintainer security pass**: key management expectations, chain RPC usage, data sent on-chain.
  2. Verify **docs** include threat model + cost implications (on-chain writes).
  3. Merge and announce; add to “recommended plugins” if it meets quality bar.
- **Potential Assignees:**
  - **Registry maintainers**
  - **jasonxkensei** (author; respond to review comments)

---

### 6) Missing “official CA of old ai16z” answer (user confusion; potential scam vector)
- **Issue Title & ID:** Official contract address clarification (old ai16z) — **DISCORD-2026-03-04-CA**
- **Current Status:** Asked, unanswered in logs.
- **Impact Assessment:**
  - **User Impact:** **High** (users may use wrong contract / get scammed)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (trust + safety)
- **Technical Classification:**
  - **Issue Category:** Documentation / Security
  - **Component Affected:** Token documentation, official links
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Token ops, on-chain verification, documentation editing
  - **Dependencies:** Confirm canonical addresses across chains (if multiple)
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish an **“Official Contracts”** page (and pin in Discord) including old/new addresses and explorers.
  2. Add a short **verification checklist** (how to verify via explorer; common scam patterns).
  3. Include in migration FAQ (ties directly to Issue #1).
- **Potential Assignees:**
  - **Odilitime** (already addressing token transparency)
  - **Server moderators** (pin + enforce)

---

### 7) Agent-to-vendor credit line enforcement primitive (bond + atomic slashing) needs validation
- **Issue Title & ID:** Validate need for credit-line enforcement primitive — **DISCORD-2026-03-06-CREDITLINES**
- **Current Status:** In validation; community feedback requested; not yet translated into a concrete spec/issue.
- **Impact Assessment:**
  - **User Impact:** **Medium** (relevant to tool/API vendors; enables safer autonomous commerce)
  - **Functional Impact:** **No** (future capability)
  - **Brand Impact:** **Medium** (positions ecosystem as production-ready for paid tools)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Architecture
  - **Component Affected:** Plugin/tool execution economics, payments, policy
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Mechanism design, smart contracts (if on-chain), payment flows, API metering, risk controls
  - **Dependencies:** Evidence that “unpaid compute mid-task” is real; integration points with tool execution
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P3** (promote to P2 only if validated by multiple vendors)
- **Specific Actionable Next Steps:**
  1. Run a **vendor survey**: frequency/impact of payment default; existing mitigations.
  2. Draft a **1–2 page spec** describing flows, failure modes, dispute resolution, and UX.
  3. Prototype off-chain escrow first (if feasible) before on-chain slashing complexity.
- **Potential Assignees:**
  - **N0vaMp4** (proposer)
  - **Stan ⚡** (infra + deployment economics perspective)
  - **Interested tool/API vendors from community** (to validate requirements)

---

### 8) Universal autoscaling deployment platform for agents (multi-channel out of the box)
- **Issue Title & ID:** Agent autoscaling + multi-channel deployment platform — **DISCORD-2026-03-05-AUTOSCALE**
- **Current Status:** In progress (Stan ⚡); no repo/issue link provided.
- **Impact Assessment:**
  - **User Impact:** **Medium** (improves reliability and onboarding for hosted deployments)
  - **Functional Impact:** **Partial** (improves production readiness; not required for core framework)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** Feature / Infrastructure
  - **Component Affected:** Deployment tooling, multi-channel adapters (WhatsApp/Telegram/SMS)
  - **Complexity:** **Complex solution**
- **Resource Requirements:**
  - **Required Expertise:** Cloud infra, autoscaling, secrets management, webhook handling, observability
  - **Dependencies:** Channel integrations, stable containerization, config standards
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Open a **design doc + repo issue** with target architecture and MVP scope.
  2. Define minimal operational requirements: logging, metrics, retries, rate limits, secret rotation.
  3. Provide a reference deployment (Terraform/Helm) and a “golden path” tutorial.
- **Potential Assignees:**
  - **Stan ⚡** (lead)
  - **Magicyte** (testing automation; can add load/regression tests)

---

## Highest-Priority Focus Summary (Top 5–10)
1. **P0:** Late token migration remediation + governance eligibility clarity (**DISCORD-2026-03-05-MIGRATION**)
2. **P0:** Discord scam/phishing mitigation and incident handling (**DISCORD-2026-03-06-SCAM**)
3. **P1:** Publish official old ai16z contract address(es) + verification guidance (**DISCORD-2026-03-04-CA**)
4. **P1:** Fix/resolve Linux embedding failures in Ollama plugin (**plugin-ollama#17**)
5. **P1:** Babylon chain delivery re-plan with transparent milestones (**DISCORD-2026-03-04-BABYLON**)
6. **P2:** Review/merge xproof plugin into registry (**registry PR #266**)
7. **P3:** Validate and spec agent-to-vendor credit line enforcement primitive (**DISCORD-2026-03-06-CREDITLINES**)
8. **P3:** Continue autoscaling multi-channel deployment platform with a published MVP plan (**DISCORD-2026-03-05-AUTOSCALE**)

---

## Patterns / Themes Indicating Deeper Problems
- **Governance + token ops are underspecified operationally:** repeated questions, missed deadlines, and “what’s official” gaps create both **brand risk** and **security risk** (scam vectors).
- **Ecosystem scaling pressure:** plugin growth (e.g., xproof) depends on maintainers’ review bandwidth; delays can discourage contributors.
- **Reliability/production readiness is emerging as a differentiator:** Linux embedding failures and autoscaling work point to the need for stronger **cross-platform CI** and **operational standards**.
- **Roadmap credibility risk:** Babylon delay discourse suggests a gap between external commitments and internally tracked milestones.

---

## Process Improvement Recommendations
1. **Create a public “Ops & Governance” issue tracker** (even lightweight) for migration, official contracts, and policy decisions—reduce Discord-only fragmentation.
2. **Adopt a security baseline for community channels:** AutoMod defaults, pinned official links, and a repeatable incident response checklist.
3. **Define PR review SLAs and ownership rotation** for the plugin registry to prevent “approved but waiting” stagnation.
4. **Expand CI matrices for plugins** (especially Linux) and require minimal repro artifacts for bug reports (env info template + automated smoke tests).
5. **Roadmap transparency discipline:** publish monthly milestones with explicit dependency callouts; avoid “couple weeks” language without tracked deliverables.