Cuando alguien cambia un activo digital, la pantalla puede resumir la acción en un botón. Por debajo, la operación puede quedarse en una red o requerir que el valor llegue a otra. Parecen dos versiones del mismo problema; operativamente, no lo son.

En la arquitectura de swaps de Bennu, 0x cubre ciertas conversiones en la misma red y Relay se usa para determinadas rutas con cambio de red y pares específicos. Ese enrutamiento depende del par, la red y las reglas de disponibilidad del producto. Describe una decisión de integración, no una afirmación de que cada ruta esté abierta o disponible en cada 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.

Para quien construye el producto, el trabajo no acaba al mostrar un precio. Hay que comprobar la red y los tokens, presentar el importe que realmente se ejecutará según la cotización y el deslizamiento, gestionar la autorización cuando corresponda y observar después el resultado de la transacción en cadena.

Una ruta entre redes

Relay proporciona una API para solicitar cotizaciones y ejecutar pasos de determinadas rutas multired. La respuesta puede contener más de un paso y la integración debe seguir el estado de la solicitud hasta un resultado terminal. Una cotización no demuestra que la transacción de origen se haya enviado, que la operación de destino haya terminado o que el activo haya llegado a la cartera esperada.

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

Separo tres cosas en la pantalla y en el backend: la cotización, la operación enviada y la liquidación verificada. Si las mezclo, el usuario puede pensar que un precio es una ejecución o que el silencio significa éxito. Si las nombro bien, el producto puede explicar lo que sabe, reconocer lo que todavía no sabe y ofrecer una acción segura.

Esta descripción refleja el diseño de enrutamiento documentado en el código de Bennu a 28 de septiembre de 2026. La disponibilidad de un proveedor, los pares admitidos y las condiciones pueden cambiar; la API y el estado verificado de cada operación son la referencia para una ruta concreta. En otra pieza explico cómo repartir responsabilidades cuando una operación atraviesa varios sistemas.

Soy cofundador de Bennu y, por tanto, tengo interés en el tema. Escribo desde la perspectiva de producto e ingeniería; esta explicación no es una recomendación de inversión ni contenido patrocinado o aprobado por 0x o Relay.

Fuentes técnicas

Alex Sicart Ramos

Alex Sicart Ramos escribe sobre producto, software y sistemas transfronterizos. Más sobre el autor.