00摘要
MicroTask 是构建于 Solana 网络之上的链上任务悬赏协议。需求方将悬赏金额作为押金存入智能合约托管的 Escrow 账户,开发者押付 10% 承诺金接单,验收通过后合约自动结算。整个生命周期不依赖任何中心化主体的资金保管或人工审批。
本文档阐述协议的核心机制、状态机设计、经济模型与技术架构。
01引言
1.1 这是个什么网站
MicroTask 是一个构建于 Solana 之上的 Web3 任务悬赏市场平台。它的核心目标用一句话讲清:
让独立创业者和小团队,能在 AI 加速的时代,快速找到能落地他们想法的开发者和设计师;与此同时,让独立的开发者和设计师,不需要付昂贵的平台抽成就能直接触达客户。
具体能做什么:
- 甲方(创业者、小团队、个人)发布需求:一个 landing page、一个 dApp、一份 logo、一段视频、一个 Solana 脚本——任何 1–14 天能交付的工作
- 悬赏金从甲方钱包直接进入智能合约托管账户(escrow),不经过任何"平台账户"
- 开发者/设计师浏览任务、主动投标、押 10% 承诺金接单
- 交付完成、客户验收 → 合约秒级自动放款(worker 拿 95% bounty + 押金,协议金库收 5%)
- 整个流程没有客服、没有人工审批、没有中介、没有 KYC
1.2 全球自由职业市场的现状
全球自由职业市场年规模已超过 4000 亿美元,并以每年约 15% 速度增长。但这个市场的底层信任模型仍停留在 Web2 时代。主流平台的运作流程是这样的:
- 甲方注册平台 → 上传任务 → 付款托管在平台账户里
- 开发者注册 → 提交 KYC 验证 → 投标(很多平台投标本身要花点数)→ 被选中
- 平台代为撮合、托管资金、记录沟通
- 交付后平台收 10–30% 抽成、5–14 天后才允许提现,跨境再扣 3–5%
- 整个过程平台是事实上的"信任中介"——它持有所有人的钱、所有人的数据、所有人的信誉
每个环节都是平台抽成的机会。每个环节都是用户被"卡"的可能。
1.3 甲方面临的痛点
痛点一:找不到靠谱的人。主流平台的搜索体验糟糕,简介注水严重("10 年经验"实际只有 1 年),评分系统被刷(5 星评价含金量低),搜索结果按"投标点数"排序——价高者得,劣币驱逐良币。
痛点二:资金安全焦虑。钱押在平台账户,平台跑路、政策变化都会冻结你的资金。疫情期间 Upwork 大批账户被冻数月,PayPal 多次调整政策导致跨境付款受阻。一旦平台破产,你的钱属于普通债权,排在所有有担保债权之后。
痛点三:沟通断层。平台拦截外部联系方式("为安全保护"),实际上是为了让你必须站内沟通——平台从中获取所有交付物的信息,并在政策上禁止"线下私单",违反 ToS 可能被封号。
痛点四:争议处理慢且偏向。客服平均 7–14 天才回应,仲裁结果对支付平台费高的一方友好(高 GMV 用户优先),透明度极低。
痛点五:高频小批量任务无处发布。现实场景:一条视频需要 10–20 个缩略图变体;一个 SaaS 主页每周迭代 3 次;一个 dApp 需要持续小修小补。这类单价低($10–500)、频次高(每周多次)、需要专属合作关系的任务,在传统平台严重错配——Upwork 鼓励长期合同(每次重新"约会"才能开始),Fiverr 强制套餐化($5/单价导致无差异竞争)。发上去太轻、雇全职太重——这是 freelance 市场最大的未服务空白。
1.4 开发者/设计师面临的痛点
痛点一:在 0% 边际成本的商业模式下,10–20% 抽成 = 年损失数万美元。AI 时代的独立开发者运行的是接近零边际成本的商业模式:月运营成本可以低至 $1000,但年净利润可达 $100 万。在这种结构下,10–20% 平台抽成意味着每年净亏损 $10–30 万——这不是"小烦恼",是"致命伤"。Upwork 抽 10–20% + Fiverr 25%(含提现费)+ Toptal 30%+ + 跨境提现再加 3–5%——一个能年净 $100 万的开发者,被平台逻辑硬生生压缩到 $60 万。
痛点二:KYC 摩擦。每个平台都要:身份证 + 人脸识别 + 银行账户验证。不同地区的开发者通过率不一(部分被列入禁用名单)。换平台一切从头开始。
痛点三:提现慢。Upwork 5 个工作日才能提,跨境到账再加 3–5 天。现金流紧时无法提前。
痛点四:信誉孤岛。在 Upwork 攒了 100 条好评,到 Fiverr 一文不值。在传统平台积累的信誉无法迁移到任何其他地方。换平台 = 信誉清零。
痛点五:冷启动地狱。新账户没评分,匹配权重最低。平台普遍偏好"绿勾认证"的高 GMV 用户。新人前 3–6 个月几乎接不到单——这是一个本质上的"赢家通吃"系统。
痛点六:摩擦 = 时间损耗 = 商业模式破产。独立开发者的时间是最贵的资产——他们用 AI 把生产力压缩到极致,一天能交付以前一周的活。但传统平台的工作流要求他们反复进入"谈判态":初聊 → 报价 → 改方案 → 合同 → 启动会议 → 中期 review → 最终 review → 提现。每个环节都打断心流。一个能用 1 天完成 $1000 项目的开发者,在传统流程下要花 3 天才能开始动手。摩擦本身就是他们最大的成本——比 20% 抽成更致命。
1.5 AI 时代的双边爆炸与匹配断层
过去两年,AI 工具(Cursor、Claude Code、v0、Lovable、Bolt 等)让独立开发者的供给侧产能爆炸:
- 1 个人 1 天可以交付一个完整的 landing page(之前需要团队一周)
- 1 个人 3 天可以做出一个 SaaS MVP(之前需要 2 个月)
- 设计、文案、代码、测试都被 AI 显著加速
但 AI 时代不只是供给侧爆炸——需求侧也同时爆炸:
- "半技术"创始人的微服务需求:非技术创始人用 Lovable、Bolt、v0 等 AI 工具能搭出网页雏形,但卡在数据库部署、支付集成、域名解析、合约调用等环节——他们不需要全职工程师,只需要一个能 4 小时帮忙搞定的专家。
- AI 同质化反向创造的需求:AI 让基础内容(网站、文案、设计)趋于平均水准,反而让"有专业判断力的人类"溢价——非技术创始人愿意为"品牌视觉差异化"等人类专长服务买单。
- 零边际成本创业者的极简交易需求:solo 创业者月运营 $1000、年净 $100 万——他们追求"客户直接刷卡、无需开会"的极简交易。任何 KYC、合同、提现等待都是商业模式的致命摩擦。
但与此同时,主流平台仍按"项目门槛 + 评分体系"运作。AI 时代的"快交付独立开发者"反而被旧平台边缘化——他们没有 5 年 GMV 累积、没有 200 条好评、没有 Toptal 那种严选认证。甲方也找不到这群人——传统平台的搜索逻辑根本不为"快交付者"优化。
匹配断层:供给端(AI 加持的独立开发者)爆炸,需求端(半技术创始人、小团队、零边际成本创业者)也爆炸,但中间的撮合机制还停留在 Web2 时代。MicroTask 是为了填补这个断层。
1.6 与传统接单平台的全面对比
每 $1,000 项目 · 开发者实际到手
数据基于公开抽成 + 跨境提现费 + 处理费的合计。MicroTask 5% 协议费;其他平台为 15–35% 区间。
独立创业者年损失 · 假设年 GMV $1,000,000
传统平台
$150K – $350K
15–35% 抽成 + 跨境费
→ 每年多保留收入 $100K – $300K
| 维度 | MicroTask | Upwork | Fiverr | Toptal |
| 平台费率 | 5% 固定 | 10–20% | 20% + 提现费 | ≥30% |
| 资金托管方 | 智能合约 escrow | 平台账户 | 平台账户 | 平台账户 |
| 结算速度 | < 1 秒 | 5–10 工作日 | 14 天 | 5–7 天 |
| 跨境额外费 | 0 | 3–5% | 1–3% | 视地区 |
| KYC 要求 | 无 | 强制 | 强制 | 极严格 |
| 争议解决 | 状态机自动 + DAO | 客服 7–14 天 | 客服 5–7 天 | 客服 + 经理 |
| 冷启动门槛 | 0(钱包即用) | 评分系统门槛 | 新人压价竞争 | 顶 3% 录取 |
| 跨平台信誉 | ✓ 钱包一致 | ✗ | ✗ | ✗ |
| 沟通中介 | 双方私聊 | 平台必经 | 平台必经 | 平台 + 经理 |
| 抗女巫机制 | 10% 押金 | Connects 点数 | 无(导致刷单) | 严选制 |
核心差异化:MicroTask 不是"另一个平台",而是用合约替代了平台这个角色。资金安全、结算速度、信誉迁移、抗女巫、争议处理这五个传统平台的核心能力,全都被合约逻辑接管。我们没有更好的客服、没有更精的算法——我们就是不需要。
1.7 我们的方案
MicroTask 把信任迁移至代码层:
- 链上托管:押金、平台费由智能合约托管,没有任何主体能挪用
- 5% 固定费率:比传统平台低 50–80%
- 钱包即身份:无 KYC、跨设备一致、跨平台可迁移
- 秒级结算:Solana 链上自动放款,无国内/跨境之分
- 反向匹配:开发者主动来找你(你不用去搜)
- 无人可动的协议金库:5% 累积在私钥已销毁的链上地址,主网上线后切换为 PDA + DAO 治理
02协议概述
2.1 角色
协议中定义两个核心角色:
- Client(需求方)—— 发布任务、押付悬赏金、验收交付物。
- Worker(接单方)—— 投标、押付承诺金、提交交付物。
协议本身不作为参与方介入资金流动,仅以 5% 协议费形式参与结算。
2.2 状态机
每个任务存在以下状态,状态转换由合约依据预设条件触发,不可人为越级:
| 状态 | 描述 |
| Open | 招募中,可投标 |
| InProgress | 接单成功,开发者交付期内 |
| Submitted | 已提交,进入 7 天验收期 |
| Completed | 验收通过,结算完成 |
| Cancelled | 取消(仅 Open 状态可触发) |
03核心机制
说明:本章描述协议层面的核心机制(spec 设计)。当前 Devnet demo 通过前端 JavaScript + 临时 Escrow keypair 等价实现;主网阶段将切换为 Anchor 合约 + PDA 控制的 escrow,业务逻辑等同。具体技术差异见第 05 章。
3.1 任务发布与押金托管
需求方调用 create_task 指令,传入悬赏金额、验收标准、招募截止时间、交付期限。合约创建 Escrow PDA,悬赏金额从需求方钱包转入。
招募期内若无人接单,需求方可调用 cancel_task,押金原路退还。
3.2 投标与接单
开发者调用 submit_bid,附上预期金额与方案说明。需求方可从所有投标中选择一名,调用 accept_bid。被选中的开发者钱包须存有不少于 10% 悬赏金额的承诺金,合约同时将该承诺金转入 Escrow。
至此 Escrow 账户中持有:
- 悬赏金额(来自 Client)
- 承诺金 10% × 悬赏(来自 Worker)
任务进入 InProgress 状态。
3.3 交付与验收
开发者在交付期内调用 submit_delivery,提交交付物链接与备注,任务进入 Submitted。需求方在 7 天验收期内有以下选择:
- approve —— 验收通过,进入结算
- reject —— 驳回(须附理由),开发者可修改后重新提交
- 不操作 —— 7 天后任意人可调用 claim_timeout,合约视为自动通过
3.4 自动结算
验收通过后,合约一次性执行以下转账:
- → Worker:承诺金(10%)+ 95% × 悬赏金额
- → 协议金库:5% × 悬赏金额
整笔结算在 1 个 Solana slot 内完成(平均 < 1 秒),全部上链可查。
3.5 超时违约
若开发者未在交付期内提交,需求方可调用 claim_default:悬赏金额原路返还需求方,承诺金作为违约赔付一并归需求方。
承诺金机制确保接单是有"皮肤在游戏中"的承诺,而非零成本的占位行为。
3.6 取消机制
仅在 Open 状态、且任务尚未被任何开发者接单的情况下,需求方可无成本取消,押金原路退还。一旦进入 InProgress,状态机不再允许单方取消。
04经济模型
4.1 协议费
固定 5%。该费用用途:
- 协议开发与维护
- 链上数据存储成本(Solana rent)
- 社区治理国库
4.2 押金比例
接单押金固定为悬赏金额的 10%。该参数旨在:
- 提高接单严肃性,过滤"占坑"行为
- 在违约情形下为需求方提供经济补偿
- 避免过高门槛阻碍开发者参与
未来该参数可通过治理投票调整。
4.3 激励对齐
| 角色 | 利益 | 风险 |
| Client | 不付款不交付的可能性归零 | 押金锁定至验收周期结束 |
| Worker | 验收通过后秒级到账 | 承诺金违约则赔付 |
| Protocol | 5% 协议费可持续累积 | — |
三方激励对齐:开发者按时交付符合自身利益,需求方拒绝合理交付物会触发争议机制并承担时间成本。
05技术架构
5.1 系统架构概览
MicroTask 是一个静态单页应用 + 链上交互的极简架构。前端不持有任何私钥,所有资金动作都由用户钱包本地签名后直接广播到 Solana 网络。整体三层结构:
System Architecture
↓
应用层
Frontend SPA
HTML + Tailwind + Vanilla JS
单文件,可静态托管
↓
钱包
Phantom
Wallet Adapter
本地签名、不上传私钥
链交互
@solana/web3.js
通过 esm.sh 加载
构建 + 广播交易
↓
链上
Solana Network
SystemProgram 转账
Escrow 账户托管资金
5.2 资金流图
一个完整任务从发布到结算,资金的链上流向:
Fund Flow · 1 SOL bounty / 1.5 SOL bid
Client
→
Escrow
1.5 SOL
发布任务时托管悬赏金
Worker
→
Escrow
0.15 SOL
投标时押 10% 承诺金
Escrow
→
Worker
1.575 SOL
验收通过 = 95% × 1.5 + 0.15 押金
Escrow
→
Treasury
0.075 SOL
5% 协议费 · 进入无人可动的金库
所有转账都是真实 Solana 交易,可在 Solscan 用 tx hash 验证。
5.3 状态机
每个任务的生命周期对应一个有限状态机。状态转换条件预先编码,无人能跳过:
State Machine
[create_task]
Open
Open
— accept_bid →
InProgress
Open
— cancel(仅 client)→
Cancelled
InProgress
— submit_delivery →
Submitted
InProgress
— claim_default(超期)→
Cancelled
Submitted
— approve →
Completed
Submitted
— reject →
Disputed
Submitted
— claim_timeout(7 天后)→
Completed
5.4 关键代码导览
下表列出当前 Devnet demo 实现中的核心函数与所在位置(行号基于当前 index.html):
| 函数 | 用途 | 关键代码动作 |
userPaysTo(toPubkey, sol) | 用户钱包签名转账 | 构造 SystemProgram.transfer → Phantom 弹窗签名 → 广播交易 |
escrowPaysTo(escrow, to, sol) | Escrow 账户签名转账 | 用 escrow keypair 私钥直接签名 → 无 Phantom 弹窗 → 广播交易 |
submitCreate() | 发布任务 | 生成 escrow keypair → userPaysTo(escrow, bounty) → 任务写入 localStorage |
submitBid() | 投标 + 押金 | userPaysTo(escrow, 10% × bid_amount) → bid 加入 task.bids |
acceptBid(taskId, bidId) | 接受投标 | 逐个 escrowPaysTo 退还其他落选 bid 押金 → 状态变 in_progress |
approveTask(id) | 验收 + 自动结算 | escrowPaysTo(worker, 95% + 押金) + escrowPaysTo(treasury, 5%) |
claimDefault(id) | 违约取回 | 交付期超时 → escrow 全部余额 → client(含 worker 押金赔付) |
claimTimeout(id) | 验收期超时自动通过 | 7 天无审核 → 等同 approveTask 流程,worker 主动触发 |
replyToBid() | 双向私聊 | 仅 task.client 与 bid.worker 可访问;写入 bid.replies 数组 |
5.5 数据模型
当前 Devnet demo 阶段,任务元数据存储在浏览器 localStorage,资金状态由链上 escrow 余额决定。主网阶段,元数据将迁移至 IPFS(PDA 仅记录 CID),实现"链上结算、链下数据"的标准范式:
- Task —— 元数据、状态、双方公钥、时间戳、escrow 地址
- Bid —— 投标人、金额、押金、留言、私聊 thread(replies 数组)、未读跟踪(seenBy)
- Reply —— bid 内嵌私聊单条消息(author / message / seenBy)
- Notification —— 任务状态变化通知(accepted / submitted / completed / rejected / defaulted)
5.6 钱包集成
当前 Devnet demo 通过 Phantom 钱包接入;主网阶段将通过 Solana Wallet Adapter 标准支持 Phantom、Solflare、Backpack、Glow 等所有兼容钱包。用户连接钱包即获得身份,无需注册。前端不持有任何用户私钥,所有交易在用户本地签名后才会广播。
5.7 前端
静态单页应用(HTML + Tailwind CSS + Vanilla JS),可托管至任意 CDN(当前部署于 Netlify)。无构建步骤、无后端服务、无数据库——这是真正去中心化的前端架构,任何人都可以 fork 一份自托管。
06安全模型
6.1 资金安全
当前 Devnet 阶段:Escrow 为临时 keypair,私钥在生成时即销毁;协议金库地址同样为已销毁私钥的钱包。
主网阶段:
- Escrow PDA 由 Anchor 协议合约独占控制,私钥不存在(PDA 在 ed25519 曲线之外)
- 状态机转换路径在主网部署前将通过形式化验证 + 第三方审计
- 合约 Upgrade Authority 由 5/9 多签持有,关键参数变更须 7 天 Timelock
6.2 抗女巫
通过承诺金(10%)实现经济级抗女巫,无需引入身份验证或 KYC。任何试图大量低质量接单的行为都将面临押金违约风险。
07路线图
| 阶段 | 里程碑 |
| Phase 1 | 核心合约部署 · SOL 计价的悬赏与结算 |
| Phase 2 | 多代币支持(USDC、USDT)· 信誉系统 |
| Phase 3 | IPFS 内容寻址完整集成 · 移动端钱包优化 |
| Phase 4 | 跨链桥接 · 与其他主流公链的资金互通 |
08团队与社区
MicroTask 由匿名核心贡献者团队启动并维护。我们相信协议的可信度应来自代码的可审计性,而非创始人的个人背景。
合约源代码将全部公开发布于协议官方仓库。
09风险声明
- 智能合约风险。合约可能存在未知漏洞。用户应仅投入承担得起损失的金额。
- 市场风险。SOL 价格波动可能影响悬赏的实际价值。建议长周期任务采用 USDC 计价。
- 法律合规。用户须自行确保所在司法辖区内使用本协议的合法性。本协议不构成投资、税务或法律建议。
10结语
接单市场过去三十年的演变,本质上是信任中介形态的不断更替——从熟人介绍,到平台担保,到行业巨头。每一代都在解决前一代的问题,但从未解决"中介本身"这个根本问题。
智能合约第一次让我们能够把信任写进代码、把执行交给链。MicroTask 是这条路径的一个早期实现。我们相信,未来十年,越来越多的"信任性服务"将以协议形态存在——不需要公司、不需要客服、不需要承诺。
只有签名,与代码。
00Abstract
MicroTask is an on-chain task bounty protocol built on Solana. Clients deposit bounty into a smart-contract-controlled escrow; workers post a 10% commitment bond to accept; the contract settles automatically upon approval. The full lifecycle operates without centralized custody or human approval.
This document specifies the protocol's core mechanism, state machine, economic model, and technical architecture.
01Introduction
1.1 What is this
MicroTask is a Web3 task bounty marketplace built on Solana. The mission, in one sentence:
Help solo founders and small teams quickly find developers and designers who can ship their ideas in the AI era — and let independent builders reach clients directly without paying a heavy platform tax.
Concretely:
- Clients (founders, indie hackers, small teams) post tasks: a landing page, a dApp, a logo, a video, a Solana script — anything deliverable in 1–14 days
- Bounty flows from the client's wallet directly into a smart-contract escrow account — never through a platform's account
- Developers and designers browse, bid, and post a 10% commitment bond on accept
- On approval, the contract settles in under one second (worker gets 95% of bounty + bond; protocol treasury gets 5%)
- No customer support, no human approval, no middleman, no KYC
1.2 The state of the freelance market
The global freelance market exceeds $400 billion annually, growing roughly 15% per year. Yet its trust model is still stuck in the Web2 era. Mainstream flow today:
- Client signs up, posts task, deposits funds into the platform's account
- Developer signs up, completes KYC, bids (often paying for bid credits), gets selected
- Platform mediates communication, holds funds, records everything
- On delivery, platform takes 10–30% commission, releases payment 5–14 days later, charges another 3–5% on cross-border withdrawal
- The platform is the de facto "trust intermediary" — holding everyone's money, data, and reputation
Every step is an opportunity for the platform to extract value. Every step is a chokepoint for users.
1.3 Pain points on the client side
1. Can't find trustworthy people. Search experience on mainstream platforms is poor. Profiles are inflated ("10 years experience" often means 1). Rating systems are gamed. Search is sorted by "bid credits" — pay-to-win, where bad money drives out good.
2. Fund safety anxiety. Money sits in the platform's account. The platform's bankruptcy, policy changes, or exit risk is your risk. During COVID, Upwork froze accounts for months. PayPal has repeatedly altered cross-border policies. If a platform goes under, your funds are unsecured debt.
3. Communication chokepoint. Platforms intercept external contact ("for safety"), but really it's to keep all conversations in-platform. Trying to take a relationship off-platform violates ToS and can get your account banned.
4. Slow, biased dispute resolution. Customer support takes 7–14 days to respond. Arbitration outcomes favor whichever party generates more platform fees (high-GMV users get priority). Process is opaque.
5. High-frequency small-batch tasks have nowhere to go. Real scenarios: a video needs 10–20 thumbnail variants; a SaaS homepage iterates 3 times a week; a dApp needs continuous small patches. These low-unit-price ($10–500), high-frequency, relationship-based tasks are severely mismatched on legacy platforms — Upwork pushes long-term contracts (a re-"meeting" required each time), Fiverr forces $5-gig templating (race to the bottom). Too small to post on Upwork, too irregular to hire full-time — this is the freelance market's largest unserved gap.
1.4 Pain points on the developer/designer side
1. In a near-zero marginal cost business model, a 10–20% cut = tens of thousands lost per year. AI-era solo developers run businesses with near-zero marginal cost: monthly opex as low as $1K, annual net as high as $1M. Under this structure, a 10–20% platform cut means $100K–$300K of net loss per year — not a "minor annoyance," but a fatal wound. Upwork 10–20% + Fiverr 25% (incl. withdrawal) + Toptal 30%+ + cross-border 3–5% — a developer who could net $1M annually is structurally compressed to $600K by platform logic.
2. KYC friction. Every platform requires ID + selfie + bank verification. Approval rates vary by region (some are blacklisted entirely). Switching platforms means starting over.
3. Slow withdrawals. Upwork holds funds 5 working days. Cross-border bank transfer adds 3–5 more days. If you need cash now, too bad.
4. Reputation silos. 100 5-star reviews on Upwork are worthless on Fiverr. Reputation accumulated on one platform doesn't transfer anywhere. Switching = reset to zero.
5. Cold-start hell. New accounts have no rating; matching weight is the lowest. Platforms favor verified high-GMV users. New developers struggle to get a single bid for the first 3–6 months. The system is structurally winner-take-all.
6. Friction = time loss = business model failure. An independent developer's time is their most valuable asset — they use AI to compress productivity to the extreme, shipping in one day what used to take a week. But legacy platform workflows force them into repeated "negotiation mode": initial chat → quote → revisions → contract → kickoff meeting → mid-review → final review → withdrawal. Every step breaks the flow state. A developer who could finish a $1,000 project in one day takes 3 days to even start under legacy flow. Friction itself is their biggest cost — more lethal than a 20% cut.
1.5 The AI-era two-sided explosion and the matching gap
Over the past two years, AI tools (Cursor, Claude Code, v0, Lovable, Bolt) have unleashed the supply side — solo developer productivity:
- One person can ship a full landing page in a day (used to take a team a week)
- One person can ship a SaaS MVP in 3 days (used to take 2 months)
- Design, copy, code, testing — all dramatically accelerated
But it's not only the supply side that exploded — demand exploded too:
- "Semi-technical" founders' micro-service demand: Non-technical founders use Lovable, Bolt, v0 to build website prototypes, but get stuck on database deployment, payment integration, domain routing, smart-contract calls. They don't need a full-time engineer — they need an expert for 4 hours.
- AI-commoditization creating reverse demand: AI flattens the quality of baseline content (websites, copy, design). Counter-intuitively, this makes "humans with professional judgment" command a premium. Non-technical founders pay for brand-visual differentiation and other human-expert services to escape the AI sameness.
- Zero-marginal-cost founders' minimalist transaction demand: Solo founders running on $1K/month opex with $1M/year net — they want "credit-card-and-go" transactions, no meetings. Every KYC step, contract, withdrawal delay is a fatal friction in their business model.
But mainstream platforms still operate on "project gating + rating systems." The AI-era fast-shipping solo builder is actively penalized by old platforms — they don't have 5 years of GMV history, 200 testimonials, or Toptal-grade vetting credentials. Clients can't find them either, because traditional search isn't optimized for "fast turnaround."
The matching gap: supply (AI-augmented solo builders) is exploding, demand (semi-technical founders, small teams, zero-marginal-cost solo entrepreneurs) is also exploding, but the matching layer is still Web2. MicroTask exists to close this gap.
1.6 Side-by-side comparison with traditional platforms
Per $1,000 project · what the freelancer actually keeps
Based on published fees + cross-border withdrawal + processing costs. MicroTask 5% protocol fee; others span 15–35%.
Annual loss for a solo founder · assuming $1M GMV
MicroTask
$50K
5% fixed protocol fee
Legacy platforms
$150K – $350K
15–35% cut + cross-border fees
→ Extra revenue retained per year: $100K – $300K
| Dimension | MicroTask | Upwork | Fiverr | Toptal |
| Platform fee | 5% fixed | 10–20% | 20% + withdrawal | ≥30% |
| Fund custody | Smart contract escrow | Platform account | Platform account | Platform account |
| Settlement speed | < 1 sec | 5–10 working days | 14 days | 5–7 days |
| Cross-border surcharge | 0 | 3–5% | 1–3% | varies |
| KYC required | None | Mandatory | Mandatory | Strict vetting |
| Dispute resolution | State machine + DAO | Support 7–14d | Support 5–7d | Support + manager |
| Cold-start barrier | 0 (wallet ready) | Rating-gated | Race to bottom | Top 3% only |
| Cross-platform reputation | ✓ wallet-portable | ✗ | ✗ | ✗ |
| Communication mediator | Direct DM | Platform-only | Platform-only | Platform + manager |
| Sybil resistance | 10% bond | Connects credits | None (causes spam) | Vetting |
Key differentiation: MicroTask isn't "another platform" — it replaces the platform with a contract. The five core capabilities of traditional platforms (fund safety, settlement speed, reputation portability, sybil resistance, dispute resolution) are all absorbed by contract logic. We don't have better support staff or smarter algorithms — we just don't need them.
1.7 Our approach
MicroTask migrates trust into code:
- On-chain custody: bond and platform fee held by smart contract; no party can misappropriate
- 5% fixed fee: 50–80% lower than incumbents
- Wallet as identity: no KYC, cross-device consistent, cross-platform portable
- Sub-second settlement: Solana-native auto-payout; no domestic vs cross-border distinction
- Reverse matching: developers come to you (you don't search them)
- Untouchable treasury: 5% accumulates at an address whose private key has been discarded; on mainnet it migrates to PDA + DAO governance
02Protocol Overview
2.1 Roles
The protocol defines two roles:
- Client — Posts task, deposits bounty, approves delivery.
- Worker — Bids, posts commitment bond, submits delivery.
The protocol itself is not a counterparty in the fund flow; it participates only as a 5% fee at settlement.
2.2 State machine
Each task occupies one of the following states. Transitions are triggered by contract under predefined conditions and cannot be skipped manually:
| State | Description |
| Open | Recruiting, accepting bids |
| InProgress | Bid accepted, worker within delivery window |
| Submitted | Delivery submitted, in 7-day review window |
| Completed | Approved, settlement complete |
| Cancelled | Cancelled (only from Open) |
03Core Mechanisms
Note: This chapter describes the protocol-level mechanism (spec). The current Devnet demo achieves equivalent behavior via frontend JavaScript + a transient escrow keypair; on mainnet this will be replaced by an Anchor program with PDA-controlled escrow. Business logic is identical. See chapter 05 for implementation differences.
3.1 Task creation and escrow
Client calls create_task with bounty amount, acceptance criteria, recruitment deadline, and delivery window. The contract creates an Escrow PDA; bounty transfers from client wallet.
If no bid is accepted within the recruitment period, the client may call cancel_task for a full refund.
3.2 Bidding and acceptance
Workers call submit_bid with proposed amount and approach. The client selects one bid via accept_bid. The chosen worker's wallet must hold at least 10% of the bounty as commitment bond, which the contract transfers into Escrow.
The Escrow now holds:
- Bounty amount (from Client)
- Commitment bond, 10% × bounty (from Worker)
Task enters InProgress.
3.3 Delivery and review
Worker calls submit_delivery within the delivery window with deliverable links and notes. Task enters Submitted. Within the 7-day review window, the client may:
- approve — Approval; proceeds to settlement
- reject — Reject (with reason); worker may revise and resubmit
- No action — After 7 days, anyone may call claim_timeout; auto-approved
3.4 Automatic settlement
Upon approval, the contract executes in a single transaction:
- → Worker: Commitment bond (10%) + 95% × bounty
- → Treasury: 5% × bounty
Settlement completes within one Solana slot (typically < 1 second), fully on-chain auditable.
3.5 Default
If the worker fails to submit within the delivery window, the client may call claim_default: bounty refunded to client, commitment bond awarded to client as compensation.
Commitment bonds ensure that accepting a task is a "skin in the game" commitment, not a zero-cost placeholder.
3.6 Cancellation
Cancellation without cost is permitted only in Open state, before any bid has been accepted. Once in InProgress, the state machine no longer permits unilateral cancellation.
04Economic Model
4.1 Protocol fee
Fixed 5%. Allocated to:
- Protocol development and maintenance
- On-chain storage costs (Solana rent)
- Community governance treasury
4.2 Commitment bond ratio
Fixed at 10% of bounty. The parameter aims to:
- Increase bid seriousness; filter out placeholder bids
- Compensate clients economically in default scenarios
- Avoid raising the participation barrier excessively
This parameter is adjustable by future governance vote.
4.3 Incentive alignment
| Role | Upside | Risk |
| Client | "Paid but not delivered" → 0 | Capital locked through review window |
| Worker | Sub-second settlement on approval | Bond forfeited on default |
| Protocol | Sustainable 5% fee accrual | — |
Three-way alignment: workers benefit from timely delivery; clients refusing legitimate work triggers dispute and bears time cost.
05Technical Architecture
5.1 System architecture
MicroTask is a static SPA + on-chain interaction minimal architecture. The frontend holds no private keys; every fund movement is signed locally by the user's wallet and broadcast directly to Solana. Three-layer structure:
System Architecture
User
Browser
Visit site · interact UI
↓
App layer
Frontend SPA
HTML + Tailwind + Vanilla JS
Single file, CDN-hostable
↓
Wallet
Phantom
Wallet Adapter
Local sign · keys never leave
Chain RPC
@solana/web3.js
Loaded via esm.sh
Build + broadcast tx
↓
On-chain
Solana Network
SystemProgram transfer
Escrow holds funds
5.2 Fund flow
A complete task from posting to settlement, on-chain fund movement:
Fund Flow · 1.5 SOL bid example
Client
→
Escrow
1.5 SOL
on task creation
Worker
→
Escrow
0.15 SOL
10% commitment bond on bid
Escrow
→
Worker
1.575 SOL
on approval = 95% × 1.5 + 0.15 bond
Escrow
→
Treasury
0.075 SOL
5% protocol fee · untouchable
Every transfer is a real Solana transaction, verifiable by tx hash on Solscan.
5.3 State machine
Each task's lifecycle is a finite state machine. Transition conditions are pre-encoded; no one can skip:
State Machine
[create_task]
Open
Open
— accept_bid →
InProgress
Open
— cancel (client only) →
Cancelled
InProgress
— submit_delivery →
Submitted
InProgress
— claim_default (overdue) →
Cancelled
Submitted
— approve →
Completed
Submitted
— reject →
Disputed
Submitted
— claim_timeout (after 7d) →
Completed
5.4 Code map
Core functions in the current Devnet demo (line numbers refer to index.html):
| Function | Purpose | Key actions |
userPaysTo(toPubkey, sol) | User-wallet-signed transfer | Build SystemProgram.transfer → Phantom popup → broadcast |
escrowPaysTo(escrow, to, sol) | Escrow-account-signed transfer | Sign with escrow keypair directly → no Phantom popup → broadcast |
submitCreate() | Post task | Generate escrow keypair → userPaysTo(escrow, bounty) → write to localStorage |
submitBid() | Bid + bond | userPaysTo(escrow, 10% × bid_amount) → push to task.bids |
acceptBid(taskId, bidId) | Accept a bid | Refund losing bids' bonds via escrowPaysTo loop → status = in_progress |
approveTask(id) | Approve + auto settle | escrowPaysTo(worker, 95% + bond) + escrowPaysTo(treasury, 5%) |
claimDefault(id) | Claim default | Delivery overdue → escrow balance → client (incl. worker bond as compensation) |
claimTimeout(id) | Auto-approve on timeout | 7d unreviewed → equivalent to approveTask, triggered by worker |
replyToBid() | Bidirectional private chat | Only task.client and bid.worker can access; written to bid.replies |
5.5 Data model
In the current Devnet demo, task metadata is stored in browser localStorage; fund state is determined by on-chain escrow balance. On mainnet, metadata will move to IPFS (PDAs record only the CID), implementing the standard "settle on-chain, data off-chain" pattern:
- Task — metadata, state, both pubkeys, timestamps, escrow address
- Bid — bidder, amount, bond, message, private chat thread (replies array), unread tracking (seenBy)
- Reply — single private chat message inside a bid (author / message / seenBy)
- Notification — task lifecycle event (accepted / submitted / completed / rejected / defaulted)
5.6 Wallet integration
The current Devnet demo integrates with Phantom. On mainnet, MicroTask will support all wallets implementing the Solana Wallet Adapter standard (Phantom, Solflare, Backpack, Glow, etc.). Connecting a wallet grants identity — no registration. The frontend holds no user keys; all transactions are signed locally before broadcast.
5.7 Frontend
Static SPA (HTML + Tailwind CSS + Vanilla JS), deployable to any CDN (currently hosted on Netlify). No build step, no backend service, no database — this is a truly decentralized frontend: anyone can fork it and self-host.
06Security Model
6.1 Fund safety
Current Devnet phase: Escrow is a transient keypair whose private key is discarded at generation; the protocol treasury address is similarly a wallet with discarded key.
Mainnet phase:
- Escrow is a PDA exclusively controlled by the Anchor program; the private key does not exist (PDA is off the ed25519 curve)
- State machine transition paths will undergo formal verification + third-party audit before mainnet deployment
- Upgrade Authority held by 5/9 multisig; key parameter changes require 7-day timelock
6.2 Sybil resistance
Achieved economically via the 10% commitment bond, without identity verification or KYC. Mass-spamming low-quality bids carries direct bond forfeiture risk.
07Roadmap
| Phase | Milestone |
| Phase 1 | Core contracts deployed · SOL-denominated bounty and settlement |
| Phase 2 | Multi-token support (USDC, USDT) · Reputation system |
| Phase 3 | Full IPFS content addressing · Mobile wallet optimization |
| Phase 4 | Cross-chain bridges · Fund interop with major L1s |
08Team and Community
MicroTask is launched and maintained by a team of pseudonymous core contributors. We believe a protocol's credibility should derive from auditable code, not founder identity.
Contract source is published openly in the protocol's official repository.
09Risk Disclosure
- Smart contract risk. Unknown vulnerabilities may exist. Users should commit only what they can afford to lose.
- Market risk. SOL price volatility may affect bounty value. Long-duration tasks should consider USDC denomination.
- Legal compliance. Users are responsible for ensuring lawful use within their jurisdiction. This protocol does not constitute investment, tax, or legal advice.
10Closing
The evolution of the freelance market over the past three decades has, at its core, been a succession of trust intermediaries — from word of mouth, to platform escrow, to industry incumbents. Each generation solved the previous generation's problem, but never solved the problem of intermediation itself.
Smart contracts, for the first time, allow us to write trust into code and hand execution to the chain. MicroTask is one early implementation of that path. We believe that over the next decade, more and more "trust services" will exist as protocols — without companies, without support staff, without promises.
Only signatures, and code.