Data streams

Sell machine data with peaqOS Stream: signed packages, tamper-evident chunk chains, per-chunk encryption, and buyer access grants. Plaintext stays protected.

Selling machine data has a trust problem on both sides. A buyer needs to know the data really came from a specific machine and was not tampered with, before paying. A seller needs to hand over exactly what was bought and nothing more, without leaking the rest or trusting a middleman to hold the plaintext. Stream solves both with the machine’s signature, verifiable hashes, and per-chunk encryption, not with shared secrets or a trusted intermediary.

Roles

Role	Description
Machine	The robot or device generating data. Holds a signing key. Packages it signs with the SDK carry a DID of the form did:peaq:0x<signing address>; the SDK package verifier does not accept the decimal did:peaq:<machine id> DID that Activate issues.
Machine Owner / Proxy Operator	Sets the data policy, runs the Edge Agent, lists data for sale, and configures recovery recipients.
Context Provider (buyer)	Buys access, verifies it, and normalizes the data into datasets for consumption such as AI training. DataHive is one.
peaqOS backend	Stores policies, manifests, receipts, and access grants, and emits audit events. It does not store raw plaintext data.

The trust model

1. Signed data packages. As data is captured, the machine bundles it with its identity (DID, timestamp, schema version, sequence number) and signs it. Anyone can verify the signature, with no account or login. For packages signed with the SDK, the verifier recovers the EIP-191 signer and compares it with the address in the package’s did:peaq:0x... DID. The ROS 2 Edge Agent signs its envelopes with Ed25519 instead, and those are checked against the agent’s Ed25519 public key. Field rules are applied before signing, so a buyer can detect tampering without the seller having to reveal protected fields.

2. Field-level rules. A Data Event Map defines, per topic and field, whether to include, exclude, encrypt, or anonymize (by hash, generalize, or redact). Sensitive values are protected before they ever leave the machine.

3. Chunks and chunk chains. Continuous data is grouped into bounded chunks: the SDK splits input into fixed-size chunks (256 KiB by default), and the Edge Agent writes one chunk per captured message. Each chunk links to the previous one, forming a chunk chain: reordering, gaps, or edits become detectable. A chunk is the unit a buyer purchases.

4. Per-chunk encryption. Each chunk is encrypted under its own random key. That key is then wrapped separately for each authorized recipient using their public key. Granting access to a new buyer wraps the same chunk key to their key. The chunk data is never re-encrypted, and no master key is shared. This is envelope encryption.

5. Manifests. Each chunk carries a manifest (the chunk envelope) recording its hashes (ciphertext and plaintext), storage reference, and encryption metadata, never the data itself. The machine’s Ed25519 signature covers the ciphertext hash, the chunk ID links that hash to the previous chunk, and the plaintext hash and key commitment are checked when a recipient decrypts. The owner lists chunks for sale; buyers verify the signatures and hashes before paying.

The chunk envelope

A chunk is stored and shared as a self-describing envelope: the encrypted bytes plus everything needed to verify and (with the right key) decrypt them.

{
  "schemaVersion": "peaq.stream.chunks.v1",
  "chunkId": "…",
  "previousChunkId": null,
  "index": 0,
  "encryptedDataHash": "0x…",
  "plaintextHash": "0x…",
  "storageRef": "walrus://…",
  "encryption": {
    "algorithm": "xchacha20-poly1305",
    "nonce": "…",
    "keyCommitment": "sha256:…",
    "keyRecipients": [
      {
        "recipientId": "…",
        "recipientType": "owner",
        "algorithm": "x25519-sealedbox",
        "publicKeyHex": "…",
        "wrappedKeyHex": "…"
      }
    ]
  },
  "signature": { "algorithm": "ed25519", "machineDid": "did:peaq:0x…", "keyId": "did:peaq:0x…#keys-1", "publicKeyHex": "…", "value": "…" }
}

The encrypted bytes live off-chain: local disk, owner storage, Walrus (walrus://), or a cloud adapter. The backend tracks only the manifest: hashes, storage reference, and the per-recipient wrapped keys. The envelope’s keyRecipients are the owner, operator, and machine, and are never modified after the chunk is built. An access grant is a separate buyer access entry that wraps the same chunk key to the buyer’s key, so no data is re-encrypted.

Buyer and seller flow

1. Capture and chunk

   The Edge Agent captures allowed topics, applies field rules, and writes each captured message as an encrypted chunk with its manifest.

2. Discover and verify

   The seller hands the buyer the listing and chunk IDs. The buyer fetches the chunk envelopes, verifies the machine’s chunk signatures and chain links, and checks the chunk hashes before paying.

3. Pay and grant access

   The buyer submits their public key and pays. After payment, an access grant re-wraps the purchased chunk keys to the buyer’s key. The backend records the grant and an audit event.

4. Deliver and decrypt

   The buyer receives the encrypted chunks, fetched from storage or streamed directly machine-to-machine over P2P, unwraps the chunk keys with their private key, and decrypts only the chunks they bought. Over P2P, every chunk’s hash, signature, and chain link is verified before decryption.

Owner and operator recovery recipients can be configured before chunks are created: the chunk key is also wrapped to their keys, so data stays recoverable if the machine goes offline.

Build it

Signing, chunk chains, encryption, and key wrapping are exposed by the stream SDK module for JavaScript and Python. Purchases, payment rails, and the S3 and P2P delivery channels are the distribution surface. The on-machine Edge Agent runs this pipeline from a Data Event Map.

Related

• Stream function
• Stream SDK reference
• peaqID
• Machine Markets