Darkbloom

Watch Risque : sérieux

Darkbloom

En bref

Imagine Airbnb pour la puce de ton Mac : quand ta machine ne fait rien (en moyenne 18h/jour), elle loue sa puissance de calcul à des développeurs qui veulent faire tourner une IA — et tu es payé. La nuance qui change tout : l’hôte (toi, propriétaire du Mac) ne peut pas lire ce que le locataire fait tourner. Les questions posées à l’IA et ses réponses restent invisibles pour toi, même si tu as les pleins pouvoirs (root) sur ta propre machine.

Darkbloom est un réseau d’inférence IA privée monté sur des Macs Apple Silicon inutilisés. Pour le développeur : une API compatible OpenAI, ~50% moins chère que les API classiques, avec une garantie de confidentialité. Pour le propriétaire de Mac : un revenu passif. C’est un projet d’Eigen Labs (la société derrière EigenLayer/EigenCloud), en alpha publique depuis juin 2026.

Faits saillants

  • Produit d’infra, pas un actif coté — Darkbloom n’a aucun token et aucun airdrop annoncé ; c’est un produit Eigen Labs, pas une crypto à acheter. L’exposition d’investisseur est uniquement indirecte (via EIGEN / l’equity Eigen Labs) (bio @darkbloomai + landing, 2026-06-25).
  • Zéro blockchain dans le design — la « vérifiabilité » ne vient pas de la crypto-économie mais de la chaîne d’attestation matérielle Apple (Secure Enclave → Managed Device Attestation → Apple root CA). Le routage passe par un coordinateur centralisé opéré par Eigen Labs (paper Naik, avril 2026).
  • Le wedge coût = absence de TEE grand public — un serveur à TEE (Intel TDX / AMD SEV-SNP / Nvidia Confidential Computing) coûte $14 000+ ; or 100M+ de Macs grand public sont déjà vendus. Sur unified memory, les modèles MoE tournent 6–32× moins cher que sur GPU cloud (paper §1 + §contributions, avril 2026).
  • Traction OpenRouter rapide — live sur OpenRouter le 15 juin 2026 ; ~20% du token-share Gemma 4 en J3 ; ~1M requêtes cumulées, ~2B tokens servis/semaine, ~300 machines live au 22 juin 2026 (tweets équipe @gajesh / @0xkydo).
  • Limite centrale assumée honnêtement — les Macs n’ont pas de TEE applicatif ; la confidentialité repose à 100% sur du logiciel et sur « le kernel macOS n’a pas de zero-day » (Assumption 1 du paper). « Only hardware TEEs provide immunity to kernel-level attacks » (paper, Limitations).
  • Subvention pure côté offre — pendant l’alpha, 100% des revenus d’inférence vont au provider + une « base reward » de $10–40/mois par palier mémoire, financée par un budget mensuel fixe qui « taper as the network grows ». L’équipe reconnaît que « les earnings sont bas right now » (gajesh, 2026-06-19).

Comment ça marche

Darkbloom est un marché d’inférence à 3 acteurs — Consumer / Coordinator / Provider — où le Mac qui exécute le modèle ne peut jamais lire le prompt. Non pas grâce à un TEE matériel (les Macs n’en ont pas pour l’isolation applicative), mais en éliminant TOUS les chemins logiciels d’observation, plus une attestation Apple à 5 couches. Après ça, le seul vecteur d’attaque restant est le sondage physique des puces mémoire — soudées au SoC — exactement le threat model résiduel accepté par Apple Private Cloud Compute.

Le problème résolu. Quand tu envoies un prompt à un service IA cloud, il voyage vers un serveur que quelqu’un d’autre possède : ta vie privée repose sur une promesse contractuelle (une privacy policy), pas une garantie technique. Les TEE matériels (Intel TDX, AMD SEV-SNP, Nvidia Confidential Computing) offrent une vraie isolation cryptographique de la mémoire — mais n’existent que sur du hardware serveur à $14 000+. Pendant ce temps, 100M+ de Macs Apple Silicon ont été vendus, dotés de GPU sérieux et d’unified memory, inutilisés ~18h/jour. Darkbloom transforme cette capacité dormante en marché d’inférence privée.

L’architecture (3 acteurs, aucune chaîne).

  • Consumer (C) — le développeur. Il garde son client OpenAI, change juste la base_url vers api.darkbloom.dev. La requête est chiffrée avant de quitter son app.
  • Coordinator (K) — le service de routage + vérification, opéré par Eigen Labs. Il tourne lui-même dans une Confidential VM AMD SEV-SNP (sa mémoire est chiffrée par le TEE ; ni le cloud operator ni Eigen ne peuvent la lire). Il route du ciphertext qu’il ne peut pas déchiffrer, et choisit le provider via un scheduler de minimisation de coût (charge + santé + réputation).
  • Provider (P) — le Mac. Un CLI Swift darkbloom qui exécute mlx-swift-lm in-process sur le GPU Apple Silicon. Le provider est présumé adversaire : il a root, custody physique, peut rebooter, brancher du RDMA Thunderbolt 5. Seule sa clé hardware-bound (Secure Enclave) déchiffre la requête qui lui est routée.

Il n’y a ni smart contract, ni token, ni règlement on-chain : le routage, le paiement et la vérification sont gérés off-chain par le coordinateur.

L’innovation centrale (UNE) : « software access path elimination ». Plutôt que d’isoler la mémoire par du hardware (impossible sans TEE applicatif), Darkbloom brique toutes les fenêtres logicielles par lesquelles l’opérateur pourrait observer l’inférence :

  • L’inférence tourne dans un seul process Swift durci — pas de subprocess, pas de serveur local, pas d’IPC (rien à intercepter entre processus).
  • Le kernel macOS bloque tout accès mémoire externe : PT_DENY_ATTACH (debuggers refusés au niveau syscall), Hardened Runtime (APIs de lecture mémoire bloquées). Ces protections ne peuvent pas être désactivées sans rebooter — et rebooter tue le process et efface ses données. Le paper prouve formellement que la System Integrity Protection, une fois vérifiée au démarrage, est immuable pour la vie du process (Theorem 1).

Analogie du point dur : c’est une boîte à gants scellée. L’opérateur peut y brancher du calcul, mais chaque hublot pour regarder à l’intérieur a été muré ; et seul le sceau d’usine Apple prouve que la boîte est authentique.

L’attestation à 5 couches (chaque couche couvre un trou des autres) :

CoucheMécanismeMenace adressée
1Signature Secure Enclave P-256 ECDSAIdentité liée au hardware ; anti-rejeu
2MDM SecurityInfo (Apple)Vérif indépendante de SIP / Secure Boot (pas via le soft du provider)
3Managed Device Attestation over MDMCert chain signée Apple = hardware authentique
4Challenge-response périodique (5 min)Liveness ; la posture sécurité n’a pas dégradé
5APNs code-identity attestationLe binaire qui tourne est bien le darkbloom signé par l’équipe

Performance validée (paper §12, hardware de prod M2 + M4 Max) : décodage 92 tok/s (modèle 9B Q4 sur M4 Max), 22 tok/s sur M2 ; time-to-first-token 1,4s ; overhead sécurité 12ms/requête ; 8 requêtes concurrentes, 0 échec ; AES-256 (16 MB) en 0,37ms. La sécurité ajoute donc un coût négligeable.

Le test on-chain

Darkbloom échoue le test « pourquoi une blockchain ? » — parce qu’il n’y en a aucune. C’est un produit systèmes off-chain : coordinateur centralisé de confiance (protégé par un TEE) + attestation matérielle Apple. Sa garantie de confidentialité repose sur « le kernel macOS et l’infra de signature Apple ne sont pas compromis », PAS sur de la crypto-économie. Le lien crypto est l’ombrelle Eigen Labs, pas le design.

Ce qui est réellement nouveau (et ne tient pas à une chaîne) : faire de l’inférence privée sur une machine qu’on ne possède pas et qu’on ne fait pas confiance, sans TEE matériel. C’est une vraie contribution systèmes — mais elle est vérifiable via la PKI d’Apple, pas via un registre décentralisé.

Ce qui n’est pas on-chain du tout : le coordinateur est un point de confiance unique (single chokepoint) qui route 100% du trafic et héberge la logique de vérification. Il tourne en SEV-SNP, donc sa mémoire est protégée — mais c’est un service centralisé opéré par Eigen Labs, pas un ensemble de contrats. Aucun slashing crypto-économique, aucun token, aucun règlement on-chain. Le système tournerait à l’identique sans aucune blockchain.

Où la crypto pourrait entrer : c’est un projet Eigen Labs, et la roadmap naturelle serait de brancher l’attestation/le slashing des providers sur la vérification crypto-économique d’EigenCloud (restaking, EigenVerify). Rien de tel n’est live ni documenté pour Darkbloom aujourd’hui. En l’état, c’est du « DePIN » au sens lâche (l’offre matérielle est décentralisée : des Macs un peu partout) mais le modèle de confiance reste centralisé (Apple + un coordinateur). La décentralisation est dans le hardware, pas dans la confiance.

Le token

Pas de token natif. Darkbloom n’a émis aucun token et n’a annoncé aucun airdrop au 2026-06-25. La rémunération des providers est libellée en dollars (le calculateur d’earnings affiche des $/mois), pas en token. Toute spéculation sur un futur token est non documentée — ne rien inventer. La seule exposition crypto est indirecte : Eigen Labs porte le token EIGEN (EigenCloud), mais aucun mécanisme documenté ne fait remonter les revenus de Darkbloom vers EIGEN.

Revenus & modèle éco

Pendant l’alpha publique, Darkbloom ne capture aucun revenu : 100% des revenus d’inférence vont au provider, plus une « base reward » subventionnée ($10–40/mois selon le palier mémoire) financée par un budget mensuel fixe qui se réduit à mesure que le réseau grandit. C’est une subvention pure d’acquisition de l’offre, pas un business à l’équilibre.

(a) Revenus actuels documentés. Côté coordinateur (Eigen Labs) : 0 pendant l’alpha — « operators keep 100% of inference revenue during the public alpha » (landing, 2026-06-25). Côté consumer, le pricing public (par million de tokens) :

ModèleInputOutputAPI classiqueÉcart
Gemma 4 26B (MoE, 128K)$0,03$0,165$0,33-50%
GPT-OSS 20B (MoE, 128K)$0,015$0,07$0,14-50%

La « base reward » va de $10/mois (24 GB) à $40/mois (512 GB), versée aux machines attestées online ≥90% du mois, « up to a fixed monthly budget — not a guarantee, and they taper as the network grows » (landing, 2026-06-25). Le calculateur affiche ~$197/mois à 80% d’utilisation, mais avec le disclaimer « the live network runs lower today ».

(b) Revenus annoncés non encore live. La formulation « 100% during the public alpha » implique qu’un take-rate du coordinateur s’activera post-alpha — mais aucun take-rate ni pricing post-alpha n’est documenté publiquement au 2026-06-25. Ne pas inventer de ligne forward.

(c) Gap. Avec 0 revenu protocole aujourd’hui et une base-reward qui tapera, la question éco centrale est : la demande organique (volume OpenRouter) suffira-t-elle à payer les providers une fois la subvention retirée ? L’équipe admet elle-même « earnings are low right now » (gajesh, 2026-06-19) et a dû publier une explication. Le wedge coût est réel et grounded (avantage MoE 6–32× sur unified memory vs GPU cloud, paper), mais sa pérennité dépend de cette bascule subvention → demande.

Pas de dashboard public on-chain (le protocole est off-chain) — les métriques de traction viennent des annonces équipe et d’OpenRouter.

Marché visé (2-3 ans)

Pas de valorisation comparative possible par multiples : Darkbloom n’a pas de token, donc ni MC, ni FDV, ni multiple fees — INSUFFICIENT GROUNDING sur la partie comps chiffrée (par construction, pas par manque de recherche). Le pari ici n’est pas un token mais une question business : Eigen Labs peut-il faire de l’inférence privée sur Macs idle une couche d’inférence vraiment compétitive en coût ? L’exposition d’investisseur reste indirecte (EIGEN / equity Eigen Labs).

TAM (côté demande). Le marché de l’inférence IA pèse ~105 Md$ (2025) → ~120 Md$ (2026), avec un CAGR ~13–19% — consensus de 4 cabinets (Fortune Business Insights $103,7→117,8 Md$ CAGR 12,98% ; MarketsandMarkets $106→255 Md$ CAGR 19,2% ; Polaris ; Kings Research), un outlier (SNS Insider, $7,5 Md$ base 2025) écarté. Le segment confidential computing (proxy le plus proche de la « privacy-preserving AI ») pèse ~12–24 Md$ (2025) selon le cabinet, CAGR >30% chez 3 des 4 sources — le signal robuste est la croissance, pas le niveau. Il n’existe aucun TAM $ fiable isolant le « DePIN compute » (le « $30–50 Md » cité ailleurs est une market cap de tokens, pas un revenu de service). Côté offre, les ancres sont grounded dans le paper : 100M+ Macs Apple Silicon vendus depuis 2020, ~8 GW de capacité ML-éligible idle 12h+/jour. Le SAM crédible est une fraction étroite de tout ça : seuls les Macs ≥48–64 GB servent les modèles utiles, et seuls les workloads sensibles à la confidentialité (santé, légal, agents on-chain à secrets) paient une prime privacy — le reste optimise coût + latence.

Peer group — Darkbloom appartient au cluster sans-token, pas au cluster DePIN tokenisé. Le constat structurant : les concurrents les plus proches (private inference API OpenAI-compatible : Tinfoil, Atoma ; angle Apple Silicon : exo) n’ont pas de token non plus. Dans le wiki, les comps internes les plus proches sont UsePod (marketplace d’inférence privée TEE/DePIN, sans token) et Venice (inférence privée + non censurée, API OpenAI-compatible, token VVV — fondé par Erik Voorhees). Le sous-groupe DePIN tokenisé (IO, TAO, PHA, NIL) est plus adjacent que direct. Darkbloom n’est donc pas valorisable par multiples — il se compare à des startups infra, pas à des tokens. Mcaps des pairs tokenisés au 2026-06-25 (CoinGecko) données pour situer le capital alloué au secteur, pas comme comparable de Darkbloom :

ProjetApproche privacy/vérifTokenMC / FDV (2026-06-25)Proximité
DarkbloomÉlimination des chemins logiciels + attestation Apple (pas de TEE)aucun
TinfoilTEE sur GPU Nvidia Confidential Computing, API OpenAI-compatibleaucun (YC, seed undisclosed mai 2025)Direct (private inference API)
AtomaTEE, inférence privée décentraliséeaucun confirméDirect (private inference)
ExoCluster multi-Mac Apple Silicon (MLX), pas de privacyaucun (open-source)Proche (angle Mac ; mais self-host, pas marketplace tiers)
UsePodTEE, marketplace d’inférence privée décentraliséeaucunDirect (fiché wiki)
VeniceInférence privée + non censurée, API OpenAI-compatible, 200+ modèlesVVV (+DIEM)n/dDirect (fiché wiki)
Apple PCCMêmes principes, serveurs Apple de confiancenon (Apple)Le « gold standard » dont Darkbloom copie le threat model résiduel
RitualZK proofs + Intel SGXpré-token ($25M seed, Archetype)Adjacent (inférence vérifiable)
NillionMPC/HE + TEE (nilAI = private LLM inference)NIL$17,1M / $35,0MAdjacent (privacy infra)
PhalaTEE Intel TDX + Nvidia H100/H200 CCPHA$29,3M / $34,8MAdjacent (confidential AI)
io.netAgrégation GPU (pas de garantie hardware)IO$63,0M / $144,1MAdjacent (DePIN GPU)
BittensorConsensus stake-weighted (pas de privacy)TAO$2,09Md / $4,57MdAdjacent (IA décentralisée)
EigenCloud (EigenAI)Re-exécution déterministe (crypto-éco)EIGEN$198M / $489MFrère (inférence vérifiableprivée)

Asymétrie. Si ça marche : Eigen Labs tient une couche d’inférence structurellement moins chère (hardware déjà payé, coût marginal ≈ électricité) ET privée — un différenciateur réel pour les workloads sensibles, avec une boucle « Mac owners gagnent → plus d’offre → prix bas ». Mais il n’y a pas de token pour capturer cet upside directement, et le downside (subvention qui tape avant la demande, 0-day kernel, dépendance Apple) ne se hedge pas par un actif liquide. L’asymétrie est celle d’un produit, pas d’un trade : intéressante à suivre pour la thèse Eigen Labs, pas directement investissable.

Faiblesses & argument CONTRE

Le risque n’est pas un rug ou une dilution (il n’y a pas de token) — c’est structurel : une confidentialité qui repose sur une assumption logicielle (zero-day kernel macOS) au lieu d’un TEE matériel, un coordinateur centralisé, une dépendance mono-vendeur à Apple, et une économie d’offre subventionnée dont la bascule vers la demande organique n’est pas prouvée. La techno livre ; la durabilité éco et la robustesse du modèle de confiance restent à prouver.

  1. Sécurité = assumption logicielle, pas TEE matériel (sérieux). Un zero-day du kernel macOS bypassant SIP / Hardened Runtime / KIP casse la garantie de confidentialité pour tout prompt traité pendant la fenêtre. Mitigation : attestation 5 couches + « reliance on Apple’s track record of rapid patching » — mais le paper concède que « only hardware TEEs provide immunity to kernel-level attacks ». Pas de mitigation matérielle.
  2. Coordinateur centralisé = point de confiance/défaillance unique (sérieux). Il route tout, héberge la vérif, est opéré par Eigen Labs. Mitigation : sa mémoire tourne en TEE SEV-SNP — mais le routage et la disponibilité ne sont pas décentralisés.
  3. Dépendance Apple mono-vendeur (sérieux). Tout le modèle de confiance dépend de la Secure Enclave, MDA, MDM, Hardened Runtime — qu’Apple peut modifier ou restreindre. Mitigation : aucune ; dépendance structurelle à un seul fournisseur.
  4. Économie d’offre subventionnée et fragile (sérieux). Les base rewards subventionnent les providers et « taper as the network grows » ; si la demande organique ne suit pas, les earnings s’effondrent (l’équipe admet « earnings low »). Mitigation : l’intégration OpenRouter pousse la demande — mais sa capacité à soutenir les payouts est non prouvée.
  5. Pas de capture de valeur pour un investisseur (sérieux, lens invest). Aucun token, aucun airdrop annoncé ; l’exposition n’est qu’indirecte via EIGEN. Mitigation : aucune — c’est un produit, pas un actif.
  6. Marché de l’inférence saturé + privacy de niche (sérieux). Concurrence frontale sur le prix (io.net, Together, Fireworks, et le pool propre d’OpenRouter) ; la plupart des devs optimisent coût + latence, pas la confidentialité (même contre-thèse qu’EigenAI). Mitigation : wedge prix -50% réel + la privacy est un vrai « must-have » pour des niches (santé, légal, agents à secrets).
  7. Side-channel temporel résiduel (jaune). Le contenu des tokens est protégé, mais leur timing est observable : les intervalles de paquets réseau révèlent la longueur approximative du prompt (durée de prefill). Mitigation : anonymisation OHTTP / blind signatures listée en future work — pas live.
  8. Catalogue de modèles étroit (mineur). Seulement 2 modèles live (Gemma 4 26B, GPT-OSS 20B) vs catalogues hyperscalers. Mitigation : MoE jusqu’à 239B revendiqué ; sharding multi-machines (400B+) via Thunderbolt 5 RDMA en future work.

Contre-thèse la plus forte. Les développeurs IA achètent sur le coût et la latence, pas la confidentialité. L’inférence privée est un « nice-to-have » pour la majorité, un « must-have » seulement pour des niches. Si la privacy reste de niche, Darkbloom se bat purement sur son wedge prix -50% — qui s’évapore si les base rewards (la subvention qui finance ce wedge) tapent avant que la demande organique scale, ou si un hyperscaler baisse ses prix. Et contrairement à un projet à token, il n’y a aucune réflexivité spéculative pour bootstrapper le réseau : pas d’airdrop farming, pas de token à pumper — juste de l’offre et de la demande réelles à équilibrer. C’est plus honnête, mais aussi plus dur à amorcer.

Équipe & crédibilité

Équipe Eigen Labs crédible et identifiée (pas d’anon, pas de mint furtif) : le paper est signé d’un ingénieur core (Gajesh Naik), la figure publique est le Head of Research d’Eigen Labs (Soubhik Deb, PhD UW / IIT Bombay), le tout sous l’ombrelle de Sreeram Kannan (a16z, 4 tours). Aucun pattern de red flag scam — mais c’est un projet jeune (alpha) dont l’équipe dédiée au-delà de 2-3 noms est peu documentée.

  • Gajesh Naik — Eigen Labs (gajesh@eigenlabs.org). Auteur du paper technique « Private Distributed Inference on Consumer Hardware » (avril 2026) ; ingénieur core qui porte les updates produit et traction sur X (@gajesh).
  • Soubhik DebHead of Research @ Eigen Labs. PhD University of Washington, undergrad IIT Bombay, co-host @postagixyz. C’est lui qui a posté l’annonce/lancement (tweet du 2026-06-11, 32k vues). Profil chercheur crédible (bio X vérifiée, soubhikdeb.com).
  • @0xkydo — a rejoint le projet en juin 2026, relaie traction et BD.
  • Tutelle Eigen Labs — CEO Sreeram Kannan (ex-prof University of Washington, cf EigenCloud), société backée par a16z (~$164M+ equity). Darkbloom est promu par les comptes officiels @eigenlabs et @eigencloud, et personnellement par Sreeram Kannan.

Endorsements sérieux. Intégration officielle OpenRouter (annoncée par @OpenRouter le 16 juin 2026, « served by Eigen Labs’s Darkbloom »). Pas de pattern serial-founder/Bankr/squat — distribution sans token, équipe nominative, paper public. La principale réserve est le bus factor : au-delà de Naik/Deb, l’équipe dédiée Darkbloom n’est pas documentée publiquement.

Évolution

  • Mars 2024 — Création du compte @darkbloomai (le projet couvait en interne chez Eigen Labs).
  • Avril 2026 — Publication du paper technique (Gajesh Naik), validé sur M2 + M4 Max.
  • 11 juin 2026Lancement public / annonce Soubhik Deb (32k vues).
  • 15-16 juin 2026Live sur OpenRouter ; 130M tokens servis en 12h ; ~20% du token-share Gemma 4 en J3.
  • 22 juin 2026 — ~1M requêtes cumulées, ~2B tokens/semaine, ~300 machines live.

Signaux à surveiller

Valident la thèse :

  • Demande organique soutenant les earnings providers APRÈS que les base rewards aient tapé (aujourd’hui : earnings « low », subventionnés).
  • Croissance du token-share OpenRouter au-delà de l’effet nouveauté (était ~20% sur Gemma 4 en J3, juin 2026).
  • Élargissement du catalogue au-delà de 2 modèles ; sharding multi-Mac (400B+ params) effectivement shippé.
  • Bascule vers une vérification crypto-économique / intégration EigenCloud — ce qui rendrait le système réellement on-chain.
  • Croissance du nombre de machines (300 au 22 juin 2026) + uptime attesté.
  • Annonce d’un éventuel token / programme d’incitation (aucun à date).

Invalident la thèse :

  • Zero-day kernel macOS bypassant SIP / Hardened Runtime (casse la garantie centrale).
  • Apple restreignant les APIs MDA / MDM / Hardened Runtime dont Darkbloom dépend.
  • Exode des providers à mesure que les base rewards tapent, faute de demande organique.
  • Baisse de prix d’un hyperscaler / concurrent effaçant le wedge -50%.
  • Incident sur le coordinateur centralisé (downtime, brèche de confiance).

Sources