Technical overview

Product model

Electronic Registry is a public registry for exact-file records, Public References, updates, and visible history. The product is task-based: users create records, add related entries when needed, and allow others to verify matching records later.

Record model

The basic browser flow identifies one exact file locally and records the resulting file hash. The file itself is not uploaded in this flow. A matching file can later be checked against the public registry record.

Current beta network

Electronic Registry is currently in controlled beta on Solana Devnet, a public test network. Devnet may be reset by the Solana network without notice, which could make current Devnet transaction references unresolvable. Beta records are used for testing and validation. Production permanence requires a later mainnet deployment and readiness path.

When a new File Record is created, Electronic Registry submits it to Solana Devnet at that moment. If the same record already exists, the existing record may be returned without creating a duplicate transaction, and no recording unit is used.

Write path for a new File Record

1. The browser computes a SHA-256 hash over the selected file's bytes.
2. The frontend sends the hash and allowed metadata to the backend; the file itself is not uploaded.
3. The backend validates the request and checks whether the record already exists (idempotency).
4. If it is new, the backend reserves a recording unit and submits a Solana Devnet transaction.
5. The recording unit is finalized only after the chain write succeeds; failed writes consume no unit.
6. Account, dashboard, and read-model data are stored for product UX, separate from the public record.

Updates and history

Registry records cannot be edited or removed. When something related needs to change, a new entry is added instead of changing the original record. This creates a public record history that can be verified later.

Verification flow

Verification starts from an exact file or verification code. The result can show a matching base record, when it was created, and related Public Reference, Research, Audit, or other registry entries when available.

Public and private data

Registry records are public. Files are private unless the user chooses to share them. Dashboard labels, private notes, account information, and similar user-specific organization data are off-chain/private product data and are not public registry records.

Technical details

Technical users can inspect the file hash method and Solana Devnet chain details — such as the transaction signature and program/account references — where available. SHA-256 may appear in technical details because it is the hash method used by the current browser flow.

Trust boundary

Electronic Registry can show that a matching public record exists, when it was created, and whether related entries were added later. It does not decide truth, ownership, authorship, originality, legality, compliance, certification, platform approval, or official approval.

Open verification

Records are written to a public blockchain, not only to Electronic Registry's own systems. The chain data is publicly readable, and Electronic Registry is building a simple way to read and verify any record directly from the chain — so a record stays checkable by anyone, even if Electronic Registry itself were to shut down.

Electronic Registry plans to publish an open verification specification describing records, hashes, public verification, Public References, and record history, so the verification model can be documented and checked independently of the hosted service over time. During the current Devnet beta this is in progress, not complete.

See the Open Verification Specification (draft) for the record and hash format, Public Reference and timeline semantics, and a third-party verifier checklist.

Future API direction

Future API access may allow external systems to create records, add entries, and verify records programmatically. API behavior should follow the same product rules as the browser: verification should remain free, failed writes should not consume units, and public registry data must stay separate from private dashboard/account data.

The website, dashboard, and human-readable read models are product services. Public registry records and chain details should be documented separately from product-service availability.