Fast Gasless Deposits to Gateway

Deposit USDC into Circle Gateway on Polygon from any supported source chain, using Eco orchestration to route Gateway deposits through fast-finality chains like Polygon. The destination Gateway balance updates in typically 20–40 seconds and the user does not need to hold source-chain gas — they sign an ERC-3009 authorization and Eco broadcasts.

For the full REST endpoint reference, see Gateway API under the API Reference tab.

Three properties define the system:

Non-custodial: Eco never holds user funds. Each deposit address is a deterministic contract whose only operation is to publish a Routes intent. If the intent expires unfulfilled, an independent, permissionless refund service returns funds to the depositor.
Permissionless: Any wallet or application can generate a deposit address via the API. No whitelisting, no KYC gate.
Immutable: The address is CREATE2-derived from (depositor, evmDestinationAddress, chainId) — the same inputs always produce the same address, and it can be shared before it’s deployed.

Supported chains

Source chains	Destination
Base, Optimism, Arbitrum	Gateway on Polygon

Any Gateway-enabled chain can be added. Ask if you need a chain that isn’t listed.

Environment

Base URL	Test app
`https://deposit-addresses.eco.com`	`https://gateway.eco.com/`

How it works

When funds arrive, the deposit contract publishes two intents: a local intent that handles the CCTP leg and a second intent that credits the user’s Gateway balance on Polygon. Solvers compete to fulfill.

Quickstart

Generate the deposit address

POST /api/v1/depositAddresses/gateway/polygon with the depositor and recipient.

Fund it — gasless or direct

Collect an ERC-3009 signature and call POST /api/v1/gasless/transferWithAuthorization, or just do a vanilla ERC-20 transfer.

Poll for completion

Hit GET /api/v1/gasless/jobs/{id} (gasless) or read the deposit address record (direct transfer).

Step 1: Generate a Gateway deposit address

curl -X POST https://deposit-addresses.eco.com/api/v1/depositAddresses/gateway/polygon \
  -H "Content-Type: application/json" \
  -d '{
    "chainId": 8453,
    "depositor": "0xYourWalletAddress",
    "evmDestinationAddress": "0xRecipientOnGateway"
  }'

Field	Type	Description
`chainId`	number	Source chain (one of the supported chains above)
`depositor`	string	EVM address authorized for refunds
`evmDestinationAddress`	string	Recipient credited on Gateway (Polygon)

Response (201 Created):

{
  "data": {
    "evmDepositAddress": "0x...",
    "isDeployed": false,
    "createdAt": "..."
  }
}

evmDepositAddress is deterministic — the same inputs always return the same address, so you can surface it to users or embed it before it’s deployed on-chain.

Step 2: Fund the address

Three ways — pick one:

ERC-3009 transferWithAuthorization (recommended for gasless UX). Single transaction, no user gas.
EIP-2612 Permit. Two transactions (permit() + createIntentWithApproval()), no user gas.
Direct ERC-20 transfer. Sender pays gas.

Recommended: ERC-3009 gasless transfer

Have the user sign an EIP-712 TransferWithAuthorization over the USDC contract, then post it:

curl -X POST https://deposit-addresses.eco.com/api/v1/gasless/transferWithAuthorization \
  -H "Content-Type: application/json" \
  -d '{
    "chainId": 8453,
    "from": "0xSignerAddress",
    "to": "0xDepositAddress",
    "value": "1000000",
    "validAfter": "0",
    "validBefore": "1776098178",
    "nonce": "0x<random-32-bytes>",
    "signature": "0x<65-byte-eip712-signature>"
  }'

Response (202 Accepted):

{ "data": { "id": "<job-id>", "status": "PENDING" } }

See Deposit methods for signing code, the Permit variant, and field-by-field details.

Step 3: Poll for completion

For gasless transfers, poll the job:

curl https://deposit-addresses.eco.com/api/v1/gasless/jobs/<job-id>

Status transitions: PENDING → COMPLETED or FAILED. The response includes transferTxHash and intentHash when complete. To confirm the deposit reached Gateway, read the deposit address’s balance record or query Circle Gateway’s balance API directly. See FAQ for both options.

FAQ

How do I know when funds have landed in Gateway?

Two options:

Poll the deposit address record via GET /api/v1/depositAddresses/evmAddress/{address} (includes lastCheckedBalance, isDeployed, deploymentTxHash).
Poll Circle Gateway directly against the recipient address.

What happens if the gasless job ends up `FAILED`?

Nothing. FAILED means the service couldn’t initiate the transfer (e.g. signature invalid, balance dropped, deadline expired). USDC never left the user’s wallet. The signature just expires — submit a new one to retry.

What if USDC arrives at the deposit address but the deposit to Gateway never happens?

The deposit address service monitors the deposit contract for any balance and publishes an intent with that balance. The intent carries a ~4-hour deadline (reducible). If Eco’s protocol doesn’t fulfill it in time, an independent, permissionless refund service returns the USDC to the depositor. You (or anyone) can also drive both steps yourself — intent creation and refund are permissionless.

What if USDC gets bridged via CCTP but doesn't land in Gateway?

CCTP-bridged tokens are minted straight into a Routes intent vault, not into a floating account. The same refund path applies: after the deadline elapses, the refund service unlocks the vault and returns funds to the depositor.

How fast is end-to-end?

On Base Sepolia → Polygon Amoy we typically see 20–40 seconds from submission to Gateway balance update. Time scales with source-chain finality.

Permit vs ERC-3009 — which should I prefer?

ERC-3009 transferWithAuthorization — single transaction, cleaner UX, USDC-native. Use Permit if the token you’re working with supports permit() but not ERC-3009.

Which source chains can I use?

Any Gateway-enabled chain. Today: Base, Optimism, Arbitrum. Ask if you need a chain added.

Is the deposit address the same every time?

Yes — it’s a deterministic CREATE2 address derived from (depositor, evmDestinationAddress, chainId). Calling the endpoint again with identical inputs returns the same evmDepositAddress.

Security

Contracts are deployed per user, deterministically derived. No shared contract state.
The only operation a deposit address can perform is createIntent(). It cannot be drained, redirected, or upgraded.
Refunds are driven by an independent, permissionless service. Funds cannot be stuck.
No AMB (Arbitrary Message Bridge). Settlement uses Circle’s CCTP.
Security model = CCTP transfer security + contract-level operation constraints.
Full audit reports (Cantina) available on request.
Eco never holds or touches user funds.

Next steps

Deposit methods

EIP-712 signing code for ERC-3009 and Permit, plus the direct-transfer path.

API Reference

Every endpoint with request/response shapes, status transitions, and validation rules.

Programmable Addresses

Products

Architecture

Fast Gasless Deposits to Gateway

Supported chains

Environment

How it works

Quickstart

Step 1: Generate a Gateway deposit address

Step 2: Fund the address

Recommended: ERC-3009 gasless transfer

Step 3: Poll for completion

FAQ

Security

Next steps

Deposit methods

API Reference

Programmable Addresses

Products

Architecture

Documentation Index

​Supported chains

​Environment

​How it works

​Quickstart

​Step 1: Generate a Gateway deposit address

​Step 2: Fund the address

​Recommended: ERC-3009 gasless transfer

​Step 3: Poll for completion

​FAQ

​Security

​Next steps

Deposit methods

API Reference

Supported chains

Environment

How it works

Quickstart

Step 1: Generate a Gateway deposit address

Step 2: Fund the address

Recommended: ERC-3009 gasless transfer

Step 3: Poll for completion

FAQ

Security

Next steps