Tensorium: A Proof-of-Work Blockchain for Open, GPU-First Mining

1 Introduction

1.1 Motivation

Proof-of-Work blockchains have proven to be the most resilient consensus mechanism in practice. Bitcoin's 15-year track record demonstrates that PoW provides objective security without relying on stake concentration or trusted validator sets. However, most modern PoW chains are dominated by ASIC manufacturers, leaving community miners — particularly GPU operators — with few viable options.

Tensorium is built to address this: a clean, open PoW chain where GPU miners are first-class participants from mainnet launch, the emission schedule is transparent and non-inflationary, and the codebase is fully open-source with no premine beyond a declared founder allocation.

1.2 Design Principles

• Fair launch over hype. Testnet runs publicly before mainnet. No private allocation beyond 3% founder reserve.
• GPU-first mainnet. Testnet uses CPU mining for validation and bootstrap. Mainnet targets GPU-first difficulty (36+ bits) after a stable GPU miner is proven.
• Open source, always. All node, miner, and wallet code is published under an open license.
• Self-custody. Users control their own keys. No custodial wallets.
• Security before speed. Consensus rules are frozen before mainnet. No shortcuts.

1.3 Scope of This Document

This whitepaper covers the protocol design, consensus mechanism, tokenomics, and roadmap of the Tensorium network as of its public testnet launch. It is a living document and will be updated as the protocol evolves toward mainnet.

2 System Architecture

2.1 Components

The Tensorium software stack consists of four independently runnable binaries:

2.2 Block Structure

Each block consists of a header and a list of transactions:

{
  "header": {
    "version":           1,
    "chain_id":          "tensorium-testnet-0",
    "height":            uint64,
    "previous_hash":     Hash256,
    "merkle_root":       Hash256,
    "timestamp_seconds": uint64,
    "leading_zero_bits": uint8,     // current difficulty
    "nonce":             uint64
  },
  "transactions": [ Transaction, ... ]
}

The block hash is computed as SHA256(SHA256(header_bytes)) — double-SHA256, identical to Bitcoin's block hashing scheme. A block is valid if its hash has at least leading_zero_bits leading zero bits.

2.3 Transaction Structure

Transactions follow a UTXO (Unspent Transaction Output) model:

{
  "id":      Hash256,            // SHA256d of transaction data
  "inputs":  [ { prev_txid, output_index, signature_script } ],
  "outputs": [ { address, value_atoms } ],
  "payload": bytes               // coinbase: encodes height + reward + miner
}

Coinbase transactions (block rewards) have empty inputs. All other transactions must reference existing UTXOs and provide valid secp256k1 ECDSA signatures.

2.4 UTXO Set

The node maintains a UTXO set that is updated with each accepted block. Coinbase UTXOs are subject to a 100-block maturity requirement before they can be spent, providing protection against reorgs invalidating mining rewards.

2.5 Chain State

Chain state is persisted to a JSON file (tensorium-testnet-state.json by default). The canonical chain is the one with the greatest cumulative work, where block work is defined as 2^leading_zero_bits.

3 Consensus Mechanism

3.1 Proof-of-Work

Tensorium uses SHA256d (double-SHA256) as its Proof-of-Work function. To mine a valid block, a miner must find a 64-bit nonce such that:

leading_zero_bits( SHA256( SHA256( serialize(header) ) ) ) ≥ D

where D is the current difficulty in leading zero bits. The expected number of hash attempts per valid block is 2^D.

3.2 Difficulty Adjustment

Difficulty is adjusted every 60 blocks (one window) to target a 60-second block time:

actual_time   = timestamp(block_N) - timestamp(block_{N-60})
target_time   = 60 blocks × 60 seconds = 3,600 seconds
ratio         = actual_time / target_time
ratio         = clamp(ratio, 0.25, 4.0)     // max 4× adjustment per window

new_difficulty = old_difficulty + 1   if ratio < 1.0  (blocks too fast)
               = old_difficulty - 1   if ratio > 1.0  (blocks too slow)
               = old_difficulty        if ratio == 1.0

The ±1 bit per window cap prevents sudden difficulty spikes that could stall the chain or enable rapid mining attacks. Difficulty is bounded between min_leading_zero_bits (20 for testnet) and max_leading_zero_bits (40 for testnet).

3.3 Fork Choice Rule

When competing chain tips exist, the canonical chain is determined by greatest cumulative work:

cumulative_work(chain) = Σ  2^(leading_zero_bits_i)  for each block i

When a higher-work chain is received, the node performs a chain reorganization: it identifies the common ancestor, reverts blocks from the old tip back to the fork point, and applies the new chain's blocks. Reorg depth is logged to allow monitoring.

3.4 Genesis Block

The genesis block has a fixed timestamp (1,748,649,600) ensuring every node that runs tensorium-node init produces the identical genesis block hash:

Genesis hash: 00000035d8a99c0900fec5daa3ef5a7c2d71c7140e473d239a24b0dd4cd7f6c3
Timestamp:    2025-05-30 16:00:00 UTC
Nonce:        95,202,247
Difficulty:   26 bits

4 Tokenomics

4.1 Supply Summary

4.2 Emission Schedule

Block rewards halve every 1,051,200 blocks (~2 years) across 10 eras. After era 10, no new TXM is issued — the network is sustained by transaction fees.

4.3 Founder Allocation

1,000,000 TXM (3.03% of total supply) is reserved for the founding team. This allocation:

• Is declared publicly in the genesis block and codebase
• Is not pre-mined — it is accounted for separately from the mining allocation
• Will be subject to a vesting schedule to be announced before mainnet
• Has no impact on block validation or consensus rules

4.4 Transaction Fees

After era 10 (~year 2045), block rewards cease. The network is sustained entirely by transaction fees included in blocks by miners. Fee market mechanics will be refined during testnet based on observed usage patterns.

5 Mining

5.1 Mining Architecture

Mining in Tensorium is a two-step process:

1. Get block template — the miner requests a candidate block from the node RPC (GET /getblocktemplate/<address>). The template includes pending mempool transactions and the current difficulty target.
2. Find valid nonce — the miner iterates the 64-bit nonce field, computing SHA256d of the block header for each value, until a hash with sufficient leading zero bits is found.
3. Submit — the mined block is submitted to the node via POST /submitblock, which validates, stores, and broadcasts it to peers.

5.2 CPU Mining (Phase 4 — Current)

During the testnet bootstrap phase, mining is intentionally CPU-accessible. The txmminer binary provides multi-threaded CPU mining:

txmminer <rpc> <address> [threads]

# Examples:
txmminer 127.0.0.1:23332 txm1youraddress          # auto-detect cores
txmminer 127.0.0.1:23332 txm1youraddress 8         # use 8 threads

5.3 GPU-First Mainnet (Phase 6 — Planned)

Tensorium's mainnet direction is GPU-first. Before mainnet launch, a CUDA-accelerated miner (txmminer-cuda) will be developed and the difficulty will be raised to require GPU-class hardware for economically viable mining.

At difficulty 36–38 bits with a small GPU testnet (3–5 cards), average block time converges toward the 60-second target through difficulty auto-adjustment. Datacenter GPUs (H100, H200) have no meaningful advantage over high-end gaming GPUs for SHA256d — the algorithm is compute-bound and does not benefit from HBM bandwidth.

5.4 Mining Pool Support

Community mining pools will be supported before mainnet. Pool protocol design will follow standard Stratum v2 patterns. The founding team plans to launch a reference pool to lower the barrier for small miners.

6 P2P Network

6.1 Protocol

Tensorium uses a custom lightweight P2P protocol over TCP. All messages are newline-delimited JSON. Each connection begins with a bidirectional handshake:

// Hello (both sides send simultaneously)
{
  "protocol":  "tensorium-p2p",
  "version":   1,
  "chain_id":  "tensorium-testnet-0",
  "node_id":   "node-name",
  "height":    uint64,
  "tip_hash":  Hash256
}

After handshake, the following messages are supported:

6.2 Peer Discovery

The current implementation uses static peer configuration via the TENSORIUM_PEERS environment variable. Automatic peer discovery (DNS seeds, peer exchange) is planned for Phase 5.

6.3 Peer Ban Policy

Nodes maintain a score-based ban list to protect against malicious peers:

Bans last 1 hour and are persisted to disk. Nodes can be manually unbanned via tensorium-node unban <ip>.

6.4 Network Ports

7 Security Considerations

7.1 51% Attack Resistance

As with all PoW chains, Tensorium is vulnerable to 51% hash power attacks. During testnet, this risk is accepted — testnet has no economic value. For mainnet, the GPU-first design means an attacker would need to acquire a large GPU farm, which is economically costly and visible. The ±1 bit difficulty cap prevents rapid hashrate manipulation.

7.2 Replay Protection

The chain_id field is included in every block header and validated on every P2P handshake. Transactions signed for one network are invalid on another.

7.3 Timestamp Manipulation

Block timestamps must not exceed the node's local time by more than 2 hours. This prevents difficulty manipulation via far-future timestamps.

7.4 Wallet Security

The txmwallet binary uses Argon2id key derivation and ChaCha20-Poly1305 authenticated encryption to protect private keys at rest. Private keys are never transmitted over the network. Users are responsible for backing up their encrypted wallet files.

7.5 Pre-Mainnet Requirements

• Independent security audit of consensus and wallet code
• Stable GPU testnet running for minimum 4 weeks without consensus bugs
• Freeze of all consensus parameters
• Published genesis block hash and parameters before mainnet launch

8 Roadmap

— Disclaimer

This document is provided for informational purposes only. Tensorium is experimental software in active development. Testnet TXM has no monetary value. Do not invest money based on testnet activity.

The authors make no warranties regarding the software's fitness for any particular purpose, security properties, or continued availability. All consensus parameters, tokenomics figures, and roadmap timelines are subject to change based on technical findings.

This is not financial advice. Participation in mainnet mining involves real risk. Always conduct your own research.