# Council Briefing: 2025-12-30 ## 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 - The fleet is riding a surge of public attention while simultaneously absorbing migration friction and cloud-beta edge cases—making trust-through-reliability the decisive battlefield for the next 72 hours. ## Key Points for Deliberation ### 1. Topic: Token Migration Integrity & Support Load **Summary of Topic:** Migration is functionally live (snapshot taken; multi-chain availability confirmed), but repeated user errors and eligibility confusion are creating support drag and reputational risk at the exact moment the project is most visible. #### Deliberation Items (Questions): **Question 1:** Do we prioritize expanding migration accessibility (wallet support / exceptions) or enforce strict snapshot policy to maximize predictability and fraud resistance? **Context:** - `Discord 2025-12-27: Odilitime — "As a policy we're not migrating any purchases after snapshot."` - `Discord 2025-12-28: Multiple users reported wallet connection problems and "max amount reached" errors; support routed to dedicated channels.` **Multiple Choice Answers:** a) Enforce strict snapshot rules; invest only in clearer messaging and automated eligibility checks. *Implication:* Maximizes determinism and reduces exploit surface, but may strand legitimate holders and increase sentiment volatility. b) Add narrowly-scoped exception paths (manual review/whitelist) for provable snapshot holders with unsupported wallets. *Implication:* Reduces legitimate-user fallout while containing fraud risk, but increases operational complexity and turnaround expectations. c) Broaden eligibility and tooling (multi-wallet connectors, expanded bridge directions) to minimize user friction. *Implication:* Improves UX rapidly but expands attack surface, creates policy ambiguity, and can undermine “trust through shipping” if rushed. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s minimum “trust posture” for migration comms (contracts, bridges, support) to reduce confusion and impersonation risk? **Context:** - `Discord 2025-12-29: Broccolex action item — "Create pinned tweet with contract addresses to avoid confusion."` - `Discord 2025-12-29: Contract shared in chat — "DuMbhu7mvQvqQHGcnikDgb4XegXJRyhUBfdU22uELiZA"` **Multiple Choice Answers:** a) Publish a single canonical “Migration & Contracts” page and pin it across Discord/X/GitHub; no other links endorsed. *Implication:* Reduces phishing/impersonation vectors and consolidates truth, at the cost of slower updates unless well-maintained. b) Keep comms distributed but add signed verification (PGP/sig, on-chain attestations) for official addresses and announcements. *Implication:* Raises authenticity guarantees without centralizing everything, but adds ceremony and requires user education. c) Rely on support channels for resolution; keep public comms lightweight to avoid mistakes. *Implication:* Limits public errors but increases support burden and leaves narrative control to rumors during peak attention. d) Other / More discussion needed / None of the above. **Question 3:** How aggressively should we invest in migration UX engineering (error clarity, wallet diagnostics) versus treating this as a one-time operation? **Context:** - `Discord 2025-12-28: Action item — "Fix 'max amount reached error' when users have large amounts of AI16Z."` - `Discord 2025-12-27: "max amount reached" interpreted as snapshot-ineligible (Odilitime), indicating UX ambiguity.` **Multiple Choice Answers:** a) Treat it as a one-time event: patch only critical blockers; focus engineering on Cloud launch stability. *Implication:* Protects near-term roadmap velocity, but risks lingering distrust among late or confused migrators. b) Invest in a polished migrator: explicit eligibility proofs, wallet-level diagnostics, and better error taxonomy. *Implication:* Improves success rate and reputation, but diverts capacity from Cloud beta hardening. c) Outsource/automate: add community-run triage tooling and templates; engineering only supports escalation paths. *Implication:* Scales support with lower core-team load, but quality control and safety guarantees may weaken. d) Other / More discussion needed / None of the above. --- ### 2. Topic: ElizaOS Cloud Beta & Jeju Compute-Marketplace Trajectory **Summary of Topic:** Cloud is in open beta with “light support,” while Jeju is positioned as a decentralized Vercel alternative (compute marketplace, distributed cache, DNS, serverless SQLite). The strategic risk is promising a future platform before the current beta’s reliability story is airtight. #### Deliberation Items (Questions): **Question 1:** Should the Council frame Jeju as near-term product reality or long-horizon R&D, given Cloud is still in “light support” beta? **Context:** - `Discord 2025-12-29: "Eliza Cloud Beta: Open beta access is now available with light support ahead of full launch."` - `Discord 2025-12-28: Shaw — "Decentralized Vercel Alternative" with marketplace selecting optimal resources; includes DNS, distributed cache, and SQLite.` **Multiple Choice Answers:** a) Position Jeju as R&D; focus messaging on Cloud beta reliability and developer onboarding now. *Implication:* Aligns with Execution Excellence and reduces expectation debt, but may dampen speculative excitement. b) Market Jeju as imminent; use hype to drive Cloud beta signups and provider interest. *Implication:* Accelerates ecosystem energy, but increases reputational risk if beta issues remain visible. c) Dual-track narrative: Jeju for providers/partners, Cloud for builders; segment comms and roadmaps. *Implication:* Balances excitement with credibility, but requires disciplined messaging and clear boundary-setting. d) Other / More discussion needed / None of the above. **Question 2:** What is the minimum reliability/operability bar required before declaring “Cloud launch” complete under the monthly directive? **Context:** - `Monthly directive: "launch ElizaOS Cloud" and "build developer trust through reliability and clear documentation."` - `Discord 2025-12-29: Users reported an unspecified error when chatting with an agent via share link (Destiny).` **Multiple Choice Answers:** a) Launch is “complete” when core workflows work end-to-end: create → deploy → chat/share, with documented known issues. *Implication:* Protects trust by anchoring launch to user reality, but may delay celebratory messaging. b) Launch is “complete” when infra is online and onboarding exists; bugs are normal post-launch backlog. *Implication:* Ships faster and captures momentum, but risks violating Execution Excellence if UX is visibly brittle. c) Launch is “complete” only after SLAs/incident response and provider reliability mechanisms are in place. *Implication:* Sets a high enterprise-grade bar that strengthens long-term credibility, but likely pushes launch beyond December. d) Other / More discussion needed / None of the above. **Question 3:** How should provider SLAs and marketplace accountability be designed without undermining composability and decentralization? **Context:** - `Discord 2025-12-28: Shaw — "I do not [offer SLAs], but providers can" and action item to implement provider SLA capabilities.` **Multiple Choice Answers:** a) Provider-defined SLAs with standardized disclosure templates and public reliability metrics. *Implication:* Keeps marketplace decentralized while enabling informed choice, but requires robust metrics and anti-gaming controls. b) Protocol-enforced baseline SLA requirements (uptime, latency tiers) for listing eligibility. *Implication:* Improves average reliability, but increases central policy surface and may reduce provider diversity. c) No formal SLAs; rely on reputation, staking/slashing, and automatic routing away from unreliable providers. *Implication:* Fits decentralized ethos, but may feel opaque/unreliable to Web2 developers unless reputation signals are strong. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Developer Trust: DX, Data Layer Choices, and Quality Gates **Summary of Topic:** Docs and tooling progress is strong (multiple PRs merged; hot reload; docs improvements), but recurring “death by papercut” bugs (agent naming crashes, share-link errors, Windows setup friction) and storage uncertainty (SQLite vs PGLite) threaten the reliability narrative. #### Deliberation Items (Questions): **Question 1:** Do we standardize on SQLite-first portability for local/dev and treat PGLite/Postgres as advanced modes, or keep PGLite central to avoid fragmentation? **Context:** - `Discord 2025-12-29 core-devs: sayonara — SQLite "more portable and uses a single file, unlike PGLite."` - `Discord 2025-12-29: Ongoing debate about restoring first-class SQLite support due to PGLite portability/file corruption concerns.` **Multiple Choice Answers:** a) Make SQLite the default local/dev path; provide a clear migration path to PGLite/Postgres for production. *Implication:* Optimizes DX and reliability for builders, but adds long-term maintenance and migration surface. b) Keep PGLite as the default; fix corruption/portability issues and improve tooling around it. *Implication:* Reduces data-layer fragmentation, but may keep setup friction higher for newcomers. c) Abstract storage behind a strict interface and let Cloud be the recommended default for persistence. *Implication:* Aligns with Cloud strategy and composability, but risks alienating self-hosters if local story feels second-class. d) Other / More discussion needed / None of the above. **Question 2:** What quality gates should be enforced now to prevent recurring UX-breaking edge cases (e.g., invalid agent names, share link errors) from reaching production? **Context:** - `Discord 2025-12-27: DorianD — agent names "null" or numeric values caused save failures/exceptions.` - `Discord 2025-12-29 coders: Destiny — unspecified error when chatting with an agent via share link.` **Multiple Choice Answers:** a) Add strict validation + contract tests for all user-input fields and share workflows; block release if failing. *Implication:* Improves reliability and trust, but may slow shipping cadence and require more test infrastructure. b) Soft validation in UI with server-side sanitization; allow releases but track regressions with Sentry/telemetry. *Implication:* Maintains velocity while reducing worst failures, but still allows some broken experiences into the wild. c) Rely on community issue triage and rapid patches; formal gates only for security and data-loss risks. *Implication:* Maximizes shipping speed, but conflicts with Execution Excellence and may erode developer confidence. d) Other / More discussion needed / None of the above. **Question 3:** How far should we push TypeScript strictness and build-time checks (unused vars, DI patterns) before it begins harming contributor throughput? **Context:** - `Discord 2025-12-29 core-devs: discussion of build-time checks for unused variables as a middle ground (Odilitime).` - `GitHub issues 2025-12-29: Issue #6292 — epic for "world-class TypeScript patterns" (Decorators, DI, advanced type system).` **Multiple Choice Answers:** a) Incrementally tighten: enforce unused-var checks now, defer full strict mode until after Cloud launch stabilization. *Implication:* Balances reliability and velocity, preserving near-term execution focus while raising quality over time. b) Go strict immediately (full TS checks, stricter linting) to eliminate entire bug classes. *Implication:* Raises codebase integrity quickly, but may slow contributions and increase friction for new developers. c) Stay permissive; invest in tooling (Copilot/Opus workflows) and code review culture rather than strict compilers. *Implication:* Keeps onboarding easy, but increases hidden defect risk and undermines “most reliable framework” positioning. d) Other / More discussion needed / None of the above.