Decentralized storage · SNIP V2Live on mainnet

Storage you can challenge, not just trust

SUM Chain holds files under Proof-of-Retrievability: archive nodes are assigned chunks, must answer periodic challenges with Merkle proofs, and are rewarded or slashed accordingly. SNIP V2 is live on mainnet.

Proof-of-Retrievability

From upload to on-chain proof

  1. 1

    Register & fund RegisterFilePendingV2

    A file is registered and a fee deposit is locked into its fee pool. It enters the Pending lifecycle.

  2. 2

    Assign chunks merkle_root

    Each chunk is assigned to archive nodes by deterministic rendezvous hashing over its merkle_root, three replicas by default, snapshot-stable.

  3. 3

    Accept assignment AcceptAssignmentV2

    Assigned archives attest possession before the file activates, recorded as per-file possession bitmaps.

  4. 4

    Challenge PoR

    The chain issues deterministic retrievability challenges over (file, chunk, node) at a fixed interval.

  5. 5

    Prove or be slashed SubmitStorageProof

    A valid Merkle proof draws a reward from the fee pool; an expired challenge slashes the node’s stake.

storage.params

replication_factor
3
challenge_interval
100 blocks
assignment
rendezvous hash (BLAKE3)
max_chunks / file
1,048,576
activation_grace
50 blocks

Reassignment active on mainnet (activated at height 8,900,000)

Archive-node exit/withdrawal and automatic chunk reassignment are implemented on-chain and active: the chain has crossed archive_unbonding_enabled_from_height and archive_reassignment_enabled_from_height = 8,900,000, so both activated automatically with no redeploy. Reassignment is epoch-aware and does not rewrite epoch-0 assignments. Challenge coverage remains probabilistic, not per-chunk guaranteed.

Deployed in runtime genesis, activates at height 9,200,000

Two further PoR gates are already in runtime genesis and activate together at height 9,200,000, with no redeploy: assignment targeting (por_assignment_targeting_enabled_from_height) and the assignment-aware bounded challenge scheduler (assignment_aware_por_scheduler_enabled_from_height).

chain_getChainParams does not expose every one of these gates, so this status uses the operator-verified runtime-genesis height and flips to active from the live block height.

Pending · H 9,200,000
File lifecycle

Pending → Active → Abandoned

Pending

Registered and funded; chunks being assigned and accepted.

Active

Assignments accepted; subject to retrievability challenges.

Abandoned

Retired after a grace period, with the remaining deposit refunded.

Private files

The chain enforces access, not encryption

Private files register an X25519 encryption-key entry per account and store per-recipient encrypted key bundles plus access metadata on-chain. The chain enforces these access-list and key-bundle rules, it does not encrypt the raw file bytes itself; that happens client-side before upload.

private_file.rules

visibility
public | private
key_registry
X25519 per account
access_list
on-chain, byte-capped
key_bundles
~80 B per recipient
raw_bytes
never chain-encrypted

SNIP, the storage product surface

This page describes the on-chain storage protocol. SNIP is the application built on it, upload, retrieve, and manage files backed by SUM Chain Proof-of-Retrievability. Try it at snip.sumchain.io ↗.

Grounded in