Launch Controls#
Operational controls for pre-launch risk, access, supported feeds, market creation, and growth instrumentation. This document is a release checklist, not proof of production readiness by itself.
Launch Scope#
| Area | Launch scope |
|---|---|
| Mobile | Android Solana Mobile devices only. iOS is unsupported and not on the mobile launch roadmap. |
| Market type | Binary price-direction markets: YES if accepted end Pyth snapshot >= accepted start Pyth snapshot. |
| Oracle | Pyth only. Push feeds are available for supported push feeds. Pull feeds depend on the paid API plan. |
| Settlement | Winning shares pay 1 settlement token unit per share; losing shares pay 0. |
| Market terms | Asset/feed, duration, settlement mint, capacity, and creator are immutable after creation. |
| Creator power | Creators cannot resolve outcomes, edit immutable market parameters, or redirect settlement. |
Range or multi-outcome user experiences must compose independent binary markets at the product layer. Do not imply that a grouped ladder of threshold markets is a single native multi-outcome market; see Market Composition.
SIMD-0266 Launch Gate#
The batched token-transfer path used by placement and cancellation requires SIMD-0266 on the target cluster. Devnet activation is not sufficient evidence for mainnet launch.
Release evidence must record:
- A mainnet feature-gate check captured within 24 hours of launch approval.
- A devnet continuous-validation run for the batched placement and cancellation paths.
- The named owner for the SIMD-0266 launch decision.
- A dated re-decision point if mainnet activation is still unavailable.
Initial decision clock: if mainnet activation is not verified by
2026-10-02, re-price the fallback options instead of carrying an open-ended
launch blocker. The fallback review must consider trimming the LOG self-CPI depth requirement and a
reduced-event launch mode, and must record why each option is accepted or rejected.
Suggested feature-gate evidence commands:
solana feature status --url mainnet-beta | rg 'SIMD-0266|batch|token'
solana feature status --url devnet | rg 'SIMD-0266|batch|token'
Supported Feed Controls#
Release evidence must record:
- The supported push-feed allowlist.
- The pull-feed allowlist enabled by the configured Pyth paid API plan.
- The Pyth API plan name or tier used by launch infrastructure.
- The deployment-secret reference for
PYTH_API_KEY. - A reviewer statement that the key value is absent from source, logs, tickets, PR text, and test fixtures.
The actual Pyth API key value must never be committed or copied into release artifacts. Evidence should name the secret manager path, CI secret name, or deployment environment variable only.
Market Creation Policy#
| Control | Requirement |
|---|---|
| Feed selection | UI/API must only expose feeds supported by the current push allowlist or pull API plan. |
| Duration | UI/API must enforce configured min/max duration bounds before signature. |
| Capacity | UI must show seat count, rent estimate, and immutability before signature. |
| Creator disclosure | UI must say creators earn fees but do not resolve outcomes or underwrite trader losses. |
| Duplicate discovery | UI/API should warn when similar active markets exist and should surface canonical markets. |
| Unsupported categories | UI/API must block market types outside launch scope instead of implying general event scope. |
| Confusing-market report | Support must have an owner for duplicate or confusing market reports. |
Creator verification is not a launch security requirement because creator identity is not a settlement authority. Creator metadata can still be used for discovery, reputation, and support workflows.
Compliance And Access Matrix#
The release owner must attach legal/compliance evidence for these rows before public launch.
| Row | Required decision/evidence |
|---|---|
| Target jurisdictions | Jurisdictions where the frontend/mobile app is intentionally offered. |
| Blocked jurisdictions | Jurisdictions blocked by product, policy, or legal review. |
| Age gate policy | Whether an age gate is required and where it is enforced. |
| Sanctions policy | Sanctions-screening or access-control approach for frontend/mobile surfaces. |
| Market category policy | Allowed and blocked market categories for launch. |
| Stablecoin/payment flow | Settlement token, funding assumptions, and external payment/funding handling. |
| Fee recipient/operator | Entity or wallet set receiving protocol fees and creator/referral treatment. |
| Frontend operator | Accountable operator for web/mobile distribution and support. |
| Android distribution | Distribution channel, package name, signing profile, and review posture. |
| Risk disclosures | Full-loss, oracle, orderbook-depth, governance, RPC, and Android-only risks. |
Growth And Analytics#
Minimum launch instrumentation:
- First app open to wallet connect.
- Wallet connect to funded account.
- Funded account to first trade.
- First trade success/failure.
- Repeat trading.
- Claim completion.
- Market creation.
- Referral attribution.
- Share-link opens.
Flagship markets should record asset/feed, oracle mode, push/pull availability, duration, creator/operator, launch timing, risk note, and share URL.
Fee Curve Launch Experiment#
Treat launch fees as an experiment, not as a permanent default. The on-chain
fee curve supports a fee holiday because fee_cap_bps = 0 makes every taker
fee zero while preserving the same settlement, referral, creator-fee, and
accounting paths. A half-curve launch is also available by setting
fee_cap_bps to 50-100 bps through the rate-limited
UpdateFeeConfig (0x1F) instruction.
Initial launch evidence must record one of these choices:
- Fee holiday:
fee_cap_bps = 0; referral/creator/protocol splits remain configured for the later ramp, but no taker fee is collected during the holiday. - Reduced curve:
fee_cap_bpsbetween50and100, with the default capped-linear decay shape. - Full default:
fee_cap_bps = 200, accepted explicitly with a rationale tied to observed demand and competitor take-rate review.
Publish the planned ramp schedule before public launch and review realized take-rate monthly. Keep the 40% referral share as the primary growth lever unless a fee-config proposal explicitly changes it; the referral attribution window remains a separate product/growth decision. Creator economics are flat for the beta because markets inherit the config split at creation time. Bounded creator-set fees are a v-next product lever, not a launch blocker.
Stats Page Launch Decision#
The web stats page was intentionally gated behind
NEXT_PUBLIC_FEATURE_STATS=false for the initial launch window. The page exposes
win rate, PnL, streaks, and other gamification surfaces that were measured
against responsible-play and retention goals before being made default-on.
Production was re-decided on 2026-07-08: enable
NEXT_PUBLIC_FEATURE_STATS=true alongside the existing WebSocket updates flag
and creator-only pro lifecycle controls. Roll back by rebuilding the web image
with NEXT_PUBLIC_FEATURE_STATS=false.
The re-decision evidence should include:
- WEB-4 product analytics delivery verified in staging.
- At least one staged wallet journey from first trade through stats-page view.
- Responsible-play/counsel review of win-rate, PnL, and streak presentation.
- A rollback owner and env-change procedure for disabling the page again.
Pause Exit Semantics#
The global pause is a halt for new deposits, market creation, and trading. It
does not block user exits from free trader-ledger balances: WithdrawFunds and
WithdrawShares remain available for unencumbered quote_free, yes_free, and
no_free buckets. Resting-order collateral and locked shares stay unavailable
until cancel/reduce/reclaim releases them through the normal encumbrance path.