Verification

The verification receipt on each record's public page summarises what Redtail can check for that record. Each row shows one piece of evidence. The rows that appear, and their values, depend on the record's anchor type — see record types below.

For records anchored as FULL_RECORD_V3, the receipt reports whether the current record data matches the canonical hash anchored on-chain. For legacy records the receipt reports file-level integrity and that an anchor transaction exists, but cannot compare current structured data against the anchor.

When a record is published on Redtail, a proof payload is committed to a public blockchain — currently the Base network — by a self-send transaction. The transaction's calldata embeds a Redtail magic prefix (RDTL), a version byte, and a 32-byte payload hash.

The transaction is public and immutable. The block in which it confirmed, the wallet that submitted it, and the calldata bytes are all publicly available on the ledger.

For new records, the 32-byte payload hash is the SHA-256 of the record's canonical snapshot — see the next section. The payload version byte distinguishes formats: v1 (legacy file/media footprint) and v3 (full canonical record hash). The payload version determines what an independent verifier can recompute.

When a new record is published, Redtail builds a canonical snapshot of the record's structured fields and media fingerprints — a deterministic, normalised representation of the verifiable content. SHA-256 of that snapshot is the canonical record hash. The same hash is what gets anchored on-chain as the RDTL v3 payload.

When the public verification page is viewed, Redtail recomputes the canonical hash from the record's current database state and compares it with the payload hash decoded from the on-chain transaction. If they agree, the record data has not been altered since anchoring. If they disagree, the receipt's record data row shows mismatch.

Media files are checked separately. The primary media's SHA-256 is computed at upload and recomputed on every public page view; the result is shown in the media row. A change to the file produces a media mismatch independently of the record-data check.

Existing records were published before the RDTL v3 format existed. Their on-chain payload binds only the file fingerprint and a minimal footprint, not the full structured record. Public verification distinguishes three states:

• FULL_RECORD_V3
  Full record-data tamper-evidence. The current canonical record hash is recomputed and compared against the RDTL v3 payload on-chain. The receipt's record data row can show v3_record_match or mismatch.
• LEGACY_MEDIA_V1
  Legacy media/file-level verification. The media fingerprint and the anchor transaction can be checked, but the current structured record data cannot be matched against the anchored payload. The receipt's record-data row is legacy_media_only. Legacy records received privacy-safe verification IDs in the same upgrade that introduced RDTL v3, so their public links no longer expose blockchain tx hashes.
• NONE
  No record-data anchor. The receipt reports record-data integrity as unavailable. These records are not represented as fully verified.

Public verification URLs use a random verification ID rather than a blockchain transaction hash:

/v/<verificationId>

Why this matters: blockchain transactions are public, and tx hashes appear in chain explorers alongside the wallet that submitted them. If a tx hash were also the public lookup key, anyone reading the notary wallet's transaction list could enumerate every Redtail record. Verification IDs decouple public lookup from on-chain transaction hashes.

Tx-hash lookups are blocked on the public surface by default:

/v/<verificationId> → 200
/v/<txHash>         → 404

The on-chain transaction hash is still shown in the verification receipt as proof detail — it just isn't a lookup key. Records also carry a visibility marker; the default is unlisted, meaning the record is accessible to anyone with the random link but is not indexed or discoverable from chain data.

Every verifiable record exposes a machine-readable proof manifest at:

/api/public/records/<verificationId>/proof

The manifest is a JSON document that contains the canonical record JSON, its hash, the hashing algorithm, the chain anchor, and a verification block. For a FULL_RECORD_V3 record that has not been altered, the manifest reports:

verification.recordData    = v3_record_match
verification.media         = verified
verification.anchorFound   = true
anchor.binding             = FULL_RECORD_V3
anchor.rdtlPayloadVersion  = 3
anchor.rdtlPayloadHash     = <canonical record hash>

If the record's structured data is modified after anchoring, the manifest reports verification.recordData = mismatch and the public page's verdict reflects the same finding. The manifest is descriptive, not a Verifiable Credentials or JSON-LD document; it is intended for inspection and for independent verifiers that wish to recompute the canonical hash from the same canonical JSON.

For records anchored as FULL_RECORD_V3, the public verification page can prove:

• that the public verification ID resolves to a record;
• that the record has an anchored canonical hash;
• whether the current canonical record data matches the anchored payload hash;
• whether the primary media's current SHA-256 matches the fingerprint recorded when the record was created;
• that the anchor transaction exists on Base and that its calldata contains the expected RDTL v3 payload.

For LEGACY_MEDIA_V1 records, verification can prove media/file-level integrity and that an anchor transaction exists, but it cannot prove that the current structured record data matches the anchored payload.

Verification does not prove:

• physical authenticity of the object;
• ownership;
• custody;
• condition or value;
• legality;
• regulatory compliance;
• issuer identity cryptographically bound to the notary wallet — the claimed issuer of a record is recorded inside the structured data by the account that created the record, and that identity is not independently signed today.

Anchor transactions are submitted through a Redtail-operated notary wallet. The accuracy of every record is the responsibility of the issuing organisation. Redtail provides cryptographic tamper-evidence for record data after anchoring; it does not prevent a party with database or wallet access from publishing inaccurate records.

Currently available:

• FULL_RECORD_V3 canonical record hashing for new records;
• comparison of current record data against the anchored canonical hash;
• media fingerprint verification;
• Base chain transaction and RDTL payload verification;
• privacy-safe verification IDs and default-deny on tx-hash lookups;
• a machine-readable proof manifest at /api/public/records/<verificationId>/proof.

Still not covered:

• physical authenticity of the object;
• ownership or custody claims;
• issuer identity cryptographically bound to the anchor wallet;
• Verifiable Credentials or JSON-LD integration;
• cross-issuer federation, where another verification platform could read a Redtail record without proxying through redtail.id;
• automatic migration of all historical records to FULL_RECORD_V3 — legacy records keep their original anchor type and are described honestly as such.

This page will be revised as those capabilities are added. Redtail does not claim alignment or compliance with any specific regulatory framework; any future regulatory alignment will be described separately and explicitly.