HDMEX — White Paper (V4.4, EN)

Human Decentralized Message Exchange — anonymous courier network, sovereign chain, programmable capsule tokens, post-quantum confidentiality. This document supersedes WP.1.2 FR.pdf (v1.2). Linked sources of truth: tokenomics, bridge/contract, PoP consensus, Chroma Guard, course value transfer.

Contents

Part I — Manifesto: 1. Abstract · 2. The Why · 3. Our Mission · 4. HDMEX's DNA.

Part II — The system: 5. The network & the course cycle · 6. Offline resilience · 7. Chroma Guard (confidentiality) · 8. Post-quantum anti-harvesting · 9. HDS-01 (token standard) · 10. Proof-of-Participation consensus · 11. The Vax · 12. Tokenomics · 13. Bridge & wHDMEX · 14. Governance · 15. Progressive decentralization.

Part III — Uses & ecosystem: 16. Detailed use cases · 17. Competitive comparison · 18. WebApp & experience · 19. Business model & fees.

Part IV — Security, future & reference: 20. Security & threat model · 21. Future developments · 22. Roadmap · 23. FAQ · 24. Conclusion · Appendix A (glossary) · Appendix B (parameters) · Appendix C (technical architecture).

PART I — MANIFESTO

1. Abstract

Security on the Internet, in its current form, is an illusion. The centralized infrastructures that dominate the digital world are vulnerable to outages, censorship and surveillance: a single actor can cut off the service, read the data, or be compelled to do so. HDMEX offers a fundamentally different alternative — decentralized, anonymous, and offline-resilient — for exchanging value and sensitive files, powered by a human network of couriers.

Three pillars:

1. An anonymous courier network between a creator (Cx), a courier (Vx) and a recipient (Dx), where value and encrypted files flow even without a connection.
2. A sovereign chain based on Proof-of-Participation (PoP): those who do the work — the Vax, graduated couriers — secure and govern the chain, from their phone. Power follows real participation, not capital alone.
3. End-to-end confidentiality (Chroma Guard) designed against the HNDL threat ("harvest now, decrypt later"): encryption is client-side and post-quantum.

The HDMEX token is unique: it pays for the course, programs and opens capsules, rewards the Vax (a courier who also validates blocks), and trades on Uniswap via a 1:1 bridge. It is a service token — its value comes from usage, not speculation.

This document presents the vision (Part I), the complete technical architecture (Part II), the uses and the ecosystem (Part III), then security, future developments and reference material (Part IV).

2. The Why

2.1 The illusion of security

We have been told over and over that the cloud is safe, that encryption protects us, that our data is in good hands. This is rented trust: it rests entirely on the good faith — and the survival — of an operator we do not control. The day that operator falls, is hacked, is acquired, is requisitioned, or simply decides to change its terms, the security evaporates. A system that a third party can shut down, read or betray was never secure; it was only not yet compromised. Real security cannot be delegated: it must be distributed.

2.2 Centralization is a fragility

Every centralized service is a single point of failure. One outage, and millions of people are cut off. One breach, and years of data leak at once. One injunction, and the service becomes a tool of surveillance or censorship. The convenience of centralization is paid for in dependence: we traded control for ease, without measuring the price. The larger a platform grows, the more it becomes a target — and the more its fall hurts. Recent history is a long list of massive leaks, outages and unilateral reversals; every time, the user had no recourse, because they had no control.

2.3 The surveillance economy

In the dominant model, we are the product. Personal data is extracted, profiled, resold; privacy is eroded by default, not by accident. Protecting oneself demands constant effort against a system designed to collect. HDMEX reverses the burden: confidentiality is the default state, exposure the chosen exception. One should not have to fight to avoid being surveilled — protection should be structural, not optional.

2.4 The world is not always connected

A vast part of human activity takes place in intermittent connectivity — rural areas, travel, saturated networks, outages, disasters. Systems that assume always-on exclude these uses and these people. And some things must still move physically: sensitive documents, keys, media we do not want to entrust to the cloud. HDMEX embraces this reality: local validation, mailboxes, hand-to-hand transfer by courier. The network rejoins the physical world instead of pretending it does not exist.

2.5 The quantum clock (HNDL)

A silent threat is advancing: "Harvest Now, Decrypt Later". An adversary does not need to break the encryption today — it is enough to copy the encrypted data and store it. The day sufficiently powerful quantum computers exist, everything that was harvested becomes readable retroactively. Most systems ignore this deadline. For a network where a courier carries encrypted files — and therefore where an interceptor can copy an envelope and keep it — ignoring it would be a failure. HDMEX designs its confidentiality for tomorrow, not for yesterday.

2.6 Value captured from those who create it

Modern platforms extract the value produced by those who do the work — couriers, drivers, contributors — without ever giving them ownership of the network they keep alive. The worker bears the risk and the effort; the platform pockets the rent and sets the rules, often without transparency or recourse. HDMEX rejects this bargain: here, power and value follow real participation. Whoever does the course becomes a co-owner of it, not a mere service provider.

2.7 What a patch cannot fix

These problems are not bugs; they are consequences of the architecture. You do not make a centralized system sovereign with an update, nor a surveilling system respectful with a promise, nor a speculative token useful with a slogan. It takes a different foundation. That is HDMEX's reason for being: rebuilding from the ground up what the current model structurally cannot offer.

3. Our Mission

To make the exchange of value and sensitive files sovereign, anonymous and resilient — accessible to everyone, everywhere, even offline — and to make the network belong to those who keep it alive.

Concretely:

• Give control back to people. Data is encrypted client-side; keys stay with the user; nothing exploitable transits or rests on a server.
• Work everywhere. The connection is a comfort, not a condition. The network also serves the areas and moments where the Internet is missing.
• Protect over time. Confidentiality that survives the quantum era, because what we protect today must stay protected in ten years.
• Make the network unstoppable. No actor — company, state, attacker — should be able to cut it off, censor it or capture it.
• Give ownership to the workers. Those who carry out the courses secure and govern the chain, and reap its value.

For whom. Any person or organization for whom confidentiality, sovereignty and resilience matter: journalists and their sources, the legal and medical professions, companies handling sensitive data, NGOs and humanitarians in crisis zones, and the billions of people with imperfect connectivity.

The horizon. To build a public infrastructure owned by its users, not a company that extracts a rent. A digital commons, pursued all the way, but without haste — because a network that holds value is not rushed.

4. HDMEX's DNA

Ten non-negotiable principles define the project. Every technical, economic and governance decision flows from them — and any feature that violates them is set aside, whatever its short-term advantages. They form the project's filter.

1. Anonymity by default. The nominal protocol is silent: opaque envelope, actors not exposed, no exploitable opening material travels with the parcel. We do not ask for more information than strictly necessary.
2. Data sovereignty. Client-side encryption; keys and data stay with the user; only public keys transit. The server never sees the plaintext.
3. Offline resilience. Local validation, mailboxes, physical handover — the connection never conditions usage. The network must work where the Internet is not.
4. Ownership through work. Power follows verifiable participation (counter-signed courses), not capital alone: voting_power = sqrt(stake) x sqrt(part_score).
5. Unstoppable. No central mint, keys on thousands of phones, an anonymous and rotating validation committee — no center to seize, no fixed list to raid.
6. Post-quantum. We encrypt for tomorrow: a hybrid ML-KEM seal and an incomplete AONT file against harvesting. Confidentiality must survive the coming technological leap.
7. Standard primitives, in-house orchestration. The alphabet (AES, ML-KEM, ML-DSA, SHA-3) is proven and audited; the novel (the assembly, Chroma Guard) is ours. Never a home-made cipher.
8. Service token, not speculation. No burn, value through usage, regulatory honesty — HDMEX is not a financial instrument in disguise.
9. Radical honesty. We never oversell decentralization before it is real; we state the current trust model, its limits and its path. Trust is earned through transparency.
10. Progressive but irreversible decentralization. Pursued all the way to permissionless mode, in stages triggered by need — never a rushed consensus that would hold value.

PART II — THE SYSTEM

5. The network: actors & course cycle

5.1 The actors

5.2 The nominal cycle (diagram)

   Cx ──crée──► Course ──RDV2 fixé──► Dx
    │                                  ▲
    │ RDV1 (GPS + hotspot Wi-Fi)       │ RDV2 (GPS + hotspot Wi-Fi)
    ▼                                  │
   Vx ──────────transport────────────►┘
                                       │
                          Dx confirme (double-coche verte)
                                       │
                    ┌──────────────────┴───────────────────┐
              Flux A : redistribution         Capsule ouvrable
              (Vx 82% / Dx 15% / ent. 3%)     par le holder autorisé

1. Creation. Cx (the creator who sends) creates the course, deposits the encrypted file (online or offline), sets the price and the RDV2 with Dx (the recipient who receives) — the Cx↔Dx tunnel can be set before the course is even taken.
2. Taking the course. An available Vx (the courier who carries) accepts; the RDV1 (Cx→Vx handover) is scheduled.
3. RDV1 — Cx→Vx handover. Verified geographic presence (GPS within the radius set by the product), transfer via local Wi-Fi hotspot. The Vx leaves with an opaque envelope — no exploitable opening material travels with the parcel.
4. Transport. The accompanying AI reminds of the meeting point, address, GPS, schedule (local time zone) and walks through the steps, online as well as offline.
5. RDV2 — Vx→Dx handover. Physical handover, verified presence, hotspot transfer.
6. Confirmation. Dx confirms (double green check) → the course is finalized: value is redistributed (Flux A, §12), the capsule becomes openable by the authorized holder according to the policy.

5.3 Course states

pending_rdv_dx → available_vx (RDV2 validated) → vx_locked (Vx assigned) → delivering (V1 validated) → delivered (double check, tokens released). Two exception states: dispute and expired_rdv (missed meeting), with traceable refund/reassignment procedures.

5.4 SECURITY_ROOT & +1 HDMEX

When the course activates secure rooms and hotspot data transfer, Cx (the creator who sends) adds exactly 1 HDMEX of securing, managed by SECURITY_ROOT outside escrow. This mechanism covers the opening of the encrypted rooms (Cx↔Vx dispatch, Vx↔Dx handover) and their closing upon delivery. This +1 HDMEX does not "burn" after the work: it is a service payment settled to the company for security — everything is redistributed, never destroyed (zero burn rule).

5.5 Graduation and accreditation

Vx (the courier who carries) can evolve (V2, super-validators, then Vax block validator) through the proof of real work (counter-signed courses) and, for sensitive roles, a training/accreditation. Graduation to Vax (a courier who also validates blocks) is detailed in §11.

6. Offline resilience

6.1 Local validation

A transaction can be signed and recorded locally on the device, then synchronized with the global network when a connection is available. Advantages: zero latency, low fees (no immediate broadcast to the whole network), operation in dead zones. Notifications warn the actors of deadlines even in intermittent use. Global consistency is guaranteed at synchronization (append-only traceability).

6.2 Mailboxes

Cx (the creator who sends) deposits an encrypted file in a mailbox; Dx (the recipient who receives) retrieves it when they can; the Vx (the courier who carries) synchronizes. - Total asynchrony: Cx and Dx never need to be online at the same time. - Use case: a company (C1) deposits daily reports that one or more recipients retrieve at their own pace; delivery in a rural area where the Vx passes through and synchronizes. - Two profiles: simple (one-off transfer, precise tracking) vs secure (multiple validations, tokens, double encryption) — depending on sensitivity. - Complementarity: the reinforced security of courses and the simplicity of offline exchanges via mailboxes offer a unique flexibility.

100% offline permanent mailboxes (deposit tied to GPS coordinates and time slots, WiFi Direct/Bluetooth/P2P transfer, GPS+time locking validated locally, key rotation) constitute a future development axis detailed in §21.

6.3 Physical transfers

At the meeting point, the Cx (the creator who sends)→Vx (the courier who carries) then Vx→Dx (the recipient who receives) transfer goes through a local Wi-Fi hotspot with geographic presence verification — 100% web, without any imposed native app, silent and anonymous. The envelope stays opaque from end to end.

7. Chroma Guard — confidentiality

Chroma Guard is the confidentiality layer, entirely client-side: encryption happens in the browser, and only public keys transit the network. The plaintext file never leaves the creator's device.

7.1 Encryption chain (diagram)

  File ──AES-256-GCM──► Ciphertext          (DEK generated locally)
    DEK ──sealed (Dx public key)──► KEM     (sent online/offline)
  Dx: private key ──► DEK ──► decrypts ──► File (locally)

1. File encryption: AES-256-GCM with a data key (DEK) generated locally.
2. Key encapsulation: the DEK is sealed for the authorized holder (Dx) — encrypted with their public key. Transmitted either online (in processPayment(reason)), or offline (attached to the file / QR). Only Dx's private key decrypts it.
3. Opening: Dx decrypts the DEK, then the file — locally, offline if needed.

Actual path of a file delivery. The content is sealed on the sender’s device, then run through an all-or-nothing transform: the transformed body travels with the courier, while the fragment it is missing travels on a separate channel, inside a hybrid post-quantum capsule addressed to the recipient alone — carried by an HDS-01 token that encapsulates the opening key and the fragment, entrusted either to another courier — never the one carrying the body — or to the chain. No carrier ever holds a complete object — without the fragment, the body it holds yields nothing, even whole, even copied (details in §8.2).

7.2 Vault hierarchy & rotation

Vault hierarchy. A local vault holds a seed and a colour. The seed never changes. From these two the period key is derived — the key that seals and unseals. The vault itself opens only with the user’s password, through a deliberately memory-hard derivation (see §7.4).

Activity-driven rotation. The next colour is derived from the current colour combined with a snapshot of the holder’s activity: courses created and delivered, packages sealed, balance movements, incoming and outgoing transfers. The more active the account, the further the colour moves. A baseline rotation can be forced even in the absence of activity.

Consequence. The period key is not a calendar object, it is a function of what has been done. Minimum cadences are configurable and are not fixed in this document.

Above the vault, two kinds of keys complete the hierarchy:

• DEK (per file): disposable symmetric key, never reused.
• Identity keys (per actor): public/private pair; the public one is distributed, the private one never leaves the device.

7.3 Capsules & proofs

A capsule (OPEN/TRANSFER) carries a policy: it only opens if the conditions are met. The opening proof (secretProofV2) is derived locally by the authorized holder from the capsule, the context (T/O/link_id/nullifier) and the Chroma material — never copyable, tied to the course, front-run-resistant.

7.4 Guiding principle

Standard primitives, in-house orchestration. The "alphabet" (AES, ML-KEM, ML-DSA, SHA-3, X25519, secp256k1) is proven and audited; the "novel" (the assembly, the policies, the capsules) is the in-house value of Chroma Guard. No home-made cipher — we never invent a cryptographic primitive, we compose them.

One exception, declared. Password derivation relies on an in-house construction, memory-hard, built on top of a standard hash function. The primitive is proven, the scheduling is not. An alternative such as Argon2id benefits from years of public analysis; ours does not. This is an accepted surface, not an oversight, and it is on our external review list ahead of mainnet.

7.5 Capsule suites

A capsule is not sealed in only one way. Three suites coexist in the product, each with a distinct role:

• a local suite, sealed under the wallet’s session key — therefore openable only by the same wallet. This is a capsule “for oneself”: local storage, never addressed to a third party;
• a classical asymmetric suite, which still seals some capsules addressed to a third party (encrypted room bootstrap, opening relay). It is not post-quantum;
• the hybrid post-quantum suite, which carries the path described in §8: it is the one that seals the separated fragment of a file delivery.

On opening, the suite is detected from the capsule itself. Whichever the suite, the unsealed key is checked against the public commitment the capsule carries: if the two do not match, opening is refused.

The opening relay carries two distinct capsules that must not be confused: the unlock right of the token, sealed with classical asymmetric encryption, and the file fragment, sealed with the hybrid post-quantum suite. It is indeed the post-quantum suite that protects the fragment.

8. Post-quantum anti-harvesting (CG-PQ1)

The central threat is HNDL: a courier (or any interceptor) can copy the ciphertext they carry and break it later. All "classical" confidentiality (poorly sealed AES alone, RSA, secp256k1) is, at that horizon, breakable. HDMEX opposes three orthogonal barriers.

8.1 Hybrid key seal

The DEK is sealed with X25519 + ML-KEM-768 — a classical mechanism and a post-quantum one combined. An attacker must break both to obtain the key; the seal holds as long as one holds. We do not bet on a single cryptographic family.

8.2 Incomplete file at the Vx (AONT + fragment on a separate route)

  File ──AONT (all-or-nothing)──► Transformed block
  Block ──remove the fragment (32 B)──► [ DATA_BUNDLE ]  +  [ fragment ]
              │                                               │
              │                       HDS-01 token { opening key + fragment }
              │                                               │
      body's courier                      another courier  or  chain (network)
              │                                               │
              └──────────► Dx recomposes and decrypts ◄───────┘

We apply an AONT transform (all-or-nothing transform): without the entirety of the block, you recover nothing. We then remove a 32-byte fragment from the transformed block. The rest of the block (DATA_BUNDLE) travels with the courier. The fragment is sealed with the hybrid post-quantum suite (§8.1) for the recipient alone, then routed by one of two ways.

What the token carries. The opening unit (HDS-01 token, §9.3) does not encapsulate only the opening key of the package: it encapsulates the fragment as well. Both travel inside the same object, each sealed for the recipient alone. The body of the file never travels with that token.

By another courier. The token is carried by a second course, entrusted to a courier who is never the one carrying the body. Neither carrier holds anything exploitable: the body without the fragment yields nothing, and the fragment is sealed for Dx — whoever carries it can open it no more than whoever carries the body. No part of the file goes online, and both barriers of §8.4 hold.

By the chain. The token is written to the ledger and reaches the recipient over the network. Once written it stays there: anyone can copy it, and only the hybrid seal protects it. This way trades the physical barrier for convenience — nothing exploitable transits or rests on a server, but one barrier remains instead of two.

The separation is a rule, not a guideline. Whichever the way, one constraint does not move: the token never takes the same carrier as the body. The transport refuses to build a delivery where the body and its fragment would travel together — a package containing both is rejected before it exists.

The fragment is moreover bound to its course: its envelope is sealed with the context (course identifier, link identifier) and carries a public commitment verified at opening. A fragment copied to another course does not open.

Dx receives both parts, recomposes the block locally and decrypts. “Vault” option: full XOR split (information-theoretic, unbreakable even under quantum) for small files.

8.3 Post-quantum signatures

ML-DSA-65 in hybrid mode on sensitive proofs (secretProofV2, OPEN, redeem). The authorization proofs remain valid and unforgeable after the arrival of quantum computing.

8.4 Why it is the differentiator

Most encrypted systems will be retro-broken. HDMEX combines two independent barriers: (a) a seal that survives quantum and (b) a physical distribution of the secret: the body and its missing fragment travel on two separate routes, and on the two-course way, with two distinct carriers. Breaking one is not enough; you must break the crypto and bring the two parts together.

9. HDS-01 — the native token standard

HDS-01 (Human Decentralized Standard, version 1) is the native token of the HDMEX chain — the utility layer, designed to be lightweight, offline-compatible and programmable.

9.1 Parameters

9.2 Receive now, record later (offline-first)

A payment in HDMEX can be received and validated locally right now — even offline — then have its value recorded on the blockchain later, at synchronization. The sender and the recipient never need to be online at the same time: value flows immediately, the chain ratifies it afterward (append-only traceability). This is what makes the token usable in dead zones without sacrificing security or traceability.

9.3 Programmable capsules (OPEN / TRANSFER)

An HDS-01 token can carry a policy and an encrypted capsule: - OPEN: the capsule only opens if the conditions are met (correct holder, correct nullifier, valid context) — anti-replay, anti front-run (redeem tied to course_id, link_id, recipient, nullifier). - TRANSFER: moves the capsule/value under policy control (forward RDV1→RDV2 for DATA_BUNDLE and TRANSFER_HANDOVER). - Sacred invariant: a capsule moves value, it never creates it (no hidden issuance → no depeg).

9.4 Positioning (comparison)

9.5 Scalability

HDS-01 is designed to evolve (HDS-02 and beyond, §21) and connects to the ERC-20 standards (Polygon) via the 1:1 bridge (§13), opening up interoperability and listing. A custom chain guarantees unique capabilities (permanent mailboxes, encapsulated payments) and reduced costs vs a general-purpose public chain.

10. Proof-of-Participation (PoP) consensus

HDMEX strictly separates two layers — this is the founding principle:

Normative rule: PoP never performs byzantine agreement itself; it weights a set of validators whose agreement is produced by CometBFT. A bug in the participation layer cannot break safety (at worst it temporarily skews the selection/reward, never the finality).

10.1 Participation score

Over a sliding window of W epochs, for a validator v:

raw_part(v) = Somme_courses ( poids_role x credit_course x decay(age) )
part_score(v) = sqrt( raw_part(v) )     (fonction sous-linéaire, anti-Sybil/anti-whale)

with credit_course capped per counterparty pair (anti-farming), decay(age) (recent participation weighs more), poids_role (Vx transport dominant, Cx creation, Dx reception, block signing).

10.2 Voting weight

voting_power(v) = sqrt(stake(v)) x sqrt(part_score(v))     (plafonné MAX_SHARE ~15-20 %)

• Sybil without work → part_score ~ 0 → weight ~ 0.
• Whale without work → limited weight (root + low participation).
• Example: Léa (stake 500, part 20) → ~100; a whale (stake 10,000, part 1) → ~100. The whale has 20x the capital for the same weight — the sqrt crushes capital, work decides.

10.3 Threat model (explicitly addressed)

10.4 Slashing

Slashable faults (loss of all or part of the stake), all provable on-chain: block double-signing (equivocation, detected by CometBFT), false participation attestation (forged counter-signature / phantom course), prolonged downtime (jail + light slash). A deferred unbonding period allows retroactive slashing and counters long-range.

10.5 Nominated mobile PoP — the unstoppable from the phone

A phone cannot be a BFT validator 24/7 (sleep, network, battery, OS). We therefore separate three roles:

Unstoppability comes from distribution: no central mint, keys on thousands of phones, anonymous and rotating committee, eligibility through work, churn tolerance.

11. The Vax — pillars of decentralization

A Vax = a Vx (the courier who carries) who, in addition, validates blocks. They are the network's owner-workers.

11.1 Becoming a Vax (evolving thresholds in p)

The first 100 are appointed (the seed, exempt from the threshold). After that, everything evolves with p — easy at launch, demanding at maturity:

(+ MIN_STAKE, evolving value recommended.) A Vax (a courier who also validates blocks) is thus a builder: they have worked (counter-signed courses) and grown the network (referrals). Example: Léa delivers ~5 courses/week (50 courses in ~2.5 months), brings in 5 active direct referrals who each bring in ~2 people → she crosses the threshold and locks her stake → she becomes a Vax.

11.2 Life cycle (state)

   [candidat] ──seuil + stake──► [Vax actif] ──< maintien──► [veille] ──90 j──► [déchu]
                                     ▲                          │
                                     └────── reprend l'activité ─┘

Maintenance: evolving activity floor 5 → 15 courses / 30 days. Below it → standby (loses rewards + is no longer selected to sign + overrides suspended, keeps badge + stake); standby > 90 d → forfeiture (re-qualification at the current threshold, stake in unbonding). Never a slash for inactivity — only proven malice makes you lose stake.

11.3 Founding Vax

Permanent soulbound badge (honorary, non-transferable, without any special consensus power), rewarded by the top of the curve for signing early (a deserved pioneer premium). No free premine: they earn by securing the network when it is fragile.

11.4 Anti-collusion (30-day window)

A course between accomplices mints ~0 thanks to five cumulative rules, which cap the credit and the mint, never the payment: 1. Cap per pair = 1 — a given pair (Cx, Dx) credits once; the 2nd → 0. 2. ≤ 25% per counterparty — catches the "hub" scheme (same Cx, varied Dx). 3. Cluster discount — credit x (1 − intra_cluster_ratio) on the courses/referral graph. 4. Independent Cx — only counts if the ordering party is outside the Vx's cluster (the courier who carries). 5. Physical friction — GPS handover + geographic presence (costly to simulate).

Example: 8 buddies set up a ring and rotate courses among themselves. The cap per pair quickly exhausts the pairs; the 25% diversity leaves them short of counterparties; the cluster discount detects the closed group → credit ~0. They bleed the 3% ops without minting anything → the ring collapses on its own.

12. Tokenomics

Principle: a SERVICE token, restrictive, with no token destruction (no burn) — regulators equate a burn with a share buyback / price manipulation. Starting parity 1 HDMEX = $0.10 (a course of 80 HDMEX = $8).

12.1 The single pilot p

A single on-chain variable (no oracle), from 1 (launch) to 0 (maturity): p = what remains of the Vax pool (a courier who also validates blocks) / initial allocation. Since the premium is proportional to courses, consuming the pool ≡ counting the courses. The formula is frozen for life; only p evolves → zero change of concept. Long horizon: 20% Vax pool ~ 205M courses (~10-12 years) — lower rates = fewer tokens resold = better price.

12.2 Genesis base distribution (7 777 777 777)

Total = 100%. Zero airdrop. The 3% of Flux A is not a genesis bucket (the old "3% buffer" was a mistake): it is the recurring intermediary commission — comparable to PayPal / eBay — that every Cx pays to the company on each course. The 3% freed from genesis is shifted to liquidity (7% → 10%).

12.3 Flux A — course payment (redistribution, no destruction)

The transport deposit T is distributed among actors (already implemented). Example, 80 HDMEX ($8): | Share | Actor | % | Receives | |---|---|---|---| | Vx (transport) | courier | 82% | 65.6 | | Dx (reception + confirmation) | recipient | 15% | 12 | | Company (intermediary commission, PayPal/eBay type) | service revenue | 3% | 2.4 |

The 3% is the company's recurring intermediary commission (trusted third-party role), paid by Cx on each course — a service revenue, not a genesis bucket.

• 1 HDMEX of securing (outside escrow) if secure rooms + hotspot are active — it is a service payment settled to the company (SECURITY_ROOT), never burned (zero burn rule). Nothing created or destroyed — value flows.

12.4 Flux B — Vax reward (mint only)

On each course, the protocol mints two things on top of the redistribution.

(a) Validator reward — 2 layers. Vax(p) = V x (1 % + 9 %.p) (V = the Vx's gain). The 1% layer is a perpetual floor (for life); the 9%·p layer is the premium drawn from the pool. | Pool | p | Vax earns | |---|---|---| | launch | 1 | 6.56 | | mid-course | 0.5 | 3.61 | | maturity | 0 | 0.66 (perpetual floor) |

(b) Referral pyramid — 5 levels, for life. Override minted upward on each real completed course of a referral: r_k(p) = r_k_max x (0,25 + 0,75.p). | Level | Max (p=1) | @p=0.5 | Permanent (p=0) | |---|---|---|---| | N1 | 8% | 5% | 2% | | N2 | 4% | 2.5% | 1% | | N3 | 2% | 1.25% | 0.5% | | N4 | 1% | 0.625% | 0.25% | | N5 | 0.5% | 0.3125% | 0.125% | | Total / course (80) | 12.4 | 7.75 | 3.1 |

Network example: Léa has 3 N1 referrals, 6 N2, 12 N3, each doing 5 courses/month. At p=1, she earns 288 HDMEX/month passively (96 per level); at maturity this income compresses ×4 (72/month). Rules (healthy MLM, not an illegal pyramid): backed by a real course (never by recruitment), compression (inactive sponsor skipped, the override climbs to the next active one), anti-loop (Cx/Dx in the tree → cancelled), 60-day activity, zero entry fee, unlimited width.

12.5 Total minted & price protection

Where the mint goes — and the risk of resale on Uniswap. The mint (Vax reward + referral overrides) goes entirely to the Vax (validators) and their referral chain (referrals): these are therefore those tokens that could be resold on Uniswap. With normal adoption (ramp 300 → 45,000 courses/day, average course 80 HDMEX), the total minted over 5 years ≈ 5.9% of the cap — and less than 0.7% cumulative over the first 3 years.

The selling pressure is therefore low and spread out: almost nil at the start (long horizon effect), it only rises (≈ 3.5%/year in year 5) once adoption is real — at the moment when demand (purchases to pay for courses + 50% purchase pool) absorbs it. The mint is also diffuse — spread over thousands of small Vax and sponsors — with no concentrated dump. → resale risk controlled by design.

The price is thus supported by demand (you must buy HDMEX to use the service) and a decreasing issuance. Without a burn — usage supports the price, not an orchestrated destruction.

12.6 In-app purchase pool (on-ramp)

A purchase module in the app (card / swap) at the current price: the fiat goes to the company (service sale), the HDMEX comes out of the 50% pool. The company operates the sale freely (liquidity must be responsive, never blocked by a vote); the pool's parameters (size, parity, replenishment) are subject to a vote (team proposes, Vax vote). Assumed choice: centralized, but it **solves the

1 problem that kills projects — the lack of liquidity*. (Note: selling the token against fiat to the

public = a primary sale, the most regulated activity — to be framed legally.)*

13. Polygon bridge & wHDMEX

The same token pays for the course and trades on Uniswap — the link = a 1:1 lock/unlock bridge, without token destruction.

  natif HDMEX ──lock──►[ PONT ]──bridgeRelease──► wHDMEX (Uniswap)
       ▲                réserve                        │
       └──────unlock──── bridgeReturn ◄────rendu───────┘   (gardé en réserve, PAS détruit)
  Invariant : wHDMEX en circulation (hors réserve) == natif verrouillé

• Outbound (native → Polygon): native HDMEX locked → proof ticket → bridgeRelease → wHDMEX released (from the bridge reserve, otherwise minted for the net shortfall).
• Return (Polygon → native): bridgeReturn → the wHDMEX is kept in the bridge reserve (never destroyed) → the relayer releases the native token.
• wHDMEX: OpenZeppelin base (ERC20 + Permit + AccessControl), 18 decimals, NATIVE_SCALE=10^12, no cap, bridge-only pause (never public transfers), EIP-2612 permit, multisig-ready.
• Peg invariant: circulatingSupply (totalSupply − reserve) == native locked, continuously monitored by the relayer (/relayer/peg) — immediate alert in case of drift.
• Exact peg: the return only accepts multiples of 10^12 → no dust.
• Tests: hardening 23/23 (return = totalSupply unchanged = zero burn; reserve reused; peg after cycles; bridge-only pause; anti-replay).

Mainnet hardening: N-of-M multisig relayer, on-chain proof of the lock, finality (anti-reorg), mint cap per window, continuous monitoring. The bridge is the most critical part (1st cause of crypto hacks) → absolute security priority.

14. Governance

Curated governance: the team holds the agenda, the active Vax + the team decide. Neither an open DAO, nor an anonymous plutocracy — the active pillars govern, on framed proposals.

Properties: the team can never decide alone (25% < 50%) but can block an attack on the DNA (25% ≥ blocking of a 3/4); no Vax (a courier who also validates blocks) dominates (15% cap); power slides toward the community (TEAM_CAP 25 → 10%) without changing the rule.

Voting example: 100 active Vax + the team (p=1, TEAM_CAP 25%). A proposal to "lower MIN_STAKE" needs ≥ 33% participation then > 50% yes → the team alone (25%) does not pass, it needs the Vax. An attempt to "reintroduce a burn" requires 3/4 → the team can block it.

Voting from the phone (native signature, no uptime). Tooling: Phase 1 = signed in-house vote (Snapshot model) + Gnosis Safe (executor) + EVM anchoring (tamper-evidence); Phase 2 = native (Cosmos x/gov, automatic execution) after CometBFT. The voting rules are written once and reused; only the plumbing becomes more decentralized.

15. Progressive decentralization

Decentralization is not a prerequisite for launch: tokenomics, Vax (a courier who also validates blocks) and governance run first on a centralized but auditable stack. We decentralize in stages, triggered by need (value at stake, public mainnet), not by the calendar — because decentralizing an unproven consensus is the worst betrayal.

Incompressible (even with fast development): the testnet soak (weeks/months under real load), the external audit (human third party), and the proof of determinism (each node computes the same state). Guiding order: product + liquidity first; a consensus bug can freeze the chain or cause loss of funds irreversibly.

PART III — USES & ECOSYSTEM

16. Detailed use cases

16.1 Journalist & source

A source must transmit sensitive documents to a journalist without leaving an exploitable trace. She encrypts locally (Chroma Guard), sets a meeting point; the Vx (the courier who carries) transports an opaque envelope with a piece missing (AONT); that piece travels on another route, sealed for the journalist alone. Even under duress, the courier can deliver nothing exploitable. The journalist recomposes and decrypts locally. Anonymity, resistance to harvesting, no server to seize.

16.2 Legal

A firm exchanges confidential documents between parties. The secure mode (multi-validation, double encryption) guarantees that only authorized persons open the capsule (policy + secretProofV2 proof), with an append-only traceability on the chain — without exposing the content.

16.3 Medical

Transfer of patient records between practitioners, including in low-coverage areas. Mailboxes allow asynchronous deposit/retrieval; client-side encryption protects the health data; post-quantum confidentiality protects over time.

16.4 Enterprise

A company (C1) deposits daily reports in mailboxes that its recipients retrieve at their own pace. Encapsulated payments, suited service commission, very low transaction costs.

16.5 Rural / humanitarian / crisis

Where the Internet is intermittent or absent, the network works anyway: local validation, physical handover by courier, 100% offline permanent mailboxes (WiFi Direct/Bluetooth/P2P, GPS+time locking validated locally, deferred synchronization). Ideal for NGOs and crisis zones.

16.6 Transport & IoT

A public transport company deposits streams in mailboxes indexed by GPS and time slots; low-connectivity IoT sensors deposit/retrieve data autonomously, without dependence on a central server.

17. Competitive comparison

Reading. The cloud and email are convenient but centralized and surveillable. Encrypted messaging protects the message but remains servers, without real offline or systematic post-quantum support. The classic courier handles the physical but offers neither cryptographic confidentiality nor decentralization. HDMEX is the only one to combine post-quantum confidentiality, offline resilience, anonymity, decentralization, and ownership through work.

18. WebApp & experience

• PWA (SvelteKit): 100% web, no imposed native app. Token management (HDS-01 creation, balances, transfers), courses, secure chat, wallet, bridge.
• Hotspot transfer: manual local Wi-Fi between devices, opaque envelope, double green check P2P — anonymity and silence, without iOS/Android native.
• Accompanying AI (IA ACC): a sober guide, FR/EN, online and offline, that reminds of the meeting point, GPS, nearby city, schedule (local time zone) and walks through the steps; interactive, in chat bubbles, with action buttons attached to the messages.
• UX security: authentication by public/private keys, visual confirmation before validation, geographic validation (maximum delivery radius respected).

19. Business model & fees

• Course pricing: indicatively ~1.05 USD/km between Cx (the creator who sends) and Dx (the recipient who receives), converted into HDMEX at the current rate (starting parity $0.10) — the service is priced in real value, settled in the token.
• Service commission: 3% to the company's operating pool (Flux A). Example: 1,000 courses/day at 80 HDMEX = 2,400 HDMEX/day for ops.
• Network fees: very low (~0.0013 USD/tx) thanks to PoP + local validation.
• Third-party projects: HDS-01 opens to integrations (minimum token amount flexible by agreement), with a suited commission (1-3%).
• Subscriptions (envisaged model): monthly offers proportional to the number of mailboxes/volume for enterprise uses.
• Long-term security budget: after the premium phase (Vax pool consumed), the Vax live off the decreasing perpetual issuance + real activity (purchases via the purchase pool, course volume). Usage funds security — since HDMEX runs on real activity, this handover is natural (unlike a purely speculative asset).

PART IV — SECURITY, FUTURE & REFERENCE

20. Security & threat model

Defense-in-depth principle: no barrier is unique. Confidentiality (encryption + PQ + fragment), consensus (BFT + PoP + slashing), token (peg invariant + no burn + immutable), governance (multisig + quorum + timelock) — each layer has several independent locks.

21. Future developments

21.1 100% offline permanent mailboxes (carried over and extended from WP 1.2)

Major axis: permanent virtual deposit points associated with GPS coordinates and time slots, allowing files to be deposited/retrieved without a simultaneous connection between sender and recipient — ideal in intermittent or nonexistent connectivity.

Operation. - Deposit: encrypted files/messages deposited securely in the mailbox. - Retrieval: the recipient decrypts with their private key (access authorized only). - Dynamic management: the mailbox is tied to time + location parameters that reinforce security.

Offline operation. - Localized deposit/retrieval: local transfer via WiFi Direct, Bluetooth or P2P between phones — 100% offline interactions. - Local state + deferred synchronization: the mailbox state (deposits made) is stored locally on the device, then synchronized with the blockchain when connectivity returns (traceability and global consistency). - GPS and time locking: the mailbox is tied to coordinates and time slots validated locally, without an active network connection. - Encryption & security: AES-256 + derived specific keys (from user identifiers), activity-driven key rotation (configurable floor) to minimize long-term attacks — even a compromised key exposes only a limited window.

Advantages. - Asynchronous communication (sender and recipient never online at the same time). - IoT & low-connectivity adaptability (rural areas, crisis zones). - Flexibility: the mailbox serves as a buffer; the decentralized nature guarantees availability without dependence on centralized servers.

These permanent mailboxes complement the courses: the reinforced security of courses on one side, the asynchronous simplicity of mailboxes on the other — a unique flexibility.

21.2 Multi-Vx courses: courier relay

The two-course way of §8.2 is its first form. A course can be relayed between several couriers (Vx1 -> Vx2 -> Vx3…) rather than entrusted to a single one. Each handover between couriers is secured like a meeting point (GPS presence, local Wi-Fi hotspot, opaque envelope, AONT fragment) and counter-signed. Benefits: long distance (crossing large routes and successive zones), resilience (if one courier drops, another takes over the segment), and reinforced anti-harvesting — no courier ever holds the complete file, and the route is split among several carriers. Each delivered segment grants participation rights for the Vx concerned.

21.3 Mesh network & P2P propagation

Extend the hotspot toward a mesh (WiFi Direct / Bluetooth relayed hop by hop) to propagate deposits and synchronizations without infrastructure — useful in dead zones or in case of outage.

21.4 HDS-02 and beyond

The HDS-01 standard evolves: richer capsules, new policies, PQ primitives integrated natively as they become standardized, and opening to third-party projects.

21.5 Cross-chain & interoperability

Beyond the 1:1 Polygon bridge, inter-shard and inter-chain bridges to broaden liquidity and accessibility, under the same security invariants (lock/unlock, monitored peg).

21.6 Governance toward the DAO

The progressive opening of the right of proposal to the Vax (a courier who also validates blocks) and the transition to native on-chain governance (Cosmos x/gov) after CometBFT — the community of makers governs fully.

22. Roadmap

1. Done: tokenomics engine (Vax reward, pyramid, eligibility/maintenance, anti-collusion, governance) + tests; wHDMEX v3 (lock/unlock, no cap) + tests 23/23 + aligned relayer; API wiring (db/service/routes) + hook on delivery confirmation + cluster detection v1.
2. In progress / upcoming: signup-referral flow (populate the tree), refined cluster detection (graph), in-app purchase module, auditable Phase A.
3. Amoy testnet (hdmex0): wHDMEX deployment + real loop (lock → release → trade → return → release → pay for a course), zero real money.
4. Before mainnet: legal structure (Estonia OÜ) + MiCA lawyer, third-party audit, LP + LP lock, N-of-M multisig, hardening of the prod chain (finality, persistence).
5. Decentralization: Phases A → D, triggered by milestones (§15).
6. Future: 100% offline permanent mailboxes (§21.1), mesh, HDS-02, cross-chain, DAO.

23. FAQ

What is HDMEX, in one sentence? An anonymous and decentralized courier network for exchanging value and sensitive files in full confidentiality, even offline.

Why a custom chain rather than Ethereum? For unique capabilities (permanent mailboxes, encapsulated payments, offline, built-in encryption) and very low fees — impossible to obtain cleanly on a general-purpose public chain.

Can the courier read or steal my file? No. The file is encrypted client-side, and the courier carries it with a piece missing. That piece travels on another route, sealed for the recipient alone: encapsulated in a token entrusted to another courier — never the same one — or passed through the chain. Even under duress, the courier has nothing exploitable.

What does "post-quantum" change? An adversary who copies today your encrypted data will not be able to break it tomorrow with a quantum computer — the hybrid ML-KEM seal resists it.

How does it work without Internet? Local validation, mailboxes, local Wi-Fi hotspot transfer; the state synchronizes later. The connection is a comfort, not a condition.

What is a Vax (a courier who also validates blocks)? A graduated courier who, in addition to delivering, validates the chain's blocks and governs its rules — from their phone.

Do you need a lot of capital to participate? No. Weight follows work (sqrt(stake) x sqrt(part)): a whale without courses has almost no power.

Is there a burn? No. HDMEX is a service token; regulators see the burn as a share buyback — we avoid it. Value comes from usage.

Does the token have a cap? No hard cap: a base of 7.77B + a decreasing perpetual issuance (inflation that trends toward ~0). It is a decreasing-inflation token, honestly labeled.

How is the price protected? By demand (you must buy to use) and decreasing issuance — without a burn or manipulation.

Is the network already decentralized? Not yet fully: today centralized but auditable. Decentralization (CometBFT/PoP) is pursued in stages, triggered by need. We never oversell this point.

How does one become a Vax? By carrying out counter-signed courses (evolving threshold), by sponsoring a few active members, and by locking a stake. The first 100 are appointed.

Who governs? The team proposes; the active Vax + the team vote (weight through work, quorum, timelock). The team never decides alone but protects the DNA.

How does one make money as a courier? 82% of the course transported, plus (if a Vax) a validation reward and referral overrides on the courses of their downline.

Isn't the referral system an illegal pyramid? No: earnings are backed by real courses (not by recruitment), bounded, with compression and anti-loop — a healthy MLM, not a pyramid scheme.

24. Conclusion

HDMEX is not an incremental improvement of a failing model — it is a different foundation. A network where the exchange of value and files is secure, anonymous and resilient; where confidentiality is designed to survive quantum; where those who do the work own and govern. A single token, from service to governance; a decentralization pursued all the way, but without haste. The courier network is at once the security budget, the liquidity and the soul of the project. Our bet: that sovereignty, anonymity and ownership through work are not ideals incompatible with a real product — but its only durable foundation.

Appendix A — Glossary

Cx / C1 creator · Vx / V1 courier · V2 super-validator · Dx / D1 recipient · Vax Vx block validator (PoP) · HDS-01 native token standard · Chroma Guard client-side confidentiality layer · DEK data key (per file) · Capsule (OPEN/TRANSFER) programmable token · secretProofV2 locally derived opening proof · nullifier anti-replay · AONT all-or-nothing transform · ML-KEM / ML-DSA post-quantum encapsulation / signature · PoP Proof-of-Participation · CometBFT BFT consensus engine · part_score participation score · p pilot (Vax pool consumption) · Flux A course redistribution · Flux B minted rewards (Vax + referral) · peg wHDMEX == native locked invariant · SECURITY_ROOT management of the +1 HDMEX securing · HNDL harvest-now-decrypt-later · unbonding stake unlock delay.

Appendix B — Parameters (quick reference)

Base 7 777 777 777 · parity $0.10 · Flux A 82/15/3 (+1 sec) · Vax reward 1%+9%.p · referral 5 lvl. 8/4/2/1/0.5% (permanent x0.25) · entry 20/2/4 → 80/8/16 · maintenance 5 → 15/month · standby→forfeiture 90 d · anti-collusion cap pair 1 / 25% / cluster / indep. Cx (30 d) · governance TEAM_CAP 25→10%, MAX_SHARE 15%, quorum 33%, thresholds 50/66/75%, timelock 7-30 d · founders 100 · premium horizon ~205M courses · unbonding ~21 d · mailbox key rotation activity-driven, configurable floor. (Config values — governable, cf. HDMEX_TOKENOMICS_NOTICE.md.)

Appendix C — Technical architecture (stack)

The layers are deliberately decoupled: the tokenomics engine is pure and transport-agnostic (API today, native chain tomorrow), confidentiality is orthogonal to consensus, and the bridge is isolated behind a monitored invariant.