Auto CCTP

The Most Requested Feature By Existing Customers

Comment

Inspiration

Cross-Chain Transfer Protocol (CCTP) by Circle enables secure USDC transfers across blockchains, but it traditionally requires two separate transactions if you're bridging out of cosmos chains: one to bridge from the source chain to Noble (USDC's native Cosmos chain), and another to complete the CCTP burn-and-mint to the final destination. This creates friction for users and limits the protocol's potential. There is now an an opportunity to leverage Noble's new Orbiter module to enable single-transaction USDC transfers from any Cosmos chain to any CCTP-supported destination, dramatically improving the user experience. This was planned as a feature and designed out, and scoped at about 9 FTE days, and now has been implemented locally at this Hackathon.

What it does

Auto CCTP enables users to transfer USDC from Cosmos chains (like Osmosis or Cosmos Hub) directly to EVM chains (like Base, Ethereum, or Arbitrum) in a single transaction. Instead of requiring users to manually bridge to Noble first and then execute a CCTP transfer, our implementation:

  1. Automatically routes USDC through Noble's Orbiter module using IBC with a specially crafted memo
  2. Handles fee payments for relayers using basis points calculated from the transfer amount
  3. Tracks the complete lifecycle across multiple chains and protocols (IBC + CCTP)
  4. Supports batching where multiple AutoCCTP transfers can be processed together by IBC relayers

The result is a seamless experience where users can send USDC from Osmosis to Base in one click.

How we built it

Message Building (Router & Operations)

  • Implemented IBCMemoable interface for CCTP operations to embed Orbiter instructions in IBC transfer memos
  • Created Orbiter memo structures matching Noble's exact JSON specification with proper address encoding (32-byte base64 for EVM/SVM addresses)
  • Integrated with existing CCTP flow by detecting when smart relay fees are present and automatically generating Orbiter memos
  • Handled Noble Forwarding to batch IBC transfer + CCTP burn into a single transaction

Lifecycle Tracking (Indexing)

  • Refactored GetCCTPTransfersFromCosmosTx to handle multiple CCTP burns in a single Noble transaction (required for batched AutoCCTP transfers)
  • Updated relay payment detection to check not just the source transaction, but also subsequent transfers in the lifecycle chain
  • Removed single-transfer assumptions throughout the codebase that broke with batched operations

Testing & Integration

  • Created test utilities to validate Orbiter memo generation and address encoding
  • Tested on both testnet and mainnet (though Orbiter isn't live on mainnet yet)
  • Built comprehensive logging to trace the full AutoCCTP flow

Challenges we ran into

  1. Understanding Orbiter's Memo Format

The Orbiter module has very specific requirements for memo structure and address encoding. We had to:

  • Decode 32-byte base64 address encoding (EVM addresses need 12 bytes of padding, SVM addresses don't)
  • Correctly calculate basis points (fee as percentage × 10,000)
  • Match exact JSON structure with proper @type fields for Cosmos SDK protobuf types
  1. Orbiter Not Live on Mainnet

I discovered mid-hackathon that while Orbiter is documented and the Noble team is actively developing it, it's not yet deployed to mainnet. Funds sent to the Orbiter address just sit there. This meant we couldn't do true end-to-end testing on mainnet, though all the message building and lifecycle logic is correct. WE could do it on TestNet though :)

  1. Lifecycle Complexity The existing lifecycle system assumes:
  2. One CCTP transfer per transaction
  3. Relay payments only in the source transaction

AutoCCTP breaks both assumptions:

  • Multiple IBC transfers can batch into one Noble tx with multiple CCTP burns
  • Relay payments are in the Noble tx, not the source tx from Osmosis

I had to carefully refactor code to handle arrays of transfers and search across the entire transaction chain for relay payments.

  1. Time Pressure & Architecture Complexity In 36 ish hours:
  2. Understanding the existing router → operations → message building flow
  3. Tracing through lifecycle's transfer tracking across multiple chains
  4. Make changes without breaking existing CCTP functionality
  5. All while learning Noble's Orbiter module and understanding various pieces of skipgo/blockcahin architecture from scratch.

Accomplishments that I am proud of

  1. Fully implemented message building - the code generates perfectly formatted Orbiter memos that work on testnet
  2. Architectural understanding - I successfully navigated a complex production codebase and made targeted changes to the router, operations, and lifecycle systems with limited experience.
  3. Lifecycle refactoring - Upgraded the CCTP tracking system to handle batched transfers, which will benefit the system even beyond AutoCCTP
  4. Soon-to-be-production ready code - Our implementation includes proper error handling, logging, and follows the existing codebase patterns
  5. Complete design document - We documented the entire architecture, making it easy for the team to understand and build upon our work

What I learned

  1. IBC memo-based composability - How protocols like Orbiter use IBC packet memos to create programmable cross-chain workflows
  2. CCTP internals - Deep dive into Circle's attestation process, domain mappings, and mint recipient encoding
  3. Cosmos SDK module architecture - Understanding how Noble's Orbiter module intercepts IBC packets and triggers CCTP burns
  4. Production indexing challenges - The complexity of tracking cross-chain transfers across multiple protocols and handling edge cases like batching
  5. The importance of testnet - Having a live testnet environment (even if mainnet isn't ready) is crucial for validating complex cross-chain logic

What's next for Auto CCTP

  1. Complete lifecycle implementation.
  2. Wait for Orbiter mainnet - Once Noble deploys Orbiter to mainnet, enable AutoCCTP in production
  3. Payment verification - When verifying a payment, the payment verifier checks to see if the message directly after the message sent event is the bank send for the relayer fee payment. This assumption may not be true anymore, given the details regarding execution order here (fee payments may now happen before the deposit for burn / message sent, but we should simply make an AutoCCTP transaction on chain to verify this behavior) and will need to be updated to handle this new ordering.

The infrastructure is built, tested, and ready. As soon as Orbiter goes live on mainnet, Skip customers will soon have the best USDC bridging experience in crypto - all powered by Auto CCTP.

Built With

  • agoodattitude
  • go
Share this project:

Updates