Distributed Storage Layer
To avoid the cost and scalability issues associated with storing large volumes of activity and sensor data directly on-chain, DEAP Network utilizes decentralized storage technologies such as IPFS, Filecoin, and Arweave to store the majority of the data off-chain. These storage layers are designed to distribute data redundantly across multiple nodes, ensuring high availability and tamper resistance so that users never lose access to their data even if some nodes go offline. Once data is stored, its hash (content ID) and associated metadata are recorded on the L1 chain via smart contracts, enabling easy verification of data integrity. Additionally, consensus mechanisms like "Proof of Storage" or "Proof of Resource" are applied to storage nodes, incentivizing those that correctly maintain the data. Users and service providers can retrieve data by specifying the content ID via gateways or through P2P methods, ensuring continued data availability through redundant copies even if some nodes fail.
L1 Chain Layer
DEAP Network will deploy its own PoS (Proof of Stake) L1 chain, built on a technology stack ( Avalanche L1), to achieve reliable finality, relatively high transaction processing performance (TPS), low fees, and robust governance features. Validators—key nodes maintaining the network—are responsible for transaction validation and block production, earning staking rewards in the process. On this chain, metadata such as data hashes, owner addresses, access conditions, and incentive issuance logic for data uploaded to the decentralized storage are recorded, ensuring that information regarding who uploaded which data and under what rules remains immutable. Moreover, the incentive model and governance mechanisms are automated via smart contracts, enabling transparent and decentralized operations for token issuance, staking rewards, and fee distribution. Through on-chain voting, the community can adjust fees, parameters, and protocol updates, ensuring high levels of transparency and decentralization.
Application Layer
Users interact with the DEAP Network through web or mobile client applications, which enable them to upload, view, and share activity data. These client apps incorporate local security processes such as wallet integration (via Account Abstraction), communication with decentralized storage gateways, encryption, and digital signing, allowing users to handle their data without needing to understand the underlying complex technology. Furthermore, to facilitate seamless integration with various external services (service providers) such as games, social networks, and healthcare apps, we provide APIs using REST, GraphQL, and gRPC, along with integrated SDKs and comprehensive developer documentation. We also plan to integrate visualization and analytics tools, including graph displays, dashboard aggregations, and AI analytics platforms, along with support for zero-knowledge proofs (ZKP) to ensure that data is disclosed only within the user-approved scope.
Modular Architecture
Data Ingestion Module
DEAP Network provides a mechanism to convert activity data collected from various sources—including wearable devices, smartphones, and web applications—into a standardized format (such as JSON or Protocol Buffers) before passing it to the encryption module. A dedicated SDK for data collection is provided for service providers, allowing them to integrate with the network with only minimal code changes. Furthermore, we are planning to implement technologies like zkTLS in the future to enable secure, real-time log retrieval over encrypted communication channels. To accommodate unstable network environments, the system also considers buffering data on the device temporarily, with batch transmission and rate control, to ensure efficient data transfer according to the network conditions.
The following table shows an example of the data format used by DEAP Network’s Data Ingestion Module. This example illustrates how activity data collected from various sources is standardized (e.g., in JSON format) before being passed to the encryption module. Actual implementations may use Protocol Buffers or a custom JSON schema; this table is provided as a representative structure.
Field | Type | Example | Description |
version | string | "1.0" | Data Format Version:
Clearly specify the version of the data format to ensure backward and forward compatibility. |
deviceId | string | "wearable-abc123" | Device ID:
A unique identifier for the device generating the data (e.g., wearables, smartphones). |
appId | string | "com.example.fitnessApp" | Application/Service ID:
The identifier for the app or service collecting the data. For web applications, the domain name may be used. |
userId | string | "user-xyz789" | User Identifier:
An identifier assigned to the user within the device or app, which is used later in encryption modules or wallet integration to uniquely track user accounts. |
dataType | string | "STEP_COUNT" | Data Type:
A field that specifies the type of data (e.g., "STEP_COUNT", "LOCATION", "HEART_RATE", "GAME_SCORE", etc.). |
timestamp | number | 1680001234 | Timestamp:
The time at which the data was generated or captured, represented in Unix epoch time. |
payload | object / array | { "steps": 12000, "units": "count" } | Payload:
An object that contains the actual activity data. For example, for step count data, it might be {"steps": 12000}, or for location data, {"lat": 35.6895, "lon": 139.6917}. When multiple elements are involved, an array structure should be used. |
metadata | object | Metadata:
An object that includes supplementary information such as the format version, category, tags, sensor accuracy, and other detailed metadata. | |
metadata.formatVersion | string | "2.0" | Payload Format Version:
The version of the format or schema used for the payload section. |
metadata.tags | array of strings | ["morning", "exercise"] | Tags:
Descriptive tags representing the content or purpose of the data, which can be used as filtering criteria during analysis and visualization. |
metadata.acquisitionMethod | string | "continuous" | Acquisition Method:
A string indicating how the data was collected (e.g., "continuous", "batch", "triggered"). |
metadata.buffered | boolean | TRUE | Buffered Flag:
A flag indicating whether the data was temporarily buffered on the device due to unstable network conditions. |
metadata.encryptionPlanned | boolean | FALSE | Encryption Status:
A flag indicating whether the data has been encrypted on the client side before being passed to the encryption module (set to false if not yet encrypted, and true if already encrypted). This is intended for future scenarios where client-side encryption is anticipated. |
signature | string (Base64) | "base64EncodedSignature" | Signature:
A signature generated by the user's device or application to prevent tampering. This signature may be attached just before the data is passed to the encryption module or applied within the module, depending on the implementation. |
zkTLSFlags (Option) | object / array | { "enabled": false } | zkTLS Settings (Optional):
Configuration settings for future secure log retrieval over encrypted channels (e.g., {"enabled": true, "protocolVersion": "draft-XX"}). |
batchInfo (Option) | object | { "size": 5, "intervalSec": 60 } | Batch Information (Optional):
Information about batch transmission, such as the number of data entries buffered and the transmission interval, which helps control the upload frequency. |
Encryption/Signing Module
By adopting an end-to-end encryption model, user activity data is encrypted on the client side using the user’s private key. This ensures that data stored in our storage remains encrypted at all times, thereby mitigating the risk of malicious storage nodes accessing its contents. Furthermore, signed transactions provide on-chain proof of which user (or which service ID) uploaded the data and when, making it easy to detect any unauthorized modifications. In the future, we plan to leverage zero-knowledge proofs such as ZK-SNARKs or ZK-STARKs to validate the legitimacy of the data without revealing its specific content.
Smart Contracts (On-Chain) Module
Smart contracts deployed on the L1 chain record essential information, including data hashes, owner addresses, access conditions, and incentive issuance logic. Transactions are executed at the time of data uploads and access updates. For example, when data is accessed, a fee is charged, and rewards—such as node operation incentives and data usage fees—are automatically distributed through these contracts. Critical protocol functions like governance, staking, and token issuance/burning are also integrated into the smart contracts, ensuring decentralized management and minimizing the risk of arbitrary intervention by administrators.
Storage Integration (Off-Chain) Module
Using gateways and node management functions, our system facilitates smooth uploads and downloads between users or applications and decentralized storage. Gateways perform hash verification and access rights checks, while regularly conducting health checks on storage nodes to maintain the overall reliability of the network. In cases such as with IPFS, a pinning feature is used to ensure that important data is persistently stored across multiple nodes. Additionally, caching and failover mechanisms are implemented to enable fast and stable content retrieval. We are also considering the integration of multiple storage solutions such as Filecoin and Arweave.
Node Operator (Validator/Storage Node)
Within DEAP Network, validator nodes execute transaction validation and block production using a PoS system, earning rewards based on their honest operational performance. Meanwhile, storage nodes focus exclusively on data storage and provision, earning rewards according to factors such as stored data volume and uptime. The performance and reputation of nodes are made transparent via on-chain records or dedicated dashboards, enabling users to easily select reliable nodes. Our design prioritizes long-term, stable node operations and rigorous integrity verification, applying penalties—such as partial stake slashing or reward suspension—for any misconduct or prolonged downtime, thereby enhancing the overall security of the network.
API & SDK Module
For developers, DEAP Network offers APIs and SDKs that enable easy integration with its core functionalities, such as data registration, access management, and reward calculation. We provide libraries for major programming languages including JavaScript/TypeScript, Python, Go, and Rust, allowing DApp developers and service providers to quickly and efficiently integrate with our ecosystem. In addition, testnet and staging environments are available to ensure that developers can safely experiment and build their applications.
Account Model
DEAP Network adopts an account model that empowers users to autonomously manage their activity data collected from various connected services and receive rewards. By leveraging account abstraction, we offer wallets that can flexibly combine multiple signature methods and security policies, as well as advanced features such as social recovery in cases of loss or theft.
When data is accessed or utilized, the corresponding DEP tokens are automatically distributed to the user’s wallet via smart contracts. Upon completing KYC after provisional registration, users are assigned a DEAP ID that is recorded on-chain, unlocking functionalities such as transferring tokens to external exchanges. The KYC process requires only minimal personal information, and by using zero-knowledge technology, we aim to enable users to prove that they are “KYC-approved” without disclosing detailed personal data.
User Flow
Data transmitted to the DEAP Network is stored and linked to each user's dedicated wallet. Consumers who wish to use this data must pay using DEP, which is then distributed to the user’s wallet via smart contracts.
User wallets are created through Account Abstraction. When users wish to withdraw the rewards earned from data usage, they must complete account linking and KYC, and create a DEAP ID.
For example, if a user named Bob has accumulated activity data through a service called A, Bob would first create an ID on the DEAP Network portal. At that point, his account is not yet linked to any wallet. Subsequently, Bob selects the service he uses from the list of data-integrated services and performs ID authentication.
Once authenticated, Bob’s rewards earned from service A are accumulated on his My Page, and he can then withdraw these rewards as desired.
- Data submitted to the DEAP Network is stored and linked to each user's dedicated wallet.
- Consumers who wish to use the data must pay using DEP, which is distributed to the user’s wallet via smart contracts.
- User wallets are created through Account Abstraction.
- To withdraw rewards earned from data usage, users must complete account linking and KYC to create a DEAP ID.
- For example, if a user named Bob accumulates activity data through a service called A:
- Bob first creates an ID on the DEAP Network portal; at this stage, his account is not linked to any wallet.
- Next, he selects the service he uses from the list of integrated services and completes ID authentication.
- Bob’s rewards from service A are then accumulated on his My Page, from which he can withdraw them as desired.
Data Flow
The data flow within the DEAP Network is broadly divided into the following steps: generation, encryption/signing, upload, on-chain recording, verification/reward distribution, and access/utilization. First, activity data generated by game applications, smartphones, wearables, and similar devices is encrypted locally (on the device or within the application) before being uploaded to decentralized storage. This process yields a hash (content ID) from systems such as IPFS. The hash, along with necessary metadata (such as owner information, access policies, and reward distribution rates), is then sent as a transaction to smart contracts on the L1 chain. Validators verify this transaction and confirm it on the blockchain. Storage nodes periodically prove that they are correctly maintaining the data and, separate from the PoS rewards, receive storage rewards. When users or developers wish to access or view the data, a dedicated indexer analyzes the latest on-chain information and provides a search API. This is followed by a process where access rights are confirmed by smart contracts and DEP payments are processed, after which the encrypted data is retrieved and decrypted via a gateway or through P2P methods. With each data access, rewards are automatically distributed and the access history is recorded on-chain, ensuring a fair and highly traceable record of data utilization.
Security Model
Data Confidentiality & Privacy Protection
DEAP Network employs an end-to-end encryption model in which activity data is encrypted on the client side using the user’s private key. As a result, data stored within our system is always encrypted, significantly reducing the risk of malicious storage nodes obtaining the content. Additionally, signed transactions provide on-chain proof of which user (or service ID) uploaded the data and when, enabling prompt detection of any tampering. In the future, we plan to implement zero-knowledge proof technologies such as ZK-SNARKs or ZK-STARKs, which will allow us to verify the legitimacy of actions—such as proving that a user has walked more than 10,000 steps or completed a particular course—without disclosing any specific details of the activity.
Data Integrity & Tamper Prevention
By comparing the data stored in the decentralized storage with the hash recorded on-chain, any tampering can be detected immediately. Moreover, only data signed by a user’s or service provider’s private key is accepted, thereby reliably proving who uploaded the data and when. Signature relay across the data collection chain further ensures smooth detection of alterations even in a highly decentralized environment.
Storage Node (Container Node) Health & Resistance to Attacks
Storage nodes (container nodes) are periodically required to provide cryptographic proofs to verify that they are maintaining data correctly; nodes that fail to do so do not receive rewards, and malicious nodes are excluded from the network. To prevent Sybil attacks, node participation requires staking a certain amount of DEP or meeting long-term operational and reputational criteria. The network as a whole adopts mechanisms similar to IPFS’s Distributed Hash Table (DHT) and employs redundant data storage. This ensures that even if individual nodes go down, automatic routing enables continued service availability.
Governance & Compliance
The governance process—from proposal submission to voting and execution—is managed by smart contracts, ensuring that key matters such as fee adjustments and protocol upgrades are determined by community consensus. Furthermore, because the network handles personal activity data, it is designed to incorporate features that comply with data protection regulations such as GDPR and CCPA. For instance, only KYC-approved accounts will be allowed to convert tokens into fiat currencies, among other tiered restrictions, thereby helping to prevent money laundering.