# ElizaOS Intel — 2026-01-31

## 1) Data Pattern Recognition

### Development velocity & trend (GitHub, Jan-to-date)
- **Repo: elizaos/eliza (2026-01-01 → 2026-02-01 window)**  
  - **PRs:** 38 opened / **22 merged** (**58% merge rate**)  
  - **Issues:** 100 opened / **54 closed** (**54% closure rate**)  
  - **Contributors:** **31 active**  
  - **Code churn:** **+25,706 / -8,753** across **269 files**; **379 commits**
- **Trend signal:** High throughput with significant churn and large in-flight branches (e.g., v2.0.0 mega-PR). This increases regression probability unless QA automation improves in parallel.

### QA / reliability signals (cross-channel)
- Recurring theme: **“breakages” in 1.x vs 2.x aspirations**, and an explicit call from core devs to **raise integration test coverage for v2**.
- **Known regressions impacting dev UX**
  - **Develop branch:** provider selection failing in **one-shot mode** (critical runtime regression).
  - **Eliza 1.7.2:** action callback ordering reversed and structured return omitted (breaks custom plugin workflows).
  - **Plugin install friction:** module resolution issues (e.g., `@elizaos/plugin-web-search`), and embeddings provider inconsistency (OpenRouter embeddings unreliable for some users).

### Community engagement patterns (Discord, last 3 days)
- Discussion load concentrated around:
  1) **Token migration & eligibility problems** (multiple reports of “0 eligible” despite long-held tokens; plus 429 errors).
  2) **Security/scams** (active impersonation of support; at least one reported wallet drain).
  3) **Competitive/product gaps** (Moltbot/OpenClaw + Moltbook; Eliza lacking mobile + voice).
  4) **Sustainability/finances** (runway stated as **8 months**; uncertainty about stablecoin vs volatile holdings).

### Feature adoption / usage signals vs intended design
- Users are treating ElizaOS as both:
  - a **framework** (plugins, embeddings, routing, workflows like n8n), and
  - an **end-user assistant** benchmarked against Clawdbot/Moltbot (voice, mobile footprint, social/calendar integrations).
- Adoption blockers cluster around **onboarding correctness**, **migration UX**, and **runtime reliability** rather than missing “new features”.

---

## 2) User Experience Intelligence

### Feedback taxonomy (theme × impact)

**A. Security & Trust (Critical impact, urgent)**
- Reported incident: user hacked after opening a “ticket”; funds stolen from Phantom/Metamask.
- Repeated scam pattern: “support team” friend requests / DMs; moderators reiterating official support never DMs.

**B. Migration UX & Platform Reliability (Critical impact, urgent)**
- Migration portal issues:
  - “**0 eligible**” shown for wallets claiming holdings since late 2024.
  - “**429 Too many requests**” on page load (even before wallet connect).
- Outcome risk: direct loss of trust + churn + support load spike before deadlines.

**C. Core Runtime / Dev Experience (High impact)**
- Regressions:
  - Provider selection failure in one-shot (develop branch).
  - Callback message ordering bug in 1.7.2 breaking expected action callback sequencing.
- Tooling direction: community aligned on building a **repeatable plugin test framework** (plugin-n8n-workflow cited as pattern).

**D. Product Positioning / Comms (High impact, reputational)**
- Token utility confusion persists despite partial explanations (gas for Jeju, currency in products, buy-backs from CC rails).
- Allocation controversy (team 40% narrative) continues to surface; unanswered vesting/address questions amplify distrust.
- “We’re doing big brain stuff…” sentiment indicates a widening gap between build narrative and user comprehension.

**E. Competitive Feature Gaps (Medium→High impact, strategic)**
- Clear asks: **mobile presence** + **voice interface** to compete with Moltbot/Clawdbot.
- Opportunity: Moltbot users face **API cost pressure** and **Anthropic TOS bans** for non-human usage—opening a wedge for ElizaOS if onboarding + integrations are smooth.

### Sentiment & risk indicators
- Sentiment is **bifurcated**:
  - Builders are optimistic about v2, n8n automation, routing ideas.
  - Token holders/users show **high anxiety** (runway, migration failures, security scams, token utility clarity).
- Trust is currently most threatened by **(1) scams**, **(2) migration failures**, **(3) unclear economics/vesting**.

---

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

### P0 — Stabilize Trust & Access (immediate, 0–7 days)
1) **Migration Portal Reliability Sprint**
   - Scope:
     - Fix/mitigate **429 on page load** (rate-limit config, CDN/WAF rules, caching, bot filtering, preconnect flows).
     - Diagnose “0 eligible” cases with reproducible wallet archetypes (LP-held, multi-wallet, post-snapshot buys, Solflare/Phantom edge cases).
     - Add self-serve **eligibility debugger** UI: “why you may see 0 eligible” with automatic checks (LP position detection, snapshot block/time, token contract verification).
   - Success metrics:
     - Reduce migration tickets per day by **>50%** within a week.
     - 429 incidence < **1%** of sessions.
     - Eligibility mismatch resolution SLA < **24h** for verified snapshot proofs.

2) **Anti-Scam Hardening (Support + UX)**
   - Changes:
     - Prominent in-portal banner: “Support will never DM you” + official staff list + link to verification channel.
     - Ticket flow: add **anti-phishing interstitial** requiring user confirmation before displaying any “next steps”.
     - Publish a single canonical “Official Links / No DM” page and pin it across channels.
   - Success metrics:
     - Reduce scam reports/week; track via a dedicated “scam-report” tag.

3) **Runway Clarity (Ops + Comms)**
   - Provide a minimal disclosure statement:
     - confirm runway: **8 months**
     - clarify treasury exposure bands (e.g., % stablecoins vs volatile) without over-disclosing sensitive details.
   - Rationale: reduces rumor-driven volatility in community sentiment.

### P1 — Reduce Regression Rate & Developer Pain (1–3 weeks)
4) **Fix core regressions blocking builders**
   - Develop branch: **one-shot provider selection bug** (ship hotfix + add regression test).
   - Eliza 1.7.2: **callback ordering + missing structured return** (ship patch release; add deterministic ordering test).
   - Success metrics:
     - Drop “develop is broken” reports to near-zero.
     - Time-to-merge for bugfix PRs improves (less rework).

5) **Testing Strategy: “Minimum Viable Integration Tests” for v2**
   - Implement a standardized test harness (use plugin-n8n-workflow pattern):
     - golden tests for one-shot + multi-step + streaming flows
     - plugin contract tests (actions/providers execution + expected message sequence)
   - Dependency: decide which “v2 runtime surface” is stable enough to test against (avoid churn loops).
   - Success metrics:
     - CI catches ordering/provider regressions before merge (target: prevent repeats of the above two P1 regressions).

### P2 — Strategic Expansion (3–8 weeks, after P0/P1 stability)
6) **Moltbook/Moltbot wedge strategy (growth via competitor pain)**
   - Near-term: deploy a small set of Eliza agents onto Moltbook to demonstrate:
     - cheaper routing (multi-model / local / plugin-local-ai embeddings)
     - reliability + compliance (avoid Anthropic non-human usage pitfalls)
   - Technical prerequisite: networked config hardening (encrypted comms, IP exposure mitigation) before encouraging “run on Mac Minis” patterns.

7) **Mobile + Voice: define the smallest viable footprint**
   - Don’t start as a full assistant rewrite. Define:
     - voice I/O plugin boundary (STT/TTS abstraction)
     - mobile “presence” as a transport + auth + notification layer (push, background jobs)
   - Gate this behind improved reliability; otherwise it magnifies support burden.

---

## Quantitative Summary Dashboard (What changed / what matters)
- **Build velocity:** 22 merged PRs / 31 contributors in month window; churn high (25.7k add / 8.8k del) → **needs stronger regression net**.
- **Top community pain volume drivers (observed):**
  - Migration failures: multiple users across wallets; plus 429 errors (high frequency).
  - Scam/security incidents: at least **2 separate scam-report threads** + **1 wallet-drain report** (highest severity).
  - Core runtime regressions: at least **2 critical bugs** (one-shot provider selection; callback sequencing).
- **Business risk:** runway **8 months**; uncertainty about treasury composition is amplifying anxiety.

---

## Actionable Recommendations (next execution cycle)

### Engineering (recommended allocation)
- **40%**: Migration portal stabilization + telemetry + self-serve debugger
- **30%**: Hotfix regressions (one-shot provider selection; callback ordering) + patch releases
- **20%**: Test harness MVP (core flows + plugin contract tests)
- **10%**: Security UX (anti-scam interstitials, canonical links) + docs updates

### Product/Comms
- Publish a single “**What the token does today**” doc (1 page) + “**What is not built yet**” section to reduce speculation.
- Add a “**Jeju staking overview**” diagram and link it from migration + token utility pages (users are connecting token value directly to Jeju readiness).
- Weekly “state of build” update: 3 bullets shipped, 3 bullets next, 3 known issues—optimize for comprehension over ambition.

### Instrumentation to add immediately
- Migration funnel metrics: page load errors (429), connect success rate, eligibility computed, successful migrate tx count, ticket deflection rate.
- Discord support taxonomy tags: migration-eligibility, migration-429, scam, runtime-regression to quantify and trend pain.

---