Council Briefing

Strategic Deliberation
▶North Star & Strategic Context

North Star & Strategic Context



This file combines the overall project mission (North Star) and summaries of key strategic documents for use in AI prompts, particularly for the AI Agent Council context generation.

---

North Star: To build a truly autonomous, sustainable DAO that develops open-source software accelerating the path toward AGI, blending AI researchers, open-source hackers, and crypto degens to create AI agents streaming, shitposting, and trading 24/7 on auto.fun to attract users and bootstrap an autonomous organization.

---

ElizaOS Mission Summary (`docs/blog/mission.mdx`): The elizaOS mission is to build an extensible, modular, open-source AI agent framework for Web2/Web3, seeing agents as steps toward AGI. Core values are Autonomy, Modularity, and Decentralization. Key products include the framework itself, DegenSpartanAI (trading agent), Autonomous Investor/Trust Marketplace (social trading intelligence), and the Agent Marketplace/auto.fun (launchpad).

---

ElizaOS Reintroduction Summary (`docs/blog/reintroduction.mdx`): elizaOS is an open-source "operating system for AI agents" aimed at decentralizing AI development away from corporate control. It's built on three pillars: 1) The Eliza Framework (TypeScript toolkit for persistent, interoperable agents), 2) AI-Enhanced Governance (building autonomous DAOs), and 3) Eliza Labs (R&D for future capabilities like v2, Trust Marketplace, auto.fun, DegenSpartanAI, Eliza Studios). The native Solana token coordinates the ecosystem and captures value. The vision is an intelligent internet built on open protocols and collaboration.

---

Auto.fun Introduction Summary (`docs/blog/autofun-intro.mdx`): Auto.fun is an AI-native, creator-first token launchpad designed for sustainable AI/crypto projects. It aims to balance fair community access with project funding needs through mechanisms like bonding curves and liquidity NFTs. Key features include a no-code agent builder, AI-generated marketing tools, and integration with the elizaOS ecosystem. It serves as a core product driving value back to the native token ($ai16z) through buybacks and liquidity pairing.

---

Taming Information Summary (`docs/blog/taming_info.mdx`): Addresses the challenge of information scattered across platforms (Discord, GitHub, X). Proposes using AI agents as "bridges" to collect, wrangle (summarize/tag), and distribute information in various formats (JSON, MD, RSS, dashboards, 3D shows). Showcases an AI News system and AI Assistants for tech support as examples. Emphasizes treating documentation as a first-class citizen to empower AI assistants and streamline community operations.
▶Daily Strategic Focus
The organization is balancing critical token migration operations with strategic technical development on cross-platform capabilities and core security enhancements.
Monthly Goal
Current focus: Stabilize and attract new users to auto.fun by showcasing 24/7 agent activity (streaming, trading, shitposting), ship production ready elizaOS v2.

Key Deliberations

Token Migration Resilience
The ongoing migration from ai16z to elizaOS tokens has created technical challenges and communication issues that require strategic attention to maintain community trust during this transition period.
Q1
How should we prioritize migration portal improvements versus developing clearer communication channels to mitigate user frustration?
  • Multiple users reported migration portal issues where tokens aren't showing up after wallet connection
  • Junaid Ali expressed concerns about the legitimacy of manual migration instructions in support tickets
1Prioritize technical fixes to the migration portal, ensuring reliable wallet connections and snapshot validation.
This would minimize the need for manual migration processes but might delay addressing immediate user concerns.
2Focus on comprehensive documentation and official guides for both automatic and manual migration processes.
This approach acknowledges technical limitations but ensures users have clear, trustworthy guidance through any pathway.
3Implement a hybrid approach with temporary community-led support teams while developing both portal fixes and documentation simultaneously.
This distributes effort across multiple fronts but risks diluting resources needed for elizaOS v2 development.
4Other / More discussion needed / None of the above.
Q2
What post-migration value-generating mechanisms should we prioritize to maintain momentum after the February 5, 2026 deadline?
  • Rainman asked about developing farming options for elizaOS tokens
  • Odilitime mentioned that the migration portal will remain open until February 5, 2026
1Prioritize farming/staking options for elizaOS tokens to create immediate utility and reward early adopters.
This creates clear token utility but might divert resources from core product development.
2Focus on integrating elizaOS tokens as the primary currency for Eliza Cloud services with token buyback mechanisms.
This aligns token value with product growth but benefits may not be immediate enough to maintain community engagement.
3Develop auto.fun integration that showcases how elizaOS tokens unlock premium agent features and creator revenues.
This directly supports our monthly goal of attracting new users to auto.fun while creating token utility.
4Other / More discussion needed / None of the above.
Cross-Platform Agent Strategy
Technical discussions reveal opportunities to expand elizaOS agent capabilities across browsers, iOS, and blockchain platforms, but require strategic decisions about resource allocation and security models.
Q3
Should we prioritize browser-based TEE capabilities to expand elizaOS to iOS, or focus on stabilizing the current runtime across existing platforms?
  • DorianD asked: Can ElizaOS runtime run in browser to make a dedicated iOS app using TEE tech for agent enclaves?
  • cjft confirmed: Core works in browser now fully, as well as wasm pglite plugin-sql, Eliza runtime runs in browser now yes just some plugins not migrated to browser compat
1Prioritize browser-TEE research and development to unlock iOS capabilities, creating a true cross-platform presence.
This expands our addressable market but may introduce new security challenges and divert resources from core stability.
2Focus on completing the browser plugin migration first, then systematically address TEE implementation as a separate milestone.
This ensures stable cross-platform behavior before attempting more advanced security models.
3Develop a hybrid approach where select plugins are prioritized for both browser compatibility and TEE support based on auto.fun user needs.
This targets our efforts toward supporting the monthly goal of showcasing 24/7 agent activity on auto.fun.
4Other / More discussion needed / None of the above.
Q4
How should we approach the integration of blockchain protocols like Babylon's EIP-8004 implementation into our core codebase?
  • DorianD asked about EIP-8004 support in Babylon's implementation
  • Questions raised about potential collaboration with a team working on Eigen Layer integration
1Fully integrate blockchain protocol support into the core codebase, making it a first-class feature of elizaOS.
This strengthens our crypto-native positioning but increases complexity of the core system.
2Keep blockchain protocol support entirely in plugins, maintaining a clean separation between core runtime and blockchain capabilities.
This preserves core simplicity but might create adoption friction for crypto-oriented developers.
3Implement a hybrid approach with minimal core support for key standards like EIP-8004, while keeping implementation details in plugins.
This balances the desire for clean architecture with the need for native Web3 capabilities.
4Other / More discussion needed / None of the above.
Technical Debt & Security Focus
The team is making significant progress on core development while addressing technical debt and security concerns, requiring strategic decisions about resource allocation between stability and new features.
Q5
How should we balance security hardening initiatives with the delivery of new features for elizaOS v2?
  • Stan completed E2E authentication tests for Entity/server isolation
  • Kenk mentioned that they are prioritizing security measures due to increased scammer activity
  • Work continues on PR #6135 with Stan taking over from Odilitime
1Establish a security-first approach, delaying feature releases until core security measures are fully implemented and tested.
This creates a more robust foundation but could delay attracting new users to auto.fun with new features.
2Implement a parallel track system with dedicated resources for security and separate teams focusing on user-facing features.
This maintains development velocity but requires more coordination and may lead to integration challenges.
3Adopt a risk-based prioritization model where security features are evaluated against user impact and implemented accordingly.
This allows for balanced progress but requires sophisticated risk assessment capabilities.
4Other / More discussion needed / None of the above.
Q6
How should we structure the developer onboarding experience to balance technical depth with accessibility?
  • vaipraonde helped amnesia understand the prerequisites for ElizaOS development, clarifying that TypeScript knowledge is needed but React/Solidity aren't required initially
  • ElizaOS is positioned as an agent framework rather than a traditional bot platform
  • Official documentation at Eliza.how is recommended for proper onboarding
1Focus on comprehensive documentation with clear progression paths from beginner to advanced use cases.
This creates a smoother learning curve but requires significant documentation maintenance resources.
2Develop a tiered approach with simplified no-code tools for beginners and comprehensive TypeScript APIs for advanced users.
This broadens accessibility but may fragment the developer experience and maintenance burden.
3Create scenario-based learning paths that introduce concepts gradually through practical agent implementation examples.
This bridges theory and practice but may be harder to keep synchronized with API changes.
4Other / More discussion needed / None of the above.