Solana deposit contract

The Solana deposit contract receives the configured ERC-20 token on an EVM source chain and publishes an intent to transfer the destination token on Solana. Its factory fixes the route configuration; initialization fixes the destination and depositor. This page describes DepositAddress_USDCTransfer_Solana and its BaseDepositAddress implementation. Circle Gateway’s quoted deposit flow uses the Gateway API; do not apply this ABI to a Gateway vaultAddress.

Initialization and destination

The factory calls initialize(bytes32 destinationAddress, address depositor) once, immediately after deployment. At the contract level, destinationAddress is the recipient’s Solana associated token account, encoded as bytes32. Use the Solana deposit API when starting from a wallet address. The depositor becomes the created intent’s reward.creator, which determines the recipient for the normal intent refund path. It is not necessarily the address that sends the ERC-20 transfer.

Creating an intent

The contract exposes these functions. This TypeScript ABI fragment describes the interface; the deposit service normally submits the calls for you.

import { parseAbi } from 'viem';

const depositAbi = parseAbi([
  'function initialize(bytes32 destinationAddress, address depositor)',
  'function createIntent() returns (bytes32 intentHash)',
  'function createIntentWithApproval(address funder) returns (bytes32 intentHash)',
  'function destinationAddress() view returns (bytes32)',
  'function depositor() view returns (address)',
]);

Function	Behavior
`createIntent()`	Uses the contract’s entire balance of the configured source token. It takes no amount argument.
`createIntentWithApproval(funder)`	Pulls the lesser of the funder’s allowance and token balance, then creates the intent. The funder must first approve this deposit contract.

The Solana implementation encodes an SPL TransferChecked call, approves the source Portal, and calls publishAndFund with partial funding disabled. The reward has a zero native amount, the configured source token, the configured prover, and a deadline derived from the factory’s duration. Receiving an ERC-20 transfer alone does not call createIntent(). The monitoring service detects the balance and submits that transaction separately.

Validation

Error	Cause
`AlreadyInitialized`	Initialization was already completed.
`OnlyFactory`	A caller other than the factory attempted initialization.
`InvalidDestinationAddress`	The destination is zero.
`InvalidDepositor`	The depositor is the zero address.
`NotInitialized`	An intent-creation call occurred before initialization.
`InvalidFunder`	`createIntentWithApproval` received the zero address.
`ZeroAmount`	The available source-token amount is zero.
`AmountTooLarge`	The amount exceeds Solana’s unsigned 64-bit token amount range.

Intent creation also depends on successful token and Portal calls. A transaction revert does not create a funded intent.

Refunds and delivery

This contract does not expose a refund(routeHash, reward) function. Once an intent has been funded, refunds use the Routes intent lifecycle with the depositor as reward.creator. Expiry alone does not confirm a refund transaction. A deployed contract proves only deployment. Confirm destination token delivery separately, as described in the Solana deposit guide.

Core

Send & Swap across chains

Deposit & Payout

Program your route

Enable 1:1 stablecoin UX

Verified Liquidity

Concepts

Protocol architecture

Solana deposit contract

Initialization and destination

Creating an intent

Validation

Refunds and delivery

Next steps

​Initialization and destination

​Creating an intent

​Validation

​Refunds and delivery

​Next steps

Initialization and destination

Creating an intent

Validation

Refunds and delivery

Next steps