Subbit presenta un canal de pago en Cardano para la facturación de API basada en uso

Dominic Wallis presentó Subbit.xyz en la 77.ª edición de Cardano Developers Office Hours con un problema específico: una solicitud de API puede costar menos que la comisión y el tiempo requeridos para una transacción en la cadena de bloques. Su sistema empareja compromisos de pago firmados con un contrato inteligente de Cardano, lo que permite a un proveedor atender solicitudes pequeñas y cobrar los cargos autorizados más adelante. La presentación mostró cómo se comunican los componentes de pago, mientras que la integración con un servicio en producción sigue siendo el siguiente paso del proyecto.

Un canal de pago diseñado para servicios medidos

Subbit.xyz está diseñado para servicios que pueden medir lo que consume un cliente, como llamadas de API, transferencias de datos o solicitudes de IA. Las suscripciones mensuales cobran por un período de acceso, mientras que las facturas llegan después de que se ha producido el uso. Wallis propuso una conexión más estrecha entre cada unidad de servicio y el monto que el cliente autoriza.

Un cliente abre un canal depositando fondos bajo las reglas de un contrato inteligente de Cardano. Al solicitar el servicio, el cliente firma un IOU que indica el monto acumulado que el proveedor puede cobrar. El proveedor verifica la firma y los fondos que la respaldan antes de cumplir la solicitud. Cada IOU está vinculado a su canal, lo que evita que una firma destinada a una cuenta se reutilice contra otra.

El canal está limitado a dos participantes, con pagos que fluyen del cliente al proveedor. El cliente puede dejar de autorizar nuevos cargos, mientras que el proveedor mantiene una reclamación por el servicio ya entregado. El canal gobierna el pago; no verifica la calidad de una respuesta de API ni cómo el proveedor maneja información sensible.

Cómo funcionan las reclamaciones y el cierre del canal en Cardano

El proveedor puede presentar el IOU más reciente al contrato inteligente y reclamar el monto autorizado mientras el canal permanezca abierto. Las reclamaciones anteriores se contabilizan, por lo que el mismo monto no puede retirarse de nuevo. Si el cliente añade fondos, la relación puede continuar sin abrir un canal nuevo.

Wallis ilustró la configuración con 10 ADA asignados para el servicio y 2 ADA adicionales reservados para los requisitos UTxO de Cardano. El cliente puede cerrar el canal cuando quiera irse. El proveedor tiene entonces un período acordado al abrirlo para realizar una reclamación final, tras lo cual el cliente puede recuperar el saldo.

Los proveedores que atienden a muchos clientes pueden combinar reclamaciones en una sola transacción. Wallis mostró un ejemplo que contabilizaba 47 canales con un costo de aproximadamente 38 centavos estadounidenses. Esta era una cifra de su presentación, no un promedio reportado para tráfico en producción. Identificó la cantidad de datos de transacción como la limitación inmediata para ampliar tales lotes.

El diseño de la integración sitúa un emisor junto a la aplicación del cliente y un proxy delante del servicio existente del proveedor. El emisor adjunta un IOU a una solicitud. El proxy lo verifica y reenvía una solicitud aceptada al servicio.

Los proveedores todavía tendrían que operar estos componentes de pago y seguir la actividad relevante del canal en Cardano, incluso si su aplicación original no implementa lógica de cadena de bloques.

La prueba pendiente es una integración real con un servicio

Las preguntas de los participantes expusieron varios límites del modelo. Los reembolsos requieren un pago por separado porque el canal mueve fondos en una sola dirección. Un proveedor preocupado por cambios en el precio del activo puede reclamar fondos con prontitud o revisar los precios para solicitudes futuras. Wallis también demostró que un canal puede usar otro activo y mencionó USDM como ejemplo.

Las reclamaciones liquidadas en Cardano revelan los montos cobrados, aunque las solicitudes individuales de servicio permanecen fuera de la cadena. Los participantes preguntaron si las pruebas de conocimiento cero podrían mejorar la privacidad o el procesamiento por lotes. Wallis sostuvo que tal diseño agregaría complejidad y que el tamaño de los datos de transacción es el problema de escalado más inmediato para Subbit.xyz.

Otro participante, David, presionó a Wallis sobre la demanda: qué proveedor cambiaría su sistema de facturación para usar el canal. Wallis habló de posibles usos en infraestructura de API, facturación de IA y entrega de datos medidos. Describió trabajos anteriores con Orcfax y reconoció el apoyo de Project Catalyst, pero no presentó un integrador en producción actual ni cifras de uso comercial.

En la demostración de cierre, el emisor y el servidor intercambiaron datos de pago, pero el servicio subyacente no se ejecutó. Wallis invitó a los proveedores a integrar Subbit.xyz. Eso permitiría que la próxima demostración conecte las tres partes de la transacción: una respuesta de servicio medida, el IOU firmado del cliente y la reclamación del proveedor en Cardano.