Trustless Work V2: Programmable Escrows Become Configurable Payment Infrastructure

Trustless Work is preparing the release of V2, the first major versioned upgrade of its programmable escrow infrastructure.

This release is more than an API update. It is a major step in the evolution of Trustless Work from a simple escrow lifecycle into a configurable payment infrastructure layer for platforms, marketplaces, developers, and stablecoin-native applications.

V1 proved the core idea: platforms should be able to create escrow flows, hold funds neutrally, track milestone progress, approve work, and release payments through programmable infrastructure.

V2 expands that foundation.

With V2, Trustless Work introduces multi-address roles, quorum-based approvals, batch milestone actions, admin controls, observer access, dispute reasons, milestone-less initialization, and cleaner separation between escrow property updates and milestone management.

These changes apply across the two core escrow models:

• Single-release escrow
• Multi-release escrow

The result is a more flexible system for real-world payment flows.

Why V2 Matters

Escrow is not one workflow.

A freelance marketplace may need milestone approvals.

A grant platform may need transparent fund releases.

A public procurement program may need observers.

A DAO may need quorum-based approvals.

A trade finance platform may need multiple parties validating different parts of a transaction.

A simple bounty may need an escrow without predefined milestones.

A platform may need an admin role that can update configuration without controlling funds.

V1 gave developers a working escrow flow.

V2 gives developers escrow primitives.

That shift matters because primitives can be composed into many products. Instead of forcing every use case into the same rigid lifecycle, V2 allows platforms to design escrow flows around their own trust requirements.

What Is New in V2?

1. Multi-Address Roles

V2 converts key roles from single-address fields into lists of addresses.

The roles affected are:

• approver → approvers
• service_provider → service_providers
• release_signer → release_signers
• dispute_resolver → dispute_resolvers

This means each role can now include multiple authorized addresses. Authorization checks now verify whether the signer is contained inside the appropriate role list instead of checking equality against a single address.

This is one of the most important V2 changes.

Real escrow workflows often involve teams, committees, organizations, DAOs, or platform operations groups. A single address is not always enough to represent how decisions are made.

With multi-address roles, Trustless Work can support:

• Multiple approvers
• Multiple service providers
• Multiple release signers
• Multiple dispute resolvers
• Team-based platform operations
• More realistic organizational workflows

2. Role Limits and Safer Multi-Role Configuration

More flexibility also requires stronger boundaries.

V2 adds limits to multi-address roles:

• Maximum of 5 addresses per multi-role
• No duplicate addresses inside a role
• Dispute resolvers cannot overlap with approvers, service providers, release signers, or the receiver

These validations run during both initialize_escrow and update_escrow.

This prevents role configuration from becoming unsafe or hard to reason about.

The product principle is simple:

V2 increases flexibility, but it does not allow unlimited complexity.

3. Quorum-Based Milestone Approvals

V2 replaces the old approved: bool milestone flag with a quorum-based approval model.

Each milestone now tracks:

• target: how many approvals are required
• approval_count: how many approvals have been received
• approvers: which addresses have already approved

A milestone is approved only when approval_count >= target. The contract also prevents the same approver from voting twice on the same milestone.

This unlocks more realistic governance models.

Instead of one approver having unilateral control, platforms can configure approval flows such as:

• 2 of 3 approvers
• 3 of 5 reviewers
• DAO-based approval
• Client plus platform approval
• Multi-department sign-off
• Buyer plus inspector approval

This is essential for higher-value escrow use cases where one approval is not enough.

4. Batch Milestone Status Updates

V2 allows multiple milestone statuses to be updated in a single transaction.

The previous change_milestone_status function accepted one milestone index, one status, and one optional evidence field. V2 replaces that with a batch input: Vec<MilestoneStatusUpdate>. Each update includes a milestone index, new status, and optional new evidence.

All milestone indices are validated before any changes are applied. If any index is invalid, the entire operation reverts.

This creates atomicity.

For developers and platforms, this means batch updates are safer and easier to reason about.

5. Batch Milestone Approval

V2 changes milestone approval from one milestone at a time to batch approval.

The old approve_milestone function becomes approve_milestones, accepting a vector of milestone indices. A single approver can approve multiple milestones in one transaction.

All validations run before any write.

This means if one milestone index is invalid, the whole transaction reverts before partially changing state.

Batch approval is especially useful for:

• Grant reviews
• Service projects
• Multi-phase deliverables
• Long-running engagements
• Platform-managed review processes

6. Batch Milestone Fund Release

For multi-release escrows, V2 updates release_funds so multiple selected milestones can be released in one transaction.

The function now accepts milestone_indices: Vec<u32>, calculates the total amount for those milestones, applies fee distribution, transfers funds to the receiver, and marks each selected milestone as released. The escrow is only considered fully released once all milestones have been released.

This feature is exclusive to multi-release escrows.

Single-release escrows still release all funds in one operation once the full escrow is approved.

7. Batch Milestone Disputes for Multi-Release Escrows

V2 adds dispute_milestones to the multi-release contract.

This allows multiple milestones to be disputed in a single transaction. If any milestone index is invalid, the entire operation reverts.

This reflects how real disputes often work.

In a multi-phase project, the issue may not be isolated to one milestone. A whole group of deliverables may be affected by the same underlying problem.

Batch milestone disputes make the multi-release contract better suited for real operational workflows.

8. Dispute Reasons

V2 replaces the old Flags structure with a dedicated Dispute structure.

The new structure includes:

• is_disputed
• resolved
• reason

The dispute_escrow function now accepts a human-readable reason: String.

This is a major improvement for transparency.

A dispute should not only say that something went wrong. It should also preserve context about why the dispute was raised.

This helps:

• Users
• Platforms
• Auditors
• Support teams
• Dispute resolvers
• Indexers
• Future reporting tools

In escrow infrastructure, state matters. But context matters too.

9. Observer Role

V2 adds an observers role to the Roles structure.

Observers are informational only. They do not receive execution permissions in the contract. Their purpose is to help indexers and platforms track escrow data on a per-address basis.

Observers are useful for:

• Auditors
• Investors
• Grant program managers
• Public sector supervisors
• Compliance teams
• DAO members
• Ecosystem partners
• Platform support teams

The observer role makes a crucial distinction:

Visibility is not the same as authority.

V2 allows stakeholders to observe escrow activity without giving them the power to change escrow state.

10. Admin Role

V2 introduces a dedicated admin role.

The admin is responsible for escrow management operations such as:

• Updating escrow properties
• Adding or managing milestones
• Extending contract TTL

Previously, some management functions were authorized by the platform role. In V2, the platform role is limited to receiving platform fees and can no longer call management functions.

This is a major separation-of-powers improvement.

In a real platform, the party receiving platform fees should not automatically be the same party with permission to manage escrow configuration.

The admin role gives platforms a cleaner operational model:

• Admin manages configuration
• Platform receives fees
• Approvers approve milestones
• Release signers release funds
• Service providers update work status
• Observers track progress
• Dispute resolvers handle disputes

That is a much better foundation for real products.

11. Separate Escrow Update Logic

V2 separates escrow property updates from milestone management.

Previously, update_escrow could modify milestone data as part of the escrow update. In V2, update_escrow is restricted to escrow properties and preserves existing milestones.

A new manage_milestones endpoint replaces the previous add_milestones flow. It supports two operations:

1. Adding new milestones
2. Updating the description and/or amount of existing milestones, depending on contract type and funding state

Adding new milestones is allowed with or without funds. Updating existing milestone descriptions or amounts is only allowed when the escrow has no funds.

This makes the contract safer and easier to reason about.

Escrow property updates and milestone changes are different kinds of actions. V2 treats them separately.

12. Initialize Escrow Without Milestones

V2 allows an escrow to be initialized with an empty milestone list.

Previously, initialize_escrow rejected any escrow that did not include at least one milestone. V2 removes that restriction and allows the admin to add milestones later through manage_milestones.

This enables deferred-milestone flows.

That matters because many real workflows do not have all milestone details available at the moment the escrow is created.

Examples:

• A bounty can be opened before final deliverables are defined
• A platform can create the escrow first and add milestones later
• A client and provider can agree on the escrow before final scope is complete
• A grant program can create a funding container before tranche details are finalized

This makes escrow creation more flexible and lowers integration friction.

13. Approve and Release Milestones in One Transaction

V2 introduces approve_and_release_milestones.

This allows a signer to approve and release funds in a single transaction, but only when that signer holds both roles:

• Approver
• Release signer

If the signer lacks either role, the transaction is rejected before any state change.

This is useful for simpler or lower-risk workflows where separating approval and release creates unnecessary friction.

It also preserves safety because the combined action is only available to addresses explicitly assigned to both roles.

Single-Release vs Multi-Release in V2

V2 improves both escrow models, but not every feature applies equally to both.

Single-release escrow

A single-release escrow releases all funds at once when the escrow is fully approved.

Best suited for:

• One-time payments
• Simple service agreements
• Deposits
• Bounties
• Single deliverable projects

In V2, single-release escrows benefit from:

• Multi-address roles
• Quorum approvals
• Batch milestone status updates
• Batch milestone approvals
• Admin role
• Observer role
• Dispute reasons
• Role limits
• Separate update logic
• Initialization without milestones
• Dual-role approve and release

Multi-release escrow

A multi-release escrow can release funds across multiple milestones.

Best suited for:

• Grant programs
• Multi-phase projects
• Agency contracts
• Trade finance
• Public procurement
• Long-running service agreements

In V2, multi-release escrows get all the shared improvements plus additional milestone-level logic:

• Batch milestone fund release
• Batch milestone disputes
• Per-milestone release tracking
• Per-milestone dispute handling
• Milestone amount updates before funding

This makes multi-release escrows significantly more powerful for complex payment workflows.

What This Means for Developers

For developers, V2 creates a clearer and more composable escrow model.

The most important changes to prepare for are:

• Role fields are now vectors for several operational roles
• Approval logic now uses quorum instead of a boolean flag
• Milestone status updates are batch-based
• Milestone approvals are batch-based
• Multi-release fund releases are milestone-index based
• Disputes include structured reasons
• Observers are available for read/indexing use cases
• Admin is now responsible for management operations
• Platform is fee-only
• Escrow property updates and milestone management are separate
• Escrows can be created without milestones
• Some actions can be combined when the signer has dual-role permissions

The migration guide should map each of these changes into:

• REST API payload changes
• SDK type changes
• React Blocks updates
• Example flows
• Breaking-change warnings
• Single-release vs multi-release differences

What This Means for Platforms

For platforms, V2 makes Trustless Work easier to adapt to real business logic.

A platform can now design escrow flows around questions like:

• Who can update the escrow?
• Who can approve milestones?
• How many approvals are required?
• Who can release funds?
• Who can observe but not act?
• Can milestones be added later?
• Can several milestones be approved at once?
• Can several milestones be released at once?
• Should one address be allowed to approve and release?
• Should disputes include a written reason?
• Should the platform only receive fees, not manage the escrow?

These are the kinds of questions real platforms need to answer before putting escrow into production.

V2 gives them more tools to answer those questions safely.

FAQ

Is V2 just an API versioning update?

No.

V2 includes API versioning, but the larger change is contract-level flexibility.

The migration plan introduces formal versioning across the REST API, SDKs, documentation, BackOffice, and Laboratory. But the contract updates go further by changing roles, approvals, milestone actions, dispute structure, admin permissions, and escrow initialization logic.

Why add multi-address roles?

Because real platforms are operated by teams, not single addresses.

Multi-address roles allow Trustless Work to represent organizations, committees, DAOs, and multi-stakeholder approval flows.

Why limit multi-address roles to 5 addresses?

Because flexibility needs guardrails.

The role limit keeps authorization logic practical and prevents role lists from becoming too large, duplicated, or hard to reason about.

Why add quorum?

Quorum allows a milestone to require multiple approvals before it is considered approved.

This is useful for higher-trust workflows where one person should not have unilateral control over approval.

Why add batch actions?

Batch actions reduce signing friction and make multi-milestone escrows more usable.

V2 supports batch status updates, batch approvals, multi-release batch fund release, and multi-release batch disputes.

Why add an admin role?

The admin role separates escrow management from platform fee collection.

In V2, the platform role becomes fee-only, while admin handles management operations such as updating properties, managing milestones, and extending TTL.

Why add observers?

Observers allow addresses to be associated with an escrow for visibility and indexing without giving those addresses execution permissions.

Why allow escrows without milestones?

Because some workflows need to create the escrow first and define milestones later.

This enables deferred-milestone flows where the admin initializes the escrow and adds milestones later through manage_milestones.

Why separate escrow updates from milestone management?

Because escrow properties and milestones are different concerns.

V2 restricts update_escrow to property updates and introduces manage_milestones for milestone operations. This makes the contract safer and easier to reason about.

Why add dispute reasons?

Dispute reasons preserve human-readable context about why an escrow or milestone was disputed.

This improves transparency, support, auditing, and downstream reporting.

Does V2 affect both single-release and multi-release escrows?

Yes.

The V2 update applies to both contracts. The full V2 overview confirms updates across both single-release and multi-release escrows, with demos and evidence prepared for each.

Some features are shared across both. Others are specific to multi-release escrows, such as batch milestone fund release and batch milestone disputes.

Will V1 stop working immediately?

No.

Because V2 introduces breaking changes, the migration plan says V1 should remain functional for a limited time while users migrate.

Closing

V1 proved that programmable escrow could be simple.

V2 makes it flexible enough for real-world platforms.

With multi-address roles, quorum approvals, batch milestone actions, observer access, admin controls, dispute reasons, milestone-less initialization, and cleaner separation between escrow updates and milestone management, Trustless Work becomes more than an escrow flow.

It becomes configurable payment infrastructure.

The goal is not only to help platforms create escrows.

The goal is to help platforms design better payment flows for the stablecoin economy.