One swap button. Two different routes.

When I reviewed Bennu’s swap code, I wasn’t trying to rank providers. I wanted to answer a practical product question: does this request stay on one network, or does it need to cross to another? That choice changes which quote we request, what the wallet is asked to sign and what we can verify afterwards.

In the code, 0x handles certain same-network quotes; the Bridge flow uses Relay only for routes whose pair, source and destination networks, and product rules are supported. That is a routing decision we can inspect, not a promise that either route is enabled for every member or at every moment.

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.

In Bennu, the quote endpoint calls 0x and returns transaction data; the execution endpoint prepares the transaction for the wallet to review and sign. A quote response is not a submitted transaction. The onchain result still needs to be checked afterwards. That separation helps the interface: “I have a quote” should never be shown as “the swap is done.”

A route across networks

Relay can return several steps for a route, and Bennu keeps that sequence instead of flattening it into one transaction. The service also checks the intent status through Relay’s API. For the product, these are two separate checks: the steps to execute and the status that confirms what happened afterwards. A quote alone does not prove the asset reached its destination.

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

For a fintech team, the decision is useful only if it leaves an observable path: a quote to review, steps to sign and a status to verify. I want the interface to give members and operations the same answer about what has happened—and what has not.

The distinction matters beyond swaps. Bennu is built for eligible companies receiving international EUR/SEPA and USD/SWIFT payments to company-named accounts, with settlement to self-custody. Third-party deposits and active rails depend on the profile and corridor. If that fits your work, you can request access. Access and service availability are subject to eligibility, jurisdiction and provider review.

I am a co-founder of Bennu and work on this product. This article describes our implementation, not an endorsement by 0x or Relay, and it is not investment advice.

Technical sources

• Official 0x documentation: Swap API flow.
• Official 0x documentation: Swap API v2 changes and contracts and allowances.
• Official Relay documentation, including its quote error guide and intent status endpoint.