# Council Briefing: 2025-12-31 ## 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 - End-of-month execution hinges on converting renewed token momentum into trust: de-risk the migration and clarify token/ecosystem messaging while shipping reliability upgrades (hooks, logging, plugins) that make Cloud onboarding frictionless. ## Key Points for Deliberation ### 1. Topic: Token Migration Integrity & Public Trust **Summary of Topic:** Community sentiment surged with a major price move tied to Shaw’s return to X, but operational risk remains: migration confusion, wallet-edge cases, and role verification gaps are eroding trust and consuming support bandwidth. #### Deliberation Items (Questions): **Question 1:** What is the Council’s minimum acceptable success criterion for the AI16Z → ElizaOS migration (and what do we publicly commit to measure and report)? **Context:** - `Discord (2025-12-29): "Snapshot has already occurred for the migration from AI16Z to ElizaOS"` - `Discord (2025-12-28): "Multiple users reported problems with the migration process"` **Multiple Choice Answers:** a) Commit to a quantified success target (e.g., % of eligible wallets migrated) and publish daily progress until close. *Implication:* Builds credibility via transparency, but forces rapid instrumentation and exposes short-term misses. b) Commit to a deadline and a robust support playbook, but avoid publishing metrics until after stabilization. *Implication:* Reduces reputational risk from noisy numbers, but may feel opaque during peak attention. c) Treat migration as an ongoing service with rolling remediation and no single success KPI. *Implication:* Maximizes inclusivity for edge cases, but risks perpetual support load and diluted urgency. d) Other / More discussion needed / None of the above. **Question 2:** How should we handle migration edge cases (large holders, unsupported wallets, bridge constraints) without creating a scam surface or favoritism narrative? **Context:** - `Discord (2025-12-28): "Fix 'max amount reached error' when users have large amounts of AI16Z"` - `Discord (2025-12-29): "Can only bridge from Solana to other chains, not vice versa."` **Multiple Choice Answers:** a) Create a formal, auditable manual-claims pathway with proof requirements and published procedures. *Implication:* Reduces scam risk via process clarity, but adds operational overhead and verification complexity. b) Patch the portal and wallet integrations rapidly; avoid manual handling except in extreme, private escalation. *Implication:* Preserves fairness optics, but risks leaving legitimate users stranded if integration lags. c) Offer a time-limited alternative migration contract/route that supports more wallets and chains. *Implication:* Improves accessibility, but increases smart-contract and communication complexity mid-flight. d) Other / More discussion needed / None of the above. **Question 3:** What is our immediate comms priority: token information discoverability, ecosystem relationship clarity (DegenAI/Ruby), or gated-role verification correctness? **Context:** - `Discord (2025-12-30, Kenk): "added details to docs.elizaos.ai/tokenomics"` - `Discord (2025-12-30): "Update Collabland to properly reflect ElizaOS token holdings instead of ai16z"` **Multiple Choice Answers:** a) Token info discoverability first (dedicated token page, CA/exchanges, official links), then ecosystem clarifications. *Implication:* Cuts confusion and support load fastest during peak visibility, reinforcing trust-through-shipping. b) Ecosystem relationship clarity first (what is 'official' vs community), then token page polish. *Implication:* Prevents brand dilution and misattribution, but may not solve immediate how-to-buy/migrate friction. c) Role verification correctness first (Collabland + ElizaOS verification), then token and ecosystem docs. *Implication:* Stabilizes community governance and gated channels, but leaves broader market-facing confusion longer. d) Other / More discussion needed / None of the above. --- ### 2. Topic: ElizaOS Cloud + Jeju Infrastructure Trajectory **Summary of Topic:** Cloud beta is live with light support and Jeju is framed as a compute marketplace launching on AWS first, then migrating toward permissionless physical infrastructure—an ambitious path that requires clear reliability guarantees and developer onboarding clarity. #### Deliberation Items (Questions): **Question 1:** Do we position Jeju/Cloud primarily as a developer cost-saver marketplace now, or as a reliability-first managed platform with marketplace optionality later? **Context:** - `Discord (2025-12-28, Shaw): "functions as a compute marketplace that automatically selects optimal resources"` - `Discord (2025-12-28): "40% reduction in cloud bills for web2 developers"` **Multiple Choice Answers:** a) Lead with reliability-first managed Cloud; introduce marketplace routing once SLAs and observability are mature. *Implication:* Aligns to Execution Excellence, but delays the most novel differentiation narrative. b) Lead with the marketplace narrative immediately (cost/monetization), accepting rough edges as early-adopter tax. *Implication:* Maximizes momentum and token utility story, but risks trust loss if early reliability disappoints. c) Dual-track messaging: Cloud for builders, Jeju marketplace for providers—two lanes, one brand. *Implication:* Captures both audiences, but increases comms complexity and potential confusion about guarantees. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s stance on SLAs in the near term: none (provider-only), platform baseline SLA, or tiered SLA tied to token/plan? **Context:** - `Discord (2025-12-28, Shaw): "I do not, but providers can" (re: SLAs)` - `Discord (2025-12-29): "Eliza Cloud Beta: Open beta access is now available with light support ahead of full launch"` **Multiple Choice Answers:** a) Provider-only SLAs for now; platform remains best-effort during beta with explicit disclaimers. *Implication:* Reduces liability, but may slow serious developer adoption for production workloads. b) Introduce a minimal platform baseline SLA (uptime + incident comms) to anchor trust. *Implication:* Accelerates developer confidence, but requires on-call, monitoring, and incident discipline immediately. c) Tiered SLAs (free/beta best-effort; paid/token-gated SLA) with clear boundaries. *Implication:* Creates monetization and prioritization, but risks community backlash if perceived as paywalling stability. d) Other / More discussion needed / None of the above. **Question 3:** How aggressively do we pursue the AWS → self-owned permissionless racks transition relative to December’s directive of execution excellence and trust? **Context:** - `Discord (2025-12-30, Shaw): "Initially launch on AWS with a goal to transition to self-owned permissionless infrastructure with physical racks in data centers by year-end"` - `Discord (2025-12-30, Odilitime): "offered to cover Northern California for data center infrastructure"` **Multiple Choice Answers:** a) Defer physical infra commitments until Cloud reliability KPIs stabilize; keep AWS as primary near-term substrate. *Implication:* Maximizes reliability and velocity, but may undercut the permissionless narrative temporarily. b) Proceed on a fixed timeline; treat physical infra as a flagship credibility milestone for the decentralized AI economy. *Implication:* Strengthens long-term narrative, but increases operational complexity and risk of service instability. c) Pilot a small multi-region rack footprint in parallel while AWS remains the control plane. *Implication:* Balances ambition and safety, but demands strong architecture boundaries and extra engineering bandwidth. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Framework Reliability & Developer Experience (Hooks, Streaming, Plugins) **Summary of Topic:** Core work is trending toward execution excellence: unified hooks across transports, database logging for streaming LLM calls, and plugin fixes (OpenAI image gen + caching). However, release/versioning and integration pathways remain fragmented, threatening DX consistency as Cloud adoption ramps. #### Deliberation Items (Questions): **Question 1:** Should unified hooks (HTTP/SSE/WebSocket) be treated as a v1.6.x hardening requirement or an optional capability that can land incrementally? **Context:** - `GitHub (PR #6300): "unified hooks with multi-transport support, including HTTP, SSE, and WebSocket"` - `Discord (core-devs, Stan): "fixed issues with duplicate events"` **Multiple Choice Answers:** a) Hardening requirement: block related releases until hooks are stable and documented end-to-end. *Implication:* Improves reliability guarantees, but may slow other roadmap items during peak market attention. b) Incremental landing: merge behind defaults and progressively roll out transport support with feature flags. *Implication:* Maintains velocity, but risks inconsistent behavior across transports and support complexity. c) Defer hooks consolidation; prioritize Cloud launch polish and migration reliability first. *Implication:* Optimizes near-term trust outcomes, but leaves architectural debt that will compound with scale. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s preferred approach to plugin versioning and release automation to reduce developer friction and ecosystem breakage? **Context:** - `Discord (core-devs, Odilitime): "Should I pump the version for every plugin PR I make?"` - `Discord (core-devs, Stan): "we should have a CI... like release please"` **Multiple Choice Answers:** a) Adopt automated semantic releases across core + plugins (changesets/release-please) with enforced conventions. *Implication:* Improves trust and predictability for builders, but requires workflow standardization and maintainer buy-in. b) Keep manual versioning but publish a strict policy and a checklist for PR authors and reviewers. *Implication:* Low tooling overhead, but relies on human discipline and will drift under scale. c) Centralize plugins into a monorepo-style release train to eliminate cross-repo drift. *Implication:* Maximizes coherence, but increases repo complexity and may deter some community contributions. d) Other / More discussion needed / None of the above. **Question 3:** How do we turn recent reliability fixes (streaming logging, caching, duplicate-event fixes) into visible developer trust signals? **Context:** - `GitHub (PR #6296, merged): "log streaming LLM calls to database"` - `Discord (2025-12-30, Odilitime): "added caching to prevent redundant media processing"` **Multiple Choice Answers:** a) Publish a weekly reliability changelog with before/after metrics and incident learnings. *Implication:* Converts engineering work into trust narratives, but requires consistent measurement and comms cadence. b) Prioritize in-product observability (dashboards, model-call logs, perf indicators) over external comms. *Implication:* Improves self-serve debugging, but may under-leverage public momentum for reputational gains. c) Run a developer-facing stability campaign: bug bounties, regression tests, and a “known issues” canon. *Implication:* Builds community participation and clarity, but may temporarily highlight shortcomings during launch. d) Other / More discussion needed / None of the above.