Litepaper
Table of Contents
Platform Architecture
Platform Components
DataHaven’s foundational architecture as a Layer 1 blockchain, built using the Substrate framework, enables deep-level customizations at the core protocol level that go beyond the capabilities of smart contracts. These inherent optimizations are crucial for effectively serving DataHaven’s intended use cases. The following sections detail the additions made to the runtime and client to add full Ethereum compatibility and decentralized storage capabilities, and for the chain to operate as an EigenLayer AVS and therefore benefit from Ethereum’s shared security.
DataHaven Runtime
Aside from managing accounts and balances, the DataHaven runtime will offer a set of powerful capabilities that are commonly included in Substrate-based chains, including support for proxy accounts (proxy pallet), account identities (identity pallet), transaction batching (utility pallet), multi-signature operations (multisig pallet), and scheduled and delayed operations (scheduler pallet).
Consensus and Finality
For consensus, DataHaven will use a typical hybrid model composed of a block production mechanism and a finality gadget for probabilistic and provable finality. The target block time will be six seconds. DataHaven will use the BABE slot-based block production mechanism based on a known set of validators with a randomized slot assignment. The block author will be selected pseudo-randomly out of an active set of validators provided to the block authoring mechanism by the EigenLayer AVS integration (based on registered AVS operators on EigenLayer). DataHaven will use the GRANDPA gadget for block finality.
Native Bridge to Ethereum
DataHaven’s chain runtime will feature a trust-minimized native bridge to Ethereum—an extremely rare and highly secure approach in the blockchain ecosystem. Unlike most bridges, which rely on significant trust assumptions, DataHaven’s bridge is built directly into the protocol, eliminating the need for additional external trust layers when transferring assets or data between Ethereum and DataHaven. This design is made possible by leveraging a custom Layer 1 with verifiable proofs via BEEFY, ensuring seamless and secure bridging, much like the native bridge of a rollup.
To achieve this, DataHaven will integrate BEEFY alongside GRANDPA finality, allowing its Ethereum-based AVS to track finalized headers efficiently. It will also support EigenLayer shared security, token transfers, and cross-chain smart contract operations. Built on Snowbridge, a decentralized bridge between Polkadot and Ethereum, the DataHaven Bridge will reuse critical components (e.g., `snowbridge-pallet-ethereum-client`) while customizing others (e.g., system and queue pallets) to fit its needs.
Additionally, DataHaven will enable generic message passing for cross-chain interoperability, utilizing Polkadot SDK components (e.g., `pallet-bridge-messages`) and developing new pallets to support arbitrary message formats beyond XCM. The team will fork Snowbridge’s pallets for enhanced functionality tailored to DataHaven’s architecture.
AVS Support (EigenLayer)
The DataHaven chain runtime will integrate capabilities to make it operate under the shared security model provided by EigenLayer. More concretely, the active set of validators will be provided by the DataHaven AVS, and the validator rewards will be sent to the DataHaven AVS. The active list of DataHaven AVS operators will be cached in a new, special-purpose Substrate pallet. The list of validators will be updated through messages transiting from Ethereum to DataHaven via the native bridge. This pallet will also track and report validator rewards based on authored blocks to the DataHaven AVS on Ethereum—again, with messages transiting over the native bridge.
Ethereum Compatibility
DataHaven will provide Ethereum compatibility by integrating core features from Moonbeam, including:
- EVM compatibility (via Frontier) allowing Ethereum smart contracts written in Solidity, or other languages targeting the EVM, to run unmodified.
- Ethereum-style Accounts (H160) thanks to Moonbeam’s unified account system.
- Moonbeam precompiled contracts exposing the chain’s runtime core features to the EVM layer for seamless integration in smart contracts.
- Moonbeam transaction fees model.
It is worth noting that Frontier provides a high degree of EVM compatibility, with a proven track record deployed on Moonbeam boasting hundreds of deployed applications/protocols and over 80M EVM transactions to date.
Bridged & Native Assets
DataHaven will support foreign (bridged) assets (i.e. wrapped / derived versions of native ETH or ERC20 tokens on Ethereum) transferred to the DataHaven chain via the native bridge. These will seamlessly interoperate with smart contracts deployed on DataHaven. DataHaven may also support native assets exposed to the EVM layer as ERC20, similarly to assets and foreign assets on Moonbeam.
DataHaven Storage
DataHaven will come built-in with decentralized storage capabilities by integrating features of the StorageHub project—a storage-optimized collection of Substrate pallets focusing on efficient and decentralized data storage. This addresses the need for scalable, secure, and decentralized storage enabling applications to seamlessly access, utilize, and manage storage even in cross-chain deployments.
DataHaven ensures efficient and reliable storage using Merkle cryptographic structures, including Merkle Patricia Forests to manage onchain storage with cryptographic summaries instead of per-file records. It also employs Merklized Files for Storage Proofs, challenging providers to prove they are storing files by verifying random chunks.
Storage Runtime Pallets
Several StorageHub Pallets (modules) will form part of the DataHaven runtime in order to provide the coordination and management of storage operations. The File System Pallet allocates files to storage providers using Merkle Patricia Forests, managing storage requests and deletions with cryptographic methods to minimize onchain storage. The Storage Providers Pallet handles Main Storage Providers (MSPs) and Backup Storage Providers (BSPs), tracking MSP data retrieval and BSP redundancy, with token collateral and capacity-based price adjustments. The Storage Proofs Pallet generates and verifies storage proof challenges, enabling storage providers to charge for services while distributing challenges based on stored data.
Main Storage Providers (MSPs)
DataHaven’s storage enables flexible interactions between users or applications and MSPs. MSPs offer data retrieval services, with multiple customizable implementations at different costs. DataHaven allows AI agents and developers to discover MSPs based on services and value, and ensures transparency by recording agreements. MSPs earn revenue from storage services, with users paying for file storage, thereby incentivizing reliable solutions. MSPs manage file “buckets,” with each linked to the provider and secured by a Merkle Patricia Forest stored onchain.
Backup Storage Providers (BSPs)
BSPs ensure data reliability and redundancy in a decentralized network, backing up data to keep it available even if an MSP fails. BSPs must hold collateral that can be slashed if data is lost, and they have lower operational costs since they only perform occasional peer-to-peer retrieval. Each file stored by a BSP is split into chunks, “merklized,” and linked to a file key, with the root stored onchain as proof of storage. BSPs are periodically challenged to submit proof of storage, with challenge frequency based on storage size. A Fair Distribution mechanism prevents front-running, allowing all BSPs the chance to volunteer for new storage requests.
Fisherman Nodes
Fisherman nodes enable verifiable file deletion in the DataHaven network. When a user initiates a deletion request, a fisherman listens for the event, constructs proofs showing that the file is currently stored by the corresponding MSP and BSPs, and submits them onchain. This process updates the onchain storage commitments for the relevant providers, effectively removing the file from their Merkle Patricia Forests. By ensuring that deletions are trustless and cryptographically verified, fisherman nodes help maintain accurate accounting and prevent storage providers from charging for files that users no longer want or are no longer obligated to pay for.
DataHaven Client
Generic Capabilities
The DataHaven client will come built-in with the typical JSON-RPC APIs that can be found in most Substrate-based chains (based on the modules—aka pallets—included in the chain’s runtime).
Ethereum RPCs
The DataHaven client will offer full JSON-RPC compatibility with Ethereum, and thus compatibility with existing dApps, wallets, and development tools and libraries.
AVS RPCs
The DataHaven client will expose specific JSON-RPC APIs to facilitate operations related to the EigenLayer AVS operators.
StorageHub RPCs
The DataHaven client will expose the standard StorageHub JSON-RPC APIs to facilitate file, metadata, and storage proof-related operations.
EigenLayer and the DataHaven AVS
EigenLayer
EigenLayer is a protocol built on Ethereum that introduces re-staking, a new primitive for Web3 builders that provides a “marketplace for trust,” bringing together restakers, operators, and AVSs. It allows users to stake assets such as Native ETH, Liquid Staking Tokens (LSTs), the EIGEN token, or any ERC20 token into EigenLayer smart contracts, thereby extending Ethereum’s cryptoeconomic security to additional applications on the network. For more background information on the EigenLayer protocol, consult the official documentation.
DataHaven AVS
DataHaven will function as an EigenLayer AVS, benefiting from Ethereum shared security and providing seamless interoperability between contracts and assets on DataHaven and the Ethereum network. Generally speaking, an AVS is composed of onchain contracts (on Ethereum) for validation and an off-chain network of operators. Operators execute the service on behalf of the AVS and then post evidence of their execution onchain to the AVS contracts. If the operators perform the tasks properly, the AVS can distribute rewards; if operators perform poorly or with malicious intent, their delegate stake can be slashed by the AVS, and the operator can be removed from the operator set.
In the case of DataHaven, this implies the following: DataHaven is registered on EigenLayer as an AVS, and operators can opt-in to provide validation services (that is, act as validators by running the DataHaven node binary) for the DataHaven network.
On the Ethereum side, the DataHaven project will deploy several contracts to operate as an AVS:
- A ServiceManager contract, implementing the base IServiceManager interface
- An OperatorManager contract, handling registration of operators and maintaining a list of active / selected operators
- A RewardsProxy contract, mediating the rewards (or points) calculated on the DataHaven chain and submitting the reward list to the EigenLayer RewardCoordinator contract
- A ServiceUpgrader contract, to support upgrades of the DataHaven AVS contracts
- A BeefyVerifier contract, to verify BEEFY commitments from the DataHaven chain (using the Snowbridge onchain Beefy light client), periodically relayed by the DataHaven-ETH bridge relayers
- A root DataHaven AVS contract, coordinating the operations of the DataHaven AVS and coordinating the communication with the DataHaven Bridge
Operators & Rewards
The DataHaven AVS contract will maintain a list of selected operators and emit events for updates. This list will be relayed via the DataHaven Bridge to the DataHaven chain to update the validator set. In return, DataHaven will send the current reward shares of active validators through the bridge to the AVS contract and then to the EigenLayer RewardCoordinator to issue staking and delegating rewards.
DataHaven Bridge
DataHaven will integrate Snowbridge as a DataHaven-Ethereum bridge, reusing existing contracts and infrastructure, modified to fit the needs of the project. The DataHaven Bridge includes an onchain Beefy light client (Solidity) contract, a Gateway contract for relaying and routing messages, and other supporting contracts (types, primitives, proxy accounts, etc.). These have been modified to support ECDSA signatures and non-XCM based messaging for the DataHaven AVS implementation.
Bridge Message Execution
The DataHaven-ETH bridge will need the following types of messages:
- DataHaven-specific operational messages, e.g. update of AVS operators list (ETH → DataHaven); update of the reward shares / list (DataHaven → ETH)
- Well-known message types, e.g. cross-chain asset / token transfer (burn & mint)
- Arbitrary messages: execution of smart contracts functions on DataHaven (call from Ethereum) or on Ethereum (call from DataHaven)
While the DataHaven Bridge is relying on the Polkadot XCM message format for all messages, it will be extended to support additional or arbitrary message formats.
DataHaven Bridge Relayers
As described above, DataHaven will have its own decentralized, trustless bridge solution to Ethereum. The relayers are off-chain, untrusted services watching two Blockchain networks, and relaying messages across them. The DataHaven project will integrate modified versions of the existing Snowbridge relayers, namely:
DataHaven → Ethereum
- BEEFY relay: relays signed BEEFY commitments and proofs from the DataHaven chain to the BEEFY light client contract on Ethereum
- Message relay: relays message commitments and proofs from the DataHaven chain to inbound channel contracts on Ethereum
Ethereum → DataHaven
- Header relay: relays Ethereum Beacon chain headers, Execution chain headers and Sync Committees to the Ethereum light client pallet on the DataHaven chain
- Message relay: relays messages emitted by outbound channel contracts on Ethereum to the DataHaven chain
