Cotton's storage safety is not only about encrypted blobs. The database describes who owns content, where it appears, which tokens are valid, and which manifests/chunks are live, so protected SQL rows carry integrity signatures too.
In a content-addressed file cloud, the database is not just UI state. It defines users, credentials, layout nodes, node files, manifests, chunks, refresh tokens, download tokens, share tokens, and server settings. If that metadata is silently changed, encrypted storage alone is not enough.
Cotton writes integrity shadow columns for protected entities through descriptors rather than scattered ad-hoc serialization. Security-sensitive reads can verify that the canonical row data still matches its signature.
The signature material is derived from master-key-protected material, so row integrity belongs to the same security boundary as storage encryption and database backup protection.
For existing databases, a bridge rollout can sign legacy unsigned rows while warning administrators that the rollout is not finished. Invalid signatures remain integrity failures; unsigned historical rows get a controlled migration path.
Row signatures are meant to catch unauthorized or accidental metadata changes at read boundaries: token edits, credential tampering, server setting changes, node/file relationship mutation, or storage reference corruption.
Database row signing does not replace backups, PostgreSQL access control, least-privilege deployment, storage consistency checks, or a real external security audit. It raises the bar and makes invisible tampering harder to ignore.
The proof is in the protected surfaces: users, passkey credentials, refresh/download/share tokens, server settings, nodes, node files, manifests, manifest chunks, and chunks can be signed and verified at security-sensitive read boundaries.
A file cloud cannot protect only blob bytes while leaving the map to those bytes easy to mutate silently. Cotton treats storage metadata as part of the security model.
Integrity signatures are detection and hardening, not magic database secrecy. Operators still need sane PostgreSQL permissions, backups, key custody, storage checks, and deployment hardening.
No. Database integrity signatures detect tampering in protected rows. They do not by themselves hide every database value from an administrator or replace encrypted storage.
Because file ownership, layout, tokens, manifests, chunks, and settings live in metadata. Protecting stored blobs while leaving critical metadata unauthenticated would leave a major gap.
It should be treated as a corruption or tampering signal, not as a row to trust silently. Operators still need backups, key custody, and normal database hardening around that signal.