Markets and visibility

The Markets page lists markets available to this operator's management view, including hidden rows, and lets scoped staff hide or show them. It does not create, resolve, or delist a market.

Dashboard path

Operator Dashboard → Operations → Markets

Required scope: markets:read

Mutation scope: markets:write

What operators can do

• search by market title or slug
• filter by visible or hidden
• inspect market status, YES percentage, trading cutoff, and operator-scoped 24h volume
• export all filtered rows as CSV
• copy the current page as HTML/plain text
• hide or show a market when the session has markets:write

Search and visibility changes apply immediately and reset the 25-row pagination; the URL retains the filters and page. 24h Volume is this operator's processed trade volume in Credits, not operator-currency sales or a platform-wide volume. Trading Cutoff is a date display; use the API timestamp when exact timing matters.

Market visibility mode controls which markets operator users can access through Mini App surface.

Modes

The Unreleased private-market implementation makes operator-owned markets eligible only for their requesting operator. Neither all mode nor an explicit allow rule grants another operator access. They are excluded from Polynion's public discovery, direct access, and public trading. See Market Requests for availability and risk terms.

Request Create Market

The repository includes Market Requests (/market-requests) and Request Create Market (/market-requests/create). This workflow is Unreleased; source presence does not confirm availability in your environment.

When enabled, human staff need markets:read to view requests and both markets:read and markets:write to submit exact terms with explicit underwriting-risk acceptance. Machine API keys cannot use these workflows. Submission is not publication; only Polynion review can approve the submitted terms.

See the dedicated Market Requests guide for required UTC dates, resolution source, initial pricing, 50–500-share virtual depth, request status tracking, permanent private ownership, and principal/payout risk. Virtual depth is not cash collateral or a payout cap; configured trade-fee sharing is unchanged.

How to choose

• use all for broad rollout with no market restrictions
• use allowlist for phased launch or regulated scope
• use blocklist when most markets allowed but few must stay hidden

Operational guidance

• treat visibility changes as production-impacting config
• validate expected market set after each change
• coordinate visibility changes with onboarding, compliance, or commercial rules
• visibility also depends on operator ownership, geographic eligibility, and the configured resolution horizon; an allow rule does not override these constraints
• a market hidden because it lies outside the resolution horizon cannot be made visible by toggling it; MARKET_OUTSIDE_RESOLUTION_HORIZON requires eligibility/configuration review
• the page controls per-market visibility, not an arbitrary mode selector; the first hide in all mode changes it to blocklist
• hiding does not cancel executed trades, erase positions, or remove payout obligations

Verification

After change:

1. call GET /api/operator/markets
2. confirm expected list returned
3. launch test user and verify same market set in Mini App

API behavior

Visibility changes call:

POST /api/operator/markets/{id}/visibility

Body:

{ "visible": true }

Mode-specific behavior:

• allowlist: show inserts or updates an allow rule; hide deletes the rule.
• blocklist: hide inserts or updates a block rule; show deletes the rule.
• all: first hide switches operator mode to blocklist and inserts a block rule.

Common mistakes

• assuming hiding cancels exposure or makes a private operator-owned market public
• changing visibility without re-running operator smoke checks
• assuming market visibility can fix wallet or webhook issues