DataHaven: an EVM Substrate chain where storage proofs settle on EigenLayer

The problem DataHaven targets: proving that stored data still exists

Storing bytes on someone else's disk is easy. Proving, months later, that those bytes were not altered or quietly dropped is the hard part, and it is the part that blocks AI training pipelines from using decentralized storage at all. DataHaven addresses that by separating the two halves of the job. Providers keep the data off-chain, where bandwidth and disk are cheap. Cryptographic commitments go on-chain, where they are expensive but tamper-evident. The README frames the network as being for AI training data, machine learning models and Web3 applications, which is a narrower audience than general-purpose file storage. The chain is EVM compatible through Frontier pallets, so the intended user already has Solidity tooling and an Ethereum mental model. If you only need a bucket to dump logs into, this is more machinery than the task requires.

Two provider roles and a proof challenge loop

The architecture diagram in the README splits storage providers into two classes with different incentives. Main Storage Providers are user-selected, serve read requests, anchor bucket roots and run an MSP Backend service. Backup Storage Providers are network-assigned, replicate data and answer proof challenges. The replication step is described as the MSP coordinating with BSPs according to the bucket's replication policy, which means replication depth is a per-bucket setting rather than a network-wide constant. Verification runs on a challenge cycle: BSPs face periodic proof challenges, and the README states that failure to prove data custody results in on-chain slashing via StorageHub pallets. Two further roles sit alongside the providers. An Indexer watches on-chain events and answers storage metadata queries from a PostgreSQL backend, and a Fisherman audits storage proofs and can trigger challenges when it detects misbehavior. Upload flow is given as four steps: chunk the file, hash it into a Merkle tree, anchor the root on-chain, then replicate. The default chunk size is stated as 8KB. That number matters more than it looks, because it fixes the granularity of every Merkle proof the network produces and every retrieval verification a client performs.

EigenLayer, Snowbridge and what the contracts directory actually holds

The security model is the reason this repository has a contracts directory alongside a Substrate node. DataHaven validators register as EigenLayer operators, and the README names two AVS contracts on Ethereum L1: DataHavenServiceManager for validator lifecycle and slashing, and RewardsRegistry for validator performance and rewards. Communication between L1 and the Substrate chain goes over Snowbridge, described as trustless cross-chain messaging for tokens and messages. The repository layout puts Solidity sources under contracts/src, deployment scripts under contracts/script and Foundry test suites under contracts/test. So the trust boundary is not inside the Substrate chain alone. A validator's economic exposure is defined by an Ethereum contract, and the Substrate runtime consumes that state through a bridge. That is a meaningful design commitment, and it means an incident in either layer is an incident for the whole system. The README does not describe how bridge latency or bridge failure affects proof challenge timing, which is the question I would want answered before relying on slashing as a real deterrent.

Building and launching: prerequisites and directory-level entry points

The Quick Start lists five prerequisites and no installation commands beyond the links: Kurtosis for network orchestration, Bun v1.3.2 or later as the TypeScript runtime, Docker for containers, Foundry for the Solidity toolkit, and Rust for building the operator. The README points at per-directory documentation rather than inlining build steps, with operator/README.md covering node building and runtime development, contracts/README.md covering smart contract work, test/README.md covering E2E testing and network deployment, and deploy/README.md covering Kubernetes. The test tree is where a local network comes from: test/suites holds integration scenarios, test/framework holds helpers, and test/launcher holds network deployment automation. Deployment for real environments is Helm charts under deploy/charts and environment-specific configuration under deploy/environments. Runtime configuration for mainnet, stagenet and testnet lives in operator/runtime. The practical consequence is that a first run means reading four READMEs, not running one command, and the launcher expects Docker and Kurtosis to already be working on the host.

Where DataHaven is the wrong tool

The chunk size is the clearest limitation. An 8KB default is a reasonable unit for Merkle commitments, but it is a poor unit for large media files or model checkpoints, where the proof overhead per byte of payload is high and retrieval becomes a reassembly problem. The README does not describe a streaming retrieval path or a way to raise the chunk size per bucket, so I cannot confirm either exists. The second constraint is operational weight. Running a node means Rust, a chain spec, and a runtime configuration chosen from mainnet, stagenet or testnet. Running a provider means the MSP Backend service on top of that. Running a full local network means Docker and Kurtosis. None of that is unreasonable for a storage operator, and all of it is unreasonable for an application developer who just wants durable object storage with an HTTP client. Third, the README's own description of verification is aspirational in one respect: it says retrieval returns files with Merkle proofs that users verify against on-chain commitments, but it does not specify which client library performs that verification or what the failure path looks like when a proof does not match. Until that is documented, treat client-side verification as something you would have to build.

How this differs from Filecoin and Arweave

The comparison that matters is with Filecoin. Filecoin's storage market matches clients to miners through on-chain deals, and its proof system is built into the L1 consensus: storage proofs are a first-class consensus concern, and the chain exists largely to carry them. DataHaven inverts the relationship. The Substrate chain runs the file system, provider registry, proof dealing, payment streams and bucket NFTs as pallets, while the economic security for validators is rented from Ethereum through EigenLayer rather than bootstrapped by the storage token itself. That is the whole point of the AVS pattern, and it means DataHaven inherits Ethereum restaking exposure instead of running its own validator economy from zero. Arweave takes a third approach entirely, paying once for permanent storage rather than running recurring proof challenges. DataHaven is neither: it is a recurring-challenge network with a rented security layer and EVM compatibility bolted on via Frontier. The EVM compatibility is the differentiator worth weighing, because it means existing Solidity contracts can address storage operations directly rather than through a separate chain's SDK.

Licence, release cadence and the cost of staying current

DataHaven is GPL-3.0. For anyone building on the node or runtime, that is a copyleft obligation that reaches derivative works distributed to others, which is a different proposition from the permissive licences common in the Substrate ecosystem. If you intend to fork the runtime and ship a modified chain, the licence question belongs with your own counsel before you write code, not after. The contracts directory is a separate question I cannot answer from the README, since it does not state a licence for the Solidity sources independently of the repository licence. On cadence, the release list shows v0.25.0 on 2026-02-25, v0.26.0 and Runtime RT1400 both on 2026-03-12, and the repository's last push on 2026-04-17. The pairing of a node release with a separate runtime release tag is the detail to watch: runtime upgrades on a Substrate chain are governance actions, and RT1400 landing the same day as v0.26.0 suggests the two are expected to move together. A provider or validator that tracks the node but lags the runtime is running a configuration the release process does not appear to test. Budget for reading release notes on every runtime tag, not just every node tag.

Who should pick this up, and what to check on day one

The audience here is storage operators and infrastructure teams who already run Substrate or Ethereum validator infrastructure and want a storage network where slashing is backed by restaked ETH rather than a new token. Application developers building AI data pipelines are the second audience, but only if they are willing to depend on the MSP Backend service and the Indexer's PostgreSQL-backed metadata queries rather than a managed API. Teams that want a client library, a hosted endpoint, or a per-file pricing page should look elsewhere for now, because the README does not describe any of those. Before committing, check three things in the repository itself. First, whether operator/runtime contains a chain spec for the network you intend to join, since the README only names mainnet, stagenet and testnet as configuration categories. Second, whether the StorageHub pallet versions the runtime pins match the ones you plan to build against, because DataHaven is built on StorageHub and a version skew there is a build failure, not a runtime warning. Third, whether test/launcher's Kurtosis setup brings up the Indexer and Fisherman alongside the providers, since a local network without them will not exercise the challenge path you are trying to evaluate.

Editorial conclusion

Adopt DataHaven only if you are prepared to run Substrate infrastructure and read the operator, contracts, test and deploy READMEs before touching the Kurtosis launcher; teams that want a hosted storage API or a single-language SDK should not start here. Verify first that the runtime directory contains a chain spec matching the network you intend to join, and that the StorageHub pallet versions referenced by the runtime match the ones you expect to build against.

Official sources

1. datahaven-xyz/datahaven on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases