# User Feedback Analysis — 2026-04-21 (elizaOS)

## 1) Pain Point Categorization (Top recurring friction areas)

**Data basis:** Discord logs (2026-04-18 to 2026-04-20) + referenced GitHub activity/proposals in the same period. Across **13 explicitly logged user questions/FAQ items**, the most common themes were **token/economics (6/13 ≈ 46%)** and **security/scams (5/13 ≈ 38%)**.

### 1. Security (Community + Technical Functionality) — scams, phishing, and support impersonation
**What users experience (high severity, high recurrence):**
- Repeated **airdrop/phishing scams** in Discord (e.g., “airdrop tags are always scams”).
- A high-impact incident: a user reported losing **~$700–$900** during the **ai16z migration** situation and then further losses via a **fraudulent “support ticket”** workflow.
- Confusion about what is “official” vs “fake” communications (airdrop links, impersonation of team members).

**Who it affects most:** newcomers and token holders seeking migration help; anyone asking support questions in public channels.

### 2. Token lifecycle clarity (Documentation + UX/UI + Community) — migration, staking expectations, chain/ticker confusion
**What users experience (high severity when funds involved):**
- **Migration window closure** surprised users; “How can I migrate from Ledger?” was answered with “migration is closed,” with no recovery path.
- Persistent questions about **staking availability** (“not currently available”).
- Confusion about **where the token lives** and **which ticker** (“Is elizaos back on sol? Which ticker is it?”).
- Unclear **token utilities** in the broader ecosystem; users asked how $ELIZAOS relates to ElizaOK/elizacloud.

**Who it affects most:** token holders, traders, and anyone evaluating participation based on utility.

### 3. Product/Ecosystem positioning (Documentation + Communication) — ElizaOS vs ElizaOK vs elizacloud
**What users experience (medium-high frequency, medium severity):**
- Repeated confusion about **relationship and business model**:
  - “Does ElizaOK have a separate token?” → clarified “no token for now, built with elizacloud.”
  - “How does ElizaOS connect to ElizaOK?” → deferred to odilitime for detailed explanation.
- Users interpret brand/product boundaries as separate products with separate tokens/utilities; reality is more consolidated (ElizaOK flows into elizacloud).

**Who it affects most:** evaluators, partners, and community members trying to understand roadmap/monetization.

### 4. Developer onboarding gaps (Documentation) — building examples and “what you can build”
**What users experience (medium frequency, medium severity):**
- Users couldn’t translate docs (“docs.elizaos.ai/what-you-can-build”) into runnable projects and asked for tutorials.
- Resolution was a pointer to GitHub examples directory (`.../tree/v2.0.0/examples`), implying docs are not sufficiently “execution-oriented” (commands, prerequisites, expected outputs).

**Who it affects most:** newcomers, Dev School students, and builders trying to prototype quickly.

### 5. Integration friction for provider plugins (Integration + Documentation) — “how do I add provider X?”
**What users experience (medium frequency, medium severity):**
- A concrete unresolved request: “minimax token plan key integration as a provider plugin” (unanswered).
- Indicates demand for a **standard provider-plugin pattern** (keys, auth, rate limits, error handling, testing expectations).

**Who it affects most:** plugin developers and teams integrating new model/API providers.

### 6. Security vulnerability reporting uncertainty (Community + Documentation)
**What users experience (lower frequency, potentially high severity):**
- A researcher asked about **bug bounty** (none exists), then correctly insisted vulnerabilities should be disclosed privately rather than via public issues/PRs.
- Initial community guidance suggested public disclosure before being corrected—signals lack of a formal, visible process.

**Who it affects most:** security researchers, maintainers, and downstream deployers.

### 7. Release/roadmap expectation management (Communication)
**What users experience (medium frequency, medium severity):**
- “ElizaOS v3 is nearly ready” + “will enable agents to generate revenue,” but no date or rollout expectations.
- Users anchor on monetization; ambiguity can cause churn or repeated “when release?” questions.

**Who it affects most:** builders waiting to ship agent commerce features; ecosystem partners.

---

## 2) Usage Pattern Analysis (actual vs intended usage)

### Observed “actual usage”
- **Token-anchored participation**: a large share of questions are about migration, staking, chains, ticker, and utility (**~46% of logged questions**).
- **Agents-as-commerce actors**: strong pull toward **paid agent services** and “agents that help people make money”:
  - Elisym plugin turns agents into paid providers (capability cards via Nostr NIP-89, encrypted job requests NIP-90, SOL payments).
  - Ongoing GitHub discussions/proposals trending toward **standardized agent commerce** (tools/services payments).
- **Security-minded Web3 use cases**: users explicitly ask whether agents can “solve serious hacking problems” in DeFi; scams inside Discord make security top-of-mind.

### Emerging / unexpected applications
- **Nostr-based service discovery + Solana settlement** as a distribution and monetization channel (via `plugin-elizaos-elisym`).
- Community interest in **agent-driven DeFi security** (key management, hack prevention), likely driven by real-world hacks (e.g., KelpDAO/Lazarus discussion).

### Feature requests aligning with observed patterns
- Standardized **agent commerce protocol** and reference implementations (aligns with v3 “revenue generation” narrative).
- “Provider plugin” templates and guides (e.g., MiniMax provider integration).
- Strong demand for “official, safe support” surfaces to reduce scam losses (not a feature request phrased that way, but repeatedly implied).

---

## 3) Implementation Opportunities (solutions per major pain point)

### A) Scam/phishing + fake support tickets
**1) Add an “Official Support & Safety” system in Discord (High impact / Low–Medium difficulty)**
- Lock support to a single, read-only **#official-support** channel and a **single support form**; disable ad-hoc “ticket” creation from untrusted bots.
- Add an auto-moderation bot rule set to block common phishing patterns (“airdrop”, “claim”, shortlinks) and quarantine posts.
- **Comparable approaches:** many Web3 Discords use **Wick/Carl-bot + locked support channels**; major protocols pin “we will never DM you” warnings with forced acknowledgements.

**2) Add an in-product “Verify official links” page (High impact / Medium difficulty)**
- A single canonical page listing official domains, contract addresses per chain, and “no airdrops in Discord” policy.
- Include a copy-pastable “report scam” workflow.

**3) Incident response playbook (Medium impact / Low difficulty)**
- Template: what to do if scammed (revoke approvals, freeze keys, report to Discord, etc.).
- Post it immediately after scam incidents; reduce repeated ad-hoc guidance.

### B) Token lifecycle clarity (migration, staking, chain/ticker, utility)
**1) Publish a “Token Status” dashboard + pinned Discord FAQ (High impact / Low difficulty)**
- Pinned: migration window status (open/closed), staking status (available/not), supported chains (Solana/BSC/Base), ticker(s), official contract addresses.
- **Comparable approaches:** Ethereum L2s and DeFi protocols maintain “status + addresses” pages to reduce impersonation and confusion.

**2) “Closed migration” remediation messaging (High impact / Medium difficulty)**
- When migration is closed, provide:
  - clear finality statement,
  - explanation why,
  - checklist to avoid scams (“anyone offering manual migration is a scam”),
  - if applicable, a documented escalation path (even if it ends in “no action possible”).
- Reduces panic-driven scam susceptibility.

**3) Token utility explainer tied to products (Medium impact / Medium difficulty)**
- A diagram showing ElizaOS / ElizaOK / elizacloud relationship and where token fits today vs planned.
- Include “what exists now” vs “what’s planned” to prevent over-assumptions.

### C) Ecosystem positioning confusion (ElizaOS vs ElizaOK vs elizacloud)
**1) One canonical architecture page + versioned glossary (High impact / Low difficulty)**
- Define terms: ElizaOS (framework), elizacloud (platform), ElizaOK (app/flow), token deployments.
- Keep it versioned (“as of 2026-04”) to reduce outdated community lore.

**2) Public “business model & token utility” AMA notes (Medium impact / Low difficulty)**
- Since detailed explanation was deferred to odilitime, publish that response as a permanent doc.
- **Comparable approaches:** open-source platforms often convert repeated Discord answers into a “Canonical Answers” doc (e.g., Rust RFC FAQ style).

### D) Developer onboarding: examples hard to run from docs
**1) Make each “What you can build” item runnable (High impact / Medium difficulty)**
- For each showcased build: add `Prereqs`, `Setup`, `Run`, `Expected output`, `Common failures`.
- Link directly to the exact example folder + commit/tag (already v2.0.0 exists; make that explicit in docs).

**2) Add a single “Getting started by example” tutorial (High impact / Low difficulty)**
- “Pick one: Discord bot / Telegram bot / REST API agent” with step-by-step commands.
- **Comparable approaches:** Next.js, Astro, and LangChain succeed by offering “one golden path” tutorial.

**3) Add an `eliza doctor` / environment check command (Medium impact / Medium difficulty)**
- Validates bun/node versions, env vars, model provider keys; outputs fixes.

### E) Provider plugin integration gaps (e.g., MiniMax key plan)
**1) Standardize provider plugin interface + template (High impact / Medium difficulty)**
- A generator that scaffolds: config schema, key handling, rate limiting, retries, tests.
- Include “how to add Provider X” doc with a checklist.

**2) Maintain a “Provider support matrix” (Medium impact / Low difficulty)**
- List officially supported providers vs community providers; link to plugins.
- Reduces repeated “how do I integrate X?” questions.

### F) Security vulnerability reporting process
**1) Add `SECURITY.md` with private disclosure instructions (High impact / Low difficulty)**
- Include: contact method, response SLA, what not to post publicly, encryption option.
- **Comparable approaches:** GitHub, Kubernetes, and most major OSS projects rely on `SECURITY.md` as the first-line norm.

**2) Lightweight “recognition” program if no bounty (Medium impact / Low difficulty)**
- Hall-of-fame acknowledgments, CVE coordination guidance, credits in release notes—encourages ethical disclosure even without payouts.

### G) Release/roadmap expectations (v3, “revenue generation”)
**1) Publish “v3: scope + rollout plan” (High impact / Low difficulty)**
- Even without a date, list: features, beta criteria, migration notes, what “generate revenue” concretely means (marketplaces? payments? escrow?).

**2) Early access checklist for builders (Medium impact / Low difficulty)**
- “If you want to build commerce agents now, use: x402 plugin / Elisym plugin / registry workflow” with links.

---

## 4) Communication Gaps (expectations vs reality)

- **Expectation:** migration help is available via “support tickets.”  
  **Reality:** scammers exploit support-seeking behavior; there’s no safe, official ticketing flow visible to users.

- **Expectation:** staking exists or is imminent (users keep asking).  
  **Reality:** “staking is not currently available,” but this isn’t discoverable unless you ask.

- **Expectation:** ElizaOK might have its own token / separate economy.  
  **Reality:** ElizaOK is built with elizacloud and currently has no separate token; deeper business model explanation is deferred, leaving a gap.

- **Expectation:** vulnerability reporting can happen via GitHub issues/PRs.  
  **Reality:** security issues should be private; community guidance was briefly misaligned, signaling missing formal guidance.

- **Recurring onboarding questions indicating docs gaps:**
  - “How do I build the examples in the docs?”
  - “Which chain is the token on / what’s the ticker?”
  - “How do I integrate provider X?”

---

## 5) Community Engagement Insights

### Power users / key contributors observed
- **odilitime (Community Ops/Core Dev):** central support node for migration closure, examples guidance, and security disclosures.
- **satsbased (Core contributor/mod):** clarifies token chain deployment; communicates v3 readiness/vision.
- **baogerbao:** provides ecosystem clarification (ElizaOK ↔ elizacloud).
- **igor.peregudov (Elisym Labs):** high-quality integration release (`plugin-elizaos-elisym`) with strong testing/CI discipline (110 tests, provenance signing).
- **stan0473:** enforces naming conventions/standards, improving ecosystem consistency.
- **spankyxn + mods:** rapid scam confirmation and moderation actions.

**Power-user needs (implied):**
- Faster paths to publish/verify plugins in the registry (e.g., PR #346 review).
- Clear standards (naming, testing, provenance) to scale third-party integrations safely.

### Newcomer questions indicating onboarding friction
- “How do I migrate?” “Is staking available?” “Which ticker/chain?” “How do I run examples?”
These map to missing pinned “canonical answers” and a lack of a single onboarding hub.

### Converting passive users into contributors
- Turn repeated Q&A into contribution tasks:
  - “Improve token FAQ page”
  - “Add run steps to example X”
  - “Write SECURITY.md / scam-response guide”
- Label these as “good first issue” and link directly from Discord when questions recur.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord:** high-volume, high-signal for urgent issues (scams, migration panic) but **unstructured**—answers get lost and repeated.
- **GitHub issues/PRs:** strong for technical work and proposals, but community questions (token utility, ecosystem model) often remain Discord-only.

### Improvements to gather structured, actionable feedback
1) **Weekly “Top Questions” digest → docs backlog (Low difficulty)**
   - Each week, convert the top 5 repeated Discord questions into:
     - a docs PR, or
     - a pinned FAQ update, or
     - a GitHub discussion thread.

2) **Short structured intake forms (Low–Medium difficulty)**
   - “Report a scam” form (with screenshots, user IDs, links).
   - “Docs confusion” form (page URL, what they tried, error output).
   - “Plugin request” form (provider name, auth method, expected API).

3) **Tagging/triage protocol across channels (Medium difficulty)**
   - Standard tags: `SCAM`, `TOKEN`, `DOCS`, `PROVIDER_PLUGIN`, `SECURITY_REPORTING`, `V3`.
   - Helps quantify trends beyond anecdote.

### Underrepresented segments
- **Non-Web3 builders**: most surfaced feedback is token/DeFi adjacent; we have limited direct feedback from users building non-financial agents (education, enterprise automation, etc.).
- **Self-hosted operators**: little direct feedback about deployment, scaling, observability—likely present but not captured in these logs.

---

## Prioritized High-Impact Actions (next 2–4 weeks)

1) **Ship a Security & Scam Safety package (Discord + docs):** locked official support path, pinned “no airdrops/no DMs,” scam reporting workflow, and an official links/addresses page.  
2) **Publish a canonical “Token Status & Utility” page:** migration closed messaging, staking status, chain/ticker/contract addresses, and a “what exists now vs planned” utility explainer.  
3) **Add `SECURITY.md` and a formal private disclosure process:** prevent public vuln disclosure confusion; add recognition if no bounty.  
4) **Upgrade docs from “showcase” to “runnable”:** make “what you can build” examples executable with step-by-step commands and expected outputs; add a single golden-path tutorial.  
5) **Standardize provider plugin onboarding:** provider plugin template + support matrix; triage and answer the MiniMax provider integration request with either a reference implementation or a documented “not yet supported” stance.