A marketplace where AI agents don't just claim capabilities — they stake real funds on them, and lose them automatically if they underperform.
"Anyone can claim their AI agent is 94% accurate. Why should you believe them? In our marketplace, agents back capability claims with staked collateral. If a completed job's verification report shows underperformance, the smart contract slashes the agent's stake and compensates the buyer — automatically, no dispute process, no trust required. This isn't just a service registry with payments bolted on — it's an underwriting market for AI capability claims, something that's only possible because the slashing is trustless and enforced on-chain. You can even let a third party stake on behalf of an agent in exchange for a cut of fees — becoming an insurer for AI agents."
Problem Statement #6 asks for a registry + discovery + x402-gated transactions. That's necessary plumbing, but it's not the point of this project.
The actual product is a staking/underwriting layer for AI capability claims — an economic primitive that doesn't exist elsewhere and is only possible because a smart contract can trustlessly slash real funds the instant a verification check fails. A centralized database can store a reputation number; it cannot autonomously enforce financial consequences for a broken claim. That's the answer, unprompted, to "why blockchain" — the question that sinks most teams in this space.
Registry, discovery, and x402 payments still exist underneath, satisfying the mandatory integration requirement — but they are infrastructure in service of the staking mechanic, not the pitch itself.
Client Agent
│
▼
Natural Language Query ("I need an AI that converts handwritten notes to LaTeX")
│
▼
Discovery Engine (embeds query → matches against agent capability vectors)
│
▼
Registry (Algorand) — agent identities, capability claims, stake amounts, prices
│
▼
Ranked Results (cost / latency / rating / stake level — Uber-style cards)
│
▼
x402 Payment (HTTP 402 flow, pay-per-call)
│
▼
Escrow + Stake Contract (PyTeal/Beaker) — holds payment AND references provider's locked stake
│
▼
Provider Agent executes task
│
▼
Verification Engine — objective checklist report vs. spec
│
▼
┌─────────────┴─────────────┐
▼ ▼
Report PASSES Report FAILS
│ │
Escrow → Seller Escrow refunded to buyer
Reputation ↑ Stake SLASHED → buyer compensated
Reputation ↓
│ │
└─────────────┬─────────────┘
▼
Reputation State Updated
(derived from stake history + job outcomes)
Optional: Underwriter Agent stakes on behalf of Provider Agent,
takes a cut of Provider's fees, absorbs slashing risk instead of Provider.
Build in this order. Stop and demo-test after every tier — each tier is a coherent, presentable product on its own.
Goal: an agent registers with a capability claim and a stake, a buyer hires it, pays via x402, a job either passes (stake safe, funds released, reputation up) or fails (stake slashed, buyer compensated, reputation down) — fully on-chain, fully automatic.
| # | Component | What it does | Est. effort |
|---|---|---|---|
| 1 | Agent Identity + Registry (Algorand) | Each agent = an Algorand account. Registry stores agent metadata (name, capability claim, price, wallet address, current stake amount) via app box storage. | Medium |
| 2 | Staking Contract | Agent locks funds into the contract when registering a capability claim. Stake amount is publicly visible and tied to that specific claim. | Medium-High |
| 3 | x402 Payment Gateway | Wraps the service-call endpoint, returns HTTP 402 until payment confirmed, then processes the request. | Medium |
| 4 | Escrow + Slashing Contract (PyTeal/Beaker) | Holds buyer's payment. On verification pass: releases payment to seller. On verification fail: refunds buyer's payment AND slashes a defined portion of seller's stake to compensate the buyer. | High |
| 5 | Verification Report Engine | Deterministic checklist against the job spec — word count, keyword presence, format checks, embedding similarity score. Outputs pass/fail + confidence. This report is what triggers the contract branch (release vs. slash). Buyer can still override in edge cases. | Medium |
| 6 | Reputation State | Mutable record per agent: jobs completed, success rate, current stake, total ever slashed, avg latency. Updated on-chain after every job. | Low-Medium |
| 7 | Minimal UI | Query box → matched agent (shows stake level + price + rating) → pay → status → verification result → stake/reputation update animates live. | Medium |
P0 demo script:
- Show two agents claiming the same capability — one staked high, one staked low/zero.
- Hire the high-stake one for a task, show it pass, watch stake stay locked, reputation tick up.
- Hire an agent on a task rigged to fail verification, watch the slash happen live — funds move from stake to buyer automatically, no human intervention, no dispute.
- That's your whole story in under 90 seconds.
| # | Component | What it does | Est. effort |
|---|---|---|---|
| 8 | Capability Benchmarking on Registration | Agent runs a small fixed benchmark suite at registration; score influences suggested/required stake level (higher claimed accuracy → higher stake required to back it credibly). | Medium-High |
| 9 | Semantic Discovery | Natural language query → embedding → cosine similarity against registered capability descriptions → ranked matches. | Medium |
| 10 | Underwriter Agents | A third-party agent can stake on behalf of a provider agent in exchange for a cut of that provider's fees — effectively insuring the provider's claims. If the provider's job fails verification, the underwriter's stake is slashed instead of the provider's own. Registry shows "backed by Underwriter X" as a trust signal. | High |
| 11 | Uber-style Comparison Cards | UI cards per agent: ⭐ rating, $ cost, ⏱ latency, ✓ success rate, 🔒 stake amount, side-by-side comparison. | Low |
| # | Component | What it does |
|---|---|---|
| 12 | Fallback category filter (in case semantic search misfires live) | |
| 13 | Live "agent onboarding" demo moment — register a new agent + set its stake on stage | |
| 14 | Underwriter marketplace UI — browse agents by "who's insuring them" | |
| 15 | Dynamic stake requirements (higher-value tasks require proportionally higher stake to accept) | |
| 16 | Multi-agent chained tasks — impressive but risky, only if time allows |
| Layer | Choice | Why |
|---|---|---|
| Blockchain | Algorand (mandatory per hackathon) | Sponsor requirement |
| Smart contracts | Beaker (Python framework over PyTeal) | Faster to write correct contracts under time pressure than raw TEAL |
| SDK | algosdk (Python or JS) | Official, well-documented |
| Payments | x402 reference implementation | Mandatory integration |
| Backend | Python (FastAPI) or Node (Express) | Whichever you're faster in — x402 middleware + verification logic lives here |
| Embeddings for semantic search | OpenAI text-embedding-3-small or local sentence-transformers | Cheap, fast, good enough for a demo |
| LLM calls (verification, benchmarking) | Claude or GPT via API | Generating verification reports and running benchmark tasks |
| Frontend | React + Tailwind | Fast to build, looks clean |
| Local dev chain | Algorand Sandbox / LocalNet for dev, deploy to TestNet for the live demo | Real on-chain transactions without real money |
On agent registration:
agent.stake = amount_locked_by_agent
agent.claimed_capability = description
registry[agent_address] = {stake, claim, price, jobs_completed: 0, jobs_failed: 0}
On job completion + verification report:
if report.passes(threshold):
release(escrow_payment → seller)
registry[seller].jobs_completed += 1
registry[seller].reputation = recompute()
else:
refund(escrow_payment → buyer)
slash_amount = min(agent.stake, penalty_formula(job_value))
transfer(slash_amount: agent.stake → buyer)
registry[seller].jobs_failed += 1
registry[seller].stake -= slash_amount
registry[seller].reputation = recompute()
if underwriter_backed(seller):
slash underwriter.stake instead of seller.stake
underwriter.reputation = recompute()
Keep penalty_formula simple for the demo — e.g. a flat percentage of job value or a fixed slash amount per failure. Don't over-engineer this; a simple, explainable rule beats a complex one you can't defend live.
Task: Summarize 10-page PDF into 200 words
Provider: Agent_Summarizer_04
Stake locked: 50 ALGO
✓ Word count: 198 (target: 200 ±10%)
✓ Covers all 5 section headers from source doc
✓ No hallucinated facts detected (cross-check against source)
✓ Format: plain text as requested
Similarity to reference summary: 91%
Confidence: 94%
Recommendation: RELEASE ESCROW — stake unaffected
Buyer override available: [Accept] [Dispute]
Failure case:
Task: Summarize 10-page PDF into 200 words
Provider: Agent_Summarizer_07
Stake locked: 10 ALGO
✗ Word count: 340 (target: 200 ±10%)
✗ Missing 2 of 5 required section headers
Similarity to reference summary: 52%
Confidence: 89%
Recommendation: SLASH STAKE — 5 ALGO transferred to buyer
Reputation updated: 91% → 87% success rate
Agent: Research_Agent_Alpha
★★★★☆ (4.6 / 5, from 312 jobs)
Success Rate: 98%
Current Stake: 120 ALGO
Total Ever Slashed: 4 ALGO (2 incidents)
Avg Latency: 2.1s
Backed by Underwriter: None (self-staked)
Verified by Registry ✓
- "Why does this need blockchain / why not just a database?" → A database can store a claim or a reputation score, but it cannot trustlessly and automatically move real funds the instant a verification check fails. The slashing has to be enforced by code neither party controls — that's the whole point.
- "Why should I trust the verification engine?" → It's a deterministic checklist against the original spec, not subjective judgment (show the report format). Buyer override always available.
- "What stops an agent from gaming its own capability claim?" → It's backed by real staked funds — overclaiming and underperforming costs the agent money automatically, which is the actual disincentive, not a benchmark score alone.
- "What happens if an agent runs out of stake?" → It can't accept jobs above what its remaining stake can back; must restake before being eligible for higher-value work.
- "Isn't this just insurance?" → Yes, structurally — that's the point. We're applying a proven economic primitive (underwriting) to a genuinely new domain (AI capability claims), which is why the underwriter-agent layer exists.
- "Why Algorand specifically?" → Fast finality and low fees make high-frequency micro-payments and slashing events between agents economically viable — this breaks down on a slow or expensive chain.
| Phase | Time | Focus |
|---|---|---|
| Setup | Hour 0-2 | Algorand sandbox running, wallets created, x402 reference code pulled and understood |
| Core contracts | Hour 2-10 | Registry + staking + escrow/slashing contracts written and tested on LocalNet |
| Payment + verification | Hour 10-16 | x402 gateway wired up, verification engine producing reports, wired to trigger release/slash |
| Integration | Hour 16-22 | Wire registry + stake + escrow + payments + verification into one working flow, deploy to TestNet |
| P1 features | Hour 22-30 | Benchmarking, semantic discovery, underwriter agents — in that order, stop if time runs short |
| UI polish | Hour 30-36 | Comparison cards with stake visibility, live slash/release animation, make it demo-pretty |
| Demo prep | Last few hours | Script the demo (pass case + fail/slash case), pre-test semantic queries, rehearse Q&A answers |
Cut in this order, stopping as soon as you're back on track:
- Underwriter agents → drop, keep self-staking only
- Semantic discovery → fall back to category dropdown
- Capability benchmarking → fall back to self-declared claims with manually-set stake
- UI polish → rough but functional screens are fine
- Multi-agent chaining → never build this unless everything above is done early
Never cut: the stake → escrow → verification → slash-or-release → reputation-update loop. That loop is the entire product. Everything else is presentation.