I built CarbonCompute as a stateful testnet marketplace where an AI agent can post and fund a task, a person can deliver it, and payment moves only after the result passes an explicit acceptance or dispute path.
A physical check, local action, expert judgment, or other external task may require a person. A useful delegation system then has to answer who can claim the work, whether funds exist, what counts as completion, and what happens when the two sides disagree.
The worker needs confidence that payment is funded. The agent needs evidence before release. Both need visible rules for rejection, cancellation, refund, dispute, and reputation rather than a platform silently deciding the outcome.
I implemented the task and escrow lifecycle across posting, funding, assignment, submission, approval or rejection, cancellation and refund, dispute handling, reputation, and layered verification—plus a frontend for the six core marketplace flows.
The default story stays at the level of the person and the work they are trying to finish.
The requester posts the work and locks payment before a person commits.
The worker can inspect the task, reward, and current state before accepting it.
The deliverable is attached to the specific funded task rather than sent off-platform.
Automated, model-assisted, and human/oracle-style checks can contribute to a decision.
Acceptance releases payment; rejection, dispute, cancellation, and refund follow explicit branches.
The outcome contributes to traceability and reputation instead of disappearing after payout.
Different work needs different evidence, and any automated reviewer can be wrong. The contract therefore preserves acceptance, rejection, dispute, cancellation, and refund as distinct outcomes instead of compressing trust into one score.
The first obvious primitive was contract-backed payment: prove funds exist and release them after approval.
Escrow does not define completion. Without task states, permissions, evidence, disputes, and reputation, it only moves the trust problem to the moment of acceptance.
I expanded the design into a full job lifecycle with layered verification, deliverable attestation, dispute states, identity and reputation modules, and tested failure paths.
The product principle became: money should move only after the system can explain which state changed, who had authority, and what evidence supported it.
Coverage spans permissions, state transitions, escrow, verification, identity, reputation, module interactions, and failure paths.
The documented LaborEscrow contract is inspectable on Ethereum's Sepolia testnet.
Inspect the testnet contract ↗Contracts, verification design, test coverage, and the six core marketplace flows.
The technical route covers the contract state machine, five-tier verification design, settlement boundaries, and the difference between test coverage and marketplace adoption.
Task, escrow, identity, reputation, verification, and dispute modules coordinate one lifecycle.
Automated evidence may contribute to a decision without becoming unquestionable authority.
Rejection, dispute, cancellation, and refund are first-class protocol paths.
One hundred tests and a public testnet contract establish inspectable engineering work within a narrow boundary.
Have a useful AI idea trapped in an unclear brief or brittle prototype?
Send me the rough version →