## ElizaOS Weekly Newsletter (2026-01-29 → 2026-02-04) ### 1) Executive Summary **1. Security and trust in the plugin ecosystem became a top priority.** This week’s most actionable thread was the community’s push to harden “skills” and plugins against malicious behavior (prompted by concerns about unsafe skills on clawhub). The emerging direction is a **layered defense**: *scanner skills*, a *code-rewrite/adaptation phase* before execution, and an *LLM-based review step*—with **sandboxing** proposed as an additional guardrail. **2. Reliability improvements for agent skill invocation gained a concrete pattern.** A key pain point was quantified: in one evaluation set, **skills failed to trigger ~56% of the time** even when documentation was available. A practical workaround—forcing explicit skill selection/activation via a **UserPromptSubmit hook**—is now being tested/used in Eliza Cloud flows. **3. Tooling and developer workflow continued to mature (PR hygiene + cross-platform work).** Odilitime shared **`prr`**, a PR review tool that “sits” on pull requests until they’re ready, plus a **cross-platform Codex Desktop rebuild**. Core-dev guidance also flagged that the **`odi-dev` branch** currently contains meaningful improvements and fixes beyond `main`, which is important for anyone building against bleeding-edge behavior. --- ### 2) Development Updates (Framework, Cloud, Tooling) **Plugin development + skill security** - Odilitime shared **`plugin-cskills`** as a reference implementation for plugin/skill capabilities and OpenClaw skill support. - Security roadmap discussed: - **Scanner skills** to detect suspicious patterns - **Rewriting/adapting packaged code** into an Eliza-compatible form before use - **LLM review** to sanity-check skill behavior and intent - **Sandboxing** proposed as an alternate/extra isolation layer for untrusted skill execution **Skill invocation reliability (big UX/automation lever)** - R0am reported that skill calling can silently fail at high rates and shared a working mitigation: a **mandatory 3-step activation sequence** enforced via `UserPromptSubmit`: 1) Evaluate each skill with YES/NO + reasoning 2) Immediately call `Skill()` for the selected ones 3) Only then proceed with implementation - Stan noted a similar pattern is already implemented in **Eliza Cloud**, and suggested **improving skill descriptions** to reduce ambiguity and improve tool selection. **Cloud usability + platform friction** - **Account duplication bug**: a report that using two Proton email variants (`@proton.me` vs `@protonmail.com`) can produce duplicate accounts and a “missing agent” experience in the dashboard. This is worth prioritizing because it looks like *data loss* from the user’s perspective. - **API/payment friction**: developers highlighted that requiring a credit card even to use free credits blocks bot-based testing and experimentation (and disables x402 flows on free tier). This intersects directly with growth and hackability. **Model ecosystem awareness** - Claude **Sonnet 5** was discussed as potentially “a generation ahead” of some competitors. Separately, there’s ongoing interest in model cost/performance tradeoffs (including references in GitHub issues around testing Eliza prompts on Sonnet). **Repo/process notes** - Core-devs recommended using **`odi-dev`** rather than `main` due to accumulated improvements and bug fixes. - Two PRs were explicitly called out for review attention: - **elizaOS/eliza PR #6457** (by 0xbbjoker) - **elizaOS/eliza-cloud-v2 PR #278** (by Stan) --- ### 3) Community Spotlight (Discord) **Security-first builders: “skills can be an attack surface”** Jin raised the uncomfortable but necessary point: malicious skills can spread if distribution is easy and verification is weak. The community’s response was pragmatic—layer defenses rather than relying on a single silver bullet. If you’re building plugins, this is your cue to treat your skill packaging, signing, provenance, and runtime isolation as first-class features. **Builder-to-builder support: DIaaS signals into Eliza agents** - Lucas Alpes described a **Data Infrastructure as a Service (DIaaS)** for Solana tokens (on-chain analytics → filters → trading signals). - 0xbbjoker confirmed the best path is to ship a **plugin** so Eliza agents can consume the API cleanly—and offered ongoing help. This is the blueprint for many ecosystem integrations: *wrap your service as an agent-native plugin, not a one-off script*. **Big-brain community challenges: CICADA-71** - Mike D. introduced **CICADA-71**, a distributed agent challenge framework featuring **497 cryptographic puzzles** across seven categories (crypto, encryption, prompt injection, multi-agent coordination, reverse engineering, economic security, meta-challenge). - Notable technical flavor: shard distribution, plugin tape system with ZK-RDF compression, Paxos consensus, and monster group math—plus explicit allocation of slots for **Eliza and Claw**. **Product reality check: marketing privacy is hard** - Odilitime shared lessons from privacy product work (sessionapp): privacy adds friction, and users are often more trusting than we expect—meaning “privacy-first” alone rarely sells without a crisp value story and smooth UX. --- ### 4) Token Economics (AI16Z → ELIZAOS, airdrops, auto.fun) **Migration status + user pain** - The **ai16z → elizaos** token migration dominated community support traffic, with a **Feb 3 deadline** repeatedly referenced. Users reported multiple failure modes: - Bridge not detecting certain older holdings (pre–Nov 2025) - “Max amount reached” errors - Wallet balances showing zero during migration - Reports of significant losses and frustration with the process Support was consistently routed to dedicated migration channels, but the volume and severity suggest a need for clearer docs, better error messaging, and a more transparent postmortem. **Staking + airdrops** - No staking mechanism was announced this week; guidance remained “hold in your wallet.” - A **Babylon airdrop for ELIZAOS holders** was confirmed previously, with timing/details still TBD post-migration. **auto.fun** - No concrete auto.fun shipping updates appeared in this week’s captured discussions. If you’re building around auto.fun assumptions, treat them as unconfirmed until the next official comms drop. --- ### 5) Coming Soon (What to Watch) - **Custom agent integration for OpenClaw**: phased rollout—everyone gets Eliza access first; custom agent capabilities come **a few weeks after launch**. - **Skill security pipeline**: scanner skills + rewrite/adaptation + LLM review (and potentially sandboxing). Expect iteration here as soon as real-world plugin distribution scales. - **More reliable tool/skill triggering**: the forced activation sequence may become standardized or abstracted into a cleaner UX pattern. - **Cloud account & billing fixes**: Proton email normalization + fewer blockers to generate API keys without a credit card would materially improve developer adoption. - **Character/prompt iteration**: GitHub issues suggest ongoing work to improve Eliza’s character file and message examples, potentially re-testing on Sonnet-class models. --- ### 6) Resources (Links & Pointers) - **plugin-cskills (reference + OpenClaw skill support):** https://github.com/odilitime/plugin-cskills - **PR review queue tool (`prr`)** (shared in core-devs; ask in Discord for the latest link/context if you missed it) - **PRs to review** - elizaOS/eliza **PR #6457** (0xbbjoker): https://github.com/elizaos/eliza/pull/6457 - elizaOS/eliza-cloud-v2 **PR #278** (Stan): https://github.com/elizaos/eliza-cloud-v2/pull/278 - **GitHub issues worth tracking** - Character file & prompt engineering: https://github.com/elizaos/eliza/issues/6447 - Billing (cloud/product): https://github.com/elizaos/eliza/issues/6448 - **CICADA-71**: see the Discord coders thread (Feb 3) for the spec overview and shard assignment discussion - **Migration help**: follow the pinned guidance in Discord’s migration support channels (referenced in-chat via channel IDs #1423981231300935801 and #1425417640071139358) ---