Skip to main content
PUT
PUT /machine/{key}/monetization

Endpoint

Sets a machine’s monetization state (opt in or opt out). This is the MCR API’s only signature-verified write endpoint: the caller proves authority with an (personal_sign) signature over a canonical message. A machine’s owner, its , or its on-chain operator may sign (the same authorization triple as EventRegistry.submitEvent). No on-chain transaction is made. Opting in requires the machine to be and not deactivated. Opting out is always allowed (a machine can always exit), so it skips those checks.

Path parameters

string
required
Machine DID (did:peaq:0x...) or a decimal machine ID (e.g. 42).

Request body

boolean
required
true to opt in, false to opt out. Must be a JSON boolean (not "true" or 1).
integer
required
Unix seconds when the message was signed. Must be a positive JSON integer inside the freshness window (see below).
string
required
The EIP-191 signature: 0x followed by exactly 130 hex characters (65 bytes).

Canonical message

The client must build and sign this exact string, byte for byte. Fields are LF-separated (\n) with no trailing newline:
  • registry is the server’s identity registry address, lowercased.
  • chain_id is the chain the server reads from. Together with the registry it binds the signature to one deployment, so a signature captured on one chain does not authorize the same action on another.
  • machine_id is the numeric machine ID. Even when the URL key is a DID, the signed message uses the resolved numeric ID.
  • opted_in is the lowercase string true or false, matching the body field.
Sign it with personal_sign (JS) or eth_account’s encode_defunct(text=message) (Python).

Freshness window

The timestamp must fall within the freshness window (by default up to 300 seconds in the past and 30 seconds of future clock skew). Replaying an old signature after the window closes is rejected, and within the window a strictly newer timestamp is required to overwrite a previously applied decision (see STALE_SIGNATURE).

Response

200 OK

Error responses

Errors use a coded envelope: {"detail": {"code", "message"}}. Branch on code, never on message. The one exception is a body that is not valid JSON: that returns 422 with detail as a list of validation objects carrying no code.

Example

Response

SDK and CLI support

Both SDKs wrap this endpoint, building and signing the canonical message for you: see the opt-in SDK reference (optIn / optOut in JS, opt_in / opt_out in Python). The CLI exposes it as peaqos monetize opt-in | opt-out.