# ElizaOS Intel — 2026-04-19

## 1) Data Pattern Recognition

### Development velocity & trend
- **Monthly baseline (2026-04-01 → 2026-05-01, elizaos/eliza):**
  - **217 new PRs / 184 merged** (≈**85% merge rate**)
  - **41 new issues / 137 closed**
  - **39 active contributors**
- **Work mix signal (last 72h context):**
  - 2026-04-18 activity skewed toward **maintenance/infrastructure** (large dependency bump batch) + **ecosystem expansion** (new plugin proposal, new commerce integration issue).
  - Community discourse in “coders” channel showed **near-zero technical throughput**, suggesting technical coordination is happening elsewhere (GitHub/maintainers) while Discord “coders” is being used for support/scam triage.

### Community engagement patterns
- Engagement is being **pulled into risk events** vs. product usage:
  - **Security vuln disclosure flow:** 1 researcher (kullai) reported “multiple vulnerabilities,” sought bounty; ultimately disclosed privately to maintainer.
  - **Scam/phishing:** multiple reports (fake Solana airdrop impersonation; repeated scammer callouts including “frog.cs”).
  - **Comms anxiety:** recurring concern about **X/Twitter inactivity (~3 weeks+)**; repeatedly reframed as “dev focus > marketing.”

### Feature / ecosystem adoption indicators
- **Plugin ecosystem continues expanding** via registry proposals (e.g., `@quantoracle/plugin-quantoracle`).
- New integration exploration: **Merxex agent-to-agent commerce** issue opened (signal: strategic direction toward transacting agents).
- Core maintenance: dependency updates across **mobile (Capacitor/Android Gradle), infra (Supabase/Postgres), Solana libs (borsh), web (Uniswap SDKs), Node typings**.

### Pain point correlation across channels (Discord ↔ GitHub)
- **Security posture + trust** is the dominant cross-channel pain point:
  - Discord: vuln reporting confusion (initial suggestion to open PR/issue), scam volume, impersonation.
  - GitHub: substantial dependency churn (good hygiene, but increases supply-chain surface area and regression risk).
- **Communication gap** amplifies risk events:
  - Lack of official, frequently updated “source of truth” leads users to rely on social signals (Twitter cadence) and become more susceptible to impersonation.

---

## 2) User Experience Intelligence

### Feedback themes (categorized by impact)

**High impact (security/trust & safety)**
- **Vulnerability reporting path unclear**: users initially advised to use public GitHub channels; corrected by researcher.
- **No bug bounty**: not inherently negative, but creates friction and delays disclosure; increases odds of public disclosure or silent non-reporting.
- **Scam volume and impersonation**: repeated airdrop scams impersonating core members; risk of user fund loss + brand damage.

**Medium impact (communication/transparency)**
- **Social account inactivity** read as “project stagnation,” despite GitHub velocity being high.
- **Org restructure (dissolution of Eliza Labs)**: community wants clarity on what is paused vs. deprecated, and how contributions work now.

**Low impact (channel hygiene / routing)**
- “Coders” channel contains non-coding safety support; indicates misrouting of support requests and lack of pinned guidance.

### Usage patterns vs. intended design
- Intended: Discord as dev/community hub; GitHub as canonical engineering channel.
- Observed: Discord becomes **incident response + reassurance** channel; GitHub shows sustained dev output but is **not perceived** by non-dev holders/users without regular summarization.

### Sentiment tracking (directional)
- **Security sentiment:** alert/high vigilance (frequent scam warnings; private vuln disclosure).
- **Product sentiment:** cautiously optimistic (“v3 nearing completion” context from 2026-04-16), but **trust impacted** by comms gaps.
- **Token/market sentiment:** frustration present (2026-04-17), but counterbalanced by “build quality first” voices.

### Implementation opportunities (near-term)
- Convert repeated Q&A into **first-class UX**:
  - “How to report security issues”
  - “Official channels / how to verify announcements”
  - “Solana deployment status” clarification (ongoing misconception noted 2026-04-16)

---

## 3) Strategic Prioritization

### Priority recommendations (impact × risk × dependency)

#### P0 — Security response & trust hardening (immediate, 24–72h)
1. **Triage and remediate reported vulnerabilities**
   - Owner: core maintainer(s) + 1 assigned security coordinator
   - Output: internal ticketing + patch plan + backport strategy (if applicable)
2. **Establish a SECURITY.md + private disclosure workflow**
   - Minimum viable:
     - security@ email or GitHub Security Advisories enabled
     - explicit “do not file public issues for security” guidance
     - expected response SLA (e.g., acknowledge within 48h)
3. **Anti-scam/impersonation mitigation**
   - Pin an “Official links + verification checklist” message in key channels
   - Add automated moderation rules for common scam patterns (airdrop keywords, link shorteners, impersonation strings)
   - Rapid ban/escalation runbook for repeated offenders (e.g., “frog.cs” pattern)

**Why P0:** Highest user harm (fund loss, exploit risk) + brand damage; also blocks adoption of commerce features (trust prerequisite).

#### P1 — Communication cadence that reduces support load (this week)
1. **Weekly “Shipping + Security + Scams” bulletin**
   - 5 bullets: merged highlights, current focus (e.g., Milady/v3), known misconceptions (Solana deployed), security reminders
   - Publish to Discord Announcements + mirror to X (even if minimal)
2. **Org restructure clarity post**
   - Explain: Labs dissolved → projects on hold → how contributions work now → where roadmap lives

**Why P1:** Directly reduces repetitive Discord churn, lowers scam susceptibility, and aligns perception with GitHub reality.

#### P2 — Dependency/update governance (next 1–2 sprints)
1. **Batch dependency PR governance**
   - Define merge windows + required CI gates for large dep waves (mobile, infra, crypto libs)
   - Add SBOM/vuln scan review step for high-risk packages (wallet/chain tooling)
2. **Plugin registry intake criteria**
   - Lightweight checklist (maintenance owner, security considerations, namespace verification) before accepting new plugins like quantoracle / future commerce integrations

**Why P2:** Maintains velocity while controlling regression and supply-chain risk as ecosystem expands.

---

## Quantitative Summary (today’s intel snapshot)
- **Security incidents:** 1 private vuln disclosure event (multiple vulns claimed) + ongoing scam/phishing reports (airdrops/impersonation).
- **Community support load:** “coders” channel contained **0 meaningful technical threads**; primary activity was scam triage.
- **Engineering throughput baseline (month-to-date window):** **217 PRs opened / 184 merged**, **39 contributors** → high velocity, but not translating into perceived momentum externally.

---

## Resource Allocation Guidance (pragmatic)
- Assign **1 rotating “Security Duty” maintainer/week**:
  - owns vuln intake, coordinates patches, posts safe public advisories once fixed.
- Allocate **0.25–0.5 FTE Community Ops** for:
  - scam response automation + pinned canonical comms + weekly bulletin drafting.
- Keep core engineers focused on v3/Milady, but **do not defer P0 security**: trust failures will compound and slow adoption of upcoming commerce/agent-to-agent initiatives.