▶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

Token migration challenges with exchange Bithumb are creating community friction while core development continues on elizaOS v2 features and security improvements.

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 Communication Strategy

The token migration from AI16Z to elizaOS is facing challenges due to miscommunication with exchanges, particularly Bithumb, creating confusion and frustration among users who traded after the November 11th snapshot.

How should we address the Bithumb exchange token migration controversy to maintain community trust?

Major controversy emerged regarding Korean exchanges (particularly Bithumb) where users claim the exchange announced full migration support but later backtracked
Team maintains that tokens purchased after the snapshot date won't be migrated

1Provide compensation for affected users who purchased tokens after the snapshot date due to Bithumb's miscommunication.

Sets precedent for financial intervention in exchange miscommunications, potentially creating additional liability but rebuilding immediate trust.

2Maintain the strict snapshot policy but improve transparency by publishing all communications with exchanges and creating a detailed timeline document.

Preserves token economics and fairness to pre-snapshot holders while addressing trust through transparency rather than exceptions.

3Extend the migration window and work with Bithumb to develop a special process for affected Korean users to verify purchase intent before the snapshot.

Balances community goodwill with economic considerations by offering process-based rather than blanket solutions.

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

What measures should we implement to prevent similar migration issues with exchanges in the future?

Q: Did the team inform Bithumb immediately after taking the snapshot? A: "Of course we did" (jasyn_bjorn)
Users are frustrated about who bears responsibility for tokens traded after the snapshot date

1Create a formalized exchange communication protocol with signed agreements, mandatory public announcements, and a verification system for exchange compliance.

Establishes clear accountability but requires significant administrative overhead and potential legal frameworks.

2Implement a gradual token migration process with multiple phases and warnings rather than a single snapshot date.

Reduces the impact of communication failures but extends the migration timeline and increases technical complexity.

3Develop a direct-to-holder airdrop approach for future token migrations that bypasses exchanges entirely.

Eliminates exchange communication dependencies but may exclude users who prefer exchange custody and requires advanced on-chain verification mechanisms.

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

ElizaOS V2 Development Progress

Core development for elizaOS v2 is advancing with significant feature work focused on enhanced security through entity-level row level security (RLS), performance optimization, and new features like cryptocurrency payment support for credits.

How should we prioritize the development pipeline to meet the monthly goal of shipping production-ready elizaOS v2?

PR #6170 titled 'fix(core): resolve TS2358 instanceof error' by @standujar is merged, addressing a TypeScript instanceof error in the core module
Stan requested a review for a pull request (#6170) that addresses a breaking build issue. The PR was described as a "quick hotfix" requiring urgent attention

1Focus on stabilizing the core system by prioritizing bug fixes and addressing technical debt before adding new features.

Improves platform stability but delays feature releases that could attract new users to auto.fun.

2Accelerate user-facing features for auto.fun integration like the crypto payments system and inline image/video generation to drive adoption.

Potentially increases user engagement but risks building on an unstable foundation if core issues aren't addressed.

3Establish parallel workstreams with dedicated teams for core stability, security enhancements, and user-facing features with a unified weekly integration cycle.

Balances progress across all fronts but requires more coordination overhead and careful integration testing.

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

What approach should we take to security enhancements like entity-level RLS while maintaining backward compatibility?

standujar: Focused on significant feature development, opening a substantial PR in elizaos/eliza (#6167) for entity-level RLS and security improvements, which involved modifying 88 files with a net reduction of over 5900 lines, primarily in code and tests
Issue #6191 titled 'Crypto Payments for Credits' by @borisudovicic is OPEN

1Implement security features as opt-in capabilities with clear migration paths for existing deployments.

Reduces disruption risk but creates a bifurcated ecosystem with varying security levels.

2Make security enhancements mandatory with comprehensive automated migration tools and extensive testing across deployment scenarios.

Ensures consistent security posture but could delay release if migration edge cases prove difficult to resolve.

3Phase in security features gradually through feature flags, with a defined timeline to make them mandatory after sufficient real-world validation.

Balances security improvements with deployment flexibility but extends the period of security inconsistency across the ecosystem.

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

Babylon Project Integration

The Babylon project has gained significant traction with 100k+ signups but faces scaling challenges with high Vercel costs and bandwidth usage, while also presenting opportunities to integrate with elizaOS and potentially spin out as "Babylon Labs."

How should we position the Babylon project within the elizaOS ecosystem to maximize synergy with auto.fun?

Babylon.market: Mentioned as a joint venture with Ethereum developers for agent infrastructure, training, and benchmarking
Consideration of spinning out Babylon as "Babylon Labs" and potentially integrating Eliza as an API service

1Fully integrate Babylon with auto.fun as a unified platform, combining their waitlists and user acquisition efforts.

Creates a more cohesive product story but potentially dilutes the distinct value propositions of each platform.

2Position Babylon Labs as a separate research entity that feeds innovations into auto.fun while maintaining its Ethereum ecosystem connections.

Preserves Babylon's research independence and Ethereum connections while establishing a clear innovation pipeline to auto.fun.

3Merge the technical infrastructure but maintain separate branding, with Babylon focusing on AI agent training/benchmarking and auto.fun on deployment/monetization.

Optimizes development resources while creating a clear funnel from agent creation (Babylon) to deployment (auto.fun).

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

What technical approach should we take to address Babylon's scaling issues while preparing for integration with elizaOS?

High Traffic Success: Babylon has gained 60k+ waitlist signups, though many are likely airdrop farmers
Performance Issues: The project is facing significant Vercel costs ($1k) due to inefficient API code

1Implement immediate tactical optimizations (caching, pagination) while designing a complete backend rewrite using elizaOS core components.

Addresses short-term cost concerns while paving the way for deeper integration but requires maintaining parallel codebases temporarily.

2Migrate Babylon to a serverless architecture optimized for bursty traffic while progressively adopting elizaOS APIs for agent functionality.

Improves cost scaling characteristics while allowing for gradual integration without disrupting the existing user experience.

3Pause new Babylon signups to focus on a rapid, complete migration to elizaOS architecture before scaling further.

Creates the most technically cohesive solution but risks losing momentum and community interest during the migration period.

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

Council Briefing

North Star & Strategic Context

Key Deliberations