# Council Briefing: 2025-10-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

- The team is pivoting from auto.fun to a new Eliza Cloud infrastructure while managing a significant token migration and architectural improvements to the core agent messaging system.

## Key Points for Deliberation

### 1. Topic: Token Migration Strategy

**Summary of Topic:** The upcoming AI16Z to ElizaOS token migration (1:10 ratio with 20% dilution) represents a critical strategic pivot that requires careful execution to maintain holder confidence while enabling new funding for development.

#### Deliberation Items (Questions):

**Question 1:** How should we address community concerns about the 20% dilution to ensure continued confidence in the project?

  **Context:**
  - `davidhq: '20% dilution to raise funds for development and marketing'`
  - `neerg: 'Are there any incentives for holders to ease the 20% dilution?'`

  **Multiple Choice Answers:**
    a) Implement a staking program with elevated rewards for early holders who migrate promptly.
        *Implication:* Creates urgency for migration and rewards loyal holders, but adds technical complexity and ongoing tokenomic obligations.
    b) Focus messaging on the buyback mechanism once Eliza Cloud generates revenue, emphasizing long-term value creation.
        *Implication:* Aligns with already planned buyback strategy and sets realistic expectations, but effectiveness depends on timely Cloud launch and revenue generation.
    c) Create a governance proposal allowing token holders to vote on how a portion of the dilution funds will be allocated.
        *Implication:* Increases community ownership and transparency, but could slow deployment of critical resources and create governance overhead.
    d) Other / More discussion needed / None of the above.

**Question 2:** What approach should we take to exchange integration for the migration to minimize fragmentation and maximize successful conversion?

  **Context:**
  - `The Light: 'Users will need to migrate tokens themselves by transferring to a personal wallet'`
  - `raja: 'If we have tokens on MEXC, do we need to do something for migration or will MEXC handle it?'`

  **Multiple Choice Answers:**
    a) Focus on providing comprehensive self-migration documentation and tools, accepting that CEX support will be limited.
        *Implication:* Minimizes dependencies on third parties but may result in lower migration participation rates from less technical users.
    b) Prioritize partnerships with 2-3 key exchanges that hold the highest concentration of tokens to support automatic migration.
        *Implication:* Maximizes conversion of the largest token pools but could create perception of preferential treatment among exchanges.
    c) Extend the migration period and implement a phased approach with incentives that increase over time to allow for exchange coordination.
        *Implication:* Provides flexibility for both users and exchanges but could create uncertainty and postpone completion of the migration.
    d) Other / More discussion needed / None of the above.

**Question 3:** How should we position the token migration to emphasize the strategic evolution of ElizaOS rather than just a technical change?

  **Context:**
  - `davidhq: 'Positioning ElizaOS as "the Ethereum of AI agents" through 2026'`
  - `Rabbidfly: 'Two-stage approach planned: 1) Fix tokenomics and improve liquidity 2) Develop L2/L3 chain with productive asset tokenomics'`

  **Multiple Choice Answers:**
    a) Focus on the infrastructure analogy ('Ethereum of AI agents') to position the token as essential infrastructure for the AI agent economy.
        *Implication:* Creates a powerful narrative that could attract developers and institutional interest, but sets high expectations that must be delivered upon.
    b) Emphasize the progressive nature of the migration as part of a broader technology roadmap leading to an L2/L3 chain for agent building.
        *Implication:* Provides a clear technological vision but might appear too technical for mainstream adoption messaging.
    c) Position the migration primarily as enabling cross-chain interoperability (via CCIP) to expand the potential market and use cases.
        *Implication:* Highlights immediate practical benefits but might understate the long-term strategic importance of the migration.
    d) Other / More discussion needed / None of the above.

---


### 2. Topic: Eliza Cloud Strategy

**Summary of Topic:** The development of Eliza Cloud as a system for running AI agents represents a strategic pivot from auto.fun toward a sustainable revenue-generating infrastructure, with targeted release by end of year.

#### Deliberation Items (Questions):

**Question 1:** Given the discontinuation of auto.fun, how should we reorient our monthly goal that focused on stabilizing and attracting users to auto.fun?

  **Context:**
  - `Auto.fun (launchpad) project discontinued as it didn't meet expectations`
  - `Eliza Cloud is nearly completed and expected to generate revenue`

  **Multiple Choice Answers:**
    a) Pivot the monthly goal entirely to focus on Eliza Cloud development and launch readiness as the primary objective.
        *Implication:* Creates clear focus on the new strategic direction but represents a significant shift from previously communicated goals.
    b) Maintain the agent activity focus (streaming, trading, shitposting) but redirect it to showcase Eliza Cloud capabilities instead of auto.fun.
        *Implication:* Preserves continuity in community-facing activities while aligning them with the new strategic direction.
    c) Expand the goal to include both Cloud development and leveraging DegenAI for community engagement during the transition period.
        *Implication:* Addresses both infrastructure and community needs but could dilute focus during a critical transition period.
    d) Other / More discussion needed / None of the above.

**Question 2:** What revenue model should we prioritize for Eliza Cloud to establish sustainable buyback capabilities?

  **Context:**
  - `Token buybacks planned once Eliza Cloud generates revenue`
  - `Plans to enable agent usage via web2 stablecoin rails`

  **Multiple Choice Answers:**
    a) Usage-based model charging for compute time and API calls with both crypto and fiat payment options.
        *Implication:* Creates predictable, scalable revenue tied directly to platform utilization but may limit initial adoption due to cost barriers.
    b) Freemium model with free basic agent deployment and premium features for persistence, advanced capabilities, and commercial use.
        *Implication:* Lowers barriers to adoption and creates viral growth potential but may delay significant revenue generation.
    c) Enterprise licensing model targeting businesses with custom pricing while maintaining a free open-source community edition.
        *Implication:* Provides potentially larger revenue streams from fewer customers but requires building enterprise sales capabilities.
    d) Other / More discussion needed / None of the above.

**Question 3:** How should we position Eliza Cloud's relationship to elizaOS v2 in our technical roadmap and communications?

  **Context:**
  - `Eliza Cloud: System for running AI agents under development, targeted for release by end of year`
  - `Monthly goal: ship production ready elizaOS v2`

  **Multiple Choice Answers:**
    a) Position Eliza Cloud as the hosted implementation of elizaOS v2, with the framework and cloud launching simultaneously.
        *Implication:* Creates a cohesive product story but ties the success of both initiatives together, increasing launch complexity.
    b) Present them as separate but complementary initiatives, with elizaOS v2 as the open framework and Eliza Cloud as the optional managed service.
        *Implication:* Maintains flexibility in development and launch timing while still connecting the initiatives conceptually.
    c) Emphasize Eliza Cloud as the priority near-term revenue driver, with elizaOS v2 positioned as the longer-term open ecosystem foundation.
        *Implication:* Creates clear prioritization for resource allocation but may disappoint community members focused on the open-source aspects.
    d) Other / More discussion needed / None of the above.

---


### 3. Topic: Technical Architecture Evolution

**Summary of Topic:** Core technical improvements in the message handling system and enhanced agent security are advancing elizaOS v2 development while architectural decisions about TEE technologies and runtime security require strategic consideration.

#### Deliberation Items (Questions):

**Question 1:** How should we prioritize the integration of boolean flags (isMention, isReply, isThread) for improved message context handling across different platforms?

  **Context:**
  - `cjft: Team discussing implementation of boolean flags (`isMention`, `isReply`, `isThread`) for better context handling in Discord plugin`
  - `Stan #6030: 'feat: Add mentionContext interface and improve shouldRespond logic'`

  **Multiple Choice Answers:**
    a) Make it a core priority for the v2 release as it fundamentally improves cross-platform agent responsiveness and user experience.
        *Implication:* Ensures a key UX improvement ships with v2 but could delay the release if implementation across platforms is complex.
    b) Implement it progressively, starting with the Discord plugin as a reference implementation, then expand to other platforms post-v2.
        *Implication:* Allows for real-world testing on one platform before expanding, but creates an inconsistent experience across platforms initially.
    c) Create a comprehensive cross-platform specification first, then implement simultaneously across all supported platforms for v2.
        *Implication:* Ensures consistency but significantly increases the scope and coordination required before shipping any improvements.
    d) Other / More discussion needed / None of the above.

**Question 2:** Given the security vulnerabilities identified in agent runs (.claude and .codex folders), what approach should we take to secure agent execution environments?

  **Context:**
  - `yikesawjeez: Unencrypted file contents in `.claude` and `.codex` folders could expose secrets from environment files`
  - `Agent Joshua: 'Beyond security vulnerabilities, SGX is limited in functionality compared to TDX which offers enterprise-grade servers and better developer experience'`

  **Multiple Choice Answers:**
    a) Prioritize migration to TDX-based Trusted Execution Environments for Eliza Cloud while implementing immediate security patches for open-source deployments.
        *Implication:* Addresses both immediate vulnerabilities and longer-term security architecture but requires managing two security approaches simultaneously.
    b) Focus on fixing the immediate security issues in the agent runtime first, then implement TEE capabilities as a separate phase.
        *Implication:* Resolves critical vulnerabilities quickly but delays the architectural improvements that would provide stronger security guarantees.
    c) Develop a hybrid approach where sensitive operations use TEE while standard operations use an improved but conventional security model.
        *Implication:* Balances security needs with practical implementation constraints but increases system complexity.
    d) Other / More discussion needed / None of the above.

**Question 3:** How should we balance computational efficiency with conversational intelligence in our message handling system?

  **Context:**
  - `cjft: 'Using a full prompt evaluation of "should I respond" works better by considering conversation context, though it makes every message an LLM call which is expensive'`
  - `Stan #6030: 'Implements fast-path optimization: skips LLM call for platform-native mentions (@mentions, replies)'`

  **Multiple Choice Answers:**
    a) Implement the hybrid approach with fast-path optimization for explicit mentions and LLM evaluation for ambiguous cases.
        *Implication:* Balances efficiency and intelligence but requires careful tuning to determine when to use each path.
    b) Prioritize intelligence by default with LLM evaluation for all messages, but implement client-side controls to limit evaluation to specific channels or contexts.
        *Implication:* Maximizes conversational quality but increases operational costs and could create performance bottlenecks at scale.
    c) Focus on optimizing the fast-path for most scenarios, using lightweight heuristics and pattern matching instead of LLM calls wherever possible.
        *Implication:* Minimizes operational costs and improves scalability but may reduce the naturalness of agent interactions in complex conversational scenarios.
    d) Other / More discussion needed / None of the above.