# DataHaven: Decentralized Storage Secured by EigenLayer Restaking

> DataHaven is a verifiable decentralized storage network built on Substrate and secured by Ethereum validators through EigenLayer restaking. It chunks files into Merkle trees, anchors commitments on-chain, and assigns storage providers to replicate data with cryptographic proof of custody.

**datahaven-xyz/datahaven** — An EVM compatible Substrate chain, powered by StorageHub and secured by EigenLayer

- Repository: https://github.com/datahaven-xyz/datahaven
- Website: https://datahaven.xyz/
- Stars: 7,887 · Forks: 146
- Language: Rust
- License: GPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/datahaven-xyz-datahaven

## Off-chain storage with on-chain Merkle proof verification

DataHaven separates storage from verification: files live off-chain with storage providers while cryptographic commitments anchor on-chain, enabling applications to prove data integrity without trusting intermediaries. The network splits responsibility between Main Storage Providers (MSPs), who handle retrieval and serve user uploads, and Backup Storage Providers (BSPs), who replicate data across the network and face on-chain slashing if they fail proof challenges.

The system is designed for AI training datasets, machine learning models, and Web3 applications where data integrity matters. A user uploads to an MSP, the bot chunks files into 8KB segments, hashes them into Merkle trees, and anchors the root on-chain. The MSP coordinates BSP replication according to bucket policy. On retrieval, the MSP returns files with Merkle proofs; users verify the proofs against on-chain commitments. BSPs face periodic randomized challenges to prove they still hold the data; failure triggers on-chain slashing.

## Architecture: Substrate, EigenLayer, and Snowbridge

DataHaven is written in Rust on Substrate with EigenLayer integration and EVM support via Frontier pallets. Validators register as EigenLayer operators via the `DataHavenServiceManager` contract on Ethereum and secure the network through ETH restaking. Slashing for validator misbehavior is enforced separately from BSP slashing, which is on-chain. A `RewardsRegistry` contract tracks validator performance and distributes performance-based rewards. Separate from validators, BSPs face on-chain slashing via StorageHub pallets when they fail proof challenges or misbehave.

Cross-chain bridging with Ethereum is handled natively via Snowbridge, enabling trustless token and message passing. The Snowbridge relayers in the test environment handle bidirectional communication between the DataHaven chain and Ethereum. The repository is organized into contracts (EigenLayer AVS smart contracts for validator lifecycle and rewards, including the DataHavenServiceManager), operator (Substrate node with custom pallets for validators, rewards, and transfers), and test (E2E framework with integration scenarios). The operator node supports runtime configurations for different environments: mainnet, stagenet, and testnet, each with distinct security and performance parameters. The custom pallets handle the core storage and validator logic, while Frontier enables native EVM contract execution and compatibility with Ethereum tooling.

## Launch and local testing with Kurtosis

Starting a local DataHaven network requires Kurtosis for orchestration, Bun 1.3.2+ as a TypeScript runtime, Docker, Foundry, and Rust. These prerequisites handle container management, TypeScript builds, smart contract compilation, and operator node building respectively. Install all of them, then launch the network:

```bash
cd test
bun i
bun cli launch
```

The interactive launcher is a guided setup that deploys a complete test environment including 2 Ethereum execution clients (reth), 2 consensus clients (lodestar), block explorers (Blockscout for Ethereum, Dora for consensus metrics), a single DataHaven validator with fast block times, MSP and BSP storage provider nodes for testing the replication protocol, EigenLayer AVS contracts deployed on Ethereum, and Snowbridge relayers for bidirectional cross-chain communication. The launcher prompts you for configuration options and outputs connection URLs and credentials for each service, allowing you to interact with the network immediately. The test README documents additional launch options and configuration parameters for different testing scenarios.

## Running E2E tests and development workflows

After launch, run integration tests to verify the storage and verification pipeline:

```bash
cd test
bun test:e2e
bun test:e2e:parallel  # Limited concurrency for large test suites
```

Add `INJECT_CONTRACTS=true` to skip initial contract deployment and speed up setup. For smart contract development, the contracts directory contains Foundry test suites:

```bash
cd contracts
forge build
forge test
```

Node development uses Rust tooling:

```bash
cd operator
cargo build --release --features fast-runtime
cargo test
./scripts/run-benchmarks.sh
```

When you modify contracts or the runtime, regenerate bindings:

```bash
cd test
bun generate:wagmi  # Contract bindings
bun generate:types  # Runtime types
```

## Storage mechanics, proof challenges, and data replication

DataHaven's verification model relies on deterministic chunking and Merkle trees. Files are split into 8KB chunks, hashed into a Merkle tree, and the root is anchored on-chain as a commitment. Users uploading to an MSP trigger a bot process that chunks the file, generates the Merkle tree, and commits the root to the blockchain. The MSP coordinates replication: BSPs download the file from the MSP and replicate locally according to the bucket's replication policy. Each bucket is summarized by a Merkle-Patricia trie root on-chain, providing a compact proof of the full bucket's contents.

Ongoing custody is verified through randomized proof challenges. A fisherman service monitors proof submissions and triggers challenges when misbehavior is suspected. BSPs must prove data possession within a challenge window; failure results in on-chain slashing via StorageHub pallets. Users verifying data retrieval receive Merkle proofs from the MSP and verify them against the on-chain commitment without trusting intermediaries. This design ensures data availability without requiring continuous file transmission. Providers only need to demonstrate they have the data when challenged. MSPs offer data retrieval with competitive service offerings; they are user-selected and perform actual data serving. The economic incentives align: MSPs compete on retrieval speed and reliability, while BSPs earn through rewards but face financial penalties for misbehavior.

## The two-tier provider model and incentives

MSPs are chosen by users and serve data on demand. BSPs are network-assigned for redundancy and face slashing for failed proof challenges. An indexer service tracks on-chain storage events for efficient querying. The two-tier design creates incentives: MSPs compete on retrieval speed and reliability; BSPs earn through rewards but face financial penalties for misbehavior.

DataHaven validators register as EigenLayer operators and earn performance-based rewards distributed by the `RewardsRegistry`. Economic security comes from ETH restaking: validators who misbehave lose a portion of their staked Ethereum. This creates a shared security model where Ethereum's validator set secures DataHaven's storage claims.

## Release cycle, Helm for Kubernetes, and runtime configuration

The last push to DataHaven was on 2026-04-17, about five months ago. Recent releases include v0.26.0 (2026-03-12), RT1400 (2026-03-12), and v0.25.0 (2026-02-25). The project is not archived and continues to receive updates.

Production deployments use Helm charts stored in the `/deploy/` directory for Kubernetes orchestration. The repository structure separates concerns: `/contracts/` holds the EigenLayer AVS smart contracts including the ServiceManager and RewardsRegistry; `/operator/` contains the Substrate node with custom pallets for validators, rewards, and transfers; `/test/` provides E2E testing frameworks and network orchestration via Kurtosis; `/tools/` houses development utilities. Each directory includes its own README with detailed setup instructions. The `/deploy/README.md` documents Kubernetes-specific configuration for production environments. Local testing uses Docker containers and Kurtosis for complete network simulation. Development is governed by biome.json for code formatting and linting standards. The codebase is written in Rust using the Substrate framework for the operator node, with smart contracts in Solidity via the contracts directory.

## Conclusion

Use DataHaven if you need cryptographically verifiable storage for datasets you cannot afford to lose, with governance by Ethereum validators and storage providers who face slashing for misbehavior. Do not use it if you need fast, centralized cloud storage or if you are unfamiliar with running Kurtosis test environments. Before deploying, install Kurtosis, Bun 1.3.2+, Docker, Foundry, and Rust; verify the setup with `bun cli launch` to test the complete network stack locally.

## FAQ

### What happens if a Backup Storage Provider fails a proof challenge?

BSPs face on-chain slashing via StorageHub pallets. Failure to prove data custody during a randomized challenge results in financial penalties enforced on-chain.

### How does DataHaven provide security if storage is off-chain?

DataHaven anchors cryptographic commitments (Merkle tree roots) on-chain and enforces proof challenges. Validators secure the network through EigenLayer restaking on Ethereum, creating economic incentives for honest behavior.

### Can I run DataHaven on my laptop?

Yes. The test environment using Kurtosis runs on any machine with Docker, Kurtosis, Bun, Foundry, and Rust installed. The interactive launcher `bun cli launch` deploys a complete network locally.

### What are the prerequisites for smart contract development?

Install Foundry from https://getfoundry.sh/. In the contracts directory, run `forge build` to compile and `forge test` to run test suites.

### What does the DataHavenServiceManager contract do?

DataHavenServiceManager handles validator lifecycle and slashing on Ethereum. It allows validators to register as EigenLayer operators and enforces slashing for misbehavior.

## Sources

- [datahaven-xyz/datahaven on GitHub](https://github.com/datahaven-xyz/datahaven)
- [License: GPL-3.0](https://github.com/datahaven-xyz/datahaven/blob/main/LICENSE)
- [Project website](https://datahaven.xyz/)
- [README](https://github.com/datahaven-xyz/datahaven/blob/main/README.md)
- [Releases](https://github.com/datahaven-xyz/datahaven/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/datahaven-xyz-datahaven