# User Feedback Analysis — 2025-12-26 (elizaOS) ## 1) Pain Point Categorization (Top recurring issues) ### 1. Documentation — Token migration rules + eligibility are unclear (high frequency, high severity) **What users report** - Migration portal shows “0 eligible” unexpectedly; users don’t understand the **Nov 11 snapshot** constraint and the **same-wallet requirement** (e.g., Dabel: “0 tokens” → Alexei: only snapshot-held tokens, same wallet). - Wallet compatibility gaps (e.g., **Tangem not supported via WalletConnect** in GitHub issue #6211; users cannot export seed phrases). - Confusion about the **1:6 swap ratio** and post-migration distribution transparency (“unfair”, “what happened to distribution?”). **Quantifiable signal from provided feedback** - In the Dec 25 captured FAQ list, **4/7 questions (57%)** are directly about migration mechanics/eligibility (“0 tokens”, mintable token, why migration, swap completion). --- ### 2. Community — Trust & safety issues in support channels (high severity) **What users report** - Repeated warnings about **scam links / impersonators** during migration (Serikiki, Hexx 🌐). - Users are being pushed to DMs; community urges “official ticket system only”. - GitHub issue #6211 explicitly states **Discord support is “compromised”** by impersonators, driving users to seek verification on GitHub. **Impact** - Users avoid support channels, delay migration, or risk theft—this is both a UX and reputational incident. --- ### 3. Communication (Documentation/Community) — Token utility & value accrual expectations don’t match reality (high frequency, high severity) **What users report** - Strong frustration about token price decline (reported “90–98% losses”, “down 99.5% from peak”). - Confusion about “what is the token for?”; answers currently focus primarily on **Cloud revenue buybacks** (Odilitime). - Roadmap perceived as not addressing tokenomics: “Where in the roadmap does it mention value accrual?” → “technical doc, not tokenomics piece” (Kenk). **Observable pattern** - The majority of discussion highlights across Dec 24–25 are token-centric (migration, valuation comparisons to Pippin/Virtuals, exchange delisting fears). --- ### 4. UX/UI — Cloud product UX and “what can I do here?” onboarding friction (medium-high frequency, medium severity) **What users report** - Direct callouts to “Improve ElizaOS Cloud website UX/UI and documentation” (Hidden Forces). - Users ask basic capability questions: - Upload constraints: “can I upload 300 pages?” → **50MB limit** (Borko) - Custom models: “can I use my own GPU models?” → “not yet, roadmap next week” (Borko) - Best data format guidance: “markdown recommended” (Borko) **What this suggests** - Users are trying to treat Cloud as a “bring my data + run my agent” workspace, but product boundaries are not self-evident in-product. --- ### 5. Technical Functionality — Tooling reliability & developer setup friction (medium frequency, medium severity) **What users report** - Install/version mismatches: “ensure latest node/bun” (cjft); “Bun/Node/NPM version inconsistencies” listed as an action item. - CI fragility due to external billing: GitHub Actions job failure due to **Claude billing needing top-up**. - Monorepo docs stale/outdated: Stan identified outdated/false monorepo documentation and started updating it. --- ### 6. Integration — Exchange/wallet ecosystem constraints create product dead-ends (medium frequency, high severity) **What users report** - Migration required moving away from **token2022** because “many exchanges won’t support it” (Odilitime). - **Korean exchange delisting risk** in January discussed repeatedly (Bithumb/Coinone/Korbit). - Wallet migration guidance (“move to Phantom”) doesn’t work for non-exportable wallets (Tangem case). --- ## 2) Usage Pattern Analysis (actual vs intended use) ### How users are actually using elizaOS / Eliza Cloud - **Automation for personal productivity / habits**: R0am maintains a 40-day streak on tip.md using “async agents… review when I get home”. - **Knowledge ingestion**: users want to upload large books/datasets (“300 pages of book data”), and ask for best formats (markdown). - **Building serverless / modern web stacks**: Shaw mentions a pure **Bun + Elysia + workerd** frontend approach (faster than Next.js), suggesting experimentation beyond the default stack. - **Cloud as an “agent registry + deployment + monetization” path**: Cloud beta positioned for agent registration pre–EthDenver; builders being onboarded for production feedback. - **Gaming-adjacent agents**: community mentions GAMEBORO (Steam AI gaming assistant) and ideas like a fighting game using Eliza IP. ### Mismatch vs intended usage (as implied by team messaging) - Team frames Cloud as the “tokenomics engine” and infrastructure foundation. - Users evaluate primarily through **token performance + migration experience**, not through building/deploying agents. - Many questions are “Can Cloud do X today?” rather than “How do I build an agent with the framework?” ### Feature requests aligned with observed usage - Custom model hosting (bring-your-own GPU/model) — explicitly requested; on near-term roadmap. - Better “data to agent” workflows (bulk upload, formats, limits) — repeatedly surfaced. - A public showcase / demo (“idea to showcase eliza cloud”) to translate infrastructure into tangible outcomes. --- ## 3) Implementation Opportunities (solutions per major pain point) ### Pain point A: Migration eligibility confusion + wallet dead-ends **High impact / medium difficulty** 1) **Migration Eligibility Checker v2 (deterministic + explainable)** - Show *why* a wallet is ineligible (e.g., “Not the snapshot wallet”, “Snapshot balance = 0”, “Wallet type unsupported”). - Provide a single “eligibility proof” screen users can screenshot/share. - Similar approach: many airdrop/migration tools add “Why am I not eligible?” breakdowns (e.g., Uniswap/Snapshot-based claims patterns). 2) **Official “Unsupported Wallet” path (Tangem-class)** - Add a documented/manual claim process with strict verification (signed message from snapshot wallet or alternative attestation). - If impossible, explicitly state “no recovery possible for non-connectable wallets” early, with rationale, to reduce false hope and repeated tickets. 3) **One canonical migration guide + pinned in Discord + linked in migration UI** - Include: snapshot date, same-wallet rule, supported wallets, common “0 eligible” causes, scam warnings, and official support links. --- ### Pain point B: Trust & safety breakdown in support **High impact / medium difficulty** 1) **Lock down support workflow** - Disable DMs from server members by default guidance; add a server banner warning. - Force all support to occur in a single verified channel + ticket tool; publish a signed “Official Support Accounts” list. 2) **Add in-app “Report scam / verify link” page** - A static page on the official domain listing the only valid migration URLs and domains. - Similar approach: Ethereum/L2 projects often maintain “official links” pages during token events. 3) **Move sensitive support to GitHub Discussions (verified identities)** - For migration, create a GitHub Discussion category with templates and maintainers tagged, reducing Discord impersonation risk. --- ### Pain point C: Token utility/value accrual messaging gap **High impact / low-medium difficulty** 1) **Publish a Tokenomics FAQ separate from the technical roadmap** - Explicitly answer: buybacks (what revenue, what cadence), “yield vs revenue” distinction, why mintable (CCIP), and what utilities arrive with Jeju. 2) **Create a “Reality check” section** - What Cloud is today vs later (custom models, limits, monetization status). - Reduces speculative interpretations and “unfulfilled promises” narrative. 3) **Monthly transparency post outside Discord** - Mirror critical updates on GitHub/website (requested by DAMONZERA). - Similar approach: many OSS/Web3 hybrids use a public changelog + monthly treasury/product update. --- ### Pain point D: Cloud UX/onboarding uncertainty **Medium-high impact / medium difficulty** 1) **First-run Cloud checklist** - “Upload knowledge → create agent → test chat → deploy → share link” with guardrails (file limits, supported formats). 2) **Context & upload UX improvements** - Show remaining upload quota (50MB), recommended chunking, and automatic conversion tips (PDF → markdown guidance). 3) **Showcase templates** - Provide a few one-click examples: “Book Q&A agent”, “Discord community agent”, “Async productivity agent”. --- ### Pain point E: Developer setup & CI reliability **Medium impact / low-medium difficulty** 1) **Version manager guidance + hard checks** - Add `engines` constraints and CLI preflight checks for Node/Bun versions. 2) **Reduce CI dependency on paid/billed services** - Where feasible, gate Claude-dependent steps behind a label or scheduled workflow; fail gracefully with clear messaging. 3) **“Docs drift” prevention** - Add a docs CI check to detect moved/renamed docs paths (e.g., recurring “Where did packages/docs go?”-type confusion). --- ## 4) Communication Gaps (expectations vs reality) 1) **“Roadmap” interpreted as “tokenomics plan”** - Users ask where value accrual appears; answer: “technical document, not tokenomics” (Kenk). - Improvement: label the roadmap clearly and link a separate tokenomics/value-accrual page from it. 2) **Mintable token misconception** - Users interpret mintability as risk; explanation: CCIP requirement (Odilitime). - Improvement: add a short, plain-language explainer in migration UI: “Mintable ≠ unlimited inflation; it enables cross-chain mechanics under defined controls.” 3) **Cloud capabilities assumed broader than current** - Users ask for custom model hosting and large context ingestion; many features are “soon”. - Improvement: add “Available now / Next / Later” tables directly in Cloud UI and docs. 4) **Repeated “promised feature since summer”** - Mentions of delayed “X” feature (DannyNOR NoFapArc) create credibility drag. - Improvement: maintain a public “Promises ledger” (feature → status → blockers → next update date). --- ## 5) Community Engagement Insights ### Power users / key contributors and their needs - **Odilitime, Borko, Stan, Kenk, Shaw**: repeatedly answering questions; need scalable FAQs and fewer repeated support cycles. - **Serikiki, Hexx 🌐, Omid Sa**: doing frontline migration help + scam prevention; need official tooling and authoritative links to reduce social-engineering risk. - **R0am**: demonstrates advanced “async agent” workflows; could be leveraged as a reference use-case (“async productivity agent” template). ### Common newcomer questions indicating onboarding friction - Migration “0 eligible”, wallet compatibility (Moonshot, Tangem), “why mintable”, “why migration”. - Cloud basics: upload limits, formats, whether custom models are possible. - Dev setup: node/bun versions, outdated docs locations. ### Converting passive users into contributors - Create “micro-contribution” tracks: - Improve migration FAQ translations (Korean exchange users are a notable segment). - Cloud onboarding docs and templates (book-to-agent tutorial). - Security: community-maintained scam-link reporting + moderation playbooks. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord** is high-volume but unstructured; critical issues (migration, scams) are hard to triage and easy to exploit. - **GitHub** has clearer tracking, but daily core repo activity was **0 PRs / 0 issues on Dec 25–26** (signal: feedback may be happening elsewhere, and/or maintainers are bandwidth-limited around migration). ### Improvements to gather structured, actionable feedback 1) **Add an in-product feedback button in Cloud and/or client** - Already aligned with an existing request: “add a user feedback button” (plugin-openai issue #6280 referenced in weekly summary). 2) **Standardize Discord-to-issue pipeline** - A weekly triage where mods convert top repeated Discord questions into GitHub issues/FAQs. 3) **Migration-specific intake form** - Fields: snapshot wallet type, can it connect, can it sign, transaction links; outputs a ticket ID and recommended path. ### Underrepresented segments whose feedback is missing - **Non-Discord users** (explicitly pushed away by impersonation risk). - **Non-exportable wallet users** (Tangem-like) who face unique dead-ends. - **Builders evaluating Cloud as an AI platform** (performance/cost/SLA feedback is minimal compared to token discussion). --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1) **Ship a single canonical Migration Hub page + in-UI eligibility explanations** (reduces the #1 repeated question: “why 0 eligible”, and cuts support/scam surface area). 2) **Implement a verified support model and anti-scam hardening** (official links page, verified accounts list, move sensitive support off Discord where possible). 3) **Publish a Tokenomics/Value Accrual FAQ separate from the technical roadmap** (aligns expectations; reduces recurring debates and “unfulfilled promises” sentiment). 4) **Add Cloud onboarding checklist + clear “Available now / Next / Later” capability matrix** (turns curiosity into successful first deployments). 5) **Developer preflight checks (Node/Bun) + CI resilience changes** (reduces setup friction and prevents avoidable workflow failures like billing-related CI breaks).