# Identicons

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

Audiences: users, developers, agents
Kind: concept
Updated: 2026-07-22

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](/docs/users/verify-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](/docs/concepts/privacy) 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](/docs/developers/image-handling) for exactly how identicons are represented in API responses.