# Intel — 2026-04-23 (based on 2026-04-22 aggregated signals)

## 1) Data Pattern Recognition

### Development velocity & trend
- **Repo throughput (month-to-date snapshot provided):** `elizaos/eliza` recorded **297 new PRs / 257 merged**, **46 new issues**, **48 active contributors** (Apr 1–May 1 window snapshot). Indicates **high shipping velocity** with strong maintenance/ops load.
- **Work mix (qualitative):**
  - Heavy **stability + infra hardening**: dependency hardening across Rust/Python/TS, CI pipeline restoration (“Milady CI”), auth migration to Steward, billing classification fix.
  - Parallel **capability expansion**: local inference hub/provider switcher + local probes (in progress), plugin ecosystem growth (registry additions), agent monetization direction (v3 “revenue generation” narrative).
- **Critical pipeline friction:** CI/CD misconfiguration in `elizaos-plugins/registry` PR **#346** (OIDC token permissions). This is a **config bottleneck** that blocks external contributions and slows plugin ecosystem scaling.

### Community engagement patterns
- **Engagement concentration:** discussion dominated by **non-technical risk** (lawsuit comms + token migration) rather than product value; dev channel still active on migration planning + plugins.
- **Official comms gap:** ElizaOS X account **inactive ~1 month** (community-reported). This correlates with:
  - Rising accusations (“fraud”, “dumping”)
  - Requests for exchange-risk mitigation (“delisting” concerns)
  - Repeated questions that should be handled by a canonical statement/FAQ

### Feature adoption & ecosystem signals
- **Payments/monetization tooling demand:** strong signal from LemonCake plugin launch—directly targets a real blocker for autonomous agents: **paywalled APIs without exposing keys/cards**.
  - Notable adoption friction reducer: “**one-line** integration” for v2.
- **Marketplace / paid work execution path forming:** Elisym plugin + LemonCake both point toward a near-term ecosystem pattern: **agents that can earn, pay, and account for spend**.

### Pain point correlation across channels
| Pain point | Where it surfaced | Correlated risks |
|---|---|---|
| Silence around lawsuit | discussion | sentiment degradation, exchange concerns, rumor amplification |
| Token migration closed / late holders | discussion | ongoing support burden, reputational drag, scam susceptibility |
| Wallet drainers / phishing | coders + prior migration-related scams | direct user losses, brand harm, support load |
| Versioning confusion (0.x/1.x/2.x mapping to v1/v2/v3) | discussion | onboarding friction, misaligned expectations for “v3 readiness” |
| Discord auto-deleting posts without audit logs | discussion | community ops overhead, loss of key announcements, trust issues |

---

## 2) User Experience Intelligence

### Feedback categorized by impact + theme

**High impact (trust & safety / existential)**
1. **Lawsuit communication void**
   - Users explicitly request an official statement; fear of “exchange delisting” from prolonged silence.
   - Current moderator explanation (“no access to X; lawyers advise silence”) is not sufficient as a UX answer because it doesn’t provide a stable reference point or next update time.

2. **Scams & wallet drainers**
   - Confirmed incident: user lost **100,000 AI16Z tokens** via `bulkdao.co/allocation`.
   - Pattern: token migration / support confusion creates a fertile scam environment (“fraudulent support tickets” previously; wallet drainer now).

**Medium impact (builder experience / adoption)**
3. **Version stability + naming confusion**
   - Builders ask: “Is v2.x/v3 stable enough?” and “Why not tag v3 as v3?”
   - Even if the code is ready, the *perceived* readiness is undermined by confusing semantic versioning narratives.

4. **Token migration late holders**
   - Migration window closed; “waitlist” offered as a longshot.
   - UX issue: lack of clear “what now” pathway for late/self-custodied holders fuels anger and extends support threads.

**Low–medium impact (ops friction)**
5. **Discord message auto-deletion without logs**
   - Users can’t post links; moderators manually repost.
   - Creates a “shadow moderation” perception even if it’s a Discord issue.

### Usage patterns vs intended design
- **Intended:** community uses Discord for builder onboarding + plugin discovery.
- **Actual:** Discord becomes a **crisis support + rumor arbitration** channel (lawsuit/migration/scams), consuming moderator time and displacing technical onboarding.

### Implementation opportunities (near-term UX wins)
- Convert repeated Qs into **single canonical artifacts**:
  - “Legal communications policy during active litigation” (what can be said + cadence)
  - “Migration status” (closed, what options exist, what not to do, scam warnings)
  - “Versioning guide” (mapping, stability expectations, recommended starting points)

### Community sentiment tracker (qualitative)
- **Polarized sentiment**:
  - Negative: fraud/dumping allegations, “project viability” doubts.
  - Counter-signal: builders showcasing real traction (e.g., agent achieving **9M impressions / 3.3K followers** prior to bans) + ongoing GitHub velocity cited by core devs.
- Net: technology credibility is holding, but **narrative risk** is increasing.

---

## 3) Strategic Prioritization (Impact × Risk × Dependency)

### Priority 0 — Trust & Safety stabilization (blockers to growth)
1. **Publish an “Official Minimum Statement” + cadence during litigation**
   - **User impact:** Very high (reduces panic, delisting fear, rumor load).
   - **Tech risk:** Low.
   - **Primary dependency:** Legal review.
   - **Recommendation:** Post a pinned Discord announcement + GitHub discussion + website page mirror; X posting if access allows, otherwise state explicitly where “official updates” will live.

2. **Security response: anti-phishing playbook + pinned warnings**
   - **User impact:** Very high (prevents losses).
   - **Tech risk:** Low–medium.
   - **Dependency:** Moderator workflow + documentation.
   - **Recommendation (actionable):**
     - Create a **“Known Scams”** page including `bulkdao.co/allocation`.
     - Add a Discord **automod rule** to warn on suspicious domains (even if deletion logs are flaky).
     - Add a lightweight **incident intake** form for reporting scam accounts/links.

### Priority 1 — Builder conversion & ecosystem scaling
3. **Unblock plugin registry CI (OIDC permissions)**
   - **User impact:** High (unblocks external plugin PR merges).
   - **Tech risk:** Low (config change).
   - **Dependency:** Repo admin permissions.
   - **Recommendation:** Patch workflow permissions (`id-token: write`) + validate `github_token` scopes; add a CI preflight check so future PRs fail with a clear message.

4. **Clarify versioning & stabilize the “start here” path**
   - **User impact:** High (reduces onboarding friction).
   - **Tech risk:** Low.
   - **Dependency:** Docs + release communication.
   - **Recommendation:**
     - Publish a **version matrix**: “Framework generation name” vs “npm tags” vs “git tags” vs “stability (alpha/beta/stable)”.
     - Provide a single recommended builder target: e.g., “v2 alpha for builders; stable ETA TBD” (only if the team can commit to a window).

### Priority 2 — Monetization narrative (convert credibility into usage)
5. **Productize “agent commerce” stack: Elisym + LemonCake + escrow/reputation**
   - **User impact:** Medium–high (gives builders a real path to revenue).
   - **Tech risk:** Medium (payments + accounting + chain integrations).
   - **Dependencies:** v2 stability line + registry health + documentation.
   - **Recommendation (resource allocation):**
     - Allocate a small “commerce strike team” (1 core dev + 1 DX/docs) to:
       - Publish a reference demo: “Agent completes task → calls paid API via LemonCake → produces receipt → optionally sells capability via Elisym”.
       - Define minimal standards: spend caps, revocation, audit receipts, idempotency.

### Priority 3 — Reduce operational drag
6. **Investigate Discord auto-deletion issue**
   - **User impact:** Medium (prevents lost posts/links).
   - **Tech risk:** Unknown (platform-level).
   - **Dependency:** Discord settings/audit, automod, bots.
   - **Recommendation:** Run an experiment matrix (new accounts vs old, link types, channels, roles). If irreproducible, move critical comms to an announcements-only channel with restricted posting and mirrored web/GitHub posts.

---

## Quantitative Summary (today’s key counts from inputs)
- **Security loss reported:** 1 confirmed wallet drainer incident, **100k tokens** lost (AI16Z).
- **Major recurring community topics:** 5 (lawsuit comms, migration closed, version stability/naming, phishing/scams, Discord deletions).
- **New ecosystem capability signal:** 1 major plugin launch (LemonCake payments) + 1 marketplace integration emphasis (Elisym porting path).
- **Dev velocity (provided snapshot):** **297 PRs opened / 257 merged**, **48 contributors**, **46 issues opened** in the current monthly window snapshot.

---

## Immediate Next Actions (24–72h)
1. **Draft + legal-review + publish** “Minimum Statement & Update Cadence” (Discord pinned + GitHub/website mirror; X if possible).
2. **Fix registry CI permissions** for OIDC token fetching; confirm PR #346 can pass end-to-end.
3. **Publish security bulletin**: bulkdao drainer link + “how to verify official links” + “no DMs/support tickets” policy.
4. **Release a one-page “Versioning & Stability Guide”** answering the exact repeated questions (v2 alpha, v3 naming convention, recommended starting path).
5. **DX follow-through:** LemonCake integration doc snippet in official docs + a short example agent showing spend-capped paid API calls with receipts.