We have dozens of bridge protocols that can move assets safely across chains. But what we don’t have is a way to use them without becoming a bridge expert first.

Orbiter fixes this. Instead of choosing bridges and coordinating multi-step workflows manually, you describe what you want to happen, and Orbiter handles the execution for you. Users don’t even need to know what a bridge is. They simply specify their end goal, and Orbiter figures out the optimal path.

What Orbiter Does

Orbiter turns complex cross-chain workflows into single transactions. Here are some use cases:

• Cross-chain swaps: A user with USDC on Base wants USDN on Hyperliquid. User sends the USDC to Orbiter on Noble, Orbiter swaps it for USDN, then forwards it to Hyperliquid via Hyperlane, all in one transaction for the user.

• Seamless fiat offramps: A user wants to convert their USDN on Noble to cash via Coinbase. They send USDN to Orbiter on Noble, which forwards it to Base via CCTP. The user can then deposit directly to their Coinbase account for instant fiat withdrawal.

• Multi-bridge routing: Connect chains that don't have direct bridge connections. For example, transfer from Arbitrum to dYdX by routing through Noble using CCTP to arrive and IBC to forward.

• Unified fee collection: IBC relayer operators can collect fees on a single Noble address instead of managing wallets and inventory across dozens of different networks.

How Orbiter Works

Orbiter operates as a middleware on Noble, receiving cross-chain transfers with embedded instructions, executing custom actions, and then forwarding tokens via a bridge protocol to their final destination.

The execution flow looks as follows:

1. Token transfer is received on Noble with payload instructions.

2. Orbiter executes any actions that leverage Noble’s core functionality, like fee payments or swaps.

3. Tokens are forwarded to the final destination based on the specified bridge protocol (IBC, CCTP, Hyperlane), with optional passthrough instructions.

The Orbiter module uses four main components:

• Adapter: Parses incoming packets from any bridge protocol.

• Executor: Handles pre-forwarding actions like fees or swaps.

• Forwarder: Routes to the optimal bridge protocol.

• Dispatcher: Orchestrates the entire flow.

Every Orbiter transaction contains instructions for what should happen. For example:

 {
    "pre_actions": [
      {
        "id": "fee_payment",
        "attributes": {
          "fees_info": [
            {"recipient": "noble1...", "basis_points": 42}
          ]
        }
      }
    ],
    "forwarding": {
      "protocol_id": "cctp",
      "attributes": {
        "destination_domain": 2,
        "mint_recipient": "0x..."
      }
    }
  }

The Roadmap: Gradual Expansion

Orbiter was introduced in the v11 Flux release and in its current iteration supports incoming transfers via IBC and outgoing via CCTP. This means you can send assets from any IBC-supported network to Noble and automatically forward to CCTP-connected networks such as Ethereum, Arbitrum, Polygon, among others. Hyperlane support is disabled in v11, but will be enabled in an upcoming minor release.

Fee payment actions are enabled from the start, enabling automatic fee collection and distribution during transfers.

Additional features will be introduced incrementally. An upcoming major version will include:

• CCTP and Hyperlane inbound adapters (complementing existing IBC inbound)

• IBC outbound forwarding

• Swap actions

```table
| Protocol and Actions | v11.0.0 | Future minor version | Future major version |
|---|---|---|---|
| IBC         | [[Only incoming|warn]] | [[Only incoming|warn]] | [[Incoming and outgoing|good]] |
| CCTP        | [[Only outgoing|warn]] | [[Only outgoing|warn]] | [[Incoming and outgoing|good]] |
| Hyperlane   | [[Disabled|bad]]       | [[Only outgoing|warn]] | [[Incoming and outgoing|good]] |
| Fee payments| [[Supported|good]]     | [[Supported|good]]     | [[Supported|good]] |
| Swaps       | [[Not supported|bad]]  | [[Not supported|bad]]  | [[Supported|good]] |
```

Integration

Integrating Orbiter into your application entails constructing a payload with your desired actions and destination, then sending tokens to the Orbiter module with the payload in the memo field (for the initial use case of IBC inbound transfers). Orbiter handles the rest.

For a detailed integration guide, code examples, and API information, please refer to the Orbiter documentation.

Conclusion

Cross-chain infrastructure has evolved from unsafe bridges to mature protocols like CCTP, IBC, and Hyperlane. But the UX still requires manual coordination across multiple interfaces and protocols.

Orbiter handles this coordination automatically. Instead of forcing users to become bridge experts, they can simply achieve their end goal without needing to even know what bridges are. Users get one-click operations and developers get powerful composability primitives, all while maintaining the security and reliability of underlying bridge protocols.

Ready to build with Orbiter? Check out our Orbiter documentation to learn how to integrate it into your product.