Los proveedores de IA acuñan bloques mientras responden prompts.

El recibo es un objeto de prueba — una transcripción compacta de la trayectoria de muestreo del modelo sobre un prompt derivado por hash — que cualquier otro nodo puede reproducir contra los pesos publicados. La verificación no puede simplemente reejecutar el forward pass y comparar bit a bit: el mismo modelo en distintas GPUs, tamaños de batch o kernels de atención produce logits ligeramente distintos. En su lugar, es una regla de decisión estadística calibrada, ejecutada en una escalera de tres niveles (Quick → Smell → Full) en la que cada nivel ajusta estrictamente lo que cuenta como honesto. El verificador se distribuye como software de código abierto: cualquiera puede ejecutar uno y desafiar bloques deshonestos.

Minería y servicio colapsan en una sola carga de trabajo. La Mining API es un fork de vLLM (CUDA) y llama.cpp (CPU / Apple Silicon) con la captura de pruebas integrada en la propia ruta de muestreo, así que generar material de prueba no ralentiza las solicitudes de los usuarios. Los prompts sintéticos de relleno solo se ejecutan cuando la GPU estaría inactiva y ceden ante el tráfico que paga. Cuando una transcripción supera el objetivo de dificultad se convierte en candidato a bloque; cuando no, ya has respondido un prompt real. Sin un bucle de minería separado, sin factura eléctrica en vacío.

TensorCash hereda el grafo de transacciones, el modelo UTXO y la maquinaria de firmas de Bitcoin Core, y extiende la superficie de consenso de un pequeño número de formas bien acotadas. Las cabeceras de bloque se comprometen con un blob de prueba de inferencia y un objetivo de dificultad ajustada. Cada bloque incrusta una prueba Wesolowski VDF que vincula el bloque al trabajo en tiempo real. La validación de pruebas se divide en peldaños Quick / Smell / Full — Quick y Smell controlan la propagación; Full se ejecuta fuera de la ruta de propagación. La capa de presync puntúa las cadenas por proof-of-time antes que por proof-of-work, y los reorgs profundos generan un aviso forense antes de que la cadena cambie. Sin VM de propósito general no se hereda una superficie de ataque de VM de propósito general.

Los activos fungibles nativos conviven con la moneda de la cadena en el mismo grafo UTXO. Cada salida que porta un activo lleva un único registro binario tipado comprometido por el sighash de la transacción, así que el estado del activo no puede revincularse después de producir una firma. Cada activo tiene una Issuer Control Unit — una credencial con forma de UTXO que el emisor debe rotar en cada gasto autorizado, garantizada por una participación nativa publicada. Los activos regulados llevan pruebas de elegibilidad de tenedor de conocimiento cero (KYC) usando claves de verificación Groth16 on-chain y raíces de cumplimiento rotativas. Componibles con las familias de scripts existentes de Bitcoin, los covenants de Taproot y las herramientas de PSBT.

Los emisores pueden publicar folletos, hojas de términos, registros de gobernanza y divulgaciones a tenedores como compromisos on-chain. Los documentos se anclan por hash; la raíz de cumplimiento del activo los vincula al consenso. La evidencia de firma electrónica con grado QES (el estándar europeo de Firma Electrónica Cualificada) se integra en el mismo ancla. El compromiso on-chain es permanente y con sello de tiempo; el documento en sí puede ser público, solo para tenedores o compartido fuera de la cadena — y la cadena demuestra que el documento que vieron los tenedores es el documento que publicó el emisor.

Las primitivas spot, repo y forward se liquidan a través de un único covenant financiero: `OP_OUTPUTMATCH`, una comprobación de Tapscript que pregunta si la transacción que gasta contiene una salida con un script hash, importe y (para salidas de activo) identificador de activo especificados. Realiza una coincidencia acotada sobre la transacción actual — sin ejecución del script destinatario, sin búsquedas en el histórico de transacciones, sin estado mutable. Taproot mantiene los términos del contrato confidenciales hasta que se toma la ruta de script: el conjunto público de UTXO ve la bóveda, no la hoja de términos.

Detrás de la wallet vive una pila de coordinación de tres capas. Nostr para el descubrimiento de ofertas; Noise+SPAKE2 para sesiones bilaterales de negociación cifradas extremo a extremo; HTLCs y la ceremonia de firma adaptada Fair-Sign para la liquidación atómica. La misma página de la wallet Qt expone seis sub-pestañas — descubrimiento, ofertas, sesiones, gobernanza, discusión, cross-chain — para que una operación fluya desde "encontrar una contraparte" pasando por "negociar en privado" hasta "liquidar bilateralmente" sin necesidad de venue. El contrato Solidity de TensorSwap gestiona la pata EVM de los swaps cross-chain.

Dos raíles de gasto existen desde el bloque 0. La pila familiar ECDSA / Schnorr en Witness v0/v1, y una pila ML-DSA (NIST FIPS 204) en un nuevo Witness v2. Las salidas v2 son salidas Taproot de 32 bytes gastables únicamente mediante prueba por ruta de script; los únicos opcodes nuevos son `OP_CHECKMLSIG` y `OP_CHECKMLSIGVERIFY`. Como TensorCash es un fork de génesis, no hay base UTXO instalada que adaptar ni ventana de activación de soft-fork — los usuarios eligen un raíl al financiar una dirección, y ambos siguen siendo válidos para siempre.

El emparejamiento de órdenes y el descubrimiento de precios tienen requisitos de throughput, apalancamiento y equidad que no encajan on-chain. TensorCash especifica un DEX de capa superior que utiliza la latencia de red y la fragmentación criptográfica — estado del libro de órdenes Shamir-compartido 6-de-10 entre subconjuntos independientes de validadores — para protegerse contra el front-running y la manipulación. Ningún subconjunto único conoce el flujo; ningún subconjunto único puede detener el trading. La liquidación final siempre regresa a la cadena base mediante las mismas primitivas atomic-swap que utiliza una operación bilateral.