> For the complete documentation index, see [llms.txt](https://hinkal-team.gitbook.io/hinkal/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hinkal-team.gitbook.io/hinkal/hinkal-waas/description/data-integrity.md).

# Data Integrity

Every record written to the database — including user records, wallet records, encrypted private keys, organization data, and policies — is signed by the enclave's private key before being stored. This signature is a cryptographic seal: it proves the record was produced by the enclave and has not been modified since.

When a sensitive operation is performed, the enclave retrieves the relevant record and verifies its signature before proceeding. If any field in the record has been tampered with — by an external attacker, a compromised database, or any other means — the signature will not match and the operation is rejected. The enclave will not use data it cannot verify.

For non-sensitive read operations such as fetching organization details or wallet addresses, the API server reads directly from the database without signature verification. These are getter-only paths — the API server never writes to the database — so the integrity of write operations is fully covered by enclave verification on the paths that matter.

This means that even if the database were compromised, an attacker could not silently substitute wallet records or policy data. Any tampered record would be caught and rejected by the enclave the next time it is used.