Scale

Delegate bounded authority to an AI agent so it can discover, buy, and consume services on your machine’s behalf.

Scale is paused. Registering a machine with the Machine Markets API fails for every machine right now. For a Tokenomics 1.0 machine, the orchestrator looks up its did:peaq:0x<address> DID on mcr.peaq.xyz, which does not serve that DID format, so machine-bound calls return 503 PEAQOS_IDENTITY_UNAVAILABLE. For a machine activated under Economics 2.0, the SDKs refuse identity-binding orchestration calls on a tokenomics20 client with TokenomicsIntegrationUnavailableError. Catalogue reads over HTTP still answer: GET /skills, GET /market/services and GET /market/adapter-credential-stack.

Scale pairs an AI agent to an activated, bonded machine and gives it delegated authority over the machine’s wallet, bounded by spend limits and an allow/denylist. The agent discovers, buys, and consumes services through the Machine Markets API. The agent is provisioned outside peaq; pairing, policy, discovery, ordering, payment, and execution happen through peaqOS.

It uses the machine’s identity from Activate, an optional smart account for delegated spending, and the credit signal from Qualify. The machine’s MCR and trust level carry through to providers when the agent buys.

What ships

Component	Description
Machine Agent pairing	Bind a third-party AI agent (Claude, OpenAI, Virtuals, Teneo, etc.) to a machine via a signed EIP-191 challenge. peaqOS verifies the signature, persists the agent’s identity and verification metadata, and issues a signed HS256 session JWT (pairingToken) the agent presents as x-agent-pairing-token on market writes. Tokens rotate via a sessions endpoint.
Delegation policy	Per-transaction limit, daily spend limit, currency, and allowed/denied skill keys and service IDs. Enforced server-side on every market call. Policy changes invalidate the session token’s delegationPolicyHash; rotate after a PATCH.
Skill registry and service catalogue	Curated capabilities (oracle.price-feed, compute.marketplace, compute.confidential, storage.object, data.location, identity.proof-of-person, device.control, machine.commerce, network.partner-console) and the concrete provider services that fulfil them.
Market search	POST /market/search takes machine context, requirements, region, budget, and execution preferences and returns ranked MarketQuotes with reasons.
Market orders	POST /market/orders locks a service from a quote into an order with state machine created → payment_pending → ready → executing → delivered → confirmed (or disputed / cancelled / failed / handoff). Server-side policy and spend checks fire on create.
Payment intent and escrow	payment-intent selects a rail; payment-proof records or RPC-verifies on-chain payment; payment/escrow-lock, payment/release, payment/refund cover the escrow lifecycle. Solana proofs are recorded; EVM proofs verify via RPC against the ERC-20 Transfer log.
Execute and runtime endpoints	POST /market/orders/:orderId/execute materialises the order as a task plus route, dispatches to a native provider or a machine-side runtime endpoint registered via PUT /machines/:machineId/runtime-endpoints/:providerKey or heartbeated by an on-machine runtime agent, and writes a Run and Outcome.
Confirm and dispute	POST /confirm closes the order and moves held payment to release_pending; POST /payment/release records the release once the rail has settled. POST /dispute opens a dispute record and freezes payment. Pairings with non-terminal orders cannot be revoked (OPEN_MARKET_ORDERS).
Machine identity proof	DID-controller challenge and EIP-191 signature flow that ties orchestration writes to the on-chain machine identity.

How it works

1. Activate the machine. Pairing needs an active, bonded machine whose identity the orchestrator can resolve through the MCR API. Registration is paused for both Tokenomics 1.0 and Economics 2.0 machines (see the warning at the top of this page). A smart account (deploySmartAccount) is optional and only needed for delegated spending. See CLI: Scale setup.
2. Prove identity ownership. POST /machine-identity/challenges returns a message that the DID-controller key signs (EIP-191). The signed proof is attached when the machine is registered with the orchestration service.
3. Provision a Machine Agent. Get an agent from any provider you trust: Claude, OpenAI, Virtuals, Teneo, your own runtime. peaq does not provide the agent.
4. Pair the agent. Pairing is challenge-based.
   1. POST /machines/:machineId/agent-pairings/challenges with the agent’s agentAddress, agentProvider, agentRole, and optional agentDid. The response is an AgentPairingChallenge with challengeId, message, and expiresAt.
   2. The Machine Agent signs message (EIP-191 personal_sign) with the wallet key behind agentAddress.
   3. POST /machines/:machineId/agent-pairings with agentProof: { challengeId, signature } and the delegation policy. The orchestrator verifies the signature, persists the pairing with verification metadata, and returns the AgentPairing with a signed session JWT in pairingToken. Store it client-side and send it as x-agent-pairing-token on market writes.
   4. Tokens expire (default 1 hour). Rotate by issuing a fresh challenge and calling POST /machines/:machineId/agent-pairings/:pairingId/sessions with the new proof. Rotate after any PATCH to the delegation policy.
5. Search the market. The agent calls POST /market/search with machine context, service type, capabilities, region, budget, and optional providerCredentials. The orchestrator returns ranked MarketQuotes with reasons for each ranking.
6. Place an order. POST /market/orders with machineId, agentPairingId, serviceId, and optional searchId + quoteId creates an order (status created). The orchestrator enforces the delegation policy and per-transaction and daily spend limits at create. The recommended payment rail is copied from the service into order.payment.
7. Settle payment. POST /market/orders/:orderId/payment-intent mints a payment record on the chosen rail. For wallet-based rails, submit POST /payment-proof after the on-chain transfer (EVM proofs are RPC-verified against the ERC-20 Transfer log). For the x402 rail there is no buyer transfer: the agent wallet signs the provider’s payment challenge and the signed header is the proof; the provider is paid during execute. For escrow rails, call POST /payment/escrow-lock with the on-chain lock transaction. Once funds clear, the order moves to ready.
8. Execute. POST /market/orders/:orderId/execute materialises the order as a task plus route, dispatches to a native provider or a machine-side runtime endpoint, and writes a Run plus an Outcome. Successful runs land in delivered. External-handoff services return a structured handoff and land in handoff.
9. Confirm or dispute. POST /market/orders/:orderId/confirm closes the order and moves held funds to release_pending. Settle through the payment rail, then call POST /market/orders/:orderId/payment/release to record the release (the endpoint updates the payment record, it does not move funds). If the service did not deliver, POST /market/orders/:orderId/dispute opens a dispute and freezes payment until peaq resolves it.

Read-only shortcut

Free, read-only operations can skip the order flow entirely. POST /market/services/:serviceId/execute runs the operation directly with machineId, agentPairingId, operation, and optional input / providerCredentials. The orchestrator dispatches through the same task + route + run + outcome machinery as executeMarketOrder but does not create an order, payment intent, or escrow record. Paid, external-handoff, and state-changing operations still go through POST /market/orders.

Payment model

peaqOS does not collect marketplace payments. The payment-intent and payment-proof endpoints record provider/service payment state only when the selected adapter requires direct provider payment. Operators or machines pay the selected provider directly through that provider’s supported rail. Raw payment headers are never stored.

Payment rails

The orchestrator quotes services in the rail the provider supports. Active rails:

Rail	Where it shows up
x402	Some agentic.market services (2Captcha, Firecrawl, Wolfram|Alpha), the Acurast Deploy Agent and pay.sh StableUpload. Agent wallet responds to an HTTP 402 payment-required challenge; orchestrator replays the request with the agent’s payment headers via the paidHttp adapter.
mpp	Solana micro-payment protocol. The main paid rail for pay.sh services.
vault-stripe / external	Card-mediated or external handoff.
wallet / wdk-usdt-transfer	Direct USDT transfer on peaq (default token USDT, decimals from PEAQOS_USDT_DECIMALS).
onchain-escrow / escrow	Funds locked into a service-specified escrow contract via payment/escrow-lock.
not-required	Free or pre-authorised services. Order proceeds straight to ready.
offchain-record	Off-chain attestation, recorded but not RPC-verified.

The orchestrator does no cross-chain or token conversion: the agent pays in the chain and token the service quotes.

Service providers

• QVAC: private inference.
• agentic.market: 2Captcha, Firecrawl and Wolfram|Alpha over x402; Claude, ChatGPT and Exa as external handoffs.
• pay.sh: Gemini, BigQuery, Document AI, StableUpload, Cloud Translation.
• Akash: decentralized compute.
• Aethir: decentralized GPU compute.
• Acurast: decentralized compute; its Deploy Agent runs as a native x402 provider runtime in the orchestrator.
• Arcium: confidential compute (compute.confidential).
• GEODNET: RTK precision-positioning data.
• Naver Maps: mapping and geolocation APIs.
• Korea Public Data (Data.go.kr): EV charging stations and chargers, next-hour weather, and AirKorea PM2.5. Needs a portal service key, sent with every request and never stored.
• World ID: proof of personhood (identity.proof-of-person).
• Walrus: object storage.
• Home Assistant: device control on the machine’s local network, on a self-hosted orchestrator configured with HOME_ASSISTANT_BASE_URL and HOME_ASSISTANT_TOKEN.
• Aave: treasury deposits.
• peaq Telemetry Export: fleet telemetry export and machine data publishing.

The live catalogue is on robotic.sh; query it programmatically via GET /market/services and market search. The adapter registry (GET /market/adapter-credential-stack) is the authoritative list of what needs credentials or setup.

Delegation policy

type DelegationPolicy = {
  allowedSkillKeys: string[];   // skill keys from GET /skills, e.g. ["walrus-storage-object", "akash-compute-deployment"]
  deniedSkillKeys: string[];
  allowedServiceIds: string[];  // exact service IDs from /market/services
  deniedServiceIds: string[];
  perTransactionLimit?: number | null;
  dailySpendLimit?: number | null;
  currency?: string | null;     // ISO 4217 or token symbol
};

Policy is enforced server-side on every call. Update it at any time via PATCH /machines/:machineId/agent-pairings/:pairingId. Revoking a pairing (DELETE) terminates the agent’s delegated access immediately, unless the pairing has open market orders (OPEN_MARKET_ORDERS).

Multichain

peaqID, Machine NFT, and the Service Registry stay canonical on peaq. Machine NFTs bridge between peaq and Base mainnet (chain ID 8453, LayerZero endpoint ID 30184). Agung and Base Sepolia are the satellite chains for the Lite mirrors. Machine Agents pay across chains using the chain and token a service quotes in.

A Signer Daemon fleet mirrors finalized peaq state onto per-chain Lite contracts (DIDLite, IdentityLite, StakingLite). Read the Omni-chain concept for the architecture and the roadmap for chain rollout.

Build with Scale

Machine Markets API

Base path, access model, error codes, and the full HTTP endpoint surface.

Machine Markets (concept)

How pairing, skills, services, orders, payments, and execution hang together.

peaqOS CLI: scale

peaqos scale agent pair, search, and the order family from your terminal.

SDK: orchestration namespace

client.orchestration for JS and Python.

Related

• Activate
• Qualify
• Wallets (OWS)