## User Feedback Analysis — 2026-04-26 (based on 2026-04-23 to 2026-04-25 sources)

### Data notes & sample size
- Sources in this snapshot: **3 Discord daily digests (Apr 23–25)** plus **aggregated engineering changelog signals (Apr 25)**.
- We observed **6 distinct high-signal “friction events”** in community discussion (questions/concerns with implied product gaps): HTN uncertainty, degenai status clarity, governance/foundation status confusion, payment rails risk, Discord roles/layout ambiguity, and scam/spam exposure. Percentages below are based on this small set (directional only).

---

## 1) Pain Point Categorization (Top recurring 5–7)

### 1) Documentation — Planning/HTN concepts are unclear (high severity, recurring in technical chat)
**Evidence**
- Apr 25 coders: multiple questions and uncertainty:
  - “What is HTN?” (odilitime asked in-context)
  - “Is it true ElizaOS v2 added HTN for agent goal decomposition?” (thirti.eth; unanswered/uncertain)
  - “Any similarity to HTM? Or more like LISP?” (uplink2501; unanswered)
- This accounts for **~33% (2/6)** of friction events (multiple questions clustered around one missing doc area).

**User impact**
- Builders hesitate to adopt v2 “alpha” capabilities when they can’t confirm what exists vs what’s aspirational.
- Terminology confusion (HTN vs HTM vs “multistep planning”) slows contributor alignment and can cause incorrect implementations.

**Concrete solutions (prioritized)**
1) **High impact / Low–Med difficulty:** Add a “Planning in ElizaOS (v2)” doc page with:
   - What exists *today* (HTN-lite? planner actions? reflection evaluator? task decomposition?) and what does not.
   - A minimal example: “goal → decomposed tasks → triggers/steps → execution → synthesis back to room.”
   - Tie to code entrypoints (e.g., planner/action handling, swarm synthesis plumbing fixes referenced in Apr 25 engineering summary).
   - Similar projects: **LangChain / LlamaIndex** “concepts” pages that separate *architecture* from *API reference* and include “When to use X vs Y” sections.
2) **High impact / Medium difficulty:** Publish an **official “HTN-lite → full HTN” roadmap note** (mirroring thirti.eth/Claude suggestion) with acceptance criteria:
   - “Replace hand-coded decomposition with LLM planning while keeping triggers/steps stable.”
   - Risks: determinism, tool safety, eval requirements.
   - Similar approach: **Temporal** and **Airflow** docs for “incremental adoption” (start simple workflows, then advanced orchestration).
3) **Medium impact / Low difficulty:** Add a **Discord pinned FAQ** in `#coders`:
   - “HTN vs planner vs triggers”
   - Links to docs and “known unknowns”.

---

### 2) Communication / Community — Governance & “who runs what” is confusing (high severity)
**Evidence**
- Apr 23: users assumed “Eliza Labs transition” implied dissolution; odilitime clarified the foundation remains funded and responsible for the token.
- Proposal for structured forum/leadership transparency from quanteliza; steering group access offered by odilitime.
- **~17% (1/6)** of friction events, but high leverage because it affects trust and contributor retention.

**User impact**
- Contributors don’t know where decisions happen (token, website/social, working groups), which reduces willingness to invest time.
- Repeated clarification burdens core maintainers.

**Concrete solutions (prioritized)**
1) **High impact / Low difficulty:** Create a **single “Project Governance & Roles” page**:
   - Foundation scope (token responsibility), maintainer roles, working groups, decision process.
   - Link to how to join steering/marketing groups.
   - Similar projects: **Rust (teams), Kubernetes (SIGs)** provide clear ownership maps and escalation paths.
2) **High impact / Medium difficulty:** Stand up a **structured forum (Discourse/GitHub Discussions)** for proposals and decisions (mirroring quanteliza’s request):
   - “RFC” tags: Tokenomics, Plugins, Core runtime, Docs.
   - Monthly “decision log” summary.
3) **Medium impact / Low difficulty:** Add a **public working-group directory** (Discord channel directory + repo doc):
   - What each WG owns, meeting cadence, how to contribute.

---

### 3) Integration / Payments — Cross-border payment risk + desire for agent monetization rails (medium–high severity, emerging)
**Evidence**
- Apr 23: concern about **USDC freezing risk** for cross-border agent operations (arkchain).
- Lemoncake03027 offered an alternative M2M payment infrastructure (spend-capped JWTs + kill switch) and potential plugin integration.
- Apr 24: igor.peregudov demoed paid agent services via **Nostr discovery + Solana settlement** (@elisym/plugin-elizaos-elisym).
- Apr 24: token utility proposal: pay protocol fees in USDC or ELIZAOS, discounts, buyback/burn; odilitime noted x402 enabling $elizaOS/$DegenAI as “lowest-hanging fruit”.
- Payments-related friction is **~17% (1/6)** in direct complaints, but appears as a strong “build direction” theme across days.

**User impact**
- Builders want monetization, but lack clarity on recommended rails (x402 vs direct chains vs escrow vs third-party).
- Compliance/freeze-risk concerns limit adoption in certain geographies.

**Concrete solutions (prioritized)**
1) **High impact / Medium difficulty:** Publish a **Payments Integration Guide** with a decision tree:
   - x402 pay-per-call vs escrow vs subscriptions
   - Stablecoin risks and mitigation (multi-rail, non-custodial options, spend caps)
   - Examples: Nostr+Solana flow from @elisym demo; Base USDC x402 API example (DeepBlue issue earlier in month).
   - Similar projects: **Stripe docs** style “choose your integration path”.
2) **High impact / Medium difficulty:** Define an **official “Payments Provider Interface”** for plugins:
   - Standard hooks: quote → authorize → settle → receipt → refunds/disputes.
   - Encourage multiple backends (Solana, EVM, JWT-capped custodial, etc.).
3) **Medium impact / Low difficulty:** Add a **security note**: recommended defaults for agent commerce:
   - spend limits, kill switch patterns, audit logs/receipts (aligns with community’s scoped-authority interests).

---

### 4) Technical Functionality — Reliability bugs leak into user-facing behavior (high severity; evidenced by fixes)
**Evidence (engineering summary Apr 25)**
- Fixed: credential conflicts between CLI and OAuth; scheduler task leaks; rename propagation; Telegram poller duplication; planner action handling for reliable swarm synthesis; prevention of “internal mechanism leaks” in agent replies.
- These fixes imply users were experiencing:
  - Wrong auth status / confusing “connected” states
  - Background task accumulation
  - Duplicate Telegram instances
  - Agents exposing internal machinery in replies
  - Swarm synthesis not reliably posting outcomes
- **~17% (1/6)** of friction events are directly reported in chat, but the shipped fixes suggest broader hidden pain.

**User impact**
- Trust degradation: agents that “double-run” or leak internals appear unsafe/unpolished.
- Cost/perf issues: leaks and retries can increase token usage; scheduler leaks degrade long-running deployments.

**Concrete solutions (prioritized)**
1) **High impact / Medium difficulty:** Add **runtime health diagnostics** surfaced to developers:
   - “Active pollers by plugin”, “scheduled tasks count”, “duplicate instance detection”, “auth source (CLI vs OAuth)”.
   - Similar projects: **Home Assistant** and **Kubernetes** surface “controllers running / reconcile loops / health”.
2) **High impact / Low–Med difficulty:** Expand **in-repo “known failure modes” playbook**:
   - Symptom → likely cause → fix (e.g., duplicate Telegram poller, auth mismatch).
3) **Medium impact / Medium difficulty:** Add **soak tests** for long-running agents:
   - scheduler leak detection, plugin deregistration, and repeated rename/config cycles.

---

### 5) Community / Safety — Scam/spam exposure in Discord (medium severity, high reputational risk)
**Evidence**
- Apr 25: suspicious message by ramson813 offering “$400 in Solana to anyone in need” (flagged as likely scam).
- **~17% (1/6)** of friction events.

**User impact**
- Newcomer trust drops quickly when scam content appears in official channels.
- Increases moderation burden.

**Concrete solutions (prioritized)**
1) **High impact / Low difficulty:** Enable/strengthen **Discord AutoMod + anti-scam rules**:
   - Block common solicitation patterns (“send wallet”, “free SOL”, etc.), rate limits for new accounts.
   - Similar communities: many OSS Discords use **AutoMod + verification gating** for posting links/solicitations.
2) **Medium impact / Low difficulty:** Add a **“Report scam”** lightweight workflow:
   - One command/button, plus a pinned “Never send funds” notice.
3) **Medium impact / Medium difficulty:** Introduce **trust levels** for posting in high-traffic channels:
   - Time-in-server + role + GitHub-linked accounts.

---

### 6) Integration / Product Comms — $degenai update status lacks specifics (low–medium severity, frequent “status pings”)
**Evidence**
- Apr 25: “Any work being done for $degenai?” (jack1000x_98528). Response: “framework update in progress” without details.
- **~17% (1/6)** of friction events.

**User impact**
- Users don’t know whether to build against degenai-related surfaces or wait.
- Repeated questions consume maintainer time.

**Concrete solutions (prioritized)**
1) **High impact / Low difficulty:** Maintain a **public “What’s shipping this week” changelog** (even lightweight):
   - “In progress / Next / Done” for degenai-related work.
2) **Medium impact / Low difficulty:** Add a **single source of truth** doc section: “Projects using ElizaOS (degenai, etc.)” with current status and links.
3) **Medium impact / Medium difficulty:** Tag GitHub issues/PRs with **`degenai`** and auto-generate a status page.

---

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

### Observed real usage (from feedback)
1) **Agents as paid service providers / agent-to-agent commerce**
   - @elisym plugin demo: Nostr discovery + Solana settlement; agent sells “trending GitHub repos” service to another agent (Claude desktop).
2) **Builders evaluating “alpha/v2” planning primitives for autonomy**
   - Discussion on HTN and upgrading HTN-lite → full HTN.
3) **Operational deployments across jurisdictions**
   - Payment freeze risk concerns indicate real intent to run agents internationally with real funds.
4) **Community organizing for continuity**
   - Steering group, working groups, and social/website operations discussions show the community acting as co-maintainers of the ecosystem.

### Gaps vs intended positioning
- Intended: “framework is composable; docs guide you.” Observed: users rely on Discord Q&A to confirm if features exist (HTN, degenai work, governance reality).
- Intended: “plugins enable integrations.” Observed: rapid emergence of **monetization/payment** as a primary “north star” use case, requiring clearer blessed interfaces and security posture.

### Feature requests aligning with usage
- **Token utility and fee payments** (USDC or ELIZAOS, discounts, buyback/burn) aligns with monetized agent services.
- **x402 routes for paid plugin endpoints** (work in progress) aligns with pay-per-call services.
- **M2M payment infra plugin integration** aligns with autonomous agents needing constrained spend + kill switch.

---

## 3) Implementation Opportunities (by major pain point)

### A) Planning/HTN documentation & capability clarity
- Ship docs + minimal example + “truth table” of what’s implemented in v2 (impact: high; difficulty: low–med).
- Add roadmap/ADR for HTN-lite → full HTN with test/eval requirements (impact: high; difficulty: med).
- Pin Discord FAQ + link to docs (impact: med; difficulty: low).

### B) Governance clarity & decision transparency
- Publish governance page + working group directory (impact: high; difficulty: low).
- Launch RFC process in GitHub Discussions/Discourse (impact: high; difficulty: med).
- Monthly decision log (impact: med; difficulty: low).

### C) Payments & monetization rails
- Payments guide + interface standard (impact: high; difficulty: med).
- Reference plugin(s): “x402 paid route template”, “Solana escrow template”, “spend-capped JWT adapter” (impact: high; difficulty: med–high).
- Security defaults checklist for commerce (impact: med; difficulty: low).

### D) Reliability and “polish” issues that surface as trust problems
- Developer-facing health panel/CLI (`eliza doctor`) for pollers/tasks/auth sources (impact: high; difficulty: med).
- Soak tests for scheduler leaks + duplicate pollers (impact: med; difficulty: med).
- Expand “known failure modes” docs (impact: med; difficulty: low).

### E) Discord safety (scam/spam)
- AutoMod + posting restrictions for new users (impact: high; difficulty: low).
- Fast report workflow + pinned warnings (impact: med; difficulty: low).

---

## 4) Communication Gaps (expectations vs reality)

1) **“Does v2 have HTN?”**
   - Expectation: it’s a defined feature.
   - Reality: community members themselves expressed uncertainty and asked to “verify accuracy” (thirti.eth).
   - Improvement: documentation that clearly separates *current implementation* from *planned*.

2) **“Is the foundation gone?”**
   - Expectation: transition = dissolution.
   - Reality: foundation still funded and token-responsible (odilitime clarification).
   - Improvement: prominent governance/continuity statement.

3) **“What’s happening with $degenai?”**
   - Expectation: a trackable roadmap/status.
   - Reality: only a brief confirmation of “framework update” without details.
   - Improvement: lightweight status page + tagged PRs/issues.

4) **“Which payment rail is ‘the’ way?”**
   - Expectation: there is an endorsed pattern.
   - Reality: multiple parallel proposals (Nostr+Solana marketplace; x402; alternative M2M infra; token fee model) with no consolidated guidance.
   - Improvement: a recommended integration matrix and security baseline.

Recurring questions indicating onboarding gaps
- “What is HTN?” and comparisons to HTM/LISP indicate missing conceptual onboarding for planning/orchestration.
- Governance/roles questions indicate onboarding for contributors beyond code (ops/marketing/web) is under-defined.

---

## 5) Community Engagement Insights

### Power users / key contributors and their needs (from this snapshot)
- **odilitime**: central responder; needs fewer repeated status questions → benefits from public status/docs; also engaged in payments/x402 enablement.
- **quanteliza**: pushing token utility design + organizational structure; needs an RFC forum and decision pipeline.
- **igor.peregudov**: building monetization marketplace plugin; needs stable payment/plugin interfaces and official guidance to reduce integration risk.
- **thirti.eth**: driving planning/HTN discussion; needs authoritative confirmation of what’s implemented and where to contribute.
- **Lemoncake03027**: offering M2M payment infra; needs a clear plugin integration pathway and requirements.

### Common newcomer questions (signals)
- Status pings (“Any work being done for $degenai?”)
- Concept clarification (“What is HTN?”, “Does v2 really have it?”, “HTN vs HTM?”)

### Converting passive users into contributors
- Add “good first issue” bundles around documentation gaps:
  - “Planning glossary + diagrams”
  - “Payments integration guide”
  - “Governance page”
- Provide a structured intake: “Join a working group” + small starter tasks (triage, doc fixes, examples).

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- Discord is effective for rapid Q&A, but:
  - Answers are ephemeral (same questions repeat).
  - Technical uncertainty persists when no canonical doc exists.
  - Safety risks (scam) can pollute channels.

### Improvements for more structured, actionable feedback
1) Add a **weekly “UX friction” intake form** (short, structured):
   - “What were you trying to do?” “Where did you get stuck?” “Logs/screenshots” “Repo/version”.
2) Introduce **Discord-to-GitHub capture**:
   - A bot command that turns a thread into a prefilled GitHub issue/discussion with links.
3) Create a **taxonomy for feedback tags** (docs/planning/payments/auth/plugins/runtime) and require one tag per report.

### Underrepresented segments (missing feedback)
- **Non-Web3 / non-payments** users: most discussion centers on tokens and agent commerce; need explicit outreach to builders using ElizaOS for non-crypto automation.
- **New self-hosters**: implied by reliability fixes (auth conflicts, scheduler leaks), but few direct narratives—add prompts asking about install/upgrade/deploy pain.

---

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

1) **Publish “Planning in ElizaOS v2” documentation (HTN/planner/triggers) + pinned Discord FAQ**  
2) **Create a public “Governance & Working Groups” page + lightweight decision/RFC process (GitHub Discussions or Discourse)**  
3) **Consolidate payments guidance: “Payments Integration Guide” + standard payments provider interface for plugins (x402, Solana/EVM, spend caps)**  
4) **Ship an `eliza doctor` health check (pollers/tasks/auth-source diagnostics) to prevent recurring reliability confusion**  
5) **Harden Discord safety: AutoMod + new-account restrictions + scam reporting workflow**