Live Genesis Network: 19 March 2026

Build for AI-Native Agents.

BTX gives you two building blocks for AI-facing products: fresh, chain-bound work challenges for route admission, and wallet-backed post-quantum signing material for agents, services, and operators that want stronger long-term identity than legacy signatures provide.

Integration Guide Challenge RPCs
Request Path
  1. signed agent request
  2. challenge envelope issued
  3. fresh work solved locally
  4. proof redeemed and admitted
Identity PQ wallet material
Admission fresh work proof
Verification cheap vs solve cost
Surface RPC + gateway flows
Use Cases Challenge Flow Patterns Identity Launch Kit FAQ
Why This Matters

AI-native products need better admission control than a CAPTCHA box.

If you run an API, agent runtime, or tool gateway, human-only CAPTCHA flows are the wrong control surface. BTX lets you require fresh computation instead: expensive to automate at scale, cheap to verify, and tied to current chain conditions.

AI-Agent CAPTCHA

A gateway pattern built for automated callers.

Use BTX when you want every expensive route to quote a live work price that agents and API clients can satisfy programmatically before execution.

API Keys Only

Identity without route-level work pricing.

Best at:
  • Simple for known paid users and stable server-to-server clients.
Weak at:
  • Weak against copied credentials, resold access, or anonymous abuse on expensive routes.
What it really provides:
  • Identity without route-level work pricing.
Challenge Flow

A practical developer loop, not a vague future story.

If your stack already uses roles, scopes, device identity, or signed requests, BTX can sit on top as a route-level work requirement for expensive or abuse-prone actions. OpenClaw-style gateway patterns are one concrete example. 

# Pseudocode: gateway route protected by BTX work
POST /v1/generate
Authorization: Signature keyId="btx-wallet:agent-42",...
X-Device-Token: devtok_...
X-BTX-Challenge-Id: chal_...
X-BTX-Proof-Nonce: ...
X-BTX-Proof-Digest: ...

# Server sequence
1. validate role + scope + device token
2. verify request signature
3. redeem BTX proof for this route
4. only then run the expensive action
Protected Route Contract OpenClaw Gateway Protocol MCP Authorization
Challenge Flow
  1. 1
    Issue a challenge

    Use getmatmulservicechallenge to bind fresh work to a purpose, resource, subject, and solve-time target.

    Open the relevant doc
  2. 2
    Let the client solve locally

    The requester computes a MatMul proof tied to current chain state, so pre-computation windows stay limited.

    Open the relevant doc
  3. 3
    Redeem and verify

    Accept the request only when redeemmatmulserviceproof confirms the proof is valid, fresh, and not already consumed.

    Open the relevant doc
  4. 4
    Layer in identity

    Add BTX wallet-backed identity and signed-request standards on top when an agent or service needs durable cryptographic identity.

    Open the relevant doc
What the server checks
  • purpose, resource, and subject match the route you intended to protect
  • solve time stays inside the window you quoted to the client
  • proof is redeemed once and cannot be replayed later
  • signed identity can be layered on top for durable agent or operator credentials
Deployment Patterns

Where BTX fits inside real AI and gateway stacks.

Gateway-style systems already distinguish device identity, route policy, and authorization. BTX adds a fresh-work layer on top of that stack when the route itself is expensive, spam-prone, or worth protecting from automated abuse.

Reference Architectures

Start from the route shape that matches your product.

Choose the route shape that matches your product, then adapt the bindings and challenge policy to your own threat model.

AI inference profile Single-node deployment

Public AI inference API

Recommended binding
  • purpose: ai_inference_gate
  • resource: model:gpt-x|route:/v1/generate|tier:free
  • subject: tenant:abc123 or api_key:key-42
Challenge policy
  • target_solve_time_s: 2-4 seconds for free or anonymous traffic
  • expires_in_s: 60-180 seconds so stale envelopes lose value quickly
  • redeem path: use redeemmatmulserviceproofs when requests queue or fan out through shared workers
Open docs: AI inference profile Open docs: Issue challenge RPC Open docs: Batch redeem RPC
Production Readiness

Know what is safe now, what needs routing discipline, and where BTX stops.

Treat BTX service challenges like a real admission-control subsystem: start single-node, redeem at the actual decision point, and stay explicit about what the proof does and does not prove.

Ready now: single-node protected routes

The documented production path is one BTX node issuing and redeeming against the same challenge registry. That covers many inference, signup, and gateway routes without adding another coordination layer first.

Scale caveat: multi-node needs affinity or shared state

Once issuance and redemption can land on different BTX nodes, the challenge registry becomes an operational dependency. Add sticky routing or a shared challenge file before you call the route horizontally safe.

Admission rule: redeem for production, verify for diagnostics

Verification tells you whether a proof matches the challenge. Redemption is the replay-safe admission event that consumes the proof once and gives your gateway the authoritative accept-or-reject result.

Protected route contract Redeem proof RPC Multi-node deployment Failure semantics
Identity Layer

Wallet-backed identity built around post-quantum primitives from the start.

BTX wallets are descriptor-based and designed around ML-DSA and SLH-DSA from the start. That reduces the chance of treating core identity material as a later migration project.

Create a Wallet
Identity Layer

Wallet-backed identity built around post-quantum primitives from the start.

  • Post-quantum wallet design by default BTX wallets are descriptor-based and designed around ML-DSA and SLH-DSA from the start. That reduces the chance of treating core identity material as a later migration project.
    Explore the source
  • Challenge flow anchored to live difficulty Service challenges and mining RPCs expose live work profiles, target solve windows, and fresh chain-bound challenge context for abuse pricing.
    Explore the source
  • Built for agent coordination services The protocol docs already position BTX above a narrow settlement base for bridges, services, and agent coordination layers instead of one shared runtime.
    Explore the source
Build Principles

Separate caller identity from work pricing.

  • Signed requests identify the caller.
  • BTX work challenges price abuse and rate pressure.
  • PQ wallet material gives the caller stronger long-term identity assumptions.
  • Together they create a more durable admission stack for agent tools, APIs, and gateway workflows.
Developer Launch Kit

Build the route, then harden it.

These bundles line up the docs in the order an API team usually works: prototype the challenge route, bind identity, wire the control plane, and watch live conditions.

Issue and redeem live challenges

Start with the smallest useful loop: issue a challenge, solve it, and redeem it on the route you want to protect.

Core Flow Guide getmatmulservicechallenge RPC
Developer FAQ

Questions teams ask when they prototype BTX challenge flows.

These answers stay close to the current RPC and wallet docs: BTX complements existing auth, adds fresh-work pricing to expensive routes, and gives AI-native systems a post-quantum identity path.

Does BTX replace API keys, OAuth, or gateway policy?

No. BTX works best as a complement to the auth stack you already have. Keep identity, scopes, and policy where they are, then ask for BTX work only on routes where abuse, cost, or resource contention matters.

Open the relevant doc
Where does the challenge fit in an AI or agent workflow?

Usually after normal request identification but before the costly action runs. The server issues a live challenge envelope, the caller solves it, and the service redeems the proof before it spends GPU time, model quota, or other scarce resources.

Open the relevant doc
Why bring wallet-backed post-quantum identity into the flow?

BTX lets the same system talk about fresh work and stronger signing material in one stack. For teams already planning around post-quantum migration, that makes it easier to evaluate identity and admission together instead of as separate future projects.

Open the relevant doc
Can this fit gateway protocols such as OpenClaw or MCP-style stacks?

Architecturally yes: keep the existing role, scope, and device-trust model, then add BTX as a route-level work requirement. That is the intended fit described on this page, not a claim that BTX ships a native OpenClaw integration today.

Open the relevant doc
Next Step

If your product has an abuse problem, a free tier, or an agent layer, prototype BTX in the admission path.

Start with the service challenge guide, read the wallet model, and prototype an agent-safe route that requires both identity and work.

Build the Flow View BTX