Language

Choose a language

/docs / schemas

FlatBuffer schemas

TensorCash uses three FlatBuffers schemas as the binary contract for two surfaces: the OSS verifier's /v1/verify/* endpoints (binary request body), and the bcore ↔ verifier ZMQ PUSH/PULL channel (cf. ZMQ topics, which covers the separate Bitcoin-Core inheritance pub/sub).

Each file is published verbatim under /schemas/ for flatc consumption, and as JSON Schema under /schemas/json/ for tooling that prefers JSON Schema. The same JSON Schemas are spliced into openapi/verifier.json's components.schemas so Scalar can render typed bodies for the JSON-encoded mirror endpoints (/v1/verify/*/json).

3 files · 12 types · openrpc 1.3.2 + openapi 3.1.0 cross-referenced

proof.fbs

root_type Proof

The TensorCash inference proof. Carries the PoW witness (target / VDF / block_hash), sampling parameters (temperature, top_p, top_k), and the model+token transcripts that a verifier replays. Same wire shape is used by the miner pipeline and by ZMQ messages on the bcore ↔ verifier PUSH/PULL channel.

Declares: Proof , FloatArray , UIntArray

raw .fbs JSON Schema

// proof.fbs
// FlatBuffers schema for PoW proof with C++ and Python compatibility
namespace proof;

// Wrapper for 1D float arrays (for 2D tensors)
table FloatArray {
  values:[float];      // float32 vector
}

// Wrapper for 1D uint arrays
table UIntArray {
  values:[uint32];     // uint32 vector
}

// Root table representing a single proof
table Proof {
  version:uint8;                 // schema version identifier
  tick:uint64;                 // monotonic tick count
  timestamp:uint64;            // UNIX timestamp

  // Binary fields as raw bytes (more compact than hex strings)
  target:[ubyte];              // target bytes
  vdf:[ubyte];                 // VDF output bytes
  hash:[ubyte];                // proof hash bytes
  block_hash:[ubyte];                // prior block hash bytes
  header_prefix:[ubyte];       // optional, if provided

  is_solution:bool;
  model_identifier : string;    // e.g. "gpt-4"
  compute_precision: string;    // e.g. "fp16"
  ipfs_cid         : string;    // e.g. "cdcdcd"
  extra_flags      : string;    // e.g. ""
  temperature      : float;     // sampling temperature
  top_p            : float;     // nucleus‐sampling p
  top_k            : uint32;    // top‐k sampling
  repetition_penalty: float;    // repetition penalty
  
  // 1D arrays
  chosen_tokens:[uint32];      // selected token IDs
  chosen_probs:[float];        // probabilities
  sampling_u:[float];          // random sampling values
  softmax_normalizers:[float]; // softmax normalizers
  prompt_tokens:[uint32];      // prompt token IDs
  pad_mask:[bool];           // pad mask (0/1)

  // 2D tensors implemented via wrapper tables
  topk_logits:[FloatArray];    // vector of FloatArray
  topk_indices:[UIntArray];    // vector of UIntArray
  logsumexp_stats:[FloatArray]; // vector of FloatArray (2D tensor)
}

root_type Proof;
file_identifier "PROF";  // optional 4-byte identifier

validation.fbs

root_type ValidationRequest

The verifier's request/response envelope. The 5-value `ValidationType` enum maps directly onto the verifier-ladder rungs documented at /docs/verifier/api/ (Quick / Quick_Smell / Full / Model / Challenge); `ResponseValue` is the 13-outcome enum the verifier returns. `ValidationRequest` is the body of every /v1/verify/* binary endpoint and is mirrored 1:1 by /v1/verify/*/json.

Declares: ValidationType , ResponseValue , ValidationUnion , BlockValidation , ModelValidation , ValidationRequest , ValidationResponse

raw .fbs JSON Schema

include "proof.fbs";

namespace proof;

enum ValidationType : uint8 {
  Quick = 0,
  Quick_Smell = 1,
  Full = 2,
  Model = 3,
  Challenge = 4,
  // Audit/logits verification: sequence + logits replay only, no block
  // sanity and no mining parameter envelope. Append-only addition —
  // wire-compatible with older readers (they warn on the unknown value).
  Logits = 5
}

enum ResponseValue : uint8 {
  Quick_OK = 0,
  Quick_Fail = 1,
  Quick_OK_Smell_OK = 2,
  Quick_OK_Smell_Fail = 3,
  Quick_Fail_Smell_OK = 4,
  Quick_Fail_Smell_Fail = 5,
  Full_Green = 6,
  Full_Amber = 7,
  Full_Red = 8,
  Model_OK = 9,
  Model_Fail = 10,
  Challenge_OK = 11,
  Challenge_Fail = 12,
  Model_Pending_Review = 13,
  Logits_OK = 14,
  Logits_Fail = 15
}

table BlockValidation {
  version: uint32;
  hash: [ubyte];             // 32 bytes
  prev_block_hash: [ubyte];  // 32 bytes
  merkle_root: [ubyte];      // 32 bytes
  timestamp: uint32;
  bits: uint32;
  nonce: uint32;
  pow_blob_hash: [ubyte];
  adjusted_bits: uint32;
  pow_blob: Proof;
}

table ModelValidation {
  model_name: string;
  model_commit: string;
  difficulty: int64;
  cid: string;
  extra: string;
  txid: [ubyte];             // 32 bytes
  block_hash: [ubyte];        // 32 bytes
  block_height: int32;
}

union ValidationUnion {
  BlockValidation,
  ModelValidation
}

table ValidationRequest {
  hash_id: [ubyte];        // 32 bytes
  validation_type: ValidationType;
  request: ValidationUnion;
}

table ValidationResponse {
  hash_identifier: [ubyte];   
  enum_response: ResponseValue;
}

root_type ValidationRequest;

blockheader.fbs

root_type BlockHeader

Mining header + miner response. `BlockHeader` is the cut-down header shape passed from bcore to the miner; `MiningResponse` is what the miner returns once it has a candidate solution (nonce + pow_blob, where pow_blob references the `Proof` table from proof.fbs).

Declares: BlockHeader , MiningResponse

raw .fbs JSON Schema

include "proof.fbs";

namespace proof;

table BlockHeader {
  req_id: uint32;
  version: uint32;
  prev_block_hash: [ubyte];  // 32 bytes
  merkle_root: [ubyte];      // 32 bytes
  timestamp: uint32;
  bits: uint32;
}

table MiningResponse {
  req_id: uint32;
  nonce: uint32;
  adjusted_bits: uint32;
  pow_blob_hash: [ubyte];
  difficulty: uint32;
  pow_blob: Proof;
  completion_id: string;  // OpenAI-style completion ID (e.g., "cmpl-xxxxx")
}

root_type BlockHeader;

Using these from a client

Generate a typed binding with the FlatBuffers compiler:

# C++
flatc --cpp -o gen/ proof.fbs validation.fbs blockheader.fbs

# Python
flatc --python -o gen/ proof.fbs validation.fbs blockheader.fbs

# Rust
flatc --rust -o gen/ proof.fbs validation.fbs blockheader.fbs

# TypeScript
flatc --ts -o gen/ proof.fbs validation.fbs blockheader.fbs

# JSON Schema (already generated; check `/schemas/json/` for the prebuilt files)
flatc --jsonschema -o gen/ proof.fbs validation.fbs blockheader.fbs

For JSON-encoded calls to /v1/verify/*/json, the field names on the wire match the FB table fields directly. For binary calls to /v1/verify/*, build a ValidationRequest and POST the resulting bytes as application/octet-stream.

Our mission

TensorCash turns useful AI work into open money.

Out of the potato age, as our whitepaper says…

We believe people deserve a cheaper, more efficient financial system, and fairer AI that works for everyone. TensorCash makes AI work verified and verifiable. Verification gives AI a face: proof of which model did the work, what it saw, and the rules it followed. That lets anyone confidently buy or sell AI work at the most efficient price. The result is more accessible, more sustainable AI, powering a new generation of financial systems. Today's currencies are the potatoes: antiquated, expensive to move, and trapped behind fee-takers. TensorCash is a more efficient way to move and store value — one that harnesses AI's computational power for everyone while pushing the control outward instead of concentrating it.

— Imosuke Takakuni

About us

Imosuke Takakuni is a pseudonym. The Japanese name is both a tribute to Satoshi Nakamoto and a nod to Potato Land — the parable from our whitepaper. The mission is bigger than any one contributor; it should outlast personalities and charisma. Decentralisation works for everyone, or it doesn't work at all. We want everyone to participate in TensorCash as equals.

Open the mission page →

Get involved

How to get TSC

TensorCash is not selling TSC. The project is not running a token sale, pre-sale, ICO, IDO, or official investment round. New TSC enters circulation through active mining. You can mine it, receive it peer-to-peer from someone who already has it, or run the wallet and be ready for mainnet.

TensorCash is not running an official sale. Do not send money to anyone claiming to sell official allocations.

Get involved

Run the Core wallet

The practical first step is to run TensorCash Core, create a wallet, and learn the RPC surface. Today the public guide starts with regtest so you can create addresses and move coins locally before touching mainnet funds.

Get involved

Donate

No mainnet donation address is published yet. For testing only, the TensorCash testnet address below was generated from the running Core wallet; do not send mainnet funds to it.

Get involved

Spread the word

The shortest useful explanation is: TensorCash turns useful AI work into open money. Share the mission page, the flagship whitepaper, or the Get involved page with one person who cares about cheaper financial rails, fairer AI, or open infrastructure.

TensorCash turns useful AI work into open money.

Get involved

Emission schedule

Bitcoin set the baseline: block rewards only, no discretionary minting, and an exact integer subsidy total of 20,999,999.97690000 BTC. TensorCash keeps the fixed-supply discipline and changes the release curve for a compute-mined network; the implemented recurrence ends at 21,184,153.03530240 TSC.

Supply over blocks

Total subsidy issued

Exact integer subsidy rules from Core: Bitcoin halvings against the TensorCash epoch-decay schedule, shown through the first 6,000,000 blocks.

Horizon
...
BTC @ 6M
...
TSC @ 6M
...
BTC and TSC total subsidy over block count At 6,000,000 blocks, Bitcoin has issued 20,999,999.92710000 BTC and TensorCash has issued 20,979,987.36365355 TSC under the implemented epoch-decay schedule.
Block 0
BTC supply 0 BTC
TSC supply 0 TSC
BTC: 50 BTC, 210,000-block halvings TSC: 715 TSC, 715-block epoch, reward x 3/5, capped epoch length