If your compliance officer hears "blockchain" and pictures customer data sitting on a public ledger forever, they are not paranoid — they are responding to a decade of consumer-crypto framing. But that is not how durable-records anchoring works, and the difference matters for HIPAA, GDPR, and any regulator that cares about data residency. This post walks through exactly what gets written to Polygon, exactly what does not, and why the architecture is compatible with the strictest privacy regimes.
What people think happens
The mental model most reviewers arrive with is something like: "the vendor takes a copy of each record, writes it to a public blockchain, and now anyone with a block explorer can read it." This is the model that comes from cryptocurrency, where transaction details — sender, recipient, amount — are genuinely public.
It is also the model behind every "we won't put PHI on a blockchain" objection in healthcare pipelines and every GDPR-residency objection in EU pipelines. Both objections are correct under that mental model. The fix is not to argue with the objection. The fix is to replace the mental model with what actually happens.
What actually goes on-chain
For each batch of accumulated records, exactly one thing is written to Polygon: a 32-byte Merkle root. That is a fixed-length cryptographic digest computed over the hashes of the records in the batch. It is not the records, not their identifiers, not their metadata, not a pointer that can be reversed back to the records. It is mathematically one-way.
- Records, in full, never leave your environment. Self-hosted deployments anchor from inside your VPC; managed deployments anchor from a single-tenant namespace dedicated to you. The records themselves stay in the database you already control.
- The on-chain anchor contains no record content, no record identifiers, no tenant identifiers, no field names, no schemas. Only the Merkle root and the batch metadata required to verify it (timestamp, batch size, contract address).
- The verification path runs in reverse. To prove a record was anchored, you supply the record, the platform recomputes its hash and the Merkle path, and the on-chain root confirms inclusion. The proof works in one direction; you cannot start from the chain and reconstruct the records.
Why this matters for GDPR and HIPAA
Both regulations care about a specific question: is the data you are processing identifiable? A 32-byte hash of a batch of records is not identifiable. You cannot derive the records from it. You cannot derive even a single record's identifier from it. Under the European Data Protection Board's guidance on hashing, a hash that does not enable re-identification is generally not personal data — and even when treated conservatively, the on-chain artifact in Certyo's design contains no per-record hash to begin with, only the per-batch root.
HIPAA's de-identification standards are stricter, but they apply to data sets that could be linked back to an individual. The on-chain Merkle root cannot be linked back to a record without access to the full record itself, which lives in your environment under your access controls. If the regulator can see the chain and you delete the record, the record is gone. The anchor proves a record once existed at a specific moment; it does not preserve the record.
What right-to-erasure looks like in practice
GDPR Article 17 grants individuals the right to have their personal data erased. The fear with public-chain architectures is that an immutable ledger conflicts with that right. In Certyo's architecture, the conflict does not exist, because no personal data is anchored. The flow looks like this:
After erasure, the on-chain root still proves that a batch existed at the anchored timestamp, but it cannot be used to reconstruct, identify, or recover the deleted record. The anchor remains as a historical fact about a batch's existence; the record itself is gone. This is the architectural reason the design is compatible with right-to-erasure regimes that other blockchain-based products fail.
How this changes three specific buyer conversations
If the architecture is one-way and per-batch, three categories of objection that historically blocked deals become resolvable:
- Healthcare and PHI — PHI never touches the chain. The on-chain artifact is a 32-byte hash of a batch of hashes — no field, no record, no patient identifier is recoverable. HIPAA-aligned environments can anchor without changing their data-handling posture.
- EU and GDPR-regulated workloads — Records remain in the residency you have configured. The on-chain anchor is global but contains no personal data. Erasure deletes records from your environment without leaving a derivable trace on-chain.
- Defense, public sector, and air-gapped operations — Self-hosted deployments anchor from inside your trust boundary. The only thing that crosses the boundary is the Merkle root — a value that has no operational meaning without the records.
The architectural choice this reflects
The reason competing systems put more on-chain is usually that they are using the chain as the database. Certyo does not. The chain is the anchor; your existing database is the system of record. That separation is not a workaround — it is what makes the design compatible with privacy law in the first place. For the deployment topologies and tenant-isolation guarantees, see /en/about. For the verification API, see the developer portal.
The chain proves a record existed at a moment in time. The record itself stays in your environment, under your access controls, subject to your erasure policy. That separation is the whole point of the design.