No file datatouches the chain.Only the source of truth.
SNIP is native decentralized storage for SUM Chain. Files are chunked, content-addressed with BLAKE3, and spread across a peer-to-peer mesh of archives — no central server, no custodian. Private files stay encrypted under a key that never leaves your hands.
- No central server to breach
- No admin to socially engineer
- Private files: you hold the only key
The chain keeps the proof. The mesh keeps the bytes.
SUM Chain acts strictly as the cryptographic source of truth. Actual file data lives off-chain in a peer-to-peer mesh — anchored to the chain, never stored on it.
The ledger
SUM Chain stores only the proof.
- Merkle roots — a file's 32-byte identity
- Access lists — who may read, and until when
- Fee pools — Koppa that pays archives over time
- Node records, coverage bitmaps & PoR challenges
No file bytes ever touch the chain.
The mesh
A libp2p network of archives holds the bytes.
- 1 MiB content-addressed chunks on local disk
- 3 replicas per chunk, on distinct archives
- Deterministic placement — no coordinator
- Each archive proving it still holds your data
Bytes live in the mesh; truth settles on the chain.
From bytes to a 32-byte root.
Raw bytes become a content-addressed, replicated, verifiable file across a decentralized mesh — every step provable, none of it trusted.
- 01
Chunk & hash
BLAKE3The file is sliced into uniform 1 MiB blocks. Each block is hashed with BLAKE3 to become a leaf of the Merkle tree.
- 02
Merkle root
IdentityThe leaves build a BLAKE3 Merkle tree. Its 32-byte root becomes the file's absolute identity — on the chain and across the mesh.
- 03
Register on-chain
RegisterFilePendingV2The owner submits the root, size, chunk count, visibility, and a Koppa fee deposit. Only 32 bytes of root plus the rules touch the chain.
- 04
Deterministic assignment
Rendezvous hashingEvery participant reads the same on-chain snapshot and computes the same 3 archives per chunk. There is no coordinator to trust.
- 05
Push to the mesh
/sum/storage/v2Each chunk streams to its 3 assigned archives over QUIC. A receiver verifies an inline Merkle proof before a single byte is written to disk.
- 06
Activate
ActivateFileV2Archives attest their coverage on-chain. Once every chunk is held by an active archive, the owner activates the file. Pending becomes Active.
Prove it, or lose it.
Proof of Retrievability runs on-chain, at the protocol level. On a fixed interval, the chain forces a random archive to prove it still holds a random chunk — settling a reward, or slashing stake, at consensus.
“The security boundary is the encryption key, not the archive.”
Private files are encrypted on the client with ChaCha20-Poly1305. The file key is wrapped per recipient with X25519 and never touches the chain. A malicious archive reading its own disk sees random bytes.
Five crates. Native Rust.
No smart contracts, no IPFS dependency, no separate storage token. Storage economics settle directly at the SUM Chain consensus layer, in Koppa.
Shared data types and consensus-critical constants — CHUNK_SIZE, REPLICATION_FACTOR, wire messages. Every crate depends on it; nothing depends on sum-node.
The private-file boundary — per-file K_file, ChaCha20-Poly1305 AEAD, HKDF-SHA256 derivation, and X25519 per-recipient key wrapping.
The libp2p swarm — QUIC and TCP transports, mDNS and Kademlia discovery, relay and hole-punching, and versioned storage codecs.
The chunk store, BLAKE3 Merkle tree and proofs, deterministic rendezvous assignment, and grace-based garbage collection.
The daemon, the CLI, and the background workers — the PoR responder, market sync, and the assignment attestor.
Shipped, and shipping.
Built ground-up by a core Rust team without breaking consensus. Storage is the first utility settled natively on SUM Chain.
Cryptography & state foundation
BLAKE3 Merkle identity, Ed25519 keys, and the on-chain metadata types that anchor every file.
L1 bridge, ACL & PoR responder
The JSON-RPC bridge, chain-enforced access lists, and the Proof-of-Retrievability responder.
P2P mesh & deterministic assignment
The libp2p mesh, rendezvous-hash placement at 3× replication, and WAN discovery over Kademlia, relay, and DCUtR.
Private files, end to end
Client-side ChaCha20-Poly1305 encryption, X25519 per-recipient key wrapping, and share / revoke / update-access.
Scale-out & multi-platform
Linux x86_64 prebuilts ship today; aarch64 and macOS builds, a lightweight outbound-only client mode, and erasure coding are on the way.
Run an archive. Earn on every proof.
Prebuilt binaries ship for Linux x86_64; every other target builds from source. The installer pins a version explicitly — there is no implicit latest.
$ curl -fsSL https://github.com/SUM-INNOVATION/Storage-Node-Interface-Protocol/releases/download/v0.4.0-rc4/install.sh \$ | sh -s -- --version v0.4.0-rc4
Client
--clientUpload, download, and share files. No registration, no stake, no daemon — push chunks to the assigned archives and exit.
- ›ingest-v2 · download
- ›share · revoke · update-access
- ›Cannot earn or be slashed
Archive
listenA long-running operator. Registers on-chain with a 1 Koppa stake, serves chunks, and answers Proof-of-Retrievability challenges.
- ›register-node --stake
- ›Earns Koppa on every valid proof
- ›Slashed 5% on a missed proof
| Environment | Client | Archive | Install |
|---|---|---|---|
| Linux x86_64 | Supported | Supported | Prebuilt binary |
| macOS (Apple Silicon) | Supported | Experimental | Build from source |
| Windows (WSL2) | Caveats | Not supported | Build from source |
| ChromeOS (Crostini) | Caveats | Not supported | Build from source |