We don’t hold your money—we hold the logic.
Trustless Work escrows are programmable trust primitives. They allow platforms, marketplaces, applications, and organizations to define how funds should be held, updated, approved, and released between different parties.
An escrow is not only a place where funds sit.
It is a coordination layer between:
dispute or exception flows
Before creating an escrow, the most important question is:
Who must do what before money can move?
If you can answer that clearly, you can design a good escrow.
Before choosing an escrow type or calling the API, map the transaction.
Start with four questions:
Who are the parties involved?
Where are the funds moving?
Who has permission to update, approve, and release?
What conditions must be met before funds are released?
This is the foundation of escrow design.
Trustless Work gives you the infrastructure to turn that logic into a smart escrow.
Every escrow involves parties.
Some parties fund the escrow.
Some perform work.
Some update status.
Some approve completion.
Some resolve disputes.
Some release funds.
Some receive funds.
Some receive platform fees.
Common roles include:
Roles are assigned to addresses.
Only the address assigned to a role can perform the actions allowed for that role.
The same real-world person, organization, or wallet can sometimes hold multiple roles, but role combinations should be intentional.
For example, a freelancer may be both the Receiver and the Service Provider, but they usually should not also be the Approver of their own work.
Next, map how funds should move.
The fund direction should answer:
Who funds the escrow, and who should receive funds after the right conditions are met?
Use case: Single-release escrow
A buyer hires or purchases from a seller, freelancer, or service provider. The buyer funds the escrow. The service provider delivers the work or product. The approver validates completion. Then funds are released once.
Use case: Multi-release escrow, same receiver
A client funds a project that has multiple milestones. The same service provider receives payments progressively as each milestone is completed and approved.
Use case: Multi-release escrow, multiple receivers
A sponsor, platform, or organization funds one escrow that needs to pay different people or entities across different milestones.
A common mistake is treating status updates, approvals, and fund releases as the same thing.
In Trustless Work, these should be understood separately:
A status update tells the other parties what is happening.
Examples:
The Service Provider or Milestone Marker usually updates the milestone status.
Status updates can happen many times before a milestone reaches its final expected state.
Approval means an authorized party has validated that the agreed condition was met.
For example:
the client approves the work
the grant reviewer approves the deliverable
the buyer confirms the shipment arrived
the platform approves submitted evidence
The Approver does not simply report progress. The Approver validates completion.
Release is when funds actually move out of the escrow.
The Release Signer can only release funds after the required approval conditions have been satisfied.
This creates a clear logic chain:
In some flows, an Approver may approve a milestone before the Service Provider updates the milestone status.
This means your escrow design should not assume that status always comes before approval.
Instead, treat status and approval as related but separate pieces of state.
The release condition should depend on the required approval logic, not only on a text status.
Every Trustless Work escrow includes a role configuration. Roles determine which address can perform which action.
Current core roles include:
Roles are assigned to addresses.
Only the address assigned to a role can perform the actions allowed for that role.
Roles are only part of the escrow design.
An escrow also includes properties that describe what the escrow is, how it should be indexed, what asset is used, and what state it is in.
Common escrow properties include:
These properties help platforms connect the on-chain escrow with real-world workflows.
Trustless Work currently supports two main escrow types:
Both use the same core idea: funds are held until defined conditions are met.
The difference is how funds are released.
A Single-Release Escrow releases funds once.
It can contain multiple milestones, but all required milestones must be approved before the final release happens.
Typical structure:
Typical flow:
Best for:
Key characteristics:
A Multi-Release Escrow releases funds progressively.
Each milestone can have its own payout, and each payout can potentially go to a different receiver.
Typical structure:
Typical flow:
Best for:
Key characteristics:
The escrow lifecycle describes how an escrow moves from configuration to completion.
Canonical lifecycle:
Map parties, fund direction, roles, milestones, release conditions, and escrow type.
Create and configure the escrow.
This includes:
The payer deposits funds into the escrow.
Possible funding states include:
The Service Provider or Milestone Marker updates the milestone status.
This creates visibility into progress.
The Approver validates whether the milestone condition was met.
Approval is the key validation step before release.
The Release Signer executes the release of funds after approval conditions are met.
In a Single-Release Escrow, this usually happens once.
In a Multi-Release Escrow, this can happen milestone by milestone.
The escrow reaches a terminal state.
Possible terminal states include:
Before creating an escrow, answer these questions:
Is there one receiver or multiple receivers?
Who updates milestone status?
A client wants to pay a freelancer after a project is completed.
Suggested design:
Simple version:
A foundation wants to release funding progressively after deliverables are completed.
Suggested design:
Simple version:
A renter deposits funds that should be held until the rental condition is complete.
Suggested design:
Simple version:
Trustless Work is not only an escrow application.
It is infrastructure for programmable transaction coordination.
Use it when your product needs to answer:
What must happen before funds move?
If the answer involves multiple parties, milestones, approvals, or release conditions, Trustless Work can help you encode that logic into a smart escrow.
Now that you understand the escrow design model:
