Os fornecedores de IA cunham blocos enquanto respondem a prompts.

O recibo é um objeto de prova — um transcript compacto da trajetória de amostragem do modelo sobre uma prompt derivada por hash — que qualquer outro nó pode reproduzir contra os pesos publicados. A verificação não pode simplesmente reexecutar o forward pass e comparar bit a bit: o mesmo modelo em GPUs diferentes, tamanhos de batch ou kernels de atenção produz logits ligeiramente diferentes. Em vez disso, é uma regra de decisão estatística calibrada, executada numa escada de três níveis (Quick → Smell → Full) em que cada nível aperta estritamente o que conta como honesto. O verificador é entregue como software open-source — qualquer pessoa pode executar um e contestar blocos desonestos.

Minar e servir colapsam numa única carga de trabalho. A Mining API é uma fork de vLLM (CUDA) e llama.cpp (CPU / Apple Silicon) com a captura de prova ligada ao próprio caminho de amostragem, pelo que gerar material de prova não atrasa os pedidos dos utilizadores. As prompts sintéticas de backfill só correm quando a GPU estaria, de outra forma, ociosa e cedem perante tráfego pago. Quando um transcript atinge o alvo de dificuldade torna-se um candidato a bloco; quando não atinge, ainda assim respondeste a uma prompt real. Sem ciclo de mineração separado, sem fatura de eletricidade ociosa.

A TensorCash herda o grafo de transações, o modelo UTXO e a maquinaria de assinaturas do Bitcoin Core, e estende a superfície de consenso através de um pequeno conjunto de formas bem delimitadas. Os cabeçalhos de bloco comprometem-se com um blob de prova de inferência e um alvo de dificuldade ajustado. Cada bloco incorpora uma prova Wesolowski VDF que vincula o bloco a trabalho em tempo real. A validação de prova é dividida em níveis Quick / Smell / Full — Quick e Smell controlam o relay; Full corre fora do caminho de propagação. A camada de presync pontua chains por proof-of-time antes de proof-of-work, e reorganizações profundas fazem emergir um aviso forense antes de a chain mudar. Sem VM de uso geral significa sem superfície de ataque de VM de uso geral para herdar.

Os ativos fungíveis nativos coexistem com a moeda da chain no mesmo grafo UTXO. Cada saída que transporta um ativo carrega um único registo binário tipado comprometido pelo sighash da transação, pelo que o estado do ativo não pode ser religado depois de produzida uma assinatura. Cada ativo tem uma Issuer Control Unit — uma credencial em forma de UTXO que o emissor tem de rodar a cada gasto autorizado, garantida por uma stake em moeda nativa. Os ativos regulados transportam provas zero-knowledge de elegibilidade do detentor (KYC) usando chaves de verificação Groth16 on-chain e raízes de conformidade rotativas. Componível com as famílias de script existentes do Bitcoin, com convenants Taproot e ferramentas PSBT.

Os emissores podem publicar prospetos, term sheets, registos de governance e divulgações a detentores como compromissos on-chain. Os documentos são ancorados por hash; a raiz de conformidade do ativo liga-os ao consenso. A evidência de assinatura eletrónica de nível QES (a norma europeia Qualified Electronic Signature) integra-se na mesma âncora. O compromisso on-chain é permanente e datado; o próprio documento pode ser público, exclusivo de detentores ou partilhado off-chain — com a chain a comprovar que o documento visto pelos detentores é o documento que o emissor publicou.

As primitivas spot, repo e forward liquidam através de um único covenant financeiro: `OP_OUTPUTMATCH`, uma verificação Tapscript que pergunta se a transação que efetua o gasto contém uma saída com um hash de script especificado, montante e (para saídas de ativos) identificador de ativo. Realiza correspondência delimitada na transação atual — sem execução de script do destinatário, sem consultas ao histórico de transações, sem estado mutável. O Taproot mantém os termos do contrato confidenciais até que o caminho de script seja tomado: o conjunto público de UTXO vê o cofre, não a term sheet.

Uma stack de coordenação em três camadas vive por trás da carteira. Nostr para descoberta de ofertas; Noise+SPAKE2 para sessões de negociação bilateral encriptadas ponto a ponto; HTLCs e a cerimónia Fair-Sign de assinaturas adaptadoras para liquidação atómica. A mesma página da carteira Qt expõe seis subseparadores — descoberta, ofertas, sessões, governance, discussão, cross-chain — para que uma negociação flua de "encontrar uma contraparte" passando por "negociar em privado" até "liquidar bilateralmente" sem um local de negociação. O contrato Solidity TensorSwap trata da perna EVM dos cross-chain swaps.

Dois carris de gasto vivem desde o bloco 0. A familiar stack ECDSA / Schnorr em Witness v0/v1, e uma stack ML-DSA (NIST FIPS 204) num novo Witness v2. As saídas v2 são saídas Taproot de 32 bytes gastáveis apenas por prova de caminho de script; os únicos opcodes novos são `OP_CHECKMLSIG` e `OP_CHECKMLSIGVERIFY`. Como a TensorCash é uma fork de génese, não há base instalada de UTXO para adaptar nem janela de ativação de soft-fork — os utilizadores escolhem um carril quando financiam um endereço, e ambos permanecem válidos para sempre.

A correspondência de ordens e a descoberta de preço têm requisitos de débito, alavancagem e justiça que não cabem on-chain. A TensorCash especifica uma DEX de camada superior que utiliza latência de rede e fragmentação criptográfica — estado do livro de ordens partilhado por Shamir 6-de-10 entre subconjuntos independentes de validadores — para proteger contra front-running e manipulação. Nenhum subconjunto único conhece o fluxo; nenhum subconjunto único pode parar a negociação. A liquidação final aterra sempre de volta na chain base através das mesmas primitivas de atomic-swap que uma negociação bilateral usa.