Al revisar el código de swaps de Bennu no intentaba ordenar proveedores. Quería responder una pregunta práctica de producto: ¿la operación se queda en una red o tiene que pasar a otra? La respuesta cambia qué cotización pedimos, qué firma solicita la cartera y qué podemos comprobar después.
En el código, 0x gestiona ciertas cotizaciones dentro de una misma red; el flujo de Bridge usa Relay solo para las rutas cuyos pares, redes de origen y destino y reglas de producto están admitidos. Es una decisión de enrutamiento que podemos revisar, no una promesa de que una ruta esté habilitada para toda persona o en todo momento.
Una ruta en una red
0x Swap API es una API de agregación y enrutamiento de liquidez para swaps EVM. Una cotización puede devolver parámetros y datos de transacción para que la cartera del usuario los revise y firme. En algunos casos hace falta una autorización de token; el contrato de autorización y el destino de ejecución deben salir de la respuesta actual de la API, no de una dirección copiada a mano.
En Bennu, el endpoint de cotización consulta 0x y devuelve los datos de transacción; el endpoint de ejecución prepara la transacción para que la cartera la revise y firme. La respuesta de cotización no es una transacción enviada. Después hay que contrastar el resultado en cadena. Esa separación es útil para la interfaz: “tengo una cotización” no debe acabar presentado como “el swap terminó”.
Una ruta entre redes
Relay puede devolver varios pasos para una ruta, y Bennu conserva esa secuencia en lugar de reducirla a una sola transacción. El servicio consulta además el estado del intent mediante la API de Relay. Para quien usa el producto, son dos comprobaciones distintas: los pasos que hay que ejecutar y el estado que confirma lo ocurrido después. Una cotización por sí sola no demuestra que el activo haya llegado a destino.
La ruta puede no existir para cierto par, superar límites, quedarse sin liquidez o devolver un error transitorio. También puede producirse un fallo en destino y una devolución. La interfaz debe explicar el estado confirmado y el siguiente paso útil, en vez de convertir cualquier respuesta inicial en un «completado».
Qué comparar antes de elegir
- Resultado que se quiere: ¿se cambia el activo en la red actual o también tiene que cambiar de red?
- Elegibilidad del par: ¿están admitidos el activo, la red, el tamaño y la cartera para esa ruta concreta?
- Coste total: ¿qué muestran la cotización y sus componentes sobre importe recibido, gas, cargos del proveedor y cualquier cargo de la aplicación?
- Prueba de finalización: ¿qué recibo en cadena y qué estado de la API confirman el resultado? ¿Qué ocurre si el origen se confirma y el destino se retrasa o falla?
- Recuperación: ¿cómo se identifican el reembolso, una operación pendiente y una operación fallida sin volver a enviarla a ciegas?
La comparación útil no es «qué proveedor es mejor». Es si la ruta resuelve el resultado pedido con un coste comprensible, un estado comprobable y una recuperación que el usuario puede entender.
Una regla de producto
Para un equipo fintech, la decisión solo sirve si deja un recorrido observable: una cotización que revisar, pasos que firmar y un estado que comprobar. Quiero que la interfaz dé al miembro y a operaciones la misma respuesta sobre lo que ha ocurrido y lo que aún no.
La distinción también importa fuera de los swaps. Bennu está pensado para empresas elegibles que reciben pagos internacionales EUR/SEPA y USD/SWIFT en cuentas a nombre de la compañía, con liquidación en autocustodia. Los depósitos de terceros y los rieles activos dependen del perfil y el corredor. Si encaja con tu trabajo, puedes solicitar acceso. El acceso y la disponibilidad están sujetos a elegibilidad, jurisdicción y revisión del proveedor.
Soy cofundador de Bennu y trabajo en este producto. Este artículo describe nuestra implementación, no un respaldo de 0x o Relay, y no es una recomendación de inversión.
