> 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/initiation-phase.md). # Initiation Phase Configure a Trustless Work V2 escrow before funding by defining its settlement model, roles, milestones, approval requirements, asset, fees, and receivers. The **Initiation Phase** is where the escrow's rules are defined. No settlement has happened yet. You are configuring the agreement that will determine: * who can act * what must be completed * how approval works * how funds will eventually be released * who receives those funds * how disputes are handled The most important principle is: > **Configure first. Fund second.** Once capital has been committed to the escrow, key economic and authorization properties become restricted. *** ### 1. Choose the escrow type Start by deciding how many independent settlements the agreement needs. #### Single Release Use **Single Release** when multiple conditions lead to one final payout. ``` Milestone 1 Milestone 2 Milestone 3 ↓ One settlement ``` #### Multi Release Use **Multi Release** when milestones need to settle independently. ``` Milestone 1 → Payment 1 Milestone 2 → Payment 2 Milestone 3 → Payment 3 ``` This decision affects where amounts, Receivers, release state, and disputes live in the escrow. [Compare Escrow Types](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-types) *** ### 2. Define the agreement identity Every escrow includes metadata that helps both the blockchain and your application identify it. #### Engagement ID The **Engagement ID** connects the escrow to an external record. Examples: ``` ORDER_12345 INVOICE_2026_091 GRANT_ROUND_7 ``` Your application can use this to associate the escrow with an order, project, invoice, agreement, or other business object. #### Title A short human-readable name for the agreement. Example: ``` Website Development Agreement ``` #### Description Additional context explaining what the escrow represents. Example: ``` Payment for the design, development, and production deployment of the new website. ``` The on-chain Contract ID remains the escrow's unique blockchain identity. The Engagement ID is your application's external reference. *** ### 3. Assign roles V2 escrows use explicit roles to separate responsibilities. You configure: * **Service Providers** * **Approvers** * **Release Signers** * **Dispute Resolvers** * **Observers** * **Admin** * **Platform** * **Receiver**, where applicable Operational roles can contain multiple addresses. The Admin and Platform remain individual addresses. #### Admin vs Platform This distinction is especially important in V2. **Admin** represents configuration authority. **Platform** represents the integrating platform and receives the configured Platform Fee. They are separate capabilities. The same address may intentionally occupy both fields, but being the Platform does not automatically grant administrative authority. [Review Roles and Permissions](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/roles-in-trustless-work) *** ### 4. Define milestones Milestones describe the conditions, deliverables, or checkpoints the escrow will track. A milestone includes concepts such as: * description * status * evidence * approval requirements For example: ``` Milestone: Production deployment completed Initial status: Pending Required approvals: 2 ``` Milestones do not need to represent payments. In **Single Release**, they are conditions for one final settlement. In **Multi Release**, each milestone also represents an independent economic settlement. *** ### 5. Configure approval requirements Each milestone defines how many approvals it requires. For example: ``` Approvers: Alice Bob Carol Approval target: 2 ``` The milestone will satisfy its approval condition once two authorized Approvers have approved it. The target must be compatible with the number of configured Approvers. This makes the approval policy part of the agreement from the beginning. Examples include: * 1 of 1 * 1 of 3 * 2 of 3 * 3 of 5 Approval policy should reflect the actual trust model of the transaction rather than adding extra signers without a clear reason. *** ### 6. Define the economic terms The economic structure depends on the escrow type. #### Single Release Define: * one total Amount * one Receiver For example: ``` Amount: 10,000 USDC Receiver: G...SERVICE_PROVIDER ``` #### Multi Release Define an Amount and Receiver for each milestone. For example: | Milestone | Amount | Receiver | | --------- | ---------: | ---------------- | | Research | 1,000 USDC | Research team | | Prototype | 2,000 USDC | Development team | | Audit | 3,000 USDC | Security firm | This determines how the escrow will distribute funds later in its lifecycle. *** ### 7. Select the asset The escrow must be configured with the Stellar asset contract it will hold and distribute. Trustless Work refers to this configuration as the **Trustline**. For most integrations, the asset will typically be a stablecoin such as USDC. The configured asset determines what the escrow can: * receive * hold * release * distribute during dispute resolution Operational roles such as Approvers or Service Providers do **not** need the asset merely because they participate in the authorization workflow. The addresses that actually send or receive funds must, however, be compatible with the configured asset and the surrounding Stellar wallet flow. *** ### 8. Configure the Platform Fee An integrating platform can define an optional fee. The Platform Fee is paid to the configured **Platform** address during settlement. It is separate from the Trustless Work protocol fee. Conceptually: ``` Gross settlement - Trustless Work fee - Platform fee = Net amount distributed ``` The current Trustless Work protocol fee is **0.3%**. The Platform Fee is configurable within the limits enforced by the contract. *** ### 9. Configure dispute authority Before funding, decide who should be responsible for resolving exceptions. **Dispute Resolvers** can determine how disputed funds are distributed. They are deliberately separated from the roles allowed to initiate disputes. A good dispute configuration answers: * Who can contest the transaction? * Who should make the final resolution? * Is that resolver sufficiently independent from the disputing parties? Do not assign dispute authority simply because the role exists. It should reflect the operational process your application will actually support. *** ### 10. Add Observers when useful Observers provide a way to associate additional addresses with an escrow without granting execution authority. They may be useful for participants such as: * compliance teams * auditors * program administrators * monitoring systems * external stakeholders Observers cannot approve, release, update milestones, or resolve disputes solely because they are Observers. *** ### Configuration before funding V2 intentionally allows controlled configuration before funds are committed. The Admin can perform the configuration changes supported by the contract while the escrow is still in the appropriate unfunded state. This is important because an escrow may need to be reviewed after creation but before funding. For example: ``` Create escrow ↓ Review configuration ↓ Correct role or milestone details ↓ Fund ``` Funding creates an important security boundary. Once funds have been committed, the agreement should not be freely rewritten by one participant. *** ### Admin and Platform are fixed identities Although V2 allows controlled configuration changes, two roles deserve special attention: * **Admin** * **Platform** These identities are established during initialization and are not ordinary mutable role fields. Choose them carefully before creating the escrow. *** ### Review before funding Before moving to the Funding Phase, verify: #### Agreement * Is the Engagement ID correct? * Are the Title and Description clear? * Is the correct escrow type being used? #### Economics * Is the amount correct? * Are the Receivers correct? * Is the Platform Fee correct? * Is the correct asset configured? #### Roles * Are all Service Providers correct? * Are all Approvers correct? * Are Release Signers correct? * Is the Admin correct? * Is the Platform correct? * Are Dispute Resolvers sufficiently independent? * Are Observers needed? #### Milestones * Are all required milestones present? * Are their descriptions clear? * Are the approval targets correct? * Do the targets match the configured Approvers? A role mistake discovered **before funding** is a configuration issue. A role mistake discovered **after funding** can become a transaction problem. *** ### Output of the Initiation Phase By the end of Initiation, the escrow has a defined: * identity * settlement model * role structure * milestone structure * approval policy * economic configuration * asset * fee configuration * dispute authority At that point, the smart contract contains the rules that will govern the protected funds. The next step is to commit capital to those rules. [Continue to the Funding Phase](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle/funding-phase) *** ### Related concepts [Escrow Design](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview) [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) [Escrow Types](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-types) --- # 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.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle/initiation-phase.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.