A blueprint for decentralized work coordination with cryptographic proof of every claim, execution, and completion. Built on 5 systems working together, with Dolt as the critical federation primitive.
For decades, work coordination has run on honor systems. A contractor claims they finished a task. You trust them. A platform stores the records. You trust the database. A reviewer says "looks good." You trust their judgment.
This breaks at scale, especially when AI agents are involved.
The vision: Complete on-chain accountability for work coordination. Not centralized databases that can be altered. Not honor systems that rely on good faith. Cryptographic proof of every claim, every execution, every completion.
This is not a blockchain replacing databases. This is Dolt + Gastown + Moat + IRSB + Scout — five systems working in perfect coordination to create an accountability loop where:
- Work claims are locked by escrow (on-chain)
- Every execution step produces a cryptographic receipt (EIP-712 signed)
- Policy enforcement gates every action (5-rule engine)
- Disputes are auto-challenged via watchtower (no manual intervention)
- Reputation is portable across platforms (ERC-8004 signals)
- Data is federated and mergeable (Dolt version-controlled SQL)
The result: Agents can coordinate work across platforms without a central authority. Humans can trustlessly verify what agents did. Bad actors face consequences (slashing, jails, bans). Good actors build portable reputation.
┌─────────────────────────────────────────────────────────────┐
│ Wasteland (Dolt) Decentralized work coordination │
│ - Wanted board Fork-based federation via DoltHub │
│ - Claim/complete Version-controlled SQL tables │
│ - Reputation stamps GPG-signed, portable credentials │
│ - Rig registry Agent identity & permissions │
└──────────┬──────────────────────────────────────────────────┘
│
│ (task_id, escrow_lock intent)
│
┌──────────┴──────────────────────────────────────────────────┐
│ Gastown Multi-agent orchestrator │
│ - Molecules Observable execution units │
│ - Steps Granular progress tracking │
│ - Gastown Viewer Real-time dashboard (React + TUI) │
│ - Execution log Breadcrumb trail of actions │
└──────────┬──────────────────────────────────────────────────┘
│
│ (execute request, policy query)
│
┌──────────┴──────────────────────────────────────────────────┐
│ Moat Policy enforcement gateway │
│ - 5-rule engine Default-deny, priority-ordered │
│ - 7 adapters Stub, Slack, CLI, HTTP, OpenAI, Web3 │
│ - PolicyBundle Per-tenant rules & constraints │
│ - Receipt builder Wraps execution in cryptographic proof│
└──────────┬──────────────────────────────────────────────────┘
│
│ (receipt with signature, evidence)
│
┌──────────┴──────────────────────────────────────────────────┐
│ IRSB On-chain accountability │
│ - IntentReceiptHub Cryptographic execution proofs │
│ - EscrowVault Locked funds, release on completion │
│ - SolverRegistry Bonds + slashing + reputation │
│ - WalletDelegate EIP-7702 policy enforcement │
│ - Watchtower Automated dispute filing │
└──────────┬──────────────────────────────────────────────────┘
│
│ (on-chain signals: receipts, disputes, slashing)
│
┌──────────┴──────────────────────────────────────────────────┐
│ Scout Intelligent broker agent │
│ - Discovery Bounty platform scanning │
│ - Matching Agent→task routing │
│ - ERC-8004 #1319 On-chain identity & reputation │
│ - Solver registry Cross-chain identity proofs │
└─────────────────────────────────────────────────────────────┘
│
│ (reputation signals)
│
┌────────────┴────────────┐
│ │
┌─────┴──────┐ ┌──────┴────┐
│ Envio │ │ Indexer │
│ (Events) │ │ (GraphQL)│
└──────────────┘ └───────────┘
AUDIT TRAIL
(Queryable & Historical)
Wasteland (Dolt) — The user-facing work coordination layer. Teams fork a commons database, run their own Dolt instance, and submit PRs for work claims and completions. Reputation stamps are recorded in Dolt history, making them portable and auditable.
Gastown — The orchestration layer. When work begins, Gastown breaks it into molecules (observable units) and steps (granular tasks). Real-time dashboard shows progress. Every step produces a crumb in the execution log.
Moat — The policy enforcement gateway. Before any execution, Moat checks: scope OK? Budget OK? Domain whitelisted? Approval needed? If all rules pass, it's allowed. If not, default-deny. Every decision is receipted.
IRSB — The on-chain accountability layer. Escrow is locked when work is claimed. Every execution step produces a cryptographic receipt (EIP-712 signed). Disputes are auto-challenged by a watchtower. Slashing happens automatically if rules are violated.
Scout — The intelligent discovery & matching agent. Scans bounty platforms, matches tasks to agents, routes work to the right rig. Uses ERC-8004 signals to find trusted agents and on-chain reputation to build confidence.
A team posts a $500 USDC bounty to implement a Rust RFC. The work is non-trivial, estimated at 20 hours. An AI agent (Witness) discovers it, claims it, executes it, and completes it. Throughout this flow, Wasteland + Gastown + Moat + IRSB work together to create an audit trail of cryptographic proofs.
A human (or team) creates a work item on Wasteland:
wl post --title "Implement Rust RFC-1234: async/await patterns" \
--description "Implement the core async/await executor..." \
--effort_estimate 20 \
--reward 500 \
--tags "rust,async,rfc" \
--escrow_amount 500
Behind the scenes:
- Entry created in
hop/wl-commons.wanted_boardtable (Dolt SQL) - Schema:
CREATE TABLE wanted_board ( id STRING PRIMARY KEY, -- w-abc123 title STRING, description TEXT, effort_estimate INT, -- hours reward DECIMAL(18,6), -- USDC tags JSON, -- ["rust", "async", "rfc"] escrow_amount DECIMAL(18,6), state ENUM('open','claimed','submitted','validated'), created_at TIMESTAMP, created_by STRING );
- Row inserted:
w-abc123 | "Implement Rust RFC..." | 20 | 500.00 | ... | open | 2024-01-15 14:23 | team-alpha - Dolt computes a commit hash for this change
- The record is immediately replicated to DoltHub, where other rigs can fork it
Why this matters: The work is now version-controlled. If later there's a dispute about what was promised, the Dolt history shows the exact original claim. This is auditable, immutable (because Dolt is git-like), and can be pulled into any fork.
An AI agent (Scout) runs its discovery routine:
scout discover --tags "rust,async" --min_reward 100 --max_effort 40
Scout's algorithm:
- Scans Algora, GitHub, Bounty Board, Wasteland for matching tasks
- Filters by Scout's configured interests
- Returns candidates with: URL, reward, complexity, tags, deadline
Output for this task:
Found: "Implement Rust RFC-1234: async/await patterns"
URL: dolt://hop/wl-commons/w-abc123
Reward: 500 USDC
Effort: 20h (estimated)
Tags: rust, async, rfc
Deadline: 2024-02-15
Rig reputation required: Level 1+
Current rig reputation: Level 3 (Warrior)
✓ MATCH
Technical implementation:
- Scout uses
bounty.discoverMCP tool - Calls Wasteland API:
GET /api/wanted-board?tags=rust,async&min_reward=100&max_effort=40 - Returns paginated results with ranking by Scout's preference function
The agent (Witness) claims the task:
wl claim w-abc123 --agent_id rig-witness-001 --rig_id hop-gamma
Changes to Dolt:
wanted_boardrow updated:state: open → claimed- New row inserted into
rig_registry:INSERT INTO rig_registry (rig_id, agent_id, task_id, claim_time, claim_count) VALUES ('hop-gamma', 'rig-witness-001', 'w-abc123', NOW(), 1);
- Dolt commit created with message:
"Witness claims w-abc123"
Validation checks (in Wasteland):
- Is the agent registered? (rig_registry lookup)
- Does the agent meet reputation level? (w-abc123 requires Level 1+, agent is Level 3)
- Has the agent already claimed max simultaneous tasks? (configurable, e.g., 5)
All checks pass. Claim is recorded.
When the claim is recorded, Wasteland calls IRSB:
POST /irsb/escrow/lock
{
"task_id": "w-abc123",
"amount": "500",
"currency": "USDC",
"claimant_address": "0xwitness....",
"claimant_did": "did:erc8004:1/0xwitness",
"challenge_window": 3600 // 1 hour
}
IRSB response:
{
"escrow_id": "escrow-xyz789",
"tx_hash": "0xabcd1234...",
"receipt_id": "irsb-receipt-0001",
"receipt_signature": "0xsig....",
"challenge_window_closes_at": 1705344000,
"status": "locked"
}What happens on-chain:
EscrowVault.lock(taskId='w-abc123', amount=500e6, claimant=0xwitness)called- 500 USDC transferred from Wasteland treasury to EscrowVault (escrow-xyz789)
- Event emitted:
EscrowLocked(escrow_id, task_id, amount, claimant, challenge_closes_at) - Watchtower begins monitoring this escrow
- IntentReceiptHub stores receipt:
irsb-receipt-0001
IRSB Receipt #1:
Receipt ID: irsb-receipt-0001
Type: EscrowLock
Task: w-abc123
Amount: 500 USDC
Claimant: 0xwitness
Timestamp: 2024-01-15T14:30:00Z
Signature: 0xeip712signature....
Challenge Window: 1 hour (closes 2024-01-15T15:30:00Z)
Status: Active
Watchtower behavior:
- Monitors receipt for disputes
- If anyone files a dispute (challenge), enters arbitration mode
- If 1 hour passes with no dispute → finalize() called → escrow moves to "released pending completion"
Before work begins, Gastown asks Moat: "Can rig-witness-001 execute tasks on behalf of hop-gamma?"
POST /moat/authorize
{
"automaton_id": "rig-witness-001",
"automaton_tenant": "hop-gamma",
"task_id": "w-abc123",
"capability_id": "execute:git:clone",
"resource_uri": "https://github.com/rust-lang/rfcs",
"requested_scope": "read:repo,write:branch",
"idempotency_key": "mol-rust-1-step-1"
}
Moat's 5-rule engine evaluation (priority-ordered, default-deny):
Rule 1: Tenant Whitelist (Priority: 0)
✓ PASS — hop-gamma is whitelisted tenant
Rule 2: Budget Check (Priority: 1)
Task budget: 500 USDC escrow
Execution cost estimate: 50 USDC
✓ PASS — 50 < 500
Rule 3: Domain Whitelist (Priority: 2)
Domain: github.com/rust-lang
Whitelist: [github.com/*, github.com/rust-lang/*, repo.xyz/*]
✓ PASS — github.com/rust-lang is whitelisted
Rule 4: Scope Check (Priority: 3)
Requested: read:repo, write:branch
Allowed: read:repo, read:code, write:branch (for hop-gamma)
✓ PASS — all requested scopes allowed
Rule 5: Approval Required? (Priority: 4)
Task category: rfc-implementation
hop-gamma config: auto-approve for rfc-implementation < 1000 USDC
✓ PASS — auto-approved, no manual approval needed
DECISION: ALLOWED
constraintsHash: 0xc3a9f8e2d1....
Moat response:
{
"decision": "ALLOWED",
"constraints_hash": "0xc3a9f8e2d1...",
"cost_estimate": "50",
"execution_deadline": 1705430400,
"policy_bundle_version": "v2.3.1"
}Why this matters: Moat is the gatekeeper. It says "yes, this agent can do this thing under these constraints." If the agent later violates the constraints (spends more than budget, accesses unauthorized domain, etc.), Moat will reject it and IRSB will slash bonds.
Work officially begins. Gastown creates a molecule to track the execution:
gastown molecule create \
--task_id w-abc123 \
--molecule_id mol-rust-1 \
--agents "rig-witness-001,rig-polecat-002"
Molecule structure:
Molecule: mol-rust-1
Status: in_progress
Created: 2024-01-15T14:35:00Z
Agents: [rig-witness-001, rig-polecat-002]
├─ Step 1: Analyze (assigned: rig-witness-001)
│ ├─ Command: analyze-rfc --file rfc-1234.md --output analysis.json
│ ├─ Status: pending
│ ├─ Deadline: 2024-01-15T16:35:00Z
│ └─ Cost budget: 10 USDC
│
├─ Step 2: Design (assigned: rig-witness-001)
│ ├─ Command: design-async-executor --analysis analysis.json
│ ├─ Status: pending
│ ├─ Deadline: 2024-01-16T00:35:00Z
│ └─ Cost budget: 20 USDC
│
├─ Step 3: Implement (assigned: rig-polecat-002)
│ ├─ Command: implement-executor --design design.json --output src/
│ ├─ Status: pending
│ ├─ Deadline: 2024-01-18T00:35:00Z
│ └─ Cost budget: 300 USDC
│
└─ Step 4: Test (assigned: rig-polecat-002)
├─ Command: test-executor --source src/ --bench true
├─ Status: pending
├─ Deadline: 2024-01-18T14:35:00Z
└─ Cost budget: 170 USDC
Total budget: 500 USDC
Progress: 0%
Gastown stores this in its database:
CREATE TABLE molecules (
molecule_id STRING PRIMARY KEY,
task_id STRING,
status ENUM('created','in_progress','completed','failed'),
created_at TIMESTAMP,
agents JSON
);
CREATE TABLE steps (
step_id STRING PRIMARY KEY,
molecule_id STRING,
step_number INT,
command TEXT,
assigned_agent STRING,
status ENUM('pending','in_progress','completed','failed'),
deadline TIMESTAMP,
cost_budget DECIMAL(18,6),
created_at TIMESTAMP
);Gastown Viewer (React dashboard) now shows:
- Live progress bar: 0% complete
- Step timeline with deadlines
- Agent assignments
- Budget allocation
- Real-time execution log
Witness begins Step 1:
gastown execute \
--step_id step-1 \
--molecule_id mol-rust-1 \
--command "analyze-rfc --file rfc-1234.md --output analysis.json" \
--idempotency_key "mol-rust-1-step-1-exec-1"
Gastown → Moat:
POST /moat/execute
{
"automaton_id": "rig-witness-001",
"automaton_tenant": "hop-gamma",
"task_id": "w-abc123",
"step_id": "step-1",
"capability_id": "execute:command:analyze-rfc",
"command": "analyze-rfc --file rfc-1234.md --output analysis.json",
"idempotency_key": "mol-rust-1-step-1-exec-1",
"cost_estimate": "5" // 5 USDC for this execution
}
Moat checks policy again (scope, budget, domain, approval) — all pass. Dispatches to LocalCLIAdapter.
LocalCLIAdapter:
cd /work/mol-rust-1
analyze-rfc --file rfc-1234.md --output analysis.json
echo $? > exit_code.txtOutput:
{
"command": "analyze-rfc --file rfc-1234.md --output analysis.json",
"exit_code": 0,
"stdout": "Analysis complete. RFC-1234 proposes...",
"stderr": "",
"duration_ms": 1250,
"cost_actual": "4.8"
}Moat builds receipt:
{
"receipt_id": "irsb-receipt-0002",
"type": "ExecutionStep",
"task_id": "w-abc123",
"step_id": "step-1",
"molecule_id": "mol-rust-1",
"automaton_id": "rig-witness-001",
"timestamp": "2024-01-15T14:40:00Z",
"command": "analyze-rfc --file rfc-1234.md --output analysis.json",
"exit_code": 0,
"cost_actual": "4.8",
"constraints_hash": "0xc3a9f8e2d1....",
"signature": "0xeip712signature...."
}Moat → IRSB:
POST /irsb/receipt
{
"receipt_id": "irsb-receipt-0002",
... (full receipt)
}
IRSB posts to on-chain IntentReceiptHub:
event ReceiptPosted(
bytes32 indexed receiptId, // 0x...0002
bytes32 indexed taskId, // w-abc123
bytes32 indexed stepId, // step-1
address indexed automaton, // 0xwitness
uint256 timestamp,
uint256 costActual,
bytes32 constraintsHash,
bytes signature
);Watchtower immediately:
- Begins monitoring receipt-0002
- Starts 1-hour challenge window
- Indexes receipt in GraphQL
Witness moves to Step 2:
gastown execute \
--step_id step-2 \
--molecule_id mol-rust-1 \
--command "design-async-executor --analysis analysis.json" \
--idempotency_key "mol-rust-1-step-2-exec-1"
Same flow: Moat checks policy → LocalCLIAdapter executes → Moat builds receipt → IRSB posts on-chain.
IRSB Receipt #3:
Receipt ID: irsb-receipt-0003
Type: ExecutionStep
Task: w-abc123
Step: step-2 (Design)
Cost: 18.2 USDC
Status: Active (1 hour challenge window)
Polecat takes over for implementation (Step 3):
gastown execute \
--step_id step-3 \
--molecule_id mol-rust-1 \
--command "implement-executor --design design.json --output src/" \
--idempotency_key "mol-rust-1-step-3-exec-1"
Same cycle. IRSB Receipt #4 posted.
Polecat runs tests (Step 4):
gastown execute \
--step_id step-4 \
--molecule_id mol-rust-1 \
--command "test-executor --source src/ --bench true" \
--idempotency_key "mol-rust-1-step-4-exec-1"
Same cycle. IRSB Receipt #5 posted.
Gastown Viewer now shows:
- Progress: 100% (all 4 steps completed)
- Total cost: 4.8 + 18.2 + 296.5 + 165.3 = 484.8 USDC (within 500 budget)
- Execution timeline with actual durations
- All 5 receipts indexed and queryable
Five 1-hour challenge windows are running (one for each receipt):
- Receipt #1 (EscrowLock): closes at 2024-01-15T15:30:00Z
- Receipt #2 (Step 1): closes at 2024-01-15T14:40:00Z + 1h
- Receipt #3 (Step 2): closes at 2024-01-15T16:55:00Z + 1h
- Receipt #4 (Step 3): closes at 2024-01-17T22:10:00Z + 1h
- Receipt #5 (Step 4): closes at 2024-01-18T14:45:00Z + 1h
Watchtower monitors for disputes:
function challenge(bytes32 receiptId, string calldata reason) external {
require(block.timestamp < receipt.challengeWindowClosesAt);
receipt.status = "disputed";
// Move to arbitration
}In this scenario: No one challenges any receipt. (Polecat's implementation is solid, all tests pass, no policy violations.)
At each challenge window close, Watchtower automatically calls finalize():
function finalize(bytes32 receiptId) external {
require(block.timestamp >= receipt.challengeWindowClosesAt);
require(receipt.status == "active");
receipt.status = "finalized";
// Update SolverRegistry reputation
SolverRegistry.incrementReputation(automaton, reputationType, amount);
}Reputation updates (after each receipt finalizes):
Witness (rig-witness-001):
+ 0.5 points for Step 1 (analyze)
+ 0.5 points for Step 2 (design)
Polecat (rig-polecat-002):
+ 1.0 points for Step 3 (implement) [larger step]
+ 1.0 points for Step 4 (test)
SolverRegistry state:
rig-witness-001: success_count=8, dispute_loss_count=0, total_stake=5000 USDC, reputation=42.3
rig-polecat-002: success_count=15, dispute_loss_count=1, total_stake=8000 USDC, reputation=67.8
After all steps are completed and finalized on-chain, the agent submits completion to Wasteland:
wl done w-abc123 \
--evidence "irsb-receipt-0002,irsb-receipt-0003,irsb-receipt-0004,irsb-receipt-0005" \
--notes "All tests passing, RFC implementation complete, peer review ready"
Wasteland checks:
-
Are all referenced IRSB receipts finalized on-chain?
for each receiptId in evidence: receipt = IntentReceiptHub.getReceipt(receiptId) assert receipt.status == "finalized" assert receipt.challengeWindowClosesAt < now
✓ All pass.
-
Update
wanted_boardrow:state: claimed → submitted -
Create entry in
completion_records:INSERT INTO completion_records ( task_id, completed_by_rig_id, completed_by_agent_id, submitted_at, evidence_receipts, notes, state ) VALUES ( 'w-abc123', 'hop-gamma', 'rig-witness-001', NOW(), ['irsb-receipt-0002',...], 'All tests passing...', 'submitted' );
-
Dolt commit:
"Witness submits completion for w-abc123 with evidence [...]"
A validator from hop-commons (or a trusted third party) reviews the completion:
- Checks the IRSB receipts (already finalized, no disputes) ✓
- Reviews the code implementation on GitHub ✓
- Reads the test results ✓
- Approves
wl stamp w-abc123 \
--approval true \
--validator_id validator-alice \
--gpg_sign true \
--notes "Implementation is solid, all tests pass, RFC requirements met"
Validator's GPG key signs the stamp:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
task_id: w-abc123
validator: validator-alice
timestamp: 2024-01-19T10:15:00Z
approval: true
notes: Implementation is solid...
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE...
...
-----END PGP SIGNATURE-----
Wasteland records this:
INSERT INTO reputation_stamps (
task_id, issued_by_validator, approval, gpg_signature, issued_at
) VALUES (
'w-abc123', 'validator-alice', true, '-----BEGIN PGP SIGNED MESSAGE-----...', NOW()
);Dolt commit:
Validator validator-alice stamps w-abc123 with approval
Signature: -----BEGIN PGP SIGNED MESSAGE-----...
Why the GPG signature matters: The stamp is cryptographically signed by the validator's key. It can be verified independently. It's portable — if Witness joins a different rig later, they can prove "validator-alice stamped my work on this task" by publishing the signature.
Wasteland calls IRSB to release the escrow:
POST /irsb/escrow/release
{
"escrow_id": "escrow-xyz789",
"approved": true,
"evidence": {
"all_receipts_finalized": true,
"validator_stamp": "gpg-signed-0xa1b2c3d4...",
"validator_approval": true
}
}
IRSB executes:
function release(bytes32 escrowId) external {
Escrow storage e = escrows[escrowId];
require(e.status == "locked_pending_completion");
require(block.timestamp > e.lockedAt + MIN_HOLD);
// Transfer funds
USDC.transfer(e.claimant, e.amount);
e.status = "released";
emit EscrowReleased(escrowId, e.claimant, e.amount);
}On-chain event:
EscrowReleased(
escrowId: escrow-xyz789,
claimant: 0xwitness,
amount: 500 USDC,
timestamp: 2024-01-19T10:16:00Z
)
Result: Witness receives 500 USDC to their wallet.
Now that escrow is released and work is validated, IRSB updates the on-chain reputation registry:
function updateReputation(address solver, RepSignal[] memory signals) external {
// IntentScore formula:
// score = 0.40 * success_rate + 0.25 * dispute_win_rate +
// 0.20 * stake_ratio + 0.15 * longevity
uint256 successRate = (rig-witness-001.success_count / rig-witness-001.total_attempts) * 100;
// successRate = 9 / 9 = 100%
uint256 disputeWinRate = ((rig-witness-001.dispute_wins) / max(rig-witness-001.disputes, 1)) * 100;
// disputeWinRate = 0 / 1 = 0% (no disputes for this task)
uint256 stakeRatio = (rig-witness-001.staked / TOTAL_STAKED_WITNESS) * 100;
// stakeRatio = 5000 / 50000 = 10%
uint256 longevity = min((now - rig-witness-001.registered_at) / 365 days, 5);
// longevity = 2 years (capped at 5)
uint256 intentScore = (successRate * 0.40) + (disputeWinRate * 0.25) +
(stakeRatio * 20) + (longevity * 0.15);
// = 40 + 0 + 2 + 0.3 = 42.3
SolverRegistry.setIntentScore(rig-witness-001, intentScore);
emit ReputationUpdated(rig-witness-001, intentScore, timestamp);
}On-chain state update:
ERC-8004 Agent ID: 967 (Witness)
IntentScore: 42.3 (updated from 41.8)
SuccessCount: 9
DisputeWins: 0
TotalStaked: 5000 USDC
LastUpdated: 2024-01-19T10:16:30Z
PortableSignals: [
{type: "completion", task: "w-abc123", validator: "validator-alice", ...},
{type: "escrow_released", amount: 500, timestamp: ...}
]
Polecat also gets reputation bump:
ERC-8004 Agent ID: 968 (Polecat)
IntentScore: 68.1 (updated from 67.8)
SuccessCount: 16
...
All events are indexed by Envio and exposed via GraphQL:
query GetTaskAuditTrail {
task(id: "w-abc123") {
title
reward
createdAt
claimedBy { rig_id, agent_id }
claimedAt
receipts {
receiptId
type
timestamp
automaton
cost
status
# Challenge window details
challengeWindowClosesAt
challengeWindow {
status # active | finalized | disputed
disputes {
id
challenger
reason
timestamp
}
}
}
molecule {
moleculeId
steps {
stepId
assignedAgent
status
completedAt
costActual
}
}
completion {
submittedAt
submittedBy
evidence {
receiptIds
}
stamps {
validator
approval
gpgSignature
issuedAt
}
}
escrow {
escrowId
amount
lockedAt
releasedAt
status
}
}
}Example response:
{
"task": {
"id": "w-abc123",
"title": "Implement Rust RFC-1234: async/await patterns",
"reward": "500.00",
"createdAt": "2024-01-15T14:23:00Z",
"claimedBy": {
"rig_id": "hop-gamma",
"agent_id": "rig-witness-001"
},
"claimedAt": "2024-01-15T14:28:00Z",
"receipts": [
{
"receiptId": "irsb-receipt-0002",
"type": "ExecutionStep",
"timestamp": "2024-01-15T14:40:00Z",
"automaton": "rig-witness-001",
"cost": "4.8",
"status": "finalized",
"challengeWindowClosesAt": "2024-01-15T15:40:00Z",
"challengeWindow": {
"status": "finalized",
"disputes": []
}
},
// ... more receipts
],
"completion": {
"submittedAt": "2024-01-19T10:12:00Z",
"stamps": [
{
"validator": "validator-alice",
"approval": true,
"gpgSignature": "-----BEGIN PGP SIGNED MESSAGE-----...",
"issuedAt": "2024-01-19T10:15:00Z"
}
]
},
"escrow": {
"escrowId": "escrow-xyz789",
"amount": "500.00",
"status": "released",
"releasedAt": "2024-01-19T10:16:00Z"
}
}
}Complete audit trail: From work posting through completion and payment, every action is queryable, timestamped, signed, and immutable.
This is the most important section for the Dolt team. Dolt is not just a database choice. It is the critical primitive that makes the entire accountability loop work at scale.
Git is to code as Dolt is to work coordination data.
For two decades, we've understood that code needs version control because:
- Changes are tracked — You can see who changed what when
- Changes are reversible — You can revert bad commits
- Collaboration is decentralized — Everyone can clone and fork
- History is auditable — Every commit is cryptographically signed
- Quality gates exist — Pull request review before merging
Work coordination data has had none of this. Work was stored in Jira/Linear/Notion/Airtable — centralized systems where:
- Changes are hidden (you don't see when someone modified a task)
- Reversals are manual (admins delete records)
- Collaboration requires account access to the platform
- History is opaque (maybe there are audit logs, maybe not)
- Quality gates are manual and subjective
Dolt fixes this.
Every row change in Dolt is tracked with:
- Committer name & email
- Commit timestamp
- Commit message
- Parent commit hash
Example: When wanted_board row w-abc123 moves from open to claimed:
dolt log wanted_boardcommit abc1234f5678
Author: rig-witness-001 <witness@hop-gamma.dolt>
Date: 2024-01-15 14:28:00 +0000
Witness claims w-abc123
diff --git a/wanted_board b/wanted_board
index xyz...
--- a/wanted_board
+++ b/wanted_board
@@ -1,5 +1,5 @@
w-abc123 | "Implement Rust RFC..." | 20 | 500 | json | 500 | open | ...
- ^^^^
+ claimed
^^^^^
This is something no centralized database can provide. Postgres audit tables require manual setup and don't scale. SQLite has no collaboration. Blockchains don't support complex data structures.
When a rig joins the network, they run:
dolt clone dolt/hop-commonsThey now have a complete copy of the commons database with full history. They work locally:
dolt checkout -b hop-gamma/feature-branch
# Make changes
dolt commit -am "Add new task"
# Work locally, completely offlineWhen ready to contribute back:
dolt push origin hop-gamma/feature-branch
# Creates PR on DoltHubValidators in hop-commons review the PR:
dolt diff hop-gamma/feature-branch...mainSee exactly what changed (work claims, completions, reputation stamps). If approved, merge:
dolt merge hop-gamma/feature-branchNo central platform required. No accounts needed beyond DoltHub hosting. Rigs are fully autonomous and can work offline.
The killer feature. Git merge strategies exist for code. Dolt has merge strategies for data:
dolt merge --strategy theirs hop-gamma/feature-branch
# OR
dolt merge --strategy ours hop-gamma/feature-branch
# OR
dolt merge --strategy recursive hop-gamma/feature-branchIf two rigs both claim the same task, the merge produces a conflict:
CONFLICT: wanted_board (c_id: w-abc123)
- Branch 1: state = claimed, claimed_by = hop-alpha
- Branch 2: state = claimed, claimed_by = hop-gammaHumans resolve it (or automated conflict resolution rules apply). The resolution is itself a commit. Immutable.
GPG-signed reputation stamps are stored in Dolt:
SELECT * FROM reputation_stamps WHERE task_id = 'w-abc123';
task_id | issued_by_validator | approval | gpg_signature | issued_at
----------|---------------------|----------|---------------|------------------
w-abc123 | validator-alice | true | -----BEGIN... | 2024-01-19 10:15:00When Witness moves to a different rig or network, they can prove:
- Clone hop-commons
- Query:
SELECT * FROM reputation_stamps WHERE recipient = 'rig-witness-001' - Verify GPG signatures offline (no network needed)
- Present stamps to new communities
The stamps are portable because they're in a version-controlled database, not locked in a platform.
Compare to: "I have a Dework profile with 47 completed tasks" (locked in Dework's server, not portable, could be edited or deleted).
No central authority can unilaterally change the data. Yes, DoltHub hosts the canonical copy, but:
- Anyone can run their own Dolt server
- Anyone can fork and diverge
- Consensus (merging) requires agreement
- The database is the source of truth, not the server
Everyone knows SQL. No special query language needed. Wasteland queries:
-- Find all claimed tasks from this rig
SELECT * FROM wanted_board
WHERE state = 'claimed' AND claimed_by_rig = 'hop-gamma';
-- Get all completed tasks with stamps
SELECT wb.id, wb.title, rs.issued_by_validator, rs.approval
FROM wanted_board wb
JOIN completion_records cr ON wb.id = cr.task_id
JOIN reputation_stamps rs ON cr.task_id = rs.task_id;
-- Audit trail for a specific task
SELECT * FROM wanted_board
WHERE id = 'w-abc123'
LIMIT 1;
dolt log -p wanted_board --where "id = 'w-abc123'"
-- Returns all commits that touched this rowJust like code reviews, work claims can be reviewed via PR before merging:
PR: hop-gamma wants to add 10 new tasks and mark 3 as completed
Proposed changes:
+ INSERT INTO wanted_board (...) VALUES (w-new-1, ...)
+ INSERT INTO wanted_board (...) VALUES (w-new-2, ...)
+ UPDATE wanted_board SET state = 'validated' WHERE id = 'w-abc123'
Reviewers: validator-alice, validator-bob
Status: Awaiting review
Validators can comment on rows:
> UPDATE wanted_board SET state = 'validated' WHERE id = 'w-abc123'
validator-alice: "Looks good, w-abc123 completed with solid tests. Approved."
validator-bob: "Reviewed the IRSB receipts, no disputes. Merging."
Human-reviewable data changes. This is unprecedented in coordination platforms.
Each rig works on its own branch:
main (hop-commons canonical)
├── hop-alpha/branch-1
├── hop-alpha/branch-2
├── hop-gamma/feature-branch
├── hop-delta/migration
└── ...
No cross-contamination. Each rig can work independently, merge when ready.
| Aspect | Postgres | SQLite | Dolt | Blockchain |
|---|---|---|---|---|
| Version control | No | No | Yes | Implicit (slow) |
| Fork & pull | No | No | Yes | No (state explosion) |
| Mergeable | No | No | Yes | No |
| SQL interface | Yes | Yes | Yes | No (custom languages) |
| Decentralized | No | No | Yes | Yes (but slow) |
| Offline work | Limited | Yes | Yes | No |
| Portable credentials | No | No | Yes (via Dolt history) | Yes (but expensive) |
| Merge conflicts resolved by | Humans + code | Humans + code | Humans + code + Dolt strategies | Humans + smart contracts |
| Cost | Hosting fees | Free | Free + DoltHub | Gas fees (expensive) |
Dolt is the only system that gives you distributed collaboration + version control + SQL + offline work + low cost.
Wasteland needs to support the work coordination flow while maintaining a decentralized, auditable record. Dolt enables:
- Rigs fork commons → Full autonomy, local changes
- Work claims stored in forks → Isolated until validated
- Validators review via PR → Human-reviewable data diffs
- Reputation stamps in Dolt → Portable, cryptographically signed
- Complete merge history → Immutable audit trail
- No central authority → Any rig can become a commons hub
Without Dolt: You need a centralized database (Postgres, MongoDB, etc.), which reintroduces the trust problem. You can't decentralize data while maintaining SQL queries + human-reviewable changes + version control + merge capabilities.
With Dolt: You get all of that for free.
Wasteland (Dolt)
│
└─> wl claim w-abc123
│
├─ Update SQL: wanted_board.state = 'claimed'
├─ Dolt commit: "Agent claims w-abc123"
│
└─> IRSB API: POST /irsb/escrow/lock
{
"task_id": "w-abc123",
"amount": "500",
"claimant": "0xwitness",
"challenge_window": 3600
}
│
├─ EscrowVault.lock() on-chain
├─ Event: EscrowLocked(...)
│
├─> IRSB Receipt #1 created
│ {
│ "receipt_id": "irsb-receipt-0001",
│ "type": "EscrowLock",
│ ...
│ }
│
└─> Watchtower monitoring begins
(1-hour challenge window)
Gastown (Molecule)
│
└─> execute step-1
│
└─> Moat API: POST /moat/authorize
{
"automaton_id": "rig-witness",
"task_id": "w-abc123",
"capability": "execute:command",
...
}
│
├─ Policy evaluation (5 rules)
│ ✓ Tenant whitelist
│ ✓ Budget check
│ ✓ Domain whitelist
│ ✓ Scope check
│ ✓ Approval required?
│
├─ Decision: ALLOWED
│ constraints_hash: 0xc3a9f8e2d1...
│
└─> LocalCLIAdapter executes command
│
├─ Command: analyze-rfc --file rfc-1234.md
├─ Exit code: 0
├─ Stdout: "Analysis complete..."
│
└─> Moat builds receipt
{
"receipt_id": "irsb-receipt-0002",
"type": "ExecutionStep",
"step_id": "step-1",
"exit_code": 0,
"cost_actual": "4.8",
"constraints_hash": "0xc3a9f8e2d1...",
"signature": "0x..."
}
│
└─> IRSB API: POST /irsb/receipt
│
├─ IntentReceiptHub.postReceipt() on-chain
├─ Event: ReceiptPosted(...)
│
└─> Watchtower monitoring begins
(1-hour challenge window)
Wasteland (Dolt)
│
└─> wl done w-abc123 --evidence "irsb-receipt-0002,..."
│
├─ Verify all receipts are finalized on-chain
│ for each receipt:
│ ✓ status == "finalized"
│ ✓ challengeWindowClosesAt < now
│
├─ Update SQL: completion_records INSERT
├─ Update SQL: wanted_board.state = 'submitted'
├─ Dolt commit: "Agent submits completion w-abc123"
│
└─> Validator reviews via PR
(human-reviewable data diff in DoltHub)
│
└─> wl stamp w-abc123 --approval
│
├─ GPG sign: "-----BEGIN PGP SIGNED MESSAGE-----"
├─ Update SQL: reputation_stamps INSERT
├─ Dolt commit: "Validator stamps w-abc123"
│
└─> IRSB API: POST /irsb/escrow/release
{
"escrow_id": "escrow-xyz789",
"approved": true,
"evidence": {...}
}
│
├─ EscrowVault.release() on-chain
├─ USDC transferred to 0xwitness
├─ Event: EscrowReleased(...)
│
└─> Reputation updated
SolverRegistry.setIntentScore()
IRSB (On-chain)
│
└─> Receipts finalized
├─ receipt-0002: success ✓
├─ receipt-0003: success ✓
├─ receipt-0004: success ✓
├─ receipt-0005: success ✓
│
└─> Reputation update
│
├─ IntentScore calculation
│ = 0.40 * success_rate
│ + 0.25 * dispute_win_rate
│ + 0.20 * stake_ratio
│ + 0.15 * longevity
│
├─ SolverRegistry update
│ rig-witness-001: IntentScore = 42.3
│
└─> ERC-8004 signals posted
{
"agent_id": "967",
"signal_type": "completion",
"task_id": "w-abc123",
"validator": "validator-alice",
"timestamp": 2024-01-19,
"score_delta": +0.5
}
┌────────────────────────────────┐
│ │
│ PORTABLE: Scout queries │
│ SolverRegistry on any chain │
│ to get rig-witness-001's │
│ reputation. Can route work │
│ based on on-chain signals. │
│ │
└────────────────────────────────┘
Scout Agent
│
└─> bounty.discover MCP call
{
"tags": ["rust", "async"],
"min_reward": 100,
"max_effort": 40
}
│
├─ Query Wasteland API: GET /api/wanted-board?...
│ ↓
│ Wasteland SQL query (Dolt):
│ SELECT * FROM wanted_board
│ WHERE tags CONTAINS 'rust'
│ AND tags CONTAINS 'async'
│ AND reward >= 100
│ AND effort_estimate <= 40
│
├─ Query SolverRegistry on-chain
│ Get Scout's own reputation
│ Get minimum reputation required for tasks
│
├─ Score candidates
│ Reward - effort_estimate
│ Time decay (deadline urgency)
│ Reputation match
│
└─> Return top 5 matches
[
{
"url": "dolt://hop-commons/w-abc123",
"title": "Implement Rust RFC-1234...",
"reward": 500,
"effort": 20,
"match_score": 0.92
},
...
]
Step 1: Work Completed in Wasteland (Dolt)
├─ wanted_board.state: submitted
├─ completion_records INSERT
├─ Dolt commit: "Agent submits completion"
Step 2: Validator Reviews & Stamps
├─ Validator reads IRSB receipt (on-chain, finalized)
├─ Validator reviews code quality
├─ Validator issues GPG-signed stamp
├─ Stamp stored in Dolt: reputation_stamps table
├─ Dolt commit: "Validator stamps w-abc123"
Step 3: Stamp is Now in Dolt History
├─ Anyone can query: SELECT * FROM reputation_stamps
│ WHERE recipient = 'rig-witness-001'
│
├─ Anyone can verify GPG signature:
│ gpg --verify <signature>
│ ✓ Signature by validator-alice@hop-commons.dolt
│ ✓ Timestamp: 2024-01-19T10:15:00Z
│
└─ Stamp is PORTABLE (no platform lock-in)
Step 4: IRSB Translates to On-Chain Signals
├─ Escrow released on-chain
├─ No disputes on any receipt
├─ All receipts finalized
│
└─> SolverRegistry.updateReputation()
├─ IntentScore calculation
├─ Emit event: ReputationUpdated(rig-witness-001, 42.3)
├─ Store in ERC-8004: agent_id=967, score=42.3
Step 5: Scout Uses On-Chain Reputation for Routing
├─ Scout needs to route new task
├─ Queries SolverRegistry (on-chain)
│ rig-witness-001: IntentScore=42.3, success_count=9
├─ Rig meets minimum threshold (20 IntentScore)
├─ Task offered to Scout
└─ Scout accepts and claims w-def456
Level | Title | IntentScore | Permissions
------|--------------|-------------|------------------------------------------
1 | Drifter | 0-10 | Browse, claim tasks, submit completions
2 | Settler | 11-30 | Larger tasks ($200+), higher effort
3 | Warrior | 31-60 | Can validate other agents' work
4 | Imperator | 61-100 | Can set policies, approve rigs
5 | Legend | 100+ | Leaderboard, community reputation
Scenario: Witness moves from hop-gamma to hop-delta
Old rig (hop-gamma):
dolt log reputation_stamps --where "recipient = 'rig-witness-001'"
commit a1b2c3d4
Author: validator-alice <alice@hop-commons>
Date: 2024-01-19 10:15:00
Validator validator-alice stamps w-abc123 with approval
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
recipient: rig-witness-001
task: w-abc123
approval: true
...
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE...
-----END PGP SIGNATURE-----New rig (hop-delta):
Witness runs:
dolt clone dolt/hop-commons
dolt query "SELECT * FROM reputation_stamps
WHERE recipient = 'rig-witness-001'
ORDER BY issued_at DESC LIMIT 10"Returns:
task_id | issued_by | approval | gpg_signature | issued_at
----------|-----------|----------|---------------|------------------
w-abc123 | val-alice | true | -----BEGIN... | 2024-01-19 10:15:00
w-xyz789 | val-bob | true | -----BEGIN... | 2024-01-18 15:22:00
w-def456 | val-alice | true | -----BEGIN... | 2024-01-16 09:45:00
...
Witness presents these stamps to hop-delta's community:
"I have 10 GPG-signed stamps from validators in hop-commons.
Here are the signatures, verify them yourself:
-----BEGIN PGP SIGNED MESSAGE-----
...
-----END PGP SIGNATURE-----
"
hop-delta can verify immediately (offline, no network needed). Reputation is portable because it's in a version-controlled database, not locked in a platform.
| Aspect | Before (Honor System) | After (Accountability Stack) |
|---|---|---|
| Work claims | Self-reported, unverified | Escrow locked on-chain immediately |
| Execution proof | None, "trust me" | Cryptographic receipt (EIP-712 signed) |
| Proof visibility | Black box, only platform sees | GraphQL queryable, on-chain finalized |
| Policy enforcement | None, open access | Default-deny, 5-rule engine |
| Policy violations | No consequences | Execution rejected, boundary enforced |
| Reputation | Manual reviews, closed system | GPG-stamped + on-chain IntentScore |
| Reputation portability | Platform lock-in | Dolt history + ERC-8004 signals |
| Disputes | Manual, slow, subjective | 1-hour auto-challenge window |
| Dispute resolution | Admin intervention | Watchtower automated + on-chain slashing |
| Bad actor consequences | None, walk away | Bond slashing (80/15/5), 3 jails = ban |
| Data portability | Export CSV, start over | Fork Dolt, bring reputation history |
| Federation | Centralized platforms | Fork-based, PR workflow for data |
| Observability | Black box | Gastown molecules, real-time Viewer |
| Audit trail | Logs (if any) | On-chain receipts + Dolt history |
| Off-chain data | Platform databases | Version-controlled, mergeable SQL |
| Work coordination | Manual (Slack, email) | Automated (Scout routing, Gastown tracking) |
Why nobody else has built this:
- What it does: Batch auctions for token swaps, MEV-minimized
- Why not for work: Finance-only, no work coordination, no proof of execution steps
- Missing: Gastown (orchestration), Wasteland (work posting), Reputation
- What it does: Bounty board + Slack integration
- Why not sufficient: Manual task management, no cryptographic proofs, no on-chain accountability
- Missing: IRSB (escrow), Moat (policy), Reputation portability
- What it does: Agent framework with on-chain rewards
- Why not sufficient: Agent-centric, no work coordination layer, no human-readable work posting
- Missing: Wasteland (work posting), Gastown (orchestration), Dolt (federation)
- What it does: Compute marketplace
- Why not sufficient: Infrastructure-focused, not work coordination, no accountability for deliverables
- Missing: Wasteland, Reputation, Gastown, IRSB escrow
- What it does: Grant platform + bounty board
- Why not sufficient: No automated policy enforcement, no cryptographic execution proofs, bounties still honor-based
- Missing: Moat (policy), IRSB (receipts), Dolt (federation)
No competitor has all 5 systems working together:
- Federated data (Dolt) — Fork-based collaboration
- Policy enforcement (Moat) — Default-deny 5-rule engine
- Cryptographic receipts (IRSB) — EIP-712 signed execution proofs
- Automated monitoring (Watchtower) — 1-hour challenge windows, no manual intervention
- Portable reputation (ERC-8004) — GPG stamps + on-chain IntentScore, cross-platform
The combination is the moat. You can't remove one piece without losing the accountability loop.
- AgentKit (Coinbase): Agents with token transfer capability
- ElizaOS: Autonomous agents with persistent memory
- Autonolas: Agent swarms, multi-agent coordination
- Virtuals: Agent tokens, agent-to-agent payments
Agents are no longer just inside applications. They're economic actors with wallet access and autonomous decision-making.
There is no standard for "how do I verify that an AI agent did what it promised?" Responses:
- "Check the logs" (opaque, could be edited)
- "Trust the platform" (centralized, can be compromised)
- "Look at the code" (doesn't guarantee execution)
The accountability stack fills this gap.
An agent doesn't have one employer anymore. It might:
- Claim tasks on Bounty Board A
- Execute with policy enforcement from Moat
- Post receipts to IRSB
- Move reputation to Bounty Board B
This is the "agent economy" — agents as independent contractors working across multiple platforms.
When one agent depends on another agent's work (Witness's analysis feeds into Polecat's implementation), both need cryptographic proof that the dependency was actually satisfied.
Moat receipts + IRSB finalization provides this.
Dolt is the only database that combines:
- Version control (git-like) for SQL data
- Fork-based federation (distributed collaboration)
- Mergeable databases (conflict resolution)
- SQL interface (everyone knows it)
- Portable data (no platform lock-in)
No blockchain can do this efficiently. No centralized database can do this without losing decentralization.
Now is the moment to build the federation layer (Dolt) that enables the agent economy to scale with accountability.
- Wasteland (Dolt): wanted_board, rig_registry, completion_records, reputation_stamps
- Gastown: molecules, steps, basic Viewer
- Moat: 5-rule engine, Stub adapter, receipt builder
- IRSB: EscrowVault, IntentReceiptHub, basic watchtower
- Scout: bounty.discover MCP tool
- DoltHub integration (public fork/PR workflow)
- Dolt merge strategies for conflict resolution
- Multi-rig coordination
- Reputation portability (GPG stamps + ERC-8004)
- Additional Moat adapters (Slack, CLI, HTTP, OpenAI, Web3)
- Watchtower automated dispute filing
- Bond slashing implementation
- SolverRegistry on L2 (Arbitrum / Optimism)
- GraphQL indexing (Envio)
- Partner integrations (GitHub, Algora, Gitcoin)
- Agent SDKs (ElizaOS, AgentKit, Virtuals)
- Community validators & reputation providers
- Cross-chain reputation proofs
On-chain Gastown + Wasteland is the complete accountability loop for AI agent work coordination.
It's not just about payment. It's about:
- Cryptographic proof that work was done
- Portable reputation across platforms
- Decentralized federation via Dolt
- Automated policy enforcement via Moat
- Zero trust architecture for agents
Dolt is the critical primitive that makes this work. It's the only system that enables distributed collaboration on structured data while maintaining complete audit trails and enabling portable credentials.
The agent economy is coming. The question is: will it run on trust, or on cryptographic accountability?
We're building the infrastructure for the latter.
An observable unit of work. Composed of steps. Tracked by Gastown in real-time. Example: mol-rust-1 with 4 steps (analyze, design, implement, test).
React dashboard + TUI for real-time work progress tracking. Shows molecules, steps, budget allocation, execution timeline, all 5 receipt types.
Cryptographic proof of an action (escrow lock, execution step, dispute, slashing). EIP-712 signed, posted on-chain, subject to 1-hour challenge window.
Automated monitor for IRSB receipts. Files disputes automatically if policy violations are detected. Finalizes receipts after challenge window expires.
A controlled execution environment running an agent (or team of agents). Has identity (rig_id), stakes bonds, builds reputation, forks Dolt databases.
Dolt table tracking all rigs: rig_id, agent_ids, claim_count, reputation, stake, jails.
Intelligent broker agent. Discovers bounties, routes to rigs, uses ERC-8004 reputation to match tasks to agents.
On-chain agent identity standard. Stores IntentScore (reputation), success counts, dispute history, portable signals.
Smart contract storing reputation for all rigs/agents. IntentScore calculated from 4 signals: success rate, dispute wins, stake ratio, longevity.
Dolt table storing all posted work. Fields: title, description, effort_estimate, reward, tags, state (open/claimed/submitted/validated), escrow_amount.
Dolt table storing submitted work. Fields: task_id, completed_by_rig_id, completed_by_agent_id, submitted_at, evidence_receipts (list of IRSB receipt IDs), notes, state (submitted/validated).
Dolt table storing GPG-signed validator approvals. Fields: task_id, issued_by_validator, approval (bool), gpg_signature, issued_at.
Smart contract holding locked funds. Lock on task claim. Release on completion + validator approval. Slashed if policy violations occur.
Document Status: Ready for Dolt team, Steve Yegge, and network founders.
Last Updated: 2024-01-19
Word Count: ~8,500 (excluding code examples and diagrams)