- 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.
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 theECDSAKeyring 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.
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.
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
signaturefield with:- The algorithm (
EcdsaSecp256k1RecoveryMethod2020). - The issuer (the admin address).
- The admin signature hash over the canonical data.
- The algorithm (
- Update the
servicesfield with a reference to the unsigned message in peaq storage, keyed by the UUID.
Putting it all Together
This script ties the steps into one flow:- Initialize wallets: create instances for the machine and the admin with
ECDSAKeyring. - Generate and store machine data: the machine generates mock data and stores it in peaq storage under a random UUID.
- Sign machine data: the machine signs the data with its private key.
- Admin approval: the admin stores an approval object in peaq storage, then signs its canonical JSON.
- 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.

