Every ARCWELL record begins as a pile of evidence: source documents, references, timestamps from systems we do not operate. Before any of it touches ARC, it passes through a hashing pipeline that decides exactly what the chain will commit to. Here is how that pipeline works, step by step.
01.From document to digest
Each piece of evidence is normalized, then hashed with a collision-resistant digest function. The output is a fixed-size fingerprint: change a single byte of the source and the digest changes completely. The record on ARC stores the digest, the event timestamp, and the submitter signature, never the raw file.
02.Content-addressed storage
The files themselves live in encrypted or permissioned storage, addressed by their own content hash. That means the storage reference doubles as an integrity check: fetch the file, recompute the digest, and any tampering announces itself. Retention rules and access logs sit in the same layer, so who saw what, and when, is itself recorded.
03.Timestamps and submitter signatures
The anchor binds three things together: the evidence hash, the chain timestamp, and the submitting organization's signature. Anyone can later verify all three independently. The organization cannot backdate a record, and no one else can forge its submission, the signature and the ledger disagree with both stories.
If a single byte changes, the hash says so, politely and permanently.
Hashing is the cheapest strong guarantee in the stack. It costs almost nothing to compute, nothing to verify, and it converts the entire question of “was this altered?” into arithmetic anyone can redo.
Filed under Evidence, ARCWELL Research, Protocol team, ARC network. ARCWELL is a software and verification service; nothing here is investment, legal, or compliance advice.
