pith. sign in

arxiv: 2606.10625 · v1 · pith:BVOZNYKTnew · submitted 2026-06-09 · 💻 cs.CR

snaproot: Decentralized File Integrity Verification Using Blockchain-Anchored Cryptographic Hashing

Arslan Br\"omme , Tarkan Yavas This is my paper

Pith reviewed 2026-06-27 12:35 UTC · model grok-4.3

classification 💻 cs.CR
keywords file integrityblockchain anchoringexistence proofauthorship proofSHA-256Solanadecentralized verificationhash anchoring
0
0 comments X

The pith

snaproot anchors SHA-256 file hashes on Solana to separate key-independent existence proofs from key-dependent authorship proofs.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents snaproot as a lightweight system that computes a file's SHA-256 hash and stores it immutably on the Solana blockchain for later verification by simple recomputation and comparison. It explicitly separates existence proof, a claim that a file existed at a given time without needing any private keys, from authorship proof, which ties the record to a specific wallet identity. This split means existence records stay valid even if the original keys are lost. The design includes a four-tier trust model with one prospective tier for persistence beyond any single chain, and it is tested on Solana Devnet for files from 1 KB to 500 MB. Security analysis rests on the second-preimage resistance of SHA-256, while limitations such as pre-registration changes and AI-generated content are noted.

Core claim

snaproot implements the hash-anchoring paradigm on Solana by storing SHA-256 hashes as on-chain records, with the central advance being the separation of existence proof, which survives without retained keys, from authorship proof, which requires the originating wallet identity.

What carries the argument

The explicit separation between existence proof (key-independent) and authorship proof (key-dependent) within blockchain-anchored hash records.

If this is right

  • Existence proofs remain valid even after loss of the originating wallet keys.
  • Verification reduces to a deterministic binary outcome from hash recomputation and comparison.
  • The four-tier trust architecture supports a future tier for persistence beyond the lifetime of any single blockchain.
  • The system incurs lower resource overhead than full decentralized storage networks.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same existence-versus-authorship split could be adopted by timestamping services on other chains to improve survival after key loss.
  • Long-term archival use cases might favor existence-only records when original authorship is secondary to content persistence.
  • Pre-registration manipulation could be mitigated by requiring multiple independent anchors at registration time.
  • Extending the model with Merkle structures might allow efficient integrity checks on large or evolving datasets.

Load-bearing premise

SHA-256 remains second-preimage resistant so that an altered file cannot produce a matching hash that passes verification.

What would settle it

Discovery of two distinct files that share the same SHA-256 hash, where one is registered on-chain and the other passes the on-chain verification check, would falsify the integrity guarantee.

Figures

Figures reproduced from arXiv: 2606.10625 by Arslan Br\"omme, Tarkan Yavas.

Figure 1
Figure 1. Figure 1: System architecture and data flow for registration (top) and verification (bottom). 4.2 Client Layer and Local Key Management The Client Layer provides the user-facing interface for file submission, verification, and result presentation. It accepts files in any format, forwards raw bytes to the Hashing Module, manages Solana wallet interactions for transaction signing, and displays results. A key property … view at source ↗
Figure 2
Figure 2. Figure 2: Development timeline of snaproot: deployed features (v0.9.9), near-term roadmap, medium￾term, and long-term outlook items, organised by thematic track. 7.1 Limitations Registration of pre-modified content. snaproot detects changes relative to the registered hash. A manipulated or synthetically generated file that is registered at the outset will be anchored by the hash of that already-altered content, and … view at source ↗
read the original abstract

The rapid growth of digital content has made reliable integrity verification increasingly important. Existing solutions rely either on centralized authorities, which introduce trust dependencies and single points of failure, or on decentralized storage systems that incur prohibitive resource overhead. In this paper, we present snaproot, a lightweight system that implements the hash-anchoring paradigm of Haber and Stornetta on the Solana blockchain to provide efficient, decentralized file integrity verification. snaproot generates a SHA-256 hash of a file and stores it immutably on-chain as a permanent reference record. Verification is performed by recomputing the hash and comparing it to the stored value, yielding a deterministic binary outcome. We describe a four-tier trust architecture comprising three realized tiers and one prospective tier for long-term persistence beyond the lifetime of any single blockchain. We present a formal threat model, a security analysis grounded in the second-preimage resistance of SHA-256, and an empirical evaluation on Solana Devnet across file sizes from 1 KB to 500 MB. A central conceptual contribution is the explicit separation between existence proof, the key-independent claim that a file existed at a given time, and authorship proof, the key-dependent binding between a record and a specific wallet identity. This separation allows existence guarantees to survive key loss while preserving stronger authorship claims where keys are retained. We position snaproot against OpenTimestamps, OriginStamp, and Chainpoint and discuss limitations with respect to pre-registration manipulation and AI-generated content.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 3 minor

Summary. The manuscript presents snaproot, a lightweight system implementing hash-anchoring on the Solana blockchain for decentralized file integrity verification. It generates SHA-256 hashes of files and stores them on-chain, performs verification by recomputation and comparison, describes a four-tier trust architecture (three realized, one prospective), provides a formal threat model and security analysis based on SHA-256 second-preimage resistance, reports empirical evaluation on Solana Devnet for files from 1 KB to 500 MB, and introduces the conceptual separation of key-independent existence proofs from key-dependent authorship proofs. The work compares to OpenTimestamps, OriginStamp, and Chainpoint while noting limitations including pre-registration manipulation.

Significance. The explicit separation between existence proof (surviving key loss) and authorship proof is a clear conceptual contribution that extends the utility of blockchain-anchored timestamps in practical scenarios. Combined with the use of an existing high-throughput blockchain for low-overhead anchoring and the inclusion of a threat model plus Devnet evaluation, the approach offers a pragmatic implementation of established primitives. Significance is moderate, as the core mechanisms rely on standard cryptographic properties without introducing new primitives or proofs.

major comments (1)
  1. [Security Analysis] Security Analysis section: the claim that verification yields a 'deterministic binary outcome resistant to forgery' is supported only by invocation of SHA-256 second-preimage resistance without a concrete reduction, attack complexity bound, or discussion of how blockchain-specific factors (e.g., transaction ordering or fork scenarios) interact with this property; this underpins the forgery-resistance portion of both existence and authorship claims.
minor comments (3)
  1. [Abstract] Abstract: states that an empirical evaluation was performed across file sizes but reports no quantitative metrics (e.g., latency, cost, or success rate), reducing the ability to assess the 'efficient' and 'lightweight' claims from the abstract alone.
  2. [Four-tier trust architecture] Four-tier trust architecture: the prospective long-term persistence tier is described only at a high level; specifying concrete mechanisms or fallback assumptions for this tier would clarify its relation to the three realized tiers.
  3. [Empirical evaluation] Empirical evaluation: while file-size range is stated, the manuscript would benefit from explicit reporting of variance, number of trials, or error bars to support reproducibility of the Devnet results.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the detailed review and constructive comment on the security analysis. The feedback highlights an opportunity to strengthen the presentation of our reliance on standard cryptographic assumptions. We address the point below and will revise the manuscript accordingly.

read point-by-point responses

  1. Referee: [Security Analysis] Security Analysis section: the claim that verification yields a 'deterministic binary outcome resistant to forgery' is supported only by invocation of SHA-256 second-preimage resistance without a concrete reduction, attack complexity bound, or discussion of how blockchain-specific factors (e.g., transaction ordering or fork scenarios) interact with this property; this underpins the forgery-resistance portion of both existence and authorship claims.

    Authors: We agree that the Security Analysis section would benefit from additional detail. The deterministic binary outcome follows directly from the definition of second-preimage resistance: given a file F and its hash h = SHA-256(F) anchored on-chain, an adversary succeeds in forgery only by producing F' ≠ F such that SHA-256(F') = h. By the second-preimage resistance of SHA-256, this requires approximately 2^128 work (the standard bound for a 256-bit hash). A formal reduction is not presented because the verification procedure is exactly the definition of the property; the paper invokes the established assumption rather than reproving it. For blockchain-specific factors, the anchoring transaction is treated as an immutable timestamp once confirmed under Solana's consensus; transaction ordering is enforced by the ledger, and the system assumes the blockchain's finality guarantees (with the four-tier model addressing long-term persistence separately). We will expand the section to explicitly state the 2^128 bound, note that the reduction is tautological to the hash property, and briefly discuss that fork or ordering attacks would require compromising the underlying blockchain consensus, which is outside the threat model for the hash-anchoring layer itself. revision: yes

Circularity Check

0 steps flagged

No significant circularity identified

full rationale

The paper presents snaproot as a direct implementation of the Haber-Stornetta hash-anchoring paradigm on Solana using standard SHA-256 hashing for on-chain records. The central conceptual contribution—the separation of key-independent existence proof from key-dependent authorship proof—follows immediately from the properties of cryptographic hashes and wallet signatures without any equations, fitted parameters, or derivations that reduce to inputs by construction. Security claims rest on the external second-preimage resistance of SHA-256 rather than any self-referential definition or self-citation chain. No load-bearing steps match the enumerated circularity patterns; the system description and threat model are self-contained applications of established primitives.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The central claims rest on standard cryptographic assumptions about SHA-256 and blockchain properties rather than new fitted parameters or invented entities.

axioms (2)
  • domain assumption SHA-256 provides second-preimage resistance
    Invoked in the security analysis to support deterministic verification outcomes.
  • domain assumption The Solana blockchain provides immutable on-chain storage
    Required for the hash-anchoring mechanism to serve as a permanent reference record.

pith-pipeline@v0.9.1-grok · 5796 in / 1391 out tokens · 26808 ms · 2026-06-27T12:35:40.808082+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

20 extracted references · 3 canonical work pages · 1 internal anchor

  1. [1]

    Menezes, Paul C

    Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone.Handbook of Applied Cryptography. CRC Press, 1996. ISBN 978-0849385230

    1996

  2. [2]

    FaceForensics++: Learning to detect manipulated facial images

    Andreas Rössler, Davide Cozzolino, Luisa Verdoliva, Christian Riess, Justus Thies, and Matthias Nießner. FaceForensics++: Learning to detect manipulated facial images. In Proceedings of the IEEE/CVF International Conference on Computer Vision (ICCV), pages 1–11, 2019

    2019

  3. [3]

    Operation Black Tulip

    J. R. Prins. DigiNotar certificate authority breach “Operation Black Tulip”. Interim report, Fox-IT, September 2011

    2011

  4. [4]

    Bitcoin: A peer-to-peer electronic cash system.https://bitcoin.or g/bitcoin.pdf, 2008

    Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system.https://bitcoin.or g/bitcoin.pdf, 2008

    2008

  5. [5]

    Scott Stornetta

    Stuart Haber and W. Scott Stornetta. How to time-stamp a digital document.Journal of Cryptology, 3(2):99–111, 1991

    1991

  6. [6]

    OpenTimestamps: Scalable, trust-minimized, distributed timestamping with Bitcoin.https://petertodd.org/2016/opentimestamps-announcement, 2016

    Peter Todd. OpenTimestamps: Scalable, trust-minimized, distributed timestamping with Bitcoin.https://petertodd.org/2016/opentimestamps-announcement, 2016

    2016

  7. [7]

    Decentralized trusted timestamping using the crypto currency Bitcoin

    Bela Gipp, Norman Meuschke, and Andre Gernandt. Decentralized trusted timestamping using the crypto currency Bitcoin. InProceedings of the iConference 2015, Newport Beach, CA, USA, March 2015. 37

    2015

  8. [8]

    Chainpoint: A scalable protocol for anchoring data in the blockchain and generating blockchain receipts, July 2016

    Wayne Vaughan, Jason Bukowski, and Shawn Wilkinson. Chainpoint: A scalable protocol for anchoring data in the blockchain and generating blockchain receipts, July 2016. Chain- point Whitepaper v2.0

    2016

  9. [9]

    In Ictu Oculi: Exposing AI-generated video by detecting eye blinking

    Yuezun Li, Ming-Ching Chang, and Siwei Lyu. In Ictu Oculi: Exposing AI-generated video by detecting eye blinking. InProceedings of the IEEE International Workshop on Information Forensics and Security (WIFS), pages 1–7, 2018

    2018

  10. [10]

    IPFS - Content Addressed, Versioned, P2P File System

    Juan Benet. IPFS – content addressed, versioned, P2P file system, 2014. arXiv:1407.3561 [cs.NI]

    work page internal anchor Pith review Pith/arXiv arXiv 2014

  11. [11]

    Filecoin: A decentralized storage network, 2017

    Protocol Labs. Filecoin: A decentralized storage network, 2017. Protocol Labs Whitepaper

    2017

  12. [12]

    ERC-721 non-fungible token standard, 2018

    William Entriken, Dieter Shirley, Jacob Evans, and Nastassia Sachs. ERC-721 non-fungible token standard, 2018. Ethereum Improvement Proposal 721

    2018

  13. [13]

    Fungibility

    Sarah Barrington and Nick Merrill. The “Fungibility” of non-fungible tokens: A quantitative analysis of ERC-721 metadata, 2022. arXiv:2209.14517 [cs.CY]

    work page arXiv 2022

  14. [14]

    C2PA technical specification, 2023

    Coalition for Content Provenance and Authenticity. C2PA technical specification, 2023. Version 1.3

    2023

  15. [15]

    Certificate transparency, June 2013

    Ben Laurie, Adam Langley, and Emilia Kasper. Certificate transparency, June 2013. RFC 6962, IETF

    2013

  16. [16]

    Proving the correctness of multiprocess programs.IEEE Transactions on Software Engineering, SE-3(2):125–143, 1977

    Leslie Lamport. Proving the correctness of multiprocess programs.IEEE Transactions on Software Engineering, SE-3(2):125–143, 1977. doi: 10.1109/TSE.1977.229904

    work page doi:10.1109/tse.1977.229904 1977

  17. [17]

    Secure hash standard (SHS)

    National Institute of Standards and Technology. Secure hash standard (SHS). FIPS Publi- cation 180-4, NIST, 2015

    2015

  18. [18]

    Solana: A new architecture for a high performance blockchain, 2018

    Anatoly Yakovenko. Solana: A new architecture for a high performance blockchain, 2018. Solana Labs Technical Whitepaper, v0.8.13

    2018

  19. [19]

    Quantum algorithm for the collision problem

    Gilles Brassard, Peter Høyer, and Alain Tapp. Quantum algorithm for the collision problem. InProceedings of LATIN’98: Theoretical Informatics, volume 1380 ofLecture Notes in Computer Science, pages 163–169, 1998

    1998

  20. [20]

    Spreeuwers, Anne J

    Luuk J. Spreeuwers, Anne J. Hendrikse, and Kees J. Gerritsen. Evaluation of automatic face recognition for automatic border control on actual data recorded of travellers at Schiphol airport. In Arslan Brömme and Christoph Busch, editors,Proceedings of the International Conference of the Biometrics Special Interest Group (BIOSIG 2012), volume P-196 ofLec- ...

    2012