# User Feedback Analysis — 2026-03-15 (covering 2026-03-12 to 2026-03-14) ## 1) Pain Point Categorization (Top Recurring Issues) ### 1. Token Migration Transparency & Support (Category: **Documentation / Community**) **Frequency/Severity:** High frequency, high impact. ~**40% of user questions (6/15)** across the period relate to migration status, missed deadlines, or token allocation outcomes. **What users are experiencing:** - Confusion and anxiety about the **ai16z → elizaOS migration**: “What % migrated?”, “What happens to unmigrated tokens?”, “burn vs redistribution?” (Cryptologos; unanswered). - Missed-deadline users asking for exceptions; community response is “migration closed” (abz → sb). - Increased **scam surface area** for late migrators (fake support bot sending users to seed-phrase phishing site). **Users affected most:** Token holders (new and returning), anyone who missed the Feb 4 close, and newcomers who treat Discord as support. --- ### 2. Security Model for Wallet-Enabled Agents (Category: **Technical Functionality / Integration**) **Frequency/Severity:** Medium frequency, critical severity (funds-loss risk). **What users are experiencing:** - A core concern: agents with wallet access can execute harmful transactions without enforcement layers. - Community is filling the gap with external tooling (e.g., **x402Guard**: spend limits, contract whitelists, EIP-7702 session keys; Base + Solana). **Users affected most:** DeFi agent builders, operators deploying autonomous agents with signing authority. --- ### 3. Plugin Initialization / Runtime Architecture Friction (Category: **Technical Functionality / Performance**) **Frequency/Severity:** Medium frequency, high developer pain. **What users are experiencing:** - Identified race condition: `plugin-sql` registers DB adapter as a side-effect in `init()` while plugins initialize in parallel; `plugin-personality` can run before adapter exists. - Workaround in milaidy: manually pre-register `plugin-sql` before `initialize()` (acknowledged as symptom-level fix). - Broader runtime refactor proposal is in-flight, with concern about complexity and breaking changes. **Users affected most:** Plugin authors, contributors integrating infra components, maintainers. --- ### 4. Agent Discovery & Registry Expectations (Category: **Integration / UX/UI**) **Frequency/Severity:** Medium frequency, medium severity; growing importance. **What users are experiencing:** - Discovery is happening via conventions (`skill.md` at domain root) and third-party registries (AIProx / agentskills.io), not via a canonical elizaOS-native flow. - Teams are building orchestration + monetization layers externally: self-registration REST API, rating, multi-rail payments (Lightning/Solana/x402), auto-approver scoring. **Users affected most:** Builders trying to get agents “found,” orchestrator developers, marketplaces. --- ### 5. Prediction-Market Agents Lack Shared Evaluation Targets (Category: **Technical Functionality / Documentation**) **Frequency/Severity:** Lower frequency, medium severity; blocks adoption credibility. **What users are experiencing:** - Milady Prediction aggregates Kalshi/Polymarket/predictdotfun/Limitless and triggers on-chain execution. - Community asks for a **prediction accuracy threshold** (Caesar) but it is **unanswered**, leaving unclear quality bars and risk controls. **Users affected most:** Prediction-market builders, users expecting “actionable data aggregation” rather than entertainment agents. --- ### 6. Token Utility / Value Accrual Messaging Confusion (Category: **Communication / Documentation**) **Frequency/Severity:** Medium frequency, medium severity. ~**20% of questions (3/15)** relate to “what does the token do?” **What users are experiencing:** - Confusion between **Milady token** (meme currency; fees support dev) vs **elizaOS token** (buybacks from Milady cloud profits; no direct utility “yet”). - Users ask “any use case for token holders?” and “does MILADY token have function?”; answers exist but are scattered across Discord. **Users affected most:** Prospective holders, new community members, anyone evaluating economic alignment. --- ## 2) Usage Pattern Analysis (Actual vs Intended) ### How users are actually using elizaOS (observed) 1. **Autonomous, revenue-linked agent services**: “Workflows-as-a-Service” with scheduled pipelines, pay-per-execution, and receipts (lightningprox). 2. **Agent marketplaces/registries**: public REST registries with self-registration, ratings, and payment rails—agents discovering and attempting to register autonomously. 3. **High-risk Web3 automation**: DeFi agents requiring guardrails (x402Guard) rather than simple “wallet plugin + agent.” 4. **Utility over entertainment (emerging)**: prediction-market aggregation with on-chain execution; community explicitly calls this “underrated utility.” 5. **Creative virality**: meme generation plugins (Memelord) used for social posting (X/Twitter demos). 6. **Hardware-bound deployments** (unexpected signal): OpenClaw driving dedicated-hardware purchases in China (“raising a lobster”), implying heavier local compute / always-on expectations than typical agent frameworks assume. ### Intended usage (implied by framework) - A composable open-source agent framework with plugins, integrations, and community-driven extension. ### Emerging feature requests aligned with real usage - Standardized **security policy layer** for wallet actions (spend limits, whitelists, session keys). - Canonical **agent discovery metadata** (beyond ad-hoc `skill.md`), registry interoperability, and trust/rating signals. - First-class **workflow scheduling/orchestration** primitives (cron triggers were mentioned; Wf-a-aS demand suggests expansion). --- ## 3) Implementation Opportunities (Concrete Solutions, Prioritized) ### A) Token migration transparency & support (High impact / Low–Medium difficulty) 1. **Publish a “Migration Postmortem + Final State” page** (docs site + pinned Discord): - % migrated, snapshot height/time, total eligible, total claimed, and explicit policy for unclaimed (burn/treasury/locked). - Include the **1:6 ratio** explanation and a link to on-chain proof where possible. - *Comparable:* Many token projects publish a “claims dashboard” + final report (e.g., ENS-style claim transparency; Optimism airdrop postmortems). 2. **Add an official “Late Migration: Not Possible” support macro + scam warning kit**: - A single canonical statement + list of official support channels; explicitly: “No one will DM you; never share seed phrases.” - *Comparable:* MetaMask and Uniswap communities use pinned anti-phishing runbooks + auto-mod keyword triggers. 3. **Create a lightweight appeal registry (optional)**: - Since a list of affected users is being tracked, formalize it: a form collecting wallet + proof only (no seeds), with a public “no guarantees” disclaimer. - *Comparable:* Gitcoin/airdrops often run a post-claim appeals form with strict criteria. --- ### B) Wallet-agent security model (High impact / Medium difficulty) 1. **Bless and integrate a “transaction policy engine” interface** in core: - Standard hooks: `preSign(tx)`, `simulate(tx)`, `enforce(policy)`, `requireHumanApproval(thresholds)`. - Make x402Guard-style controls pluggable (spend caps, contract allowlist, rate limits). - *Comparable:* OpenZeppelin Defender + “relayer policies”; Permit2 / session-key patterns in smart-wallet ecosystems. 2. **Provide a reference “Safe DeFi Agent” template**: - Defaults: no raw signing, session keys only, allowlist-first, per-action limits, and mandatory simulation for swaps/transfers. - Include Base + Solana examples (matching x402Guard’s current scope). 3. **Security documentation: threat model + deployment checklist**: - Explicitly document “what can go wrong” with walleted agents and recommended mitigations. --- ### C) Plugin initialization race conditions / runtime refactor (High impact / Medium–High difficulty) 1. **Move from side-effect registration to explicit dependency injection**: - Make DB adapter a required constructor arg (as proposed) and enforce plugin dependency graphs. - *Comparable:* NestJS / Fastify plugin ecosystems emphasize explicit registration order and dependency injection over hidden side-effects. 2. **Deterministic initialization order + plugin dependency declaration**: - Add `requires: ["sql-adapter"]` metadata; runtime resolves a DAG and initializes sequentially where needed. - Provide tooling to detect cycles/missing deps at startup with actionable errors. 3. **Add a “plugin init contract” test harness**: - CI test to run randomized init ordering to surface race conditions early (chaos-style ordering). - *Comparable:* Kubernetes controllers and distributed systems often use fuzz/chaos to catch ordering bugs. --- ### D) Agent discovery & registry interoperability (Medium impact / Low–Medium difficulty) 1. **Standardize `/.well-known/agent.json` (or similar) alongside `skill.md`**: - Machine-readable capabilities, endpoints, auth, pricing rails, and versions. - Keep `skill.md` for human-readable discovery; use JSON for automation. - *Comparable:* OAuth `.well-known`, OpenAPI descriptors, AI plugin manifests. 2. **Publish a canonical “Discovery & Registry Integration” doc**: - Examples: agentskills.io, AIProx registry endpoints (`/api/agents/register`, `/api/agents`), rating signals, and safety considerations. 3. **Create an official registry schema + validation tool**: - CLI to validate manifests and simulate registration. --- ### E) Prediction-market agent quality bars (Medium impact / Low difficulty) 1. **Define evaluation metrics and target thresholds**: - Brier score calibration, hit rate vs baseline, confidence thresholds for on-chain action. - Publish a “minimum bar” for executing transactions based on predictions. - *Comparable:* Forecasting communities (Metaculus-style) use calibration + scoring rules to set trust levels. 2. **Add a backtesting harness and public leaderboard**: - Run historical tests against Kalshi/Polymarket outcomes; display performance transparently. 3. **Add safety gates for execution**: - Require multi-source consensus or minimum liquidity/market depth before acting. --- ## 4) Communication Gaps (Expectations vs Reality) ### Recurring mismatches - **“Migration support exists” vs reality (“migration closed”)**: Users keep asking for late migration; scam attempts exploit this gap. - **Token utility expectations vs current state**: Users ask for direct utility; response is “buybacks via cloud profits,” but this is not centralized in one canonical explainer. - **“Agent can trade” vs “agent can trade safely”**: Users are building/considering DeFi agents, but core docs don’t visibly foreground wallet-risk and enforcement patterns. - **Prediction agents expected to be “accurate enough”** without any stated threshold—users request targets, none provided. ### Specific improvements - Pinned Discord messages in relevant channels: - “Migration is closed (Feb 4, 2026). Official links only. No DMs.” - “Tokenomics: elizaOS vs Milady in one paragraph + link.” - Add an onboarding “First secure agent” guide that explicitly covers wallet signing risk and recommended mitigations. - Publish a “Roadmap reality check” section for Milady app timeline and what “launch” includes (MVP vs full features). --- ## 5) Community Engagement Insights ### Power users / key contributors observed - **Odilitime**: de-facto product comms + tokenomics clarifications + moderation; also proposing core runtime refactor. - **lightningprox**: building registry/orchestration, implementing `skill.md`, pushing pay-per-exec workflows; needs standard discovery + official hooks. - **dzik pasnik**: security-focused builder (x402Guard); needs early testers, clear plugin security interfaces. - **ElizaBAO**: prediction-market integration; needs evaluation framework + thresholds. - **Meme Broker**: plugin author (Memelord); benefits from clearer plugin submission/discovery pathways. ### Newcomer questions indicating onboarding friction - “I missed migration, can you help?” (abz) → suggests onboarding/support flows still route to Discord without strong self-serve resolution. - “What does token do?” (multiple users) → indicates tokenomics doc needs to be easier to find and shorter. - “Is support bot legit?” (scam incident) → indicates need for stronger trust signals for official support. ### Converting passive users into contributors - Create “Good first issues” tied to the week’s pain points: - Docs PR: migration final-state page, tokenomics explainer, security checklist. - Tooling PR: `.well-known/agent.json` schema + validator. - Run short “community test drives”: - x402Guard early tester cohort (DeFi builders) with a defined checklist and feedback form. - Prediction harness hack session with a shared dataset and scoring. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness (observed) - **Discord is high-velocity but low-structure**: many critical questions remain unanswered publicly (e.g., migration %; fate of unclaimed tokens; prediction threshold). - **GitHub activity exists (weekly summary)** but user-impact feedback (token migration outcomes, scam reports, runtime pain) is not consistently captured as issues/FAQs. ### Improvements for more structured, actionable feedback 1. **Add a weekly “Feedback Intake” form** (docs site + Discord pinned): - Required fields: category, severity, reproducibility, links/screenshots, expected vs actual. 2. **Create GitHub Discussion templates** for: - Tokenomics/migration Qs (keeps answers canonical) - Security reports (with safe disclosure guidance) - Plugin/runtime architecture proposals (tracks decisions) 3. **Discord automation**: - Auto-mod triggers for “migration,” “seed phrase,” “support bot,” responding with official links and scam warnings. 4. **Underrepresented segments** - Non-crypto developers using elizaOS for SaaS automation (signals exist via workflow orchestration, but their feedback is not directly present). - Chinese OpenClaw users driving hardware purchases (major adoption signal, but no direct feedback captured). Consider a localized survey or partner channel. --- ## Prioritized High-Impact Actions (Next 1–2 Weeks) 1. **Publish migration transparency report + explicit unclaimed-token policy** (answer Cryptologos’ unanswered questions; reduce scam risk). 2. **Ship a “Walleted Agent Security” guide + core policy hook spec** (align with x402Guard; prevent funds-loss incidents). 3. **Implement runtime/plugin dependency ordering (DAG) or explicit adapter injection** to eliminate init race conditions (unblocks plugin authors). 4. **Standardize discovery metadata (`skill.md` + `.well-known/agent.json`) and document registry integration** (supports actual marketplace/orchestration usage). 5. **Define prediction accuracy metrics + execution safety gates** for Milady Prediction (enables credible “utility agents” and safer on-chain actions).