# Council Briefing: 2025-12-20 ## Monthly Goal December 2025: Execution excellence—complete token migration with high success rate, launch ElizaOS Cloud, stabilize flagship agents, and build developer trust through reliability and clear documentation. ## Daily Focus - All vectors converge on shipping Cloud streaming with release-discipline (monorepo → plugin → cloud-v2) while restoring trust via clear migration guidance amid visible community frustration. ## Key Points for Deliberation ### 1. Topic: ElizaOS Cloud Streaming: Launch Readiness & Release Discipline **Summary of Topic:** Streaming is functionally working in simple flows, but the release train has critical dependencies (monorepo release, elizacloud-plugin merge, cloud-v2 core bump) plus operational blockers (NPM token changes). Execution excellence requires a single coordinated launch sequence, not parallel merges that create drift. #### Deliberation Items (Questions): **Question 1:** Do we freeze all non-launch merges until Cloud streaming ships, enforcing the monorepo → elizacloud-plugin → cloud-v2 sequence as the only authorized path? **Context:** - `Stan ⚡ (core-devs): "Need to release monorepo, review/merge elizacloud-plugin, and use latest core version into cloud-v2, in that order."` - `Borko (discussion): Team preparing for Monday release with streaming capabilities.` **Multiple Choice Answers:** a) Yes—declare a launch freeze and hard-gate merges on the release sequence. *Implication:* Maximizes reliability and reduces integration risk, but delays unrelated improvements and may frustrate contributors. b) Partial freeze—only gate changes that touch streaming, versions, or cloud runtime. *Implication:* Balances velocity and safety, but requires vigilant triage and can still allow subtle coupling bugs through. c) No freeze—continue normal merges and rely on post-merge stabilization. *Implication:* Preserves throughput but increases probability of launch regressions, undermining the monthly directive of execution excellence. d) Other / More discussion needed / None of the above. **Question 2:** What is our explicit launch acceptance bar for “streaming readiness” (end-to-end tests, known limitations, rollback plan) before we announce Cloud streaming to builders? **Context:** - `Stan (Discord 2025-12-17): "Streaming functionality: Now working for simple messages and actions."` - `core-devs: "Conversation blocking issue fixed when no summary existed, improving chat creation."` **Multiple Choice Answers:** a) Strict: require e2e streaming tests + documented limitations + rollback/revert instructions before announcement. *Implication:* Strengthens trust through shipping discipline and reduces support load, but may push the date. b) Moderate: require manual verification + smoke tests, and ship with a “beta” label and rapid patch cadence. *Implication:* Ships sooner while signaling risk, but may dilute the “reliable platform” positioning if issues arise. c) Minimal: ship once it works in core flows and fix forward in production. *Implication:* Fastest path, but highest chance of breaking first impressions for developers evaluating Cloud. d) Other / More discussion needed / None of the above. **Question 3:** How do we operationally de-risk tooling failures (e.g., NPM token rotation) so releases cannot be blocked by external credential policy changes? **Context:** - `cjft (core-devs): "Get new NPM token for release as classic token was deleted (NPM changed their tokens)."` **Multiple Choice Answers:** a) Implement a release-credentials runbook + rotating token owners + preflight checks in CI (block if invalid). *Implication:* Reduces single-point-of-failure risk and improves release reliability, aligning with execution excellence. b) Centralize release credentials in a dedicated secrets manager with a single release bot identity. *Implication:* Simplifies operations but concentrates risk; compromise or policy change affects everything. c) Treat as ad-hoc incidents handled by maintainers when they occur. *Implication:* Lowest process overhead, but recurring release interruptions erode developer trust. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Token Migration: Trust, Support Integrity, and Exchange Confusion **Summary of Topic:** The Feb 4, 2026 deadline is understood by some but still confusing in practice (“0 eligible”, exchange snapshot discrepancies), and sentiment is deteriorating. Trust-through-shipping now depends as much on clear migration documentation and anti-impersonation support hygiene as on code. #### Deliberation Items (Questions): **Question 1:** Do we elevate migration support into a hardened, official “single source of truth” (docs + signed announcements), explicitly deprecating ad-hoc Discord replies as authoritative guidance? **Context:** - `Discord 2025-12-19 (discussion): Multiple users confused; request: "Create clear explanation of token migration process and deadlines."` - `Omid Sa → roybot: "Go to the migration-support channel."` **Multiple Choice Answers:** a) Yes—publish an official migration playbook (docs site) and require all helpers to link to it. *Implication:* Cuts confusion and impersonation risk, improving trust and reducing repetitive support burden. b) Hybrid—keep Discord as primary support but pin a canonical FAQ and standard macros. *Implication:* Faster community support, but still exposes users to inconsistent messaging and spoofing vectors. c) No—maintain current approach; rely on community moderation and channel routing. *Implication:* Lowest effort, but ongoing confusion can depress sentiment and hinder migration completion rates. d) Other / More discussion needed / None of the above. **Question 2:** What stance should we take on exchange-handled swaps (Bithumb/Kraken discrepancies): proactive coordination and public evidence, or strict “self-custody only” messaging with limited exchange engagement? **Context:** - `Discord 2025-12-17: "Different exchanges (Bithumb and Kraken) are handling the AI16Z to ELIZAOS token swap differently, causing confusion."` - `Discord 2025-12-17: Korean users requested evidence of communications with Bithumb regarding snapshot timing.` **Multiple Choice Answers:** a) Proactive: designate an exchange liaison, publish a status matrix per exchange, and share verifiable communication logs where possible. *Implication:* May restore credibility with affected regions, but increases operational overhead and public commitments. b) Limited: provide best-effort guidance without publishing communications; emphasize self-custody going forward. *Implication:* Moderate burden and reduces liability, but may not satisfy communities demanding transparency. c) Strict: state that exchanges are out of scope; only portal-based self-custody migrations are supported. *Implication:* Operationally simple, but risks alienating exchange-heavy users and amplifying negative narrative. d) Other / More discussion needed / None of the above. **Question 3:** How do we address worsening sentiment (price decline + “no tangible products” claims) without overpromising—what is the minimum credible evidence package we should broadcast this week? **Context:** - `Discord 2025-12-18: "Significant frustration... regarding token price decline and perceived lack of delivered products."` - `Discord 2025-12-19: Cloud streaming preparing for Monday release; knowledge repo endpoints shipped; bootstrap/initPromise fix merged (#6261).` **Multiple Choice Answers:** a) Publish a “Proof of Shipping” bulletin: Cloud streaming status, merged reliability fixes, docs updates, and next 7-day deliverables. *Implication:* Aligns narrative with execution excellence and makes progress legible to builders and holders. b) Run a live demo/space of Cloud streaming + flagship agents, focusing on real workflows rather than token talk. *Implication:* Transforms sentiment via visible capability, but risks embarrassment if demo reliability slips. c) Stay quiet until after launch to avoid distraction and misinterpretation. *Implication:* Reduces comms risk short-term, but allows negative narratives to compound unchallenged. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Developer Experience: Plugin Reliability, EVM Readiness, and Ecosystem Observability **Summary of Topic:** Builders are probing whether plugin-evm is truly supported while Starknet integration and provider performance changes highlight API churn and type friction. The knowledge repository and new GitHub analytics JSON endpoints are a strategic asset for “taming information,” but need packaging into a developer-facing observability story. #### Deliberation Items (Questions): **Question 1:** Do we formally designate a “supported onchain stack” for Q1 (e.g., Spartan EVM path, Starknet plugin path) with clear maintenance tiers, or keep onchain support community-driven and opportunistic? **Context:** - `Roman V (coders): Concern about plugin-evm maintenance status and alternatives for onchain capabilities.` - `Odilitime (coders): "working on EVM support for Spartan" and shared an active PR.` **Multiple Choice Answers:** a) Yes—publish a supported onchain roadmap with tiered support (Core, Maintained, Community). *Implication:* Improves DX clarity and reduces wasted builder effort, but commits us to maintenance obligations. b) Partially—declare a single blessed path (Spartan EVM) and label everything else experimental. *Implication:* Creates a clear default while limiting commitments, but may slow multi-chain adoption. c) No—keep onchain support unopinionated; let the ecosystem decide. *Implication:* Maximizes openness but increases confusion and fragmentation, harming developer trust. d) Other / More discussion needed / None of the above. **Question 2:** How aggressively should we optimize provider performance (parallel execution + timeouts) versus preserving strict determinism and simplicity in the runtime pipeline? **Context:** - `Discord 2025-12-18: Stan proposed PR #6263 for parallel provider execution with configurable timeout (default 1s), aborting pipeline if too slow.` - `Discord 2025-12-18: Debate on best practices—avoid API calls in providers, use caching; add warning logs for slow providers.` **Multiple Choice Answers:** a) Aggressive: adopt parallel providers + hard timeouts + abort-on-slow as default behavior. *Implication:* Improves perceived speed and reliability under load, but risks breaking edge-case providers and surprising plugin authors. b) Balanced: parallelize with soft timeouts (warnings) by default; hard abort is opt-in via config. *Implication:* Protects compatibility while nudging best practices, aligning with developer-first principles. c) Conservative: keep sequential execution; focus on documentation and caching guidelines instead. *Implication:* Minimizes behavioral change risk, but may leave performance issues unaddressed for Cloud-scale workloads. d) Other / More discussion needed / None of the above. **Question 3:** Do we elevate the knowledge repository + GitHub analytics endpoints into an official “Ecosystem Telemetry Layer” (dashboards, RSS, infographics) as a flagship of Taming Information, or keep it as an internal tool? **Context:** - `Jin (coders/core-devs): Knowledge repository provides data for agents to reason with ecosystem activity; added JSON endpoints for leaderboards/summaries (daily/weekly/monthly).` - `Jin (coders): Considering a name for GitHub analytics project ("GitScape"); experimenting with infographics.` **Multiple Choice Answers:** a) Officialize it: brand and document it, add stable endpoints, and ship a minimal public dashboard + RSS integration. *Implication:* Turns scattered activity into trust-building transparency and improves contributor coordination. b) Semi-official: keep endpoints public but label as beta; prioritize internal consumption until Cloud launch settles. *Implication:* Reduces immediate scope while preserving momentum, but delays the narrative benefit of visibility. c) Internal only: do not promote; avoid additional support and stability commitments. *Implication:* Lowest burden, but misses a strategic opportunity aligned with Taming Information and developer trust. d) Other / More discussion needed / None of the above.