> 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-lifecycle/release-phase.md). # Release phase Execute settlement in Trustless Work V2 after approval conditions are satisfied, with explicit Release Signer authorization, fee calculation, and dispute protection. The **Release Phase** is where escrow authorization becomes settlement. This is the point where funds actually leave the escrow contract and are transferred to their intended recipients. Release answers: > **Can the approved economic outcome now be executed?** The lifecycle distinction remains: ``` Status = communication Approval = validation Release = settlement ``` Approval does not move funds. Release does. *** ## Who can release funds? Only an address assigned to the escrow's **Release Signers** role can execute a release. V2 supports multiple Release Signers. For example: ``` Release Signers: Finance Wallet Operations Wallet Settlement Service ``` Any authorized Release Signer can execute a valid release. Other roles do not gain this permission automatically. Being an: * Approver * Service Provider * Platform * Admin * Receiver * Observer does not by itself grant release authority. [Review Roles and Permissions](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/roles-in-trustless-work) *** ## Release does not bypass contract conditions A Release Signer has authority to **execute an eligible settlement**. They do not have authority to override the escrow rules. Before transferring funds, the contract verifies conditions such as: * the signer is authorized * the required approval thresholds are satisfied * the relevant settlement has not already been released * there is no unresolved dispute blocking settlement * sufficient funds are available This distinction is important: > **A Release Signer controls execution, not eligibility.** The contract determines whether the settlement is eligible. *** ## Single-Release settlement A **Single-Release Escrow** has one economic outcome. Before release, every milestone must satisfy its configured approval target. For example: ``` Milestone 1 2 / 2 approvals Milestone 2 1 / 1 approval Milestone 3 2 / 2 approvals ``` If all milestones satisfy their thresholds and the escrow is not disputed or already released, an authorized Release Signer can execute settlement. The contract then releases the **entire escrow amount**. Conceptually: ``` Escrow amount: 10,000 USDC All milestones approved No active dispute Not previously released ↓ Release ↓ Fees distributed Net amount → Receiver ``` Single Release does not pay milestones independently. The milestones collectively act as gates for one final settlement. [Compare Escrow Types](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-types) *** ## Multi-Release settlement A **Multi-Release Escrow** settles at the milestone level. Each milestone has its own: * amount * Receiver * approval state * dispute state * release state An authorized Release Signer selects the milestones to release. For example: ``` Milestone 1 Approved Not disputed Not released → Eligible Milestone 2 1 / 2 approvals → Not eligible Milestone 3 Approved Not disputed Not released → Eligible ``` The Release Signer can release Milestones 1 and 3 without waiting for Milestone 2. *** ## Batch release V2 Multi Release supports releasing multiple eligible milestones in one operation. For example: ``` Release milestones: [1, 3, 5] ``` Each selected milestone is validated independently. Every milestone in the release batch must: * satisfy its approval threshold * not be disputed * not already be released * not already have a resolved dispute Duplicate milestone indices are rejected. If the batch passes validation, settlement is executed for those milestones. This is useful for: * grant disbursements * project payouts * recurring operational settlement * marketplaces * automated settlement systems * agent-driven workflows *** ## Disputes block normal release Release cannot be used to bypass an active dispute. ### Single Release If the escrow is disputed, the normal release path is blocked. The dispute applies to the entire protected settlement. ### Multi Release If a specific milestone is disputed, that milestone cannot be normally released. Other eligible milestones can continue independently. For example: ``` Milestone 1 Released Milestone 2 Disputed → Normal release blocked Milestone 3 Approved → Can still be released ``` Once a dispute has been resolved, its economic outcome is handled through the dispute-resolution process rather than the normal release path. [Read Dispute Resolution](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle/dispute-resolution) *** ## Fee distribution Release calculates the economic distribution automatically. For each settlement amount: ``` Gross amount - Trustless Work fee - Platform fee = Net Receiver amount ``` The current Trustless Work protocol fee is: ``` 0.30% ``` The Platform Fee is the optional fee configured during escrow setup. For example: ``` Gross amount: 1,000 USDC Trustless Work fee: 3 USDC Platform fee: 10 USDC Net Receiver amount: 987 USDC ``` assuming a 1% Platform Fee. The contract performs the fee calculation during settlement. *** ## Where the fees go On release: * the **Trustless Work protocol fee** is sent to the Trustless Work fee address * the **Platform Fee** is sent to the configured Platform address * the **remaining amount** is sent to the Receiver For Single Release, there is one Receiver. For Multi Release, each released milestone pays its own configured Receiver. *** ## Release state Successful settlement updates the contract state so that the same economic obligation cannot be released twice. ### Single Release The escrow-level release state becomes: ``` released = true ``` The entire Single-Release escrow is now settled. ### Multi Release Each released milestone is updated independently: ``` Milestone 1 released = true Milestone 2 released = false ``` This prevents already-settled milestones from being paid again while allowing the remaining milestones to continue. *** ## Effects before transfers V2 updates release state **before executing token transfers**. This is an important smart-contract security pattern. Conceptually: ``` Validate settlement ↓ Mark as released ↓ Execute transfers ``` rather than: ``` Transfer funds ↓ Then mark as released ``` Updating state before external token interactions reduces the risk of the same settlement being executed recursively or more than once. *** ## Approver + Release Signer Sometimes the same participant is intentionally responsible for both validation and settlement. For example: ``` Alice: Approver + Release Signer ``` V2 supports an **approve-and-release** operation for this configuration. The signer must hold both roles. *** ### Multi Release For Multi Release, approve-and-release can: 1. approve the selected milestones 2. validate their release eligibility 3. release those milestones in a single transaction. Conceptually: ``` Approve milestones [1, 2] + Release milestones [1, 2] ↓ One transaction ``` *** ### Single Release For Single Release, approve-and-release can approve selected milestones and then attempt the final escrow settlement. However, **all milestones must satisfy their approval targets before the release can succeed**. For example: ``` Milestone 1 → already approved Milestone 2 → approve now Milestone 3 → still unapproved ``` An approve-and-release call for Milestone 2 cannot release the escrow because Milestone 3 still has not satisfied its approval requirement. Once every milestone is approved, the final settlement can execute. *** ## When should approval and release be combined? Combining both permissions can simplify workflows where the same participant legitimately controls both decisions. Examples might include: * simple marketplace payments * automated settlement policies * internal operational workflows * agent-controlled execution with predefined authority But it changes the trust model. Separating: ``` Approver ``` from: ``` Release Signer ``` creates an additional authorization boundary. Whether those roles should be separate is an application design decision. [Review the Approval Phase](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle/approval-phase) *** ## The Receiver can also be a Release Signer In some workflows, the Receiver may also intentionally be assigned as a Release Signer. That can produce a claim-like experience: ``` Approval threshold satisfied ↓ Receiver executes release ↓ Receiver receives settlement ``` In other workflows, settlement may be executed by: * a platform * an operations wallet * a finance team * an automated service * another authorized signer The contract does not infer release authority from who will receive the funds. The address must explicitly hold the Release Signer role. *** ## What happens on-chain? When an authorized Release Signer executes a valid release: 1. The contract verifies the signer. 2. Approval requirements are checked. 3. Dispute state is checked. 4. Previous release state is checked. 5. The settlement is marked as released. 6. Trustless Work and Platform fees are calculated. 7. Fees are transferred to their configured addresses. 8. The net settlement amount is transferred to the Receiver. 9. A release event is emitted. For Multi Release, this process applies to every milestone included in the release operation. *** ## Release events Successful settlement emits an on-chain release event containing the economic result of the operation. For Multi Release, the event includes payout information for the milestones released in that transaction. This provides an auditable record of: * settlement amounts * Receivers * Trustless Work fees * Platform fees * net payouts Applications can use these events to update their own settlement history and reporting. *** ## Example: Single Release Consider a 10,000 USDC development agreement. ``` Amount: 10,000 USDC Receiver: Development Studio Approvals: All milestones satisfied Platform Fee: 1% ``` Release calculates: ``` Gross: 10,000 USDC Trustless Work fee: 30 USDC Platform fee: 100 USDC Net Receiver amount: 9,870 USDC ``` The entire escrow is then marked released. *** ## Example: Multi Release Consider this milestone: ``` Milestone: Security Audit Amount: 3,000 USDC Receiver: Audit Firm Approvals: 2 / 2 Disputed: No Released: No ``` The milestone is eligible for settlement. After release: ``` Milestone: Security Audit Released: Yes ``` The other milestones remain unchanged and continue through their own lifecycle. *** ## Output of the Release Phase After a successful release: * the relevant economic obligation has been settled * the release state prevents duplicate settlement * Trustless Work fees have been distributed * Platform fees have been distributed * the Receiver has received the net payout * the settlement is recorded on-chain * the release event can be indexed by applications For a happy-path transaction, this is the final economic phase of the escrow. If settlement is contested before release, the lifecycle moves through the dispute path instead. [Continue to Dispute Resolution](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle/dispute-resolution) *** ### Related concepts [Escrow Lifecycle](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle) [Approval Phase](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle/approval-phase) [Escrow Types](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-types) [Roles and Permissions](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/roles-in-trustless-work) [Escrow Properties](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/what-does-a-smart-escrow-look-like) --- # 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-lifecycle/release-phase.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.