Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
melchermaxwell
left a comment
melchermaxwell
left a comment
There was a problem hiding this comment.
A few suggested edits, each of which can be applied directly from its comment.
llms-full.txt is generated from these pages, so I didn't leave suggestions on it. After applying, please regenerate it:
npm run generate:llms -- --section solutions/prediction-market-resolution-engine
Co-authored-by: Maxwell Melcher <melcher.maxwell@gmail.com>
| | `final` | Every market reached a terminal state. Outcomes are determined, except for markets that were cancelled. Delivery can still be in progress. | | ||
| | `completed` | Resolution, and delivery where configured, are complete. | | ||
| | `cancelled` | The event will not occur. | | ||
| | `unsafe` | At least one market has missing or conflicting evidence. Nothing is delivered for it. The engine keeps checking. | |
There was a problem hiding this comment.
sorry my bad, this should be:
event_status |
Meaning |
|---|---|
final |
The event is over. Resolution is in progress or complete. Outcomes are determined where the evidence supports them. A market that cannot be decided stays unresolved and the engine keeps checking. final does not guarantee that every market has an outcome. Delivery can still be in progress. |
unsafe |
The event itself is parked for review because the engine cannot decide it. This is an event-level state for derived and AI Oracle events. For an ordinary fixture, an unsafe market does not change the event from final. The API does not expose per-market status. unsafe is not terminal. |
completed is the reliable done signal. Status sync sets final when the provider reports the event final. The evidence applier sets a market unsafe without changing the event. Only the tournament resolver and the AI Oracle rollup set the event unsafe.
Update the transition table and event-status.svg to match. The same status error is in outcome-delivery.mdx, trust-and-failure-handling.mdx, track-event-status.mdx, glossary.mdx, and how-it-works.mdx.
|
|
||
| import { ClickToZoom } from "@components" | ||
|
|
||
| `event_status` is the only lifecycle signal in the Market Registry API. Every market on an event shares its event's status. The API does not return a per-market status or outcome; outcomes reach your platform as agreed with Chainlink. See [Outcome delivery](/solutions/prediction-market-resolution-engine/overview/outcome-delivery). |
There was a problem hiding this comment.
This is not true for final events. A market can be unsafe while the event stays final. Say the API exposes one status per event and no per-market status.
Line 53 should also say "while a market is unsafe", not "while the event is unsafe".
| | -------------- | ----------------------------------------------------------- | | ||
| | `live` | No outcome yet. The event is in progress. | | ||
| | `unsafe` | No outcome. The evidence cannot support an answer yet. | | ||
| | `final` | Outcomes are determined. Delivery can still be in progress. | |
There was a problem hiding this comment.
sorry my bad, this should be:
final is set when the event ends, not when the outcome is determined. It does not guarantee that every market has an outcome. completed is the done signal. unsafe is an event-level review state. An ordinary fixture with an unsafe market stays final.
Use the corrected status table in reference/lifecycle.mdx. Also say "normally" before "providers are not queried again" because settlement falls back to a live fetch when no stored box exists.
|
|
||
| | Dependency | What it does | How it is protected | | ||
| | ----------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | Data providers | Report the real-world result | At least two independent providers must agree, and every provider must report a final result. Chainlink monitors providers for outages and discrepancies. | |
There was a problem hiding this comment.
Quorum is per measurement profile, not always two. Weather uses one provider. Calendar rules require quorum 1. A provider that errors is excluded. If enough usable providers remain, resolution proceeds.
Suggest:
The market's measurement profile sets a quorum. Most sports markets require two independent providers. A single authoritative source can be approved with quorum 1. Every provider whose value is counted must report it as final. If fewer than quorum usable providers remain, no outcome is delivered.
There was a problem hiding this comment.
again @melchermaxwell not sure if we want to mention this or not
| | The event is cancelled | Delivers no outcome. | `cancelled` | | ||
| | The event is postponed | Moves the checks for every market on the event. | `postponed` | | ||
|
|
||
| `unsafe` is not final. A later round of evidence can resolve the event, which then moves to `final`. A market that stays unsafe never receives an outcome. The [Market lifecycle](/solutions/prediction-market-resolution-engine/reference/lifecycle) reference lists every status and transition. |
There was a problem hiding this comment.
sorry my bad, this should be:
An unfinished event can be scheduled, live, or postponed. A provider error can leave the event status unchanged while markets retry. For an ordinary fixture, conflicting evidence leaves the event final with an unsafe market. It does not set the event to unsafe. Event-level unsafe is for derived and AI Oracle events.
Use the corrected status table in reference/lifecycle.mdx. The note at line 45 only applies to event-level unsafe.
| ## What your platform gets | ||
|
|
||
| - **Answers from agreement, not from one source.** At least two independent providers must agree before an outcome is accepted automatically. | ||
| - **No challenge period.** Once the data providers confirm a final result and agree, the engine resolves the market. It does not wait for a proposal to go unchallenged. |
There was a problem hiding this comment.
Two fixes in these bullets. Quorum is per measurement profile, not always two. Weather and calendar can use one provider. Resolution has no challenge period, but settlement can have a dispute window.
Suggest:
Answers from agreement. The market's quorum must agree before an outcome is accepted automatically. Most sports markets require two independent providers.
No challenge period in resolution. Once the data providers confirm a final result and agree, the engine resolves the market. Settlement may still follow your platform's dispute window.
|
|
||
| | `event_type` | Event | | ||
| | ------------------------ | ------------------------------------------------------------------------------------------------ | | ||
| | `match` | An ordinary fixture. | |
There was a problem hiding this comment.
match is the default event type, not only a fixture. ClassifyEventType returns it for calendar and AI Oracle events too. Broaden the row or @melchermaxwell should we classify those events separately.
| | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | `400` | Invalid query: missing `from` or `to`, an invalid date, a range over 16 days, an invalid filter value, or an invalid `limit` or `offset`. The body is `{"error": "<message>"}`, such as `{"error": "from and to are required (UTC dates YYYY-MM-DD)"}`. | | ||
| | `401` | The `Authorization` header is missing, or the organization does not have Prediction Markets access. For the second case, the body is `{"error": "prediction-markets access is not enabled for this organization"}`. | | ||
| | `403` | The API key is not valid. | |
There was a problem hiding this comment.
The control plane's /user/v1 handlers return 401 for a missing or disabled claim (user_auth.go). No user route returns 403. Remove this row unless something upstream returns 403 for an invalid key. The tutorial lines list-markets.mdx:91 and before-you-begin.mdx:43 repeat the 403.
| | `403` | The API key is not valid. | | ||
| | `404` | The path does not exist. | | ||
| | `500` | Unexpected server error. | | ||
| | `503` | `/taxonomies` is temporarily unavailable. | |
There was a problem hiding this comment.
This is a configuration error, not a temporary outage. The handler returns 503 only when deps.Coverage == nil. The body is {"error":"coverage not configured"}.
Suggest:
503|/taxonomiesis called while the service has no coverage store configured. Body:{"error": "coverage not configured"}.
|
|
||
| Chainlink resolves a market only when its answer can come from data that meets this standard: | ||
|
|
||
| - **At least two independent providers.** Automated resolution requires agreement between at least two independent providers that report the facts the question needs. |
There was a problem hiding this comment.
Quorum is per measurement profile, not always two. Weather uses one provider and calendar rules require quorum 1. This bullet also contradicts the single-source exception on line 62. See the suggested wording on trust-and-failure-handling.mdx:14.
There was a problem hiding this comment.
@melchermaxwell idk what balance we want to say here
Co-authored-by: Maxwell Melcher <melcher.maxwell@gmail.com>
Add Prediction Market Resolution Engine solution docs
Adds a new multi-page solution, prediction-market-resolution-engine, describing Chainlink's managed service for resolving prediction markets. It covers how the service works, how to read the Market Registry API, and how to follow resolution progress. Content follows the live /user/v1 API and its OpenAPI spec, not the earlier design docs.
Overview: Overview, How it works, Supported markets, Trust and failure handling, Outcome delivery
Tutorial: Before you begin, 1. List markets, 2. Track event status
Reference: Market Registry API, Market lifecycle, Glossary
Open TODOs: the pages contain open TODOs pending product input: access contact, coverage requests, delivery formats, incident contact, and onchain record details.