Identicons

What Agreebase's document and signature identicons are, how they're generated, and what they're safe to rely on for.

An identicon is a small generated image, a grid of colored shapes, that Agreebase produces for a sealed record and for each finalized signer. It's a visual fingerprint: two identical records or signatures always produce the same identicon, and any difference in the underlying state changes it. It exists for quick human comparison, not as a substitute for a hash or a verification result.

Document and signature identicons

A document identicon belongs to a sealed agreement, declaration, witnessed agreement, or notarization. It's generated from that record's sealed state; its metadata hash, its sealing time, its body hash, and its identity; so two records with different content never produce the same image, and the same record always produces the same image no matter how many times it's regenerated.

A signature identicon belongs to one finalized signer or witness, for one specific agreement version. It's generated from that person's completed signature evidence for that version, so it changes if they complete a new signature after a version change, but never appears at all before their signature is finalized. Unlike the document identicon, it's participant-facing evidence, not something shown in public record listings.

How they're generated

Both are built the same way: Agreebase gathers the relevant facts (for a document, things like the metadata hash and completion time; for a signature, the finalized evidence for that signer and version), serializes them consistently, and hashes the result with SHA-256. That digest becomes the seed for a small, deterministic grid of colored rectangles; the same seed always produces the same image, and there's no randomness or external service involved. This is a small in-house renderer, not a third-party identicon library, chosen so the whole process stays deterministic and auditable.

What they're for, and what they're not

Identicons are useful for a fast eyeball check; for example, confirming two copies of a share card or two views of the same record "look the same" before you dig into the actual hash comparison, or spotting at a glance that two records are different without reading through their metadata. They are not a verification method on their own: two visually similar identicons don't prove identical content, and Agreebase never treats an identicon match as a substitute for a hash check. Always use Verify a record or a direct hash comparison for anything that actually needs to be certain.

Privacy

A signature identicon's seed never includes raw contact details, IP addresses, or other personal data directly; only hashed representations of that evidence go into the seed. This means the identicon is safe to display alongside a signature without exposing anything about the signer beyond what a hash already reveals: it's derived data, not a copy of anything private. See Privacy and publication for the broader picture of what is and isn't exposed by Agreebase's public and participant-facing responses, and Image handling and share cards for exactly how identicons are represented in API responses.

Discard changes?

Are you sure? Your draft and any progress will be lost.