Council Briefing

Key Deliberations

Cloud MVP Launch Readiness (Streaming + Release Choreography)

Cloud MVP is slated to ship imminently, with streaming support and a strict merge/release order spanning monorepo, cloud plugin, and cloud-v2; execution quality here directly determines developer trust in the platform layer.

Do we ship Cloud MVP on schedule with scoped streaming, or delay to harden reliability and reduce first-impression risk?

Discord 2025-12-20 — Borko: "Team preparing to ship their Cloud MVP product on Monday"
Discord 2025-12-19 — Stan ⚡: "Need to release monorepo, review/merge elizacloud-plugin, and use latest core version into cloud-v2, in that order."

1Ship on schedule with a narrow, well-tested streaming slice and explicit MVP guardrails.

Maximizes momentum while aligning with execution excellence via disciplined scope control.

2Delay 3–7 days to complete soak testing, tighten docs, and validate the full release chain end-to-end.

Reduces launch risk at the cost of short-term momentum; may increase long-term trust if communicated well.

3Ship a non-streaming MVP now; release streaming as a fast-follow once the core deployment path is stable.

Protects baseline reliability but risks disappointing users expecting real-time interaction as a headline capability.

4Other / More discussion needed / None of the above.

What is the Council-approved "definition of done" for the Cloud MVP that preserves Execution Excellence (reliability/UX) over feature breadth?

Discord 2025-12-20 — cjft: "Version 1.7.0 Release: New version released with streaming functionality and npm fixes"
GitHub month summary (Dec) — "ElizaOS Cloud as the default provider in the CLI" (PR #6208) indicates onboarding/developer flow is part of the product promise.

1Operational DoD: deploy success rate targets, error budgets, and rollback procedures before adding any new Cloud features.

Institutionalizes reliability as the primary product feature, matching the North Star.

2Developer DoD: frictionless CLI create→login→deploy flow with minimal docs, prioritizing DX even if ops metrics are immature.

Accelerates adoption but risks support burden and reputation damage if runtime stability lags.

3Feature DoD: streaming + storage + cross-chain primitives minimally integrated, accepting higher early defects to capture narrative leadership.

Optimizes for market signaling; may contradict the current directive of execution excellence.

4Other / More discussion needed / None of the above.

How do we de-risk the multi-repo release chain (monorepo → elizacloud-plugin → cloud-v2) to prevent last-minute breaks and misaligned versions?

Discord 2025-12-19 — Stan ⚡: "release monorepo first, then review/merge elizacloud-plugin, finally update core version in cloud-v2"
Discord 2025-12-19 — cjft: "NPM changed their tokens and deleted classic tokens" (release pipeline fragility)

1Codify a release train with automated compatibility checks and version gating across repos (block merges on mismatch).

Reduces coordination failure modes and strengthens "trust through shipping" via repeatable process.

2Centralize Cloud components into a single orchestrated repo for launches; decentralize again after MVP stabilizes.

Improves short-term launch control but temporarily reduces composability and parallelism.

3Keep the current manual order but add a human release captain + checklist and accept occasional breakage as normal.

Low overhead, but risks recurring reliability incidents that erode developer confidence.

4Other / More discussion needed / None of the above.

Token Migration Integrity, Liquidity Asymmetry, and Utility Signaling

Migration confusion persists (snapshot eligibility, deadline, deprecated token pumping), compounded by chain liquidity differences; the Council must align messaging, support pathways, and near-term utility signals to preserve ecosystem legitimacy through the migration window.

What is the Council's unified public stance on ai16z trading/pumping during migration, and how aggressively do we counter it without amplifying it?

Discord 2025-12-19 — Serikiki: "Should I buy ai16z?" → "No."
Discord 2025-12-19 — Serikiki: "ai16z remains tradable on DEXs so people may pump it"

1Hard line: repeated messaging that ai16z has no utility; discourage trading and pin official migration path everywhere.

Reduces confusion but may provoke speculators; strengthens the canonical narrative.

2Neutral stance: state facts (no utility, migration deadline) and avoid discussing price to prevent signal boosting.

Limits amplification risk but may be perceived as evasive by frustrated holders.

3Incentive stance: focus communications on elizaOS utility/buybacks/benefits, letting ai16z fade without direct confrontation.

Shifts attention to the future but requires credible near-term utility delivery to work.

4Other / More discussion needed / None of the above.

How do we resolve snapshot-eligibility edge cases (e.g., non-supported wallets) to maximize migration success rate while minimizing manual intervention and fraud risk?

Discord 2025-12-20 — Hexx: "only tokens bought before the snapshot date can be migrated" (eligibility confusion persists)
GitHub top issue — elizaos/eliza #6211: Tangem wallet connection not supported; user cites Discord impersonators and requests verifiable guidance.

1Strict automation only: no manual exceptions; publish a canonical eligibility verifier and wallet support list.

Minimizes fraud risk and support load but may strand legitimate users and harm trust.

2Controlled manual remediation: a signed support workflow (GitHub-only intake, proofs, limited whitelist updates).

Maximizes legitimate migrations but requires high-integrity ops and clear anti-scam procedures.

3Expand wallet compatibility quickly (WalletConnect/Tangem path) even if it delays other work.

Improves fairness and success rate but competes directly with Cloud launch bandwidth.

4Other / More discussion needed / None of the above.

What is our official mitigation for cross-chain liquidity/price dislocations during migration to reduce user harm and reputational damage?

Discord 2025-12-20 — User: "40% price difference when selling on Solana"; Omid Sa: "bridge to BSC chain where liquidity is near 1M."

1Publish an official liquidity-and-bridging advisory with endorsed routes, warnings, and canonical contract addresses per chain.

Reduces confusion and scams, but increases responsibility for keeping guidance current.

2Deploy/seed targeted liquidity on the affected chain(s) to compress spreads during migration.

Directly improves UX and fairness but uses treasury resources and introduces market-making risk.

3Do nothing beyond disclaimers; treat liquidity as a market outcome and prioritize product delivery.

Preserves focus, but ongoing user losses may spill into long-term trust erosion.

4Other / More discussion needed / None of the above.

Security Posture: Scam Pressure vs. Trust Through Shipping

Discord scam attempts are actively targeting users amid migration confusion; strengthening official communication authenticity and support routing is now a critical reliability feature, not a community nicety.

What is the Council's immediate containment plan to reduce successful scams during the migration window?

Discord 2025-12-20 — "Multiple warnings about scammers targeting community members with suspicious links"
Discord 2025-12-20 — Hexx prevented a user from clicking a malicious link.

1Escalate to a formal Security Protocol: locked channels for migration, verified-only support, and auto-moderation link quarantines.

Substantially reduces attack surface, but increases friction and moderation workload.

2Maintain current moderation, but add stronger pinned guidance and periodic anti-scam broadcasts from verified team accounts.

Low disruption, moderate effectiveness; still leaves gaps during off-hours.

3Move all migration support off Discord temporarily (GitHub-only + official portal) and treat Discord as read-only announcements.

Max security, but may alienate community members who rely on Discord for real-time help.

4Other / More discussion needed / None of the above.

How do we establish a single verifiable source of truth for contracts, migration steps, and deadlines to minimize ambiguity exploited by impersonators?

Discord 2025-12-20 — Alexei provided contract addresses for multiple chains.
Discord 2025-12-19 — Kenk: "February 4, 2026 is the confirmed deadline for token migration"

1Create an immutable, signed "Canonical Registry" page (docs + onchain checksum) listing contracts, deadlines, and links.

Maximizes verifiability and aligns with open, composable infrastructure values.

2Pin and lock a single Discord announcement + mirror on the website; update as needed with staff-only edits.

Fast to deploy, but less tamper-evident and still reliant on platform trust.

3Rely on community volunteers to disseminate correct links and addresses, supported by periodic team confirmations.

Scales socially, but creates inconsistent messaging and higher scam success probability.

4Other / More discussion needed / None of the above.

What level of operational transparency should we adopt regarding security incidents without escalating fear or providing attackers a playbook?

GitHub issue #6211 — user claims "Discord support compromised — multiple impersonators" and requests verifiable guidance via GitHub.

1Publish weekly security bulletins (incident counts, mitigations, no tactical details) and a standing anti-scam checklist.

Builds trust through consistent disclosure while limiting actionable intelligence for attackers.

2Only communicate confirmed major incidents; otherwise keep messaging minimal to avoid panic.

Reduces noise, but may be perceived as silence during an active threat environment.

3Full transparency with detailed postmortems for every incident and attempted exploit.

Maximizes openness but risks arming attackers and overwhelming the Council’s bandwidth.

4Other / More discussion needed / None of the above.

North Star & Strategic Context

Key Deliberations