# Council Briefing: 2025-11-25 ## 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. ## Daily 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. ## Key Points for Deliberation ### 1. Topic: Babylon Growth & Optimization Strategy **Summary of Topic:** 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). #### Deliberation Items (Questions): **Question 1:** How should we balance accommodating the influx of users (many of whom are airdrop farmers) with the immediate need to optimize infrastructure costs? **Context:** - `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)` **Multiple Choice Answers:** a) Implement immediate technical optimizations (caching, pagination) first, then focus on user quality filtering once costs are under control. *Implication:* Prioritizes financial sustainability but delays addressing user quality issues that might affect product engagement metrics. b) Deploy a scoring system (like Neynar) to filter out low-quality users while simultaneously optimizing the infrastructure. *Implication:* Balances both concerns but increases implementation complexity and may slow down the overall resolution timeline. c) Cap new signups temporarily while optimizing the system, then reopen with stronger verification requirements. *Implication:* Provides immediate cost control but risks losing momentum and potentially valuable users in a competitive market. d) Other / More discussion needed / None of the above. **Question 2:** 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? **Context:** - `Consideration of spinning out Babylon as "Babylon Labs" and potentially integrating Eliza as an API service` **Multiple Choice Answers:** a) Fully restructure immediately to position Babylon Labs as a separate entity with Eliza as its infrastructure backbone. *Implication:* Creates clear product differentiation but requires significant resources and might distract from core elizaOS v2 development. b) Implement a gradual transition where Babylon remains integrated while we develop and test the API service approach. *Implication:* Reduces risk and allows for validation, but might create technical debt from maintaining dual architectures. c) Maintain the current integration but rebrand as Babylon Labs to signal the project's growing importance while evaluating technical architecture separately. *Implication:* Leverages branding momentum while deferring technical decisions, potentially missing early optimization opportunities. d) Other / More discussion needed / None of the above. **Question 3:** What technical improvements should we prioritize for Babylon's backend to better support its rapid growth? **Context:** - `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` **Multiple Choice Answers:** a) Implement aggressive caching and optimize API endpoints to immediately reduce bandwidth and computation costs. *Implication:* Addresses immediate cost concerns but may require future architectural changes for true scalability. b) Develop a comprehensive plugin loader system for custom agents through API alongside pagination fixes. *Implication:* Balances immediate optimizations with longer-term extensibility, potentially enabling faster future development. c) Rebuild the backend with more scalable architecture (serverless functions, edge computing) to handle growth beyond current metrics. *Implication:* Provides the most robust long-term solution but requires significant development time and might delay addressing immediate issues. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Token Migration Challenges **Summary of Topic:** The AI16Z to ElizaOS token migration is facing significant user confusion and technical challenges, particularly with exchange support, eligibility criteria, and communication clarity. #### Deliberation Items (Questions): **Question 1:** How should we address the communication issues surrounding token migration, particularly regarding exchange support and eligibility criteria? **Context:** - `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` **Multiple Choice Answers:** a) Create a comprehensive, multi-language migration guide with explicit timelines, exchange status, and eligibility criteria. *Implication:* Improves clarity but doesn't address root issues with exchange coordination or technical implementation. b) Establish direct communication channels with exchanges and extend migration deadlines to ensure broader support and clearer messaging. *Implication:* Addresses both communication and implementation issues but may delay project timeline and create dependency on external parties. c) Implement manual migration support for all users regardless of exchange, while improving documentation and communication moving forward. *Implication:* Provides immediate relief to affected users but significantly increases operational overhead and may create scaling challenges. d) Other / More discussion needed / None of the above. **Question 2:** What technical approach should we take for handling migrations from exchanges that don't support the token swap process? **Context:** - `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` **Multiple Choice Answers:** a) Develop an automated verification system that can validate exchange transactions and process migrations without manual review. *Implication:* Scales efficiently but increases technical complexity and potential security risks if not implemented carefully. b) Create a dedicated migration support team with clear processes, prioritizing larger exchanges and gradually extending to smaller ones. *Implication:* Balances manual effort with systematic approach but requires significant staff resources during the migration period. c) Partner with specific migration-supporting exchanges to facilitate transfers, incentivizing users to move their tokens to these platforms. *Implication:* Reduces direct operational burden but may frustrate users and create dependency on exchange partnerships. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Security & Technical Debt **Summary of Topic:** 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. #### Deliberation Items (Questions): **Question 1:** How should we prioritize security scanning and vulnerability remediation against the pressure to ship elizaOS v2? **Context:** - `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` **Multiple Choice Answers:** a) Implement a dedicated security sprint to comprehensively address all vulnerabilities before continuing feature development. *Implication:* Prioritizes security but may delay the elizaOS v2 release timeline specified in our monthly goal. b) Adopt a risk-based approach, immediately fixing critical vulnerabilities while addressing moderate ones in parallel with development. *Implication:* Balances security and development but requires careful coordination and may still introduce some delay. c) Focus on completing elizaOS v2 feature development with targeted security fixes only for components directly in the release path. *Implication:* Maintains development velocity but may leave security vulnerabilities in peripheral systems that could impact reputation. d) Other / More discussion needed / None of the above. **Question 2:** What strategy should we adopt for managing our GitHub repository's technical debt versus new feature development? **Context:** - `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.` **Multiple Choice Answers:** a) Allocate 20% of development capacity specifically to technical debt reduction while maintaining feature development velocity. *Implication:* Creates sustainable balance but slightly slows down new feature delivery in the short term. b) Focus entirely on shipping elizaOS v2, then dedicate a full engineering sprint to technical debt immediately after release. *Implication:* Accelerates product delivery but risks compounding technical issues that might be harder to fix post-release. c) Integrate technical debt reduction into feature work by requiring refactoring of adjacent code when implementing new features. *Implication:* Gradually improves codebase health without explicit allocation but may lead to inconsistent debt reduction. d) Other / More discussion needed / None of the above.