Human + Agent Operations

How Gridz Works

Understand the COMP market, place or provide compute, follow every verification and settlement boundary, and operate Gridz through the browser, WebMCP, typed MCP, or HTTP.

Six boundaries

How It Works

Gridz turns heterogeneous compute into verifiable COMP products. Each product is bound to one workload, meter, capability class, and proof policy; orders clear in batches and native XEC moves only through the job's exact escrow contract.

Buyer Or Agent
MCP client, phone, laptop, or automation
Gridz Matchmaker
FBA clearing, registered workload routing, escrow intents
Provider Compute
Local execution, receipts, proof artifacts
01

Discover

Select an active COMP product. Confirm its workload ID, meter version, definition digest, input boundary, verifier, and provider capability requirements.

02

Authorize

Connect a wallet or establish a proof-backed participant session. Browser and agent requests remain bound to the exact deployment origin and role.

03

Clear

Submit a bounded bid or capacity offer. The batch auction matches only orders with the same product binding and conserves price, quantity, and capacity.

04

Fund

A matched job receives a canonical funding deadline and native-XEC escrow intent. Execution authority opens only after funding is independently observed.

05

Execute + verify

The provider runs the registered local executor and returns manifest-bound artifacts. The verifier checks output, metering, provenance, and proof policy.

06

Settle

Proposal-bound signatures release or refund the exact escrow transaction. Finality reconciliation remains reorg-aware and fail-closed.

COMP Protocol
microCOMP

Canonical fixed-point compute accounting across capability classes, topology, reservations, auctions, receipts, and settlement events.

Product Registry
No remote code

Buyers choose audited workload IDs and input commitments. Providers run local implementations rather than buyer-supplied code.

Native XEC escrow
2-of-3

Matched fills bind buyer and provider escrow public keys before payment metadata is created.

Buyer Flow

Buy Compute

A buyer discovers an active COMP product, submits a bounded bid, funds escrow after a canonical match, and verifies the provider receipt before treating work as complete.

1

Discover products

Read `list_workloads` or `GET /api/workloads` and select an active registered workload with an admitted COMP meter and verifier.

2

Submit a bid

Call `submit_bid` with whole `comp`, exact `maxPriceSatsPerComp`, workload ID, and input commitment. Keep executable payloads out of the market.

3

Fund escrow

After the fill exposes canonical provider settlement identity, call `fund_escrow` and pay the exact native-XEC funding amount to the generated eCash address.

4

Verify proof

Poll `get_job_result`, then call `verify_proof`. Release decisions should stay fail-closed until receipt fields match the workload contract.

Buyer MCP
list_workloads()
submit_bid({
  buyerId: "<buyer escrow pubkey>",
  comp: 4,
  maxPriceSatsPerComp: "546",
  workloadId: "gridz.reference.sha256-chain/v1",
  inputCommitment: "sha256:..."
})
fund_escrow({ bidId, buyerPubkey, providerPubkey, buyerRefundAddress })
verify_proof({ jobId })
Provider Flow

Sell Compute

The browser seller actively executes the audited reference SHA-256 workload. CPU, GPU, ZK, TEE, and custom lanes are registered and routable, but a provider must operate an audited executor and verifier path before advertising one of those workloads.

1

Quote one workload

Call `quote_provider_capacity` to detect or submit capability metadata, then select a registered workload backed by an audited executor you operate.

2

Advertise one tranche

Call `submit_ask` with one product-specific capacity tranche, its capability descriptor, minimum XEC per COMP, telemetry evidence, and settlement profile.

3

Poll funded jobs

Use `list_provider_jobs` with your provider token. Execute only assignments whose escrow state is funded and whose workload ID matches that tranche.

4

Execute and attest

Run the audited local implementation, then call `submit_job_artifacts` with its canonical meter and proof fields. The browser journals the job before this boundary so response loss is recoverable.

5

Sign and recover payout

Reload the exact durable release coordination, validate its complete funding, script, payout, fee, and job binding, submit only the provider signature, then retry broadcast and finality after an independent second role signs.

Provider MCP
const registry = list_workloads()
const workload = registry.workloads.find(w => w.marketStatus === "active")
const meter = get_workload_meter({ workloadId: workload.workloadId })
const quote = quote_provider_capacity({ providerId })
submit_ask({
  providerId: "<provider escrow pubkey>",
  comp: quote.recommendedOfferComp,
  minPriceSatsPerComp: "546",
  workloadId: workload.workloadId,
  meterVersion: meter.meterDefinition.meterVersion,
  meterDefinitionDigest: workload.meterDefinitionDigest,
  capabilityDescriptor: quote.capabilityDescriptor,
  settlementProfile: { schemaVersion: "gridz.provider-settlement/1", escrowPubkey, payoutAddress }
})
list_provider_jobs({ providerId })
submit_job_artifacts({ jobId, providerId, workloadId, meterVersion, meterDefinitionDigest, inputCommitment, outputHash, gasUsed, vmVersion })
create_escrow_spend({ intentId: settlementIntentId, jobId, participantRole: "provider", providerId, operation: "release" })
submit_escrow_spend_signature({ coordinationId, jobId, providerId, signatureResponse: providerWalletSignature })
reconcile_escrow_spend({ coordinationId, jobId, participantRole: "provider", providerId })
Agent API

WebMCP In Browser, Typed MCP For Automation

An agent in a WebMCP-compatible browser can inspect the live market, prepare a buy or sale, and read activity without guessing selectors. Prepared intents never mutate orders, escrow, wallets, or settlement until the visible confirmation boundary. Autonomous services should use the 25 typed MCP tools and 2 read-only resources.

Browser market
get_gridz_market

Read the live price, COMP product binding, market statistics, and current workflow state.

Browser intents
prepare_compute_buy, prepare_compute_sale

Prepare an exact bounded intent; inspect it in the page and explicitly confirm or cancel it.

Browser activity
get_gridz_activity

Read current workflow and pending-intent state without scraping the rendered interface.

Typed market tools
get_spot_price, get_orderbook, list_workloads

Read current price, book depth, and product registry before submitting an order.

Buyer tools
submit_bid, fund_escrow, get_job_result, verify_proof

Create demand, escrow payment, inspect result state, and verify artifacts.

Provider tools
quote_provider_capacity, submit_ask, list_provider_jobs, submit_job_artifacts, set_pricing

Quote one workload-specific tranche, process funded work, submit receipts, and tune pricing.

Resources
gridz://market/spot-price, gridz://market/orderbook

Read-only MCP resources for agents that need cheap market context.

Open the live COMP control interface →
Remote MCP
{
  "mcpServers": {
    "gridz-compute": {
      "url": "https://mcp.46.225.106.23.sslip.io/mcp",
      "headers": { "Authorization": "Bearer <GRIDZ_MCP_HTTP_API_KEY>" }
    }
  }
}
Security

Trust And Execution Boundaries

Gridz is permissionless at the market layer, but the execution contract remains narrow. The public surface is designed so anonymous agents can trade without gaining remote-code execution or unauthorized participant access.

Registered workloads only

Orders carry workload IDs and input commitments, not arbitrary code blobs.

Participant-scoped sessions

Matched bids and offers return buyer/provider tokens used for protected reads and mutations.

Escrow before artifacts

Providers submit artifacts only after escrow is funded for the canonical matched job.

Verifier fail-closed

Proof status stays invalid until output, receipt, gas, and workload metadata satisfy the registered contract.

Source Of Truth

Canonical References

How it works is the operational entry point. Agents that need exact route semantics, deployment policy, or verifier trust material should read the repository docs and machine-readable discovery artifacts. Compatibility wire fields retain their version-2 names until the ratified COMP migration; they are transport fields, never a second market architecture.

server.json

MCP registry descriptor for the Gridz server package.

chatgpt-app-submission.json

Agent-app review metadata and public install surface.

docs/mcp-server-reference.md

Exact MCP tool behavior, resources, and auth boundaries.

docs/api-reference.md

HTTP routes, WebSocket events, proof status, and settlement flows.

docs/agent-environment.md

Runtime bootstrap and non-local deployment environment requirements.

docs/architecture.md

System-level market, escrow, provider, and verifier architecture.