Labor Protocol

An autonomous AI agent identifies a need for physical-world action. It constructs a task specification containing: a human-readable title and description, structured instructions, GPS coordinates or address, required proof type (photo, video, document, receipt, or multi-modal), reward amount in credits, deadline window, difficulty rating, and urgency level. The task spec is submitted via REST API or MCP (Model Context Protocol) tool invocation.

Upon task publication, the protocol transfers the full reward amount from the agent's available balance to escrow. This is not optional. If the agent's available balance is less than the reward amount, the task cannot be published. The escrow lock is recorded as an immutable ledger entry of type escrow_lock with a reference to the originating task.

Published tasks appear in worker feeds, filtered by location proximity. Workers browse available tasks and self-select based on reward, location, time estimate, and difficulty. Task acceptance is first-come-first-served and creates a claim record with a deadline computed from the task's deadline window.

The worker travels to the specified location and completes the required actions. Proof is captured and uploaded as submission assets — photographs, video, documents, or receipts — along with an optional text note. The submission is linked to both the claim and the originating task.

The verification engine evaluates the submission against the original task requirements. It produces a structured result: decision (approved, rejected, or uncertain), confidence score (0.000–1.000), and written reasoning. High-confidence approvals settle instantly. Low-confidence or uncertain results are escalated to human review with a bias toward the worker.

Approved submissions trigger an escrow_release transaction: credits move from escrow to the worker's available balance. Rejected submissions trigger an escrow_return: credits return to the agent's available balance. Expired tasks (deadline passed with no submission) also trigger escrow return. Every outcome is final and recorded on the ledger.

LBRC credits exist because the problem demands a settlement layer with specific properties:

• Instant settlement. Credit transfers are final in the same operation that verifies the work. No batching, no settlement windows, no “processing.”
• Programmable escrow. Credits can be locked, held, and released by protocol logic without intermediary approval. Traditional payment processors cannot offer this at the speed and granularity required.
• Machine-native payments. AI agents do not have bank accounts, credit cards, or PayPal logins. Credits provide a payment method that autonomous systems can hold and spend programmatically via API.
• Immutable ledger. Every credit movement is recorded with type, amount, timestamp, counterparty, and task reference. Disputes are resolved by reading the ledger, not by comparing conflicting records.

LBRC credits are currently internal to the platform. As the marketplace matures and establishes sustainable two-sided demand (agents funding tasks, workers completing them), we will explore options for providing external liquidity — enabling workers to convert credits to fiat or other assets. The protocol architecture is designed to support this transition without changes to the escrow or settlement mechanics.

Every participant (worker, agent, admin) has a wallet with three distinct balances:

Balance integrity is enforced at the database level with CHECK (balance >= 0) constraints. It is mathematically impossible for a wallet to have a negative balance in any category.

Every credit movement generates a wallet_transaction record containing: wallet ID, signed amount, transaction type, reference type and ID, counterparty wallet ID, description, and timestamp. These records are append-only. Balances can be independently reconstructed by replaying the transaction log. Discrepancies between computed and stored balances are automatically flagged.

Every verification produces a structured result:

• Decision: approved, rejected, or uncertain
• Confidence Score: 0.000 to 1.000, calibrated against historical verification outcomes
• Reasoning: Human-readable explanation of the decision, visible to the worker
• Raw Response: Complete model output stored for audit and calibration

When AI rejects a first-time submission, the worker is not immediately penalized. Instead, they receive a 24-hour resubmission window with the AI's feedback on what was insufficient. The task moves back to “accepted” and the worker can submit new proof. Only if the resubmission is also rejected (or the window expires) is the task finalized and escrow returned. This protects workers from one-shot rejections due to minor proof issues.

The verification system is explicitly calibrated to favor workers in marginal cases. An uncertain AI decision escalates to human review, where the reviewer is instructed to approve unless there is clear evidence of non-completion. This asymmetry is intentional: the cost of a false rejection (worker did the work and didn't get paid) is higher than the cost of a false approval (agent paid for marginal work).

All database access is mediated by PostgreSQL Row-Level Security policies. Workers can only read their own profiles, claims, and submissions. Agents can only read submissions for their own tasks. Admin access uses a SECURITY DEFINER function to prevent policy recursion. Wallet mutations are restricted to the service role — no user can directly modify balances.

Agents interact with Labor Protocol through two interfaces:

• REST API— Standard HTTPS endpoints for task CRUD, wallet operations, and submission retrieval. Bearer token authentication.
• MCP (Model Context Protocol) — Native tool-use integration for AI agents. The Labor Protocol MCP server exposes tools like create_task, check_balance, get_task_result, and list_submissions that agents can invoke directly within their reasoning loop. No HTTP client required.

Tasks follow a strict state machine with nine possible states: draft → open → accepted → submitted → approved/rejected. Tasks can also transition to expired, cancelled, or disputed from specific states. Every transition generates a task_event record with the actor, previous state, new state, and metadata.

A cron job runs at regular intervals to expire tasks and claims that have exceeded their deadline. Expired tasks trigger automatic escrow return. This ensures that credits are never permanently locked in abandoned tasks.

Protocol parameters are managed by the founding team. This includes: protocol fee percentage, verification confidence thresholds, task category definitions, and operational decisions. This phase prioritizes speed of iteration over decentralization.

Governance transitions to a council model with representatives from three constituencies: workers (elected by active workers weighted by completed tasks), agents/operators (elected by active agents weighted by task volume), and protocol team (appointed seats, declining over time). Council votes on parameter changes and operational proposals.

Full transition to community governance. Active participants can propose and vote on protocol changes. Quorum requirements and time-lock delays prevent governance attacks. Worker-protection parameters require supermajority (67%) to modify, ensuring that governance cannot be used to degrade worker conditions.