Pay First, Settle Later with CCTP

A platform that pays contractors with USDC across multiple chains has a few options. It can run CCTP per payout: one burn, one attestation, one mint, every time. That works. But at volume, it means hundreds of crosschain transactions a day, signing infrastructure on every destination chain, and treasury cadence locked to individual payouts.

There is another shape: delegate payout execution to a counterparty that already holds USDC on the destination chain. That counterparty, which is a fulfiller, pays the contractor locally. The platform settles reimbursement afterward through CCTP. The platform never executes on the destination chain at all. It stays single-chain operationally, while fulfillers handle delivery where the recipients are.

‍

When this matters

If a platform does a handful of payouts and the contractor can wait for crosschain settlement, direct CCTP to the recipient is simpler. There is no need for a fulfiller, a repayment contract, or any reimbursement choreography.

This pattern is for platforms that pay frequently across several chains and want to batch settlement, delegate destination-chain operations, or decouple payout timing from treasury movement. The wins stack up at scale: fewer burns on the source chain, no signing infrastructure on destination chains because fulfillers handle execution there, and a treasury cadence that follows the platform's schedule instead of firing per-payout.

The demo

To show the mechanics, we'll go through a single payout cycle in this demo.

The platform keeps its funds on Arc Testnet. A contractor needs to be paid on Ethereum Sepolia. Instead of running a CCTP burn on Arc for each payout, a selected fulfiller fronts the payment on Sepolia first. The platform then uses CCTP to reimburse the fulfiller by burning on Arc, minting into a repayment contract on Sepolia.

1. the platform creates a payout intent
2. the platform selects one fulfiller
3. that fulfiller sends the payout to the contractor on Sepolia
4. the platform starts a CCTP burn from Arc
5. attestation becomes available
6. the destination mint lands in a repayment contract on Sepolia
7. the repayment contract releases funds to the selected fulfiller

What the fulfiller is doing

In a real system, a fulfiller would usually expect compensation or some other benefit for fronting payouts. Our demo keeps that economic layer out of scope and focuses on the settlement flow itself.

The demo includes three fulfiller profiles with different fee and speed characteristics:

• alpha: 5 bps, cheaper, slower, handles amounts above 3 USDC
• beta: 12 bps, faster, more expensive
• gamma: 3 bps, cheapest for small payouts up to 3 USDC

A simple selector picks one based on the payout request's amount, priority, and fee cap.

Once selected, the fulfiller fronts the payout as a direct USDC transfer on the destination chain:

export async function fulfillPayout(
  fulfillerId: FulfillerId,
  recipient: `0x${string}`,
  amount: bigint,
) {
  const walletClient = fulfillerWalletClients[fulfillerId];

  const hash = await walletClient.writeContract({
    address: env.destinationUsdcAddress,
    abi: usdcAbi,
    functionName: "transfer",
    args: [recipient, amount],
    account: walletClient.account,
    chain: walletClient.chain,
  });

  await destinationPublicClient.waitForTransactionReceipt({ hash });
  return hash;
}

Where CCTP fits

CCTP is the crosschain settlement mechanism in this architecture. It is not choosing the fulfiller. It is not delivering the initial payout. It is settling value after the payout has already been delivered.

The platform burns on Arc toward the repayment contract on Sepolia instead of sending funds straight to the recipient:

export async function burnToRepaymentContract(
  amount: bigint,
  quote?: BurnQuote,
) {
  const burnQuote = quote ?? (await quoteBurn(amount));

  const hash = await sourceWalletClient.writeContract({
    address: testnetContracts.tokenMessengerV2,
    abi: tokenMessengerV2Abi,
    functionName: "depositForBurn",
    args: [
      burnQuote.sourceAmount,
      DESTINATION_DOMAIN,
      encodeAddressToBytes32(env.repaymentContractAddress),
      env.sourceUsdcAddress,
      ZERO_BYTES32,
      burnQuote.maxFee,
      burnQuote.minFinalityThreshold,
    ],
    account: sourceWalletClient.account,
    chain: sourceWalletClient.chain,
  });

  await sourcePublicClient.waitForTransactionReceipt({ hash });
  return hash;
}

The mint destination is the repayment contract. What happens after the mint lands is the contract's job.

The repayment contract

The repayment contract records who should be reimbursed, receives the CCTP mint, and releases funds to the selected fulfiller.

The sample uses a demo repayment contract on Sepolia at 0x65b1210b4ee0e56f03184b454b3bd035e8c6bdf0. It exists to make the flow inspectable; builders should deploy their own repayment contract and encode the reimbursement rules their product needs.

function registerIntentRepayment(
    bytes32 intentId,
    address fulfiller,
    uint256 amount,
    address recipient
) external onlyOperator {
    if (repayments[intentId].fulfiller != address(0)) revert RepaymentExists();
    repayments[intentId] = IntentRepayment({
        fulfiller: fulfiller,
        recipient: recipient,
        amount: amount,
        repaid: false
    });
}

function releaseToFulfiller(bytes32 intentId) external onlyOperator {
    IntentRepayment storage repayment = repayments[intentId];
    if (repayment.fulfiller == address(0)) revert RepaymentMissing();
    if (repayment.repaid) revert AlreadyRepaid();
    if (USDC.balanceOf(address(this)) < repayment.amount) revert NothingToRelease();
    bool ok = USDC.transfer(repayment.fulfiller, repayment.amount);
    if (!ok) revert TransferFailed();
    repayment.repaid = true;
}

In a production setting, this is where a platform would encode its own operational rules: who is allowed to register a repayment, who is allowed to release it, whether the fulfiller and amount match the approved request, and whether holds, disputes, limits, or policy checks should block release.

What production adds

A production system built on this pattern would layer in batched burns instead of one per payout, netting across fulfillers before settlement, fulfiller economics (fees, competition, SLAs), dispute and hold logic in the repayment contract, and gas and signing infrastructure managed by fulfillers rather than the platform on each destination chain.

A Different Role for CCTP

This demo is meant to explain the concept behind this flow. Builders can take it from there, shaping reimbursement rules, fulfiller economics, and operational hardening around the needs of their product.

_{Circle Technology Services, LLC (“CTS”) is a software provider and does not provide regulated financial or advisory services. You are solely responsible for services you provide to users, including obtaining any necessary licenses or approvals and otherwise complying with applicable laws. For additional details, please click here to see the Circle Developer terms of service.} 

_{USDC is issued by regulated affiliates of Circle. See Circle’s list of regulatory authorizations.}

_{Arc testnet is offered by Circle Technology Services, LLC ("CTS"). CTS is a software provider and does not provide regulated financial or advisory services. You are solely responsible for services you provide to users, including obtaining any necessary licenses or approvals and otherwise complying with applicable laws.}

_{Arc has not been reviewed or approved by the New York State Department of Financial Services.}

_{The product features described in these materials are for informational purposes only. All product features may be modified, delayed, or cancelled without prior notice, at any time and at the sole discretion of Circle Technology Services, LLC. Nothing herein constitutes a commitment, warranty, guarantee or investment advice.}