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

Circle Products & Developer Toolings

If you've built a cross-chain bridge from scratch, you know the pain. You're managing contract addresses for every chain. You're encoding calldata for depositForBurn. You're polling Circle's attestation API with retry logic and backoff timers. You're estimating gas on two different chains. You're handling partial failures where the burn succeeds but the mint doesn't. And you're writing all of this separately for every chain pair you want to support.

I know because I did it. XyloNet's bridge started as a raw CCTP integration - custom contracts, manual attestation polling, the whole thing. Then I rebuilt it with App Kit. The core bridge logic went from roughly 200 lines of contract interaction code down to 6.

This post breaks down what App Kit actually is, what's inside it, and how each piece works. Whether you're evaluating it for a project or just want to understand what Circle built for developers on Arc, this should give you the full picture.

App Kit is a suite of TypeScript SDKs published by Circle under the @circle-fin npm scope. It gives you three things: the ability to bridge tokens across chains, swap tokens on the same chain, and send tokens between wallets. Each of these is a single async function call.

It's free. It's permissionless. You don't need Circle's approval to use it. Install the package, create an adapter for your wallet type, and call the method. That's it.

Under the hood, App Kit is built on top of three pieces of Circle infrastructure: USDC (the stablecoin), CCTP (the Cross-Chain Transfer Protocol that handles the actual burn-and-mint bridging), and Circle Wallets (developer-controlled custodial wallets for server-side applications). If you read my previous post on CCTP, App Kit is essentially the developer-friendly layer that sits on top of everything I described there.

The SDK supports chains across both mainnet and testnet environments. Arc is currently live on testnet - that's where XyloNet and most Arc builders are operating today. But App Kit isn't Arc-exclusive. You can bridge between Ethereum and Solana, swap on Base, or send on Polygon - all through the same interface.

Every interaction with App Kit starts the same way: you create a kit instance and call one of three methods.

 - moves USDC across blockchains. This is the one most builders will use first. You call kit.bridge() with four pieces of information:

  - A source chain and adapter (e.g. Ethereum Sepolia with a viem adapter)

  - A destination chain and recipient address (e.g. Arc Testnet)

  - The amount of USDC to move (e.g. 100.00)

  - An optional transfer speed configuration (FAST or SLOW)

App Kit handles the entire CCTP flow behind the scenes: token approval, burn on the source chain, attestation polling, and mint on the destination chain. One function call replaces what would normally be four separate contract interactions plus attestation API polling.

 - exchanges one token for another on the same chain. You specify the chain, the input token, the output token, and the amount. App Kit handles routing, slippage, and execution. This is the only capability that requires a Kit Key - it's free and takes about 30 seconds to generate from the Circle Developer Console.

 - transfers tokens between wallets on the same blockchain. You specify the chain, the recipient address, the amount, and the token. This supports any token - USDC, EURC, USDT, DAI, PYUSD, native tokens, or any custom token by contract address.

Each capability also has an estimate method - estimateBridge, estimateSwap, estimateSend - that previews gas costs and fees without executing the transaction. Build your confirmation screens with real numbers before the user commits.

This is the design decision that makes App Kit work across ecosystems.

Different blockchains use different signing mechanisms. EVM chains use one pattern, Solana uses another, and Circle's developer-controlled wallets use an API-based approach. Instead of forcing developers to handle these differences, App Kit abstracts wallet interactions behind an adapter interface. You pick the adapter that matches your wallet type, and the SDK handles the rest.

Viem Adapter (@circle-fin/adapter-viem-v2) - for browser wallets and viem-based applications. This is what most frontend developers will use. You pass in an EIP-1193 provider (the thing MetaMask or RainbowKit gives you) and optionally override the public client per chain for custom RPCs.

Ethers Adapter (@circle-fin/adapter-ethers-v6) - for ethers.js v6 applications. Same capability, different library.

Solana Adapter (@circle-fin/adapter-solana-kit) - for Solana wallets. Required when one side of a bridge involves Solana.

Circle Wallets Adapter (@circle-fin/adapter-circle-wallets) - for server-side applications using Circle's developer-controlled wallets. This one requires a Circle API key and entity secret. Server-side only.

The key insight: for cross-ecosystem bridges (like EVM to Solana), you use two different adapters -- one for the source chain and one for the destination. App Kit handles the translation between them.

FAST VS SLOW: CHOOSING YOUR TRANSFER SPEED

App Kit exposes two transfer speed modes for bridging, and understanding the tradeoff matters for your application design.

FAST mode uses Circle's Orbit relayer. Settlement typically completes in 8 to 20 seconds. The user's USDC arrives on the destination chain almost immediately. The tradeoff is a small fee, and the SDK lets you cap it with the maxFee parameter. If the live fee exceeds your cap, the transfer automatically falls back to slow mode instead of failing. Your user's money stays safe either way.

SLOW mode is standard CCTP finality. It takes 13 to 19 minutes because it waits for full block confirmations on the source chain before Circle signs the attestation. Some chains with instant finality (like Avalanche or Polygon PoS) complete standard transfers in about 8 seconds. The benefit is zero cost - no fee at all. For applications where speed doesn't directly impact user experience - payroll, treasury operations, scheduled settlements - slow mode saves money on every transfer.

At XyloNet, we use FAST for every bridge operation. Our users are moving USDC interactively, and waiting 13+ minutes for a bridge to complete is not acceptable UX. But if I were building a backend settlement system, I'd use SLOW mode for every transfer and save on fees.

This is the feature that changes the developer experience the most, and it's worth understanding even if you don't use it immediately.

In a standard CCTP transfer, someone has to submit the receiveMessage transaction on the destination chain. That means your application (or your user) needs gas on the destination chain, needs to poll for the attestation, and needs to handle the mint transaction. It's manageable, but it's extra infrastructure.

The Forwarding Service eliminates all of that. At the protocol level, it works by embedding forwarding instructions in the CCTP message during the source-chain burn. But with App Kit, you just enable it in the bridge configuration. Circle's infrastructure then handles everything on the destination side automatically. It validates the burn, signs the attestation, and broadcasts the mint transaction. No destination-side wallet needed. No destination gas needed. The fee is deducted directly from the USDC minted on arrival.

For the user, this means they sign one transaction on the source chain and USDC appears on the destination chain without any further action. For the developer, it means you don't need to build or maintain any destination-side infrastructure.

This is a first-party Circle service. No third-party relayers, no additional trust assumptions beyond Circle itself (which you're already trusting by using USDC).

REAL INTEGRATION: HOW XYLONET USES APP KIT

I'm going to walk through exactly how XyloNet integrates App Kit, because reading real production decisions is more useful than reading documentation.

Our entire bridge runs through a single React component - BridgeWidget.tsx. It imports two things from App Kit: BridgeKit from the @circle-fin/bridge-kit package and createAdapterFromProvider from @circle-fin/adapter-viem-v2. That's every App Kit import in the entire XyloNet codebase.

 We override the default public client with custom RPC URLs for every chain, plus fallback transports for unreliable ones. Base Sepolia, Arbitrum Sepolia, and Ethereum Sepolia each have a fallback RPC that kicks in if the primary fails. This is critical for testnet reliability - public RPCs go down more often than you'd expect.

 Bridge Kit emits events for every step of the transfer: approve, burn, fetchAttestation, mint. We use the wildcard listener to capture all of them and update the UI in real-time. The user sees exactly which step they're on and gets a transaction hash as soon as each step completes.

App Kits: What's Inside the SDK That Turns 200 Lines of Bridge Code into 6

Home

Forum

Events

Content

Courses

People

Contributors

Albums

Groups

Chat

Channels

Arc Apps

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

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.