Génesis: 19 de marzo de 2026

Construye para agentes nativos de IA.

BTX da a los desarrolladores dos primitivas que encajan especialmente bien con software nativo de IA: desafíos de trabajo frescos y ligados a la cadena para control de admisión, e identidad post-cuántica respaldada por billetera para agentes, servicios y operadores que quieren reducir su dependencia de firmas heredadas.

Ruta de solicitud
  1. solicitud de agente firmada
  2. se emite el sobre de desafío
  3. se resuelve trabajo fresco localmente
  4. la prueba se canjea y se admite
Identidad material de billetera PQ
Admisión prueba de trabajo fresco
Verificación barato frente al costo de resolver
Superficie RPC + flujos de gateway

Los productos nativos de IA necesitan un mejor control de admisión que una caja CAPTCHA.

Los flujos de desafío solo para humanos no encajan bien con sistemas automatizados, clientes API y herramientas de operador. Los desafíos de servicio BTX te permiten pedir cómputo fresco: costoso de automatizar a escala, barato de verificar y ligado a las condiciones actuales de la cadena.

Un patrón de gateway construido para llamadores automatizados.

El objetivo no es interrumpir a una persona con acertijos. El objetivo es que cada ruta costosa publique un precio de trabajo en vivo que agentes y clientes API puedan satisfacer programáticamente y luego verificar de forma barata antes de ejecutar.

Solo claves API

Identidad sin precio de trabajo por ruta.

Mejor en:
  • Simple para usuarios pagos conocidos y clientes estables servidor a servidor.
Débil en:
  • Débil frente a credenciales copiadas, acceso revendido o abuso anónimo en rutas costosas.
Lo que realmente aporta:
  • Identidad sin precio de trabajo por ruta.

Un ciclo práctico para desarrolladores, no una historia vaga del futuro.

La documentación publicada de OpenClaw es un ejemplo: los clientes declaran rol y alcances en el handshake, firman un nonce de desafío provisto por el servidor y reciben tokens de dispositivo limitados por rol y alcances. BTX encaja por encima de esa pila como requisito de trabajo a nivel de ruta para acciones costosas o propensas al abuso.

# 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
  1. 1
    Emitir un desafío

    Usa getmatmulservicechallenge para vincular trabajo fresco a un propósito, recurso, sujeto y objetivo de tiempo de resolución.

    Abrir el documento relevante
  2. 2
    Dejar que el cliente resuelva localmente

    El solicitante calcula una prueba MatMul vinculada al estado actual de la cadena, por lo que las ventanas de precómputo siguen siendo limitadas.

    Abrir el documento relevante
  3. 3
    Canjear y verificar

    Acepta la solicitud solo cuando redeemmatmulserviceproof confirme que la prueba es válida, fresca y no ha sido consumida antes.

    Abrir el documento relevante
  4. 4
    Añadir identidad

    Agrega identidad respaldada por billetera BTX y estándares de solicitud firmada cuando un agente o servicio necesite identidad criptográfica duradera.

    Abrir el documento relevante
  • que propósito, recurso y sujeto coincidan con la ruta que querías proteger
  • que el tiempo de resolución quede dentro de la ventana cotizada al cliente
  • que la prueba se canjee una sola vez y no pueda reutilizarse después
  • que se pueda superponer identidad firmada para credenciales duraderas de agentes u operadores

Dónde encaja BTX dentro de pilas reales de IA y gateways.

Los sistemas tipo gateway ya distinguen identidad de dispositivo, política de ruta y autorización. BTX añade una capa de trabajo fresco sobre esa pila cuando la ruta es costosa, propensa al spam o vale la pena protegerla del abuso automatizado.

Empieza por la forma de ruta que coincide con tu producto.

No son personas abstractas. Son formas concretas de desafío BTX que puedes trasladar a un gateway, una API pública o un flujo de agentes y luego endurecer según tu propio modelo de amenaza.

API pública de inferencia IA

Binding recomendado
  • purpose: ai_inference_gate
  • resource: model:gpt-x|route:/v1/generate|tier:free
  • subject: tenant:abc123 o api_key:key-42
Política del desafío
  • target_solve_time_s: 2-4 segundos para tráfico gratuito o anónimo
  • expires_in_s: 60-180 segundos para que los sobres viejos pierdan valor rápido
  • redeem path: usa redeemmatmulserviceproofs cuando las solicitudes se encolan o se reparten a workers compartidos

Muestra a los builders qué es seguro hoy, qué requiere disciplina de enrutado y dónde termina BTX.

Trata los service challenges de BTX como un subsistema real de control de admisión: empieza con un solo nodo, canjea en el punto real de decisión y deja explícito qué demuestra la prueba y qué no.

Listo hoy: rutas protegidas en un solo nodo

La ruta de producción documentada usa un único nodo BTX para emitir y canjear contra el mismo registro de desafíos. Eso cubre muchas rutas de inferencia, registro y gateway sin añadir otra capa de coordinación primero.

Cautela de escala: multi-nodo necesita afinidad o estado compartido

Cuando issue y redeem pueden caer en nodos BTX distintos, el registro de desafíos pasa a ser una dependencia operativa. Añade sticky routing o un archivo compartido de desafíos antes de considerar segura la escala horizontal.

Regla de admisión: redeem para producción, verify para diagnóstico

La verificación solo te dice si una prueba coincide con el desafío. El canje es el evento de admisión con protección contra replay que consume la prueba una vez y da al gateway un resultado autoritativo de aceptar o rechazar.

Identidad respaldada por billetera que empieza siendo post-cuántica.

Las billeteras BTX son basadas en descriptores y están diseñadas alrededor de ML-DSA y SLH-DSA desde el inicio. Eso reduce la probabilidad de tratar el material de identidad central como un proyecto de migración posterior.

Identidad respaldada por billetera que empieza siendo post-cuántica.

Cómo debe explicarse BTX a los equipos de IA.

  • Las solicitudes firmadas identifican a quien llama.
  • Los desafíos de trabajo BTX ponen precio al abuso y a la presión de tasa.
  • El material de billetera PQ da al llamador mejores suposiciones de identidad a largo plazo.
  • Juntos crean una pila de admisión más duradera para herramientas de agentes, APIs y flujos de gateway.

Construye la ruta y luego endurece su operación.

Estos bloques ordenan la documentación como suele avanzar un equipo API: prototipar el desafío, enlazar identidad, cablear el plano de control y observar condiciones en vivo.

Emitir y canjear desafíos en vivo

Empieza por el bucle más pequeño que sirva: emitir un desafío, resolverlo y canjearlo en la ruta que quieres proteger.

Preguntas que hacen los equipos cuando prototipan flujos de desafío con BTX.

Estas respuestas se mantienen cerca de la documentación actual de RPC y billetera: BTX complementa la autenticación existente, añade precio de trabajo fresco a rutas costosas y ofrece un camino de identidad post-cuántica para sistemas nativos de IA.

¿BTX reemplaza claves API, OAuth o la política del gateway?

No. BTX funciona mejor como complemento del stack de autenticación que ya tienes. Mantén identidad, scopes y política donde están, y pide trabajo BTX solo en rutas donde importan el abuso, el coste o la contención de recursos.

Abrir el documento relevante
¿Dónde encaja el desafío dentro de un flujo de IA o de agentes?

Normalmente después de identificar la solicitud y antes de ejecutar la acción costosa. El servidor emite un sobre de desafío en vivo, quien llama lo resuelve y el servicio canjea la prueba antes de gastar tiempo de GPU, cuota de modelo u otros recursos escasos.

Abrir el documento relevante
¿Por qué llevar identidad post-cuántica respaldada por billetera al flujo?

BTX permite que el mismo sistema hable de trabajo fresco y de material de firma más fuerte en una sola pila. Para equipos que ya planifican la migración post-cuántica, eso facilita evaluar identidad y admisión juntas en lugar de tratarlas como proyectos futuros separados.

Abrir el documento relevante
¿Puede encajar con gateways como OpenClaw o con pilas de estilo MCP?

Arquitectónicamente sí: conserva el modelo existente de roles, scopes y confianza del dispositivo, y añade BTX como requisito de trabajo a nivel de ruta. Ese es el encaje descrito en esta página, no una afirmación de soporte nativo de OpenClaw dentro de BTX hoy.

Abrir el documento relevante

Si tu producto tiene un problema de abuso, un nivel gratuito o una capa de agentes, BTX debe entrar en la revisión de diseño.

Empieza con la guía de desafíos de servicio, lee el modelo de billetera y prototipa una ruta segura para agentes que exija tanto identidad como trabajo.