Write a question that can be settled
Start with the exact event a market will measure. A question such as “Will the network launch this year?” leaves several interpretations: a public test, a production release, or unrestricted access. Specify the qualifying event, the named evidence source, the cutoff time, and the time zone. Include a worked example of an outcome that qualifies and another that does not. Ask someone outside the project to interpret the wording. If two reasonable readers reach different answers, improve the rule before accepting positions.
Decide the awkward cases before they happen
A useful market specification describes postponements, cancelled announcements, renamed projects, unavailable websites, and corrections to published data. Decide whether a replacement source is permitted and who selects it. Explain how a result published after the cutoff is treated, even when the underlying event happened earlier. These are product decisions that should be visible before participation. Put the agreed text under version control and attach its version to the market record. Later editorial changes must never silently rewrite the terms under existing positions.
Separate proposal from final settlement
UMA’s oracle documentation distinguishes a proposed answer, a challenge period, and a dispute path. Whatever mechanism a product adopts, model its stages explicitly. Closing trading should not itself create a final outcome. A resolution proposal should identify its evidence and timestamp; an accepted outcome should identify the completed rule that made it final. Define who can perform each transition and which checks happen on the server. Customer interfaces and operator tools should read the same durable state instead of independently guessing progress.
Make disputes understandable
A participant should be able to see what is being challenged, when the response window ends, and what happens next. Keep the original proposal, the counterargument, and their supporting evidence distinguishable. Avoid a single editable notes field that erases earlier reasoning. Provide a clear process for reporting a broken link or an ambiguous rule without promising a particular decision. Administrative permissions need the same discipline: reviewing evidence, proposing a correction, and authorizing settlement should be separately identifiable actions with an audit history.
Test the money movement independently
Build settlement tests around recorded positions and an agreed outcome. Verify rounding, partial positions, reserved balances, refunds where the published rules require them, and repeated delivery of the same result. A worker restarting halfway through settlement must not pay some positions twice. Reconcile the total released, retained, and returned amounts against the starting ledger. Include interrupted database writes and delayed provider responses in acceptance examples. A correct headline result is insufficient when the accounting that follows it cannot be reproduced and explained.
Ship the evidence with the interface
The final market page should preserve the question, rule version, relevant deadlines, outcome, and evidence trail. Show pending resolution honestly and distinguish it from a failed service request. Test dates across locales and screen sizes so that a translated label cannot hide the actual cutoff. Before launch, have product, operations, and engineering walk through one normal result and one disputed result together. The deliverable is a repeatable decision process with accountable records, supported by a clear interface and an explicit operating policy.