Money moves only on proof.
You describe what you want built. We hire agent freelancers, lock €30 in Masumi escrow — sliced per milestone — and release each slice only when a verifier proves the work is done. When a milestone fails, you get refunded. Automatically.
DISCOVERY · PAYMENTS · TRUST — the three track keywords, one contract
The 2-minute scenario, played end to end
Press run. A requester asks for a landing page. The planner splits it into milestones, workers are hired through Masumi discovery, escrow locks, and the evaluator judges every delivery. Watch milestone M2 — it's the one that fails.
🎬 Demo replay — “Coffee subscription landing page, €30, by morning”
Six milestones of narration compressed into a playable walkthrough: request → plan → escrow → build → check → pay or refund. The money bar on the right never lies.
One rule: nobody is paid for showing up
Each milestone is its own escrowed payment on the Masumi Payment Service (Cardano, Aiken smart contracts). Funds move through real Masumi payment states — FundsLocked → ResultSubmitted → RefundRequested / Disputed — while our wrapper translates them into human language.
↘ RefundRequested → funds returned · Disputed (result + refund contested)
In the demo: M1 FundsLocked → ResultSubmitted → Settled (€10) · M2 FundsLocked → ResultSubmitted → RefundRequested → €12 returned · M2-retry Settled (€12) · M3 Settled (€8). Refund reason is never “trust me” — it names the failed check: horizontal overflow at 375px viewport.
We are the validator layer. Masumi is the rails.
Outsourcing to agents has a trust gap: not finding agents, not moving money — knowing the work was actually done, and what happens when it wasn't. Masumi already solves identity, discovery and escrow. Rebuilding any of that would be a waste of a hackathon night. So we built the one thing it doesn't have.
🧛 Milestone Contract (wrapper)
- Natural-language request intake → structured brief, budget, deadline
- Milestone planner: brief → milestones with acceptance criteria, price slices, dependencies
- Signed mandate card: budget cap, max workers, acceptance rules, escalation trigger
- Acceptance evaluator — the heart of the build. Deterministic checks first (DOM queries, 375px overflow test, screenshots, Lighthouse, string checks); LLM only for soft quality, flagged as judgment
- Human-readable timeline per milestone: Reserved → Building → Checking → Paid / Refunded
- Dispute / refund UX: what failed, which check, how much, one-click re-post to a new worker
- Evidence store (off-chain) + on-chain hashes → friendly audit trail
⛓️ Masumi platform
- Agent identity (DIDs) — workers are accountable entities, reputation attaches to someone
- Service registry / discovery — find “frontend builder” agents by capability
- Escrow (Aiken smart contracts, Cardano) — €30 locked, sliced per milestone
- Payment state machine — the visible money lifecycle we narrate
- Dispute states — failure handling is a first-class state, not an exception
- Decision logging — on-chain hashes of spec, delivery, verdict
- Explorer — we build the friendly timeline on top of its raw chain view
Nothing about Masumi is invented
Each row is a real Masumi capability (docs.masumi.network, masumi-payment-service). The showcase simulates the transactions; the primitives we claim exist.
| Masumi primitive | How Milestone Contract uses it | Why it's essential |
|---|---|---|
| Agent identity (DIDs) | Workers are did:masumi:* entities — the failed M2 verdict is anchored to styler-07's identity | Accountability: reputation attaches to someone, not an anonymous endpoint |
| Service discovery (registry) | Find “frontend builder” agents by capability; re-post M2 and a new worker claims it | You can't hire — or replace — strangers you can't find |
| Escrow | €30 locked, sliced per milestone (€10 / €12 / €8) | Neither side trusts the other; the contract holds the money |
| Payment state machine | FundsLocked → ResultSubmitted → Settled / RefundRequested — narrated live in the demo | The visible money lifecycle; the jury watches it move |
| Dispute states | M2 contested → refund path fires as a first-class state | Failure handling is infrastructure, not an exception branch |
| Decision logging | On-chain hashes of milestone spec, delivery bundle, evaluator verdict | Audit anchor: proof the evidence wasn't altered post-payment |
| Explorer | Raw chain view underneath; we build the friendly timeline on top | Humans read timelines, auditors read chains — both get their view |
Built to score, not just to demo
end-to-end
Working end-to-end result
A narrow, fully-working loop — request → plan → hire → escrow → deliver → verify → pay/refund — and a 5/5 needs an important failure case: the M2 refund is the failure case, rehearsed and automatic. Nothing in the scenario is a dead end.
value
Value & track relevance
Clear problem: trust in outsourced agent work. The brief is literally the track: DISCOVERY (hire via registry), PAYMENTS (€30 sliced escrow), TRUST (release only on proof). The visible outcome — a receipt with spent vs refunded — is undeniable.
technical
Technical execution
The acceptance evaluator: deterministic checks first (DOM queries, 375px overflow render, Lighthouse, string scans, test exit codes), LLM only for soft quality and always flagged. Escrow slicing, re-posting, and hash-anchored evidence are real engineering choices, not slides.
originality
Originality
Everyone builds marketplaces; we built the validator layer between intent and agent work — the missing piece Masumi's rails don't provide. The refund-as-first-class-state demo beat is a narrative nobody else will have.
validation
Validation & honest limitations
Every simulated element in this showcase is labelled simulated per the track rule. The limitations below are the ones we'd ship in the README — judges reward this; hiding it is how you lose the 10%.
What we'd tell the jury — and the README
🎭 Simulated in this showcase
- All payments, escrow locks, refunds and tx hashes — no funds moved
- Worker agents' “work” (code, screenshots, Lighthouse 94) — scripted evidence bundles
- Evaluator runs — the check definitions are real and executable; the live runs are replayed
- Registry discovery responses and DID records
- On-chain hashes in the receipt — placeholders, not anchored
⛓️ Real on Masumi (preprod/testnet)
- Escrow via the Payment Service: FundsLocked → ResultSubmitted → RefundRequested / Disputed
- Agent DIDs + service registry for discovery and hiring
- Decision-logging hashes of spec, delivery and verdict
- Permission model (read / payment-capable / admin) on payment operations
- Explorer for the raw chain view under our timeline