File Storage

Storing large files directly in Bitcoin transactions imposes significant costs on the entire network, and this externalization of costs has made on-chain data storage a contentious subject within the Bitcoin community. Moreover, the high cost of embedding data on-chain also limits what’s practical to store. Even with witness discounting, storing megabytes of data in Bitcoin transactions is expensive, and storing gigabytes is prohibitive. As a result, many projects today relies on centralized servers or systems like IPFS that don’t actually provide any availability guarantees.

Kontor aims to solve both of these problems—and provide a viable alternative for scalable data storage on the Bitcoin network—with a storage system that operates entirely on Bitcoin while keeping the stateless data off-chain. The Bitcoin blockchain records the cryptographic commitments, storage agreements, and periodic proofs—all the stateful components of the system that require consensus and immutability, while the file contents themselves are held by storage nodes who are strongly economically incentivized through ongoing KOR emissions and penalized through slashing for failures. This architecture makes large-scale data storage economically practical and provides very strong guarantees of perpetual availability.

Kontor’s approach differs from that of other blockchain storage solutions in both economics and architecture. Projects like Filecoin, Sia, and Chia are primarily designed to compete with centralized cloud storage—optimizing for cost and capacity to handle bulk data where users can re-upload if files are lost. Kontor targets blockchain-native applications requiring perpetual availability without user intervention and it aims to be a scalable alternative to on-chain data storage. Kontor combines positive incentives (block emissions) with negative incentives (slashing), and integrates directly with Bitcoin rather than operating as a separate blockchain, allowing users to upload files to the Kontor storage network with BTC or other Bitcoin metaprotocol tokens with a chain of standard Bitcoin transactions.

Protocol

File agreement creation.

A user prepares a file by applying Reed-Solomon erasure coding, which adds redundancy so the file can be recovered even if some data is lost. The encoded file is organized into a Merkle tree, and the tree’s root serves as a cryptographic commitment to the entire file. The user creates a FileAgreement transaction containing this Merkle root, the file size, and signatures from at least a minimum number of storage nodes. Once confirmed on Bitcoin, the agreement becomes active—storage nodes hold the file data off-chain and begin earning rewards. The blockchain stores the metadata and the cryptographic commitments, but not the file contents themselves. In practice, users may use a “storage portal” service to automate the file preparation and signature-gathering steps.

Emissions and staking.

Each block, files generate KOR emissions. Files created earlier in the network’s history receive slightly higher weights, ensuring valuable historical data remains attractive to store as the network grows. Emissions are distributed equally among the nodes storing each file. Storage nodes must stake KOR proportional to their commitments, with requirements designed to prevent Sybil attacks and ensure capital efficiency. Nodes wishing to exit agreements must pay fees that increase as a file’s replication approaches its minimum threshold.

Challenge-response mechanism.

The protocol uses Bitcoin block hashes to deterministically select files for auditing, targeting approximately 12 challenges per file per year. For each challenged file, one storage node is randomly chosen and must prove it possesses the data. The challenge specifies 100 randomly selected sector indices. The selected node must then produce a recursive SNARK demonstrating knowledge of valid Merkle paths for those sectors. The proof is compact and verifiable in constant time regardless of file size (on the order of 100 ms). Nodes have approximately two weeks to publish their proof on-chain, allowing multiple challenges to be aggregated into a single Bitcoin transaction.

Detection and slashing.

The challenge mechanism provides strong detection guarantees. A node storing only 90% of a file—at the threshold where erasure coding can still recover the full data—has a 99.997% chance of being caught per challenge. Complete data loss is detected with probability exceeding 99.99% on the first challenge. When a node fails a challenge, it is slashed—part of its stake is burned, part is redistributed to other storage nodes storing the same file. The slashed node is removed from the agreement. This makes storage attacks economically irrational, as expected losses from detection far exceed any savings from avoiding storage costs.