Skip to main content
Deposit addresses for Gateway let users deposit USDC from any supported chain into Gateway through Arc with a single vanilla transfer. No bridge UI, no approval step, no contract interaction required from the user. Three properties define the system:
  • Non-custodial: Eco never holds user funds. The deposit address contract is deployed deterministically per user and its only operation is to create an intent to fulfill the deposit. If the intent expires unfulfilled, Routes’ refund rails return funds to the depositor automatically. No other outcome is possible.
  • Permissionless: Any wallet or application can generate a deposit address via the API. No whitelisting, no KYC gate, no special credentials.
  • Immutable: Each deposit address is derived deterministically from the user’s wallet using CREATE2. The same input always produces the same address on every supported chain. Once deployed, the address is permanent and can be shared publicly, embedded in invoices, or surfaced in a product UI.

​
Key highlights

PropertyDetail
Security modelDeterministic contracts with a single allowed operation. Refunds on intent expiry handled by Routes’ refund rails. No AMB bridging. No solver capital at risk. Equivalent to a standard CCTP transfer + contract-level guarantees.
UXSingle transfer to a static address. No approval step. No contract interaction. Minimum possible user actions.
SpeedSub-30 seconds end-to-end on chains with fast finality (vs 15 minutes for standard CCTP today). Performance scales with source chain finality.
Gasless pathSignature-based flows available. Users can authorize transfers without executing an on-chain transaction.
Multi-chainSingle static address works across all supported CCTP chains. Global balance abstraction coming via Permit3, collapsing multiple source chains into one deposit action.
CostNetting and coincidence-of-wants orchestration can drive effective cost to near-zero or subsidize the user entirely.
Developer experienceOne API call to generate an address. No bridge SDK integration. No user-facing complexity.

​
How it works

When funds arrive, the contract creates a Routes intent. The structure uses two local intents with a CCTP transfer in between. Local intents are proven implicitly and instantly by reading on-chain storage. Solvers compete to fulfill. Refunds for expired intents are handled by Routes’ refund rails, not by the deposit address contract itself.

​
Quickstart

​
Step 1: Generate a Deposit Address

Call the API to generate a Gateway deposit address. 
curl -X POST {base_url}/api/v1/depositAddresses/gateway \
  -H "Content-Type: application/json" \
  -d '{
    "chainId": 8453,
    "depositor": "0xYourDepositorAddress",
    "evmDestinationAddress": "0xYourDestinationAddress"
  }'
Request parameters:
FieldTypeDescription
chainIdnumberSource chain ID
depositorstringEVM address authorized to claim refunds if the intent expires unfulfilled
evmDestinationAddressstringEVM address that will receive funds on Gateway
Response (201 Created): 
{
  "data": {
    "evmDepositAddress": "0x...",
    "isDeployed": false,
    "createdAt": "..."
  }
}
The evmDepositAddress is the deposit address. Surface this to the user or send tokens to it programmatically.

​
Step 2: Send Tokens

The user (or application) sends USDC to the deposit address as a vanilla ERC-20 transfer. No special app or bridge UI required.

​
Step 3: Automatic Processing

Once tokens arrive, the routing logic executes automatically:
  1. Detects the deposit: Eco’s monitoring service detects the incoming tokens
  2. Deploys the contract: On first deposit, the contract is deployed via the factory (gasless to the user)
  3. Creates intents: The contract calls createIntent(), publishing two intents: one local intent (CCTP deposit into Arc/Polygon) and a second depositing into Gateway
  4. Solver fulfillment: Solver fulfills the intent, funds are added to the user’s balance on Gateway (sub-30 seconds on fast-finality chains)

​
Step 4: Check Status

curl {base_url}/api/v1/depositAddresses/evmAddress/0xYOUR_DEPOSIT_ADDRESS

​
Security

  • Contracts are deployed per user, deterministically derived. No shared contract state between users.
  • The only operation a deposit address contract can perform is createIntent(). It cannot be drained, cannot be redirected, cannot be upgraded.
  • If a solver fails to fulfill within the intent deadline, Routes’ refund rails return funds to the depositor. Funds cannot be stuck.
  • No AMB (Arbitrary Message Bridge) is used. Settlement is via Circle’s own CCTP infrastructure.
  • Security model = CCTP transfer security + contract-level operation constraints.
  • Full audit reports available via Cantina (linked in Eco docs).
  • Eco does not hold or touch user funds at any point in the flow.