Design a Crypto Micro-Task Platform (Gig economy)

Problem statement

Design a crypto micro-task platform where requesters post small units of human work—image labeling, short transcription, translation snippets, receipt extraction, search-relevance judging—and workers complete them for micropayments denominated in a stablecoin. The platform must accept task specifications and reward budgets, fund escrow before work begins, let eligible workers claim tasks under contention, receive content-addressed work artifacts, validate quality through automated checks and redundant human consensus, release or refund escrow under explicit timeouts, maintain requester and worker reputation, and settle tiny amounts cheaply and quickly enough that workers trust the balance they see.

The defining tension is financial, not logistical. A $0.08 payout can never pay $1.00 of settlement cost, yet the worker's balance must be as correct as a bank ledger. The design therefore separates three money paths: an off-chain double-entry ledger that is the source of truth for spendable balance with millisecond acknowledgement; batched Layer-2 settlement that anchors ledger state on-chain every few minutes through a signed Merkle root; and optional payment channels for requesters who stream repeated tasks to the same worker. Escrow smart contracts hold requester funds and release them only against validated outcomes or expired timeouts.

Why the problem is distinctive

A conventional gig backend can retry a payment webhook. This system cannot double-release escrow, double-spend an off-chain balance, or lose a submission because a stream partition rebalanced. Quality is also adversarial: workers may farm honeypots, collude in voting rings, or submit plausible garbage; requesters may post spam, refuse good work to avoid paying, or launder funds through fake tasks. Every one of these is an architecture requirement, not a policy footnote.

Public operating baseline versus design assumptions

Public evidence shows the category is real. Amazon Mechanical Turk publicly reported hundreds of thousands of registered workers and millions of human intelligence tasks completed daily at peak years ago; Gitcoin has run on-chain bounty escrow and Sybil-resistant identity scoring in production; Kleros operates decentralized arbitration courts with staked jurors; Lightning Network public capacity has been tracked in the thousands of BTC with tens of thousands of channels. These are cited public signals, not requirements for our fictional system.

For capacity planning this answer explicitly assumes: 2,000,000 registered workers, 150,000 daily active workers, 500,000 tasks posted per day, 2,500,000 submissions per day, a 5× event peak, average reward $0.08, and average three validation votes per submission. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold—not a claim about any company's private architecture.

The four architectural planes

1. Marketplace plane: task posting, discovery, claiming, submission, reputation, notifications.
2. Validation plane: automated checks, honeypot insertion, redundant consensus, dispute and arbitration.
3. Settlement plane: escrow contracts, off-chain ledger, payment channels, batched L2 finality, withdrawals.
4. Trust and governance plane: Sybil resistance, abuse detection, compliance holds, contract upgrade governance, audit evidence.

A strong interview answer keeps these planes separate: the marketplace may degrade while escrow correctness and ledger integrity never do.