Public API gating
Require fresh work before expensive or abuse-prone endpoints admit traffic. This is a better fit for anonymous or free-tier traffic than charging every caller up front.
Develop on BTX Agent-safe workflows
Build APIs that agents have to prove themselves to.
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.
Request Path
- signed agent request
- challenge envelope issued
- fresh work solved locally
- proof redeemed and admitted
Identity PQ wallet material
Admission fresh work proof
Verification cheap vs solve cost
Surface RPC + gateway flows
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 inference admission
Price bot pressure and inference abuse with challenge difficulty instead of relying only on quotas, CAPTCHA prompts, or blind rate limits.
Agent-to-tool verification
Challenge the caller, verify the proof cheaply, and combine that with signed requests when agents need access to tools, gateways, or operator workflows.
Spam and signup resistance
Use BTX service challenges for comments, account creation, and public forms where human-only CAPTCHA flows are a poor experience or easy to outsource.
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.
Mark the route as challengeable
At the gateway, identify inference, signup, search, or tool routes whose cost and abuse profile justify quoting fresh work before execution.
Issue a chain-bound challenge envelope
Return BTX work keyed to purpose, resource, and subject instead of sending the caller through a human-only CAPTCHA flow.
Require proof with the request
The client or agent solves locally, then submits the proof alongside the original API call and any signed identity material you require.
Redeem before the expensive action runs
Your server verifies freshness, replay state, and difficulty context before the model run, workflow step, or privileged tool call begins.
Challenge Flow
A practical developer loop, not a vague future story.
1
Issue a challenge
Use getmatmulservicechallenge to bind fresh work to a purpose, resource, subject, and solve-time target.
Open the relevant doc2
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 doc3
Redeem and verify
Accept the request only when redeemmatmulserviceproof confirms the proof is valid, fresh, and not already consumed.
Open the relevant doc4
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# Issue a challenge envelope
curl --silent --user "$BTX_RPC_USER:$BTX_RPC_PASSWORD" \
--data-binary '{
"jsonrpc":"1.0",
"id":"issue",
"method":"getmatmulservicechallenge",
"params":["ai_inference_gate","model:gpt-x|route:/v1/generate|tier:free","tenant:abc123",2,300,0.25,0.75]
}' \
-H 'content-type: text/plain;' \
http://127.0.0.1:19334/
# Redeem the returned proof
btx-cli redeemmatmulserviceproof CHALLENGE NONCE DIGEST Admission Stack Comparison
BTX is the work-and-identity layer, not the whole auth stack.
The practical choice is not between "use BTX" or "use auth." It is how you combine normal authentication with a machine-native way to price abuse on the routes that matter.
API Keys Only
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.
Human CAPTCHA
Best at: Useful when the caller is definitely a person in a browser.
Weak at: Poor fit for agents, tools, automated clients, and flows that can be outsourced to CAPTCHA farms.
What it really provides: Human friction, not machine-native admission.
BTX Challenge + Signed Identity
Best at: Lets the caller prove freshness, pay an abuse cost in computation, and attach stronger signing material.
Weak at: Still needs normal auth and policy decisions around account, scope, and business rules.
What it really provides: Fresh work plus durable machine identity.
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.
AI inference gateway
Anonymous or free-tier inference requests get challenged before the model spins up. Known paid traffic can bypass or use lighter policies.
Agent tool access
Before an agent hits a sensitive tool or operator workflow, require both a signed identity and fresh work tied to that route or scope.
Signup and spam control
Comments, registrations, and public forms can price abuse with computation instead of relying on CAPTCHA farms, SMS walls, or permanent balances.
Operator control planes
High-risk admin paths can require a post-quantum wallet identity plus chain-bound work, making replay and outsourced abuse materially harder.
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.
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
Agent or tool gateway
Recommended binding
- purpose: api_gate
- resource: tool:calendar.write|route:/mcp/tools/calendar.write
- subject: wallet:agent-42 or device:devtok_abc123
Challenge policy
- target_solve_time_s: 1-2 seconds for interactive tool calls, higher on privileged routes
- expires_in_s: 30-120 seconds to keep signed requests and work tightly coupled
- redeem path: use redeemmatmulserviceproof for request-by-request admission at the gateway edge
Anonymous public submission
Recommended binding
- purpose: rate_limit
- resource: signup:/v1/messages or comment:/v1/posts/:id
- subject: ip:203.0.113.0/24 or user:[email protected]
Challenge policy
- target_solve_time_s: 1-3 seconds so honest users can finish while spam costs rise
- expires_in_s: 60-300 seconds and redeem only on final submit
- redeem path: use redeemmatmulserviceproof unless you batch queued moderation jobs
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.
Trust boundary: BTX proves work, not your whole auth model
BTX can prove fresh chain-bound work and pair cleanly with wallet identity, but it does not decide business authorization, human intent, or whether a model response is correct. Keep those checks in the gateway and product layer.
Implementation note: BTX is the fresh-work layer, not the whole policy stack. Multi-node fleets still need sticky routing or shared challenge state, and business authorization stays outside the proof.
Scoped Gateway Pattern
BTX fits alongside gateways that already use role, scope, and device trust.
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.
Handshake state already exists in scoped gateways
OpenClaw’s published gateway protocol is one example: clients declare role and scopes during the WebSocket handshake, which is a natural place to decide whether later routes should require fresh work.
Device identity and device tokens can stay intact
In that model, signed device identity, pairing, and per-device role tokens stay intact. BTX does not replace that layer; it complements it when a route also needs anti-abuse work pricing.
Server-issued nonce plus BTX challenge is a clean stack
A gateway can keep its own connect challenge and request-signing rules, then issue BTX work only for the expensive inference, tool, or operator action that follows.
The result is policy that feels native to agents
Roles, scopes, device trust, and fresh work can all be evaluated without dropping back to a human-only CAPTCHA or permanent prepaid balance model.
# 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 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 sourceChallenge 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 sourceBuilt 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 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.
Bind caller identity to wallet material
Layer BTX work on top of explicit caller identity so admission and stronger signing assumptions evolve together.
Map BTX onto the service surface
Once the challenge loop works, connect it to the broader RPC and wallet surfaces your service already operates.
Watch difficulty and challenge conditions
Expose challenge cost and network health like any other production dependency so operators can tune protection without guessing.
Standards and Ecosystem
The rest of the stack is already moving toward stronger agent identity and challenge flows.
2024-08-13
NIST finalizes first PQC standards
BTX starts from the direction the standards world is already moving toward: post-quantum signatures and migration pressure now, not later.
RFC 9421 / 9449Signed request standards are mature enough to build on
HTTP Message Signatures and DPoP provide a strong standards-adjacent frame for authenticated, proof-of-possession style API traffic.
2025-03-26MCP pushes real auth and security concerns into agent tooling
Agentic systems now need proper authorization, scoped access, and secure tool use. BTX fits as a work and identity layer around those flows.
OpenClawGateway-style agent systems already use signed device material
OpenClaw gateway docs show signed device tokens and scope-aware roles. BTX can complement that with fresh work requirements for high-risk routes.
2025-09-18NIST says organizations should start planning PQC migration now
NCCoE's CSWP 48 draft frames PQC transition as a current governance and control-mapping problem, not a task to postpone until later milestones.
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 docWhere 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 docWhy 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 docCan 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.