> 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/roles-in-trustless-work.md). # Roles in Trustless Work Understand the roles, permissions, and authority boundaries in a Trustless Work V2 escrow. ## Roles in Trustless Work Trustless Work escrows are **role-based**. Roles define which addresses can perform specific actions on an escrow: report progress, approve milestones, release funds, manage configuration, open disputes, resolve disputes, or receive funds. The core design question is: > **Who should have authority over each step before money can move?** V2 expands the role model so that operational authority can be distributed across multiple addresses rather than depending on a single wallet. *** ### V2 role model The V2 roles are: | Role | Main responsibility | Multiple addresses? | | --------------------- | ------------------------------------------------------------ | ---------------------: | | **Service Providers** | Report milestone progress and evidence | Yes | | **Approvers** | Validate milestone completion | Yes | | **Release Signers** | Execute fund releases | Yes | | **Dispute Resolvers** | Resolve disputes and distribute disputed funds | Yes | | **Observers** | Read-only association with the escrow | Yes | | **Admin** | Manage permitted escrow configuration | No | | **Platform** | Represent the integrating platform and receive platform fees | No | | **Receiver** | Receive released funds | Depends on escrow type | Role lists support up to **five addresses per role**. The **Admin**, **Platform**, and Single-Release **Receiver** remain individual addresses. *** ### Service Providers **Purpose:** Report progress on the work, delivery, or condition represented by a milestone. Service Providers can: * change milestone status * attach or update evidence * raise a dispute Examples: * a freelancer marking a deliverable as ready for review * a vendor reporting that an order has shipped * a grant recipient submitting evidence for a milestone * an application updating progress after an external condition is met A V2 escrow can have **multiple Service Providers**. The Service Provider communicates progress. They do not automatically approve that progress or release funds. > **Status is communication, not approval.** *** ### Approvers **Purpose:** Validate that a milestone has satisfied its agreed conditions. Approvers can: * submit an approval for a milestone * raise a dispute V2 can assign **multiple Approvers** to an escrow. Each milestone defines its own approval target. For example: ``` Approvers: Alice Bob Carol Required approvals: 2 Alice approves → 1 / 2 Bob approves → 2 / 2 → approval requirement satisfied ``` An Approver can only contribute one approval to a milestone. This allows applications to create approval policies such as: * 1 of 1 * 1 of 3 * 2 of 3 * 3 of 5 without introducing a separate multisig mechanism. *** ### Release Signers **Purpose:** Execute settlement after the required contract conditions have been satisfied. Release Signers can: * release an approved Single-Release Escrow * release approved milestones in a Multi-Release Escrow * release multiple eligible milestones in a batch * raise a dispute V2 supports multiple Release Signers. Release authority does **not** bypass approval requirements. A Release Signer can only release funds when the contract's conditions are satisfied. #### Approver + Release Signer The same address can intentionally hold both roles. When it does, V2 supports an **approve-and-release** operation that combines both authorized actions into one transaction. This is useful for simpler workflows where the party validating completion is also responsible for executing settlement. It is still important to treat the two permissions as conceptually different: > **Approval validates the condition. Release executes the payment.** *** ### Receiver **Purpose:** Receive funds released from the escrow. The Receiver is an **economic role**, not an authorization to approve or release funds. #### Single Release A Single-Release Escrow defines one Receiver at the escrow level. When the escrow is released, the final protected amount is sent to that Receiver after applicable fees. #### Multi Release Each milestone defines its own Receiver. This allows one escrow to distribute funds to different parties across different milestones. A Receiver can also raise a dispute over funds in which they are the relevant recipient. The Receiver does not automatically become a Service Provider, Approver, or Release Signer. *** ### Platform **Purpose:** Represent the application, marketplace, protocol, or platform integrating Trustless Work. The Platform: * receives the configured platform fee * can raise a dispute * provides platform-level attribution to the escrow The Platform is a **single address**. A key V2 distinction is: > **Platform is not the escrow administrator.** V1 used the Platform address for configuration authority. V2 introduces a dedicated **Admin** role so that fee receipt and configuration control are represented as separate capabilities. The Platform and Admin fields may still intentionally use the **same address**, but they remain different roles with different meanings. *** ### Admin **Purpose:** Manage the escrow configuration through the administrative actions permitted by the contract. The Admin can manage areas such as: * escrow properties * role configuration * milestone configuration The exact changes allowed depend on the escrow state and the operation being performed. The Admin does **not** automatically gain authority to: * approve milestones * update milestone progress * release funds * resolve disputes * receive payments V2 deliberately separates **configuration authority** from **economic and operational authority**. The Admin is a single address. *** ### Dispute Resolvers **Purpose:** Decide the outcome after a dispute has been opened. Dispute Resolvers can: * resolve disputed funds * define how disputed value should be distributed among recipients V2 can assign multiple Dispute Resolvers. The most important authority boundary is: > **A Dispute Resolver cannot open a dispute.** This is deliberate. The actor responsible for deciding a dispute should not also be able to create the dispute they will resolve. For that reason, V2 enforces separation between Dispute Resolvers and roles that can initiate disputes. A resolution can distribute disputed funds according to the outcome of the arbitration rather than being limited to a simple refund-or-pay decision. *** ### Observers **Purpose:** Associate read-only participants with an escrow. Observers: * do not approve * do not release * do not update milestones * do not resolve disputes * do not receive authority over funds They provide a way to associate additional addresses with an escrow for visibility, discovery, or tracking. Examples might include: * auditors * compliance participants * program administrators * external stakeholders * monitoring services Observers can overlap with other roles because being an Observer does not add execution authority. *** ### Funders are not a role The wallet providing funds does not need to hold an escrow role. A **Funder** or **Depositor** is simply the economic participant providing assets to the escrow. Funding does not automatically make that address: * an Approver * a Service Provider * a Release Signer * an Admin * a Dispute Resolver * a Receiver If the same participant should also perform one of those actions, that permission must be assigned explicitly. This distinction is important: > **Who creates the escrow, who funds it, and who controls it do not have to be the same participant.** *** ### Roles can be combined — but not arbitrarily Some workflows benefit from one address holding more than one role. For example: #### Approver + Release Signer A buyer might validate delivery and execute payment. V2 supports this composition and can combine both actions through approve-and-release. #### Admin + Platform A platform may intentionally use the same wallet for: * configuration management as **Admin** * platform fee receipt as **Platform** The capabilities remain separate even when the address is the same. #### Receiver + Service Provider A service provider may report progress and ultimately receive payment. This is common in service agreements. *** ### Authority separation Other combinations are intentionally restricted. #### Admin separation The Admin cannot simultaneously act as an operational signer such as: * Approver * Service Provider * Release Signer * Dispute Resolver The Admin is intended to manage configuration rather than directly control transaction outcomes. #### Dispute Resolver separation A Dispute Resolver cannot also hold a role capable of opening the dispute they would resolve. This includes conflicting roles such as: * Approver * Service Provider * Release Signer * Platform * relevant Receiver These constraints prevent one participant from both initiating a dispute and deciding its outcome. *** ### Designing your role model Before creating an escrow, answer these questions: 1. **Who provides the funds?** 2. **Who receives them?** 3. **Who reports progress?** 4. **Who validates completion?** 5. **How many approvals are required?** 6. **Who executes release?** 7. **Should approval and release be separate authorities?** 8. **Who manages configuration?** 9. **Who receives the platform fee?** 10. **Who can raise a dispute?** 11. **Who independently resolves disputes?** 12. **Who needs visibility without execution authority?** If those answers are clear, the escrow's trust model is usually clear too. *** ### Core principle A good role configuration makes authority explicit. Participants should be able to understand: * **who can act** * **what they can change** * **when they can act** * **what they cannot do** * **what must happen before funds move** Next: [Understand the properties that make up an escrow](/trustless-work/v2-en/introduction/technology-overview/what-does-a-smart-escrow-look-like.md) --- # 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/roles-in-trustless-work.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.