Simple Summary

Capx is migrating off Capx Chain. The community needs to choose the destination ecosystem before we commit irreversible engineering work and before the Capx Chain sunset timeline is finalized. This proposal puts five options on the ballot: Solana, Ethereum, Base, Arbitrum, and BSC. The winning chain becomes the new home for the Capx token, the seven existing agent-token communities, Capx Terminal, and all future playbook-launched agent-tokens.

Abstract

A separate proposal (CIP-006) will be published within 24 hours of the vote closing, covering the actual migration mechanics: snapshot date, swap ratios, claim window, LP seeding, and treasury treatment. The Capx Chain sunset date will be announced as part of CIP-006, once the destination is known.

Motivation

Why we're voting now

Capx Chain shipped to give autonomous-company agents a dedicated execution environment. In practice, two things became clear:

1. Liquidity does not bootstrap in isolation. Agent-tokens need to live where traders, market-makers, and existing communities already are. Running a chain plus a product plus a token economy at the same time spreads attention too thin.
2. The community has been overwhelmingly vocal in Discord that we should migrate to where agent-token activity actually happens. This vote converts that informal consensus into a formal, token-holder-weighted decision before we commit irreversible engineering work.

We are running the vote before announcing a Capx Chain sunset date for two reasons: the migration runway depends on which chain wins (tooling maturity and bridge availability vary), and we want voters to choose the destination on its merits, not under deadline pressure.

What this vote decides

A single ecosystem that will host:

• The Capx native token (new contract, new ticker conventions per chain)
• All seven existing agent-token communities currently on Capx Chain
• Capx Terminal — the trading-metrics and agent-activity surface
• Capx Casa — the autonomous-company runtime (chain-agnostic, but with on-chain hooks for token actions)
• All future playbook-launched agent-tokens

What this vote does NOT decide

To keep this proposal focused, the following are explicitly out of scope and will be addressed in CIP-006:

• Capx Chain sunset date and final-block timing
• Per-token swap ratios for the 7 raffle communities
• Treasury and team-token treatment
• LP seeding mechanism and bootstrap liquidity sizing
• Exact claim contract design
• Capx Terminal launch sequencing
• CEX / CMC / CoinGecko listing transitions

Specification

The five options

Each option is presented with the same evaluation criteria: ecosystem fit, liquidity, fees & UX, developer tooling, and risks.

Option A — Solana

• Ecosystem fit: Strongest existing culture for agent-tokens, memecoins, and launchpad-style token economies. Pump.fun, Raydium, Jupiter, and Phantom form a tight retail loop.
• Liquidity: Deep on Raydium and Orca; Jupiter aggregates across venues. Active market-makers for new launches.
• Fees & UX: Sub-cent transactions, sub-second confirmation. Best-in-class for high-frequency agent actions and small-buy retail participation.
• Tooling: Anchor / Rust. Carries a learning curve for an EVM-native team; ecosystem maturity has improved substantially over the last 18 months.
• Risks: Historical outage record (materially improved post-Firedancer rollout). Non-EVM means existing EVM tooling does not port directly.

Option B — Ethereum (Mainnet)

• Ecosystem fit: The neutral, credibly-decentralized home of crypto. Strongest signal of seriousness to institutional capital.
• Liquidity: Deepest in the industry, but concentrated in blue-chip assets; small-cap agent-token activity has largely migrated to L2s and Solana.
• Fees & UX: Gas costs are prohibitive for the use case. A $5–$20 transaction makes agent micro-actions and small-size community participation economically unworkable.
• Tooling: Mature, well-understood, every wallet supports it.
• Risks: Cost alone likely disqualifies mainnet for our use case. Included on the ballot for completeness.

Option C — Base

• Ecosystem fit: Coinbase-distributed, EVM-compatible, growing AI-agent and memecoin culture (Virtuals, Clanker, etc.). Coinbase Wallet provides a clean retail on-ramp.
• Liquidity: Maturing rapidly. Aerodrome is the anchor DEX; depth is smaller than Solana but trending up.
• Fees & UX: Low fees (cents), fast confirmation, EVM familiarity.
• Tooling: Full EVM tooling carries over from Capx Chain. Easiest engineering transition.
• Risks: Sequencer is Coinbase-operated (centralization tradeoff). Ecosystem direction is partially dependent on Coinbase's strategy.

Option D — Arbitrum

• Ecosystem fit: Largest L2 by TVL, mature DeFi composability, strong developer ecosystem.
• Liquidity: Deep for DeFi blue-chips; weaker for memecoin / agent-token launch activity.
• Fees & UX: Cheap and fast, EVM-compatible.
• Tooling: Excellent EVM tooling, strong developer ergonomics.
• Risks: Capx originally chose to build on Arbitrum and did not see the agent-token retail traction we needed. Including Arbitrum on the ballot is honest — the community deserves the option to say "we should have tried harder there" — but the team's read is that the cultural fit for agent-tokens is on other chains.

Option E — BSC

• Ecosystem fit: Huge retail base, particularly in Asia. PancakeSwap is an established meme-launch venue. Strong existing flow for low-cap token speculation.
• Liquidity: Deep on PancakeSwap; significant sandwich-MEV concerns on small launches.
• Fees & UX: Cheap and fast, EVM-compatible, Binance-wallet integration.
• Tooling: Full EVM tooling.
• Risks: Small validator set raises centralization concerns. Reputation drag with non-Asia institutional capital. Narrative momentum has slowed relative to Solana and Base.

Eligibility

Eligibility is activity-based. Any address that has actively participated in the Capx ecosystem at or before the cutoff is eligible to vote. Specifically:

• Any address that participated in a Capx presale (purchased a presale ticket on any of the qualifying raffles), or
• Any address that has executed at least one trade on the Capx SuperApp.

A cutoff block/timestamp is set prior to this announcement to prevent vote-buying or last-minute manufactured activity. The exact cutoff is published in the announcement.

Weighting

One vote per eligible address. Sybil-resistance is handled by the activity-based eligibility filter rather than by vote weighting — only addresses that have actually participated in the Capx ecosystem prior to the cutoff are eligible to vote. Equal weight per address keeps the result intelligible and aligned with the community-sentiment goal of this vote.

Alternatives the team considered: USD- or token-weighted votes (excludes participants who used the SuperApp but don't hold large balances; depends on price feeds), per-token quorum (complex, risks deadlock). The chosen model relies on the eligibility filter to capture participation and on equal-weight tallying to capture sentiment.

Mechanism

Vote is conducted on-chain on Capx Chain. Single-choice ballot, five fixed options, no ranked preferences. Each eligible voter submits one vote transaction; the contract verifies the voter and records the vote. The voting window is published in this announcement.

Quorum

At least 20% of eligible addresses must cast a vote for the result to count. If quorum is not met, the proposal is marked Rejected and the team will publish a follow-up explaining whether we re-vote or recommend a default. There is no automatic extension of the voting window.

Tie-break

In the event of an exact tie between two or more top options, the proposal is marked Rejected — the team will publish a follow-up with a refined ballot. When there is a clear plurality winner above quorum, that option wins; there is no separate approval threshold beyond the quorum check.

Implementation

Timeline

Date	Milestone
23rd May 2026 12:00AM UTC	Eligibility Cut-off Time
29th May 2026 1:30PM UTC	Vote opens
05th June 2026 1:00PM UTC	Vote closes
Within 24h of close	Result declared on-chain; CIP-006 (migration mechanics & sunset date) released
TBA (per CIP-006)	Capx Chain final block
90 days post-sunset	Claim window closes

On the claim window: The Capx Chain sunset and the claim window are two separate clocks. Once block production stops, the claim contract on the winning chain remains open for at least 90 days so holders have a full quarter to migrate without rushing.

What we commit to as a team

• We will publish migration mechanics and the Capx Chain sunset date within 24 hours of the result being declared, regardless of outcome.
• We will honor the result. The team's preferred chain is not on the ballot as a foregone conclusion; if Arbitrum or BSC wins, we ship there.
• We will keep the claim window open for at least 90 days post-sunset and provide a recovery mechanism for any holder who can prove eligibility after that window closes.
• The on-chain vote is the canonical record. The team will not selectively reinterpret the result; only the contract-declared winningOptionIndex determines the destination.

How to participate

1. Read and challenge this proposal within the community during the announced period.
2. Confirm eligibility and vote at https://app.capx.ai/governance — sign in to the Capx SuperApp, your eligibility is checked against the eligibility cut-off timestamp, and if eligible you'll be shown the ballot to submit your choice on-chain.
3. Watch for CIP-006 within 24 hours of the result being declared, for migration steps and the Capx Chain sunset date.

FAQ

Q: When does Capx Chain shut down?

A: The sunset date will be announced as part of CIP-006, within 24 hours of the result being declared. We want voters to choose the destination on its merits before we commit to a timeline that depends on which chain wins.

Q: I participated in multiple presales and traded a lot on the SuperApp. Do I vote once or per activity?

A: Once per eligible address. The governance enforces one vote per address regardless of how many qualifying activities you've performed; what matters is whether your address has any qualifying activity at or before the cutoff. Volume, frequency, and recency don't change vote weight.

Q: Why isn't my vote weighted by my activity volume or holdings?

A: Pure equal weight per eligible address keeps the vote intelligible, auditable on-chain without oracles, and aligned with the community-sentiment goal of CIP-005. Sybil-resistance is handled by the activity-based eligibility filter rather than by vote weighting — to vote N times an attacker would need N addresses that each independently participated in a Capx presale or executed a SuperApp trade prior to the cutoff.

Q: Will existing exchange listings carry over automatically?

A: No. Each CEX requires a separate migration; we will coordinate but cannot guarantee timing per exchange.

Q: I started participating in Capx after the cutoff. Can I vote?

A: No. Eligibility is fixed at the cutoff block/timestamp. Activity (presale participation or SuperApp trades) after the cutoff does not qualify an address — this is to prevent vote-buying and manufactured-activity gaming after the proposal is announced.

Q: What gas do I pay to vote?

A: A single transaction on Capx Chain — typically negligible. The team is not subsidizing vote gas; it's paid directly from the voter's wallet.

Q: What if quorum isn't met or there's a tie?

A: The proposal transitions to Rejected. The team will publish a follow-up explaining whether we re-vote, recommend a default, or adjust scope. There is no automatic extension of the voting window.

Q: Can I see my vote on-chain?

A: Yes. Every vote is recorded as an on-chain event with your address, the proposal ID, and your chosen option. Anyone can query the full vote history through any block explorer or RPC.

Q: What is the eligibility cut-off timestamp?

A: The eligibility cut-off date and time refers to the timestamp up to which all activity and balances on the Capx Chain will be considered for vote eligibility for CIP-005. Any activity or balance changes after this timestamp will not be included, therefore will NOT be eligible to vote in CIP-005.

---