Skip to main content
Once your machine has a wallet and a DID Document on peaq, the next step is to link its data to that on-chain identity. This gives you verifiable storage of machine data with admin approval, and traceability of what the machine produced. In this section you will:
  • Simulate data generated by a machine.
  • Sign that data with the machine’s private key.
  • Store the data in peaq storage.
  • Update the DID Document with a reference to the signed data and its storage location.
You can use any other decentralized or traditional storage backend instead of peaq storage. The requirement is that the storage reference is linked through the machine’s DID Document, so others can verify where the data came from. See Off-Chain Storage Solutions.

Prerequisites

Before proceeding, ensure you have the following in place:
  • peaq JavaScript SDK installed.
  • A completed machine onboarding flow (see the previous page Onboard a Machine).
  • A basic understanding of blockchain transactions, DIDs, and public/private key cryptography.

Instructions

This guide builds on the code from Onboard a Machine, which covered creating a wallet, transferring tokens, and registering a DID Document with an ECDSA verification method. Here you simulate data output from a machine (a sensor reading or a device log), sign it with the machine and admin private keys, and store the result in peaq storage. Then you update the DID Document with a link to the signed data so others can verify and reference it.

1. Generating Machine Data

First, simulate a machine generating data and store it in peaq storage as a key-value pair. Reuse the ECDSAKeyring class from the previous page to access the machine’s wallet. With it you:
  • Generate mock data, as if produced by a sensor or onboard system.
  • Store the unsigned message in peaq storage under a randomly generated UUID key.
peaq storage holds a 64-byte key and a 256-byte value. For larger datasets or binary formats, use an alternative storage solution.

2. Sign Machine Data

Next, sign that message with the machine’s private key. This proves the machine produced the data. The signature uses ECDSA, the signature algorithm native to EVM chains. It is later embedded in the DID Document so third parties can verify the message using:
  • The machine’s public key (on-chain)
  • The unsigned message (from peaq storage)
  • The signature (in the DID Document)

3. Admin Approve Machine Data

The administrator is the trusted authority for the machine. By signing a canonical representation of the stored data, the admin creates a verifiable link between the machine data and the party that controls the machine. A verifier can then confirm both where the data came from and that the responsible party endorsed it. The administrator:
  • Retrieves the stored machine data, identified by the UUID used in peaq storage.
  • Prepares a canonical JSON representation of the data to sign.
  • Signs the canonical content with the admin private key.
  • Sends the transaction that stores the signed approval.
The admin signature covers the canonical JSON of the stored machine data, which includes the storage key and the machine’s signature. It is the proof that the trusted authority approved the data, and the next step writes it into the machine’s DID Document.

4. Update DID Document

Both signatures exist and both unsigned messages are in peaq storage, so the last step is to update the machine’s DID Document. The update embeds the admin approval in the DID, so anyone can resolve the DID, fetch the unsigned message, and check both signatures. In this step you:
  • Reuse the machine’s original DID (same name and wallet).
  • Keep existing fields such as the verification method.
  • Add a signature field with:
    • The algorithm (EcdsaSecp256k1RecoveryMethod2020).
    • The issuer (the admin address).
    • The admin signature hash over the canonical data.
  • Update the services field with a reference to the unsigned message in peaq storage, keyed by the UUID.
The DID Document now carries the admin signature and points at the unsigned machine data in peaq storage. Anyone can read the DID Document, fetch the message from peaq storage by its UUID, and verify it against both the machine’s public key and the admin attestation.

Putting it all Together

This script ties the steps into one flow:
  1. Initialize wallets: create instances for the machine and the admin with ECDSAKeyring.
  2. Generate and store machine data: the machine generates mock data and stores it in peaq storage under a random UUID.
  3. Sign machine data: the machine signs the data with its private key.
  4. Admin approval: the admin stores an approval object in peaq storage, then signs its canonical JSON.
  5. Update DID Document: the DID Document gets the admin signature and the reference to the stored data.

Summary

After running this script, your machine’s DID Document holds:
  • A reference to the storage entry that the admin wrote to peaq storage.
  • The admin’s signature attesting to the data.
The storage entry itself holds the machine’s signature over the data. That is a verifiable data trail: anyone can resolve the DID Document, retrieve the stored data by its key, and confirm that both the machine and the admin signed it.