ValiBlocks

ValiBlocks connects data-generating systems — ePRO apps and EDC platforms — to independent verifiers such as regulators, sponsors, and auditors through a neutral, tamper-evident on-chain registry. No personal or clinical data ever leaves the vendor system.

1. ① Store — the vendor system hashes a data point locally and calls storeHash() on the contract. Only the digest is sent on-chain; the clinical data stays in the vendor database.
2. ② Export — when data is later shared for audit or regulatory review, the vendor includes the digest metadata (trialId, recordId, amendmentVersion, algorithmId) alongside the plaintext records.
3. ③ Query — the auditor calls getVersion() with the supplied metadata to retrieve the on-chain record. No wallet or permissions are required.
4. ④ Verify — the contract returns the stored hash and block timestamp. The auditor re-hashes the received data and compares it to the on-chain value.

Steps taken by the ePRO or EDC system each time a data point is recorded or amended.

1. Data entry
   A user — patient, site investigator, or clinician — submits a data point such as a patient-reported outcome, a clinical observation, or an adverse event.
2. Canonicalise
   The data point is serialised to a canonical JSON form: keys sorted alphabetically at every level of nesting, whitespace removed, numbers normalised per RFC 8259. This ensures the same data always produces the same digest, regardless of how it was originally formatted or which system processes it.
3. Hash
   The canonical string is hashed using the registered algorithm (e.g. SHA-256, algorithm ID 1). The hash is applied to the UTF-8 bytes of the canonical string. No data leaves the vendor system at this stage.
4. Store locally
   The digest and the on-chain submission parameters are persisted in the vendor database alongside the original record:

   Field	Description
   trialId	The bytes32 trial identifier assigned at trial creation
   recordId	Your internal identifier for this data point within the trial
   amendmentVersion	A strictly-increasing version number for this record (e.g. 1, 2, 3 or a date such as 20250401)
   algorithmId	Numeric algorithm ID used to produce the digest (e.g. 1 = SHA-256)
   digest	The bytes32 hash, for local reference and to include in data exports

5. Submit on-chain
   Call storeHash(trialId, recordId, digest, algorithmId, amendmentVersion) on the ValGuard contract with the required ETH fee. The contract records the digest, the submitting wallet address, and the block timestamp in an append-only version history for that record.
6. Transaction confirmed
   Once the transaction is mined, the proof-of-existence is immutable. The block timestamp is the authoritative, independently verifiable record of when the digest was first registered on-chain. Store the transaction hash in your own audit log if required.

Steps taken by an independent third party to verify a data point received from a vendor — months or years after the original submission.

1. Receive data export
   The auditor receives a data export from the vendor. Each record includes the plaintext data alongside the proof metadata: trialId, recordId, amendmentVersion, and algorithmId.
2. Look up algorithm
   Call algorithms(algorithmId) on the contract to confirm the algorithm description (e.g. "SHA-256"). This provides an on-chain, vendor-independent confirmation of which hash function was used.
3. Re-canonicalise and re-hash
   Apply the same canonicalisation and hashing procedure to the received plaintext data. The canonical form must be identical to the one the vendor produced at the time of submission — keys sorted, whitespace removed, numbers normalised.
4. Retrieve the on-chain record
   Call getVersion(trialId, recordId, amendmentVersion) on the contract. No ETH fee, wallet, or special permissions are required — the function is publicly accessible to anyone who knows the identifiers.
5. Compare digests
   Compare the locally-computed digest against the on-chain hash field:

   Match — the data is provably unchanged since it was first recorded. The on-chain timestamp gives the earliest possible moment the data could have existed in this exact form, independently verified by the blockchain.

   Mismatch — the received data does not match the on-chain record. The data may have been altered after submission, or the wrong proof metadata was provided with the export.
6. Review amendment history (optional)
   Call getFullHistory(trialId, recordId) to retrieve every version ever submitted for this record, oldest first. Each entry includes the submitter's wallet address, providing a complete, tamper-evident chain of custody that does not rely on the vendor's internal audit system.

• Integrator documentation
• Back to home