Once your machine has a wallet and a corresponding DID Document registered on the peaq network, the next step is to associate metadata with its on-chain identity. This enables verifiable storage of machine-generated data with admin approval and adds traceability to the machine’s activity within a DePIN ecosystem. In this section, we’ll demonstrate how to:Documentation Index
Fetch the complete documentation index at: https://docs.peaq.xyz/llms.txt
Use this file to discover all available pages before exploring further.
- Simulate data generated by a machine.
- Sign that data using the machine’s private key.
- Store the signed data using peaq storage.
- Update the existing DID Document to include 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
In this guide, we’ll build upon the code from the Onboard a Machine tutorial. That section covered creating a wallet, transferring tokens, and registering a DID Document with an ECDSA verification method. Here, we’ll simulate data output from a machine (e.g., a sensor reading or device log), sign the data with the machine and admin private key to ensure authenticity, and store the result using peaq storage. Finally, we’ll update the DID Document to include a link to the signed data, allowing it to be verified and referenced by others in the network.1. Generating Machine Data
To start we will simulate a machine generating data and then store it using peaq storage as a key-value pair. We will reuse the previously createdECDSAKeyring class to access the machine’s wallet instance. This allows us to:
- Generate mock data (as if produced by a sensor or onboard system).
- Store the unsigned message in peaq storage using a randomly generated uuid as the key.
64-byte key : 256-byte value. For larger datasets or binary formats, please refer to alternative storage solutions or consult our extended tutorials.
2. Sign Machine Data
After storing the message in peaq storage, the next step is to sign that message using the machine’s private key. This proves that the machine was indeed the originator of the data — a core requirement for decentralized, verifiable systems. We use the ECDSA signature algorithm, which is native to EVM ecosystems. The generated signature can later be embedded into the DID Document so that 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
After the machine has generated its data and signed it, the next step is for the administrator—acting as the trusted authority—to explicitly approve the machine-generated data. By signing a canonical representation of the stored data, the administrator creates a verifiable link between the machine data and the authority that controls the machine. This dual-layer verification is critical for ensuring trust in decentralized systems, as verifiers can confirm both the origin of the data and its formal endorsement by the responsible party. The administrator will perform the following tasks:- Retrieve the stored machine data (identified by the UUID used in peaq storage).
- Prepare a canonical JSON representation of the data that the admin will sign.
- Sign the canonical content using the administrator’s private key.
- Send the transaction to store the signed approval.
4. Update DID Document
Now that the machine & admin have generated a verifiable signatures and stored their unsigned messages in peaq storage, the final step is to update the machine’s DID Document. This update embeds the administrators approval into the DID, linking the stored data to a trusted authority. With this update, external parties can resolve the DID, retrieve the unsigned message, and verify both the machine’s signature and the admin’s attestation. In this step, we will:- Reuse the machine’s original DID (same name and wallet).
- Preserve existing fields such as the verification method.
- Add a new
signaturefield that includes:- The algorithm used (
EcdsaSecp256k1RecoveryMethod2020). - The issuer (admin’s address).
- The admin’s signature hash over the canonical data.
- The algorithm used (
- Update the
servicesfield to include a reference to the unsigned message stored in peaq storage, which is linked by a UUID.
- Retrieve the DID Document to inspect the machine’s verification method and the admin-approved signature.
- Fetch the corresponding unsigned message from peaq storage using the UUID reference.
- Verify the authenticity of the machine data using both the machine’s public key and the trusted admin’s attestation.
Putting it all Together
In this example, we tie all the steps into one complete flow. The script performs the following tasks:- Initialize Wallets: Create instances for both the machine and the admin using the ECDSAKeyring.
- Generate & Store Machine Data: The machine generates mock data and stores it in peaq storage under a randomly generated UUID.
- Sign Machine Data: The machine signs the generated data with its private key to create a verifiable signature.
- Admin Approval: The admin (trusted authority) retrieves the machine data reference and stores an approval object in peaq storage. Then, the admin signs a canonical JSON representation of this approval content.
- Update DID Document: The machine’s DID Document is updated with the admin’s signature and a reference to the stored data. Ultimately links the unsigned machine data (with its machine signature) to the trusted admin’s attestation.
Summary
After running this script, your machine’s DID Document will be updated with:- A reference to the unsigned machine data stored in peaq storage.
- The machine’s signature over the generated data.
- The admin’s signature attesting to the data’s validity.

