Statut : alpha. Une revue de sécurité externe a eu lieu le 13/08/2026 — 85 constats dont 13 critiques — et ses rapports sont publiés tels quels dans docs/audit/2026-08-13/. C'était une revue à un seul relecteur, pas un audit de cabinet établi, et elle ne remplace pas ce dernier.

Le code n'a par ailleurs jamais été éprouvé entre deux machines physiques derrière deux NAT distincts : le jalon de mai 2026 précède deux ruptures de protocole et une régression qui a rendu le nœud muet sur tout réseau réel pendant deux mois sans qu'aucun compteur ne le signale. N'engagez pas de valeur réelle que vous ne pouvez pas perdre.

Envoyez un rapport privé à nobodyohm@gmail.com avec :

• une description et l'impact estimé,
• les étapes de reproduction (idéalement un test ou un PoC),
• la version / le commit concerné.

Merci de ne pas ouvrir d'issue publique pour une faille exploitable avant qu'un correctif soit disponible. Réponse visée sous 7 jours.

Le passage v9 → v10 est la réponse à l'audit externe du 13/08/2026 : la pré-image signée d'une transaction, la feuille Merkle et l'en-tête de bloc passent à un encodage injectif (séparateur de domaine + champs préfixés en longueur), et l'unicité d'une transaction devient une règle de consensus (nonce de compte séquentiel vérifié à l'inclusion). Toute signature et tout hash changent, genèse comprise ; un nœud v9 et un nœud v10 ne peuvent pas converger.

Frontière post-quantique. Il n'y a plus de schéma hybride ni de repli classique : l'autorité d'une transaction, d'un vote de finalité ou d'une enveloppe gossip est une signature ML-DSA-65, et rien d'autre. Une adresse est BLAKE3(ADDR_DOMAIN ‖ clé publique ML-DSA) ; la clé ML-DSA est dérivée déterministiquement de la graine (XOF BLAKE3), donc aucune matière secrète supplémentaire n'est persistée. L'échange de clés QUIC/TLS négocie l'hybride X25519MLKEM768, ce qui protège la confidentialité du transport contre une attaque harvest-now-decrypt-later.

Ce qui reste classique. L'identité de nœud d'Iroh (NodeId = Ed25519) : c'est une dette upstream, Iroh attend un consensus d'industrie sur la signature post-quantique des EndpointIds. Elle n'authentifie ni l'argent, ni la finalité, ni les messages — seulement le point de terminaison réseau.

Le raisonnement complet derrière ces choix — ce qu'un ordinateur quantique casse exactement, pourquoi une chaîne publique est un cas particulier, pourquoi l'hybride sur le transport et le PQ pur sur les signatures — est développé dans docs/POST-QUANTUM.md.

• Forge de transactions : chaque tx est signée ML-DSA-65 par la clé liée à l'adresse de l'expéditeur, et re-vérifiée par chaque nœud. Les adresses synthétiques NETWORK / ESCROW sont exemptes de signature ; un expéditeur synthétique ne peut apparaître que dans une coinbase Mining, et l'ensemble exact des bénéficiaires et de leurs montants est re-dérivé de la chaîne par chaque nœud (validate_block_reward_plan). Un Transfer depuis NETWORK est rejeté (sinon il aurait minté sans limite, invisible au plafond). (Corrigé le 13/08/2026 : ce paragraphe annonçait « au plus une tx de minage », règle remplacée par le plan de récompense au fork v9 — la documentation n'avait pas suivi le code.)
• Rejeu : nonce monotone par expéditeur, identifiant d'enveloppe canonique (id == BLAKE3 de la pré-image signée), déduplication LRU 100 K insérée après la vérification de signature, fenêtre de fraîcheur ±90 s, seen_tx_hashes au ledger.
• Double-dépense : règle de couverture symétrique — un bloc reçu dont une dépense n'est pas couverte par le solde on-chain est rejeté, et un bloc scellé localement exclut ces tx, donc il est valide par construction. Conservation Σ(dépensable + staké + en déverrouillage) + brûlé == miné vérifiée à chaque pas de simulation.
• Réécriture de l'histoire : plancher de finalité monotone, vérifié par hash et persisté ; aucun fork ne peut remplacer un bloc situé sous le plancher.
• Équivocation d'un validateur : détectée à l'ingestion (double-vote et surround), preuve ML-DSA non-répudiable diffusée, enjeu de l'offenseur détruit STAKE→BURN — y compris l'enjeu en cours de déverrouillage, pour qu'un « unstake-and-run » ne mette pas les fonds à l'abri. Un proposeur malveillant ne peut pas punir un innocent : la preuve embarquée est re-vérifiée par chaque nœud.
• DoS gossip : 4 Mio max par enveloppe (MAX_RAW_ENVELOPE_BYTES, réduit de 10 Mo après R3 — un OOM distant par un pair non authentifié), rate-limit adaptatif plafonné à 120 msg/min msg/min, 50 blocs max par segment de synchronisation, bannissement après 3 signalements, cartes par pair bornées en mémoire.
• Eclipse : heuristique de collision de préfixe de clé publique (> 80 %).
• Sybil (économique) : le poids d'élection est l'enjeu inscrit sur la chaîne, une fonction pure du ledger — la réputation locale a été retirée du chemin de sécurité, précisément parce qu'elle divergeait entre nœuds.
• RPC monnaie : les méthodes qui déplacent des fonds exigent un jeton cookie et passent une garde Origin / Content-Type ; sans elle, un fetch() depuis n'importe quelle page web atteignait sendtoaddress en requête CORS simple.

Par honnêteté, et c'est la ligne du projet :

• Pas d'audit tiers. Un audit interne adversarial (25/07/2026, docs/audit/AUDIT-INTERNE-2026-07-25.md) a ouvert 4 critiques, 8 hauts et 4 moyens, tous corrigés derrière le fork v7. Ce n'est pas un audit externe. Le dossier de consultation est prêt dans docs/audit/.
• Échelle non éprouvée. Deux machines physiques (mai 2026) et un test d'intégration deux nœuds. Les partitions, réordres, crashs et nœuds byzantins sont couverts en simulation déterministe seedée, pas sur un vrai réseau.
• Aléa d'élection. L'élection du proposeur est déterministe et publiquement vérifiable — ce n'est pas un VRF : le leader d'un slot est prévisible. Un beacon enterré bloque le grinding immédiat ; un vrai VRF et un VDF sont au roadmap (ADR-004, ouverte).
• Identité de nœud classique (voir ci-dessus).
• Pas de confidentialité on-chain. Transactions et soldes sont publics ; aucune couche ZK.
• Binaires non notarisés / non signés. La dernière release publiée date de mai 2026 et ne correspond plus au code.

Un audit externe sans complaisance a produit 85 constats, dont 13 critiques. Le motif dominant n'était pas l'incompétence mais un angle mort méthodologique : le projet vérifiait très bien ce qu'il avait décidé de vérifier, et ne vérifiait pas ce dont il n'avait jamais écrit la règle. Les défenses présentes étaient bonnes ; ce sont les défenses absentes qui ouvraient le système, et elles étaient absentes en silence, sans test rouge pour le dire.

Les rapports d'origine sont publics. Les six documents de la revue du 13/08/2026 et le PoC exécutable de C-1 sont versionnés dans docs/audit/2026-08-13/, sans coupe ni reformulation. Sans le constat d'origine, une remédiation demande d'être crue sur parole.

Ce qui reste vrai malgré tout : la liaison intrinsèque adresse↔clé (from == BLAKE3(ADDR_DOMAIN ‖ pk)), l'indépendance réelle de la racine ML-DSA vis-à-vis d'Ed25519, la récompense de bloc recalculée plutôt que crue, l'absence de XSS stockée, la défense CSRF du RPC, Argon2id au-dessus d'OWASP.

Ce que l'audit n'a pas vérifié, et que nous ne prétendons donc pas : aucun réseau réel (tout en mémoire, dans un même processus) ; pas de mesure de temps constant sur fips204/aes-gcm ; pas de fuzzing conduit ; pas de revue de fips204 lui-même. La cible de fuzz existante était d'ailleurs inopérante — 100 % des entrées mouraient au mur de signature ML-DSA, donc la couverture réelle des parseurs était nulle (SC-06, corrigé) ; le fuzzing reste néanmoins à conduire.

Section réécrite le 13/08/2026 après un audit externe. Trois affirmations y étaient fausses, et deux d'entre elles servaient à justifier des décisions de sécurité — c'est le pire usage possible d'une phrase inexacte.

• deny.toml — cargo deny check (licences, advisories RUSTSEC, sources, doublons). La porte était inopérante : elle renvoyait 0 alors que l'arbre portait 4 vulnérabilités et un use-after-free (RUSTSEC-2026-0253, lru), parce que [advisories] ne déclarait que yanked et qu'une liste d'ignore — dont six périmés — couvrait le reste. Les ignore doivent porter une justification datée, et cargo audit tourne désormais sans liste d'exclusion à côté, pour que le chiffre brut reste visible.
• cargo audit — vulnérabilités connues des dépendances. Le chiffre à jour (13/08/2026) est 4 vulnérabilités + 22 avertissements transitifs, pas « 8 ». Parmi elles, hickory-* (boucle non bornée sur réponse DNS) est sur un chemin réseau réel, via le résolveur d'iroh.
• L'application embarque bien un client HTTP sortant. reqwest et hyper sont dans l'arbre via iroh, iroh-relay et tauri-plugin-updater, que lib.rs enregistre. L'affirmation inverse figurait ici et servait de justification à quatre ignore de deny.toml ; les deux sont corrigés.
• Un seul bloc unsafe dans tout le backend (interop AppKit pour l'état d'occlusion de la fenêtre, guardian.rs) ; zéro dans la couche cryptographique, et fips204 est lui-même pur Rust sans unsafe. (Vérifié par l'audit.)
• Secrets zeroize-és en mémoire ; jamais de clé privée dans les logs ou les erreurs. (Vérifié par l'audit, avec une réserve : le mnémonique BIP39 lui-même n'est pas encore zeroize-é.)

1. Aucune unwrap() dans le code de production — Result + ?.
2. tokio::sync uniquement à travers un .await (jamais std::sync).
3. Tous les montants en u64 µQTA (jamais de f64 pour les soldes).
4. Erreurs de déchiffrement opaques (« Invalid », jamais le type réel).
5. L'autorité d'un compte est ML-DSA ; Ed25519 n'est plus qu'un identifiant de point de terminaison réseau.