The single hardest thing was getting Circle CCTP V2's receive_message working on Solana devnet end-to-end for the Fund-from-Arc flow. It is the flow that qualifies us for the Circle track, and Circle's Solana side programs (CCTPV2Sm4AdWt5296sk4P66VBZ7bEhcARwFaaS9YPbeC and CCTPV2vPZJS2u2BBsUoscuikbYjnpFmbFsvVuJdgUMQe) had essentially no TypeScript reference for the EVM to Solana direction. We had to reverse engineer the account order and PDA seed encoding from live on-chain data. Four separate traps, each one ate a demo-day hour.

1. The used_nonce PDA seeds changed between V1 and V2
   Our first guess, by analogy to V1, was ["used_message", source_domain_BE, nonce]. It failed with AnchorError: ConstraintSeeds. The actual V2 seeds are [b"used_nonce", nonce_32_bytes]. The prefix string changed, and source_domain is not a seed at all.

2. remote_token_messenger and token_pair use ASCII-encoded domains
   We initially encoded source_domain as a 4-byte big-endian u32 (the standard Rust to_be_bytes() convention). It failed with AccountNotInitialized. On-chain inspection revealed that Circle encodes the domain as ASCII bytes. Domain 26 becomes [0x32, 0x36] (the string "26"), not [0x00, 0x00, 0x00, 0x1A]. That choice is not documented anywhere we could find.

3. V2 added a fee_recipient_token_account that every V1 example is missing
   CCTP V2 inserted a new account slot between token_pair and recipient_ata in the remaining_accounts forwarded to handle_receive_finalized_message. V1 did not have it, so every reference implementation online was silently wrong. Worse, the fee recipient's pubkey is not a well-known constant. It is stored inside the token_messenger account at byte offset 109 (after owner, pending_owner, paused_by, a u32 version field, and a u8 bump). We wrote a small Node script that walked byte offsets, called getAssociatedTokenAddress for each possible 32-byte chunk, and checked which USDC ATAs actually existed on-chain. That pinpointed the real fee_recipient in about 30 seconds. Now the route fetches token_messenger at call time and parses the layout by hand.

4. The full transaction was 66 bytes over Solana's 1232-byte limit
   Combining create_ata and receive_message in one tx exceeded Solana's hard cap. We split into two transactions. An idempotent ATA creation first, then receive_message alone. Only the latter is the real mint, so the user still sees a single on-chain mint event.

The meta-lesson
Six failed attempts burned around 15 USDC on Arc before we got it right. Each iteration was a real on-chain burn that cannot be "un-burned". But the reverse engineering pattern we developed is transferable. Fetch a known-good account, diff its byte layout against what Anchor expects, and iterate on the Anchor error codes until every constraint validates. That pattern is what turned a flow we thought would never ship into the cleanest segment of our demo.

This is the only Arc and Solana CCTP V2 cross-chain flow we have found running end-to-end on a hackathon project in this cycle. It is also why the Circle track qualifier is a fully live demo rather than a bullet point on the README.