> For the complete documentation index, see [llms.txt](https://docs.trustlesswork.com/trustless-work/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-types.md). # Escrow Types Compare Single-Release and Multi-Release escrows and choose the settlement model that fits your workflow. Trustless Work supports two escrow types: * **Single-Release Escrow** — multiple conditions can lead to one final settlement. * **Multi-Release Escrow** — milestones can settle independently over time. Both use the same V2 foundations: * role-based authorization * multiple Service Providers, Approvers, Release Signers, and Dispute Resolvers * threshold approvals * milestone status and evidence * programmable disputes * non-custodial asset custody * optional platform fees The main difference is **where the economic outcome lives**. > **Single Release protects one final payment. Multi Release protects a series of payments.** *** ### Single-Release Escrow A **Single-Release Escrow** protects one amount that is released once the required conditions have been satisfied. The escrow can contain one or many milestones, but those milestones collectively govern **one final settlement**. #### How it works A typical Single-Release flow is: 1. Define the escrow amount and Receiver. 2. Define one or more milestones. 3. Fund the escrow. 4. Service Providers report progress. 5. Approvers validate the milestones. 6. Each milestone reaches its required approval threshold. 7. A Release Signer releases the full protected amount. 8. The Receiver receives the net payment after applicable fees. #### Example Imagine a client hires a development studio for a **10,000 USDC project**. The agreement has three milestones: 1. Design approved 2. Application deployed 3. Final handoff completed The milestones help the parties track and validate progress, but they do not represent three separate payments. ``` Protected amount: 10,000 USDC Milestone 1 → approved Milestone 2 → approved Milestone 3 → approved All approval requirements satisfied ↓ Release 10,000 USDC ↓ Receiver ``` This is a good Single-Release use case because the parties want **one protected final payment** after several conditions have been met. *** ### Single-Release properties In Single Release, these properties belong to the escrow as a whole: * **Amount** * **Receiver** * **Release state** * **Dispute state** Milestones contain: * description * status * evidence * approval requirements * approval votes The milestones answer: > **Have all the conditions for the final settlement been satisfied?** *** ### When to use Single Release Single Release works well when the transaction has: * one final economic outcome * one Receiver * several checkpoints before payment * a final acceptance process * no need to pay individual milestones independently Common patterns include: * security deposits * final-delivery marketplace payments * one-time service agreements * project retainers * purchase agreements * milestone-verified payments that settle only at completion *** ## Multi-Release Escrow A **Multi-Release Escrow** turns each milestone into an independent settlement unit. Each milestone can define its own: * amount * Receiver * approval requirements * release state * dispute state This allows funds to move progressively instead of waiting for the entire agreement to finish. *** ### How it works A typical Multi-Release flow is: 1. Define the agreement and its milestones. 2. Assign an amount and Receiver to each milestone. 3. Fund the escrow. 4. Service Providers report progress. 5. Approvers validate milestones. 6. A milestone reaches its required approval threshold. 7. A Release Signer releases that milestone's funds. 8. The remaining milestones continue independently. Eligible milestones can also be released **in batches**. *** ### Example Imagine a grant program allocates **6,000 USDC** across three stages: | Milestone | Amount | Receiver | | ----------------- | ---------: | -------------------- | | Research | 1,000 USDC | Research team | | Prototype | 2,000 USDC | Development team | | Production launch | 3,000 USDC | Project organization | The escrow might eventually look like: ``` Milestone 1 1,000 USDC Approved → Released Milestone 2 2,000 USDC Approved → Ready for release Milestone 3 3,000 USDC In progress ``` Milestone 1 does not need to wait for Milestones 2 and 3 before being paid. That is the core advantage of Multi Release. *** ### Multi-Release properties In Multi Release, economic and settlement state moves down to the milestone level. Each milestone contains: * **Amount** * **Receiver** * **Approvals** * **Release state** * **Dispute state** * **Description** * **Status** * **Evidence** The milestone answers: > **Has this specific part of the agreement earned its settlement?** *** ### Independent disputes Multi Release also gives disputes a narrower scope. In Single Release, the dispute applies to the entire protected settlement. In Multi Release, a dispute applies to specific milestones. For example: ``` Milestone 1 → Released Milestone 2 → Disputed Milestone 3 → In progress ``` A dispute over Milestone 2 does not automatically make Milestone 3 disputed. This can be useful for long-running agreements where one contested deliverable should not necessarily invalidate the rest of the relationship. *** ### Batch operations Multi Release does not require every action to happen one milestone at a time. V2 supports operations across multiple milestone indices, including capabilities such as: * approving multiple milestones * releasing multiple eligible milestones * disputing multiple milestones This makes Multi Release useful not only for sequential projects, but also for workflows where several independent outcomes become ready at the same time. *** ## Single Release vs Multi Release | Dimension | Single Release | Multi Release | | --------------------------- | ---------------------------------------------- | ----------------------------------------- | | **Settlement pattern** | One final payout | Multiple payouts | | **Amount** | Escrow-level | Per milestone | | **Receiver** | Escrow-level | Per milestone | | **Approval** | Per milestone | Per milestone | | **Release state** | Escrow-level | Per milestone | | **Dispute scope** | Entire escrow | Selected milestones | | **Release timing** | After all required milestones satisfy approval | As individual milestones satisfy approval | | **Multiple Receivers** | No | Yes | | **Batch milestone release** | Not applicable | Yes | | **Best fit** | One protected economic outcome | Progressive or distributed settlement | *** ## How to choose The simplest way to choose is to ignore the number of milestones and ask: > **How many independent payments should this agreement produce?** #### Choose Single Release when: ``` Many conditions ↓ One payment ``` For example: > “Complete design, development, and deployment, then receive 10,000 USDC.” #### Choose Multi Release when: ``` Milestone 1 → Payment 1 Milestone 2 → Payment 2 Milestone 3 → Payment 3 ``` For example: > “Receive 1,000 USDC after research, 2,000 after the prototype, and 3,000 after production launch.” The number of milestones does **not** determine the escrow type. The **settlement model does**. *** ### One milestone can still use Single Release A Single-Release Escrow does not require multiple milestones. For example: ``` Milestone: Vehicle returned without damage Amount: 500 USDC deposit Approved ↓ Release 500 USDC ``` There is only one milestone and one settlement, so Single Release is the natural fit. *** ### Multi Release is not automatically better Multi Release provides more flexibility, but it also introduces more economic state: * multiple amounts * multiple release states * potentially multiple Receivers * milestone-specific disputes * more settlement events Use it when the business workflow genuinely requires **progressive or distributed payouts**. If several milestones simply determine whether one payment should happen, Single Release is usually the simpler model. *** ### Both types use the same V2 authorization model Choosing Single Release or Multi Release does not change the fundamental V2 role model. Both support: * multiple Approvers * approval thresholds * multiple Service Providers * multiple Release Signers * multiple Dispute Resolvers * Admin * Platform * Observers The escrow type determines **how settlement is structured**, not who the application is allowed to assign to these roles. [Learn more about Roles and Permissions](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/roles-in-trustless-work) *** ### Understand the underlying properties For the exact conceptual differences in where amount, Receiver, release state, and dispute state live: [Read Escrow Properties](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/what-does-a-smart-escrow-look-like) *** ### Next Once you have chosen a settlement model, the next step is understanding how that escrow moves from configuration to funding, approval, release, or dispute. [Continue to the Escrow Lifecycle](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle) --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-types.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.