Skip to main content
Required consensus upgrade Hard fork · block 185,000

Update every BTX node to v0.33.2 before the fork.

MatMul v4.7 Epoch A activates at mainnet block 185,000. Miners, pools, validators, exchanges, custodians, explorers, and node operators running older code will not follow the upgraded consensus.

Blocks until hard fork Checking live mainnet tip
4,927 blocks remaining
Live tip 180,073
Activation 185,000
Estimated time ≈ 5d 03h 10m 30s

The fork is height-based, not clock-based. The time estimate uses BTX's 90-second target and resets from the live chain tip. Upgrade, restart, and confirm v0.33.2 before block 185,000.

Trusted MatMul Mirrors

Deploy and operate MatMul v4.7 trusted RPC mirrors with qualified GPU archives, explicit M-of-N attestation trust, monitoring, and recovery.

Mine Context

This reference is part of the BTX operator rollout.

Use the Mine microsite to reconnect this page to the broader operator thesis, AI-infrastructure framing, and mining launch kit.

Trust boundary

A trusted MatMul mirror validates headers, block bodies, transactions, scripts, and state, but accepts an M-of-N archive-signer quorum instead of performing local Profile-1 ExactReplay. It is not an independently validating MatMul full node.

Use this topology only inside an explicitly governed fleet. Compromise of M configured keys can make those mirrors accept false MatMul work. Attestations are operator sidecars, not block contents, consensus proofs, or Stage-3 proof authority; ordinary consensus nodes ignore them as authority.

Recommended topology

two or more qualified GPU archive validators
  local Profile-1 ExactReplay + one attestation key each
                         |
                         | signed, context-bound attestations
                         v
two or more HA RPC mirrors
  full block/state validation + 2-of-N signer quorum

A supported 1-of-1 mainnet configuration emits a prominent warning and leaves one key as the mirror's sole proof-of-work authority. Two distinct signers with threshold 2 are the recommended minimum; 2-of-3 adds tolerance for one unavailable archive. Repeating a public key is rejected and does not add independence.

GPU archive configuration

matmulvalidation=consensus
matmulrcexecution=strict-device
matmultrustedpubkey=02...this-archive-public-key
matmulattestationsignerkeyfile=/secure/btx/matmul-attestor.wif
matmulattestationserve=1
assumevalid=0
prune=0
  • Use a dedicated permission-restricted online attestation key on each archive.
  • Never put the WIF in a process argument; the direct key option is deprecated because command lines can leak.
  • Only a consensus-role node with successful, locally persisted ExactReplay may sign and serve attestations.
  • Pin deployment to reviewed source and binary hashes, and verify strict-device qualification after daemonization.

RPC mirror configuration

matmulvalidation=trusted
matmultrustedpubkey=02...archive-a-public-key
matmultrustedpubkey=02...archive-b-public-key
matmultrustedthreshold=2
matmultrustedwaitms=30000
connect=<gpu-archive-a-address>
connect=<gpu-archive-b-address>
server=1
prune=0
txindex=1
assumevalid=0

Apply normal RPC isolation, authentication, firewall, TLS/reverse-proxy, and rate-limit policy. Trusted MatMul mode does not relax RPC security. Use prune=0 only when the deployment promises historical block/RPC access, and enable txindex=1 only when transaction-by-id history is required.

Operations and monitoring

  • Compare attestation_version and replay_authority_context across every archive and mirror before admitting traffic.
  • Monitor getmatmultrustedstatus for role, threshold, retained objects, quorum completions, rejects, duplicates, and timeouts.
  • Alert on archive provider loss, mirror tip lag, replay-authority mismatch, quorum timeout, and signer-key change.
  • If a device is unhealthy, stop that archive's attestation service until it again completes authoritative ExactReplay.
  • A missing quorum leaves a block retryable; it is not a peer fault and does not make the block invalid.
  • To regain independent validation, restart in matmulvalidation=consensus with a qualified strict device and deliberately revalidate as required.

Bundle transfer and key rotation

btx-cli getmatmulattestations <blockhash>
btx-cli submitmatmulattestations '["<serialized-attestation>", ...]'

exportmatmulattestations and importmatmulattestations are aliases. The runtime store and replay memo are process-local, so current-policy signatures must be fetched or imported again after restart when validation revisits a block. Signer rotation is prospective by default; applying it retroactively requires deliberate reindex/revalidation from the chosen height.

See the MatMul v4.7 specification and the canonical v0.33.2 operator guide.