Open Verification Specification

Purpose & scope

Verification must remain free and portable. The goal of this specification is that anyone can confirm an Electronic Registry record from public chain data, without depending on the hosted product. It covers what a record is, how a content hash maps to a record, how Public References and history entries relate to a record, and how to read the data from the chain.

It does not cover private dashboard data, account information, or billing — those are product-service concerns and are never part of the public record.

Record & hash format

A record is keyed by the content hash of an exact file. The current browser flow computes a SHA-256 hash over the file bytes. The specification will define the canonical hash encoding, the record fields exposed publicly, and the schema version field used to evolve records over time.

• Content hash — algorithm and hex/byte encoding (placeholder: SHA-256, encoding to be confirmed).
• Record account fields — created marker, schema version, issuer reference (field names to be confirmed).
• Append-only guarantee — records are not edited or removed; changes are new entries.

Public Reference semantics

A Public Reference is a later public entry attached to an existing record — for example a public URL, DOI, report page, or source page. The specification will define how a Public Reference entry is represented, how it is bound to its parent record, and how a verifier presents it without implying authorship, ownership, or endorsement.

Timeline & history semantics

A record can grow a verifiable history when timeline entries (such as Research or Audit entries) are added. The specification will define entry ordering, the sequence field, and how exact matches are distinguished from related timeline entries so that related entries are never presented as exact matches.

Reading from Solana

Records are written to Solana Devnet during the current beta. The specification will document the program identifier, account derivation, and the read steps needed to locate a record from a content hash and to read its entries. These identifiers are placeholders until published.

Program IDs and read semantics are an out-of-frontend dependency and will be published alongside the reference verifier.

Worked example

A complete worked example — from a file’s content hash to the on-chain record and its entries — will be added here once the field names and program identifiers are finalized. See the public record example for a faithful illustration of what a record looks like in the product today.

Build a third-party verifier (checklist)

1. Compute the content hash of the exact file using the canonical algorithm.
2. Derive or look up the record location on-chain from that hash.
3. Read the record account and confirm it exists and is well-formed.
4. Read attached Public Reference and timeline entries in order.
5. Present exact matches and related entries separately, with the trust boundary visible.

Beta note

During the Solana Devnet beta this specification is in progress, not complete. Solana Devnet is a public test network that can be reset, so any identifiers used while testing may change. Stronger claims about portable verification will only be made once the specification and a reference verifier are actually published.