▶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

Core technical foundation improvements and fixes for elizaOS are advancing while token migration issues threaten user trust and engagement with the ecosystem.

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 Crisis Management

Korean users are experiencing significant migration problems with Bithumb exchange, creating trust issues and frustration, while the continuous price decline of ELIZA raises questions about the migration strategy and transparency.

What immediate actions should be taken to address the Bithumb migration issue and rebuild trust with affected Korean users?

Korean users are experiencing significant problems with the ELIZA token migration on Bithumb exchange
Users expressed frustration about the continuous price decline of ELIZA

1Establish a dedicated compensation fund for affected Bithumb users and provide clear timeline commitments.

Allocating resources for compensation could strain treasury reserves but would demonstrate commitment to users affected by circumstances beyond their control.

2Deploy a specialized Korean-speaking community team with daily updates and a migration support hotline.

A dedicated, localized response team would improve communication and support but requires finding qualified staff and maintaining consistent messaging.

3Pressure Bithumb through coordinated community action and explore legal options to force resolution.

An aggressive approach might accelerate Bithumb's actions but risks escalating the situation and creating further tensions with the exchange.

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

How should we address the transparency concerns regarding the token migration process and supply changes?

Some users questioned whether migrated AI16Z tokens were sold instead of burned
Team shared the migrator wallet link to demonstrate transparency
Supply increased from 6.6B to 11B tokens (~40% increase), with 13% immediately entering circulation and 27% on a 3-year unlock schedule

1Publish a comprehensive audit report of all migration transactions with third-party verification.

A thorough audit would establish credibility but takes time and resources while revealing potentially sensitive treasury operations.

2Create a real-time dashboard showing token migration status, burns, and unlock schedules with educational content.

A transparent dashboard would improve ongoing trust but requires technical resources to build and maintain.

3Host an emergency AMA with treasury management team focusing exclusively on migration and tokenomics questions.

Direct engagement would address immediate concerns but could expose team to difficult questions without preparation time.

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

Technical Foundation Strengthening

The development team is making significant progress on core infrastructure with monorepo fixes, database optimizations, and standardization efforts, but performance bottlenecks and security concerns require attention.

How should we prioritize and balance the current technical improvements between infrastructure stability and new user-facing features?

Stan fixed critical issues in the monorepo (PR #6218) after Shaw's cleanup work broke types, tests, and try/catch blocks
Odilitime reported performance issues with pglite in their swarm environment (response times increasing from 10ms to 900ms)
Work began on two significant backend features with new pull requests for a unified serverless API (#6201) and a comprehensive JWT authentication and user management system (#6200)

1Focus exclusively on infrastructure and performance until all issues are resolved before adding features.

Prioritizing infrastructure would create a more stable foundation but delays visible progress that could attract users and developers.

2Split resources 50/50 between infrastructure improvements and new user-facing features to maintain momentum.

Balancing resources allows parallel progress but risks slower resolution of core issues and potential technical debt.

3Implement a rotating sprint focus alternating between infrastructure weeks and feature weeks.

A cyclical approach provides clear focus periods but creates potential context-switching overhead and scheduling complexities.

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

What database strategy should we adopt given the performance issues observed with pglite in the swarm environment?

Odilitime reported performance issues with pglite in their swarm environment (response times increasing from 10ms to 900ms)
Users discussed connecting ElizaOS to different databases (PGLite vs PostgreSQL)
sayonara helped FenrirFawks with database connection issues by suggesting PostgreSQL instead of PGLite

1Standardize on PostgreSQL for all production environments while keeping PGLite for development/testing.

Using PostgreSQL in production would improve performance but increases hosting complexity and costs.

2Optimize PGLite for scale through caching, connection pooling, and performance profiling.

Improving PGLite maintains simplicity but requires engineering resources and may not solve all scaling issues.

3Implement a tiered database strategy with automatic switching based on usage patterns and load.

An adaptive approach provides flexibility but adds complexity to the codebase and potential migration challenges.

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

How should we address the security vulnerability discovered in the previous week where secrets were exposed through API endpoints?

Critical security issue discovered: Jin conducted a security audit using Claude skills and found that the server doesn't require ELIZA_SERVER_AUTH_TOKEN, allowing attackers to extract secrets via API endpoints
The vulnerability stems from process.env being dumped into unencrypted settings instead of encrypted settings.secrets
fix: encryption for character secrets in correct order (PR #6217)

1Implement a comprehensive security audit program with regular third-party penetration testing.

A formal security program would systematically find vulnerabilities but requires significant investment and process changes.

2Create a dedicated security team focused on implementing zero-trust architecture throughout the codebase.

A specialized security team would bring expertise but increases organizational complexity and overhead.

3Establish a bug bounty program to incentivize community security researchers to find and report vulnerabilities.

A bug bounty leverages community expertise but requires careful management of disclosure and reward processes.

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

Product Launch Strategy

The ecosystem has multiple projects advancing toward launch, including Babylon as a web browser game and elizaOS Cloud integration, but clarity on timelines and feature sets remains limited.

How should we strategically sequence the launches of Babylon and elizaOS Cloud to maximize user engagement and ecosystem growth?

The Babylon repository has moved to a new GitHub location: https://github.com/BabylonSocial/babylon
Babylon will be launching as a web browser game rather than requiring local installation
Babylon project focused on autonomous agents with 275K registrations, but no launch date announced
ElizaOS Cloud: Originally promised for November, still in development with no specific launch date

1Launch Babylon first to leverage its 275K registrations, then release elizaOS Cloud as an infrastructure upgrade.

Prioritizing Babylon capitalizes on existing interest but could strain infrastructure without Cloud improvements in place.

2Release elizaOS Cloud first to establish a stable foundation, then launch Babylon as its first major application.

Infrastructure-first approach ensures stability but delays capitalizing on Babylon's registration momentum.

3Coordinate a simultaneous launch with Babylon as the flagship application powered by elizaOS Cloud.

A coordinated launch creates maximum marketing impact but increases complexity and risk of technical issues.

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

What specific UI/UX improvements should be prioritized to enhance user experience across the ecosystem products?

Using Eliza for Twitter now is so convoluted... like I have all these settings and it's still not posting, what's preventing it?
Current agent system lacks composability
The user-facing client was improved with fixes to markdown rendering. These changes addressed excessive vertical spacing in AI-generated responses, particularly around headings and blockquotes, for better visual consistency

1Focus on simplifying social media integration workflows, especially Twitter posting functionality.

Improving social media integration would enhance viral growth potential but narrows focus to specific use cases.

2Create a unified dashboard that centralizes control of all agents and services with consistent UI patterns.

A unified dashboard would improve overall usability but requires significant design and implementation resources.

3Develop guided wizards and templates for common agent creation and configuration scenarios.

Wizard-based approaches would help new users but might constrain flexibility for power users.

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

Council Briefing

North Star & Strategic Context

Key Deliberations