# KingPulse and KING — Roadmap

**Status:** Current, milestone-based roadmap  
**Network:** Monad mainnet (chain ID `143`)  
**Official token:** KINGEL3BA (`KING`) — `0x0b954D45Ebb320dEe2e0Ecfa5Ce6d30a38171a39`  
**Last reviewed:** 2026-10-20

The roadmap is conditional on engineering, liquidity, review, and operational readiness. No date or incentive is guaranteed. A milestone is complete only when its deployment or observable result is publicly verifiable.

## Phase 1 — Official identity and accurate disclosures (✅ Completed)

- [x] Use KING consistently in public-facing token selection and token documentation.
- [x] Read token state from Monad and show address, supply, owner, and pause state with a timestamp.
- [x] **Verified Contract Bytecode:** Deployed KING contract successfully verified and authenticated on [MonadScan](https://monadscan.com/address/0x0b954D45Ebb320dEe2e0Ecfa5Ce6d30a38171a39#code) and [Sourcify](https://sourcify.dev/server/repo-ui/143/0x0b954D45Ebb320dEe2e0Ecfa5Ce6d30a38171a39).
- [x] Clearly identify KPL as the legacy asset used by already deployed xKP/FeeMaker contracts.
- [x] Keep reward claims and “active” labels tied to verifiable, live functionality.

**Acceptance:** UI and published docs agree on the official token address; deployed source and permissions are verified on-chain; live contract status panel operational.

## Phase 2 — Verifiable KING markets (🟡 Partially implemented)

- [x] Identify active KING pools from on-chain factory/index data.
- [x] Show reserve-based liquidity, quote source, price impact, and index freshness.
- [x] Do not present a quote as a completed trade; show transaction state through confirmation.
- [ ] Verify continuous token/pool risk monitoring and show its source and freshness before highlighting a market.

**Acceptance:** displayed pairs and activity are reproduced from chain data, stale/incomplete indexing is visibly disclosed, and market-risk monitoring is sourced and current.

## Phase 3 — Points-only usage campaign with KING Multiplier (🟡 Partially implemented)

- [x] Implement a 30-day campaign window with transaction deduplication and 12 block confirmations.
- [x] **KING Tier Multiplier:** Bronze (1.5x, cap 15), Silver (2.0x, cap 20), VIP (3.0x, cap 30).
- [x] Zero client-side counters; points strictly derived from indexed on-chain events.
- [ ] Verify campaign activation, persistent storage, backup, and recovery in the production service.

**Acceptance:** campaign start/end and point totals are continuously available from the production service and survive release/recovery procedures.

## Phase 4 — Token-Gated Utility & KING Staking Ecosystem (🟡 Partially implemented)

- [x] Implement 4-tier Token-Gated Access (`Free`, `Bronze 100 KING`, `Silver 500 KING`, `Gold VIP 2,500 KING`).
- [x] Enforce frontend and routing barriers for advanced features (Arbitrage engine, Bridge, Locker, Analytics).
- [ ] Verify the displayed fee schedule against fees actually charged by every live route; a UI discount alone is not an executed fee discount.
- [ ] Deploy and independently review a KING-compatible staking/fee stack before claiming live KING staking utility. Existing KPL/xKP contracts remain separate.
- [ ] Verify any live staking position and its tier effect against deployed contract state.

**Acceptance:** live utility claims match deployed contracts and observable fee behavior. Script availability does not count as deployment.

## Phase 5 — Deeper liquidity and platform reliability (🟡 Partially implemented)

- [x] Existing `/api/health` reports RPC/index health, index age, pair coverage, and block lag.
- [x] Publish a platform status panel with live Monad block height, pair coverage, index freshness/lag, confirmed swap transactions in the retained index window, and aggregate persisted campaign accounting.
- [x] Label transaction-failure rate and order-size executable depth as not measured instead of substituting simulated figures.
- [ ] Publish route-specific executable quotes/depth for disclosed order sizes and units; pool reserves alone are not executable depth.
- [ ] Measure transaction success/failure from a defined, privacy-reviewed sample; current client-side wallet transactions are not comprehensively collected.
- [ ] Publish liquidity concentration and provenance from verifiable on-chain balances and labeled providers.
- [ ] Run production/release health checks and confirm monitoring, persistence, and recovery on the actual deployment.

**Acceptance:** the public dashboard identifies sources, confirmation depth, retained-window scope, and unavailable measurements. Phase 5 is not complete until the remaining measurement and operational checks above are verified.

## Not promised

No phase promises a token price, return, minimum liquidity, exchange listing, reward, redemption, or delivery date. Purchases are not required to use the platform and do not qualify a wallet for an undisclosed reward.

## Next roadmap

The next proposed milestones are tracked separately in [ROADMAP_NEXT.md](ROADMAP_NEXT.md). They are sequencing proposals, not launch commitments.