Machine Markets

​

Roles

​

Core objects

type Machine = {
  id: string;
  displayName: string;
  status: "draft" | "active" | "degraded" | "blocked" | "archived";
  ownerId: string;
  identityRef: string;          // did:peaq:0x... or peaqos:machine:<id>
  identityProof?: { /* EIP-191 controller signature, see API ref */ } | null;
  machineType: string;
  runtimeProfile: string;
  capabilities: string[];
  labels: Record<string, string>;
  policyIds: string[];
  skillKeys: string[];
  createdAt: string;
  updatedAt: string;
};

type AgentPairing = {
  id: string;
  machineId: string;
  status: "active" | "paused" | "revoked";
  agentAddress: string;
  agentDid: string | null;
  agentProvider: string;        // "anthropic" | "openai" | "virtuals" | ...
  agentRole: string;            // free-form, e.g. "ops" | "trader" | "buyer"
  description?: string | null;
  verification: {
    method: "eip191";
    signerAddress: string;
    verifiedAt: string;
    challengeExpiresAt: string;
  } | null;
  delegationPolicy: {
    allowedSkillKeys: string[];
    deniedSkillKeys: string[];
    allowedServiceIds: string[];
    deniedServiceIds: string[];
    perTransactionLimit?: number | null;
    dailySpendLimit?: number | null;
    currency?: string | null;
  };
  hasAuthToken: boolean;
  tokenLastFour: string | null;
  sessionId: string | null;
  sessionTokenId: string | null;
  sessionIssuedAt: string | null;
  sessionExpiresAt: string | null;
  pairingToken?: string;        // signed HS256 session JWT, returned once at create/rotate
  createdAt: string;
  updatedAt: string;
};

​

Skills vs services

• A skill is a capability schema. storage.object says “an object-storage service exposes these operations”. Skills are the contract.
• A service is a concrete instance of a skill from a specific provider. “Exa search via agentic.market” is a service. Services are what you actually buy.

oracle.price-feed
compute.marketplace
compute.confidential
storage.object
data.location
network.partner-console
identity.proof-of-person
device.control
machine.commerce

• Native: peaqOS executes the skill server-side or on a registered machine-side runtime endpoint. No human handoff.
• External handoff: the orchestrator returns a structured handoff (URL, contact, setup steps) and the agent or operator completes the purchase out of band. Used when a provider integration is partner-required or credentials-required.

native | credentials-required | partner-required | local-config-required | setup-required | docs-only

​

Identity proof flow

1. Call POST /machine-identity/challenges with the machine’s identityRef. The orchestrator looks up the controller addresses from peaqOS MCR data and returns a short-lived challengeId plus a message.
2. Sign message with the controller’s private key using EIP-191 personal_sign.
3. Submit { challengeId, signature } as identityProof when calling POST /machines. The orchestrator verifies the signature recovers to one of the controller addresses before persisting. The stored proof is re-checked against MCR data on subsequent machine-bound writes.

​

Pairing flow

1. Call POST /machines/:machineId/agent-pairings/challenges with agentAddress, agentProvider, agentRole, and optional agentDid. The orchestrator returns an AgentPairingChallenge with a challengeId, a machine-bound message, and an expiresAt.
2. The Machine Agent signs message (EIP-191 personal_sign) with the wallet key behind agentAddress.
3. Call POST /machines/:machineId/agent-pairings with agentProof: { challengeId, signature } and the delegation policy. The orchestrator verifies the signature recovers to agentAddress, persists the pairing with verification metadata, and returns the AgentPairing with a signed HS256 session JWT in pairingToken. Store the token 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. A policy change invalidates the current token’s delegationPolicyHash, so rotate after every PATCH to the delegation policy.

​

Order lifecycle

created -> payment_pending -> ready -> executing -> delivered -> confirmed

intent_created -> held -> release_pending -> released
                                          \-> refunded
                                          \-> frozen   (on dispute)

​

Payment rails

• recorded: operator attestation. The orchestrator stores the proof but does not verify on-chain.
• rpc: the orchestrator queries an EVM RPC for the transaction receipt and the ERC-20 Transfer log, validating sender, recipient, token, and amount. Solana proofs are always recorded.

​

Delegation, bounded

​

Multichain shape

• peaqID, Machine NFT, and the Service Registry stay on peaq
• Machine NFTs and smart accounts deploy on supported chains (Base first)
• IdentityLite, DIDLite, and StakingLite mirror peaq state on each supported chain (Agung and Base Sepolia)
• Machine Agents can pay across chains using the chain and token a service quotes in

​

Related

• Scale function
• Machine Markets API
• Activate
• Qualify