> 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/funding-phase.md). # Funding Phase Fund a Trustless Work V2 escrow using the configured Stellar asset while preserving non-custodial signing and on-chain funding records. *** The **Funding Phase** is where capital is committed to the escrow. During Initiation, the parties define the agreement: * roles * milestones * approval requirements * amounts * Receivers * asset * fees Funding places the configured asset into the escrow contract so those rules can govern how the funds are eventually released. > **Funding commits capital to the agreement. It does not authorize settlement.** *** ### Who can fund an escrow? The Funder does not need to hold an operational escrow role. A wallet can provide funds without being: * a Service Provider * an Approver * a Release Signer * an Admin * a Dispute Resolver * a Receiver This allows the economic source of funds to remain separate from the participants responsible for operating the escrow. For example: ``` Company treasury ↓ Funds ↓ Escrow Approvers: Operations team Release Signers: Finance team Receiver: Vendor ``` The treasury provides the capital, while other addresses control approval and settlement. *** ## The V2 funding flow Trustless Work remains non-custodial during funding. The standard V2 application flow is: 1. Your application requests a funding transaction through the Trustless Work Core API or SDK. 2. Trustless Work builds the unsigned Stellar transaction. 3. The Funder signs that transaction with their wallet. 4. The signed transaction is submitted to Stellar. 5. The configured asset is transferred into the escrow contract. 6. The contract emits the funding event. 7. The V2 indexer updates the escrow read model. The important authorization boundary is: > **Trustless Work builds the transaction. The user's wallet signs it.** The API does not take custody of the Funder's private keys or sign the transaction on their behalf. *** ### The configured asset An escrow can only be funded with the asset configured during Initiation. That asset is defined by the escrow's **Trustline** configuration. For example, if the escrow is configured for USDC, the funding transaction must use that configured USDC asset. The asset configuration determines what the contract can: * receive through its funding operation * hold * release * distribute during dispute resolution [Review Escrow Properties](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/what-does-a-smart-escrow-look-like) *** ## Funding amount vs escrow obligations Funding and settlement obligations should be considered separately. ### Single Release A Single-Release Escrow defines one escrow-level amount. For example: ``` Escrow amount: 10,000 USDC ``` The contract must have sufficient balance to execute the final settlement. The escrow can receive funding across multiple funding transactions. For example: ``` First funding: 4,000 USDC Second funding: 6,000 USDC Total funded: 10,000 USDC ``` The intended settlement remains 10,000 USDC. *** ### Multi Release A Multi-Release Escrow defines amounts at the milestone level. For example: | Milestone | Amount | | --------- | ---------: | | Research | 1,000 USDC | | Prototype | 2,000 USDC | | Launch | 3,000 USDC | The total intended settlement obligations are: ``` 1,000 + 2,000 + 3,000 = 6,000 USDC ``` Because milestones can settle independently, the contract needs sufficient balance for the milestone or group of milestones being released. Funding does not need to imply that every milestone is immediately ready for settlement. Approval and release remain separate lifecycle stages. *** ## Funding can happen more than once V2 funding is not limited to a single transaction. An escrow can receive multiple funding operations over its lifecycle. This supports patterns such as: * partial initial funding * staged capital contributions * multiple Funders * topping up an escrow before future settlement Applications should compare the escrow's current balance with the economic obligations they expect the escrow to cover. The blockchain balance represents **capital currently held**. The configured amounts represent **settlement obligations**. Those are related, but they are not the same concept. *** ## Use the funding operation For application integrations, use the Trustless Work **fund escrow operation** exposed through the V2 API or SDK. This matters because the funding operation does more than move tokens. It executes the contract's funding logic and emits the event used to represent the funding action. Conceptually: ``` Funder ↓ fund_escrow ↓ Asset transferred ↓ Funding event emitted ↓ Indexer updates read model ``` *** ### Do not treat direct token transfers as equivalent A Soroban contract address can hold assets, but simply transferring tokens to a contract address is **not the same thing as calling the escrow funding operation**. A direct asset transfer can bypass Trustless Work's normal funding logic, including the escrow funding event and internal funding accounting. For that reason: > **Use the V2 funding operation for normal integrations.** If you are building a specialized funding mechanism, verify its contract and indexing implications explicitly rather than assuming that sending tokens to the Contract ID is equivalent to funding through Trustless Work. *** ## Signing remains with the Funder Funding follows the same non-custodial transaction model as other Trustless Work actions. A typical integration looks like: ``` Application ↓ Trustless Work Core API ↓ Unsigned transaction ↓ Funder's wallet ↓ Signature ↓ Submit transaction ↓ Stellar ``` The Funder remains in control of the wallet that authorizes the transfer. This allows platforms to integrate escrow funding without taking custody of user assets. *** ## Funding creates an important configuration boundary Before funding, the Admin can perform the configuration changes permitted by the contract. Once funds have been committed, key economic and authorization configuration becomes restricted. That protects participants from having important agreement terms changed after capital enters the escrow. The intended lifecycle is therefore: ``` Configure ↓ Review ↓ Correct if necessary ↓ Fund ↓ Operate the escrow ``` Not: ``` Fund ↓ Rewrite the agreement ``` This is why the Initiation review is important. [Review the Initiation Phase](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle/initiation-phase) *** ## Funding does not mean approval An escrow holding enough funds for settlement does not mean those funds can be released. For example: ``` Escrow balance: 10,000 USDC Milestone approvals: 1 / 2 Result: Funds remain protected. ``` The contract still enforces the approval requirements configured for the escrow. The lifecycle remains: ``` Fund ↓ Perform work ↓ Update milestones ↓ Approve ↓ Release ``` *** ## Funding does not assign authority Funding also does not change the role model. A Funder does not gain approval or release authority merely because they provided the assets. If the Funder should also be an Approver or Release Signer, that role must have been explicitly assigned. This distinction allows Trustless Work to support workflows where: * one entity provides capital * another verifies performance * another executes settlement * another receives payment [Review Roles and Permissions](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/roles-in-trustless-work) *** ## Indexing and visibility A successful V2 funding operation emits an on-chain funding event. Core API v2 indexes chain activity automatically so applications can retrieve updated escrow state without using the manual V1 `update-from-txHash` indexing flow. There can still be a short delay between: ``` Transaction confirmed on Stellar ↓ Indexer processes event ↓ Updated API read model ``` A submitted transaction can therefore succeed on-chain before the updated balance appears in an indexed API response. Applications should treat this as **eventual consistency**, not automatically as a failed funding transaction. *** ### Verify funding You can inspect an escrow after funding through: [Escrow Viewer](https://viewer.trustlesswork.com/) For lower-level blockchain verification, Stellar explorers can also be used to inspect the transaction and contract activity. The blockchain remains the authoritative execution layer, while the Core API provides an indexed application-friendly view. *** ## Output of the Funding Phase After a successful funding operation: * the escrow contract holds the deposited asset * the funding transaction is recorded on Stellar * a funding event has been emitted * the indexed read model can reflect the new funding state * the escrow's configured authorization rules remain in force The escrow now has capital behind its agreement. The next step is for the Service Provider to communicate progress through milestone updates. [Continue to Change Milestone Status](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle/milestone-status-update) *** ### Related concepts [Escrow Lifecycle](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle) [Initiation Phase](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/escrow-lifecycle/initiation-phase) [Escrow Properties](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/what-does-a-smart-escrow-look-like) [Roles and Permissions](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview/roles-in-trustless-work) --- # 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/funding-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.