When someone swaps a digital asset, the screen may reduce the action to one button. Underneath, the operation may stay on one network or require value to reach another. They look like two versions of the same problem; operationally, they are different.

In Bennu’s swap architecture, 0x covers certain conversions on the same network, while Relay is used for selected cross-network routes and specific pairs. Routing depends on the pair, network and product availability rules. This describes an integration decision; it does not claim that every route is enabled or available at all times.

A route on one network

0x Swap API is an API for aggregating and routing EVM swap liquidity. A quote can return parameters and transaction data for the user’s wallet to review and sign. In some cases a token approval is needed; the approval contract and execution target should come from the current API response, not from a copied address.

For a product team, the work does not end when a price appears. The app must check the network and tokens, show the amount that can actually execute under the quote and slippage settings, handle approval when needed, then observe the transaction’s onchain result.

A route across networks

Relay provides an API for requesting quotes and executing steps on selected multichain routes. A response may contain more than one step, and the integration needs to follow the request to a terminal state. A quote does not prove that the origin transaction was sent, that the destination operation finished, or that the asset reached the expected wallet.

A route may not exist for a particular pair, exceed limits, lack liquidity or return a transient error. A destination failure and refund can also occur. The interface should explain the confirmed state and the next useful step instead of turning any initial response into “completed.”

What to compare before choosing

  • Desired outcome: are you swapping the asset on its current network, or does it also need to move to another network?
  • Pair eligibility: are the asset, network, amount and wallet supported for this specific route?
  • Total cost: what do the quote and its components show about the amount received, gas, provider charges and any app fee?
  • Proof of completion: which onchain receipt and API state confirm the result? What happens if the origin confirms while the destination is delayed or fails?
  • Recovery: how do you identify a refund, a pending operation and a failed operation without blindly resubmitting it?

The useful comparison is not “which provider is better.” It is whether the route can deliver the requested outcome with understandable costs, verifiable status and a recovery path the user can follow.

A product rule

I keep three things separate in the interface and backend: the quote, the submitted operation and verified settlement. If I merge them, a user may mistake a price for execution or silence for success. If I name them clearly, the product can say what it knows, acknowledge what it does not yet know and offer a safe action.

This describes the routing design documented in Bennu’s code as of 28 September 2026. Provider availability, supported pairs and conditions can change; the API and verified state of each operation are the reference for a specific route. In another article, I explain how to assign responsibility when one operation crosses several systems.

I am a co-founder of Bennu, so I have an interest in this topic. I am writing from a product and engineering perspective; this is not investment advice or sponsored or approved content from 0x or Relay.

Technical sources

Alex Sicart Ramos

Alex Sicart Ramos writes about product, software and cross-border systems. More about the author.