Persistent Deposit Addresses

One POST returns a permanent deposit address — send USDC from any supported chain to reach USDC-SPOT on HyperCore.

POST /deposit-addresses returns a persistent, never-expiring deposit address that delivers USDC-SPOT to a recipient on HyperCore. The same request parameters always resolve to the same address, so you can request it once and reuse it — the amount is not part of the request. Send any amount, any time, and it's swept to the destination automatically; no wallet signing or per-transfer quote is required.

API key with the deposit-address permission required (Bearer auth). Get an API key + Integrator ID.

Supported routes

Destination: always USDC-SPOT on HyperCore — chainId 1337, 0x2000000000000000000000000000000000000000.
Recipient: an EVM address.
Origins: you don't need to hardcode these. The response's supportedInputs[] lists every origin chain you can deposit USDC from, the token to send on each, that route's min/max limits, and its indicative fees and fill time — read them from there. The list stays current as new chains are added.

The response returns a single deposit instruction. Other destinations or non-EVM recipients return 400.

Integrate

Request an address

Send the destination (token + recipient) and a refundAddresses entry to refund to if a deposit can't be completed.

curl -X POST https://across.to/api/deposit-addresses \
  -H "Authorization: Bearer $ACROSS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "destination": {
      "token": { "chainId": 1337, "address": "0x2000000000000000000000000000000000000000" },
      "recipient": "0x1111111111111111111111111111111111111111"
    },
    "refundAddresses": [
      { "namespace": "evm", "address": "0x2222222222222222222222222222222222222222" }
    ]
  }'

Read the deposit instruction

The response returns depositInstructions[]. Each has a depositAddress (an Account — { namespace, address }) and the supportedInputs it accepts: origin chain, input token, that route's min/max limits, plus an indicative fee breakdown and fill time. expiresAt is always null.

{
  "destination": {
    "token": { "chainId": 1337, "address": "0x2000…0000", "symbol": "USDC-SPOT", "name": "USDC", "decimals": 8 },
    "recipient": { "namespace": "evm", "address": "0x1111…1111" }
  },
  "refundAddresses": [
    { "namespace": "evm", "address": "0x2222…2222" }
  ],
  "expiresAt": null,
  "depositInstructions": [
    {
      "depositAddress": { "namespace": "evm", "address": "0xAcc0…BD6E" },
      "supportedInputs": [
        {
          "originChainId": 1,
          "inputToken": { "chainId": 1, "address": "0xA0b8…eB48", "symbol": "USDC", "name": "USD Coin", "decimals": 6 },
          "limits": { "minInputAmount": "5000000", "maxInputAmount": "10000000000000" },
          "indicativeFees": { "proportionalPct": "100000000000000", "fixedFeeUsd": 0.246894 },
          "indicativeFillTime": 30
        }
        // …one entry per supported origin chain
      ]
    }
  ],
  "id": "75795-1781095882239-8e49a5353db9"
}

Send funds

Send native USDC on any supported origin chain to the depositAddress. It's swept to HyperCore USDC-SPOT for the recipient. The address is amount-agnostic and permanent — reuse it for future transfers; re-POSTing the same parameters returns the same address.

Track your deposit

Two calls: list the deposits made through your deposit address, then fetch full details for the latest one. Prefer push over polling? Subscribe to webhooks to be notified the moment funds land.

List deposits for the address

Call GET /deposits with the depositAddress query param. It returns the transfers sent to that address, newest first, each enriched with the bridge deposit created for it. depositTxnRef is the hash of the transfer you sent to the deposit address. A transfer that hasn't been swept yet reports status deposit-pending; once the sweep is picked up, the item carries the bridge deposit's fill status (pending → filled).

curl "https://across.to/api/deposits?depositAddress=0xAcc0dDdb8169FD06a34AADd52a39A4166a15BD6E" \
  -H "Authorization: Bearer $ACROSS_API_KEY"

[
  {
    "status": "filled",
    "depositTxnRef": "0x92ffc5d69d00e14e79254f68adab030dd38119996501a88cac0da76557703d11"
    // …other deposit fields
  }
]

Fetch the latest deposit

Pick the latest transfer — the first item in the response — and pass its depositTxnRef to GET /deposit for the full deposit record, including fill status.

curl "https://across.to/api/deposit?depositTxnRef=0x92ffc5d69d00e14e79254f68adab030dd38119996501a88cac0da76557703d11" \
  -H "Authorization: Bearer $ACROSS_API_KEY"

See the full schema, fields, and error responses in the POST /deposit-addresses API reference.

Get notified with webhooks

Instead of polling GET /deposits to discover incoming transfers, subscribe once and Across POSTs a pda_transfer.deposit-pending event to your endpoint whenever funds land at any of your deposit addresses. The webhook is a notification, not a status feed: it reports the initial state of a deposit into your deposit address and hands you its depositTxnRef — from there, use GET /deposit for the full record and live status.

One-time setup, same base URL and API key as above (deposit-address permission):

curl -X POST https://across.to/api/v1/webhooks/subscriptions \
  -H "Authorization: Bearer $ACROSS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/webhooks/across",
    "filter": { "eventTypes": ["pda_transfer.deposit-pending"] }
  }'

{
  "id": "whsub_1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d",
  "secret": "whsec_kZ3vN8pXqLmR2sT5wY7bC1dF4gH6jK9n",
  "secretHash": "9f2c3b7a1e4d5f6089ab2c3d4e5f60718293a4b5c6d7e8f9012345678abcdef0"
}

The signing secret is returned only in this response — store it now. You need it to verify delivery signatures.

A subscription is persistent: it fires for every matching transfer, across all of your deposit addresses, until you delete it.

Receive events

When funds land at a deposit address, Across POSTs this body to your URL the moment the incoming transfer is detected. data carries the origin-side transfer; its status is always deposit-pending — the initial state at detection time, not a live value:

{
  "id": "b6d3f2a1-4c5e-5f60-9a8b-7c6d5e4f3a2b", // dedup key, stable across re-deliveries
  "type": "pda_transfer.deposit-pending",
  "version": 1,
  "timestamp": "2026-07-21T07:55:02.000Z",
  "filterableFields": { "integratorId": "0x00cf" }, // what subscriptions match on
  "data": {
    "status": "deposit-pending", // always this value — see "Track the deposit" below
    "originChainId": 8453,
    "depositor": "0x1e25bb9f82fa447a47C425Ff38Ee9B09A3507Fe0",
    "inputToken": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "inputAmount": "5000000",
    "depositTxnRef": "0x8cb734decaa78a20e720c4f94ec81d8be1c18e84f15912d367e7ed5b23e3b29f",
    "depositBlockNumber": 28491233,
    "depositBlockTimestamp": "2026-07-21T07:55:01.000Z"
  }
}

Verify, acknowledge, dedup

Deliveries are signed per the Standard Webhooks spec — verify them with an off-the-shelf library (standardwebhooks, svix) instead of writing crypto:

import { Webhook } from "standardwebhooks";

const wh = new Webhook(secret); // the whsec_… secret from subscription creation

// Pass the RAW body string — parsing and re-serializing breaks the signature.
const event = wh.verify(rawBody, {
  "webhook-id": req.headers["webhook-id"],
  "webhook-timestamp": req.headers["webhook-timestamp"],
  "webhook-signature": req.headers["webhook-signature"],
}); // throws on a bad signature or stale timestamp

Respond with any 2xx to acknowledge; anything else (or a timeout) is retried with backoff. Deliveries can repeat, so dedup on the envelope id and process idempotently.

Track the deposit

The webhook only tells you a deposit arrived — it never fires again for that transfer. To follow it to completion, pass the event's data.depositTxnRef to GET /deposit and poll until a terminal status:

curl "https://across.to/api/deposit?depositTxnRef=0x8cb734decaa78a20e720c4f94ec81d8be1c18e84f15912d367e7ed5b23e3b29f" \
  -H "Authorization: Bearer $ACROSS_API_KEY"

The response is the full deposit record — including the depositAddress that received the funds (useful to attribute the event to a user), the recipient, and the live status: deposit-pending → filled on success, or the refund path (auto-refund-pending → refunded) if the transfer can't be completed.

Headers, signature scheme, retry policy, and the full subscription API are in the webhooks API reference.

Persistent Deposit Addresses

On this page