Az MI-szolgáltatók blokkokat vernek, miközben válaszolnak a kérésekre.

A nyugta egy bizonyíték-objektum — egy kompakt átirat a modell mintavételezési pályájáról egy hash-eredetű kérésen —, amelyet bármely másik node visszajátszhat a közzétett súlyokkal szemben. Az ellenőrzés nem futtathatja egyszerűen újra a forward passt és hasonlíthatja össze bitenként: ugyanaz a modell különböző GPU-kon, batch-méreteken vagy attention kerneleken kissé eltérő logitokat produkál. Ehelyett egy kalibrált statisztikai döntési szabályról van szó, amelyet egy háromszintű létrán (Quick → Smell → Full) futtatnak, ahol minden szint szigorúan szűkíti, mi számít becsületesnek. Az ellenőr nyílt forráskódú szoftverként szállítódik — bárki futtathat egyet, és megtámadhatja a tisztességtelen blokkokat.

A bányászat és a kiszolgálás egyetlen munkaterheléssé olvad össze. A Mining API egy elágaztatott vLLM (CUDA) és llama.cpp (CPU / Apple Silicon), amelyben a bizonyíték-rögzítés magába a mintavételezési útvonalba van bekötve, így a bizonyíték-anyag generálása nem lassítja a felhasználói kéréseket. A szintetikus utántöltő kérések csak akkor futnak, amikor a GPU egyébként tétlen lenne, és átadják a helyet a fizető forgalomnak. Amikor egy átirat eléri a nehézségi célt, blokkjelöltté válik; amikor nem, akkor is megválaszoltál egy valódi kérést. Nincs külön bányászati ciklus, nincs üresjárati villanyszámla.

A TensorCash örökli a Bitcoin Core tranzakciós gráfját, UTXO-modelljét és aláírási gépezetét, és a konszenzus-felületet kis számú, jól körülhatárolt módon bővíti. A blokkfejlécek elkötelezik magukat egy inferencia-bizonyíték blob és egy igazított nehézségi cél mellett. Minden blokk tartalmaz egy Wesolowski VDF bizonyítékot, amely a blokkot a fali óra szerinti munkához köti. A bizonyíték-validáció Quick / Smell / Full fokokra van bontva — a Quick és Smell a továbbítást szabályozza; a Full a propagációs útvonalon kívül fut. A presync-réteg a láncokat először proof-of-time, majd proof-of-work szerint pontozza, és a mély reorg-ok forenzikus figyelmeztetést jelenítenek meg, mielőtt a lánc átváltana. Általános célú VM hiányában nincs általános célú VM-támadási felület, amit örökölni kellene.

A natív helyettesíthető eszközök ott ülnek a lánc érméje mellett ugyanabban az UTXO-gráfban. Minden eszközhordozó kimenet egyetlen tipizált bináris rekordot hordoz, amelyhez a tranzakció sighash-e kötelezi el magát, így az eszközállapot nem köthető újra egy aláírás létrehozása után. Minden eszköznek van egy Issuer Control Unit-ja — egy UTXO-formájú hitelesítő adat, amelyet a kibocsátónak minden engedélyezett elköltésnél rotálnia kell, és amelyet egy posztolt natív érme tét fedez. A szabályozott eszközök nulla-tudás birtokos-jogosultsági bizonyítékokat hordoznak (KYC) on-chain Groth16 ellenőrzési kulcsok és gördülő megfelelőségi gyökerek használatával. Komponálható a Bitcoin meglévő szkriptcsaládjaival, Taproot covenants-szel és PSBT eszközökkel.

A kibocsátók on-chain elkötelezettségként közzétehetik a tájékoztatókat, term sheet-eket, irányítási nyilvántartásokat és birtokosi közzétételeket. A dokumentumokat hash horgonyozza; az eszköz megfelelőségi gyökere konszenzushoz köti őket. A QES-szintű elektronikus aláírás-bizonyíték (az EU Minősített Elektronikus Aláírás szabványa) ugyanabba a horgonyba illeszkedik. Az on-chain elkötelezettség állandó és időbélyegzett; maga a dokumentum lehet nyilvános, csak birtokosoknak szóló vagy off-chain megosztott — a lánc bizonyítja, hogy a birtokosok által látott dokumentum megegyezik a kibocsátó által közzétett dokumentummal.

A spot, repo és határidős primitívek egyetlen pénzügyi covenant-en keresztül rendeződnek: `OP_OUTPUTMATCH`, egy Tapscript ellenőrzés, amely megkérdezi, hogy az elköltő tranzakció tartalmaz-e egy megadott szkript-hash-sel, összeggel és (eszközkimenetek esetén) eszközazonosítóval rendelkező kimenetet. Korlátos illesztést végez a jelenlegi tranzakción — nincs címzett-szkript végrehajtás, nincs tranzakciótörténeti lekérdezés, nincs változó állapot. A Taproot a szkript-útvonal megnyitásáig bizalmasan tartja a szerződéses feltételeket: a nyilvános UTXO-halmaz a páncélt látja, nem a term sheet-et.

Egy háromrétegű koordinációs stack él a pénztárca mögött. Nostr az ajánlatfelfedezéshez; Noise+SPAKE2 a végpontok közötti titkosított kétoldalú tárgyalási munkamenetekhez; HTLC-k és a Fair-Sign adapter-aláírási szertartás az atomi rendezéshez. Ugyanaz a Qt pénztárca-oldal hat al-fület jelenít meg — felfedezés, ajánlatok, munkamenetek, irányítás, vita, kereszt-lánc —, így egy kereskedés a "találj egy partnert"-től a "tárgyalj privátan"-ig a "rendezz kétoldalúan"-ig folyik helyszín nélkül. A TensorSwap Solidity szerződés kezeli a kereszt-lánc swapok EVM-lábát.

Két elköltési sín él a 0. blokktól. Az ismert ECDSA / Schnorr stack a Witness v0/v1-en, és egy ML-DSA stack (NIST FIPS 204) egy új Witness v2-n. A v2 kimenetek 32 bájtos Taproot kimenetek, csak szkript-útvonalú bizonyítékkal költhetők; az egyetlen új opcode az `OP_CHECKMLSIG` és az `OP_CHECKMLSIGVERIFY`. Mivel a TensorCash genezis-fork, nincs telepített UTXO-bázis utólagos felszereléséhez és nincs soft-fork aktiválási ablak — a felhasználók sínt választanak, amikor finanszíroznak egy címet, és mindkettő örökre érvényben marad.

A megbízásillesztésnek és az árfelfedezésnek olyan átviteli, tőkeáttételi és méltányossági követelményei vannak, amelyek nem férnek el a láncon. A TensorCash specifikál egy magasabb rétegű DEX-et, amely hálózati késleltetést és kriptográfiai töredezést használ — order-book állapot Shamir-megosztva 6-ból-10 független validátor-részhalmazokon — a front-running és a manipuláció ellen. Egyetlen részhalmaz sem ismeri meg a forgalmat; egyetlen részhalmaz sem állíthatja le a kereskedést. A végső rendezés mindig az alapláncon száll le, ugyanazon atomic-swap primitíveken keresztül, amelyeket egy kétoldalú kereskedés használ.