BTX // ASCII ART MINER

PROOF-OF-MATMUL · POWERED BY BTX.DEV
idle — checking btxd…

▌ HOW IT WORKS

1

GET A CHALLENGE FROM THE CHAIN

Your browser asks our BTX node for a fresh matmul_service_challenge_v1. It's anchored to the live mainnet block — every challenge carries previousblockhash, seed_a, seed_b, and a target. No two challenges are the same; expired ones can't be reused.

2

SOLVE A 512×512 MATMUL

A solver does real CPU work: build matrices A,B deterministically from the seeds, multiply them in the M31 prime field, compress the transcript through a rolling SHA-256d hasher, and hunt for a nonce64 whose final digest beats target. Roughly ~150M field multiplies per attempt.

3

REDEEM ON-CHAIN, RECEIVE THE ART

The proof (nonce64_hex, digest_hex) goes to redeemmatmulserviceproof. The node re-runs the math (Freivalds + transcript check), marks the challenge consumed, and only then do we mint the ASCII art seeded by the challenge_id. One challenge = one mint. No replays.

▌ WHAT THIS PROVES

▸ TRUSTLESS ACCESS

NO API KEY, NO ACCOUNT

You didn't sign up. You didn't pay. You spent verifiable computation instead. The chain — not us — decides whether your work was valid.

▸ REAL CHAIN ANCHOR

BOUND TO LIVE MAINNET

Every challenge ID embeds the current BTX block hash. Refresh in 90 s and the anchor changes. Try replaying an old proof — the node rejects it with already_redeemed or expired.

▸ AGENT-NATIVE

SAME FLOW FOR AUTONOMOUS AGENTS

An LLM, a swarm worker, or a curl one-liner hits /challenge + /redeem identically. This is how AI services gate themselves against bots without captchas or seat licenses.

OLD WAY · API KEYS → issue keys, rotate them, rate-limit by tenant, get scraped, ban IPs, lose to bots, charge for seats.
NEW WAY · MATMUL PROOFS → caller burns CPU per request, proof carries its own cost, no identity required, no bearer secret to leak.