How Redtail records are verified.

Every record published on Redtail produces a deterministic content hash derived from its structured data and the cryptographic hashes of its associated media. That content hash is committed to a public ledger — at the time of writing, the Base L2 network — by a self-send transaction whose calldata embeds a Redtail magic prefix, a version byte, and the 32-byte SHA-256 content hash.

The transaction is public, immutable, and indexable by any third party. The block in which it confirmed, the wallet that submitted it, and the calldata bytes are all available without Redtail's cooperation.

If Redtail ceased operation today, a record published today remains independently verifiable. The reader needs three things:

• The record's structured data (the title, fields, media files and their SHA-256 hashes) — exportable from the record's public verification page, or from Redtail's API while it operates.
• The on-chain transaction hash for the record's anchor event — also published on the verification page, and recoverable from the public ledger by Redtail wallet address and content-hash lookup.
• The reproducible hashing algorithm — described in the next section.

With these three, anyone can recompute the content hash from the record data, recover the on-chain transaction, and confirm the two hashes match. Redtail's involvement is not required.

Each RecordMedia file is hashed with SHA-256 over its raw bytes, server-side, at the moment of upload. The hash is a 64-character lowercase hexadecimal string. Hashes are persisted alongside the record and never recomputed.

The record's content hash is derived deterministically from the record's structured fields, in canonical key order, joined with the ordered list of media SHA-256 hashes. The resulting 32-byte digest is what gets committed on-chain.

A reference implementation of the hashing function is documented alongside this page in the Redtail engineering documentation.

A successful verification proves three things:

• The record existed in its current form at the moment its anchor transaction confirmed on-chain. It cannot be silently backdated, edited, or substituted after that point.
• The media attached to the record has not been replaced. Each file's SHA-256 must match the hash committed alongside the record. A swapped image is detectable.
• The record was issued by the wallet that submitted the anchor transaction. By policy, that wallet is operated by Redtail, and the record's claimed issuer (gallery, brand, institution) is recorded inside the structured data, not in the wallet identity.

What verification does not prove: that the issuer's claim about the physical object is true. Redtail records the attestation; verification confirms the attestation has not been tampered with. The attestation's underlying truth is the issuer's responsibility.

Phase 1 of this specification covers the data model, hashing process, and on-chain anchor format. It does not yet cover:

• A standalone JSON-LD endpoint or Verifiable Credentials integration — planned, not yet shipped.
• Cross-issuer federation, where another verification platform could read a Redtail record without proxying through redtail.id — supported architecturally, not yet documented.
• Full alignment with the EU Digital Product Passport (ESPR) — the data model is shaped compatibly with the draft regulations, but the regulations are not yet final and Redtail does not claim compliance.

This page will be revised as those capabilities ship. The URL and section structure are stable.