Control de APIs públicas
Exige trabajo fresco antes de admitir tráfico en endpoints caros o propensos al abuso. Es un mejor encaje para tráfico anónimo o de capa gratuita que cobrar a todos los llamadores desde el inicio.
Desarrollar sobre BTX Flujos seguros para agentes
Construye APIs a las que los agentes tengan que demostrarse.
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
- solicitud de agente firmada
- se emite el sobre de desafío
- se resuelve trabajo fresco localmente
- 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
Por qué importa
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.
Admisión para inferencia de IA
Pon precio a la presión de bots y al abuso de inferencia con dificultad de desafío, en lugar de depender solo de cuotas, CAPTCHA o límites ciegos.
Verificación de agente a herramienta
Desafía al llamador, verifica la prueba de forma barata y combínala con solicitudes firmadas cuando los agentes necesiten acceso a herramientas, gateways o flujos operativos.
Resistencia a spam y registros abusivos
Usa desafíos de servicio BTX para comentarios, creación de cuentas y formularios públicos donde los CAPTCHA solo para humanos dan mala experiencia o son fáciles de subcontratar.
CAPTCHA para agentes IA
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.
Marca la ruta como desafiante
En el gateway, identifica rutas de inferencia, registro, búsqueda o herramientas cuyo costo y perfil de abuso justifican cotizar trabajo fresco antes de ejecutar.
Emite un sobre de desafío ligado a la cadena
Devuelve trabajo BTX indexado por propósito, recurso y sujeto en lugar de enviar al llamador a un flujo CAPTCHA solo para humanos.
Exige prueba junto con la solicitud
El cliente o agente resuelve localmente y luego envía la prueba junto con la llamada API original y cualquier material de identidad firmado que requieras.
Canjea antes de la acción costosa
Tu servidor verifica frescura, estado de repetición y contexto de dificultad antes de que comience la ejecución del modelo, el paso del flujo o la llamada privilegiada.
Flujo de desafío
Un ciclo práctico para desarrolladores, no una historia vaga del futuro.
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 relevante2
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 relevante3
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 relevante4
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# 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 Comparación de pila de admisión
BTX es la capa de trabajo e identidad, no toda la pila de autenticación.
La elección práctica no es entre "usar BTX" o "usar autenticación". Es cómo combinar la autenticación normal con una forma nativa de máquina de poner precio al abuso en las rutas que realmente importan.
Solo claves API
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.
CAPTCHA humano
Mejor en: Útil cuando quien llama es claramente una persona en un navegador.
Débil en: Mal encaje para agentes, herramientas, clientes automatizados y flujos que pueden externalizarse a granjas de CAPTCHA.
Lo que realmente aporta: Fricción humana, no admisión nativa para máquinas.
Desafío BTX + identidad firmada
Mejor en: Permite al llamador probar frescura, pagar un costo de abuso en computación y adjuntar material de firma más fuerte.
Débil en: Sigue necesitando autenticación normal y decisiones de política sobre cuenta, alcance y reglas de negocio.
Lo que realmente aporta: Trabajo fresco más identidad duradera de máquina.
Patrones de despliegue
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.
Gateway de inferencia IA
Las solicitudes de inferencia anónimas o de capa gratuita reciben el desafío antes de que el modelo arranque. El tráfico pagado conocido puede omitirlo o usar políticas más ligeras.
Acceso de agentes a herramientas
Antes de que un agente toque una herramienta sensible o un flujo operativo, exige tanto identidad firmada como trabajo fresco ligado a esa ruta o alcance.
Control de registros y spam
Comentarios, registros y formularios públicos pueden poner precio al abuso con computación en lugar de depender de granjas de CAPTCHA, muros SMS o balances permanentes.
Planos de control operativos
Las rutas administrativas de alto riesgo pueden exigir identidad de billetera post-cuántica más trabajo ligado a la cadena, haciendo más difícil el replay y el abuso subcontratado.
Arquitecturas de referencia
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
Gateway de agentes o herramientas
Binding recomendado
- purpose: api_gate
- resource: tool:calendar.write|route:/mcp/tools/calendar.write
- subject: wallet:agent-42 o device:devtok_abc123
Política del desafío
- target_solve_time_s: 1-2 segundos para llamadas interactivas; más alto en rutas privilegiadas
- expires_in_s: 30-120 segundos para mantener juntas la firma y el trabajo
- redeem path: usa redeemmatmulserviceproof para admisión solicitud por solicitud en el borde del gateway
Envío público anónimo
Binding recomendado
- purpose: rate_limit
- resource: signup:/v1/messages o comment:/v1/posts/:id
- subject: ip:203.0.113.0/24 o user:[email protected]
Política del desafío
- target_solve_time_s: 1-3 segundos para que usuarios honestos terminen mientras sube el costo del spam
- expires_in_s: 60-300 segundos y canje solo en el envío final
- redeem path: usa redeemmatmulserviceproof salvo que agrupes trabajos de moderación en cola
Preparación de producción
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.
Límite de confianza: BTX demuestra trabajo, no todo tu modelo de auth
BTX puede demostrar trabajo fresco ligado a la cadena y combinarse bien con identidad basada en wallet, pero no decide la autorización de negocio, la intención humana ni si una respuesta del modelo es correcta. Esos controles siguen en el gateway y en la capa de producto.
Nota de implementación: BTX es la capa de trabajo fresco, no toda la pila de políticas. Los despliegues multinodo siguen necesitando sticky routing o estado compartido de desafíos, y la autorización de negocio queda fuera de la prueba.
Patrón de gateway con alcances
BTX encaja junto a gateways que ya usan rol, alcance y confianza de dispositivo.
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.
El estado de handshake ya existe en gateways con alcances
El protocolo publicado de OpenClaw es un ejemplo: los clientes declaran rol y alcances durante el handshake WebSocket, un lugar natural para decidir si rutas posteriores deben exigir trabajo fresco.
La identidad y los tokens del dispositivo pueden permanecer intactos
En ese modelo, la identidad firmada del dispositivo, el emparejamiento y los tokens por dispositivo y rol permanecen intactos. BTX no reemplaza esa capa; la complementa cuando una ruta también necesita precio de trabajo antiabuso.
Nonce del servidor más desafío BTX es una pila limpia
Un gateway puede conservar su propio desafío de conexión y reglas de firma de solicitudes, y emitir trabajo BTX solo para la inferencia, herramienta o acción operativa costosa que sigue.
El resultado es una política que se siente nativa para agentes
Roles, alcances, confianza del dispositivo y trabajo fresco pueden evaluarse sin volver a un CAPTCHA humano o a un modelo de saldo prepago permanente.
# 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 Capa de identidad
Identidad respaldada por billetera que empieza siendo post-cuántica.
Diseño de billetera post-cuántica por defecto
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.
Explorar la fuenteFlujo de desafío anclado a dificultad en vivo
Los desafíos de servicio y los RPC de minería exponen perfiles de trabajo en vivo, ventanas objetivo de resolución y contexto fresco ligado a la cadena para poner precio al abuso.
Explorar la fuenteConstruido para servicios de coordinación de agentes
La documentación del protocolo ya posiciona a BTX por encima de una base de liquidación estrecha para puentes, servicios y capas de coordinación de agentes en lugar de un único runtime compartido.
Explorar la fuente Kit de lanzamiento para desarrolladores
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.
Vincular la identidad del llamador a material de billetera
Superpone trabajo BTX sobre identidad explícita para que admisión y firmas más fuertes evolucionen juntas.
Mapear BTX sobre la superficie del servicio
Cuando el bucle de desafíos funcione, conéctalo a las superficies RPC y de billetera que tu servicio ya opera.
Vigilar dificultad y condiciones del desafío
Expón coste del desafío y salud de la red como cualquier otra dependencia de producción para ajustar la protección sin adivinar.
Estándares y ecosistema
El resto de la pila ya se mueve hacia una identidad de agente y flujos de desafío más sólidos.
2024-08-13
NIST finaliza los primeros estándares PQC
BTX parte de la dirección hacia la que ya se mueve el mundo de estándares: firmas post-cuánticas y presión de migración ahora, no más tarde.
RFC 9421 / 9449Los estándares de solicitudes firmadas ya son lo bastante maduros
HTTP Message Signatures y DPoP ofrecen un marco sólido, cercano a estándares, para tráfico API autenticado y con prueba de posesión.
2025-03-26MCP lleva preocupaciones reales de auth y seguridad al tooling de agentes
Los sistemas agénticos ya necesitan autorización real, acceso por alcances y uso seguro de herramientas. BTX encaja como capa de trabajo e identidad alrededor de esos flujos.
OpenClawLos sistemas de agentes tipo gateway ya usan material firmado por dispositivo
La documentación de gateway de OpenClaw muestra tokens de dispositivo firmados y roles con alcance. BTX puede complementar eso con requisitos de trabajo fresco en rutas de alto riesgo.
2025-09-18NIST dice que las organizaciones deben empezar ya a planificar la migración PQC
El borrador CSWP 48 del NCCoE enmarca la transición PQC como un problema actual de gobierno y mapeo de controles, no como algo para aplazar hasta hitos posteriores.
FAQ para desarrolladores
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 Siguiente paso
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.