The Khalani chapter: how we wired Khalani into Nexus bridge
We worked with Khalani to plug its intent network into Hyperlane’s Nexus bridge, so users can bridge supported tokens and chains with one simple flow.
Why this matters
Cross-chain UX still feels like switching trains mid-journey. People just want to move value or call an app on another chain without juggling bridges, gas, or mental models. Hyperlane’s Nexus brings many ecosystems under a single interface so users can transfer tokens between Hyperlane or IBC integrated chains from one place. That is a big step toward practical interop for real users.
Khalani focuses on intent-driven transactions. You define the outcome and bounds, then its solver network handles pathfinding, routing, gas, and settlement. That model fits cross-chain flows well because it hides execution details while keeping strong guarantees on the result.
What we built
Khalani asked us to extend the Nexus bridge so when a user needs to bridge a Khalani supported token or chain, Nexus can use Khalani’s infrastructure behind the scenes. Our goal was simple: keep the familiar Nexus UI, but give it a new route where it makes sense. We shipped the integration with a strong bias for compatibility and low risk.
On Hyperlane's side we worked with the Warp Route UI template and SDK, validating configs against the canonical registry and adapting the UI where needed. On Khalani's side we ensured the route selection could defer to Khalani for supported pairs without breaking existing paths. We also recommended a light-SDK design so the integration could be upstreamed cleanly and made repeatable for future networks. The approach helps Khalani stay in sync with new chains added to Hyperlane and to the Nexus interface.
How it works today
- A user opens Nexus and selects a source chain, destination chain, and token. If the pair is supported by Khalani, the UI can present that path as a normal option. Users do not need to change how they bridge.
- When the user confirms, Nexus invokes the configured route. Hyperlane handles message passing and token routing. When Khalani is selected, its infrastructure covers routing and execution while preserving outcome bounds.
- Settlement and state updates return through Hyperlane’s standard flows. From the user’s point of view it is just a bridge transaction that completes as usual.
This keeps the UI stable while letting the infra evolve. If you are curious about defaults and security assumptions around Nexus, L2BEAT has a good explainer.
How we approached safety and compatibility
Bridges live at the sharp end of risk. Two rules guided us: do not surprise users, and change as little as possible in the security stack. We also kept flows the same and showed route provenance. Hyperlane’s ISMs are modular, so routes can pick a custom ISM when needed. We respect defaults and allow overrides where Khalani or a destination chain requires them.
We also audited configuration boundaries. Route definitions must agree on token metadata, decimals, and router addresses across chains. Mismatches in these areas create the most common class of integration bugs. We codified checks in CI so contributors see errors before anything reaches a user.
Route selection and fallbacks
Nexus already aggregates multiple token routes. The Khalani path is just one more option where it adds value. The UI can surface this path exactly like any other route. If a given token or chain is not supported by Khalani, Nexus uses the existing Hyperlane route. This keeps the experience predictable and reduces edge cases. It also means we can roll out support incrementally without blocking unrelated flows.
On the execution side, Khalani provides outcome bounds and a solver network that handles the hard parts: finding liquidity, paying gas, and assembling a safe path. If those bounds cannot be met inside the configured constraints, the transfer does not proceed. Users keep custody unless guarantees are satisfied. That is the right failure mode for cross-chain UX.
What developers can reuse
You can reproduce this pattern for other networks. Start from the Warp Route UI template, wire your registry, and keep configs in version control. When you need a new route, add it behind a simple capability check so the UI presents it only when it actually works. Keep observability uniform across routes so user support does not fragment.
If you are integrating Khalani specifically, the light-SDK approach keeps the interface narrow between Nexus code and Khalani services.
Why BootNode
We have shipped bridges, explorers, and interop tooling for years and contributed upstream to Hyperlane. That history speeds up discovery, reduces risk, and shortens delivery. The Khalani team highlighted the same points when they talked about our work together, including our push for a light-SDK to raise the odds of official support and to simplify future integrations.
If you are exploring intent UX or multi-chain onboarding and want to wire Khalani into your bridge or app, reach out. We can help scope it and ship it with a clean path to upstream.
