# Issue Triage — 2026-03-08

## 1) Token migration: late ai16z → elizaOS migrations (missed 90-day deadline) — **DISCORD-2026-03-05-MIGRATE**
- **Current Status:** Open; team collecting affected users; eligibility criteria not finalized
- **Impact Assessment:**
  - **User Impact:** **High** (multiple holders impacted; repeated questions in community)
  - **Functional Impact:** **Partial** (blocks token utility/governance for affected users; not core framework runtime)
  - **Brand Impact:** **High** (trust + fairness concerns; reputational risk)
- **Technical Classification:**
  - **Issue Category:** Bug / UX / Documentation (process + tooling gap)
  - **Component Affected:** Token ops / Governance process (off-repo operational workflow)
  - **Complexity:** **Moderate effort** (policy + tooling + comms)
- **Resource Requirements:**
  - **Required Expertise:** Token ops, on-chain analysis, governance policy, community support
  - **Dependencies:** Snapshot data availability; definition of “eligible at snapshot time”; potential legal/compliance review
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish an **official policy**: eligibility rules (e.g., “physically held at snapshot time”), required proofs, deadlines, appeals.
  2. Create an **intake form** (wallet, tx proofs, amount, chain, timestamp) + public tracking (anonymized).
  3. Build/ship a **verification script** to check snapshot inclusion + post-snapshot movements.
  4. Decide operational resolution path: manual mint, vesting, claim contract, or “no action” for sold-before-snapshot cases.
- **Potential Assignees:** **Odilitime** (token ops/community), **Not Magicyte** (governance stance contributor), core multisig/operator team

---

## 2) Airdrops for token holders “in progress” but unclear scope/timeline — **DISCORD-2026-03-07-AIRDROP**
- **Current Status:** Open; acknowledged by team; execution pending
- **Impact Assessment:**
  - **User Impact:** **High**
  - **Functional Impact:** **No** (doesn’t block agent runtime)
  - **Brand Impact:** **High** (confidence + “shipping” narrative)
- **Technical Classification:**
  - **Issue Category:** Feature / UX / Documentation (delivery + communication)
  - **Component Affected:** Token ops / Distribution tooling
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Smart contract ops (if claim), scripting, exchange/wallet edge cases, comms
  - **Dependencies:** Final airdrop rules; snapshot references; anti-sybil constraints (if any)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Announce **exact airdrop spec**: eligibility, calculation, chain(s), claim method, dates.
  2. If claim-based: deploy claim contract + publish audited/verified source + Merkle dataset.
  3. Provide a **self-check page/script** for eligibility to reduce Discord support load.
- **Potential Assignees:** **Odilitime**, token ops engineers/maintainers, community mods for support triage

---

## 3) Active scam risk & token impersonation confusion (Milady “legit token” + scam links) — **DISCORD-2026-03-07-SCAM-MILADY**
- **Current Status:** Ongoing; “no legit Milady token yet” stated; scam link warnings observed
- **Impact Assessment:**
  - **User Impact:** **Critical** (users can lose funds)
  - **Functional Impact:** **No** (doesn’t break framework execution)
  - **Brand Impact:** **High** (project perceived as unsafe/confusing)
- **Technical Classification:**
  - **Issue Category:** **Security** / Documentation
  - **Component Affected:** Community safety, official comms, link hygiene
  - **Complexity:** **Simple fix** (process + pinned messaging) to **Moderate** (automation/bots)
- **Resource Requirements:**
  - **Required Expertise:** Community moderation, security awareness, Discord automation
  - **Dependencies:** Confirmation of official plans (chain, naming, contracts) when ready
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Pin an **“Official Tokens & Links”** message in key channels (contract addresses when applicable; “none yet” where applicable).
  2. Add/strengthen **anti-phishing bot rules**: block new accounts posting links, domain allowlist, auto-delete flagged URLs.
  3. Create a short **security playbook**: how to verify announcements, where official addresses will be published, reporting flow.
  4. Assign moderators to maintain a **live scam tracker** and escalate repeat offenders for bans.
- **Potential Assignees:** **Odilitime** (official comms), **Mylord.eth** (security-minded community member), Discord moderators/admins

---

## 4) Transparency gap: questions about Shaw’s holdings/role driving FUD — **DISCORD-2026-03-07-TRANSPARENCY**
- **Current Status:** Open; community asking; partially addressed (“team vs Shaw” distinction) but not resolved
- **Impact Assessment:**
  - **User Impact:** **High** (broad community morale)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (stakeholder comms)
  - **Component Affected:** Governance comms, project credibility
  - **Complexity:** **Simple fix** (publish FAQ) to **Moderate** (ongoing reporting cadence)
- **Resource Requirements:**
  - **Required Expertise:** Governance, comms, on-chain transparency reporting
  - **Dependencies:** Agreement on what can be disclosed
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a **Transparency FAQ**: roles, vesting/lockups if any, policies on selling, multisig controls.
  2. Provide a **single canonical link** for token-related disclosures (snapshot, holdings statements, audits).
  3. Establish a **monthly transparency note** to prevent recurring rumor cycles.
- **Potential Assignees:** **Odilitime**, governance/core leadership, comms lead

---

## 5) Plugin registry PR pending: xproof plugin (on-chain audit trails) awaiting maintainer review — **elizaos-plugins/registry PR #266**
- **Current Status:** CodeRabbit approved; awaiting maintainer merge/review
- **Impact Assessment:**
  - **User Impact:** **Medium** (useful for compliance + auditability adopters)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (ecosystem momentum; contributor experience)
- **Technical Classification:**
  - **Issue Category:** Feature
  - **Component Affected:** Plugin System / Registry
  - **Complexity:** **Simple fix** (review + merge) / **Moderate** (if policy/security review needed)
- **Resource Requirements:**
  - **Required Expertise:** Registry maintainership, plugin security review, API compatibility checks
  - **Dependencies:** Registry contribution guidelines; potential security checklist for on-chain hooks
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Perform a **maintainer review** focusing on permissions, key management expectations, and data leakage risks.
  2. Merge PR or request changes within 48–72h to keep contributor loop tight.
  3. Add minimal **documentation snippet**: example config + threat model notes.
- **Potential Assignees:** Registry maintainers, **jasonxkensei** (author) for follow-ups

---

## 6) Linux embedding failures in Ollama plugin — **elizaos-plugins/plugin-ollama Issue #17**
- **Current Status:** Open; “investigating” noted previously; no resolution in current logs
- **Impact Assessment:**
  - **User Impact:** **Medium** (Linux devs/self-hosters are a large segment)
  - **Functional Impact:** **Partial** (blocks embeddings-dependent features: retrieval/memory/vector search)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Model Integration / Embeddings (plugin-ollama)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Linux runtime debugging, Ollama API behavior, embeddings pipeline, dependency management
  - **Dependencies:** Repro steps + environment matrix (glibc, CUDA/ROCm, CPU-only); upstream Ollama versions
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1** (because it breaks a common capability: embeddings/RAG)
- **Specific Actionable Next Steps:**
  1. Request a **minimal repro** + logs from reporters (Ollama version, model, OS, arch).
  2. Add **CI smoke test** for embeddings on Linux container.
  3. Validate request/response schema; add defensive parsing + clearer error messages.
  4. Document known-good version matrix; pin or warn on incompatible versions.
- **Potential Assignees:** plugin-ollama maintainers, core model-integration contributors

---

## 7) Agent autoscaling universal deployment platform (WhatsApp/Telegram/SMS) — **DISCORD-2026-03-05-AUTOSCALE**
- **Current Status:** In development (prototype described)
- **Impact Assessment:**
  - **User Impact:** **Medium** (important for production deployers)
  - **Functional Impact:** **Partial** (not required for local dev, but key for hosted reliability)
  - **Brand Impact:** **Medium** (signals maturity if delivered)
- **Technical Classification:**
  - **Issue Category:** Feature / Performance / Reliability
  - **Component Affected:** Infrastructure / Deployments / Multi-channel adapters
  - **Complexity:** **Complex solution** (potentially architectural)
- **Resource Requirements:**
  - **Required Expertise:** Cloud infra (K8s/containers), queueing, multi-tenant isolation, secrets management, observability
  - **Dependencies:** Stable agent runtime interfaces; channel integrations; auth + rate limiting; cost controls
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Write a short **RFC**: scaling model, tenancy, deployment targets, SLA goals.
  2. Define a minimal **MVP**: single cloud, 1–2 channels, autoscale on CPU/QPS, basic health checks.
  3. Add **observability** first (metrics/traces/logs), then autoscaling policies.
- **Potential Assignees:** **Stan ⚡** (infra lead on this), infra contributors

---

## 8) Agent-to-vendor credit line enforcement primitive (bond + atomic slashing) needs validation — **DISCORD-2026-03-06-CREDITLINE**
- **Current Status:** In validation phase; community feedback requested
- **Impact Assessment:**
  - **User Impact:** **Low → Medium** (depends on adoption by paid tool/service providers)
  - **Functional Impact:** **No** (not required for basic agents)
  - **Brand Impact:** **Medium** (trust layer for “agents that pay”)
- **Technical Classification:**
  - **Issue Category:** Feature / Security (economic security)
  - **Component Affected:** Payments / Tooling ecosystem (agent commerce)
  - **Complexity:** **Architectural change** (if integrated into core)
- **Resource Requirements:**
  - **Required Expertise:** Mechanism design, smart contracts (if on-chain), risk modeling, API billing systems
  - **Dependencies:** Clear problem statement + real-world incidents; integration points in tool calling/payment flows
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P3** (until validated as a real, frequent failure mode)
- **Specific Actionable Next Steps:**
  1. Collect **incident data**: unpaid compute, partial task abandonment, chargeback-like scenarios.
  2. Draft an **RFC** with threat model and alternatives (prepay, escrow, metering, quotas).
  3. If validated, prototype as an **optional plugin** before core integration.
- **Potential Assignees:** **N0vaMp4** (proposer), tokenomics/security-minded contributors

---

## 9) Buyback program request during price depression (unanswered) — **DISCORD-2026-03-07-BUYBACK**
- **Current Status:** Open question; no team response in logs
- **Impact Assessment:**
  - **User Impact:** **Medium** (investor community concern; not all users)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium → High** (perceived capital allocation competence)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Governance
  - **Component Affected:** Treasury strategy (off-repo)
  - **Complexity:** **Moderate effort** (policy + execution) to **Complex** (legal/compliance)
- **Resource Requirements:**
  - **Required Expertise:** Treasury management, legal/compliance, governance process
  - **Dependencies:** Treasury transparency; jurisdiction constraints; governance approvals
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Provide an **official stance** (yes/no/maybe later) and rationale.
  2. If considered: publish guardrails (budget, triggers, disclosure cadence).
- **Potential Assignees:** Core leadership, governance/tresury operators

---

## 10) Product shipping credibility gap (missed “end of 2025” timeline; low Discord technical activity) — **DISCORD-2026-03-07-SHIPPING**
- **Current Status:** Ongoing; sentiment issue; no concrete mitigation published
- **Impact Assessment:**
  - **User Impact:** **High**
  - **Functional Impact:** **Partial** (reduces adoption; slows contributions)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (developer relations) / Process
  - **Component Affected:** Release management
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Release engineering, roadmap planning, comms
  - **Dependencies:** Agreement on near-term deliverables; owners for each deliverable
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a **30/60/90-day roadmap** with measurable deliverables (not aspirations).
  2. Start a weekly **changelog + demo** cadence (even small wins) to restore momentum.
  3. Add “good first issue” labeling + contributor onboarding tasks to re-energize coders channel.
- **Potential Assignees:** Core maintainers, project manager/release captain (if designated), **Odilitime** for comms loop

---

# Conclusion

## A) Top highest-priority issues to address immediately (next 24–72h focus)
1. **P0 — DISCORD-2026-03-07-SCAM-MILADY:** Scam/token impersonation risk + official links/contracts pinning
2. **P1 — DISCORD-2026-03-05-MIGRATE:** Late token migration policy + verification workflow
3. **P1 — DISCORD-2026-03-07-AIRDROP:** Airdrop specification + execution plan + self-check tooling
4. **P1 — elizaos-plugins/plugin-ollama #17:** Linux embedding failures blocking embeddings/RAG capability for a key segment
5. **P1 — DISCORD-2026-03-07-TRANSPARENCY:** Publish transparency FAQ to reduce recurring FUD
6. **P1 — DISCORD-2026-03-07-SHIPPING:** Near-term roadmap + release cadence to restore trust
7. **P2 — elizaos-plugins/registry PR #266:** Maintain contributor momentum by timely review/merge

## B) Patterns/themes indicating deeper issues
- **Information scarcity → trust debt:** Repeated token/governance questions (migration, airdrops, holdings) suggest missing canonical documentation and a regular disclosure cadence.
- **Operational work not tracked like engineering work:** Token ops, migration support, and airdrops behave like “tickets” but lack owners, SLAs, and public status—creating the perception of stagnation.
- **Security surface is community-driven:** Scam detection is happening ad hoc (users spotting links). This needs systematic controls (pinned guidance + automated moderation).

## C) Process improvement recommendations
- Establish a **public Ops & Governance tracker** (GitHub Project board or dedicated repo) with issues for migration, airdrops, disclosures, and comms—owned, dated, and statused.
- Create a **single “Source of Truth” page** for: official tokens/contracts, snapshots, migrations, airdrops, and security warnings; link it via Discord channel topics and bot auto-replies.
- Implement a **moderation + security baseline**: link throttling for new accounts, domain allowlist, and a defined escalation workflow.
- Adopt a **weekly release + demo ritual** with a fixed template: shipped, in-progress, blocked, next—reducing timeline ambiguity and keeping technical contributions visible.