> 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/smart-escrow-design.md). # Escrow products Mix & Match Guide Choose the Trustless Work V2 integration surface that fits your product, from Backoffice-assisted pilots to SDK, REST, Blocks, and custom application workflows. There is no single required way to integrate Trustless Work. You can start with operational tools, embed escrow directly into your product, use prebuilt UI components, or integrate the Core API from your own backend. The right path depends on: * how much product control you need * how much engineering you want to invest * whether the workflow is still being validated * where wallet signing happens * how much operational tooling you want to build yourself A useful starting question is: > **What do we need to own ourselves, and what can Trustless Work provide for us?** *** ## Quick decision guide | If you need... | Start with... | | ---------------------------------------------------------------------- | ------------------------ | | Validate a workflow before building | **Backoffice** | | Add escrow to a React application | **React SDK** | | Integrate from Node.js, another frontend framework, scripts, or agents | **JS SDK** | | Direct HTTP control or a non-JavaScript stack | **REST API** | | Reusable escrow UI components | **Escrow Blocks** | | Independent escrow inspection | **Escrow Viewer** | | Product UX plus operational tooling | **SDK/API + Backoffice** | These are not separate escrow systems. They are different interfaces to the same underlying Trustless Work infrastructure. *** ## Core integration surfaces ### Core API v2 The **Core API** is the underlying developer interface for Trustless Work V2. Use it when you want direct control over: * escrow creation * funding * milestone updates * approvals * disputes * releases * transaction submission * escrow queries The API builds transactions, but it does not replace wallet authorization. The typical write flow remains: ``` Your Application ↓ Core API ↓ Unsigned transaction ↓ Authorized wallet signs ↓ Stellar / Soroban ``` Use the REST API directly when: * you are not using JavaScript or React * you want your own SDK abstraction * you are integrating from a backend service * you want direct control over HTTP orchestration [Explore the V2 REST API](https://docs.trustlesswork.com/trustless-work/v2-en/api-rest) *** ## React SDK Package: ``` @trustless-work/escrow ``` The React SDK is the natural integration path for React and TypeScript applications. Use it when you want Trustless Work functionality inside your own product experience. Your application owns: * pages * forms * workflow * design system * user experience The SDK provides the Trustless Work integration layer. A typical architecture looks like: ``` Your React Application ↓ Trustless Work React SDK ↓ Core API v2 ↓ Wallet signing ↓ Escrow contract ``` Choose this path when: * escrow is a core part of your product * you want full control of the UX * your frontend is React-based * you do not want to build the API client layer from scratch [Explore the Escrow React SDK](https://docs.trustlesswork.com/trustless-work/v2-en/escrow-react-sdk) *** ## JavaScript SDK Package: ``` @trustless-work/escrow-js ``` The JS SDK exposes the same Core API v2 concepts without depending on React. Use it for: * Node.js applications * backend services * scripts * Vue, Svelte, or other frontend frameworks * automation * AI agents * server-side workflows For example: ``` Backend Service ↓ Escrow JS SDK ↓ Core API v2 ↓ Signing boundary ↓ Soroban ``` Choose the JS SDK when you want a JavaScript or TypeScript client but do not need React hooks or React-specific state management. [Explore the Escrow JS SDK](https://docs.trustlesswork.com/trustless-work/v2-en/escrow-js-sdk) *** ## Escrow Blocks **Escrow Blocks** provide reusable UI components for common escrow interactions. They sit above the React integration layer. Conceptually: ``` Escrow Blocks ↓ React SDK ↓ Core API ↓ Escrow contracts ``` Use Blocks when you want to accelerate frontend development while still embedding escrow directly inside your product. They are useful when: * you want common escrow UI quickly * the existing interaction patterns fit your workflow * you prefer adapting components over building every screen from zero Use the React SDK directly when you need complete control over the interface. [Explore the Escrow Blocks SDK](https://docs.trustlesswork.com/trustless-work/v2-en/escrow-blocks-sdk) *** ## Backoffice The **Backoffice** is an operational interface for working with Trustless Work without first building every escrow interaction into your own product. It is useful for: * pilots * internal operations * testing escrow configurations * exceptional workflows * support teams * early-stage integrations It can also complement a programmatic integration. For example: ``` Customer workflow ↓ Your application + SDK Operational exceptions ↓ Backoffice ``` This is often a better MVP architecture than trying to build every possible administrative flow immediately. [Explore Backoffice](https://docs.trustlesswork.com/trustless-work/v2-en/oss-dapps/backoffice) *** ## Escrow Viewer The **Escrow Viewer** is a read-only inspection surface. It is useful when someone needs to understand an escrow without receiving authority to modify it. Examples include: * customers verifying escrow state * support teams investigating a transaction * external stakeholders reviewing milestones * partners verifying funds * auditors or compliance participants * developers comparing indexed state against contract state Conceptually: ``` Your Application ↓ Link to escrow ↓ Escrow Viewer ↓ Read-only contract inspection ``` The Viewer does not replace your application. It gives users an independent way to inspect the underlying escrow. [Explore the Escrow Viewer](https://docs.trustlesswork.com/trustless-work/v2-en/oss-dapps/escrow-viewer) *** ## Integration patterns The individual tools become more useful when combined intentionally. *** ### Path 1 — Backoffice-first pilot Use this when the business workflow is still being validated. ``` Business workflow + Backoffice + Trustless Work escrow ``` You can use Backoffice to: * configure escrows * test roles * fund * update milestones * approve * release * test disputes without first implementing all of those interactions in your own product. #### Best for * pilots * proof of concepts * early customer implementations * testing new use cases * teams learning Trustless Work #### Why start here? Because the first uncertainty is often not: > Can we code the integration? It is: > **Does this escrow model actually fit the workflow?** Validate that first. *** ## Path 2 — React SDK integration Use this when escrow is becoming part of the actual customer experience. ``` Your React App ↓ React SDK ↓ Core API ↓ Escrow ``` Your application can expose: * escrow creation * deposits * milestone progress * approvals * release * dispute actions inside your existing product. #### Best for * marketplaces * fintech products * grant platforms * project-management products * transaction platforms * customer-facing applications #### You own * UX * routing * application permissions * wallet experience * surrounding business workflow #### Trustless Work provides * escrow transaction integration * contract semantics * settlement infrastructure * indexed escrow state *** ## Path 3 — Escrow Blocks Use this when you want an embedded customer experience but do not want to design every escrow interaction from scratch. ``` Your Application ↓ Escrow Blocks ↓ React SDK ↓ Core API ``` #### Best for * fast frontend integration * MVPs * internal tools * products whose workflow matches existing Blocks Start with Blocks where they fit. Drop down to the React SDK when you need more control. You do not need to choose one forever. *** ## Path 4 — JS SDK integration Use this when your integration is JavaScript or TypeScript but not primarily React. ``` Backend / Script / Agent ↓ JS SDK ↓ Core API ↓ Escrow ``` #### Best for * Node.js backends * automation services * non-React applications * scheduled workflows * agent systems * scripts and tooling This is also a strong path when the user-facing interface and escrow orchestration happen in different parts of your architecture. *** ## Path 5 — Direct REST integration Use REST when you want the lowest-level Core API integration surface. ``` Your System ↓ HTTP ↓ Core API v2 ↓ Stellar transaction ``` #### Best for * non-JavaScript stacks * backend-first systems * custom SDKs * infrastructure teams * services that already have their own transaction abstractions REST gives you the most direct relationship with the Core API. It also means your team owns more of the surrounding client implementation. *** ## Path 6 — Product + Backoffice A common production architecture does not need to choose between programmatic integration and operational tooling. Use both. ``` Normal user flow ↓ Your Application ↓ SDK / API Exceptions and operations ↓ Backoffice ``` For example, customers might: * fund * update progress * approve * release inside your application. Your operations team might use Backoffice for: * troubleshooting * exceptional cases * pilot customers * manual interventions supported by their assigned roles This can reduce the number of internal admin screens you need to build. *** ## Path 7 — Product + Viewer Your application can expose an independent transparency layer through the Viewer. ``` Your transaction page "View escrow on Trustless Work" ↓ Escrow Viewer ``` #### Best for * marketplaces * grant programs * B2B transactions * public funding * partner-facing workflows * transactions where independent verification adds value The Viewer can complement your interface without becoming your primary user experience. *** ## You can change paths over time Your first integration architecture does not need to be your final architecture. For example: ``` Pilot ↓ Backoffice Product validation ↓ Blocks Custom UX ↓ React SDK Automation ↓ JS SDK / REST ``` All of these paths can interact with the same underlying escrow model. That means you can increase integration depth as the product matures instead of committing to maximum complexity from day one. *** ## Start with the smallest integration that resolves the uncertainty Do not automatically choose the most technically sophisticated path. If the uncertainty is: > Does this use case need escrow? start with Backoffice. If the uncertainty is: > Will users understand this workflow? Blocks may help you test it quickly. If the requirement is: > Escrow must feel native to our product. use the React SDK. If the requirement is: > Our backend or agent needs to orchestrate escrows. use the JS SDK or REST API. A good integration architecture should solve the current product problem without creating unnecessary infrastructure. *** ## Integration path comparison | Path | Engineering effort | UX control | Operational speed | Typical use | | ----------------- | -----------------: | ---------: | ----------------: | --------------------------- | | **Backoffice** | Low | Low | High | Pilots and operations | | **Escrow Blocks** | Low–Medium | Medium | High | Fast embedded UX | | **React SDK** | Medium | High | Medium | React products | | **JS SDK** | Medium | High | Medium | Backend, scripts, agents | | **REST API** | Medium–High | Maximum | Medium | Custom infrastructure | | **Viewer** | Low | Read-only | High | Transparency and inspection | These are not mutually exclusive. Most mature integrations will use more than one. *** ## Example: marketplace evolution A marketplace might evolve like this. #### Stage 1 — Validate Use Backoffice to create and operate escrows manually. ``` Marketplace + Backoffice ``` Learn: * which roles users need * which milestones matter * who actually approves * who handles disputes * where UX friction exists *** #### Stage 2 — Embed Move the common user journey into the application. ``` Marketplace UI ↓ React SDK ↓ Trustless Work ``` Keep Backoffice for operations. *** #### Stage 3 — Accelerate Add Escrow Blocks where reusable components fit. Use the SDK directly where the marketplace needs differentiated UX. *** #### Stage 4 — Automate Add backend or agent workflows through: * JS SDK * REST * other authorized integration surfaces For example: ``` Delivery system confirms shipment ↓ Backend updates milestone status ↓ Customer approves ↓ Authorized settlement workflow executes ``` The escrow model does not need to change just because the integration becomes more sophisticated. *** ## Example: agent-driven system An agent-oriented integration might use: ``` Agent ↓ JS SDK / REST ↓ Core API ↓ Authorized signing boundary ↓ Escrow ``` The agent might: * inspect escrow state * evaluate external evidence * prepare transactions * update milestones * initiate actions within its assigned permissions It still cannot bypass contract authorization. The same role model applies whether the action originates from: * a human interface * a backend * automation * an AI agent > **Choose the interface based on how you want to integrate. Choose the roles based on who should control the money.** *** ## Recommended progression If you are starting a new Trustless Work integration, a practical progression is: #### 1. Understand the escrow model Define: * escrow type * roles * milestones * approval thresholds * settlement flow * dispute process [Review Escrow Design](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/technology-overview) #### 2. Validate the workflow Use operational tools or a small prototype before building the complete product. #### 3. Choose your integration surface Select: * Backoffice * Blocks * React SDK * JS SDK * REST based on the problem you are solving now. #### 4. Design the signing boundary Decide which wallets or services actually hold: * approval authority * release authority * administrative authority * dispute authority #### 5. Build the application workflow Keep business logic in your application and economic authorization in the escrow. #### 6. Add operational tools where needed Use Backoffice and Viewer instead of rebuilding operational surfaces that do not differentiate your product. *** ## V2 beta boundary Trustless Work Version 2 is currently: * **Beta** * **Stellar Testnet only** * **Not yet externally audited** Use V2 to build, test, and validate integrations. Version 1 remains the current production/mainnet path. Do not treat the V2 beta environment as a production settlement environment yet. *** ## Continue building [Open the Developer Guide](https://docs.trustlesswork.com/trustless-work/v2-en/introduction/developer-resources) [Explore the V2 REST API](https://docs.trustlesswork.com/trustless-work/v2-en/api-rest) [Explore the Escrow React SDK](https://docs.trustlesswork.com/trustless-work/v2-en/escrow-react-sdk) [Explore the Escrow JS SDK](https://docs.trustlesswork.com/trustless-work/v2-en/escrow-js-sdk) [Explore the Escrow Blocks SDK](https://docs.trustlesswork.com/trustless-work/v2-en/escrow-blocks-sdk) [Explore Backoffice](https://docs.trustlesswork.com/trustless-work/v2-en/oss-dapps/backoffice) [Explore the Escrow Viewer](https://docs.trustlesswork.com/trustless-work/v2-en/oss-dapps/escrow-viewer) --- # 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/smart-escrow-design.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.