Market rules schema

Market rules describe the question, its resolution criteria, and the numerical answer for each outcome. This JSON format is recommended for Polymarket, predict.fun, and Outcome requests and clarification updates.

Current API support: the Proposer API accepts binary outcomes through p1, p2, and p3. Type 2 below specifies atomic neg-risk rules; arbitrary winner-index submissions are not supported by the current API. These request types are separate from Polymarket V2 and the API's version numbers.

Request fields

Encode the rules as a UTF-8 JSON object. Every field except integration is required.

Each res_data tuple contains a JSON number followed by a nonempty outcome string. Use the explicit value, never the tuple's position in the array. Both request types use res_data.

Values are unscaled JSON numbers. Multiply the exact decimal value by 10^18 to obtain the signed on-chain integer, without floating-point arithmetic. For example, 0.5 becomes 500000000000000000. These are oracle prices, not bond-token amounts.

Use market_id to join Polymarket and predict.fun requests to their market APIs. For Outcome, supply the Hyperliquid outcome ID as a string. This external ID is distinct from the oracle question ID. For 3PO creation integrations, market_id is intended as a creation parameter from which 3PO constructs the JSON.

Type 1: binary markets

{
  "type": 1,
  "title": "Will Team A win the final?",
  "description": "Resolve Yes if Team A wins; No if Team B wins; 50-50 if cancelled.",
  "market_id": "4805182",
  "res_data": [
    [0, "No"],
    [1, "Yes"],
    [0.5, "50-50"]
  ],
  "product_spec": "",
  "integration": "polymarket"
}

Include 0, 1, and 0.5 exactly once each. Labels describe the market-specific meaning of those values.

A 0.5 settlement is valid only when the resolution rules permit it and the settlement contract supports it. Its presence in res_data does not authorize that result; do not choose it merely because you are uncertain. Too early is an oracle voting action and is not included in res_data.

Type 2: atomic neg-risk

{
  "type": 2,
  "title": "Tournament winner",
  "description": "Resolve to the winning team's condition index; use 3 if cancelled.",
  "market_id": "4805183",
  "res_data": [
    [0, "Celtics"],
    [1, "Lakers"],
    [2, "Hunters"],
    [3, "Cancellation"]
  ],
  "product_spec": "",
  "integration": "polymarket"
}

Here, the value is the actual zero-based on-chain condition index, expressed as a JSON integer. Lakers selects index 1, encoded as 1000000000000000000. The selected outcome resolves Yes; all other real outcomes resolve No.

• Values must be unique, nonnegative integers below the event's registered capacity, also called its arity.
• Include every assigned outcome. Omit unused reserved slots; they may be assigned later only within the original capacity.
• Cancellation or None of the above must be registered as real outcomes when supported by the rules. The synthetic Other at index arity is not a selectable atomic winner.
• The selected index must appear in res_data after applying valid, authorized clarifications. An unassigned reserved slot is not selectable, even if its index is below the registered capacity.

Clarification updates

A clarification changes permitted rule fields. It is separate from an answer proposal, which selects and signs a numerical answer to an existing request. Only authorized actors may issue clarifications.

An update must contain one or more of these fields:

Omitted fields remain unchanged. Reject empty updates, unknown fields, and updates containing the immutable fields type, market_id, or integration.

For the Type 2 example, if the event originally reserved slot 4, this update assigns it to Heat:

{
  "res_data": [
    [0, "Celtics"],
    [1, "Lakers"],
    [2, "Hunters"],
    [3, "Cancellation"],
    [4, "Heat"]
  ]
}

Repeat all unchanged tuples and preserve existing value-to-outcome identities. Do not send only the new tuple or increase the event's registered capacity. Other request fields remain unchanged.

This schema defines the update payload and its interpretation. It does not define a clarification-submission endpoint. The Proposer API endpoints submit answers, not rule changes; use the integration's authorized clarification mechanism.

Validation

Reject malformed JSON, unsupported types, missing required fields, tuples with other than two elements, nonnumeric values, empty or nonstring outcome labels, and duplicate values. Numbers must use canonical plain decimal notation, convert exactly, and fit signed 256-bit encoding after scaling.

Apply the request-specific mapping rules to both creation and updates. The specification calls for update-format validation at Managed OO submission and semantic checks during request processing, including authorization of the update's source.

Before proposing

Read the original rules and all valid, authorized clarifications before choosing an answer. Verify the final evidence, selected value, and applicable settlement rules. For binary API submissions, compare the returned outcome label and price with those rules; API acceptance does not establish that your answer is correct.

Keep the original request ancillary bytes for question-ID derivation and signing. Do not hash reserialized JSON or a reconstructed rules object with clarifications merged into it. Preserve any suffix already present in the original request.

Continue with your first proposal or the endpoint reference.