1. Purpose and scope
This policy explains how the Qstamp SDK is designed to support compliance with the GDPR, the UK GDPR and comparable laws in other jurisdictions, and which responsibilities remain with the organisation that uses it. It is written for organisations that stamp records with the SDK.
The Privacy Policy describes how Quantova Inc processes personal data about visitors to its website and about systems that use its network endpoints. This policy is general information and is not legal advice. Each organisation should obtain its own advice on its processing.
2. Roles
An organisation that stamps records with the SDK determines the purposes and means of that processing and is the controller of its records, fingerprints and receipts. Quantova Inc provides the SDK as software that runs on the controller's own systems. It does not receive records, fingerprints or receipts, has no access to them and does not process them on the controller's behalf.
In our assessment, Quantova Inc is therefore neither a controller nor a processor of record content, and the use of the SDK as such does not require a data processing agreement with Quantova Inc. Where the SDK sends requests to a network endpoint operated by Quantova Inc, Quantova Inc acts as an independent controller of the technical request data, such as the IP address of the calling system, as described in the Privacy Policy.
The controller decides what it writes to the Quantova network and is responsible for that decision. Data written to the network becomes public and is kept by the network permanently.
3. Data flows
- Records are read and fingerprinted on the controller's own systems.
- Fingerprints are combined with random salts and assembled into a hash tree on the controller's own systems.
- For each batch, one salted 32 byte commitment and the record kind are written to the Quantova network in a transaction signed by the controller's account. The transaction also carries the address of the signing account, the contract, the block, the time and the fee.
- Transactions are submitted through a network endpoint. Where the endpoint is operated by Quantova Inc, the request carries the IP address of the calling system and is recorded in our server logs.
- Receipts holding the digest, salt and inclusion path of each record are returned to the controller and stored by it.
- Records, fingerprints and receipts are never sent to Quantova Inc. They leave the controller's systems only if the controller chooses to share them, for example with a verifier.
4. Data published to the network
The commitment is computed with a one way function over salted inputs, and the content of a record cannot be derived from it. The record kind, the signing account address and the other transaction data are public and permanent.
Controllers should ensure that the record kinds they use contain no personal data or confidential information. Controllers should also sign with accounts held by the organisation rather than accounts associated with an individual, because an account address may be personal data where it can be linked to a person.
5. Data minimisation and privacy by design
The design publishes only the minimum value needed to prove that a record existed in an exact form no later than a given time, in line with the principle of data minimisation in Article 5(1)(c) of the GDPR and the duty of data protection by design and by default in Article 25. Records and fingerprints stay with the controller, and one commitment is published for each batch, however many records the batch contains.
6. Status of published commitments
A commitment reveals nothing about the content of a record. While the controller holds a record and its receipt, however, the commitment can still be linked to that record. Where a record relates to an identifiable person, controllers should treat the commitment as pseudonymised personal data, and not as anonymous data, for as long as that link exists.
Guidance from data protection authorities on blockchain technologies, including the guidelines of the European Data Protection Board, should be taken into account when assessing whether and how to publish commitments that relate to personal data.
7. Erasure and immutable records
The Quantova network does not permit published data to be altered or deleted, and Quantova Inc cannot remove it. Because only a salted commitment is published, a controller that deletes a record together with every copy of its receipt leaves on the network a value that can no longer be linked to any person or content.
Controllers should include this step in their erasure procedures, and should explain the permanent nature of published commitments in the information they give to the individuals concerned.
8. Receipts
Receipts contain the digest and salt of the corresponding record. A party that holds a receipt can test guesses about a record with low variability, such as a short code or an amount. Controllers should store receipts with the same protection as the records they describe, apply the same retention period, and delete receipts at the same time as those records.
9. Signing keys
Signing seeds are used only on the controller's systems. The SDK accepts seeds only as byte buffers, signs from a private copy and overwrites that copy after signing. Controllers remain responsible for the generation, storage and rotation of their keys, including in hardware security modules where appropriate.
10. Responsibilities of the controller
The organisation that uses the SDK remains responsible for its own compliance, including the following.
- identifying a lawful basis for stamping each category of record
- informing the individuals concerned, including about the publication of commitments on a public and permanent network
- recording the processing in its records of processing activities
- assessing whether a data protection impact assessment is required, and carrying one out where it is
- setting retention periods for records and receipts, and deleting them together
- protecting records, receipts and signing keys with appropriate security measures
- handling requests from individuals to exercise their rights
- ensuring that its own transfers of records and receipts, and those made by its service providers, comply with the law
- complying with the record keeping laws and the laws on SI systems, including laws on artificial intelligence, that apply to it
11. Data protection impact assessments
Stamping is usually part of a wider processing activity, such as logging the actions of an SI system. Where that activity requires a data protection impact assessment under Article 35 of the GDPR or a comparable law, the assessment should address the points below.
- which records are stamped and whether they contain personal data
- the publication of salted commitments, record kinds and signing account addresses on a public and permanent network
- the storage, access control and retention of receipts
- the risk that a party holding a receipt tests guesses about records with low variability, and the measures used to reduce that risk
- the erasure process, including the deletion of records together with their receipts
- the network endpoint used to submit transactions and the data it receives
Quantova Inc will provide technical documentation of the SDK on request to support an assessment.
12. International aspects
The SDK itself sends no records across borders, because it runs on the controller's own systems. Data written to the Quantova network is public and can be read from any country. Controllers should take into account that publication makes the commitment, the record kind and the signing account address accessible worldwide.
Requests to network endpoints operated by Quantova Inc are handled on servers operated by Quantova and protected by Cloudflare, and may be processed outside the controller's own country, including in the United States, as described in the Privacy Policy.
Qstampby Quantova