BTX // ASCII ART MINER

ADMISSION TICKET · PROOF-OF-USEFUL-WORK · BTX L1
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

▸ COMPUTATIONAL LIVENESS

YOU COMPUTED NOW, NOT EARLIER

The whitepaper's term. Your proof can't be prepaid, replayed, or amortised across requests — it has to be produced against the current chain state, every time.

▸ DIFFICULTY COMMONS

CALIBRATED TO LIVE MAINNET

Your challenge's target tracks BTX's live difficulty per block. Refresh in 90 s, the anchor shifts. Replay an old proof — node rejects it with already_redeemed or expired.

▸ ADMISSION TICKET

EXACTLY WHAT BTX CALLS IT

An LLM, a bridge operator, a swarm worker, or a curl one-liner uses the same primitive: "a proof of current work before accepting a request". No API key. No bearer secret. Just work.

▌ STRAIGHT FROM THE WHITEPAPER
"Above the base layer, BTX work proofs can be reused as admission tickets. A bridge, relay, or service can require a proof of current work before accepting a request." That ticket "proves not only that the requester holds an identity key, but also that the requester has expended fresh computation now, against current network conditions."
BTX Specifications, §7 — Network, Relay, and Admission Control
▌ HOW IT STACKS ▌
╔═══════════════════╗   ╔═══════════════════╗
║   L2 BRIDGES      ║   ║  ADMISSION TICKETS║
║   whitepaper §9   ║   ║  whitepaper §7    ║
║                   ║   ║                   ║
║   value movement  ║   ║  access gating    ║
║   banks · swaps   ║   ║  ◄── YOU ARE HERE ║
╚════════╤══════════╝   ╚═════════╤═════════╝
         │                        │
         └──────────┬─────────────┘
                    ▼
          ╔═══════════════════╗
          ║       BTX L1      ║
          ║   PoW · 90s blocks║
          ╚═══════════════════╝
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.