# Market lifecycle
Source: https://docs.chain.link/solutions/prediction-market-resolution-engine/reference/lifecycle

> For the complete documentation index, see [llms.txt](/llms.txt).

`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).

## Event statuses

| `event_status` | Meaning                                                                                                                                    |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| `scheduled`    | The event has not started.                                                                                                                 |
| `live`         | The event is in progress. No outcome is ready.                                                                                             |
| `postponed`    | The event is delayed and can be rescheduled. A new `scheduled_start` appears when it is.                                                   |
| `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.                           |

`unsafe` is not terminal. A later round of evidence can move the event back to `final`. A market that stays unsafe never receives an outcome, and an absent outcome is not `NO`.

To list events in particular statuses, pass `status` to [`/events`](/solutions/prediction-market-resolution-engine/reference/market-registry-api#list-events). Repeat it to match several.

## Transitions

![An event starts as scheduled and moves to live when it starts, then to final when it ends, then to completed when resolution and delivery finish. A final event moves to unsafe on an evidence conflict or gap, and back to final when the evidence resolves. A scheduled or live event can be postponed, and a postponed event returns to scheduled when rescheduled. A scheduled or live event can be cancelled. Completed and cancelled are terminal.](/images/solutions/prediction-market-resolution-engine/event-status.svg)

| From                  | To          | When                                        |
| --------------------- | ----------- | ------------------------------------------- |
| `scheduled`           | `live`      | The event starts.                           |
| `live`                | `final`     | The event ends and outcomes are determined. |
| `final`               | `completed` | Resolution and delivery are complete.       |
| `final`               | `unsafe`    | Evidence is missing or conflicting.         |
| `unsafe`              | `final`     | The evidence resolves.                      |
| `scheduled`           | `postponed` | The event is delayed.                       |
| `live`                | `postponed` | The event is suspended.                     |
| `postponed`           | `scheduled` | The event is rescheduled.                   |
| `scheduled` or `live` | `cancelled` | The event is cancelled.                     |

`completed` and `cancelled` are terminal for resolution. If a provider relists a cancelled event under the same fixture, the event returns to the catalog with the same slug. A relisting under a new fixture is a new event with a new slug.

## Rescheduling

A rescheduled event keeps its slug. The date in an event slug is part of the identifier, not the current schedule; read `scheduled_start` for timing. Because `/events` filters by `scheduled_start`, a rescheduled event can move into or out of a date window.

## Resolution timing

Resolution follows the real end of the event, not its scheduled start: the engine resolves once the data providers confirm a final result and agree. Overtime, extra innings, and delays move that point. Resolution takes longer when providers are slow to mark a result final, or while the event is `unsafe`.

## Next steps

- [Track event status](/solutions/prediction-market-resolution-engine/tutorial/track-event-status): Read these statuses from the API.
- [Trust and failure handling](/solutions/prediction-market-resolution-engine/overview/trust-and-failure-handling): Why an event becomes `unsafe`.

## Disclaimer

Please note, this repo contains community examples only — these are not Chainlink products or services and are not supported or maintained by Chainlink. This code represents an example of using a Chainlink product or service, and is intended for demonstration and educational purposes only. It is provided “AS IS” and “AS AVAILABLE” without warranties of any kind, may not have been audited, and may omit checks or error handling. Each party intending to use this example code does so entirely at their own risk and must perform its own audits, security and code review, key management, and testing before any production deployment and ensure the operation and performance of such code matches expectations. Neither Chainlink Labs nor the Chainlink Foundation deploys, operates, monitors, maintains or endorses any deployment of this code. Note that this is not a Chainlink product, feature or service, and there are no commitments made with respect to the code, including compatibility with future Chainlink releases. You should not rely on this code without first conducting your own technical, engineering, and security review. This code is also outside the scope of any Chainlink bug bounty programs. Neither Chainlink Labs, the Chainlink Foundation, nor Chainlink node operators are responsible for outcomes due to errors in this example or how it is deployed or operated, or liable for any resulting claims or damages. Use of the Chainlink Network is subject to the Chainlink Foundation [Terms of Service](https://chain.link/terms), which provides important information and disclosures. By using this code, you acknowledge and agree to these terms.