Physical Capability Cloud

Send a per-kernel heartbeat to keep the kernel marked online. Used by pcc-node daemons as an alternative to the operator relay heartbeat.

List all active API keys for the authenticated operator. Returns key IDs, prefixes, scopes, rate limits, usage counts, and creation/expiry timestamps. Requires a valid API key or SIWE session.

List automation status for all instrument transfer pairs. Shows current automation level, episode count, and training readiness. Filter by kernelId.

List active and completed settlement batches.

List open bounties for capabilities the network needs. Operators can claim these to earn rewards by onboarding new capabilities.

List all capability types registered on the network (FDM, SLA, CNC, HPLC, etc.) with metadata.

List agent-to-agent conversations showing topic, participants, message count, and status.

List escrow contracts with milestones and bonds. Optionally filter by status.

List encrypted evidence bundles stored in the gateway.

List all evidence access grants for an address. Returns bundles the address has been granted access to.

List all jobs with status. Optionally filter by kernelId or status.

List all Shop Kernels on the network with status and capability types. Optionally filter by status.

List every channel attached to an operator. Returns the full channel records (id, transport, direction, endpoint, describe, enabled flags). Useful for an operator's onboarding agent to confirm what is wired up, and for status dashboards.

List all investment pools. Optionally filter by status or capability type.

List protocol runs. Filter by status or kernelId.

List protocol templates in the library. Filter by tags, required capabilities, search query, or status.

List all machine registrations on the network. See pending, approved, active, and rejected registrations. Public endpoint — no auth required.

List all transfer agents (robots and human operators) available for instrument-to-instrument transfers.

Decrypt a Lit Protocol-encrypted evidence bundle using a Lit auth signature. Returns the decrypted bundle payload.

List all supplies and materials marketplace categories with the count of active listings in each. Categories cover the full spectrum of physical production inputs: raw metals, plastics, lab reagents, consumables, electronics, tooling, and more.

Create a new supplies/materials listing in the marketplace. Suppliers post available raw materials, lab reagents, tooling, or consumables for other operators to purchase.

Remove a supplies/materials listing from the marketplace. The listing is immediately hidden from search results.

Get full details of a specific supplies/materials marketplace listing by ID. Returns pricing, availability, lead time, location, and tags.

Get details of a specific supply order including the associated listing details, quantity, total price, status, and optional escrow address.

Search and filter supplies/materials marketplace listings. Operators buy raw materials here to fulfill capability contracts. Filter by category, in-stock status, location, or free-text query.

List marketplace supply orders. Filter by buyerId, sellerId, or status. Returns order history with pricing and status.

Place a purchase order for supplies or materials. Calculates total price automatically (quantity × pricePerUnit). Returns an order with 'pending' status. Optionally links to an on-chain escrow for trustless settlement.

Update an existing supplies/materials listing (price, stock status, description, etc.). Pass only the fields you want to change.

Find hosting spaces that match specific machine requirements (voltage, area, etc.). Returns scored matches.

Mint a soulbound capability certificate (cNFT via Metaplex Core) for a kernel. Proves a verified capability on-chain as an immutable credential. Step 5 of onboarding.

Submit a cross-chain payment intent to the NEAR 1Click solver network. Creates a signed intent that routes the payment atomically across chains. Call near_quote first to obtain a quoteId. Intents typically settle within 30-60 seconds — poll near_intent_status to track progress.

Check the settlement status of a submitted NEAR 1Click cross-chain payment intent. Statuses progress: pending → submitted → settled | failed. Returns txHash and explorerUrl when settled.

Get a cross-chain payment quote from the NEAR 1Click solver network (chaindefuser.com). Provides optimal routing and fee estimates for funding PCC escrow contracts using any source asset on any supported chain. Call near_status first to confirm available chains/assets.

Get NEAR Protocol chain-abstraction integration status. Returns supported chains (near, eth, base, arbitrum, optimism, polygon), supported assets (USDC, USDT, NEAR, ETH, WBTC), and capability flags. Use this to confirm cross-chain settlement is available before requesting quotes.

Register a new machine on the PCC network. Provide machine details to create a registration record. Include `operator` ({walletAddress, displayName, email}): without it the registration is recorded as operator 0x0000000000000000000000000000000000000000 / "Unknown", and prove cannot match it to you.

Operator sends heartbeat with capability re-announcement. Keeps the kernel alive on the network and updates its own capability rows. Requires operate authority for this kernel: its recorded operator identity (the caller that registered it), its proven operator wallet, or the gateway admin authority. Another identity gets 403; no credentials gets 401; an unregistered kernel gets 404 for a non-admin. Operator identity proof for operate is completed by WP-A (DECISIONS items 136 and 138).

Operator polls jobs assigned to their kernel; status defaults to queued, and the route can filter any status. Requires operate authority for this kernel: its recorded operator identity (the caller that registered it), its proven operator wallet, or the gateway admin authority. Another identity gets 403; no credentials gets 401; an unregistered kernel gets 404 for a non-admin. Operator identity proof for operate is completed by WP-A (DECISIONS items 136 and 138). The pcc-node 0.1.1 daemon does not call it: it takes no jobs.

Operator pushes evidence bundle from a completed job execution. Requires decide authority for the stored job's kernel: its proven operator wallet or the gateway admin authority. A matching claimed operator key gets 403 operator_proof_required. Evidence takes decide, per DECISIONS 2026-10-04 01:25 (N31c). Evidence is posted with the kernel's proven operator wallet authority (decide). The body's kernelId cannot choose the authorization target. No credentials gets 401 before the job read; a job without a kernel gets 403 for a non-admin. Contains device ID, execution timestamp, result payload, and event timeline. Success is a receipt with stored: true naming this jobId. HTTP 200 with stored: false means nothing was stored: never follow it with status completed.

Operator reports a job's status (in_progress, completed, failed). Requires operate authority for the stored job's kernel: its recorded operator identity (the caller that registered it), its proven operator wallet, or the gateway admin authority. The body's kernelId cannot choose the authorization target. Another identity gets 403; no credentials gets 401 before the job read; a job without a kernel gets 403 for a non-admin. Operator identity proof for operate is completed by WP-A (DECISIONS items 136 and 138). The node path finishes a job in two calls: submit its evidence (POST /api/operator/evidence, posted with the kernel's proven operator wallet authority, decide), and only if that receipt says stored: true for this jobId, set status completed here. HTTP 200 alone is not enough: the relay answers 200 with stored: false when it could not store the evidence (an unknown job, a storage failure); then set failed with the reason evidence_not_stored. On the current gateway, completed marks the job done and its timeline then says settled, but the escrow is not released yet (board G1). Do not call pcc_job_complete after this: it answers 409.

Pause a running protocol run. Use resume_protocol_run to continue.

Pay royalties to an IP asset vault. The payer sends tokens that flow to stakeholders via the royalty splits.

Assign an operator to a specific capability node within a request. The node status changes to 'assigned'. Operators claim nodes to indicate they will execute that capability.

Get the latest camera frame from a kernel as a JSON snapshot (base64 JPEG + metadata). For raw JPEG image, use GET /api/ot2/camera/latest directly.

Cancel a capability request. Cancelled requests cannot be updated, decomposed, or published. This is a soft delete — the request remains visible with status 'cancelled'.

Anchor a PASS + anchor-candidate capture verdict to CaptureClassRegistry on-chain (Base Sepolia by default). Rejects FAIL/PARTIAL verdicts. Idempotent — re-submitting the same verdictId returns the existing anchor row. Returns 202 {status:'deferred'} if CaptureClassRegistry is not yet deployed (CAPTURE_REGISTRY_ADDRESS unset).

Issue a fresh block-anchored CaptureNonceChallenge for a job. The operator's device must render this nonce into the captured media (QR code, audio tone, etc.) before calling pcc_capture_upload. The nonce is derived from (challengeId, latest blockHash, workOutputRoot) so captures cannot be pre-computed. Returns challengeId, 64-char hex nonce, blockNumber, maxAgeSeconds (clamped to 120).

Look up a capture's on-chain anchor record in CaptureClassRegistry by its 32-byte captureHash. Returns the registry address, captureHash, and decoded anchor tuple (declaredClass, verifiedClass, manifestHash, submittedBy, jobId, challengeId, blockAnchor, capturedAt, attestationsRoot, attesterCount). onchain is null if the capture was never anchored. Returns 202 deferred when CaptureClassRegistry is not yet deployed.

Fetch the combined verdict + on-chain anchor view for a single capture. Mirrors the verifier's DB shape plus the anchor tx metadata (txHash, blockNumber, gasUsed, explorerUrl). Anchor is null if the verdict was never anchored.

Upload a capture (photo / video / audio / sensor clip) with its CaptureManifest for G1..G6 verification. Bytes are base64-encoded inline; optional base64 C2PA manifest bytes can be supplied for CC3+ claims. The server runs the 6-gate CaptureVerifier and persists a PASS/PARTIAL/FAIL verdict. Returns {verdictId, verdict, verifiedClass, gatesPassed, gatesFailed, warnings, anchorCandidate, captureHash, manifestHash}.

Get chat history with a kernel. Returns messages between agents, operators, and users for a specific kernel.