> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Solana deposit factory

> How the Solana deposit factory derives addresses, deploys contracts, and fixes route configuration.

`DepositFactory_USDCTransfer_Solana` predicts and deploys deposit contracts for a configured source token and Solana destination token. Use the [deposit-address API](/programmable-addresses/solana-deposit-addresses) for an application integration; use the contract interface when inspecting its configuration or deployment behavior.

This factory is specific to the Solana deposit flow. Circle Gateway's quoted `vaultAddress` has a different lifecycle.

## Address derivation

The factory derives a CREATE2 salt from both the destination associated token account and the depositor. The predicted address also depends on the deploying factory and implementation. The same destination and depositor on the same factory produce the same address, including before deployment.

At this contract boundary, `destinationAddress` is the recipient's Solana associated token account encoded as `bytes32`, not the base58 wallet string accepted by the API.

```typescript theme={null}
import { parseAbi } from 'viem';

const factoryAbi = parseAbi([
  'function getDepositAddress(bytes32 destinationAddress, address depositor) view returns (address)',
  'function isDeployed(bytes32 destinationAddress, address depositor) view returns (bool)',
  'function deploy(bytes32 destinationAddress, address depositor) returns (address deployed)',
  'event DepositContractDeployed(bytes32 indexed destinationAddress, address indexed depositAddress)',
]);
```

`getDepositAddress` and `isDeployed` both require the depositor argument. `deploy` creates the clone, initializes it with the destination and depositor, and emits `DepositContractDeployed`. Deployment requires an onchain transaction; an incoming token transfer does not deploy the contract by itself.

## Configuration

Each factory stores these settings. The constructor validates that token, Portal, prover, and Solana account values are nonzero and that the deadline duration is nonzero.

| Getter | Meaning |
| - | - |
| `DESTINATION_CHAIN()` | Solana chain ID, `1399811149` |
| `SOURCE_TOKEN()` | ERC-20 token on the source chain |
| `DESTINATION_TOKEN()` | Solana token mint, encoded as `bytes32` |
| `PORTAL_ADDRESS()` | Source-chain Routes Portal |
| `PROVER_ADDRESS()` | Prover used in the reward |
| `DESTINATION_PORTAL()` | Solana Portal program |
| `PORTAL_PDA()` | Solana Portal vault authority |
| `INTENT_DEADLINE_DURATION()` | Intent validity duration in seconds |
| `EXECUTOR_ATA()` | Executor's associated token account on Solana |
| `DEPOSIT_IMPLEMENTATION()` | Implementation used for deposit clones |

`getConfiguration()` returns the first nine values in the table, in that order. The destination chain is a constant; the remaining route configuration and implementation address are immutable.

## Troubleshooting

* If an API request reports an unconfigured factory, check the source chain's support for the Solana deposit flow.
* If your predicted address differs from the API response, check the factory, depositor, and associated token account. A wallet public key and its token account are different addresses.
* If a deposit address has no bytecode yet, it may be a predicted address awaiting deployment. Check the API record before treating that as a failure.

## Next steps

* [Deposit contract behavior](/programmable-addresses/architecture/deposit-contract)
* [Solana deposit integration](/programmable-addresses/solana-deposit-addresses)