# KingPulse — Next Roadmap

**Status:** Proposed milestones; no dates or delivery guarantees  
**Depends on:** Completing the remaining acceptance checks in [ROADMAP.md](ROADMAP.md) and the applicable gates in [LAUNCH_CHECKLIST.md](LAUNCH_CHECKLIST.md)  
**Reviewed:** 2026-10-20

This roadmap prioritizes measured safety and dependable user journeys before new financial integrations. A feature is not considered delivered because a UI or deployment script exists; completion requires observable behavior, documented risk, and production verification where relevant.

## Milestone 1 — Production operations and recovery

- Confirm the canonical HTTPS origin, supported launch networks, TLS, and managed service restart/health behavior.
- Test persistence, backup, and restore for campaign and email-alert state.
- Add operator runbooks for RPC/indexer outages, stale data, incident communication, and safe feature disablement.
- Keep SwapKit and QR connections disabled until provider authentication, domain registration, and real-device checks pass.

**Exit criteria:** a release can be deployed, monitored, rolled back, and recovered without losing persistent state or presenting stale data as current.

## Milestone 2 — Transaction and quote transparency

- Define an opt-in, privacy-reviewed measurement method for transaction attempts, confirmed success, reverts, user rejections, and RPC failures.
- Present route-specific quotes for explicit order sizes, including quote time, source, slippage/price impact, and confirmation status.
- Distinguish indexed reserves from executable depth and disclose missing or stale routes.
- Add regression coverage for unavailable data, provider timeouts, reverted transactions, and stale quotes.

**Exit criteria:** each published reliability or liquidity metric has a reproducible definition, source, sample window, and freshness indicator.

## Milestone 3 — Mobile and accessibility quality

- Complete real-device checks for wallet connection, route navigation, dialogs, charts, transaction review, and recovery.
- Verify keyboard-only navigation, screen-reader labels, focus restoration, contrast, reduced motion, and touch target sizes.
- Track and resolve high-impact usability failures before expanding the wallet/provider matrix.

**Exit criteria:** critical wallet and trading journeys pass the documented device/browser matrix without blocking accessibility issues.

## Milestone 4 — KING utility governance decision

- Resolve the exact source, permissions, and operational controls of the official KING deployment.
- Decide whether any KING-denominated staking, fee sharing, or rewards should exist; document risks, eligibility, funding, and governance before implementation.
- Keep legacy KPL/xKP contracts isolated unless a separately reviewed migration is explicitly approved.
- Require independent review and public verification for any new financial contract.

**Exit criteria:** no new incentive or contract is enabled until its authority, funding, user obligations, and emergency policy are independently reviewed and disclosed.

## Milestone 5 — Carefully scoped integrations

- Evaluate each proposed bridge, swap provider, or wallet integration for domain-bound credentials, counterparty exposure, custody assumptions, data handling, and outage behavior.
- Enable one integration at a time behind explicit configuration and production smoke tests.
- Remove integrations that cannot meet authentication, metadata accuracy, or support requirements.

**Exit criteria:** every enabled integration has a named owner, tested credentials, documented failure mode, and a disable switch.

## Non-goals and safeguards

- No guaranteed token price, return, liquidity level, listing, reward, or delivery date.
- No automatic production deployment, wallet transaction, or contract migration without explicit approval.
- No reporting simulated quotes, synthetic activity, or local-only counters as live on-chain metrics.
- No collection of transaction or wallet telemetry beyond a documented, minimized, consent-appropriate policy.