I provider IA coniano blocchi mentre rispondono ai prompt.

La ricevuta è un oggetto di prova — una trascrizione compatta della traiettoria di campionamento del modello su un prompt derivato da hash — che qualsiasi altro nodo può rieseguire contro i pesi pubblicati. La verifica non può semplicemente rieseguire il forward pass e confrontare bit per bit: lo stesso modello su GPU, batch size o kernel di attention diversi produce logit leggermente differenti. È invece una regola di decisione statistica calibrata, eseguita su una scala a tre livelli (Quick → Smell → Full) dove ogni livello restringe in modo stringente ciò che conta come onesto. Il verificatore è distribuito come software open-source — chiunque può eseguirne uno e contestare blocchi disonesti.

Mining ed erogazione si fondono in un unico carico di lavoro. La Mining API è una versione fork di vLLM (CUDA) e llama.cpp (CPU / Apple Silicon) con la cattura della prova integrata direttamente nel percorso di campionamento, in modo che generare materiale di prova non rallenti le richieste degli utenti. I prompt sintetici di backfill girano solo quando la GPU sarebbe altrimenti inattiva e cedono la priorità al traffico pagante. Quando una trascrizione supera la difficoltà target diventa un blocco candidato; quando non ci riesce, hai comunque risposto a un prompt reale. Nessun loop di mining separato, nessuna bolletta elettrica per l'idle.

TensorCash eredita il transaction graph, il modello UTXO e il meccanismo di firma di Bitcoin Core, ed estende la superficie di consenso in un piccolo numero di modi ben delimitati. Le intestazioni di blocco si impegnano a un blob di prova di inferenza e a un target di difficoltà aggiustato. Ogni blocco incorpora una prova Wesolowski VDF che lega il blocco al lavoro in tempo reale. La validazione della prova è suddivisa in scalini Quick / Smell / Full — Quick e Smell controllano il relay; Full gira fuori dal percorso di propagazione. Il livello di presync valuta le chain in base al proof-of-time prima del proof-of-work, e i reorg profondi fanno emergere un avviso forense prima che la chain cambi. L'assenza di una VM generalista significa nessuna superficie d'attacco di una VM generalista da ereditare.

Gli asset fungibili nativi si trovano accanto alla moneta della chain nello stesso UTXO graph. Ogni output che porta un asset trasporta un singolo record binario tipizzato impegnato dal sighash della transazione, quindi lo stato dell'asset non può essere ricollegato dopo la produzione di una firma. Ogni asset ha un Issuer Control Unit — una credenziale a forma di UTXO che l'emittente deve ruotare a ogni spesa autorizzata, garantita da uno stake in moneta nativa depositato. Gli asset regolamentati portano prove zero-knowledge di idoneità del detentore (KYC) usando chiavi di verifica Groth16 on-chain e radici di compliance rotanti. Componibile con le famiglie di script esistenti di Bitcoin, i covenant Taproot e gli strumenti PSBT.

Gli emittenti possono pubblicare prospetti, term sheet, registri di governance e disclosure ai detentori come impegni on-chain. I documenti sono ancorati tramite hash; la radice di compliance dell'asset li lega al consenso. Le evidenze di firma elettronica di livello QES (lo standard europeo Qualified Electronic Signature) confluiscono nello stesso ancoraggio. L'impegno on-chain è permanente e datato; il documento stesso può essere pubblico, riservato ai soli detentori o condiviso off-chain — con la chain che dimostra che il documento visto dai detentori è il documento pubblicato dall'emittente.

Le primitive spot, repo e forward si regolano attraverso un singolo covenant finanziario: `OP_OUTPUTMATCH`, un controllo Tapscript che chiede se la transazione di spesa contiene un output con uno specifico hash di script, importo e (per gli output di asset) identificatore di asset. Esegue un matching vincolato sulla transazione corrente — nessuna esecuzione dello script del destinatario, nessuna lookup nello storico delle transazioni, nessuno stato mutabile. Taproot mantiene riservati i termini del contratto fino a quando non si imbocca il percorso script: l'insieme UTXO pubblico vede il vault, non il term sheet.

Dietro al wallet vive uno stack di coordinamento a tre livelli. Nostr per la scoperta delle offerte; Noise+SPAKE2 per sessioni di negoziazione bilaterali end-to-end criptate; HTLCs e la cerimonia con firma adattatore Fair-Sign per il regolamento atomico. La stessa pagina del wallet Qt mostra sei sotto-tab — discovery, offerte, sessioni, governance, discussione, cross-chain — così uno scambio fluisce da "trova una controparte" attraverso "negozia in privato" fino a "regola bilateralmente" senza una venue. Lo smart contract Solidity TensorSwap gestisce la gamba EVM degli swap cross-chain.

Due binari di spesa esistono dal blocco 0. Il familiare stack ECDSA / Schnorr su Witness v0/v1 e uno stack ML-DSA (NIST FIPS 204) su un nuovo Witness v2. Gli output v2 sono output Taproot da 32 byte spendibili solo tramite prova script-path; gli unici nuovi opcode sono `OP_CHECKMLSIG` e `OP_CHECKMLSIGVERIFY`. Poiché TensorCash è un fork di genesi, non c'è una base UTXO installata da convertire e nessuna finestra di attivazione soft-fork — gli utenti scelgono un binario quando finanziano un indirizzo, ed entrambi restano validi per sempre.

Il matching degli ordini e la price discovery hanno requisiti di throughput, leva ed equità che non si adattano on-chain. TensorCash specifica un DEX di livello superiore che usa la latenza di rete e la frammentazione crittografica — stato dell'order book condiviso Shamir 6-su-10 tra sottoinsiemi indipendenti di validatori — per proteggersi da front-running e manipolazione. Nessun singolo sottoinsieme conosce il flusso; nessun singolo sottoinsieme può fermare il trading. Il regolamento finale arriva sempre sulla chain di base attraverso le stesse primitive di atomic-swap usate da uno scambio bilaterale.