“Will it reach 30 degrees?” leaves room for several different trades. A weather app’s rounded forecast, a station’s measured temperature and an official report published later can disagree. The market needs to say which one determines payment before anyone buys YES or NO.
This sixth article in How Polymarket and Kuest work turns that question into a testable rule, then follows its evidence through the system’s separate layers. A readable page, committed resolution bytes and an accessible metadata document each prove something different.
Rewrite the question until two readers get the same answer
Keep our fictional Observatory A, City B and Date C. “At 12:00” must identify the observation time or the publication deadline; those are different events. Rewrite the title as: “Will Observatory A’s 12:00 UTC observation for City B on Date C be at least 30.0°C?” Then specify the evidence:
Use Observatory A’s official daily observations CSV, station B-01, for Date C. Read the air-temperature field in degrees Celsius for the record timestamped 12:00:00 UTC. Use the latest official revision available by 13:00:00 UTC on Date C, including a revision published exactly at that cutoff. Compare the published numeric value directly with 30.0; do not round it again. A valid value of 30.0 or above means YES; a valid lower value means NO. Ignore forecasts, other stations and later revisions. If, at that cutoff, the record has been withdrawn, conflicting records lack an authoritative revision order, or no valid record is available, use the specified unavailable-data outcome.
In a real market, replace every fictional name and date with the exact source URL, station identifier, calendar date and field definition. “Official website” alone leaves readers choosing among pages, mirrors and revisions. A backup source also needs a stated priority; otherwise it adds another choice after the outcome is known.
Here, 29.96 means NO even if an app displays 30.0. A correction from 29.9 to 30.1 before the cutoff means YES; the same correction afterward does not change the selected observation. Equality is explicitly YES, so the threshold has no unresolved tie.
Observation time selects the record. The cutoff selects its revision. The payout policy handles missing evidence.
The unavailable-data outcome must match the chosen contract route. For this teaching example, assume a standard binary adapter supporting UNKNOWN: YES pays one collateral unit and NO zero for a YES result, the reverse for NO, and each pays half for UNKNOWN. This is an explicit model assumption, not a universal cancellation rule or a NegRisk payout policy.
Half a unit per token is not a refund of its purchase price. A participant who paid 0.80 for YES receives 0.50 under that assumed result. The split and redemption mechanics determine the payment; the rules determine which supported result should be reported.
A source deadline, trading cutoff and resolution time serve different purposes. The first selects evidence; the second controls order admission; the third records a result. For example, orders could stop at 11:55 UTC while eligible revisions remain open until 13:00; resolution can follow later. The operator must configure trading separately, and a delayed transaction does not extend the evidence cutoff.
Follow two kinds of evidence
A market needs both a defined resolution question and readable supporting information. Ancillary data means the extra question bytes used by a particular oracle integration; descriptive metadata can also include images, labels and links. They serve different purposes and must not be treated as interchangeable commitments.
The public Polymarket CTF adapter is one example of question data recorded under a defined encoding. Recomputing a commitment requires that exact encoding, not a visually similar paragraph. Check the published interface of the chosen deployment instead of generalizing an example across adapter families.
The question commitment and an external document support different checks; a reference does not by itself prove integrity or availability.
Kuest’s publicly verified Conditional Tokens contract records a creator and an external metadata reference. A reference locates information; it does not by itself prove that a document is available, immutable or identical to the original resolution commitment. Retrieve the documents and compare them with the recorded question evidence.
Kuest’s public market-creation documentation describes the supported product interface. An uploaded document, a prepared condition and a tradable listing are separate observations. Confirm the appropriate records rather than inferring all three from one successful screen.
Similar-looking identifiers have different jobs
A slug locates a page. A question ID identifies a question under its adapter’s scheme. A condition ID combines oracle, question ID and outcome count in the public CTF construction. The exact inputs matter; similar page text does not establish identical conditions.
A position ID identifies the asset held and traded. In CTF, its derivation also depends on the collateral and collection representing the outcome set. Matching titles or slugs cannot establish identical assets. The creator address records attribution and certain permissions; the external metadata identifier locates descriptive content. Neither replaces the condition or position ID.
Even “question ID” is not a universal encoding. In Polymarket’s specific NegRiskIdLib, a question shares its market ID’s first 31 bytes and uses the last byte for its question index. Apply that rule only to that adapter family, not to every oracle question.
The metadata field in a signed exchange order is another object. For example, the public CTF Exchange V2 definition includes an order-level bytes32 metadata. Its presence is not proof that the signature commits to the market’s displayed document.
A traceable update is still an update
Kuest’s Conditional Tokens extension records the condition creator and current external metadata reference. The creator or a CTF admin can replace that reference. Each successful call increments a counter and emits the condition ID, old reference, new reference and updater address.
The inspected function has no freeze at resolution and no check that a replacement string points to available, nonempty content. An unchanged condition ID therefore does not mean its current displayed description has never changed. An update might instead add a supporting reference or correct an image; compare the actual documents before deciding whether the proposition changed.
A reference update can enrich a document or change its description. The event reveals who changed the pointer; compare the contents.
Changing the pointer does not rewrite the original question bytes or grant a new right to report payouts. CTF’s reporting function derives the condition using the caller as oracle. The adapter and its configured resolution route govern how a result reaches that function; metadata-edit permission is a separate power.
Suppose version A says 30.0°C and version B says 31.0°C. A history event makes the replacement visible; it does not establish that 31.0 became the legitimate threshold. Compare both with the original ancillary bytes and the applicable clarification policy before interpreting the change.
Clarifications need an author and a policy
Polymarket already has on-chain question commitments. Its pinned UMA CTF adapter hashes and stores augmented ancillary data, while its bulletin board records attributed updates. These are specific CTF-adapter mechanisms, not an ABI claim for every current Polymarket route.
A clarification also needs an identifiable author and an applicable policy. In the public Polymarket example, an attributed post does not rewrite the original ancillary data. Do not treat an arbitrary statement mentioning a question as an official amendment.
Polymarket’s current resolution documentation says clarification context should preserve fundamental intent. Identifying a renamed CSV column can clarify evidence; replacing a 30.0 threshold with 31.0 changes the proposition. A timestamp proves when a statement was recorded, not that it has legitimate authority.
Verify the path from reference to screen
A practical review follows the evidence in order:
- Identify the deployment. Record network, contract addresses, adapter family and a block reference. Obtain the creation receipt, original question bytes, oracle identity, creator and condition ID.
- Recompute the appropriate identifiers. Use that implementation’s encoding, initializer treatment and outcome count. Check position IDs against the actual collateral and outcome mapping.
- Follow metadata history. Read the preparation reference, current reference, counter and update logs. Retrieve original and replacement documents, then compare changes and updater addresses.
- Check integrity and availability separately. Validate content using the storage system’s actual transaction or commitment scheme. Preserve exact retrieved bytes and provenance; a recorded reference cannot serve a document that nobody can retrieve.
- Compare what participants see. Match the displayed source, dates, rules and outcome labels against the original resolution data and authorized context. A readable interface is not an independent integrity check.
A reachable document, valid provenance and matching display are separate checks. None alone establishes the correct resolution.
For a branded operator, Kuest’s concrete addition is creator-linked metadata references and visible update history alongside original resolution data. That supports a reviewable catalog and an attributable publishing process. It does not put all market information on-chain, guarantee document availability or settle a disagreement about meaning.
Launch your own prediction market with Kuest by bringing a defined audience and jurisdictions, a worked rule sheet, source and correction policies, a supported resolution route and a plan to retain accessible evidence. Test those inputs against ambiguous examples before accepting trades.