Guide
Evidence Anchoring: Hashing, Merkle Roots and Custody
How evidence anchoring works in Noesea — local hashing, Merkle-root bundling, custody records and on-chain anchoring so evidence stays verifiable outside any single tool.
On this page
Local hashing
Evidence is hashed where it lives, before anything is uploaded. The content hash is a stable fingerprint: if a single byte changes, the hash changes, so anyone can later confirm that an artifact is exactly the one that was anchored.
Merkle-root bundling
Related evidence is grouped into a bundle and reduced to a single Merkle root. Anchoring the root commits to every item in the bundle at once, and a compact Merkle proof later shows that a specific item belongs to the bundle without revealing the rest.
Custody records
Each handoff — capture, transfer, review — is recorded as a custody event with a signer attestation. The chain of custody travels with the evidence record, so a reviewer can see who touched an artifact and when, which is what makes it useful in legal and compliance settings.
On-chain anchoring
Only hashes, Merkle roots and outcomes are anchored on Base — never raw content. The artifact stays in content-addressed storage such as IPFS; the on-chain anchor is the durable, tamper-evident reference that lets the record be rechecked independently.
How the claim gets a stable identifier
Evidence is anchored against a claim, and the claim identifier is deterministic. Under the active canonicalization version, claim text is Unicode-normalized, entities and related claims are sorted, and the canonical bytes are hashed into a content hash. The claim ID is keccak256 over the ABI encoding of the canonicalization version, the topic ID, that content hash and a nonce — a fixed 128-byte preimage. The Rust canonicalizer, the TypeScript SDK, the web verifier and the contracts are held to one shared set of test vectors, so independent clients derive the same ID from the same claim.
What a receiver actually checks
The browser verifier runs structural checks locally and reports each one separately: it recomputes an evidence ID from the content hash, submitter and file name; recomputes a bundle's Merkle root over every item and compares it with the stated root; confirms that a claim ID and content hash are well-formed 32-byte commitments; and checks an oracle response's schema and EIP-712 signature. None of these checks asserts that a claim is factually correct, that the bytes are still stored somewhere, or that an anchor has reached chain finality. Those are different questions with different evidence.
Where anchoring sits in the verifiability tiers
Noesea grades a record by what can be independently checked. Tier 1 means a content hash exists, so anyone holding the file can confirm its integrity. Tier 2 adds an on-chain anchor for the hash or Merkle root, with a timestamp and custody event. Tier 3 means the claim, evidence, custody and provenance relationships can be reconstructed from artifacts. Anchoring moves a record from Tier 1 to Tier 2; it does not by itself make a record dispute-settled.
Integrity is not availability
A hash proves that bytes are unchanged; it cannot bring back bytes that no longer exist. Noesea's evidence lifecycle treats retrievability as its own question: storage providers return receipts bound to the exact evidence ID, replicas are probed by downloading and re-hashing them, and content deletion, key destruction and the permanence of the on-chain commitment are recorded as separate facts rather than folded into one status.
Current status
Noesea is pre-launch. The anchoring flow has been exercised on local and test deployments but is not yet operated on a public production network. Exported proofs stay locally verifiable either way, and the verifier shows a record as not anchored when no on-chain anchor is present.
FAQ
Common questions about evidence anchoring
What gets stored on-chain?
Only hashes, Merkle roots, stakes, outcomes and reputation. Raw content is never written on-chain — it stays in content-addressed storage, referenced by its hash.
What is a Merkle proof used for here?
It lets you prove that one specific evidence item is part of an anchored bundle without disclosing the other items, which keeps unrelated evidence private while still being verifiable.
Can evidence be verified without Noesea?
Yes. Because verification is hash- and proof-based, a receiver can recompute the hash and check the Merkle proof against the public anchor independently of Noesea-operated infrastructure.
Does a valid hash mean the evidence is still available?
No. A hash confirms that the bytes you hold match what was recorded. Availability is tracked separately through storage-provider receipts and periodic re-download probes, because a commitment cannot reconstruct missing data.
Continue