▶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

Babylon project is experiencing explosive growth with 60k+ waitlist signups, but faces technical scaling challenges that require immediate optimization to control costs and improve performance.

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

Babylon Growth & Optimization Strategy

The Babylon project has gained significant traction with over 60k waitlist signups but is facing technical bottlenecks and high infrastructure costs ($1k on Vercel) due to inefficient API code and excessive bandwidth usage (3.42TB).

How should we balance accommodating the influx of users (many of whom are airdrop farmers) with the immediate need to optimize infrastructure costs?

cjft: 90% are airdrop farmers from Indonesia/India, but they're real humans
cjft: 3.42 TB, 99.4% of allocation (answering about Babylon bandwidth usage)

1Implement immediate technical optimizations (caching, pagination) first, then focus on user quality filtering once costs are under control.

Prioritizes financial sustainability but delays addressing user quality issues that might affect product engagement metrics.

2Deploy a scoring system (like Neynar) to filter out low-quality users while simultaneously optimizing the infrastructure.

Balances both concerns but increases implementation complexity and may slow down the overall resolution timeline.

3Cap new signups temporarily while optimizing the system, then reopen with stronger verification requirements.

Provides immediate cost control but risks losing momentum and potentially valuable users in a competitive market.

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

Should we restructure Babylon as "Babylon Labs" with Eliza as an API service, and if so, what should be our approach to this strategic pivot?

Consideration of spinning out Babylon as "Babylon Labs" and potentially integrating Eliza as an API service

1Fully restructure immediately to position Babylon Labs as a separate entity with Eliza as its infrastructure backbone.

Creates clear product differentiation but requires significant resources and might distract from core elizaOS v2 development.

2Implement a gradual transition where Babylon remains integrated while we develop and test the API service approach.

Reduces risk and allows for validation, but might create technical debt from maintaining dual architectures.

3Maintain the current integration but rebrand as Babylon Labs to signal the project's growing importance while evaluating technical architecture separately.

Leverages branding momentum while deferring technical decisions, potentially missing early optimization opportunities.

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

What technical improvements should we prioritize for Babylon's backend to better support its rapid growth?

cjft identified optimization opportunities for the Babylon project's high Vercel costs and offered to fix the code, working on pagination and reducing fetch size
Code is fetching 100 items instead of 10 and missing pagination, contributing to 3.42TB bandwidth usage

1Implement aggressive caching and optimize API endpoints to immediately reduce bandwidth and computation costs.

Addresses immediate cost concerns but may require future architectural changes for true scalability.

2Develop a comprehensive plugin loader system for custom agents through API alongside pagination fixes.

Balances immediate optimizations with longer-term extensibility, potentially enabling faster future development.

3Rebuild the backend with more scalable architecture (serverless functions, edge computing) to handle growth beyond current metrics.

Provides the most robust long-term solution but requires significant development time and might delay addressing immediate issues.

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

Token Migration Challenges

The AI16Z to ElizaOS token migration is facing significant user confusion and technical challenges, particularly with exchange support, eligibility criteria, and communication clarity.

How should we address the communication issues surrounding token migration, particularly regarding exchange support and eligibility criteria?

Korean investors expressed confusion about Bithumb potentially not supporting the token swap for AI16Z tokens acquired after November 11, 2025, 11:40 UTC
Questions raised about whether the ElizaOS team properly communicated with exchanges before the snapshot

1Create a comprehensive, multi-language migration guide with explicit timelines, exchange status, and eligibility criteria.

Improves clarity but doesn't address root issues with exchange coordination or technical implementation.

2Establish direct communication channels with exchanges and extend migration deadlines to ensure broader support and clearer messaging.

Addresses both communication and implementation issues but may delay project timeline and create dependency on external parties.

3Implement manual migration support for all users regardless of exchange, while improving documentation and communication moving forward.

Provides immediate relief to affected users but significantly increases operational overhead and may create scaling challenges.

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

What technical approach should we take for handling migrations from exchanges that don't support the token swap process?

Team will handle manual migrations for users whose exchanges don't support the token swap
Omid Sa (community member) provided extensive assistance to multiple users

1Develop an automated verification system that can validate exchange transactions and process migrations without manual review.

Scales efficiently but increases technical complexity and potential security risks if not implemented carefully.

2Create a dedicated migration support team with clear processes, prioritizing larger exchanges and gradually extending to smaller ones.

Balances manual effort with systematic approach but requires significant staff resources during the migration period.

3Partner with specific migration-supporting exchanges to facilitate transfers, incentivizing users to move their tokens to these platforms.

Reduces direct operational burden but may frustrate users and create dependency on exchange partnerships.

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

Security & Technical Debt

The project faces ongoing security concerns with the Sha1-Hulud pt2 vulnerability affecting dependencies, while also needing to balance between shipping production-ready elizaOS v2 and addressing technical debt.

How should we prioritize security scanning and vulnerability remediation against the pressure to ship elizaOS v2?

Sha1-Hulud pt2 Attack: Team discussed security concerns affecting dependencies
Stan ran security scans on eliza and eliza-cloud-v2 projects to check for vulnerabilities

1Implement a dedicated security sprint to comprehensively address all vulnerabilities before continuing feature development.

Prioritizes security but may delay the elizaOS v2 release timeline specified in our monthly goal.

2Adopt a risk-based approach, immediately fixing critical vulnerabilities while addressing moderate ones in parallel with development.

Balances security and development but requires careful coordination and may still introduce some delay.

3Focus on completing elizaOS v2 feature development with targeted security fixes only for components directly in the release path.

Maintains development velocity but may leave security vulnerabilities in peripheral systems that could impact reputation.

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

What strategy should we adopt for managing our GitHub repository's technical debt versus new feature development?

Key Developments: A major effort was completed to enhance the stability of `@elizaos/core` by migrating from the deprecated `langchain` v0.3 to `@langchain/textsplitters v1.0`
The week saw minimal activity with no new pull requests opened or merged, no new issues created, and only 1 active contributor during this period.

1Allocate 20% of development capacity specifically to technical debt reduction while maintaining feature development velocity.

Creates sustainable balance but slightly slows down new feature delivery in the short term.

2Focus entirely on shipping elizaOS v2, then dedicate a full engineering sprint to technical debt immediately after release.

Accelerates product delivery but risks compounding technical issues that might be harder to fix post-release.

3Integrate technical debt reduction into feature work by requiring refactoring of adjacent code when implementing new features.

Gradually improves codebase health without explicit allocation but may lead to inconsistent debt reduction.

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

Council Briefing

North Star & Strategic Context

Key Deliberations