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
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:
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
React SDK
Package:
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:
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
JavaScript SDK
Package:
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:
Choose the JS SDK when you want a JavaScript or TypeScript client but do not need React hooks or React-specific state management.
Escrow Blocks
Escrow Blocks provide reusable UI components for common escrow interactions.
They sit above the React integration layer.
Conceptually:
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.
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:
This is often a better MVP architecture than trying to build every possible administrative flow immediately.
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:
The Viewer does not replace your application.
It gives users an independent way to inspect the underlying escrow.
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.
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 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.
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.
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.
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.
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.
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:
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
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.
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.
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:
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:
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
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
Last updated