# Council Briefing: 2025-12-03 ## 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 - Core development teams are advancing critical technical infrastructure improvements for elizaOS v2 while navigating ongoing token migration challenges that impact community sentiment and exchange relationships. ## Key Points for Deliberation ### 1. Topic: Technical Architecture Enhancements **Summary of Topic:** Development efforts are focused on critical improvements to plugin memory architecture, authentication, and streaming capabilities, with discussions about cost-effective scaling through multi-agent server hosting rather than isolated serverless instances. #### Deliberation Items (Questions): **Question 1:** How should we prioritize the implementation of streaming functionality in elizaOS v2 given its potential impact on user experience? **Context:** - `0xbbjoker outlined specific tasks for plugin-memory, including figuring out table migrations for cloud and tailoring architecture to specific tasks.` - `Odilitime suggested using a 'stream: true' parameter in the runtime.ts file for implementing streaming without rewriting the entire framework.` **Multiple Choice Answers:** a) Immediately implement streaming as a core feature using the suggested 'stream: true' parameter approach to enhance real-time agent interactions. *Implication:* Prioritizing streaming could dramatically improve user perception of agent responsiveness but may delay other critical architecture work. b) Focus first on completing plugin-memory architecture and authentication improvements before adding streaming capability. *Implication:* This approach ensures a more stable foundation but delays a feature that could significantly enhance perceived agent intelligence and responsiveness. c) Develop streaming in parallel with other architecture work by assigning a dedicated team to this specific feature. *Implication:* Parallel development could accelerate delivery of all features but risks creating integration challenges between components developed simultaneously. d) Other / More discussion needed / None of the above. **Question 2:** Should we transition from isolated serverless instances to hosting multiple agents on fewer servers to reduce operational costs? **Context:** - `Discussions about hosting multiple agents on single/few elizaOS servers instead of isolated serverless instances for each user, which could potentially reduce costs.` **Multiple Choice Answers:** a) Transition immediately to a multi-agent server architecture to optimize costs while maintaining reasonable isolation boundaries. *Implication:* Could significantly reduce operational costs but introduces new security and resource contention challenges that must be managed. b) Continue with isolated serverless instances to maintain perfect security isolation while exploring cost optimizations elsewhere. *Implication:* Preserves the current security model but keeps operational costs high, potentially limiting long-term sustainability. c) Develop a hybrid model where certain agent types share servers while others (e.g., those with sensitive data) remain isolated. *Implication:* Balances cost reduction with security needs but introduces complexity in deployment and resource allocation decisions. d) Other / More discussion needed / None of the above. **Question 3:** How should we approach the implementation of multi-user authentication in elizaOS to balance security with ease of integration? **Context:** - `Stan provided an update on their work introducing per-user authentication validation on the server with generic JWK provider support (including Privy).` **Multiple Choice Answers:** a) Standardize on the current JWK provider approach and make it the only supported authentication method. *Implication:* Simplifies the codebase and security model but may limit integration options for some developers. b) Support multiple authentication methods through a plugin architecture that developers can extend. *Implication:* Maximizes flexibility for different use cases but increases security review burden and potential for vulnerabilities. c) Implement a tiered authentication system with simple methods for basic use cases and more secure options for sensitive applications. *Implication:* Balances ease of use with security needs but requires clear documentation of security implications for each method. d) Other / More discussion needed / None of the above. --- ### 2. Topic: ElizaCloud Marketplace Strategy **Summary of Topic:** Discussions around ElizaCloud's business model suggest implementing a marketplace similar to Salesforce AppExchange or Apple App Store with revenue sharing from third-party developers and standardized URL structures for agents. #### Deliberation Items (Questions): **Question 1:** What revenue sharing model should ElizaCloud implement for third-party developers to balance platform sustainability with developer incentives? **Context:** - `Suggestions for revenue sharing with third-party developers (30% platform cut)` - `DorianD suggested implementing a marketplace model (like Salesforce AppExchange/Apple App Store) with revenue sharing for third-party developers` **Multiple Choice Answers:** a) Implement a standard 30% revenue share model similar to established app stores. *Implication:* Follows proven industry models but may deter some developers who are accustomed to more favorable terms in Web3. b) Adopt a tiered model where ElizaOS takes a smaller percentage from smaller developers and increases the cut as revenue grows. *Implication:* Could attract more developers initially but adds complexity to the system and may reduce predictable revenue streams. c) Implement a token staking model where developers stake ElizaOS tokens instead of paying direct revenue shares. *Implication:* Creates additional utility and demand for the ElizaOS token but may make the platform less accessible to developers without tokens. d) Other / More discussion needed / None of the above. **Question 2:** How should we structure agent URLs and discovery in ElizaCloud to maximize user engagement and platform growth? **Context:** - `Proposals for standardized URL structures for agents (e.g., 'https://www.elizacloud.ai/agent/[agentname]')` - `DorianD also inquired about URL structures for agents on the platform.` **Multiple Choice Answers:** a) Implement a social network-like structure with standardized URLs and strong discoverability features. *Implication:* Enhances agent discoverability and social sharing but may position the platform too similarly to existing social networks. b) Create an application-centric structure with agents organized by function rather than creator. *Implication:* Emphasizes utility over social aspects and may appeal more to enterprise users seeking specific solutions. c) Develop a hybrid model with both creator profiles and functional categories, with corresponding URL structures. *Implication:* Provides maximum flexibility but could create a less focused user experience and complicate SEO strategy. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Token Migration and Exchange Relations **Summary of Topic:** The ongoing migration from AI16Z to ElizaOS tokens with a 6:1 conversion ratio is creating challenges as exchanges like Kraken pause trading while evaluating support for the migration, affecting user sentiment and requiring clear communication strategies. #### Deliberation Items (Questions): **Question 1:** How should we address the exchange listing challenges for ElizaOS tokens to improve liquidity and accessibility? **Context:** - `Kraken exchange announced pausing AI16Z trading while evaluating whether to support the migration` - `Community sentiment about ElizaOS price performance was mixed, with some believing it has bottomed out while others warned of potential further decline` **Multiple Choice Answers:** a) Focus on supporting existing exchange relationships through enhanced communication and technical support for the migration process. *Implication:* Preserves existing liquidity channels but doesn't address the need for wider exchange availability. b) Aggressively pursue new exchange listings with targeted incentives and simplified technical integration requirements. *Implication:* Could expand accessibility but requires significant resources and may dilute focus from product development. c) Develop decentralized liquidity solutions through automated market makers and liquidity pools to reduce dependency on centralized exchanges. *Implication:* Aligns with decentralization values but may limit access for mainstream users unfamiliar with DeFi mechanisms. d) Other / More discussion needed / None of the above. **Question 2:** What strategy should we implement to address community concerns about token value and migration challenges? **Context:** - `Some users reported issues with the migration process and were directed to support channels` - `Concerns about unresolved tickets regarding AI16Z tokens held on Kraken` **Multiple Choice Answers:** a) Create comprehensive migration guides and dedicated support resources specifically for exchange-related migration issues. *Implication:* Addresses immediate pain points but doesn't solve the underlying concerns about token value and exchange support. b) Implement new utility features for ElizaOS tokens that create tangible value regardless of exchange listings. *Implication:* Could improve long-term token value but doesn't solve immediate migration accessibility problems. c) Launch a community ambassador program where experienced community members help others with migration while earning rewards. *Implication:* Leverages community resources to scale support while building stronger community bonds and token utility. d) Other / More discussion needed / None of the above.