> For the complete documentation index, see [llms.txt](https://docs.trueopen.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trueopen.ai/protocol/v1/tasks/challenges-and-settlement.md).

# Challenge and Settlement Rules

Challenge rounds, effective verdicts, final accounting, and Task finality.

TrueOpen uses optimistic settlement: the first verification-round verdict stands unless a challenge opens another independent verification round. No accounting is applied until the challenge opportunity and all opened rounds have closed.

## Challenge window

The challenge window begins when round 1 closes. Opening a challenge is permissionless: any address can lock the required challenge bond and prepay the maximum verification budget for the new round.

The opener does not choose the Verifiers, submit a replacement verdict, or need access to private Task data. The protocol selects a new Verifier set, excluding participants from previous rounds, and those Verifiers independently retrieve and evaluate the frozen Task material.

V1 allows only the configured bounded number of rounds. A Task cannot be delayed indefinitely by repeatedly opening challenges.

## Round result

Every closed round records an immutable facts commitment covering its Task, round number, accepted inference receipt, ordered Verifier results, frozen execution context, failure class, and verdict.

The latest closed round's verdict is effective. Votes are never aggregated across rounds. A challenge that reaches the same conclusion confirms the earlier result; a challenge that reaches the opposite conclusion replaces it for final settlement.

An inconclusive or unavailable challenge does not automatically prove that the previous round was wrong. Its own missing-duty and availability rules apply independently.

## Economic effect of a challenge

* If the new round diverges, the opener's bond is returned. Objectively disproved Workers or earlier Verifiers lose payment eligibility and may incur the defined ServiceBond penalty.
* If the new round concurs, the opener pays for the additional verification and forfeits the challenge bond to the treasury.
* If the round is inconclusive, the configured portion of the bond is charged and the remainder is returned.

Challenge Verifiers are paid from the opener's separate challenge budget. The User's original Task verification budget is not charged a second time.

## Settlement

Settlement is derived entirely from accepted immutable state. The transaction submitter does not supply an alternative bill, verdict, or participant list.

The settlement plan:

1. Selects the latest effective verdict.
2. Determines which Worker and round-1 Verifier slots remain payable.
3. Applies maintenance fees and recorded eligible gas reimbursements.
4. Credits claimable earnings.
5. Returns every unused unit of Task escrow to the User.
6. Records the immutable settlement facts and finality height.

All transfers and state writes occur atomically. A failure rolls back the entire plan; partial settlement is forbidden.

## Finality

A Task is final only when no round remains open, no further challenge can be opened, required fault effects are complete, and settlement succeeds. Settlement and finality are the same transition. There is no state in which a Task has paid out but can still be challenged.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.trueopen.ai/protocol/v1/tasks/challenges-and-settlement.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.