Live Genesis Network: 19 March 2026

AI-Native Mining.

If you run power, cooling, and AI-grade compute, BTX gives you a MatMul proof-of-work network designed around the same operating realities. As more mining campuses are evaluated for AI and HPC revenue, BTX gives you a compute-native workload to test alongside the rest of your site strategy.

Mining Docs Mining RPCs
Workload 512x512 MatMul
Cadence 90 sec target
Difficulty ASERT per block
Treasury rail PQ descriptor payout
Why miners care

If your site is already judged on megawatts, cooling, uptime, and dense-compute readiness, BTX fits the way you already evaluate capacity.

Market Shift Strategy Flywheel Playbook Launch Kit FAQ
Market Shift

Mining sites are increasingly being evaluated as compute infrastructure.

Miners increasingly talk about megawatts, liquid cooling, lease terms, and AI hosting. BTX is positioned for that environment because its proof-of-work story starts from compute and fleet economics.

Recent News

Next-Gen Mining Strategy

Revenue follows dispatch, utilization, and site optionality.

If your job is to keep power, cooling, and dense compute monetized as demand shifts, BTX belongs in the same review as AI hosting, fleet orchestration, and power-market discipline.

Why BTX Fits

Built for fleets that need optionality.

AI-class math at the consensus layer

BTX mining is based on 512x512 matrix multiplication over M31. The same class of hardware that serves AI and numerical workloads can secure the chain.

Explore the source
Live difficulty as a public operator signal

BTX publishes a public work benchmark through its difficulty process. Operators can monitor cadence, readiness, and reward concentration with on-chain RPCs instead of opaque dashboards.

Explore the source
Post-quantum payout rails from the start

Production payouts can land in post-quantum descriptor wallets and multisig policies, so treasury security assumptions do not have to wait for a later migration cycle.

Explore the source
Site Fit

See where your site fits before you allocate power.

Different site profiles need different first checks, different caveats, and different docs entry points. Start with the profile that matches your site before you allocate power.

Lab operator or independent miner

Best fit when
  • You want to validate BTX mining without standing up a large fleet first.
  • You care about node bring-up, payout routing, and watching cadence before scaling.
Validate first
  • Confirm your hardware path and getblocktemplate loop first.
  • Make sure rewards land cleanly in a BTX descriptor wallet before you add more capacity.
Open docs: Hardware requirements Open docs: Create descriptor wallet
Network Effect Thesis

Compatible compute can deepen the BTX work market.

As miners and power operators explore more AI-oriented infrastructure strategies, networks that rely on narrower hardware profiles may align less closely with some emerging site economics. BTX is positioned for operators who value reusable dense-compute infrastructure.

1

AI infrastructure expands the pool of compatible compute

More sites are being financed around dense math, cooling, and power delivery assumptions that already resemble the workload profile BTX needs.

2

Compatible operators can mine BTX without a hash-only story

That broadens the potential miner base beyond teams whose economics depend entirely on specialized, single-purpose hardware narratives.

3

A wider miner base can deepen the difficulty commons

More participation can make BTX’s public work benchmark more resilient, more legible, and more useful to infrastructure teams watching real solve conditions.

4

A stronger work benchmark can reinforce the mining case

If services, APIs, and verification workflows increasingly rely on BTX challenge pricing, the network becomes more valuable infrastructure to secure and to mine.

Operator Playbook

Move from evaluation to fleet workflow.

Before you point serious power at BTX, keep these docs open. They cover the operating surface, payout rails, and monitoring loops you will actually rely on.

Operator Readiness

Know what is ready, what needs caveats, and what to validate before scale.

  • Ready now Solo mining, template issuance, PQ payout routing, and difficulty-health monitoring are all documented end to end for operator teams.
  • Known operator caveats Hardware fit, backend choice, and routing behavior still matter. CPU paths work, Apple Silicon Metal is documented, and pool flows remain a separate integration concern.
Stand up the node Point your fleet at MatMul work
getblocktemplate workflow Mine to address Watch getdifficultyhealth Hardware requirements

Stand up the node

Build from source, connect to mainnet, and use the same node surface that drives the public docs and RPC references.

Open the relevant doc
Operator Launch Kit

Turn the thesis into an operator work queue.

These bundles line up the BTX docs the way an infra desk actually moves: bring up the node, automate the work loop, route payouts, and watch live health.

Wallet Guide

Commission the node

Stand up a mainnet-capable node and confirm the control plane before any fleet traffic touches it.

Quickstart Mining Guide
Operator FAQ

Questions mining teams ask before they allocate power.

These answers stay close to the current docs and the operator thesis on this page: evaluate BTX like infrastructure, validate the work loop, then scale deliberately.

Do I need AI-specific hardware to evaluate BTX?

Not necessarily. BTX is built around dense matrix work, so operators should evaluate hardware, thermals, and fleet economics through the lens of reusable compute. The practical question is whether a site can run the work productively and operationally, not whether every machine looks like a hyperscale AI cluster.

Open the relevant doc
How should BTX fit a site that is also courting AI or HPC business?

Treat BTX as one workload inside a broader dispatch strategy. If a site is comparing mining, hosting, and other compute demand, BTX belongs in that workload-mix conversation rather than in a siloed hash-only plan.

Open the relevant doc
What should I monitor before scaling a BTX mining fleet?

Start with node readiness, block-template flow, difficulty health, and payout routing. The goal is to verify cadence and treasury operations with the same operational discipline you would apply to any other production compute surface.

Open the relevant doc
Next Step

If you run power-rich compute, evaluate BTX like a real revenue path.

Start with the mining guide, inspect the wallet and payout model, and read the RPC surface the same way you would review an infrastructure control plane.

Start Mining View BTX