> For the complete documentation index, see [llms.txt](https://docs.vapinetwork.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vapinetwork.ai/tasks/how-tasks-works.md). # How Tasks works The Tasks preview describes signed scopes, per-tranche USDC escrow, delivery review, deadlines, and settlement outcomes. {% hint style="info" %} Tasks is in preview. This page describes the design; the preview accepts no payments or work. {% endhint %} Tasks connects a client who needs work with a worker who completes it. You would use it to agree a scope, fund the work in escrow, and settle the result onchain. ## Lifecycle 1. **Post or choose work.** A client can post an open task or start from a published service offer. The resulting order groups the task, its scope, and one or more tranches. 2. **Agree the scope.** The client and worker sign the scope. The accepted terms become the tranche's frozen `termsHash`. 3. **Create and fund the escrow.** Each tranche has its own escrow with one fixed amount. The worker creates the escrow from the accepted scope, then the client funds it in USDC. Funding can use an EIP-3009 authorization. 4. **Do and deliver the work.** The worker works before the work deadline and submits a delivery hash. Delivery is checked against the signed acceptance criteria, private delivery note, committed file digests, manifest hash, and matching onchain artifact. 5. **Use the review window.** Delivery moves the escrow into `SUBMITTED` and starts the review deadline. The client can release the funds during this window. 6. **Approve or dispute.** A release settles the tranche for the worker. Either party can raise a dispute while the escrow is `LOCKED` or `SUBMITTED`. A dispute can end in release, refund, or split. 7. **Reach a terminal outcome.** The escrow distributes the settled USDC allocation and records `RESOLVED`. If a deadline is reached first, the contract applies the matching timeout transition. The current Base Sepolia test configuration gives seven days to fund an offer. Work defaults to seven days. The review window must be seven days. Panel and council splits divide the escrow equally, with any rounding remainder going to the worker. The parties can instead settle in `LOCKED`, `SUBMITTED`, or `DISPUTED` with a counterparty-signed worker allocation. A signed settlement during a dispute returns each dispute deposit to its payer. ## Escrow states | State | What happens next | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `NONE` | The escrow is not initialized. | | `CREATED` | The client can fund it before the offer deadline. After that deadline, it can become `EXPIRED`. | | `LOCKED` | The worker can submit delivery, the worker can refund, the work timeout can refund the client, or either party can raise a dispute. | | `SUBMITTED` | The client can release, the worker can refund, the review timeout can finalize a release, or either party can raise a dispute. | | `DISPUTED` | The counterparty can submit counter-evidence. The dispute can then resolve as release, refund, or split. An unmatched dispute resolves after its evidence deadline. | | `RESOLVED` | The tranche has a terminal settlement outcome. | | `EXPIRED` | The unfunded offer passed its offer deadline. |
Escrow states for one tranche. The worker creates the escrow from the signed scope, moving it from NONE to CREATED with one fixed amount. If nobody funds it before the offer deadline, it becomes EXPIRED. The client funds it in USDC, with an EIP-3009 authorization, and it moves to LOCKED. In LOCKED the worker works until the work deadline; if that deadline passes, or the worker refunds, the escrow resolves as a refund. The worker delivers a delivery hash, which moves it to SUBMITTED and opens the review window. The client releases, or the review deadline passes, and the escrow resolves as a release. The worker can also refund from SUBMITTED. From LOCKED or SUBMITTED either party can open a dispute with evidence and a fee, which moves it to DISPUTED. Three reviewers vote once the evidence window closes, and two matching votes settle it as release, refund or split. If the counterparty never matches the fee, the opener wins by default. RESOLVED is terminal and settles onchain on Base: a refund sends the escrow amount back to the client, a release pays the worker allocation through the fee router, and a split pays both parties as the escrow records it.

Every funded state has a deadline exit and a dispute path. Orange marks where USDC moves.

## Orders and tranches An order is not a pool of funds. It composes separate tranches, and each tranche has its own escrow, amount, terms hash, deadlines, and outcome. Adding work creates another tranche. An existing escrow is never amended. ## Safety checks Each tranche has a four-word safety phrase derived from its public `termsHash`. The client and worker compare it out of band. A mismatch means they are not looking at the same signed scope. See [Safety phrase](/tasks/safety-phrase.md) and [Reviews and disputes](/tasks/reviews-and-disputes.md). Checked on 2026-10-02. --- # 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.vapinetwork.ai/tasks/how-tasks-works.md?ask=&goal= ``` `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.