Skip to content
BitcoinAI — The AI Blockchain for Bitcoin
GitHub (opens in a new tab)White Paper
BitcoinAI — The AI Blockchain for Bitcoin

AI

Proof-of-AI verification

The verification methods behind AI receipts and qualified work.

Verify what can actually be verified

Do not pretend hidden model weights are publicly hashable.

Engineering
Provider / Model ID plus Input hash plus Output hash plus Signed receipt equals Verifiable provenance.

What can be recorded for proprietary APIs

  • Provider identity
  • Model identifier
  • Model version (if provided)
  • Request configuration hash
  • Input commitment
  • Output commitment
  • Timestamp
  • Provider receipt
  • Provider signature
  • Execution metadata

Never claimed

  • Exact proprietary model weights are known
  • Hidden model binaries are independently hashed by BitcoinAI

Stronger artifact verification

Open and local models can support deeper reproducibility.

Planned

Open / local deployments can include

  • Model artifact hash
  • Container hash
  • Weights hash
  • Tokenizer hash
  • Inference configuration
  • Deterministic seed where applicable
  • Runtime measurement
  • TEE attestation
  • Optional reproducibility test
  1. 01Model artifact
  2. 02Artifact hash
  3. 03Execution receipt
  4. 04BitcoinAI commitment

Not all AI inference is deterministic. Reproducibility depends on the model, runtime and configuration.

AI needs compute

Open AI infrastructure still depends on GPUs, networks and operators.

The decentralized layer coordinates who can provide services, how work is evidenced, and how applications settle—while the underlying models continue to run on specialized computing infrastructure.

Temporary Unsplash placeholder · Photo by Eric Stoynov

Assurance levels

Different AI jobs can require different verification strength.

  1. Tier 0

    Hash commitment

    • Integrity
    • Provenance

    No premium economic qualification by itself.

    Canonical

  2. Tier 1

    Signed provider receipt

    • Provider accountability
    • Execution claim
    Engineering

  3. Tier 2

    Independent verification

    • Second-party validation
    • Result or policy confirmation
    Engineering

  4. Tier 3

    Trusted Execution Environment

    • Hardware-backed execution evidence
    Research target

  5. Tier 4

    zkML / verifiable inference

    • Cryptographic proof of computation where practical

    Not universally practical or cheap today.

    Research target

Tiers 3 and 4 are future-capable and task-dependent.

Batch the micropayments

Millions of AI events should not require millions of heavyweight on-chain settlements.

Engineering
Merkle root → BitcoinAI commitmentAI job receipts 1 … N
  1. Provider batch
  2. Merkle tree
  3. Merkle root
  4. BitcoinAI commitment
  5. Periodic settlement

Batched together

  • Job receipts
  • Provider earnings
  • Verification records
  • Micropayment obligations
  • Individual jobs retain inclusion proofs.
  • On-chain state remains compact.
  • Provider balances can be netted.
  • Settlement can occur periodically.

Batching does not remove the need for an individual dispute path.