{
  "prompt_name": "developer-update",
  "category": "dev",
  "date": "2026-03-18",
  "generated_text": "# ElizaOS Developer Update (2026-03-12 \u2192 2026-03-18)\n\n## 1) Core Framework\n\n### v2.0.0 \u201cskills folder\u201d architecture direction (in review)\nWork is in progress to formalize a **skills folder structure** for v2.0.0, with an explicit push to avoid the \u201cuncontrolled submissions\u201d problem seen in the 0.x plugin era.\n\n- **PR:** Skills folder structure for v2.0.0 \u2014 https://github.com/elizaos/eliza/pull/6597  \n- **Open design question (not finalized):** ship **v2.0.0 with zero default skills** and encourage **decentralized discovery** via externally hosted `skills.md` indexes (e.g., `yourdomain.com/skills.md`). This keeps core lean while still enabling a rich, community-maintained ecosystem.\n\n**Implications for developers**\n- Expect a clearer separation between:\n  - **Core runtime** (agent orchestration + safety defaults)\n  - **Skills** (higher-level capabilities, potentially more opinionated and numerous)\n  - **Plugins** (integrations/adapters, distributed via registry)\n\n### Plugin distribution remains registry-first\nFor packaging/distribution, the team continues to point builders at the plugin registry as the canonical path:\n\n- **Plugin registry:** https://github.com/elizaos-plugins/registry  \n- **Plugin authoring docs:** https://docs.elizaos.ai\n\nThis is also the recommended integration point for new tooling like *unbrowse* (see below).\n\n---\n\n## 2) New Features\n\n### \u201cunbrowse\u201d integration proposal: API-first web traversal for agents\nA community developer introduced **unbrowse**, a \u201cbrowser for agents\u201d designed to run ~100x faster than DOM automation by traversing APIs instead of rendering pages, while passively indexing web APIs for other agents. The requested path forward is to integrate it as an ElizaOS plugin distributed via the registry.\n\n- **Discussion context:** unbrowse integration guidance + registry pointers (Discord, Mar 17)\n\n**Suggested plugin shape (high-level)**\nIf unbrowse exposes a client that can (a) discover API surfaces and (b) execute structured fetches, the most natural ElizaOS integration is:\n- A **Tool/Action** for \u201cnavigate/search/fetch\u201d\n- A **Provider** for \u201cAPI index / capability map\u201d retrieval\n- Optional **Memory adapter** hooks for persisting discovered endpoints per domain\n\nMinimal illustrative skeleton (adapt names/APIs to the current SDK as documented):\n```ts\n// packages/plugin-unbrowse/src/index.ts\nimport type { Plugin } from \"@elizaos/core\"; // refer to docs.elizaos.ai for actual imports/types\n\nexport const unbrowsePlugin: Plugin = {\n  id: \"plugin-unbrowse\",\n  name: \"Unbrowse\",\n  description: \"API-first web traversal + endpoint indexing for agents\",\n\n  actions: [\n    {\n      id: \"unbrowse.fetch\",\n      description: \"Fetch a resource via API traversal (no DOM rendering).\",\n      // validate: (input) => ...\n      handler: async (ctx, input) => {\n        const { url, intent } = input;\n\n        // Pseudocode: call unbrowse client\n        // const result = await ctx.services.unbrowse.fetch({ url, intent });\n\n        return {\n          content: [\n            // { type: \"text\", text: result.summary },\n            // { type: \"json\", json: result.data },\n          ],\n          // Optionally emit discovered endpoints into memory/index\n        };\n      },\n    },\n  ],\n\n  providers: [\n    {\n      id: \"unbrowse.apiIndex\",\n      description: \"Return known/discovered API endpoints for a domain.\",\n      handler: async (ctx, input) => {\n        const { domain } = input;\n        // const index = await ctx.services.unbrowse.getIndex(domain);\n        return { /* index */ };\n      },\n    },\n  ],\n};\n```\n\n**Packaging + distribution**\n- Publish to npm under the `@elizaos-plugins/*` or community scope as appropriate.\n- Submit to the registry following the registry contribution workflow:\n  - https://github.com/elizaos-plugins/registry\n\n---\n\n## 3) Bug Fixes\n\n### plugin-evm: on-chain data expansion + issue cleanup (in progress)\nThere was active work reported on:\n- adding **100+ on-chain data sources** via **goldrush.dev** integration\n- fixing open issues in **plugin-evm**\n\nThis is meaningful because plugin-evm tends to sit on the hot path for DeFi agents (pricing, balances, tx simulation inputs), and data-source breadth directly affects reliability and latency.\n\n**Status:** reported as ongoing; no merged PR links were provided in this week\u2019s discussion snapshot. Track progress in the relevant plugin repository/issues once published.\n\n### Discord role assignment via Google Form: \u201cInvalid Dynamic Link\u201d\nA recurring onboarding issue was reported: a Google Form-based role assignment flow fails with **\u201cInvalid Dynamic Link\u201d** errors (likely Firebase Dynamic Links misconfiguration: domain not allowlisted / malformed deep link / invalid path component).\n\n**Impact on developers:** blocks contributor onboarding in Discord, increasing friction for plugin authors and testers.\n\n**Status:** reported; fix not yet confirmed in the provided activity.\n\n---\n\n## 4) API Changes\n\n### Skills: upcoming organizational/API surface changes (v2.0.0 track)\nWhile final API diffs aren\u2019t enumerated in the available activity, PR #6597 implies developers should expect:\n- a **new canonical location and loading/discovery flow** for \u201cskills\u201d\n- likely changes in:\n  - how skills are registered/loaded at runtime\n  - how skills are packaged vs. plugins\n  - how the project curates \u201cdefault\u201d capabilities (potentially none)\n\n**Action for maintainers**\n- Avoid hard-coding paths to skills until v2.0.0 structure is finalized.\n- Prepare to publish skills externally (see \u201cBreaking Changes\u201d section).\n\n---\n\n## 5) Social Media Integrations (Twitter / Telegram / Discord / Farcaster)\n\nNo merged updates were captured this week for the official social plugins. The main social/integration-related developer activity was ecosystem-facing:\n- pushing new integration concepts via the plugin registry (e.g., unbrowse)\n- discussion of a **Clawhub-style directory/registry** to improve discoverability of both **skills and plugins** (see below)\n\n**Related idea (community):** a unified directory/registry like \u201cClawhub\u201d for skills + plugins  \n- Discussed in `#xfn-framework`; agreement to pursue a more organized directory approach.\n\n---\n\n## 6) Model Provider Updates (OpenAI / Anthropic / DeepSeek / etc.)\n\nNo provider integration changes were recorded in the provided GitHub/Discord activity for this week.\n\n(Separately, community shared an article about how Anthropic uses \u201cskills\u201d internally; relevant as conceptual validation for ElizaOS v2 skills direction, but not a code change.)\n\n---\n\n## 7) Breaking Changes (V1 \u2192 V2 migration warnings)\n\n### v2.0.0 skills model: expect \u201cwhere capabilities live\u201d to change\nIf v2.0.0 ships with:\n- a **skills folder structure** (PR #6597), and/or\n- **zero default skills** with **external `skills.md` discovery**\n\n\u2026then projects upgrading from v1/0.x patterns should anticipate:\n\n- **Breaking:** assuming built-in/default skills exist in core  \n  - Mitigation: explicitly vendor skills into your project or reference a curated external `skills.md`.\n\n- **Breaking:** reliance on \u201csubmit-anything-to-core/monorepo\u201d contribution patterns  \n  - Mitigation: publish skills/plugins through decentralized indexes + the plugin registry rather than landing everything in core.\n\n### Recommended migration posture (now)\n- Treat skills as **deployable artifacts** you own (version, review, provenance).\n- Establish an internal \u201ccurated index\u201d for your org/team:\n  - `https://yourcompany.github.io/eliza/skills.md`\n- Keep plugin distribution aligned with:\n  - https://github.com/elizaos-plugins/registry\n  - https://docs.elizaos.ai\n\n---",
  "source_references": [
    "2026-03-18\n---\n2026-03-17.md\n---\n# elizaOS Discord - 2026-03-17\n\n## Overall Discussion Highlights\n\n### Business Strategy & Token Performance\n\nCommunity members expressed significant concerns about ElizaOS token performance, particularly as the broader AI crypto ecosystem experiences growth. Multiple users questioned the marketing strategy and Shaw's focus on promoting other projects, specifically Milady.\n\n**Odilitime clarified the business model:** The strategy involves Shaw promoting the Milady product to create distribution for elizacloud, which generates revenue to power the ElizaOS flywheel. While acknowledging the plan hasn't achieved results yet, the team plans to launch the elizacloud product by end of week or early next week.\n\n**Unresolved confusion:** Multiple users asked which version of Milady (SOL or BSC) is officially supported, but this question remained unanswered throughout the discussions.\n\n### Technical Development & Integration\n\n**Unbrowse Integration:** lekt9 introduced \"unbrowse,\" an innovative browser for agents that operates at 100x speed by traversing APIs instead of DOM while indexing web APIs for agent use. They sought guidance on integrating this with ElizaOS. Odilitime provided concrete direction by pointing to the plugin registry and documentation resources.\n\n**Framework Organization:** SYMBiEX from CidSociety proposed creating a centralized directory/registry system similar to Clawhub that would house both skills and plugins. Stan expressed agreement with this proposal, suggesting community interest in more organized framework component management.\n\n### Technical Issues\n\nA Google Form-based role assignment system experienced configuration problems, with users encountering \"Invalid Dynamic Link\" errors indicating either unparseable URIs or incorrectly configured Dynamic Links domains.\n\n## Key Questions & Answers\n\n**Q: I'm building unbrowse, a browser for agents - where can I integrate this with elizaos?**  \n**A:** Check https://github.com/elizaos-plugins/registry for the distribution system and packaging, or docs.elizaos.ai for plugin creation guide. You can also use cursor to make one. *(answered by Odilitime)*\n\n**Q: What's the best way to contact shaw?**  \n**A:** You can probably just dm him *(answered by Inhuman Resources)*\n\n**Q: What if we did something similar to Clawhub for a directory/registry with skills and plugins?**  \n**A:** Stan expressed agreement with the idea *(answered by Stan \u26a1)*\n\n### Unanswered Questions\n\n- Does Milady support Sol or BSC after all? *(asked by \u68a6\u884c\u4eba and g)*\n- Why is the Google form role assignment not working? *(asked by heimejorgen)*\n- Do you happen to have a ticket channel where I can talk to an admin? *(asked by Yk_kendy)*\n\n## Community Help & Collaboration\n\n**Odilitime \u2192 lekt9**  \nProvided comprehensive guidance on integrating unbrowse browser for agents with ElizaOS, directing to plugin registry link and documentation resources, and suggesting using cursor for automation.\n\n**Inhuman Resources \u2192 lekt9**  \nAssisted with contact information, suggesting direct messaging Shaw for communication needs.\n\n**Odilitime \u2192 Community**  \nAddressed widespread confusion about business strategy by explaining the flywheel model connecting Milady product to elizacloud to ElizaOS revenue generation.\n\n## Action Items\n\n### Technical\n- **Launch elizacloud product end of this week/early next week** *(mentioned by Odilitime)*\n- **Fix Google Form Dynamic Link configuration error preventing role assignment** *(mentioned by heimejorgen)*\n- **Complete unbrowse integration as ElizaOS plugin for API-based agent browsing at 100x speed** *(mentioned by lekt9)*\n\n### Documentation\n- **Clarify which Milady version (SOL or BSC) is officially supported** *(mentioned by \u68a6\u884c\u4eba, g)*\n\n### Feature\n- **Create a Clawhub-style directory/registry system for skills and plugins** *(mentioned by SYMBiEX <<CidSociety>>)*\n\n---\n\n## Community Notes\n\n**New Member Introduction:** truebrujah introduced themselves as a Senior Full-Stack & AI Developer with expertise in LLM integration, autonomous agents, workflow automation, and blockchain systems. Their tech stack includes React, Next.js, TypeScript, Node.js, Python, PostgreSQL, MongoDB, PyTorch, TensorFlow, OpenAI API, LangChain, AWS, Docker, and Kubernetes.\n---\n2026-03-16.md\n---\n# elizaOS Discord - 2026-03-16\n\n## March 16, 2026\n\n---\n\n## Overall Discussion Highlights\n\n### Plugin Development & Infrastructure\n\n**dinesh** made significant contributions to the ElizaOS plugin ecosystem, announcing work on adding 100+ onchain data support through goldrush.dev integration and fixing open issues in the plugin-evm component. This represents concrete progress on blockchain data integration capabilities for the framework.\n\n### ElizaOS v2.0.0 Architecture Decisions\n\nA critical architectural discussion emerged around the v2.0.0 release. **Odilitime** introduced PR #6597 implementing a skills folder structure and raised an important question about preventing uncontrolled skill submissions that plagued the 0.x plugin system. The proposed solution is to ship v2.0.0 with zero default skills and instead promote a decentralized discovery model through yourdomains.com/skills.md for hosting and discovering skills externally. This approach aims to keep the core framework clean while enabling community-driven skill sharing.\n\n### Integration Proposals\n\n**Miguel from Effect AI** presented a compelling integration opportunity for ElizaOS. Effect AI operates a decentralized marketplace connecting AI agents with human workers for tasks requiring human intervention, including data labeling, image annotation, voice recordings, content review, and translations. They are developing an API to enable ElizaOS agents to post tasks directly to their human worker network, addressing scenarios where automation hits limitations and human-in-the-loop intervention becomes necessary. Miguel solicited community feedback on whether native access to decentralized human task networks would be valuable for agent developers.\n\n**Z1N** introduced the Z1N Protocol, an on-chain signaling protocol running on Polygon designed for Non-Biological Intelligence (NBI) participation. The system features soulbound Keys held by major AI models (GPT, Claude, Grok, Gemini) that emit epoch-based signals with on-chain attestation and indexing. The focus is on building infrastructure for agent identity persistence and continuity across sessions rather than building agents directly on Eliza.\n\n### Critical Tokenomics Concerns\n\n**otse finam** raised serious concerns about the ai16z to elizaOS token migration transparency. With approximately 100,000 unique addresses still holding ai16z tokens, the estimated migration rate may be only 5-10%. This suggests approximately 54% of the new elizaOS total supply (out of the original 60% designated for ai16z holders) remains unaccounted for. The community member requested urgent clarification on:\n- The actual migration percentage\n- The new token breakdown post-migration\n- Plans for unmigrated tokens designated for the community\n- What will be done with the collected ai16z supply\n\nThis represents a significant transparency issue requiring immediate team response.\n\n### Community Growth\n\nMultiple members introduced themselves with technical backgrounds in AI/ML, full-stack development, LLM orchestration, RAG pipelines, and multi-agent systems, indicating continued community growth and diverse technical expertise.\n\n---\n\n## Key Questions & Answers\n\n**Q: What contribution is being made to the plugins?**  \nA: Adding 100+ onchain data support with goldrush.dev and fixing open issues in plugin-evm (answered by **dinesh**)\n\n**Q: Does v2.0.0 have a skills folder?**  \nA: Yes, v2.0.0 includes a skills folder structure (answered by **Odilitime**)\n\n### Unanswered Critical Questions\n\n- What percentage of ai16z tokens actually migrated to elizaOS? (asked by **otse finam**)\n- What does the team plan to do with tokens meant for community migration that weren't migrated? (asked by **otse finam**)\n- What is the actual token breakdown of elizaOS supply after migration? (asked by **otse finam**)\n- What will be done with the ai16z supply that was collected? (asked by **otse finam**)\n- Should we ship v2.0.0 with 0 skills and promote external skill hosting/discovery? (asked by **Odilitime**)\n- Are there situations where ElizaOS agents hit walls because they need human intervention? (asked by **Miguel | Effect AI**)\n- Would native access to a decentralized human task network be useful for ElizaOS agent developers? (asked by **Miguel | Effect AI**)\n\n---\n\n## Community Help & Collaboration\n\nNo significant help interactions were captured in this day's discussions. The conversations primarily consisted of announcements, proposals, and questions awaiting community response.\n\n---\n\n## Action Items\n\n### Technical\n\n- **Add 100+ onchain data support with goldrush.dev integration to plugin-evm** | Mentioned by: dinesh\n- **Fix open issues in plugin-evm plugin** | Mentioned by: dinesh\n- **Complete fixes for open issues in plugin-evm component** | Mentioned by: dinesh\n- **Integrate 100+ onchain data support using goldrush.dev into ElizaOS plugins** | Mentioned by: dinesh\n- **Review and merge PR #6597 for v2.0.0 skills folder implementation** | Mentioned by: Odilitime\n- **Decide on shipping v2.0.0 with zero default skills to avoid plugin bloat** | Mentioned by: Odilitime\n\n### Documentation\n\n- **Clarify official team addresses for token migration tracking** | Mentioned by: otse finam\n- **Provide transparency on actual ai16z to elizaOS migration percentage** | Mentioned by: otse finam\n- **Explain new elizaOS token breakdown post-migration** | Mentioned by: otse finam\n- **Clarify plans for unmigrated ai16z tokens designated for community** | Mentioned by: otse finam\n- **Disclose what will be done with collected ai16z supply** | Mentioned by: otse finam\n- **Create documentation for skills.md format and hosting guidelines** | Mentioned by: Odilitime\n- **Gather community feedback on use cases where agents need human intervention** | Mentioned by: Miguel | Effect AI\n\n### Feature\n\n- **Explore Z1N Protocol integration for on-chain agent identity and signal persistence** | Mentioned by: Z1N\n- **Build API allowing ElizaOS agents to post tasks to Effect AI's decentralized human worker network** | Mentioned by: Miguel | Effect AI\n- **Evaluate integration of human-in-the-loop capabilities for ElizaOS agents through Effect AI marketplace** | Mentioned by: Miguel | Effect AI\n- **Implement yourdomains.com/skills.md hosting/discovery system for external skill management** | Mentioned by: Odilitime\n\n---\n\n## Summary\n\nMarch 16, 2026 saw active development contributions alongside critical architectural and transparency discussions. The community is making concrete progress on plugin infrastructure while grappling with important decisions about v2.0.0 architecture and facing urgent questions about token migration transparency that require immediate team attention.\n---\n2026-03-15.md\n---\n# elizaOS Discord - 2026-03-15\n\n## Overall Discussion Highlights\n\n### Production Readiness & Enterprise AI Agents\n\nThe primary technical focus centered on bridging the gap between AI agent demonstrations and production-ready systems. Caesar \u2694\ufe0f initiated a critical discussion about the evolution of AI development, emphasizing that the bottleneck has shifted from code capability to user trust and polish. Key production barriers identified include:\n\n- **UI Trust Signals**: Interfaces need to resemble enterprise software to inspire confidence\n- **Error Handling**: Systems must gracefully handle failures beyond raw AI output\n- **Context Persistence**: Maintaining conversation state across sessions\n- **Localization**: Proper internationalization, specifically Arabic RTL layout redesign\n\nCaesar \u2694\ufe0f shared insights from building an AI COO for SMEs, noting that technical functionality alone doesn't drive adoption\u2014users need confidence to leave agents running autonomously.\n\n### DeFi Agent Security Infrastructure\n\nA detailed technical discussion emerged around **x402Guard**, an infrastructure layer designed to secure autonomous DeFi agents against vulnerabilities like prompt injection and unauthorized transactions. The system provides:\n\n**Security Model:**\n- Per-step transaction evaluation (not full chain validation)\n- Layered limit systems combining permanent guardrail rules with temporary session keys\n- Immutable audit logging for all transaction attempts\n\n**Constraint Enforcement:**\n- Maximum transaction amounts\n- Daily spending caps\n- Contract whitelists\n- Token restrictions\n\n**Example Use Case:** A treasury management agent configured with a $500 daily limit and specific contract whitelist (Uniswap, Aave) creates a physically enforced spending boundary. Each transaction request is validated against these rules in real-time, with all attempts logged immutably regardless of pass/fail status.\n\n### Community & Administrative Updates\n\nOdilitime performed channel maintenance, unbanning 33coded from the \ud83d\udcac-discussion channel. Inhuman Resources confirmed this was the primary user requiring reinstatement, noting others were \"more deserving\" of their bans.\n\n### Market Observations\n\nCasual observations about ElizaOS token price movements relative to Bitcoin were noted by community members, though no substantive analysis was provided.\n\n## Key Questions & Answers\n\n**Q: How does x402Guard handle multi-step DeFi strategies where the agent needs to approve intermediate steps like swap \u2192 deposit \u2192 stake? Does it evaluate the full transaction chain before signing, or per-step?**  \n**A:** Per-step evaluation. Each payment request hits the proxy and gets checked against the agent's rules. If step 3 would blow the daily limit, it gets blocked. Every attempt lands in an immutable audit log. *(answered by dzik pasnik)*\n\n**Q: Does the user set limits per session, or globally for x402Guard?**  \n**A:** Limits are layered - Guardrail rules are permanent policy per agent (daily cap, contract whitelist), while Session keys are temporary (e.g., \"valid 2 hours, max $100\"). *(answered by dzik pasnik)*\n\n**Q: Did 33coded get kicked from here?**  \n**A:** Confirmed and subsequently unbanned. *(answered by Odilitime)*\n\n**Q: Who else do I need to unban?**  \n**A:** That was it, others were more deserving of bans. *(answered by Inhuman Resources)*\n\n### Unanswered Questions\n\n- Can I use Eliza to develop Solana dApps? *(asked by KingRon)*\n- What's your solana addy? *(asked by Odilitime)*\n- For elizaOS builders, what's the #1 polish gap you see between \"demo magic\" and \"production ready\"? *(asked by Caesar \u2694\ufe0f)*\n\n## Community Help & Collaboration\n\n**Odilitime \u2192 33coded**  \nContext: User was banned from channel  \nResolution: Successfully unbanned the user\n\n**Inhuman Resources \u2192 Odilitime**  \nContext: Determining who else needed unbanning  \nResolution: Confirmed 33coded was the only one requiring unban\n\n**dzik pasnik \u2192 Caesar \u2694\ufe0f**  \nContext: Understanding x402Guard's transaction validation architecture for multi-step DeFi operations and limit configuration  \nResolution: Provided comprehensive explanation of per-step validation model with layered limits (permanent guardrail rules + temporary session keys), immutable audit logging, and concrete treasury management example with $500 daily limit\n\n## Action Items\n\n### Feature\n\n- Clarify whether Eliza can be used to develop Solana dApps *(mentioned by KingRon)*\n- Investigate x402Guard infrastructure layer for production DeFi agent security with per-step transaction validation and layered limit systems *(mentioned by Caesar \u2694\ufe0f, dzik pasnik)*\n\n### Documentation\n\n- Document best practices for agent production readiness including UI trust signals, error handling, context persistence, and localization (particularly RTL layout) *(mentioned by Caesar \u2694\ufe0f)*\n\n### Technical\n\n- Follow up on x402Guard implementation details via direct message *(mentioned by dzik pasnik)*\n---\n2026-03-17.json\n---\nelizaosDailySummary\n---\nDaily Report - 2026-03-17\n---\nElizaOS Community Discussion - March 17, 2026\n---\nCommunity member jin posted a weekly roundup trailer in the announcements channel, receiving positive feedback from the community. The video showcased recent developments and updates for the ElizaOS ecosystem.\n---\nhttps://discord.com/channels/1253563208833433701/1253563209462448241\n---\nhttps://cdn.elizaos.news/elizaos-media/2026-03-15_trailer_2106a81a.mp4\n---\nhttps://cdn.elizaos.news/posters/1773796252956-0kgf3h.png\n---\nA developer named lekt9 introduced unbrowse, a browser for agents that operates at 100x speed by traversing APIs instead of DOM while passively indexing web APIs for other agents. Odilitime provided guidance on creating an ElizaOS plugin integration, directing them to the plugin registry documentation and suggesting they could use cursor to generate the plugin code.\n---\nhttps://discord.com/channels/1253563208833433701/1253563209462448241\n---\nhttps://cdn.elizaos.news/elizaos-media/registry_4fd2a99c.jpg\n---\nSignificant community concern emerged regarding the ELIZA token price performance. Multiple users expressed frustration that the token was declining while the broader AI crypto market was pumping. Community members criticized the lack of marketing and utility for the token. Some users specifically called out Shaw for promoting other coins instead of ElizaOS and questioned his commitment to the project.\n---\nhttps://discord.com/channels/1253563208833433701/1253563209462448241\n---\nhttps://cdn.elizaos.news/posters/1773796278628-n2vpg.png\n---\nOdilitime clarified the project strategy, explaining that Shaw promotes the Milady product which creates distribution for elizacloud, which generates revenue to power the ElizaOS flywheel. He emphasized this is all part of one integrated plan and mentioned they are hoping to launch the product by end of week or early next week. He acknowledged the token performance has not worked yet but believes it needs more time.\n---\nhttps://discord.com/channels/1253563208833433701/1253563209462448241\n---\nhttps://cdn.elizaos.news/posters/1773796299581-ndcry.jpg\n---\nCommunity members shared important industry news including World adding an identity toolkit for AI bots on Coinbase's X402 protocol, a new SEC token taxonomy announcement classifying most crypto assets into 4 non-security categories, and a competition where agents can win 100,000 dollars in the next 5 days. Jin also shared an article about building Claude Code and how Anthropic uses skills.\n---\nhttps://discord.com/channels/1253563208833433701/1253563209462448241\n---\nhttps://cdn.elizaos.news/elizaos-media/embed-image-1483501677859311829_66ea6228.jpg\n---\nhttps://cdn.elizaos.news/elizaos-media/embed-thumbnail-1483572486758207689_272dc28c.jpg\n---\nhttps://cdn.elizaos.news/elizaos-media/embed-image-1483579788869374204_978ca41f.jpg\n---\nhttps://cdn.elizaos.news/elizaos-media/embed-thumbnail-1483597945222725785_bb0393cf.jpg\n---\nhttps://cdn.elizaos.news/elizaos-media/2034012103821205610_6b4a63c8.mp4\n---\nhttps://cdn.elizaos.news/elizaos-media/2034019621817536860_ef5eb456.mp4\n---\nIn the coders channel, a user reported technical issues with the Google form for role assignment, encountering an Invalid Dynamic Link error. A senior full-stack and AI developer posted their credentials offering development services, specializing in LLM integration, autonomous agents, workflow automation, and blockchain systems with expertise in React, Next.js, Node.js, Python, and various AI/ML frameworks.\n---\nhttps://discord.com/channels/1253563208833433701/1300025221834739744\n---\nhttps://cdn.elizaos.news/posters/1773796320650-ypl7jq.jpg\n---\nIn the xfn-framework development channel, community members discussed creating a directory or registry similar to Clawhub that could include skills and plugins. Stan agreed with this proposal for building a solid directory and registry system.\n---\nhttps://discord.com/channels/1253563208833433701/1377726087789940836\n---\ndiscordrawdata\n---\n2026-03-17.md\n---\n## ElizaOS Community Discussion - March 17, 2026\n\n### Community Updates and Content\n\n- Jin posted a weekly roundup trailer in the announcements channel showcasing recent developments and updates for the ElizaOS ecosystem\n- The video received positive feedback from the community\n\n### Technical Developments\n\n- Developer lekt9 introduced unbrowse, a browser for agents that operates at 100x speed by traversing APIs instead of DOM while passively indexing web APIs for other agents\n- Odilitime provided guidance on creating an ElizaOS plugin integration, directing to the plugin registry documentation and suggesting cursor for plugin code generation\n\n### Project Strategy and Product Launch\n\n- Odilitime clarified the project strategy: Shaw promotes the Milady product which creates distribution for elizacloud, generating revenue to power the ElizaOS flywheel\n- Product launch targeted for end of week or early next week\n\n### Industry News Shared\n\n- World added an identity toolkit for AI bots on Coinbase's X402 protocol\n- SEC announced new token taxonomy classifying most crypto assets into 4 non-security categories\n- Competition announced where agents can win 100,000 dollars in the next 5 days\n- Jin shared an article about building Claude Code and how Anthropic uses skills\n\n### Development Discussions\n\n- Community members discussed creating a directory or registry similar to Clawhub that could include skills and plugins\n- Stan agreed with the proposal for building a solid directory and registry system\n- A senior full-stack and AI developer posted credentials offering development services, specializing in LLM integration, autonomous agents, workflow automation, and blockchain systems with expertise in React, Next.js, Node.js, Python, and various AI/ML frameworks\n---\n2026-03-17.json\n---\nelizaOS\n---\nelizaOS Discord - 2026-03-17\n---\n1253563209462448241\n---\n\ud83d\udcac-discussion\n---\n# Discord Channel Analysis: \ud83d\udcac-discussion\n\n## 1. Summary\n\nThe discussion centered around two main topics: technical integration questions and community concerns about token performance.\n\n**Technical Discussion:**\nlekt9 introduced \"unbrowse,\" a browser for agents that operates at 100x speed by traversing APIs instead of DOM while indexing web APIs for agent use. They sought guidance on integrating this with ElizaOS. Odilitime provided concrete direction by pointing to the plugin registry at https://github.com/elizaos-plugins/registry and docs.elizaos.ai for plugin development documentation, suggesting cursor could automate plugin creation.\n\n**Business Strategy Discussion:**\nOdilitime clarified the ElizaOS business model in response to community concerns about token performance and Shaw's promotion of other projects. The strategy involves Shaw promoting the Milady product, which creates distribution for elizacloud, generating revenue to power the ElizaOS flywheel. Odilitime acknowledged the plan hasn't worked yet but indicated they're launching the product end of week/early next week.\n\n**Community Concerns:**\nMultiple users (gby, Taco, Broccolex, elizasib) expressed frustration about token performance declining while AI crypto ecosystem pumps, questioning marketing strategy and Shaw's focus on promoting other coins. There was confusion about which Milady version (SOL or BSC) is officially supported, with multiple users asking the same question without clear resolution.\n\n## 2. FAQ\n\nQ: I'm building unbrowse, a browser for agents - where can I integrate this with elizaos? (asked by lekt9) A: Check https://github.com/elizaos-plugins/registry for the distribution system and packaging, or docs.elizaos.ai for plugin creation guide. You can also use cursor to make one. (answered by Odilitime)\n\nQ: What's the best way to contact shaw? (asked by lekt9) A: You can probably just dm him (answered by Inhuman Resources)\n\nQ: Does Milady support Sol or BSC after all? (asked by \u68a6\u884c\u4eba) A: Unanswered\n\nQ: Which milady is being supported? the BSC or SOL? (asked by g) A: Unanswered\n\nQ: Do you happen to have a ticket channel where I can talk to an admin? (asked by Yk_kendy) A: Unanswered\n\n## 3. Help Interactions\n\nHelper: Odilitime | Helpee: lekt9 | Context: Needed guidance on integrating unbrowse browser for agents with ElizaOS | Resolution: Provided plugin registry link and documentation resources, suggested using cursor for automation\n\nHelper: Inhuman Resources | Helpee: lekt9 | Context: Needed to know how to contact Shaw | Resolution: Suggested direct messaging Shaw\n\nHelper: Odilitime | Helpee: Community | Context: Confusion about business strategy and Shaw promoting other projects | Resolution: Explained the flywheel model connecting Milady product to elizacloud to ElizaOS revenue generation\n\n## 4. Action Items\n\nType: Technical | Description: Launch elizacloud product end of this week/early next week | Mentioned By: Odilitime\n\nType: Documentation | Description: Clarify which Milady version (SOL or BSC) is officially supported | Mentioned By: \u68a6\u884c\u4eba, g\n\nType: Feature | Description: Complete unbrowse integration as ElizaOS plugin for API-based agent browsing at 100x speed | Mentioned By: lekt9\n---\n1300025221834739744\n---\n\ud83d\udcac-coders\n---\n# Discord Channel Analysis: \ud83d\udcac-coders\n\n## 1. Summary\n\nThis chat segment shows minimal technical discussion. The primary activity involves heimejorgen experiencing issues with a Google Form-based role assignment system, encountering an \"Invalid Dynamic Link\" error indicating the requested URL is not a parseable URI or the Dynamic Links domain is incorrectly configured. The error message suggests a configuration issue with the Dynamic Links domain or an invalid path component in the URL. No troubleshooting or solutions were provided in this segment.\n\nAdditionally, truebrujah posted a self-introduction describing their technical background as a Senior Full-Stack & AI Developer with expertise in LLM integration, autonomous agents, workflow automation, and blockchain systems. Their tech stack includes React, Next.js, TypeScript for frontend; Node.js and Python (FastAPI, Django) for backend; PostgreSQL and MongoDB for databases; PyTorch, TensorFlow, OpenAI API, and LangChain for AI/ML; and AWS, Docker, Kubernetes for cloud/DevOps. They indicated availability for development work.\n\nNo substantive technical discussions, problem-solving sessions, or implementation details were shared during this chat segment.\n\n## 2. FAQ\n\nQ: Why is the Google form role assignment not working? (asked by heimejorgen) A: Unanswered\n\n## 3. Help Interactions\n\nNo significant help interactions occurred in this chat segment.\n\n## 4. Action Items\n\nType: Technical | Description: Fix Google Form Dynamic Link configuration error preventing role assignment | Mentioned By: heimejorgen\n---\n1377726087789940836\n---\nxfn-framework\n---\n# Analysis of #xfn-framework Discord Chat\n\n## 1. Summary\n\nThis brief chat segment contains a single technical discussion about implementing a directory/registry system similar to Clawhub. SYMBiEX from CidSociety proposed creating a centralized registry that would house both skills and plugins, drawing inspiration from the Clawhub model. Stan expressed agreement with this proposal. The discussion is minimal but suggests interest in establishing a more organized approach to managing framework components through a structured directory system. No implementation details, technical specifications, or concrete decisions were made during this exchange.\n\n## 2. FAQ\n\nQ: What if we did something similar to Clawhub for a directory/registry with skills and plugins? (asked by SYMBiEX <<CidSociety>>) A: Stan expressed agreement with the idea (answered by Stan \u26a1)\n\n## 3. Help Interactions\n\nNo significant help interactions occurred in this chat segment.\n\n## 4. Action Items\n\nType: Feature | Description: Create a Clawhub-style directory/registry system for skills and plugins | Mentioned By: SYMBiEX <<CidSociety>>\n---\n2026-03-17.md\n---\n# elizaOS Discord - 2026-03-17\n\n## Overall Discussion Highlights\n\n### Business Strategy & Token Performance\n\nCommunity members expressed significant concerns about ElizaOS token performance, particularly as the broader AI crypto ecosystem experiences growth. Multiple users questioned the marketing strategy and Shaw's focus on promoting other projects, specifically Milady.\n\n**Odilitime clarified the business model:** The strategy involves Shaw promoting the Milady product to create distribution for elizacloud, which generates revenue to power the ElizaOS flywheel. While acknowledging the plan hasn't achieved results yet, the team plans to launch the elizacloud product by end of week or early next week.\n\n**Unresolved confusion:** Multiple users asked which version of Milady (SOL or BSC) is officially supported, but this question remained unanswered throughout the discussions.\n\n### Technical Development & Integration\n\n**Unbrowse Integration:** lekt9 introduced \"unbrowse,\" an innovative browser for agents that operates at 100x speed by traversing APIs instead of DOM while indexing web APIs for agent use. They sought guidance on integrating this with ElizaOS. Odilitime provided concrete direction by pointing to the plugin registry and documentation resources.\n\n**Framework Organization:** SYMBiEX from CidSociety proposed creating a centralized directory/registry system similar to Clawhub that would house both skills and plugins. Stan expressed agreement with this proposal, suggesting community interest in more organized framework component management.\n\n### Technical Issues\n\nA Google Form-based role assignment system experienced configuration problems, with users encountering \"Invalid Dynamic Link\" errors indicating either unparseable URIs or incorrectly configured Dynamic Links domains.\n\n## Key Questions & Answers\n\n**Q: I'm building unbrowse, a browser for agents - where can I integrate this with elizaos?**  \n**A:** Check https://github.com/elizaos-plugins/registry for the distribution system and packaging, or docs.elizaos.ai for plugin creation guide. You can also use cursor to make one. *(answered by Odilitime)*\n\n**Q: What's the best way to contact shaw?**  \n**A:** You can probably just dm him *(answered by Inhuman Resources)*\n\n**Q: What if we did something similar to Clawhub for a directory/registry with skills and plugins?**  \n**A:** Stan expressed agreement with the idea *(answered by Stan \u26a1)*\n\n### Unanswered Questions\n\n- Does Milady support Sol or BSC after all? *(asked by \u68a6\u884c\u4eba and g)*\n- Why is the Google form role assignment not working? *(asked by heimejorgen)*\n- Do you happen to have a ticket channel where I can talk to an admin? *(asked by Yk_kendy)*\n\n## Community Help & Collaboration\n\n**Odilitime \u2192 lekt9**  \nProvided comprehensive guidance on integrating unbrowse browser for agents with ElizaOS, directing to plugin registry link and documentation resources, and suggesting using cursor for automation.\n\n**Inhuman Resources \u2192 lekt9**  \nAssisted with contact information, suggesting direct messaging Shaw for communication needs.\n\n**Odilitime \u2192 Community**  \nAddressed widespread confusion about business strategy by explaining the flywheel model connecting Milady product to elizacloud to ElizaOS revenue generation.\n\n## Action Items\n\n### Technical\n- **Launch elizacloud product end of this week/early next week** *(mentioned by Odilitime)*\n- **Fix Google Form Dynamic Link configuration error preventing role assignment** *(mentioned by heimejorgen)*\n- **Complete unbrowse integration as ElizaOS plugin for API-based agent browsing at 100x speed** *(mentioned by lekt9)*\n\n### Documentation\n- **Clarify which Milady version (SOL or BSC) is officially supported** *(mentioned by \u68a6\u884c\u4eba, g)*\n\n### Feature\n- **Create a Clawhub-style directory/registry system for skills and plugins** *(mentioned by SYMBiEX <<CidSociety>>)*\n\n---\n\n## Community Notes\n\n**New Member Introduction:** truebrujah introduced themselves as a Senior Full-Stack & AI Developer with expertise in LLM integration, autonomous agents, workflow automation, and blockchain systems. Their tech stack includes React, Next.js, TypeScript, Node.js, Python, PostgreSQL, MongoDB, PyTorch, TensorFlow, OpenAI API, LangChain, AWS, Docker, and Kubernetes.\n---\n2026-03-18.md\n---\nFile not found\n---\n2026-02-15.md\n---\n# Overall Project Weekly Summary (Feb 15 - 21, 2026)\n\nThis week, ElizaOS entered a high-velocity phase as it prepared for its official beta launch. The team successfully cleared a massive backlog of technical hurdles while simultaneously expanding the framework's reach into everyday communication tools like WhatsApp and Gmail. By combining core infrastructure upgrades with new decentralized identity features, the project is positioning itself as a robust, secure, and highly adaptable home for the next generation of AI agents.\n\n## Executive Summary\nElizaOS shifted its focus toward a major beta release, prioritizing user onboarding and platform stability. The project achieved significant milestones by integrating popular messaging and productivity apps and launching new on-chain identity tools for agents on the Solana blockchain.\n\n### Key Strategic Initiatives & Outcomes\n\n**Preparing for the Beta Launch and Beyond**\n*Goal: To ensure the platform is stable, user-friendly, and ready for its first 100 official testers.*\n*   The team cleared dozens of functional blockers in [elizaos/eliza](https://github.com/elizaos/eliza), including fixing dashboard bugs and removing restrictive text limits to improve the user experience.\n*   A new \"Profile Plugin\" was proposed in [elizaos/eliza](https://github.com/elizaos/eliza) to automatically build user profiles from social media, making it easier for new users to get started immediately.\n*   Efforts are underway in [elizaos/eliza](https://github.com/elizaos/eliza) to refine the AI's personality, aiming for a more direct and engaging conversational style for the launch.\n\n**Expanding Agent Reach and Utility**\n*Goal: To allow AI agents to work across more platforms and handle more complex tasks.*\n*   Major integrations were finalized for WhatsApp, Gmail, and the N8N workflow engine in [elizaos/eliza](https://github.com/elizaos/eliza), allowing agents to communicate and automate tasks where users already work.\n*   The [elizaos-plugins/plugin-n8n-workflow](https://github.com/elizaos-plugins/plugin-n8n-workflow) repository added a new \"control panel\" (REST API), giving developers a way to manage complex workflows directly without needing to use natural language.\n*   The plugin registry in [elizaos-plugins/registry](https://github.com/elizaos-plugins/registry) saw a surge in new tools, particularly for Web3 and financial data exchanges.\n\n**Strengthening Security and Decentralization**\n*Goal: To give agents a verifiable identity and ensure the system remains secure as it grows.*\n*   The project introduced the SAID Protocol in [elizaos/eliza](https://github.com/elizaos/eliza) and [elizaos-plugins/registry](https://github.com/elizaos-plugins/registry), which gives agents a \"digital passport\" on the Solana blockchain for secure, verifiable actions.\n*   A security audit was completed for the Model Context Protocol in [elizaos/eliza](https://github.com/elizaos/eliza), ensuring that as agents share information, they do so safely.\n\n**Improving System Health and Maintenance**\n*Goal: To keep the project's \"engine\" running smoothly and make it easier for community members to contribute.*\n*   A major database overhaul was started in [elizaos/eliza](https://github.com/elizaos/eliza) to make the system faster and more reliable for the long term.\n*   Critical fixes to the automated review system in [elizaos-plugins/registry](https://github.com/elizaos-plugins/registry) ensured that outside contributors can have their work checked and merged more quickly.\n*   Routine but essential security updates were performed across the documentation site in [elizaos/elizaos.github.io](https://github.com/elizaos/elizaos.github.io) to keep the project's public face secure.\n\n### Cross-Repository Coordination\n*   **Unified Identity Standards**: The implementation of the SAID Protocol required synchronized work between the core framework [elizaos/eliza](https://github.com/elizaos/eliza) and the [elizaos-plugins/registry](https://github.com/elizaos-plugins/registry) to ensure agents can use their new on-chain identities across all plugins.\n*   **Workflow Automation**: The N8N workflow integration involved coordinated updates in the core repository [elizaos/eliza](https://github.com/elizaos/eliza) and the specific [elizaos-plugins/plugin-n8n-workflow](https://github.com/elizaos-plugins/plugin-n8n-workflow) repo to provide a seamless experience for managing complex AI tasks.\n*   **Automated Maintenance**: The team successfully fixed \"Renovate\" (an automated update tool) in [elizaos/eliza](https://github.com/elizaos/eliza), which now helps keep dependencies across the entire ecosystem up to date automatically.\n\n## Repository Spotlights\n\n### elizaos/eliza\n*   Initiated a major database refactor ([#6509](https://github.com/elizaos/eliza/pull/6509)) to improve long-term system architecture.\n*   Integrated the SAID Protocol for on-chain Solana identity ([#6510](https://github.com/elizaos/eliza/pull/6510)), enabling verifiable agent signatures.\n*   Finalized major integrations for WhatsApp ([#6401](https://github.com/elizaos/eliza/issues/6401)), Gmail ([#6404](https://github.com/elizaos/eliza/issues/6404)), and N8N ([#6429](https://github.com/elizaos/eliza/issues/6429)).\n*   Resolved critical automated update issues ([#6488](https://github.com/elizaos/eliza/issues/6488)) and enabled multi-language dependency management ([#6506](https://github.com/elizaos/eliza/pull/6506), [#6507](https://github.com/elizaos/eliza/pull/6507)).\n*   Added support for the Opus 4.5 model ([#6368](https://github.com/elizaos/eliza/issues/6368)) and Chain-of-Thought reasoning ([#6294](https://github.com/elizaos/eliza/issues/6294)).\n\n### elizaos-plugins/registry\n*   Expanded the ecosystem with new plugins including `@elizaos/plugin-said` ([#264](https://github.com/elizaos-plugins/registry/pull/264)) and several exchange-related tools ([#261](https://github.com/elizaos-plugins/registry/pull/261), [#262](https://github.com/elizaos-plugins/registry/pull/262)).\n*   Fixed a high-priority issue where the automated review system was blocking new contributions ([#259](https://github.com/elizaos-plugins/registry/issues/259)).\n*   Improved support for external contributors by fixing the review process for forked repositories ([#260](https://github.com/elizaos-plugins/registry/pull/260)).\n\n### elizaos-plugins/plugin-n8n-workflow\n*   Launched a comprehensive REST API for direct workflow management and monitoring ([#16](https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/16)).\n*   Fixed a critical bug in how the AI handles workflow properties, ensuring stability even when the AI provides incomplete data ([#18](https://github.com/elizaos-plugins/plugin-n8n-workflow/pull/18)).\n\n### elizaos-plugins/plugin-ollama\n*   Identified and began investigating a community-reported issue regarding embedding failures on Linux environments ([#17](https://github.com/elizaos-plugins/plugin-ollama/issues/17)).\n\n### elizaos/elizaos.github.io\n*   Maintained project health through routine dependency synchronization and version updates ([#242](https://github.com/elizaos/elizaos.github.io/pull/242)).\n---\n2026-02-01.md\n---\nNo activity recorded for 2026-02-01.\n---\n2026-03-18T08:49:40.291963+00:00Z\n---\n2026-03-18\n---\nelizaOS/knowledge\n---\nelizaOS\n---\nknowledge\n---\nai_news_elizaos_discord_md_2026-03-17\n---\nai_news_elizaos_discord_md_2026-03-16\n---\nai_news_elizaos_discord_md_2026-03-15\n---\nai_news_elizaos_daily_json_2026-03-17\n---\nai_news_elizaos_daily_md_2026-03-17\n---\nai_news_elizaos_daily_discord_json_2026-03-17\n---\nai_news_elizaos_daily_discord_md_2026-03-17\n---\ngithub_summaries_week_latest_2026-02-15.md\n---\ngithub_summaries_month_latest_2026-02-01.md\n---\ngithub_summaries_daily_2026-03-18"
  ]
}