
Bless
BLESS#801
Che cos’è Bless?
Bless è una rete decentralizzata di edge computing che tenta di trasformare la capacità inattiva dei dispositivi consumer in un livello di calcolo condiviso per le applicazioni, in particolare per l’IA, i dati e i carichi di lavoro sensibili alla latenza.
Invece di noleggiare capacità da provider cloud centralizzati di tipo hyperscale, gli sviluppatori dovrebbero instradare i job attraverso la rete di nodi di Bless, mentre i proprietari dei dispositivi contribuiscono con CPU, GPU, banda o uptime e ricevono ricompense.
Il suo vantaggio competitivo proposto non è una nuova blockchain general-purpose, ma un livello di coordinamento per calcolo eterogeneo: i materiali del progetto descrivono una combinazione di nodi browser e nativi, isolamento tramite WebAssembly, matching dinamico delle risorse e verifiche specifiche per tipo di carico di lavoro, con l’obiettivo di rendere i dispositivi comuni utilizzabili come infrastruttura distribuita anziché semplici detentori passivi di token, come descritto nella documentazione ufficiale di Bless e nella documentazione sul network dispatch.
Bless si colloca nella nicchia della physical infrastructure decentralizzata e del calcolo decentralizzato, piuttosto che nelle categorie core di Layer 1 o DeFi.
Tra fine luglio e inizio agosto 2026, le pagine di mercato di terze parti collocavano BLESS nella fascia medio-bassa di capitalizzazione tra gli asset crypto: CoinMarketCap mostrava una capitalizzazione di mercato inferiore ai 20 milioni di dollari e un rank intorno ai 700, mentre CoinGecko indicava una capitalizzazione simile, sempre sotto i 20 milioni di dollari, e un rank intorno agli 800; le informazioni sull’asset fornite per questo report mostravano invece un’istantanea di market cap più elevata, di circa 38,6 milioni di dollari e un prezzo nell’ordine di poco più di un centesimo, evidenziando come liquidità ridotta, metodologia sull’offerta e tempistiche possano cambiare in modo sostanziale la dimensione apparente per i token giovani.
Bless non presenta un profilo DeFi TVL significativo paragonabile a mercati di lending o DEX; gli aggregatori di TVL definiscono il TVL come gli asset degli utenti bloccati nei contratti del protocollo, come spiegato dalla metodologia TVL di DeFiLlama, mentre la stessa documentazione per sviluppatori di Bless descrive ancora in parte le implementazioni in testnet o beta come gratuite e non ancora in un ambiente di billing in produzione, il che rende l’utilizzo di calcolo, i nodi attivi e la domanda di carichi di lavoro pagati più rilevanti del TVL per valutare l’adozione.
Chi ha fondato Bless e quando?
Bless è stata fondata a San Francisco nel 2022 con il nome Blockless, durante la fase di contrazione del mercato crypto successiva al 2021 e nelle prime fasi della spinta istituzionale verso l’infrastruttura IA e le reti in stile DePIN.
CoinMarketCap identifica Butian Li, Michael Chen e Liam Zhang come fondatori, mentre la pagina About ufficiale del progetto indica che il team ha esperienze pregresse in Akash Network, Binance Research e NGC Ventures. La tempistica è importante: Bless è emersa dopo che la prima ondata di narrative generiche sul “world computer” si era evoluta in mercati infrastrutturali più specializzati, e la sua tesi era più ristretta rispetto a una L1 per smart contract: i dispositivi consumer sarebbero diventati un substrato di calcolo distribuito, invece di essere soltanto endpoint che interagiscono con applicazioni on-chain.
La narrativa del progetto si è evoluta dall’inquadramento di Blockless come infrastruttura decentralizzata per applicazioni verso il linguaggio più accessibile del “computer condiviso” usato da Bless.
Nella formulazione attuale, il progetto è meno focalizzato sulla sostituzione di un layer di settlement blockchain esistente e più orientato alla riduzione della dipendenza dai provider cloud centralizzati, consentendo alle applicazioni di accedere al calcolo dalla propria base di utenti o di nodi. Questo spostamento ha avvicinato Bless ai pari nel mondo DePIN e dell’infrastruttura IA più che alle piattaforme tradizionali per smart contract: il sito pubblico enfatizza i carichi di lavoro GPU/CPU, il training e l’inferenza IA, il gaming, l’elaborazione dati e un marketplace di dati basato sul consenso, mentre la documentazione per sviluppatori enfatizza il deployment in TypeScript e JavaScript tramite la CLI di Bless, come mostrato nell’introduzione per sviluppatori.
Come funziona la rete Bless?
Bless va compresa principalmente come una rete decentralizzata di coordinamento del calcolo ancorata a incentivi cripto-economici, non come una blockchain di execution layer autonoma che compete direttamente con Ethereum o Solana per il settlement generale delle transazioni.
Il token BLESS è descritto nella disclosure MiCA come un token fungibile SPL su Solana, mentre il modello di sicurezza previsto per la rete si basa su una partecipazione in stile Proof-of-Stake, in cui i detentori di token mettono in stake BLESS per supportare la validazione, l’operatività dei nodi e il settlement dei task di calcolo al raggiungimento della maturità del mainnet, secondo il white paper MiCA del progetto. L’esecuzione effettiva dei carichi di lavoro avviene su nodi distribuiti anziché all’interno di una singola VM blockchain deterministica, quindi la domanda tecnica cruciale per Bless non riguarda solo la finalità del consenso, ma anche se i task di calcolo distribuiti possano essere assegnati, eseguiti, verificati e pagati con una latenza, un’affidabilità e una resistenza alle frodi accettabili.
Lo stack tecnico della rete è costruito attorno al routing dei task, all’isolamento basato su WebAssembly, alla selezione dei nodi consapevole delle prestazioni e alla verifica dinamica.
Gli sviluppatori inviano job tramite la CLI di Bless, includendo requisiti di risorse come CPU, RAM, banda, priorità e aspettative di latenza; la rete identifica poi i nodi online in base alle loro capacità e alla geolocalizzazione, dando priorità all’affidabilità storica e all’uptime, come descritto nella documentazione sull’orchestrazione. Per la verifica, Bless descrive un modello modulare in cui le applicazioni possono scegliere metodi di validazione specifici per task, tra cui votazioni in stile pBFT o RAFT per risultati binari e validazione aggregata dei dati per task di retrieval, invece di affidarsi a uno schema di verifica universale per ogni computazione, come indicato nella documentazione sulla verificabilità.
Questo design è pragmatico ma introduce un problema di sicurezza rilevante: l’hardware consumer eterogeneo è più economico e diffuso dell’infrastruttura di data center, ma è anche più rumoroso, meno affidabile e più vulnerabile a comportamenti Sybil, collusione, gaming dell’uptime e ambienti di esecuzione incoerenti.
Qual è la tokenomics di Bless?
Il programma di emissione di BLESS è relativamente aggressivo per un giovane token infrastrutturale. Tokenomics.com riporta una supply massima di 10 miliardi di BLESS, una supply totale di poco inferiore a tale livello, una TGE del 23 settembre 2025 e una supply circolante che era circa il 18–19% della supply totale nelle snapshot di dati di mercato dei primi mesi del 2026, con il completo vesting che si estende fino ad agosto 2032 attraverso un programma di unlock di 84 mesi, secondo la pagina di tokenomics di Bless Network e il relativo calendario di unlock. La distribuzione riportata suddivide la supply tra incentivi per la community, pool per airdrop e marketing, insider, investitori privati, riserve della foundation e liquidità. Questo fa sì che BLESS non sia né un asset a flottante fisso in stile commodity né un token di governance completamente emesso; il principale fattore di pressione economica è rappresentato dagli unlock programmati, soprattutto perché le allocazioni per investitori, team, advisor, foundation e community vengono rilasciate nell’arco di più anni e possono aumentare in modo significativo la supply circolante anche se la supply totale è limitata.
L’utilità prevista del token è il settlement e il coordinamento per il calcolo.
La documentazione MiCA afferma che BLESS dovrebbe costituire la base per lo staking per la partecipazione alla rete, ricompensare gli operatori di nodi e fungere da mezzo di pagamento per i carichi di lavoro di calcolo; afferma inoltre che i detentori non ricevono equity, dividendi, diritti di profit-sharing, diritti di rimborso o diritti contrattuali nei confronti della rete o dell’emittente, aspetto importante per la classificazione del rischio e per una valutazione disciplinata.
La tesi economica di Bless è che la domanda di carichi di lavoro pagati dovrebbe generare flussi di commissioni verso gli operatori di nodi e potenzialmente comportare accrual di valore per gli staker o per i meccanismi di burn del token, ma il record pubblico non è ancora sufficientemente chiaro per considerare ciò come dimostrato.
Alcuni riassunti di mercato descrivono una pressione di burn basata sui ricavi, mentre il white paper MiCA afferma che BLESS non implementa meccanismi automatici di aggiustamento della supply come rebasing, emissione legata alla domanda o burn legato alla domanda. L’interpretazione prudente è che BLESS abbia una supply nominale massima fissa con inflazione circolante guidata dal vesting, e che qualsiasi accrual di valore duraturo dipenda da pagamenti reali per il calcolo, domanda di staking e un enforcement credibile delle prestazioni dei nodi, piuttosto che da un modello meccanicamente deflazionistico garantito.
Chi sta usando Bless?
L’adozione visibile di Bless è stata più forte sul lato dell’offerta che su quello della domanda.
Il progetto afferma che la sua rete ha raggiunto milioni di nodi, con il sito ufficiale che fa riferimento a oltre 5 milioni di nodi gestiti dagli utenti e la documentazione per sviluppatori che indica che Bless aveva più di 4,1 milioni di nodi online ogni giorno al momento della pubblicazione di quella pagina.
La descrizione del progetto su CoinMarketCap cita anch’essa oltre 5 milioni di nodi in testnet, mentre un articolo di settembre 2025 sul lancio del mainnet menzionava più di 6,3 milioni di nodi e 2,5 milioni di utenti durante la fase di testnet. Queste cifre suggeriscono una partecipazione sostanziale guidata da airdrop e incentivi, ma non dovrebbero essere confuse con domanda ricorrente da parte di imprese o con ricavi da calcolo pagato; nei mercati DePIN, la crescita dei nodi sul lato dell’offerta può essere poco costosa da sovvenzionare, mentre la validazione più difficile è verificare se gli sviluppatori paghino per i carichi di lavoro una volta che gli incentivi si normalizzano.
Sul lato della domanda, Bless punta al supporto per inferenza e training IA, elaborazione dati, infrastruttura per gaming, web hosting distribuito e deployment per sviluppatori.
La documentazione mostra il supporto per applicazioni TypeScript e JavaScript, il deployment tramite npx blessnet deploy e integrazioni elencate per tecnologie come Space and Time Database e Monad Blockchain, ma le stesse documentazioni affermano anche che la rete è in beta o
testnet e che i deployment siano gratuiti durante quella fase, il che rende difficile verificare la trazione di ricavi sulla base dei materiali pubblici.
L’adozione da parte degli exchange è più chiara rispetto a quella enterprise: Bitget ha annunciato la quotazione di BLESS nella sua Innovation and AI Zone il 23 settembre 2025, e la copertura da parte di Binance Alpha e Binance Futures è stata riportata circa nello stesso periodo di lancio, mentre il white paper MiCA è stato preparato per l’ammissione alla negoziazione su Bitvavo. Queste quotazioni favoriscono la liquidità e la distribuzione, ma non sono una prova che le imprese stiano consumando compute Bless su larga scala.
Quali sono i rischi e le sfide per Bless?
Bless comporta rischi regolamentari, esecutivi e di centralizzazione tipici dell’infrastruttura tokenizzata nelle prime fasi. In Europa, il white paper MiCA classifica BLESS come un “altro cripto-asset”, non come e-money token o asset-referenced token, e lo descrive come non riscattabile e non fruttifero di interessi, ma tale classificazione non risolve automaticamente come altre giurisdizioni possano analizzare le vendite di token, le ricompense di staking, gli airdrop o le questioni legate all’aspettativa di profitto. La ricerca pubblica non ha identificato una causa SEC nota e attiva specificamente contro Bless o BLESS, ma l’assenza di un’azione esecutiva nota non equivale a certezza regolamentare. La rete dipende anche dall’integrità del punteggio dei nodi, della verifica dei task, della distribuzione delle ricompense e del design dello staking; se la partecipazione dei nodi è fortemente guidata dagli incentivi o concentrata tra operatori coordinati, l’apparente decentralizzazione di milioni di nodi browser può sovrastimare il numero di fornitori di compute economicamente indipendenti e affidabili.
La minaccia competitiva è sostanziale perché Bless entra in un mercato di compute decentralizzato affollato. Akash, Render, io.net, Aethir, Golem, Fluence e altre reti DePIN o di compute competono tutte per un’attenzione degli sviluppatori in sovrapposizione, mentre incumbent centralizzati come AWS, Google Cloud, Microsoft Azure e provider specializzati di GPU cloud dominano ancora in termini di affidabilità, procurement enterprise, conformità, osservabilità e garanzie di livello di servizio. Il modello di Bless basato su dispositivi consumer può essere conveniente per determinati carichi di lavoro sensibili alla latenza, bursty o edge, ma è meno chiaramente adatto a cluster GPU ad alte prestazioni deterministici, carichi regolamentati enterprise o task che richiedono rigorose garanzie di uptime. Il suo modello economico affronta anche pressioni specifiche del token: un calendario di unlock pluriennale può diluire i detentori circolanti prima che l’utilizzo maturi, e se le ricompense superano per troppo tempo i ricavi organici del compute, la rete può scivolare da marketplace infrastrutturale a circuito di partecipazione sovvenzionata.
Quali sono le prospettive future per Bless?
Le prospettive di Bless dipendono meno dalle quotazioni del token e più dal fatto che riesca a convertire un’ampia impronta di testnet o di offerta di nodi in una domanda verificabile di carichi di lavoro a pagamento.
Le principali milestone da monitorare sono la prontezza per la produzione del compute su mainnet, nodi desktop o nativi con GPU, meccanismi di verifica più robusti, un supporto linguistico più ampio oltre TypeScript e JavaScript, un’orchestrazione migliorata e dati trasparenti su fatturazione o ricavi.
L’audit di agosto 2025 di Halborn sui programmi Solana di Bless ha riscontrato un solo problema informativo e nessuna criticità con severità critica, alta, media o bassa nell’ambito esaminato, il che è positivo ma limitato: ha coperto i programmi Solana relativi a token e airdrop, non l’intero modello di sicurezza del compute distribuito, l’economia del marketplace dei nodi o il sistema avversariale di verifica dei carichi di lavoro.
La roadmap del white paper individua come priorità il lancio del mainnet, il miglioramento della verifica, un supporto più ampio ai linguaggi di programmazione, una migliore orchestrazione e funzionalità di sicurezza più solide, mentre la documentazione attuale contiene ancora un linguaggio da beta/testnet, quindi l’ostacolo pratico è allineare le dichiarazioni di lancio pubblico, gli strumenti per sviluppatori, i sistemi di pagamento e una domanda di produzione misurabile.
La tesi infrastrutturale è plausibile ma non provata. Se Bless riuscirà a instradare in modo affidabile carichi di lavoro reali verso dispositivi eterogenei, a far rispettare la qualità del servizio, a impedire il gaming dei nodi e a pagare i contributori sulla base della domanda dei clienti anziché delle emissioni di token, potrà occupare una nicchia difendibile di edge compute all’interno del DePIN. In caso contrario, il progetto rischia di diventare un’altra rete di token ricca di offerta, con conteggi di nodi impressionanti ma bassa densità di ricavi. Gli indicatori più importanti non sono il prezzo di breve periodo, il volume sugli exchange o la crescita sui social, ma l’utilizzo ricorrente di compute a pagamento, la retention degli operatori di nodi non legati ad airdrop, il completamento verificabile dei carichi di lavoro, la partecipazione allo staking che migliori la sicurezza anziché assorbire semplicemente il float e una divulgazione trasparente su ricavi, burn, unlock e fonti delle ricompense.
