Event Replay: Arcshop- Introducing Bridge Kit

Intro and guests

Sam (Host): Hey, everybody. We’re very excited here for another livestream. We’ve got Dave Musikant, Senior Director of Engineering at Circle, and Tobias Gobbs. Today we’re talking about Circle Bridge Kit, one of the most popular tools we’ve been seeing from the community.

Dave, quick intro.

Dave Musikant: Great to meet everyone. I’m Dave Musikant, Senior Director of Engineering at Circle, leading the Stablecoin Solutions Group. Bridge Kit is something we worked on for a while, and we’re excited about what we’re doing with it.

Sam: Tobias?

Tobias Gobbs: I’m Tobias Gobbs, Engineering Manager at Circle. I led the team building Bridge Kit. We’re excited to get feedback because it took a while to build, and now we want to show it to the world.

---

Dave: design goals and architecture

Dave: I’ll give a quick overview of the developer experience principles and the architecture, then Tobias will do a live demo.

Developer experience principles

• Abstract away the hard parts with sane defaults, but include escape hatches when you need low-level control.

• Reduce fragmentation across:

  • Chains (EVM vs non-EVM)
  • Wallet providers
  • Frameworks (viem, ethers, etc.)

• Meet developers where they are: don’t force a full stack rebuild; plug into existing tooling.

• Pluggability: don’t lock developers into one choice.

A core principle: easy to use correctly and hard to use incorrectly.

Architecture overview

There’s a lot of fragmentation. Implementing CCTP directly across multiple chains can be a lot of code.

Bridge Kit tackles two main fragmentation areas:

1. Chain adapters

• Framework-based adapters for EVM chains (e.g., viem and ethers).
• Non-EVM adapters (e.g., Solana).
• You interact with adapters the same way, so code doesn’t need to change when switching chains.

2. Wallet provider adapters

• Allows swapping wallet backends (e.g., Circle Wallets, Fireblocks, Privy, browser wallets) without rewriting the rest of your code.
• Wallet adapters can behave like “interfaces into chains,” just like chain adapters.

3. Pluggable providers

• Providers are “capability providers.” Example: a CCTP v2 bridging provider.
• Circle can add more providers, and developers can implement their own providers and plug them in.
• The kit orchestrates providers and uses adapters to execute onchain operations.

---

Tobias: live demo (EVM ↔ EVM)

Tobias: I’ll walk through a demo. I’ve installed Bridge Kit and the viem v2 adapter.

I instantiate the adapter (here with a private key from environment variables). Then I create the kit, add an event listener to log progress, and call bridge().

Under the hood, for CCTP, the flow is:

1. Approve token allowance
2. Burn USDC via Token Messenger
3. Fetch attestation from the offchain attestation service
4. Mint USDC on the destination chain

Tobias (running code):

• Approve succeeded
• Burn succeeded
• Attestation received
• Mint succeeded

Because this is a fast transfer, a small USDC fee is taken, and the destination receives slightly less than 1 USDC.

---

Tobias: switching to Solana (EVM ↔ Solana)

Tobias: Now I’ll show cross-ecosystem bridging. I bring in the Solana adapter (already installed), instantiate it with a Solana private key, then switch the sourceAdapter / destinationAdapter in the same bridge() call and set the destination chain to Solana.

That’s basically it: add adapter, configure it, drop it into the same bridge call. The adapter abstracts Solana specifics.

Tobias (running code):

• Approve
• Burn
• Attestation
• Mint on Solana successful

Result: bridged from an EVM chain to Solana with minimal changes.

---

Tobias: wallet provider adapter (Circle Wallets)

Tobias: Bridge Kit also supports wallet provider adapters. For example, there’s a Circle Wallets adapter. I can configure it with an API key and entity secret.

One difference: with some wallet providers you can control multiple wallets on multiple chains simultaneously, so the kit may require explicit source and destination addresses.

Tobias: You can also mix adapters: Circle Wallets on one side, Solana on the other, or custom adapters like Fireblocks.

---

Reliability: retry / resume

Tobias: Bridge Kit also exposes a retry method. If something fails mid-flow (network blip, gas issues, etc.), you can resume from the last known state instead of rebuilding the bridging logic manually.

---

Feature: native fee taking

Tobias: Another feature is fee taking. You can configure an extra fee amount. At burn time, the kit takes the fee from the user (in the same asset), splits it 90/10:

• 10% to Circle (platform fee)
• 90% to the developer recipient address

Then the main transfer proceeds through CCTP.

Tobias (after running): In the burn transaction you can see:

• The total pulled from the user
• The split to fee wallets
• The remainder forwarded into the Token Messenger for bridging

---

Q&A and clarifications

Sam: A question came up: is it still burn-and-mint?

Tim (“Silence” in chat): Yes. Burn-and-mint happens via CCTP, but Bridge Kit abstracts it.

Sam: Fee taking works across supported chains; kit contracts handle logic. Also: kit contracts are audited twice by third-party auditors (as noted in chat).

Dave: Some chains can be slower depending on finality. The kit won’t time out; it can run end-to-end, and also supports restarting from intermediate state.

Tobias: Security-wise: Bridge Kit doesn’t add extra trust assumptions on top of CCTP. It’s orchestrating standard smart contract calls and attestations; the kit is “glue” to avoid everyone re-implementing bridging.

Dave: Bridge Kit currently supports CCTP v2. CCTP v1 is deprecated, so the kit focuses on v2.

Dave (open source question): Not open source yet. Under discussion. However, the system is pluggable: developers can build and publish their own adapters and providers compatible with the kit.

Dave (Aleo / USDCX): There are plans to add support related to USDCX.

Dave (EURC): Not supported today; it’s being discussed. Feedback helps prioritize.

Tobias (other tokens): Out of the box, it’s USDC via CCTP v2. Developers can implement additional providers for other tokens if they want.

Dave (Stellar): Solana is supported. Stellar is not supported by the kit today because it’s built around CCTP v2 support.

---

Closing

Sam: We’ll post links to the docs and quick start. Join the Discords (Build on Circle / Build on ARC) to keep the conversation going. We’ll likely schedule a Discord AMA after folks try the kit and come back with questions.

Dave: We want feedback. Tell us what you’re building and what support you need.

Tobias: We’re developers too. The goal is to make bridging something you don’t have to re-implement from scratch.

Sam: Thanks everyone. See you in Discord.