For developers building on Circle products, post Q&A, best practices & SDK/API insights. Use Tags

Circle Products & Developer Toolings

If you've read my previous posts here on CCTP internals and App Kit's SDK architecture, those covered the protocol theory and the developer toolkit. This post is what happened when we put it all together and shipped.

XyloBridge now supports 20 chains with single-signature bridging. You sign once on the source chain. USDC arrives on the destination. No second transaction. No gas on the other side. No claiming step.

This post covers exactly what we built, how the Forwarding Service works at the implementation level, the edge cases we handle, and why it matters for anyone building cross-chain applications on Arc.

We migrated XyloBridge to Circle's App Kit with the Forwarding Service enabled. The user-facing result is that bridging went from a multi-step, multi-signature process to a single click.

  - Approving USDC spending (signature 1)

  - Calling depositForBurn on the source chain (signature 2)

  - Submitting receiveMessage on the destination chain (signature 3)

  - Having native gas tokens on the destination chain to execute that final transaction

That's it. One signature. Everything else is handled by Circle's Orbit relayer network through the Forwarding Service.

HOW THE FORWARDING SERVICE WORKS IN PRACTICE

When we enable useForwarder in the bridge destination config, App Kit doesn't just submit a standard CCTP burn. It embeds forwarding instructions directly into the CCTP message during the burn transaction on the source chain.

Here's what happens after the user signs:

1. The source chain contract burns the user's USDC and emits a message with embedded forwarding metadata

2. Circle's attestation service detects the burn event and signs the attestation

3. Circle's Orbit relayer picks up the signed attestation

4. The relayer submits the receiveMessage transaction on the destination chain - paying gas from its own funds

5. Native USDC is minted directly to the user's wallet on the destination chain

6. A small relay fee (~$0.20 USDC) is deducted from the minted amount

The user never interacts with the destination chain. They don't need to have ever used that chain before. They don't need native gas there. They sign once on the source side and the system handles delivery.

This is a first-party Circle service - same trust model as USDC itself. No third-party relayers. No additional bridge risk.

XyloBridge currently supports bridging across all of these:

Every chain identifier is mapped against Circle's BridgeChain enum from the SDK type definitions. The enum uses specific naming  Optimism_Sepolia (not OP_Sepolia), Polygon_Amoy_Testnet (not Polygon_PoS_Amoy), Edge_Testnet (not EDGE_Testnet). App Kit validates these strictly. A single character mismatch and the SDK rejects the call.

HANDLING CHAINS WITHOUT FORWARDING SUPPORT

Not every chain supports the Forwarding Service yet. The support status is defined per-chain in Circle's SDK as a forwarderSupported property with separate source and destination booleans.

Morph Testnet currently has forwarderSupported set to false for both source and destination. If you pass useForwarder: true with Morph as the destination, the SDK returns INPUT_UNSUPPORTED_ROUTE.

We handle this with a conditional approach. We maintain a set of chains where forwarding isn't available as a destination. Before constructing the bridge call, we check if the selected destination is in that set. If it is, we omit the useForwarder parameter entirely and fall back to standard CCTP mode.

The UI reflects this dynamically. If you select Morph Testnet as your destination, the interface tells you upfront that this will be a multi-step bridge. For all other chains, it shows "Single-Sign" with the explanation that Circle handles delivery automatically.

No failed transactions. No confusing error messages. The user knows exactly what to expect before they commit.

L2 chains like Arbitrum and Optimism have a gas pricing characteristic worth understanding: the base fee can increase between the moment you estimate gas and the moment your transaction is included in a block.

The default behavior in viem applies a 1.2x multiplier on top of the current base fee. On L1 Ethereum that's usually fine. On L2s where base fees can tick up faster due to sequencer behavior, a 1.2x buffer isn't always enough.

We configured a 1.5x baseFeeMultiplier globally across all chains in our public client setup. This gives enough headroom for L2 fee volatility without overpaying on L1 chains (because you only pay the actual base fee regardless of your max). The result is reliable transaction execution across all 20 chains.

The bridge flow in XyloBridge works like this:

1. User connects their wallet via wagmi/RainbowKit

2. We create a viem adapter from their EIP-1193 provider using createViemAdapterFromProvider from @circle-fin/adapter-viem-v2

3. In the adapter config, we provide a getPublicClient callback that returns chain-specific public clients with custom RPC endpoints and the 1.5x baseFeeMultiplier

4. We instantiate the App Kit via createAppKit() from @circle-fin/app-kit

5. When the user clicks Bridge, we call kit.bridge() with:

   - from: { adapter, chain: sourceChainId }

XyloBridge V2: Single-Sign USDC Bridging Across 20 Chains - How We Built It

Home

Forum

Events

Content

Courses

People

Contributors

Albums

Groups

Chat

Channels

Not being used

Help

Join the global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make the economy work for everyone.

Arc House

Profession

Join a global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make that economy work for everyone. 

Arc House | Build the economic OS for the internet with us

Copyright

Terms of Service

Privacy

Code of Conduct

Your Privacy Choices

It looks like there is no account associated with the email you provided. The event is for members only. Please complete the application to join our community first.

Thank you for your interest in joining us

Thanks for your interest in joining the event. However, your account is still pending. Once it's approved, you'll be able to register for the event. Please contact us via noreply@arc.network if you need support.

Pending Approval

Login to the The Arc Community Hub community to connect with others, attend community events, and more!

Login or Sign Up for even more

To unlock all parts of the community complete your profile using verifiable and real information.

Hey, complete your profile

It looks like there is no account associated with the email you provided. Please complete the application to join our community.

Thank you for your interest in joining Arc House.

Thanks for your interest in joining Arc House. We will review your request shortly and email you once it's approved. Meanwhile, please feel free to contact us via noreply@arc.network for any questions.

Accounts are unapproved when profile information cannot be verified or when activity patterns indicate spam, inorganic participation, or behavior that undermines trust in the program.

To strengthen your profile for future consideration, sign in with a verified LinkedIn account, use real and current profile information, and participate constructively in other community spaces.

Commercial customers should raise concerns through their support channel.

https://www.arc.network/community-guidelines