This is a call to action. We are looking for people who would want to openly fix the Health Insurance system in the world. The current Private/For-Profit Health Insurance solutions have "players" incentives completely unaligned: A Health Insurer wants to increase profit and to do so increasingly push to deny as many claims as they can.
The idea of this project is to build a Non-profit org/foundation that leverages the decentralized and automated nature of public blockchain technologies to create a self-governed Health Insurance network. There is still a lot of things to questions to answer and things to solve. But we are looking for people interested in helping define, build and deploy this in the open.
We are looking for "CAN DO-ers", people who want to help solve the problems as they arise. We understand that it is a daunting task full of legal, technical and operational landmines. But we believe society has all the capabilities to make this a reality.
Right now we are defining the mechanics/policies of the process. What you see in this document is the initial proposal. So immediate next steps would be:
The rest of this document was generated with the help of AI, after a long session of brainstorming to define an initial framework of how the Open Health Insurance system could work. This should serve as an idea of where we want to go, but should be taken as what it is, a very initial draft of the mechanisms and ideas we want to use to solve the Health Insurance problem.
We are aiming to disrupt the health insurance space by building a global, non-profit mutual insurance fund that is owned and governed by the very people it covers. Traditional insurers profit by collecting premiums, rejecting risky applicants, and denying claims. We remove that conflict of interest entirely: there are no shareholders to pay, nobody is turned away, and every dollar of premiums stays in the pool to serve members.
The mechanics are simple. Members pay a monthly premium in digital dollars into a shared fund. Idle capital in the fund is put to work earning interest, which covers the cost of running the system rather than being extracted as profit. When a member gets sick, their claim is reviewed by a randomly selected panel of independent, vetted medical professionals who are financially rewarded for honest judgments and penalized for dishonest ones. Approved claims are paid out directly and automatically. Members who stay healthy and loyal are not left empty-handed either: the longer they participate, the larger the coverage they unlock and the greater the share of their contributions they can withdraw upon retirement.
Why this is a good idea: health insurance is a multi-trillion-dollar industry whose core product, pooling risk, is fundamentally a trust and accounting problem. Today that trust is rented from expensive intermediaries. By making the fund's balance sheet fully transparent and its rules enforced automatically, we can offer coverage at a fraction of the overhead, reach the billions of people that incumbents ignore, and align every participant, from members to medical reviewers, around the same goal: a solvent, fair, and lasting safety net.
All user premiums are collected in USDC and deposited into a single, global General Pool. To ensure capital efficiency and long-term solvency, idle capital in the General Pool is dynamically deployed to blue-chip DeFi lending markets (e.g., Aave, Compound) to generate interest. The protocol exclusively utilizes USDC for daily operations to shield users from cryptocurrency volatility.
While funds are pooled globally, the protocol maintains strict on-chain accounting of each user's contributions. A user's maximum claim allowance is dynamically calculated as a multiple (e.g., 10x to 50x) of their accumulated account balance. This multiple scales positively with the user's tenure in the protocol, heavily incentivizing long-term participation.
In the event of a DeFi protocol exploit resulting in a loss of yield-bearing assets, the losses are socialized across the protocol, proportionally reducing user accounting balances. If approved claims exceed the available liquid USDC, payouts enter a strict First-In-First-Out (FIFO) queue, ensuring systemic stability without defaulting on coverage.
The protocol guarantees inclusivity; no user is rejected. During onboarding, users complete a zkKYC process (e.g., zkME) for Sybil resistance and submit initial medical documentation. Evaluators review these documents strictly to determine the user's initial risk profile, which the smart contract maps to a specific monthly premium tier. Premium tiers are further adjusted by a DAO-governed regional multiplier to account for geographic disparities in healthcare costs.
If a user misses a monthly contribution, the protocol deducts the equivalent amount from their accumulated accounting balance. This inherently reduces their available claim multiple. If the accounting balance is completely depleted by missed payments, the account is automatically invalidated.
To incentivize health and long-term commitment, users who rarely claim can execute a one-time withdrawal upon retirement or account closure. The permissible withdrawal percentage scales with the age of the account (capped at a maximum, e.g., 80%). Exercising this option permanently closes the account and invalidates the insurance coverage.
To prevent claim spam, a non-refundable submission fee is deducted directly from the user's accumulated balance when a claim is filed. Medical data is never stored publicly on-chain. The claimer retains full ownership of their medical records, which are stored encrypted off-chain. The system generates encrypted data packages utilizing the specific public keys of the randomly assigned medical evaluators, ensuring strict end-to-end privacy.
Claims are judged by a randomly selected panel of evaluators. Evaluators are vetted medical professionals (approved by the DAO) who have passed zkKYC and staked a financial bond. The protocol utilizes a Schelling-point consensus mechanism:
Upon a successful majority vote, the smart contract automatically releases the approved USDC funds directly to the claimer as a refund, simplifying the integration without requiring global medical providers to adopt web3 infrastructure.
The protocol is governed by a DAO composed of protocol participants. To prevent monopolization by wealthy actors ("whales"), governance voting power is calculated using Quadratic Voting. This ensures that users with skin in the game have a voice, but prevents capital dominance.
Passed DAO proposals automatically trigger immutable smart contract upgrades. However, recognizing the inherent risks of smart contracts, the protocol employs a Multi-Sig Guardian Wallet controlled by trusted ecosystem actors. This wallet holds the strict, limited capability to trigger an emergency "pause" on the protocol to secure funds during a zero-day exploit.
To protect the nascent protocol from being drained by early claims, the maximum allowable claim is hard-capped at a dynamically phased percentage of the Total Value Locked (TVL). For example, a single claim cannot exceed 1% of the General Pool's liquidity during the protocol's bootstrapping phase.
This section records, in one place, every design decision reached during the initial design discussions. It is intentionally more detailed than the previous sections and is aimed at engineers, auditors, and reviewers who want to understand exactly how the protocol behaves. Where a concrete number is given (e.g., "80%", "1% of TVL"), it should be read as the initial proposed value: all such parameters are protocol constants that the DAO can adjust.
The core logic will be implemented as a suite of EVM-compatible smart contracts. Responsibilities are split as follows:
The protocol operates exclusively in USDC for deposits, accounting, evaluator rewards and payouts, so that premiums and payouts are always expressed in a stable, fiat-equivalent unit. The DAO may later authorise the treasury to hold other crypto-assets as part of a diversified investment strategy, but that is explicitly out of scope for day-to-day operations and for this RFC.
Figure 1 — Flow of funds. Every premium goes into a single General Pool; the "individual pool" is purely an accounting record.
An early design question was whether each member holds a personal pool of funds. The answer is no. All USDC contributed by members is deposited into the single General Pool. Each member's "individual pool" is an on-chain accounting record (balance) that tracks how much they have contributed and not yet consumed. Pooling all liquidity maximises the capital deployed to yield markets and makes the protocol's solvency a single, transparent number. The ledger is still essential: it is the basis for the member's claim ceiling, their loyalty withdrawal, their missed-payment buffer, and their governance weight.
Contributions accrue monthly. Members may optionally make additional voluntary contributions at any time; these are credited to their balance in the same way and increase their claim ceiling. The monthly premium for a member is computed on-chain as:
premium = baseRate(tier) × regionalMultiplier(region)
The protocol never rejects an applicant on medical grounds; the medical assessment affects only the price, never eligibility. The onboarding flow is:
A member's maximum claimable amount is bounded by two independent limits; the lower of the two applies:
maxClaim = min( balance × multiple(tenure), TVL × capPct(phase) )
multiple(tenure) starts low (e.g., 10×) for new accounts and rises with the number of monthly contributions made, up to a ceiling (e.g., 50×). This blocks "hit-and-run" attacks in which someone pays one premium and files a large claim, and rewards long-term participation. Any reduction of balance (missed payments, submission fees, loyalty withdrawal) reduces the ceiling proportionally.Figure 2 — Illustrative shape of multiple(tenure). Exact curve and bounds are DAO parameters.
When a monthly contribution is not paid, the protocol does not suspend coverage immediately. Instead it self-funds the premium from the member's own balance: the missed amount is deducted from balance, which in turn lowers the claim ceiling. This behaves as an automatic, mathematically defined grace period whose length is proportional to what the member has already put in. When a contribution can no longer be covered because the balance is exhausted, the account is cancelled and invalidated.
EVM contracts cannot wake themselves on a schedule. Rather than relying on an external automation network (e.g., Chainlink Automation, Gelato) to touch every account monthly, missed-payment deductions are computed lazily: on the member's next interaction (deposit, claim, vote, withdrawal), the contract computes how many billing periods have elapsed since the last settlement, applies the corresponding deductions, and updates tenure and status. Because the rule is deterministic, the "true" state of any account can be read at any time by simulating the settlement without a transaction.
Figure 3 — Missed contributions consume the member's own balance until it reaches zero.
Member contributions generally remain in the pool permanently; this is insurance, not a savings account. The one exception is a single, account-closing withdrawal available to members who have rarely or never claimed. Two rules govern it:
balance increases with the age of the account, measured specifically as the number of monthly contributions made (not calendar time).Worked example. A member joins at age 20 and contributes $100 every month. Over 60 years they make 720 contributions totalling $72,000 and never file a claim. At age 80 they may elect to withdraw up to 80% of their balance, i.e. $57,600, with the remaining 20% staying in the pool for the community. (This ignores any adjustments from socialized losses or fees.)
Properties of the withdrawal:
Figure 4 — Illustrative loyalty withdrawal curve. The rate of increase and the cap are DAO parameters.
.zip archives). See 5.10.maxClaim, 5.5) is released as a refund directly to the claimer's wallet. The payout is first drawn against the member's own ledger balance and any remainder against the shared pool. Paying the claimer rather than the provider means hospitals and clinics do not need to adopt web3 infrastructure for the protocol to function; direct-to-provider payment with a vetted provider whitelist is a possible later extension.Figure 5 — Claim lifecycle from submission to payout.
Both claimers and evaluators must complete full KYC. To avoid the protocol (or a legal entity behind it) custodying personally identifiable information, KYC is performed through a zero-knowledge KYC provider such as zkME or an equivalent. The provider verifies identity off-chain and issues a proof that the wallet belongs to a unique, verified human in a given jurisdiction; the contract checks the proof and gates protocol functions on it. This delivers:
The protocol handles three classes of sensitive off-chain data. None of them is ever written to the blockchain in plaintext, and none of them is held by the protocol, a foundation, or any central operator:
| Data class | Owner | Who may need to read it | When |
|---|---|---|---|
| Claimer KYC documents | Claimer | zkKYC provider only (produces an on-chain proof; documents are never shared with the protocol) | Onboarding |
| Claimer medical data (questionnaire, records, claim evidence, provider evidence) | Claimer | The randomly selected evaluator panel for that specific assessment or claim | Onboarding assessment; each claim; appeals |
| Evaluator credentials & KYC documents | Evaluator candidate | zkKYC provider; the DAO members (or DAO-elected vetting committee) reviewing the candidate's application | Evaluator vetting |
Where the data lives. All documents are stored in an external, distributed, content-addressed storage network such as IPFS (with Filecoin/Arweave-style persistence, or pinning services chosen by the owner). Files are encrypted before they leave the owner's device, so the storage layer only ever holds ciphertext. The blockchain stores only the content identifiers (CIDs/hashes) needed to prove integrity and to link a file to a case, an application, or an account. This gives three properties at once: no central honeypot of health or identity data, tamper-evidence (a CID changes if a single byte changes), and censorship resistance (any node can serve the ciphertext, none can read it).
Data sovereignty: the owner is the only key holder. The guiding principle is that the person the data is about is the sole party able to grant read access, and the protocol never possesses a decryption key. The exact mechanism is still to be defined; the initial proposal is a public-key-cryptography scheme that leverages the key pairs participants already hold in their blockchain wallets, so that no additional identity or key infrastructure needs to be introduced:
eth_getEncryptionPublicKey-style APIs)..zip per recipient) encrypted such that only that recipient's wallet private key can open it.Figure 6 — Data sovereignty model: encrypted at the edge, stored on a distributed network, unlocked only by chosen recipients' wallet keys.
Special case: KYC. Identity documents follow an even stricter path. They are shown only to the zkKYC provider, which returns a zero-knowledge proof; neither the protocol nor the DAO ever sees passports or IDs. For evaluator vetting, the DAO reviews professional credentials (licences, certifications) via the envelope mechanism above, while identity itself is established by the zkKYC proof.
Open questions (TBD). Which encryption-key derivation to standardise on across wallets; whether to use a threshold/proxy re-encryption scheme (e.g., Lit Protocol-style access control) instead of per-recipient envelopes to reduce client-side work; retention and deletion policy for ciphertext after a case closes; and how a member recovers access to their own data if they lose their wallet key. These will be addressed in a follow-up RFC.
Vetting. Becoming an evaluator is permissioned. A candidate submits professional credentials through a secure channel, completes zkKYC, and the DAO votes to approve them. Only approved evaluators may stake and receive assignments.
Bond. Every active evaluator stakes a USDC bond. The bond is the collateral behind honest behaviour and can be partially or fully slashed. Slashed funds are not burned; they flow into the General Pool.
Schelling-point consensus. Because the "correct" answer is the medically justified one under the adopted ICD-10 ruleset, honest evaluators are expected to converge. An evaluator is paid when their vote matches the final majority and penalised when it does not.
Reputation & assignment weighting. Each evaluator carries a score that rises with correct evaluations and falls with incorrect ones. Random selection is weighted by score, so evaluators with a poor record receive fewer cases and therefore less income; a score below a DAO-set threshold suspends the evaluator.
Lazy-voting defence. Majority-matching alone can be gamed by always voting the same way. Three mechanisms counter this: (1) commit-reveal voting hides other votes until the window closes; (2) an appeal process lets the claimer (or any member posting a bond) escalate a decision to a larger, freshly drawn panel; if the appeal overturns the original outcome, the original majority is treated as incorrect and slashed; (3) statistical audits over an evaluator's voting history (e.g., anomalous unanimity or near-zero review time) can trigger slashing via DAO proposal.
Compensation. Evaluator rewards are paid out of the General Pool, which is funded by member premiums and yield. Onboarding assessments (5.4) are compensated the same way as claim evaluations.
To remove ambiguity about what is "covered", the protocol adopts the ICD-10 classification as its reference standard. The DAO vets and formally approves the version of the catalogue (and any exclusions or additions) that is in force; once adopted, evaluators must reference the relevant codes in their assessment and are bound by it. Changes to the catalogue follow the normal governance process.
Every KYC-verified member with a positive ledger balance may vote. To prevent a wealthy actor from buying control, voting power is quadratic: the cost of casting v votes on a proposal grows as v2 (equivalently, influence scales with the square root of stake). Combined with zkKYC-enforced uniqueness, this makes vote-splitting across wallets ineffective.
The DAO governs, among other things: premium base rates and tiers, regional multipliers, the tenure-multiple curve, the TVL claim cap and its phasing, the loyalty withdrawal curve and cap, the submission fee, evaluator bond size and slashing parameters, panel size N, the ICD-10 catalogue, evaluator approvals, yield venues, and any future reserve or asset-diversification policy.
Execution. A passed proposal is executed automatically on-chain (parameter update or contract upgrade through the governance contract), with no human committee required to carry out the DAO's will. A timelock between passing and execution is recommended so members can react to malicious proposals.
The protocol will hold significant USDC and must use leading-edge security practice: independent audits before launch and before every upgrade, formal verification of the accounting invariants (e.g., sum of ledger balances never exceeds pool assets plus queued liabilities), a public bug bounty, and minimal external dependencies.
Independently of the DAO, a Guardian Multi-Sig held by trusted ecosystem actors has exactly one power: to pause the protocol (halting deposits, payouts and treasury movements) if a vulnerability or exploit is detected. The multi-sig cannot move funds, change parameters or upgrade contracts; resuming operation, and any remediation, requires a DAO vote. This combines trustless automated governance with the ability to react to a zero-day faster than a voting period allows.
| Parameter | Initial proposal | Set by |
|---|---|---|
| Unit of account | USDC only | Protocol |
| Contribution cadence | Monthly, plus optional extra contributions | Protocol |
| Claim multiple range | 10× (new) → 50× (long tenure) | DAO |
| Single-claim TVL cap | 1% of TVL during bootstrap (e.g., $600 on $60k) | DAO, phased |
| Loyalty withdrawal cap | 80% of balance; one-time; closes account | DAO |
| Missed payment | Deducted from balance; cancel at zero; lazy settlement | Protocol |
| Submission fee | Non-refundable, deducted from ledger balance | DAO |
| Evaluator panel size | N = 3 (larger on appeal) | DAO |
| Evaluator entry | Credentials + zkKYC + DAO approval + bond | DAO |
| Slashed funds | Returned to General Pool | Protocol |
| Medical standard | ICD-10, DAO-vetted version | DAO |
| Identity | zkKYC (e.g., zkME) for claimers and evaluators | Protocol |
| Data storage | Encrypted client-side, stored on IPFS-style distributed network; chain holds CIDs only | Protocol |
| Access control | Per-recipient envelopes encrypted to wallet public keys (mechanism TBD) | Protocol |
| Payout routing | Refund to claimer; FIFO queue when illiquid | Protocol |
| External losses | Socialized pro rata across ledger balances | Protocol |
| Voting | Quadratic; auto-executed proposals | Protocol |
| Emergency control | Guardian multi-sig, pause only | Protocol |