Proposal: Sunset the dHealth Cosmos App Chain & Migrate to Solana

Token-Holder Voting Period: 5 Jan - 6 Jan 2026

Proposal: Sunset the dHealth Cosmos App Chain and migrate the dHealth protocol and DHP to Solana.

Why this vote matters: Healthcare delivery and blockchain infrastructure have evolved. Continuous care, AI, and care robots require high-frequency, low-latency, and reliable attestations that a standalone app chain cannot efficiently support. Maintaining the Cosmos chain introduces growing operational risk and diverts resources away from healthcare adoption. Migrating to Solana aligns dHealth with a production-grade execution layer, enabling the protocol to focus on real-world healthcare use cases.

What will change:

• The dHealth Cosmos App Chain will be sunset after a transition period of 3 months

• A new Solana-native DHP will be issued with a fixed 2% annual supply inflation and no hard cap.

• Existing Cosmos-based DHP will be migrated 1:1 via an audited, transparent process with a generous grace period. Existing wrapped DHP on Solana will be exchanged 1:1

• All attestations, mandates, and protocol activity will move to Solana.

• No holder value is lost.

Role of DHP after migration: DHP becomes a protocol-layer asset rather than a payment token. It anchors identity, mandates, and attestations—defining who acted, under what authority, and what happened in healthcare. Payments and incentives are handled using stablecoins.

Token supply and inflation:

• The new DHP will have no fixed supply cap.

• A controlled 2% annual inflation will be introduced.

• Inflation is allocated to active contributors (e.g., attestation issuers, onboarding entities, verifiers), not to passive holders, to fund protocol operations and growth.

Impact on DHP value: Participation in the protocol requires acquiring and locking DHP, not spending it. As healthcare providers, insurers, research organisations, and care networks adopt the protocol, more DHP is committed for operational use, reducing circulating supply. This ties DHP’s long-term value to real-world healthcare adoption rather than speculative activity.

What token holders are voting on:

• Approving the sunset of the Cosmos app chain

• Approving the migration of DHP and protocol services to Solana

• Approving the updated role and tokenomics of DHP, including controlled inflation

Outcome of a “Yes” vote: dHealth transitions to Solana, reducing operational risk, improving scalability, and strengthening DHP as a trust and accountability asset for human-centric, AI-supported healthcare.

Outcome of a “No” vote: dHealth continues operating the Cosmos app chain, with higher long-term operational complexity and constrained scalability.

---

1. Background and Rationale

When the dHealth Cosmos App Chain was launched less than two years ago, the decision to operate a sovereign Layer-1 was well-reasoned and aligned with the ecosystem's state at the time. App chains promised sovereignty and specialisation, interchain security was still emerging, and high-throughput, general-purpose blockchains had not yet demonstrated sustained production-readiness. For a sensitive domain such as healthcare, operating an independent chain was the most responsible way to ensure control, security, and long-term optionality.

Since then, both blockchain infrastructure and healthcare delivery have evolved rapidly and irreversibly.

In the blockchain ecosystem, the industry has shifted from chain proliferation toward consolidation around a small number of execution layers that operate reliably at a global scale. Attention has moved away from speculative metrics toward real-world metrics such as throughput, availability, and capital efficiency. In this environment, Solana has emerged as the dominant execution layer for high-frequency applications, ranking #1 globally by transaction volume and #2 by Total Value Locked (TVL) according to independent analytics platforms (see Figures 1 & 2). This reflects sustained production use. For healthcare systems that depend on continuous interactions, auditability, and machine-generated events, aligning with a production-grade execution layer is an operational necessity.

Figure 1. Traffic Market Share 2025

Figure 2. TVL 2025

At the same time, the Cosmos ecosystem itself has experienced a gradual deterioration in cohesion and economic gravity. The proliferation of application-specific chains has resulted in fragmented security models, dispersed liquidity, slow coordination, and increasing governance complexity. Interchain security has added dependency rather than reducing operational burden. Recent leadership changes and shifting strategic priorities at the Cosmos Hub level have further increased uncertainty for app chains. For a healthcare protocol that must plan on decade-long horizons and support safety-critical systems, this level of ecosystem fragility is unacceptable.

More importantly, healthcare itself has changed! Healthcare is no longer defined solely by episodic clinical encounters and static records. It is increasingly characterised by continuous care, longitudinal monitoring, and coordination between patients, healthcare professionals, AI systems, and, to some extent, care robots. This evolution does not reduce the role of humans. On the contrary, it increases the need for systems that support human decision-making, reduce administrative burden, and ensure that technology remains accountable to human values and outcomes.

Continuing to operate the dHealth Cosmos App Chain would divert scarce resources from building practical, real-world applications involving patients, clinicians, and machines to maintain consensus infrastructure. Sunsetting the Cosmos app chain is therefore not a retreat, but a necessary adaptation to ensure that infrastructure serves healthcare - rather than the other way around.

2. Human-Centric Healthcare as the Core Principle

The purpose of healthcare infrastructure is not technological innovation for its own sake. Its sole purpose is to improve human health and well-being. Patients remain at the center of the system as owners of their health data, beneficiaries of care, and participants in long-term health outcomes. Healthcare professionals remain essential as caregivers, decision-makers, and accountable authorities responsible for clinical judgment.

AI systems and care robots are not replacements for human care. They are supportive tools designed to extend human capacity, reduce repetitive workload, and enable continuity of care in environments where human presence alone is insufficient. Any infrastructure that supports AI and robotics in healthcare must therefore be human-first by design.

3. Essential Concepts

   1. Identity and Accountability Across Humans and Machines

In the Solana-based architecture, i.e. using the Solana Attestation Service (SAS) Framework (https://attest.solana.com/), identity becomes a shared primitive across patients, healthcare professionals, AI agents, and care robots. Human identities represent patients, clinicians, caregivers, and researchers, etc. AI agent identities represent software systems acting under defined permissions. Care robot identities represent physical devices operating in real-world environments.

Each identity is cryptographically verifiable and bound to explicit mandates that define what actions are permitted. This shared identity framework ensures that machines act only under human-defined authority, responsibility is always attributable, and trust is preserved across complex care workflows.

While identities and actions are verifiable on-chain, user privacy is preserved by design. The SAS records only cryptographic proofs and references, never raw health data or personal information, and can leverage zero-knowledge proofs to attest that authorised actions or conditions were met without revealing underlying medical details. Sensitive data remains off-chain under user control, ensuring accountability, auditability, and regulatory compliance without exposing private health information.

2. Attestations as Proof of Action

At the core of this proposal is a shift from document-centric records toward attestations of care-relevant actions. Attestations do not replace clinical judgment and data. Instead, they provide verifiable evidence that supporting actions occurred as intended. A patient adhered to a therapy plan, a clinician gave a vaccine shot to a patient or approved an AI-generated summary, a care robot delivered assistance as prescribed, or an AI system flagged a risk and escalated it to a human professional.

Attestations exist to reduce administrative burden, enable auditability, support outcome-based models, and protect both patients and healthcare professionals. SAS allows these attestations to occur at high frequency, low cost, and with near-instant finality, without exposing sensitive health data.

3. Separation of Meaning and Money

A core design principle of the dHealth ecosystem will be the clear separation between meaning and money. Identity and attestations define who acted and what happened in healthcare, while payments and incentives are predominantly settled in stablecoins rather than DHP. Stablecoins provide price stability, regulatory familiarity, and operational simplicity for patients, healthcare providers, insurers, and research institutions. This allows incentives, reimbursements, and service payments to function predictably in real-world healthcare contexts. DHP does not replace money; instead, it complements stablecoin-based payments by anchoring identity, mandates, and attestations, ensuring that financial flows are always tied to verifiable human- and machine-mediated healthcare actions.

4. Selected Use Cases: Care Delivery, Research & Outcomes

   1. In homecare settings, patients increasingly rely on a combination of visiting nurses, remote clinicians, AI-driven monitoring, and assistive robots. In this context, clinicians remain responsible for care plans, while AI systems and robots support execution and monitoring. Attestations provide a transparent, verifiable record of supportive actions, improving patient safety, continuity of care, and trust among families, providers, and insurers. It will also serve as the basis for the actors' reimbursement by the payers.
      

   2. Research similarly benefits from this model. Patients consent to participation, clinicians define study protocols, and study nurses, AI systems, and robots assist with data collection and adherence. Attestations replace manual, error-prone reporting with verifiable evidence, reducing burden on participants while increasing data integrity. Humans remain the subjects and beneficiaries of research; technology simply ensures fidelity and transparency.
      

   3. Outcome-based reimbursement further illustrates the value of attestation-driven healthcare. In therapies such as weight-loss treatments with Wegovy or Ozempic, patients voluntarily enrol in outcome-based programs, clinicians define therapeutic goals, and AI tools and care devices support adherence and monitoring. Reimbursement is triggered by verified health improvement rather than service volume, aligning incentives around real patient outcomes.

5. Role of DHP After Migration

After migration, SOL provides economic settlement, and stablecoins enable payments, while DHP anchors meaning and accountability. DHP is used to secure attestations, back mandates and permissions, facilitate dispute resolution, and preserve the long-term integrity of healthcare actions. It does not replace money; it defines what it means for care to have happened.

1. DHP Token Evolution and Controlled Inflation

As part of the migration to Solana, DHP must evolve to reflect its role as a long-lived protocol token rather than a scarce or speculative asset. In this architecture, a new Solana-native DHP is minted with no fixed hard cap and with a controlled annual inflation rate, designed to support long-term sustainability and network participation. Inflation is not introduced as a value-extraction mechanism, but rather as a reflection of real system usage and ecosystem growth. As healthcare actions, attestations, and mandates increase over time, the token supply expands proportionally to maintain incentives for validators, agents, and other participants who secure and operate the protocol. This design acknowledges that healthcare infrastructure must operate on multi-decade horizons and that a rigid, capped supply would ultimately undermine resilience, adaptability, and long-term security.

2. DHP Demand, Participation, and Price Formation

DHP is designed as a required participation asset in the dHealth protocol, not as a payment token. It is used to establish identity, issue and receive attestations, define mandates, and participate in dispute resolution. Verifiable healthcare actions, performed by patients, healthcare professionals, institutions, AI agents, or care robots, cannot occur unless the involved parties hold DHP.

Every participating entity must maintain a minimum DHP balance to be subject to attestations. This balance is not spent but locked or referenced as part of the entity’s protocol identity, ensuring accountability and preventing unbacked participation. To avoid friction for individuals, the obligation to acquire DHP is shifted upstream. When new participants are onboarded, the attestation issuer—such as a hospital, insurer, research organisation, or care provider—provides the required DHP on their behalf. This allows patients to participate without purchasing tokens while creating direct demand among organisations.

Issuing attestations requires DHP commitments on both sides. Issuers lock DHP to signal credibility and accept liability, while subjects’ DHP anchors accountable participation. In cases of proven misconduct or unresolved disputes, committed DHP may be partially slashed in accordance with predefined rules. Protocol inflation is allocated productively to entities that issue high-quality attestations, onboard participants, and maintain dispute-free mandates, rewarding real protocol work rather than passive holding.

This structure drives DHP's price by creating persistent, non-speculative demand while reducing circulating supply. Participation requires ownership and long-term locking rather than spending, thereby lowering token velocity and accumulating locked balances over time. As healthcare activity grows, institutions must acquire and commit increasing amounts of DHP to support identities, attestations, and mandates. With demand tied to real-world usage and supply constrained by locking, DHP’s price is driven by protocol adoption and long-term reliance, not short-term trading dynamics.

3. Migration Strategy and Post-Migration Focus

   1. A new Solana-native DHP will be mintedA new Solana-native DHP token will be minted under the updated tokenomics. The official mint address, metadata, and verification details will be published to clearly identify the canonical DHP and prevent confusion with unofficial or copycat tokens.

   2. Migration channels and supply-locking will be deployed.Migration channels will be deployed to lock or permanently burn the existing Cosmos-based DHP supply. The locked or burned supply will be publicly verifiable on-chain to ensure transparency and trust throughout the transition.

   3. A 1:1 migration interface will be launchedA user-friendly migration interface will be made available, allowing all DHP holders (Cosmos and Solana) to migrate their tokens to the new Solana-based DHP at a one-to-one ratio. Eligibility criteria and migration status will be visible through public dashboards and on-chain proofs.

   4. A migration grace period will be maintainedThe migration window will remain open for an extended period to ensure accessibility for non-technical users, institutional participants, and long-term holders. Regular communication will be provided through all official channels to guide participants through the process.

   5. Cosmos functionality will be progressively wound downDuring the migration period, non-essential modules on the dHealth Cosmos App Chain will be frozen, and operational complexity will be reduced in stages. Validator operators will be informed in advance and coordinated with to ensure a smooth wind-down.

   6. The dHealth Cosmos App Chain will be formally decommissionedAfter the migration grace period concludes, validator operations will be shut down, and the dHealth Cosmos App Chain will be formally decommissioned in a transparent and orderly manner.

   7. All protocol functions will transition entirely to SolanaFollowing the migration, attestations, mandates, and proof-of-action mechanisms will operate exclusively on Solana. No new protocol activity will be executed on the Cosmos chain.
      

4. Roles of DHP and AIDH in the dHealth Ecosystem

DHP and AIDH tokens serve clearly distinct but complementary roles within the dHealth ecosystem. DHP is the protocol-native token that anchors meaning, accountability, and trust at the infrastructure level: it secures attestations, mandates, and proof of action, and enables governance and dispute resolution for healthcare activities. DHP defines what it means for a healthcare action to have occurred. AIDH, by contrast, is an application-level access and incentive token used within dHealth Intelligence to unlock AI services, subscriptions, onboarding incentives, and participation in outcome markets. While AIDH drives user adoption and application usage, DHP operates at the protocol layer, ensuring the integrity and long-term reliability of human- and machine-mediated healthcare actions.

5. Optional Expansion to BASE for Adoption and Access

At a later stage, DHP may also be released on BASE to support broader adoption and easier access for users and organisations that already operate within the EVM ecosystem. Such a release would be designed purely as an access and distribution layer, improving availability through familiar tooling and liquidity, while protocol governance remains anchored on Solana. Any DHP circulating on BASE would be bridged and fully backed by Solana-native DHP, ensuring a single source of truth for supply, governance, and protocol integrity. This approach allows dHealth to expand reach and interoperability without fragmenting governance or weakening the protocol’s trust guarantees.

6. Conclusion

This proposal asks token holders to make a deliberate and consequential decision about the future of the dHealth protocol. The vote is not a technical formality, but a governance choice that determines whether dHealth continues to allocate scarce resources to maintaining independent consensus infrastructure, or instead concentrates entirely on delivering real-world healthcare applications that serve patients, clinicians, and accountable AI systems.

By approving the migration to Solana and the sunsetting of the Cosmos app chain, token holders endorse a shift toward an execution layer that is already proven at a global scale, while preserving DHP’s core role as the anchor of meaning, accountability, and trust in healthcare actions. The proposed architecture ensures that DHP evolves into a long-lived protocol token aligned with real usage, human oversight, and verifiable outcomes, rather than short-term speculation.

Voting in favour supports a path in which governance, attestations, and mandates remain robust while reducing operational complexity and ecosystem fragmentation. Voting against retains the status quo, including continued maintenance overhead and ecosystem uncertainty, with direct implications for the protocol’s ability to support AI agents, care robots, and outcome-based healthcare models over multi-decade horizons.

This vote, therefore, represents a collective choice about stewardship. Token holders are asked to evaluate not only the technical merits but also the long-term responsibility. Hence, ensuring that dHealth infrastructure remains sustainable, human-centric, and capable of supporting accountable healthcare at scale. Participation in this vote is an essential expression of governance, signalling the community's intent to align technology with real human health outcomes.