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.
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_versionandreplay_authority_contextacross every archive and mirror before admitting traffic. - Monitor
getmatmultrustedstatusfor 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=consensuswith 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.