> For the complete documentation index, see [llms.txt](https://docs.bitdoctor.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bitdoctor.ai/bitdoctor-blockchain-technology-stack.md). # BitDoctor Blockchain Technology Stack
This document outlines the architecture for BitDoctor.AI, a decentralized system leveraging blockchain technology for managing health data, analysis, and rewarding contributors. The system incorporates **Decentralized Physical Infrastructure Networks (DePIN)** and **Decentralized Science (DeSCI)** principles to create a transparent, secure, and community-driven ecosystem. Additionally, it introduces a **Flywheel Effect** to drive network growth and a **Data Protocol Vision** that invites developers and researchers to build on top of anonymized health data. Note 1\) The final choice of blockchain architecture is **TBD**. We are still evaluating whether to deploy on our own **native blockchain** or use an **L2 solution** (e.g., Base) or **Solana**. 2\) The **LIV** points mentioned in this document are **in-game points** used to determine weightage for future airdrops; they are **not the final token.** ## 1. Core Components and Flow #### a) Data Sources **BitDoctor Smartphone AI Doctor:** \ \- Collect health metrics such as heart rate, blood pressure, heart attack risk, diabetes risk, etc. \ \- Forward the data to the system via the **BitDoctor Gateway.** **b) BitDoctor Gateway** \ \- **Entry Point:**\ Acts as the entry point for the collected data. \ \- **Processing and Forwarding:** \ **Blockchain (TBD):** For creating a decentralized identity (DID) and storing data hashes. \ **Centralized Databases or IPFS/Arweave**: For scalable storage of health data. **c) Blockchain (TBD)** \ \- **Data Integrity**: Ensures data integrity and security. \ \- **Decentralized Identity (DID)**: DID and data hashes are stored for transparency and validation. \ \- **Reward System**: Handles the reward system via a Reward Contract (using LIV points for distribution weightage, until final token is determined). **d) Data Storage** \ \- **Filecoin/Arweave**: Decentralized storage solutions for health data. \ \- **Centralized Database**: Backup or complementary storage for certain data needs. **e) BitDoctor Aggregator** \ \- **Data Aggregation and Analysis**: Aggregates health data and analyzes it. \ \- **Outputs**: Medical reports. Propensity for diseases. \ \- **Sharing**: Shares data with medical providers and AI agents for further use. **f) Consumers** \ \- **Stakeholders**: Medical Institutions, End Users, and Health Agencies. \ \- **Access**: These stakeholders pay (in tokens or other agreed-upon means) to access medical reports and health data insights. **g) AI Agents** \ \- **Enhanced Models**: Use the aggregated data to enhance AI-driven medical models for diagnostics or predictive analytics. \ \- **Tracking**: Contributors to these models are tracked using the Model Contributor Tracking system. h) **Reward System** \ **- Contributor Rewards**: Individuals providing BitDoctor application data are rewarded with LIV points (which may later translate to token allocations). \ \- **Management**: \ \&#xNAN;*Data Contributor Validator*: Validates data contributions. \ \&#xNAN;*Reward Contract:* Allocates points based on contributions. **i) Medical Providers** \ **Access**: Gain access to aggregated data and reports for diagnostics or treatment recommendations. ## 2. DePIN and DeSCI Integration ### Decentralized Physical Infrastructure Networks (DePIN) **a) Distributed Data Collection** \ \- Leverages BitDoctor application as physical infrastructure to collect health data. \ \- Incentivizes device owners through LIV points to participate in a contributing their data. **b) Infrastructure for AI Training** \ \- Uses distributed computing and data storage networks (e.g., Filecoin, Arweave) to support massive AI model training workloads. \ \- Reduces dependency on centralized entities, democratizing access to AI capabilities. **c) Network Security and Integrity** \ \- Ensures data collected from physical infrastructure is securely stored and accessible only through permissioned blockchain-based mechanisms. ### Decentralized Science (DeSCI) **a) Open Data for Research** \ \- Health data aggregated through BitDoctor is anonymized and shared with the global scientific community for disease research and predictive model development.\ \- Researchers can access data via a pay mechanism (or token model), ensuring contributors are rewarded fairly for their participation. **b) Transparent Model Development** \ All AI models developed using contributor data are anonymized and governed on-chain, ensuring transparency and accountability. **c) Collaborative Research Incentives** \ Encourages scientific collaborations by rewarding contributors whose data significantly enhances research outcomes, fostering innovation in healthcare. **d) DeSCI Tokenomics** \ A portion of institutional payments for medical data or AI models is reserved for funding decentralized scientific initiatives. ## 3. Reward and Tracking System #### a) Recognition and Rewards * Ensures contributors of data or models are recognized and rewarded. * DID and wallet information is used to ensure transparency in reward distribution (through LIV points). **b) Profit Distribution Contributors** \ to the AI models generating profits are identified, and LIV-based rewards are allocated accordingly. ## 4. Reward Distribution in LIV (Points) ### Reward Calculation **a) DID Creation** \ \- When a contributor logs in via the mobile app, a unique Decentralized Identifier (DID) is created (e.g., did:bitdoc:12345abc). \ \- The DID tracks the contributor’s data contributions, which are stored along with metadata about the data (e.g., type, volume, timestamp, relevance). \ \- The DID does not equate to a wallet but acts as a bridge between the contributor’s data and the reward (points) allocation process. **b) Wallet Linking** \ \- Contributors link their DID to a wallet address through the app. Mapping between the DID and the wallet is securely stored: { "DID": "did:bitdoc:12345abc", "Wallet": "0x12345abcdef67890" } \ \- If a wallet is not linked, the allocated points remain tied to the DID until claimed or converted (upon token launch). ### Data Collection **Contributor Participation** \ Contributor A uploads health data (e.g., heart rate, blood pressure) via their BitDoctor application. The system assigns this data to their DID (did:bitdoc:12345abc) and logs it with metadata: { "DID": "did:bitdoc:12345abc", "Data": { "Type": "Heart Rate, Blood Pressure", "Volume": "1,000 records", "Timestamp": "2025-01-01T10:00:00Z", "Relevance": "High" } } ### AI Model Training **Massive Data Pool** \ The Stroke Prediction Model is trained using data from 50,000 contributors. \ The system logs each DID whose data was used for training: { "Model": "Stroke Prediction Model", "Contributors": \[ { "DID": "did:bitdoc:12345abc", "Volume": 1000, "Relevance": "High" }, { "DID": "did:bitdoc:67890xyz", "Volume": 500, "Relevance": "Medium" } ] } ### Payment and LIV Allocation **a) Institution Payment** \ \- Suppose a hospital pays a certain amount (e.g., 100,000 tokens or a stablecoin equivalent) for access to the Stroke Prediction Model / data. \ \- A portion of that payment (e.g., 50%) is allocated to the reward pool for contributors. **b) Reward Pool Allocation** \ \- **LIV** points are allocated based on: Volume of data contributed. Relevance of the data (e.g., stroke-specific metrics may carry more weight). \ \- **Example Allocation**: * Contributor A’s data volume: 1,000 records. * Total data volume: 50,000,000 records (all contributors combined). * Contributor A’s share: \ \- Adjustments for relevance: High relevance multiplier (e.g., ×2): Contributor A earns 2 LIV points. **c) Reward Storage** Allocated points are stored on the blockchain (or sidechain) under the contributor’s DID until they are claimed: { "DID": "did:bitdoc:12345abc", "Allocated Points": 2 } ### DID-to-Wallet Mapping Example **a) Contributor Logs In** \ Contributor A logs into the system app and links their DID (did:bitdoc:12345abc) to their wallet (0x12345abcdef67890). **b) Mapping on Blockchain** The system records: { "DID": "did:bitdoc:12345abc", "Wallet": "0x12345abcdef67890" } **c) Claiming Process** \ \- Contributor A logs into the app and view the LIV points. Claimable tokens are determined based on the LIV points of the contributor. \ \- Contributor A clicks on the claim button and the system validates their wallet and processes the transaction, transferring tokens from the reward pool to their wallet. **d) Audit Log** Blockchain transaction log: \ { "Transaction ID": "tx123456", "DID": "did:bitdoc:12345abc", "Wallet": "0x12345abcdef67890", "Points Claimed": 2, "Timestamp": "2025-01-02T12:00:00Z" } ## 5. Token and Gas Mechanism (TBD) As mentioned, the final choice of **blockchain architecture** is still under discussion (native chain vs. L2 solutions like Base vs. Solana). The LIV points described here are not the final token but an in-game metric for airdrop weightage. Below is a conceptual overview, which may evolve: **Proposed Token Structure (Subject to Change)** **a) BitDoctor's Future Token (TBD)** \ \- The primary token within the BitDoctor ecosystem will be determined after the chain choice (native vs. L2). \ \- This token could be used for: \ i) Payments for accessing medical reports. \ ii) Rewards to contributors. **b) Gas Fee Mechanism** \ \- If BitDoctor launches its own network, gas fees could be denominated in the BitDoctor token or in a well-adopted gas token (e.g., ETH on L2, SOL on Solana). \ \- Until then, LIV points will serve as an internal reward and accounting mechanism. ### Cross-Chain Compatibility (Possible Directions) **a) Bridge to Popular Blockchains** \ \- To enhance liquidity in the future, bridging mechanisms may be implemented, allowing the final token to be interoperable with popular chains (e.g., Ethereum, BSC, Solana). \ \- LIV points, as an internal measurement, would eventually convert or unlock the final token. **b) Seamless Conversion** \ A bridging or conversion contract could facilitate the movement of tokens between ecosystems, ensuring holders can leverage multiple blockchain networks. ### Benefits of a Dedicated Mechanism **a) Efficiency (If Native or L2)** \ **-** A streamlined chain or L2 could reduce transaction costs and congestion. **b) Flexibility** \ **-** Cross-chain bridges provide users with greater liquidity options. **c) Sustainability** \ \- A well-designed token model ensures long-term viability for data contributors and ecosystem partners. ## 6. Flywheel Effect and Ecosystem Growth ### The Flywheel Dynamics **a) Incentivizing Data Submission** \ \- Contributors are rewarded (via LIV points) for submitting health data. \ \- This incentivizes individuals to upload data more frequently, improving the quantity and quality of the dataset. **b) Enhanced Data Value** \ \- As data volume and quality increase, the health dataset becomes **more valuable.** \ \- A larger and richer dataset attracts more medical institutions and researchers, who purchase access to the data and AI models. **c) Platform Revenue Growth** \ \- With more data and growing demand, BitDoctor’s revenue from data sales and AI model subscriptions increases. \ \- Part of these revenues is **channeled back** into the reward pool. **d) Increased Incentives for Members** \ \- As revenues grow, the system can offer **higher rewards** (via more LIV points which gives weightage for future token airdrops) to new and existing contributors.\ \- This further **encourages** more data submissions and participant growth. **e) Reinforcing the Cycle** \ The cycle repeats, creating a **positive feedback loop**: More data leads to more value, which leads to more revenue, which leads to more rewards, and thus encourages even more data contributions. ## 7. Data Protocol Vision and Developer Integration ### Becoming a Data Protocol **a) Protocol Approach** \ \- Over time, BitDoctor aims to evolve into a **comprehensive data protocol**, aggregating vast amounts of anonymized health data. \ \- This protocol will serve as a **foundation laye**r upon which developers, researchers, and AI model creators can build. **b) Developer Ecosystem** \ \- By exposing APIs and smart contract interfaces, developers can create applications or tools that **leverage anonymized health data**. \ \- Examples include: \ i) Advanced AI-driven diagnostics tools. \ ii) Research platforms for epidemiological studies. \ iii) Customized health and wellness apps offering personalized recommendations. **c) Open Collaboration** \ \- **Researchers and AI model developers** are invited to build on top of the protocol. \ \- **DeSCI** principles ensure that data remains **open, anonymized,** and **securely permissioned,** fostering a global community of innovators in healthcare. ### Anonymized Data for Developers **a) Privacy by Design** \ All data made available to third-party developers will be anonymized and stripped of personally identifiable information (PII). **b) Enhanced Research Outcomes** \ The **richness** of the dataset, combined with its **anonymized** nature, fosters cutting-edge research and AI model development without compromising individual privacy. ## 8. Conclusion BitDoctor.AI aims to revolutionize healthcare data management by combining **decentralized technology, robust incentive mechanisms,** and **privacy-focused data sharing**. Through its **Flywheel Effect**, the platform drives continuous growth and increased value for all participants. By evolving into a **data protocol**, BitDoctor invites developers, researchers, and AI innovators to build transformative healthcare solutions on top of a vast pool of **anonymized health data**—ultimately improving global health outcomes while ensuring contributors are **fairly rewarded** via **LIV points** (and, in the future, a fully realized token).