Summary: Storj is best understood not as a permanence chain or a pure storage marketplace, but as a distributed cloud object-storage system whose core mechanism is client-side encryption, erasure-coded dispersal across many independently run storage nodes, and a satellite coordination layer that handles metadata, node reputation, audits, repair, billing, and access management. That makes it a useful comparison class for other decentralized storage projects because the real trust surface is not just the dispersed nodes: it is the combination of user-held encryption keys, delegated access grants, and the satellite-run control plane that decides placement, repair, reputation, and account-level operations.
What it does:
Provides S3-compatible object storage and developer tooling for backups, archives, and application data
Encrypts object data and metadata client-side by default, then erasure-codes segments and distributes pieces across many storage nodes operated by different parties
Uses uplink clients, gateways, and SDKs so developers can interact with the network through familiar object-storage flows rather than custom crypto-specific interfaces
Relies on satellites to coordinate node selection, metadata, audits, repair, access management, billing, and payments to storage-node operators
Supports delegated authorization through Access Grants and restricted API keys, including macaroon-based caveats for path, bucket, time, and operation limits
Emphasizes repair, audit, and heterogeneous node distribution as the main durability engine rather than onchain storage proofs or permanence economics
Key claims:
The official site positions Storj as S3-compatible distributed cloud object storage with lower cost, strong durability, and globally distributed performance rather than as a blockchain-native permanence layer
Storj’s docs describe three main peer classes—storage nodes, uplinks, and satellites—which is analytically important because the satellite is a first-order coordination and trust surface rather than a minor helper service
Introductory docs say files are encrypted client-side, erasure-coded, and typically distributed as many pieces across diverse nodes, with only a subset needed for recovery
The decentralization, redundancy, and repair docs argue that Storj’s durability thesis depends on Reed-Solomon erasure coding, heterogeneous node distribution, continual audits, and repair workers instead of simple replication
The access-management docs make clear that Storj combines hierarchical encryption keys with macaroon-based restricted API keys and Access Grants, so authorization design is part of the protocol’s real mechanism rather than a thin application layer
The glossary and architecture docs show Storj is not fully serverless: satellites retain important responsibilities over metadata, account management, node reputation, repair, and payments, which matters when comparing where practical authority sits across storage systems
Whitepaper: The official Storj V3 whitepaper has been saved locally as ../whitepapers/storj-v3-whitepaper.pdf. See also ../whitepapers/storj-primary-sources-2026-05-09.md.