🧩 Understanding Roles in Trustless Work

The Logic Layer That Powers Escrow Flows

In Trustless Work, roles are everything.
They define who can act, what can change, and when funds can move.

Every escrow you deploy is just a JSON logic file — a programmable schema that maps real-world responsibilities to on-chain permissions.
Once deployed, those roles become the only addresses capable of moving the escrow through its lifecycle: marking milestones, approving work, releasing funds, or resolving disputes.

🧠 Why Roles Matter

Each role enforces least-privilege access, meaning no one can control the full flow of funds alone.
This ensures:

✅ Transparency — every action emits an on-chain event
✅ Security — no single party can move funds unilaterally
✅ Programmability — you define who can act at each step
✅ Flexibility — assign roles to humans, platforms, or AI agents

“We don’t hold your money — we hold the logic.”

1. Issuer — The Initiator

Every escrow starts with a deployer.
The Issuer is the address that signs the deployment transaction.
It’s factual, not functional — being the issuer doesn’t grant any control over funds.

Still, Trustless Work indexes who issued what, so you can query “escrows I initiated” directly via API or Viewer.

Think of the Issuer as the contract author, not the contract owner.

2. Funder — The Capital Source 💸

Anyone who deposits into an escrow becomes a Funder.
This role isn’t part of the contract logic, but it’s indexed by our system — every deposit is recorded as an event tied to the depositor’s address.

💡 Why it matters

• Transparent audit trail for grants, crowdfunding, and multi-funder projects
• Lets platforms trace who financed what and when
• Enables composable, multi-deposit escrows

Funders have no signing authority — they can’t change milestones or trigger releases — but their activity provides full financial transparency.

3. Service Provider — The Progress Marker

The Service Provider updates milestone statuses to signal progress.
They can also raise disputes, but they can’t move funds.

🧱 Common mappings

• Freelancer or vendor marking work as completed
• Project team submitting a deliverable
• NGO updating progress on a funded milestone

Service Providers supply proof over promise — data, not custody.

4. Approver — The Gatekeeper

The Approver validates each milestone and decides whether conditions for release are met.
Their signature is required for any milestone to move toward payout.
They can also raise disputes.

💡 Example

• A client confirming delivery
• A grants committee approving work
• A QA or compliance team validating results

Without the Approver’s signature, funds stay locked.

5. Release Signer — The Trigger

The Release Signer executes the payout once approvals are in place.
Depending on how you configure your escrow, this can work in two modes:

• Payout Model → Release Signer sends funds to the Receiver
• Claim Model → Receiver signs the release to claim funds themselves

That choice defines your user experience — whether you want manual disbursement or self-claim flow.

6. Receiver — The Beneficiary

The Receiver is the address that ultimately receives funds.
In single-release escrows, there’s one receiver.
In multi-release escrows, each milestone can have its own receiver, enabling partial or parallel payouts.

💡 Example

• A freelancer wallet receiving funds
• A project team splitting payouts across contributors

7. Platform Address — The Manager

The Platform Address acts like the escrow’s operations manager.
It can:

• Update milestones or metadata before the escrow is funded
• Collect the platform fee automatically on every release
• Optionally act as a Dispute Resolver or Release Signer

🧱 Example: In a marketplace, this might be the platform’s treasury address taking a 0.5% fee per transaction.

8. Dispute Resolver — The Arbiter ⚖️

Optional but crucial.
The Dispute Resolver steps in when things go wrong — they can re-route funds, cancel milestones, or return deposits.
Their decisions are final and logged on-chain.

💡 Ideal for neutral third parties, DAOs, or arbitration platforms.

9. Observer — The Watcher 👀

Observers are read-only participants.
They play no part in the lifecycle, but their address is indexed for analytics or transparency dashboards.

💡 Great for auditors, regulators, or DAO voters who need full visibility without touching logic.

🧩 Full Role Map

| Role | Action | Can Move Funds? | Indexed by System? | |------|---------|------------------|--------------------| | Issuer | Deploys escrow | ❌ | ✅ | | Funder | Deposits funds | ❌ | ✅ | | Service Provider | Marks milestones | ❌ | ✅ | | Approver | Approves milestones | ✅ (approval) | ✅ | | Release Signer | Executes payout | ✅ (release) | ✅ | | Receiver | Receives funds | ✅ (receipt) | ✅ | | Platform Address | Updates config & collects fee | ✅ (fee) | ✅ | | Dispute Resolver | Resolves conflicts | ✅ (override) | ✅ | | Observer | Views only | ❌ | ✅ |

🧠 Why This Design Works

Trustless Work’s role system encodes programmable trust.
By separating powers and indexing every action, we achieve:

• Transparency: every event is visible and verifiable
• Security: no unilateral control over funds
• Composability: roles can belong to users, teams, or bots
• Auditability: full traceability of deposits and decisions

🧪 Try It Yourself

• 🧱 Deploy your first escrow on the Demo dApp
• 📘 Read the full Escrow Lifecycle Guide
• 🧩 Explore Role Configs via API
• 🛠 Clone example repos on GitHub

Trustless Work makes logic the new custody.
Every role, every signature, every release — verifiable by design.