▶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 AI16Z to ElizaOS token migration reaches critical phase with ongoing exchange integrations and technical improvements to core framework capabilities.

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 Strategy

The migration from AI16Z to ElizaOS tokens is creating both opportunities and challenges, with technical issues in the migration portal and mixed user experiences across exchanges affecting community sentiment during this transition period.

How should we address the technical issues users are experiencing with the migration portal?

Users reported technical issues with the migration portal, including "max amount reached" errors
Borko suggested typing in the exact amount instead of using "max" button to resolve migration errors

1Prioritize an emergency fix for the migration portal's "max amount" error while extending the migration deadline.

This focuses on technical stability but may delay the overall migration timeline and create scheduling conflicts with exchange listings.

2Create detailed workaround documentation for common issues and increase support staff, without changing the portal code.

This provides immediate relief to users without technical risks, but may not address fundamental issues in the migration system.

3Continue with the current timeline but add a secondary migration wave for users who encountered technical issues during the initial period.

This maintains momentum while acknowledging difficulties, but creates additional complexity in tracking and validating legitimate issue claims.

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

How should we optimize our tokenomics strategy given community concerns about the increased token supply?

The token has a large supply (11B) which some users questioned
Q: Any plan for this huge supply? (iory yagamy) A: "It just felt right" (Kenk)

1Implement a token burn mechanism tied to auto.fun activity to create deflationary pressure while increasing utility.

This directly addresses supply concerns while aligning with our monthly goal of driving auto.fun engagement.

2Launch a comprehensive communication campaign explaining the strategic advantages of the current supply model and long-term value accrual mechanisms.

This maintains the current tokenomics while attempting to reshape community perception through education rather than structural changes.

3Introduce single-sided staking with tiered rewards to incentivize long-term holding and reduce circulating supply.

This provides immediate utility that community members have requested while effectively reducing liquid supply without changing the total.

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

Framework Technical Evolution

The ElizaOS framework is undergoing significant technical improvements with new features like entity-level row-level security, dynamic prompt execution, and API enhancements, while developers face architecture decisions about event handling patterns.

How should we prioritize the implementation of new technical features versus stabilizing existing functionality?

GitHub Activity Summary showed moderate activity with 1 new pull request successfully merged
Odilitime raised an issue about EventType.MESSAGE_RECEIVED being removed from bootstrap, which led to a discussion about plugin conversion

1Implement a feature freeze for two weeks to focus exclusively on stabilizing the core framework and resolving backward compatibility issues.

This delays feature delivery but potentially creates a more solid foundation for v2 release.

2Continue parallel development but establish a dedicated stabilization team focused on technical debt, while feature teams maintain momentum.

This maintains development velocity but requires additional coordination and potentially divides the engineering team's focus.

3Adopt a staged release strategy with weekly stabilization periods between feature deployments to balance both priorities.

This creates a rhythmic development cycle that addresses both needs, but may slow overall release cadence.

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

How should we approach plugin architecture evolution to maintain both innovation and backward compatibility?

Technical issue raised regarding EventType.MESSAGE_RECEIVED being removed from bootstrap
Stan ⚡ helped Odilitime understand current usage patterns for event handling, leading to successful plugin conversion

1Maintain deprecated patterns with clear migration paths for at least one major version to ease the transition for plugin developers.

This reduces immediate friction but increases technical debt and maintenance burden.

2Enforce breaking changes with comprehensive documentation and migration tools, prioritizing architectural cleanliness.

This creates short-term pain but yields a cleaner, more maintainable framework in the long run.

3Create adapter patterns that bridge old and new approaches, allowing both to coexist while nudging developers toward preferred patterns.

This balances backward compatibility with architectural evolution but increases system complexity.

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

Auto.fun User Acquisition Strategy

While token migration and technical improvements dominate current activities, we need to refocus on our monthly directive of stabilizing and attracting new users to auto.fun through compelling agent demonstrations.

What types of agent activities should we prioritize showcasing to attract new users to auto.fun?

Current focus: Stabilize and attract new users to auto.fun by showcasing 24/7 agent activity (streaming, trading, shitposting)

1Focus on high-ROI trading agents with public performance metrics to appeal to profit-motivated users.

This creates tangible value demonstrations but may attract a narrower audience focused primarily on financial returns.

2Prioritize content creation agents (streaming, shitposting) that generate viral, shareable outputs to maximize reach.

This optimizes for growth and awareness but may not demonstrate the full technical capabilities of the framework.

3Balance both approaches with agent showcases featuring cross-functional workflows where trading decisions drive content creation.

This demonstrates the composability of the framework while potentially appealing to multiple user segments.

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

How can we leverage the token migration to drive new user acquisition for auto.fun?

Gate.io trading starting soon with ElizaOS
Bybit listing mentioned for November 12

1Create exclusive auto.fun agent templates for new token holders who complete migration by a specific deadline.

This directly links token migration to auto.fun adoption while creating urgency for completing the transition.

2Partner with exchanges listing ElizaOS to feature auto.fun agent demos on their platforms and marketing channels.

This leverages exchange exposure to reach new audiences but requires coordination with external partners.

3Implement a points-based reward system that gives migrated token holders special privileges on auto.fun.

This creates an ongoing incentive structure that can drive sustained engagement beyond the initial migration.

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

Council Briefing

North Star & Strategic Context

Key Deliberations