Technical reference

Hashing canonicalization

SHA-256 describes bytes. In the browser file flow the original stays local and its digest is submitted with off-chain metadata. A digest is not encryption or automatic anonymization: predictable candidate inputs can be hashed and tested against a public fingerprint.

Historical jcs@1 is a legacy label, not a guarantee that RFC 8785 processing was used. A null processing identifier means the original processing rule was not recorded; do not guess one from the file type. Preserve the original input procedure when you have it.

For files, retain the exact bytes for verification.

Chain architecture

New records use Base L2. Historical QF Network and Polkadot Asset Hub records are readable as historical service records; direct verification needs the corresponding historical chain data. They are not current write targets.

Anchoring mechanics

A managed relayer sends a zero-value EIP-1559 self-transfer. Its transaction input is the claimed SHA-256 digests concatenated in order, 32 bytes each. The ordinary transaction carries one digest. Multiple digests use the same mechanism: no length prefix, framing or Merkle root.

batchIndex identifies your zero-based 32-byte slot; batchSize describes the array length. Compare that exact slot. Finding the digest at another offset is insufficient. On an explorer, skip 64 × batchIndex hexadecimal characters after 0x, then read exactly 64 characters. A shared transaction reveals a short submission window, while filenames, topic, external ID, tenant data and service IDs remain off-chain.

Chain client

Independent checking uses Base JSON-RPC transaction, receipt and block data from a provider you select. An explorer is a convenient view and may be unavailable or lag behind the chain. The direct procedure checks consistency and the named slot.

Response receipt fields

The digest connects to retained source bytes. txHash, blockHash and blockNumber identify the reported transaction and block; slot fields select the digest within transaction input. A successful L2 receipt is inclusion evidence under the inspected node's view.

finalized currently means the service observed a successful Base L2 transaction receipt. It does not mean Ethereum L1 settlement or confirmation-depth monitoring. includedAt, finalizedAt and similar application fields are service observation times unless explicitly identified as a Base block timestamp. A block timestamp describes chain time for that block, not the time an off-chain document was created.

Proof bundle versioning

proofVersion is currently "3". Version 3 allows canon to be null when historical processing is unknown. Retain the original bundle, version and input-processing identifiers.

Renaming, removing, retyping or changing a field's meaning requires a version bump. Adding an optional field does not bump the version. Verifiers must ignore unknown fields at every object depth while still checking every field required for their claimed result. The published bundle, chain, block, tx and finality schemas allow additive fields; runtime response construction remains strict. An unknown version or missing required evidence must not become success.

Older receipts without batch fields can support the single-digest case only when the chain input really contains one digest. Obtain the correct slot evidence for a multi-digest record; do not assume its position. Signed acceptance receipts attest service acceptance separately from transaction inclusion. They are not interchangeable with the chain proof bundle.

Verification and evidence boundary

A match does not establish legal admissibility, authorship, ownership, identity or contents' truth. Check file bytes separately from chain evidence. See what a fingerprint cannot prove.

For documented uses of blockchain records in disputes, see Blockchain evidence in court.

Availability

Preserve the exact file, receipt and exported proof in storage you control. Download the Python verifier package and its SHA-256 checksum, and follow Direct Base verification to run it with Python 3.12+. No source checkout or account is required. Independent verification also needs suitable historical chain access. The separate HTML verifier's current unbound profiles can report cannot-check; see its limitation and the usable Python method in Direct Base verification. Service or provider availability is not guaranteed by retaining a digest.