Research teams routinely move protocols, instrument exports, analysis scripts, processed datasets, and result bundles between tools that do not share a common evidence layer. File names and folder history help humans navigate, but neither makes byte-level integrity portable. Attestome creates a compact receipt that couples a SHA-256 digest with deliberately limited, self-declared context. The source file stays on the user’s device.
1. Design goals
The first release optimizes for verifiability, minimization, and honest product boundaries. A useful evidence object should be deterministic across compatible implementations, easy to export, independent of a hosted account, and usable without a wallet. It should also make absence visible: a metadata-only receipt must never masquerade as file-backed evidence.
| Goal | Mechanism | Deliberate limit |
|---|---|---|
| Local privacy | Browser memory processing; no file upload | 25 MiB input cap in this prototype |
| Determinism | Sorted-key canonical JSON and SHA-256 | Does not normalize scientific file formats |
| Portability | Plain JSON Schema, examples, and ESM core | No hosted registry is implied |
| External anchoring | Unsigned, chain-agnostic envelope | No signing or transaction path ships here |
2. Receipt anatomy
An Attestome receipt has two conceptual layers. The artifact layer describes either a locally hashed file or an explicitly metadata-only record. The declaration layer records project context: title, artifact type, study stage, protocol version, research identifier, contributor claim, collection time, tags, redaction claim, and creation time.
For file-backed evidence, the receipt includes only file metadata needed for comparison: base name, byte size, media type, last-modified time, and SHA-256 digest. Directory paths and file contents are excluded. For metadata-only evidence, the file field is null and the evidence mode is unambiguous.
3. Canonical integrity
JSON permits semantically equivalent objects to be serialized with different key orders. Attestome sorts object keys recursively while preserving array order, rejects non-finite numbers and unsupported values, and hashes the canonical UTF-8 representation. Verification removes the stored receipt digest, recreates the canonical payload, and compares the recomputed value using exact lowercase hexadecimal encoding.
A file comparison is a second, separate operation. The verifier re-selects the alleged source file; the browser hashes those bytes and compares the result to the digest recorded in the imported receipt. A valid receipt with a mismatching file means the declaration is internally intact, but the selected file is not the same byte sequence.
4. Provenance without overclaiming
Provenance is best treated as a sequence of explicit claims. A protocol can precede raw data; processed data can cite raw input; an analysis script can cite a dataset; a result bundle can cite both. This prototype generates one receipt at a time, while the schema is intentionally suitable for future parent-digest links. The system does not infer lineage from filenames or silently merge records.
Contributor identifiers are self-declared. Collection and creation times are device-provided. A future trusted system may attest an identity or externally anchor a digest, but its assurance must be evaluated separately from Attestome’s local computation.
5. Wallet and network posture
Wallet connection is optional. When requested by the user, Attestome reads the connected account and chain context. The Web3 workspace adds a strict allowlist for account, chain, block, balance, transaction, and receipt reads. It does not expose signing, chain switching, approvals, contract writes, or transaction broadcasting.
The anchor envelope is an intent package, not a transaction. It carries a receipt digest, contextual address and chain hints when available, an explicit unsigned state, and empty signature and anchor fields. An authorized external operator would need to review network, destination, amount, policy, and execution using a separately governed tool.
Local participation points are a separate browser-only action. The visible 0.53 BOT payment preflight is deliberately inert: payments are not offered in this release, no request is created, and confirmation remains disabled.
6. Ecosystem contribution
Attestome contributes a domain-specific on-ramp from life-science work products into a general evidence network. Its value is not a new asset or marketplace. It normalizes a common research action—“I am presenting these bytes with this context”—into an independently testable object.
- Research artifact receipt schema distinguishes file-backed evidence from an explicit metadata-only declaration.
- Deterministic ESM core and verifier gives builders canonicalization, SHA-256 creation, import validation, and source-file comparison primitives.
- Synthetic receipt example lets users and verifiers exercise the format without exposing real research material.
- Anchor envelope schema and its synthetic example separate local evidence preparation from external signing or submission.
Research users can create and carry a minimal evidence object; tool builders can reuse the schemas and reference module; independent verifiers can import a receipt, recompute its canonical digest, and compare the alleged source bytes in the browser workspace. Network operators receive a smaller, reviewable envelope instead of raw scientific content. No deployed contract or completed anchor is implied.
7. Threat model and non-goals
The prototype assumes the browser runtime and selected file are under the user’s control. It does not defend against a compromised device, malicious browser extension, dishonest metadata declaration, weak laboratory process, or colluding reviewers. SHA-256 collision resistance supports integrity comparison; it does not make a false statement true.
Attestome is not an electronic laboratory notebook, repository, clinical record system, identity provider, digital signature service, timestamp authority, intellectual-property registry, diagnostic product, regulatory submission system, or funding platform.
8. Release roadmap
- Current: local hashing, deterministic receipts, import verification, file comparison, schemas, examples, unsigned envelopes, and read-only provider inspection.
- Next: parent-digest lineage, batch manifests, interoperable command-line verification, and stronger file-format guidance.
- Later, only after review: trusted timestamp adapters, organizational signing policies, external storage references, and audited anchoring integrations.