## Issue Triage — 2026-02-02 (elizaOS)

### 1) Token migration portal shows “0 eligible” / zero balances for holders (Discord + migration site)
- **Issue Title & ID:** Migration portal shows “0 eligible” / wallet balance zero for known holders — **DISC-2026-01-30-MIG-01**
- **Current Status:** **Open / Active** (multiple reports; users routed to tickets; deadline Feb 3)
- **Impact Assessment:**
  - **User Impact:** **Critical** (token holders at risk of losing funds if they can’t migrate)
  - **Functional Impact:** **Yes** (blocks mandatory token migration)
  - **Brand Impact:** **High** (perceived as unsafe/unreliable; panic + support load)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component Affected:** Migration Web App / Wallet indexing / Snapshot eligibility logic
  - **Complexity:** **Moderate effort** (may involve snapshot rules, LP detection, caching, RPC/indexer reliability)
- **Resource Requirements:**
  - **Required Expertise:** Solana/EVM token mechanics, snapshot/eligibility logic, web debugging, indexers/RPCs
  - **Dependencies:** Snapshot criteria clarity (LP holdings, post-snapshot purchases), support ticket telemetry, RPC rate limits
  - **Estimated Effort (1-5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add an **eligibility debug panel** (read-only) showing: detected wallet(s), token accounts, snapshot block/time, LP detection, and “why ineligible” reason codes.
  2. Pull **top 20 failing wallets** from tickets; reproduce locally against snapshot dataset; classify into buckets (LP, wrong chain, wrong wallet, post-snapshot, indexing lag, UI bug).
  3. Add **forced refresh + alternate RPC** fallback; log RPC/indexer errors to a dashboard.
  4. Publish an **official checklist**: LP holdings, multiple wallets, exchanges, snapshot date, common false negatives.
- **Potential Assignees:**
  - **Odilitime** (project context + prior migration guidance)
  - **BrightSyntax** (offered blockchain/fullstack support; suitable for indexer + wallet integration work)
  - **0xbbjoker** (infra/debugging support)

---

### 2) Migration portal HTTP 429 “Too many requests” on page load (rate limiting)
- **Issue Title & ID:** Migration site returns 429 on load; blocks migration checks — **DISC-2026-01-30-MIG-02**
- **Current Status:** **Open**
- **Impact Assessment:**
  - **User Impact:** **High** (prevents or delays many users near deadline)
  - **Functional Impact:** **Yes** (blocks migration workflow)
  - **Brand Impact:** **High** (looks like outage)
- **Technical Classification:**
  - **Category:** Performance / Reliability
  - **Component Affected:** Migration API / WAF / RPC provider limits / Frontend request burst
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Backend rate limiting, CDN/WAF config, frontend request shaping, RPC/indexer ops
  - **Dependencies:** Hosting/WAF provider configuration, traffic patterns near deadline
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Identify offending endpoints and **reduce initial request fan-out** (debounce; lazy load; cache results).
  2. Implement **server-side caching** (per wallet address) and **token bucket** limits with friendly retry UI.
  3. Add **status page** + banner when rate limits are hit; provide retry guidance.
- **Potential Assignees:** **0xbbjoker**, **Odilitime**, **madjin** (ops/infra-capable)

---

### 3) Active migration-support impersonation scams (seed phrase / DM attacks)
- **Issue Title & ID:** Scammers impersonating support; users asked for seed phrases; reported wallet theft — **DISC-2026-01-31-SEC-01**
- **Current Status:** **Ongoing / Open**
- **Impact Assessment:**
  - **User Impact:** **Critical** (direct asset loss)
  - **Functional Impact:** **Partial** (not a framework bug, but affects safe use of ecosystem)
  - **Brand Impact:** **High** (trust + reputational damage)
- **Technical Classification:**
  - **Category:** Security / UX
  - **Component Affected:** Community support process, Discord security, migration comms surface
  - **Complexity:** **Simple fix + ongoing operations**
- **Resource Requirements:**
  - **Required Expertise:** Security ops, Discord moderation, incident response comms
  - **Dependencies:** Discord permissions, verified support workflows, pinned announcements
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Pin a **single canonical “Migration Support: Never DM / Never share seed”** message in all relevant channels.
  2. Enforce **ticket-only support**: auto-responder bot that warns when users mention “ticket/seed/ledger”.
  3. Add a **public list of official staff accounts** + guidance for reporting impersonators.
  4. Run a short **incident post** summarizing scam patterns and safe steps.
- **Potential Assignees:** **Maff || Hourglass ⌛** (proven intervention), **Arceon**, **Hexx 🌐** (mods), plus **Odilitime** for official wording

---

### 4) ElizaCloud: API key creation blocked unless credit card is added (even with free credits)
- **Issue Title & ID:** ElizaCloud requires payment method to create API keys; blocks bot-based testing — **DISC-2026-02-01-CLOUD-01**
- **Current Status:** **Open** (reproducible by users; gating behavior confirmed)
- **Impact Assessment:**
  - **User Impact:** **High** (developers + agents can’t onboard; hurts integrations like OpenClaw)
  - **Functional Impact:** **Yes** (blocks API usage for many)
  - **Brand Impact:** **High** (seen as hostile DX / “broken free tier”)
- **Technical Classification:**
  - **Category:** UX / Bug (policy vs implementation)
  - **Component Affected:** ElizaCloud Billing/Identity, API Key service
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Backend auth/billing, product policy, abuse prevention
  - **Dependencies:** Fraud controls, free-tier policy decision, x402 enablement (see next issue)
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Decide policy: **allow API keys on free credits without card** (recommended) with anti-abuse limits.
  2. Implement: create key allowed when `free_credits_remaining > 0` and account is verified (email/Discord OAuth).
  3. Add safeguards: rate limits, per-account quotas, CAPTCHA on key creation, IP throttling.
  4. Update docs + UI copy so failures clearly state requirements and alternatives.
- **Potential Assignees:** **0xbbjoker** (integration/debug), **madjin** (backend feature work), **DorianD** (repro + acceptance testing)

---

### 5) ElizaCloud: x402 payment disabled on free tier; agents can’t top up without credit cards
- **Issue Title & ID:** x402 disabled for free tier; no agent-friendly top-up path — **DISC-2026-02-01-CLOUD-02**
- **Current Status:** **Open / Proposed**
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (blocks autonomous agent workflows; hurts “agent-native” positioning)
  - **Functional Impact:** **Partial** (cloud usable only with traditional billing)
  - **Brand Impact:** **High** (misalignment with crypto/agent narrative)
- **Technical Classification:**
  - **Category:** Feature / UX
  - **Component Affected:** ElizaCloud Billing, Payments (x402)
  - **Complexity:** **Complex solution** (payment flows + ledgering + fraud)
- **Resource Requirements:**
  - **Required Expertise:** Payments, secure ledgering, backend billing, abuse prevention
  - **Dependencies:** x402 infrastructure readiness; policy on minimum top-ups / chargebacks not applicable (crypto)
  - **Estimated Effort (1-5):** **4**
- **Recommended Priority:** **P2** (raise to P1 if Cloud adoption is a near-term KPI)
- **Specific Actionable Next Steps:**
  1. Implement a **non-card “developer mode”**: x402 top-up enabled after lightweight verification.
  2. Ship an MVP: **fixed denomination** top-ups + clear receipt + immediate credit posting.
  3. Add monitoring: unusual top-up frequency, replay protection, webhook signing.
- **Potential Assignees:** **madjin**, **BrightSyntax** (payments/on-chain integration), **0xbbjoker** (API integration)

---

### 6) ElizaCloud MCP app failing due to `isomorphic-dompurify` CJS/ESM module load error
- **Issue Title & ID:** ElizaCloud MCP endpoint fails: CommonJS/ESM incompatibility with isomorphic-dompurify — **DISC-2026-01-31-CLOUD-03**
- **Current Status:** **Open** (reported as server-side bug; blocks OpenClaw→ElizaCloud MCP)
- **Impact Assessment:**
  - **User Impact:** **High** (breaks a key integration path)
  - **Functional Impact:** **Yes** (MCP integration fails)
  - **Brand Impact:** **High** (appears as “Cloud is broken”)
- **Technical Classification:**
  - **Category:** Bug
  - **Component Affected:** ElizaCloud deployment/bundling, MCP app runtime
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Node/TS bundling, ESM/CJS interoperability, deployment pipeline
  - **Dependencies:** Runtime environment constraints (Node version), bundler configuration
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce in staging: confirm Node version + module resolution mode.
  2. Fix via one of: pin compatible dompurify build, switch to ESM build, or add dynamic import shim.
  3. Add a **deployment CI smoke test** that imports all server modules used by MCP endpoints.
- **Potential Assignees:** **0xbbjoker** (recent plugin-mcp work), **madjin** (build/deploy), **BaseGold** (HTTP transport familiarity)

---

### 7) ElizaCloud A2A endpoint failing: `contentModerationService` function error on `message/send`
- **Issue Title & ID:** A2A `message/send` crashes due to contentModerationService error — **DISC-2026-01-31-CLOUD-04**
- **Current Status:** **Open**
- **Impact Assessment:**
  - **User Impact:** **High** (breaks agent-to-agent messaging for Cloud users)
  - **Functional Impact:** **Yes** (core A2A path degraded)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Category:** Bug / Reliability
  - **Component Affected:** ElizaCloud A2A API, moderation pipeline
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Backend API, dependency injection/service wiring, observability
  - **Dependencies:** Moderation provider availability/config; feature flags
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add error logging with request correlation IDs around moderation calls.
  2. Ensure moderation service is optional: **fail-open or fail-soft** with policy-based fallback for dev environments.
  3. Add contract tests for A2A endpoints in CI.
- **Potential Assignees:** **madjin**, **0xbbjoker**, **DorianD** (integration tester)

---

### 8) Core repo develop branch: provider selection fails in “one-shot” mode
- **Issue Title & ID:** Provider selection bug in develop branch for one-shot mode — **DISC-2026-01-30-CORE-01**
- **Current Status:** **Open** (reported by core devs/community; no linked issue in provided data)
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (affects common “quick run” workflow)
  - **Functional Impact:** **Partial** (likely workaround exists via explicit config)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Category:** Bug
  - **Component Affected:** Core Framework / CLI runtime configuration
  - **Complexity:** **Simple fix–Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, provider routing/config precedence, CLI execution path
  - **Dependencies:** None, but should be covered by regression tests
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create minimal repro: one-shot invocation + provider selection scenario matrix.
  2. Fix precedence rules (CLI args vs env vs config file) and add tests.
  3. Document workaround until release.
- **Potential Assignees:** **Odilitime**, **0xbbjoker**

---

### 9) Monorepo stability: insufficient integration testing causing repeated breakages (v1x vs v2x)
- **Issue Title & ID:** Need better integration tests to prevent recurring breakages across versions — **DISC-2026-01-30-QA-01**
- **Current Status:** **Open / Ongoing**
- **Impact Assessment:**
  - **User Impact:** **High** (breakages hit many devs; churn risk)
  - **Functional Impact:** **Partial** (intermittent but blocks upgrades/onboarding when it happens)
  - **Brand Impact:** **High** (quality concerns raised publicly)
- **Technical Classification:**
  - **Category:** Quality / Reliability
  - **Component Affected:** Core Framework + Plugins + Release pipeline
  - **Complexity:** **Architectural change** (test strategy + CI investment)
- **Resource Requirements:**
  - **Required Expertise:** CI design, test harnesses, fixtures for plugins/providers, release engineering
  - **Dependencies:** Agreement on “golden paths” to test; stable test credentials/mocks
  - **Estimated Effort (1-5):** **5**
- **Recommended Priority:** **P2** (start now; benefits accrue quickly but won’t finish immediately)
- **Specific Actionable Next Steps:**
  1. Adopt/port the **plugin-n8n-workflow** testing approach as an org standard.
  2. Define 5–10 golden-path integration tests: `create → run → tool call → plugin load → provider call`.
  3. Add “canary” nightly runs against develop + main; block releases on failures.
- **Potential Assignees:** **Stan ⚡** (test framework lead), **madjin**, **Odilitime**

---

### 10) Babylon deployment into TEE needs fast-track plan (time-sensitive strategic deliverable)
- **Issue Title & ID:** Fast-track Babylon into TEE (parallel workstreams) — **DISC-2026-01-31-TEE-01**
- **Current Status:** **In progress / Planning** (guidance given; need execution)
- **Impact Assessment:**
  - **User Impact:** **Medium** (new product; not a current outage)
  - **Functional Impact:** **No** (feature delivery)
  - **Brand Impact:** **High** (market timing + “secure agents” narrative)
- **Technical Classification:**
  - **Category:** Feature / Security architecture
  - **Component Affected:** TEE deployment pipeline, Babylon runtime, container orchestration
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** TEE/Phala, secure deployment, Docker Compose, observability
  - **Dependencies:** Coordination with Phala team; stable container images; deployment checklist
  - **Estimated Effort (1-5):** **5**
- **Recommended Priority:** **P1** (time-window driven)
- **Specific Actionable Next Steps:**
  1. Establish parallel tracks: (A) iterate Babylon outside TEE; (B) TEE integration pipeline.
  2. Create a single **“TEE readiness” checklist**: secrets, attestation, logging, rollback, perf budgets.
  3. Schedule a working session with Phala + publish milestone dates for demo.
- **Potential Assignees:** **Agent Joshua ₱ | TEE** (lead), **Shelven**, **puncar**, **s**

---

## Summary — Top Highest-Priority Issues to Address Immediately (Next 24–72 hours)

1. **P0:** Migration portal “0 eligible” / zero balances — **DISC-2026-01-30-MIG-01**
2. **P0:** Migration portal 429 rate limiting on load — **DISC-2026-01-30-MIG-02**
3. **P0:** Active migration-support impersonation scams — **DISC-2026-01-31-SEC-01**
4. **P1:** ElizaCloud API key creation blocked without credit card — **DISC-2026-02-01-CLOUD-01**
5. **P1:** ElizaCloud MCP broken due to isomorphic-dompurify ESM/CJS error — **DISC-2026-01-31-CLOUD-03**
6. **P1:** ElizaCloud A2A message/send failing (contentModerationService) — **DISC-2026-01-31-CLOUD-04**
7. **P1:** Core one-shot provider selection bug — **DISC-2026-01-30-CORE-01**
8. **P1 (strategic/time-window):** Babylon TEE fast-track execution — **DISC-2026-01-31-TEE-01**
9. **P2:** Monorepo integration testing initiative — **DISC-2026-01-30-QA-01**
10. **P2:** x402 top-up path + free-tier enablement — **DISC-2026-02-01-CLOUD-02**

---

## Patterns / Themes Indicating Deeper Issues

- **Release quality & regression gaps:** Repeated breakages and develop-branch bugs suggest inadequate **integration test coverage** and missing “golden path” CI gates.
- **Cloud product friction at the “front door”:** Credit-card gating + broken key creation + MCP/A2A runtime errors all cluster around **first-use onboarding**, compounding negative perception.
- **Ecosystem trust and safety under strain:** Migration deadline + scams amplify the need for **operational security** and clearer support boundaries.
- **Build/deploy complexity (ESM/CJS, service wiring):** Failures like dompurify import and moderation service crashes suggest insufficient **staging smoke tests** and runtime contract checks.

---

## Recommendations — Process Improvements

1. **Add “Day-0 Onboarding” CI:** Automated tests that create an account (or mocked), create API key, run a minimal MCP call, and send an A2A message in staging before deploying.
2. **Migration war-room checklist (until Feb 3):** Dedicated on-call rotation, ticket triage buckets, live metrics (429 rate, eligibility failure rate), and public status updates.
3. **Security hardening for community ops:** Verified staff list, ticket-only enforcement, automated scam keyword detection, and a standard incident response playbook.
4. **Adopt a shared plugin/core test harness standard:** Use the plugin-n8n-workflow approach as the baseline; require new critical features to include integration tests.
5. **Pre-release “dependency compatibility” checks:** Automated Node/ESM/CJS import validation for server bundles to catch module-load failures before production.