> 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/orders-and-identity.md).

# Orders and Task Identity

Sessions, signed orders, Task identity, replacement, and budget admission.

A User submits work through a Session. The Session owns an ordered sequence of Task positions and prevents an old order from being replayed as a new request.

## Session and sequence

A Session has one owner and a monotonically increasing expected order sequence. Creating a Session is an on-chain action, so the User account and public key are available before any offline order signature is evaluated.

For a new Task, the submitted sequence must equal the Session's next expected sequence. The sequence is consumed only when the first valid Open Task proposal is accepted. Failed local uploads or rejected proposals do not advance it.

## Stable position and signed version

TrueOpen distinguishes:

* `task_id`, the stable position derived from the Session and order sequence.
* `task_hash`, the digest of one exact `TaskOrderV3` value.

This distinction allows a User to replace an unaccepted order at the same Task position while preserving a stable reference. Once the first proposal is accepted, its `task_hash` becomes authoritative and competing versions are rejected.

A signed order binds at least the User, Session, order sequence, chain, model Profile, generation constraints, price bid, maximum fee, expiration, and the anchor inputs needed to determine the Task Builders. The signature does not become a general transaction authorization.

`model_id` is a 32-byte hash in the order and its canonical hash input. The user signs the EIP-712 order domain at version `3`, where `modelId` is `bytes32`. The `SignedOrderV2` envelope carries that signature and the `TaskOrderV3` value; its envelope name does not make the order a V2 schema.

`input_hash` commits to the exact input bytes sent to Task Builders. Transport must preserve those bytes across retries and must not normalize or reserialize them after the order is signed.

## Admission is atomic

The first accepted Open Task proposal must validate all of these before changing state:

* User signature and Session ownership
* Expected sequence and unexpired order
* Model and Profile admission state
* Budget arithmetic and User balance
* Candidate-pool and Builder-set snapshots
* At least one valid Worker handraise

Only after all checks pass does the protocol consume the sequence, freeze `max_fee` in Task escrow, lock the order version, and record the Task snapshots. Partial admission is forbidden.

## Historical stability

The Task freezes the Profile version, pricing inputs, verification rules, maintenance rate, gas-reimbursement policy, candidate source, Builder set, and other versioned rules used by later stages.

Governance or market changes after admission affect future Tasks. They do not change the price, judgment rule, candidate weight, or Task Builder group of an accepted Task.


---

# 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/orders-and-identity.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.