Market Requests
Market Requests
Unreleased: this guide describes the current repository workflow, not an accepted or deployed service. Wait for Polynion to confirm availability in your environment before relying on it. See the changelog.
When enabled, use Operations → Market Requests (/market-requests) to review requests and Operations → Request Create Market (/market-requests/create) to submit one.
- Viewing requests, details, and market options requires a human staff session with
markets:read. - The creation page requires both
markets:readandmarkets:write; submission requires market-write authorization and explicit risk acceptance. - Operator API keys cannot use these staff-only workflows, even with
*. - Requests belong to the authenticated operator; there is no operator selector.
Only staff authorized to accept the operator's commercial risk should receive write access. Submission creates a pending request, not a published market. The operator UI cannot approve, reject, edit, or resolve a market.
Prepare the exact terms
| Field | Requirements |
|---|---|
| Title | Required, maximum 255 characters. |
| Description / resolution criteria | Required, maximum 10,000 characters; state how the winning outcome is determined. |
| Category | Select an active category from the loaded options. |
| Resolver label | Required, maximum 100 characters; no commas. |
| Resolver URL | Required HTTP(S) source URL, maximum 512 characters; no commas. Use the English /en/ version for LiveScore sources. |
| Initial YES price | 1–99% (100–9,900 BPS); NO is the complement. |
| Virtual market depth | Whole number from 50 to 500 shares. |
| Tags | Optional selections from available tags. |
| Image URL | Optional HTTP(S) URL, maximum 512 characters. |
| Custom YES/NO labels | Optional, maximum 32 characters each. |
If options fail to load, use Retry loading options; do not substitute unlisted categories or tags. There is no publication fallback when validation fails.
All schedule fields are UTC
Enter Open at, Trading cutoff, and Resolution deadline. Despite the date/time control's appearance, these values are interpreted as UTC, not browser-local time; review the displayed ISO timestamps.
current time < opening < trading cutoff <= resolution deadline
The mandatory deadline must also fit the operator's configured maximum market duration. An estimated resolution time is not a substitute. Leave enough review time before opening: approval rechecks the actual approval time, category/tags, operator eligibility, and duration constraints. Dates are not shifted automatically. A request whose opening has passed cannot be approved; submit a new request with valid dates.
Shares, depth, and underwriting risk
Read How shares, depth and operator risk work, then accept risk only if authorized:
- One whole winning share redeems for 10,000 Credits, approximately USD 1 at the current conversion. One microshare is one millionth of a share. This is not a fixed operator-currency price guarantee.
- Purchase price depends on probability and AMM price movement; trade fees are additional. Existing execution FX snapshots determine operator-currency settlement.
- Virtual depth is an AMM pricing/slippage parameter, not cash collateral, a deposit, a budget, or a maximum payout. A 500-share depth does not cap liability at USD 500.
- The requesting operator retains 100% of principal trading gains and losses and bears sell proceeds and winning redemption payouts. Configured platform trade-fee sharing remains unchanged; underwriting does not replace it.
- Approved ownership is permanent and private to the requesting operator's Mini App, subject to visibility/geographic/duration eligibility. Public Polynion users and other operators cannot gain access through visibility rules.
- Approval adds an allow rule for the owner. Automated platform liquidity/risk repricing is disabled for these operator-underwritten markets. Hiding a market later does not erase positions, liability, or ownership, and is not market delisting.
Review all terms before selecting Submit exact terms for review. Requests cannot be edited after submission. The success state provides View request #…; retain this request ID rather than submitting a duplicate because no market is visible yet. A displayed request error keeps the current form draft, but this is not a promise of saved drafts after leaving or reloading the page.
Track review
On Market Requests, filter All, Pending, Approved, or Rejected; choose 20, 50, or 100 requests per page and use Refresh for updated review state. Open a request to see exact submitted terms, submitting/reviewing actor IDs, timestamps, review reason, and the approved market ID/slug when present.
| Status | Meaning and next step |
|---|---|
| Pending | Await Polynion review. No market has been published by submission. |
| Approved | The exact terms and permanent ownership were published atomically; use the recorded market ID/slug. Opening and eligibility rules still apply. |
| Rejected | Read the reason. Submit a new request if corrected terms are appropriate; the rejected record remains as evidence. |
If a pending request is stale or unavailable, use Operator Support with environment, request ID, submitted schedule, status/review reason, and error code. Do not send credentials or assume an approval deadline/SLA not agreed with Polynion.
Reporting after publication
Market PnL remains user confirmed-wallet cash flow, not operator principal profit. Opinion Settlement Reports separate operator-underwritten principal/payout exclusions from platform-underwritten amounts. Private principal and payouts are not principal owed to or reimbursable by Polynion; the existing platform fee share remains payable.
Source API
Staff-only source routes are GET /api/operator/market-requests, GET /api/operator/market-requests/options, GET /api/operator/market-requests/{id}, and POST /api/operator/market-requests. The operator interface provides no request edit/review endpoint.
See the Market Requests API reference for strict request schemas, response objects, and errors. The same rollout caveat applies.