▶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

ElizaOS Cloud beta successfully launched at Devconnect, marking a significant step toward production-ready v2 while concurrent efforts to strengthen security through entity-level RLS and address token migration issues demonstrate balanced progress on product development and ecosystem stability.

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

ElizaOS Cloud Beta Launch

The successful beta launch of ElizaOS Cloud at Devconnect represents a milestone in our v2 readiness, but requires clear documentation and technical integration paths to fully engage our developer community.

How should we prioritize documentation development for ElizaOS Cloud to maximize developer onboarding?

User DorianD reported testing the platform and setting up an agent called 'Shilltoshi Nekomoto'
A request was made for documentation similar to ChainOpera's MCP servers

1Focus on technical integration guides similar to ChainOpera's documentation first, targeting experienced developers.

Accelerates integration by skilled developers but may limit broader adoption from less technical users.

2Prioritize use-case tutorials and agent creation examples to showcase practical applications.

Drives adoption through demonstrated value but might delay technical integrations requiring deeper documentation.

3Develop comprehensive API reference documentation first, then expand to tutorials and examples.

Ensures technical completeness but might not effectively showcase the platform's capabilities to potential users.

4Other / More discussion needed / None of the above.

What features should we prioritize to differentiate ElizaOS Cloud from competing AI platforms?

User 'jin' shared experience using LM Studio as an alternative to Ollama for local AI model hosting
Confirmed that plugin-local-ai integration works with LM Studio using an OpenAI-like interface

1Multi-model flexibility and local AI integration options (Ollama, LM Studio) to reduce vendor lock-in.

Appeals to technical users concerned with sovereignty but increases testing and maintenance complexity.

2Web3-native features like token gating, on-chain verification, and crypto payment rails.

Creates unique value proposition in the crypto ecosystem but potentially narrows initial audience.

3Focus on agent-to-agent communication, autonomous workflows, and persistence mechanisms.

Highlights our core strengths in autonomous systems but may require deeper technical understanding from users.

4Other / More discussion needed / None of the above.

Security Architecture Evolution

The PR for entity-level Row Level Security (RLS) represents a significant advancement in our multi-tenant security model, providing database-level isolation between different entities within the same ElizaOS instance.

How should we balance security enhancements like Entity-level RLS with performance considerations?

PR #6167 titled 'feat: Entity-level RLS & Security Improvements' by @standujar is in an unknown state
This PR implements four major improvements to ElizaOS's security, data architecture, and observability

1Implement full security features by default, with options to disable for performance-sensitive deployments.

Maximizes security posture by default but may create friction for high-performance use cases.

2Make security features opt-in through configuration flags, allowing granular control based on deployment needs.

Provides flexibility but risks deployments with insufficient security if users don't enable protections.

3Create tiered security profiles (basic, standard, enterprise) with pre-configured security/performance tradeoffs.

Simplifies configuration decisions but may not address specific deployment requirements.

4Other / More discussion needed / None of the above.

Should we incorporate the Entity-level RLS architecture into auto.fun as a competitive differentiator for our platform?

Added three-layer security model: Server RLS (multi-tenant isolation) + Entity RLS (user privacy) + Application Layer (authorization)
Mentioned zero configuration required - just update and restart

1Yes, emphasize our multi-layer security model as a key differentiator for projects requiring stronger data isolation.

Creates unique value proposition for security-conscious projects but must ensure it doesn't impede performance for auto.fun agents.

2No, keep security implementations distinct from auto.fun's value proposition to avoid technical complexity in marketing.

Maintains focus on auto.fun's core value but misses opportunity to highlight enterprise-grade security capabilities.

3Selectively incorporate only the performance-optimized aspects of RLS into auto.fun's marketing narrative.

Balances technical differentiation with user experience but requires careful messaging to avoid confusion.

4Other / More discussion needed / None of the above.

Token Migration & Ecosystem Trust

Ongoing token migration from AI16Z to ElizaOS has created community confusion and security concerns, requiring clear communication to prevent scams and maintain trust in the ecosystem.

What approach should we take regarding token migration deadlines given the challenges with exchange support?

Clarification that migration deadlines can be extended if needed
Q: Should we wait for Kraken's announcement about migration support? A: Yes, the deadline can be extended if needed (answered by Omid sa)

1Announce an official extension of the migration deadline until all major exchanges have implemented support.

Relieves user anxiety but might reduce urgency and slow overall migration progress.

2Maintain the current deadline but establish a clear exception process for users with tokens on non-supporting exchanges.

Preserves migration momentum while providing safety net for users with legitimate barriers to migration.

3Set a final extended deadline with progressive incentives that decrease as the deadline approaches.

Creates clear urgency while still accommodating delays, but adds complexity to the migration process.

4Other / More discussion needed / None of the above.

How can we better protect our community from token-related scams while maintaining ecosystem growth?

Warning about a fake 'ElizaOS Cloud' token on Solana that is not affiliated with the project
Reminder that only tokens listed in the official channel (#1285103549944168450) are legitimate
Multiple scam warnings about direct messages claiming to be from the team

1Implement a verified token registry on-chain that applications can query to confirm legitimate tokens.

Creates trustless verification system but requires technical integration and maintenance.

2Develop a comprehensive scam education program with regular community alerts and automated detection tools.

Empowers users through education but places responsibility on them to identify scams.

3Partner with key exchanges and wallet providers to implement token verification systems that flag unofficial tokens.

Leverages existing infrastructure but depends on third-party cooperation and implementation timelines.

4Other / More discussion needed / None of the above.

Council Briefing

North Star & Strategic Context

Key Deliberations