Proof, not promises: our audit log is time-stamped on a public blockchain

Check any time-stamp yourself: paste a fingerprint or check a signed report, free, without trusting us.

In plain words: if anyone edits or deletes a past entry, the fingerprints no longer match, and you can check that without trusting us.

DPDP Star keeps an audit log of what happens to consents, rights requests and breach records. The log is hash-chained: each entry carries a fingerprint of the one before it, so a changed or missing entry breaks the chain.

What we time-stamp

At most once a day, on days the log has new entries, DPDP Star writes a short record: the fingerprint of the newest log entry, how many entries the log holds, and the time (UTC). It then time-stamps the SHA-256 of that record on the Bitcoin public blockchain through OpenTimestamps, a free, open-source service.

The same SHA-256 is also sent to an RFC 3161 time-stamp authority. Today that is FreeTSA (free RFC 3161 time-stamp authority; not CCA-licensed).

Only the fingerprint leaves our server. No personal data goes to the blockchain.

Time-stamps so far

Each row is one time-stamped record, newest at the top. The record itself (log fingerprint and entry count) is not published here; your organisation's signed hash report prints it. Each organisation has its own SHA-256 hash chain (isolated by fiduciary_id) and per-tenant Merkle proof anchored in the time-stamped root.

Date (UTC)	Record SHA-256	Bitcoin status	RFC 3161 time-stamp	Proof files
Loading the time-stamps...

"Pending" means the proof is waiting for the next Bitcoin block, usually a few hours.

Check a fingerprint

Paste a record SHA-256 to see whether it is one of the time-stamps above. The check runs in this browser against the list above; the value you paste is not sent anywhere.

A signed hash report carries two fingerprints. Its own "Record SHA-256" is a fingerprint of the report, not of the log, so it will not be in this list. Use the fingerprint in the report's "latest independent time-stamp" line.

Check a signed hash report

Your signed hash report shows the latest time-stamp, so your DPO can compare the log they see with the fingerprint that was time-stamped. Choose the report file (.json) below. It is read in this browser; nothing is uploaded.

Drop the report file here, or choose it JSON, up to 20 MB

Check a time-stamp yourself

You do not have to trust us to check the time-stamp: the proof file can be checked with the free, open-source OpenTimestamps tools against the public Bitcoin blockchain, and the RFC 3161 response with OpenSSL. Download the proof files from the table above. The steps are for your IT or security team.

For your IT or security team

Signed hash report (OpenSSL)

The report holds the exact signed bytes, the signing certificate and the signature (SHA256withRSA). With jq and OpenSSL:

jq -r .signed_payload_b64 report.json | openssl base64 -d -A > payload.bin
jq -r .digital_signature report.json | openssl base64 -d -A > signature.bin
jq -r .signing_cert_pem report.json > signing-cert.pem
openssl x509 -in signing-cert.pem -pubkey -noout > signing-key.pem
openssl dgst -sha256 -verify signing-key.pem -signature signature.bin payload.bin
openssl dgst -sha256 payload.bin

"Verified OK" means the signature matches the key in the report. The last line prints the SHA-256 of the signed part of the report; it equals the report's own fingerprint (the report prints it in capital letters). The report's anchor fingerprint, the one to look up in the table above, is inside the signed part.

In the commands below, replace <Record SHA-256> with the value from the table; the downloaded files are named after it.

Bitcoin (OpenTimestamps)

Download the .ots proof file for a row.
Install the open-source OpenTimestamps client: pip install opentimestamps-client

Run:

ots verify -d <Record SHA-256> <Record SHA-256>.ots

If you run a Bitcoin Core node, the tool confirms the Bitcoin block and the time. Without a node, run ots info <Record SHA-256>.ots to see the Bitcoin block it points to, then check that block on any public block explorer.
While a proof is pending, ots verify prints "Pending confirmation in Bitcoin blockchain". Download the proof again after the next Bitcoin block.

RFC 3161 (FreeTSA)

Download the .tsr time-stamp response for a row.
Download FreeTSA's certificates: cacert.pem and tsa.crt.
Run:
```
openssl ts -verify -digest <Record SHA-256> -in <Record SHA-256>.tsr -CAfile cacert.pem -untrusted tsa.crt
```
"Verification: OK" means FreeTSA signed a time-stamp for that SHA-256. OpenSSL may also warn that tsa.crt is not a CA certificate; that warning is expected.
To see the time FreeTSA recorded: openssl ts -reply -in <Record SHA-256>.tsr -text

These steps were tested on 12 Oct 2026 in our test setup with OpenTimestamps client 0.7.2 and OpenSSL 3.

What this proves, and what it does not

It proves the record existed, unchanged, no later than that Bitcoin block.
It does not prove the log entries are true, complete or lawful, what happened between two time-stamps, or anything about entries made after the last time-stamp.
You can check the time-stamp. Checking the log itself against it needs the log, which only your organisation's admin and DPO can see, in their signed hash report.
After one year, a person's details in sign-in records are blanked under our retention rule. Those rows stay in the chain and the report marks them "redacted after retention".
The report check on this page shows that a report was signed by the key in the report. It does not show who holds that key.
A time-stamp is not a legal certificate. Using a log in a legal proceeding has its own requirements; take legal advice.

Coming next

A second time-stamp from a time-stamping authority licensed under India's Controller of Certifying Authorities is planned. It is not live yet.

Per-organisation SHA-256 hash chains and Merkle proofs (isolated by fiduciary_id), so each customer's report shows only its own log, are built into the verifier.

Back to dpdpa.support