gpu.aiDocs
CH·GGuides

Stablecoin Deposits

Fund your GPU.ai balance with USDC on Ethereum, Base, Arbitrum, Polygon, or Solana.

Fund your GPU.ai balance with USDC or USDT. Create a deposit, send the exact amount to the address you get back, and your balance goes up when the payment settles.

gpu billing deposit --crypto --chain base --asset usdc --amount 50
gpu billing deposits          # check on it

Everything below is also available over the API — POST /v1/billing/deposits/crypto, GET /v1/billing/deposits, GET /v1/billing/deposits/{id} — under the billing scope. See the CLI reference and the OpenAPI spec at https://api.gpu.ai/v1/openapi.json.


Read this before you send

Three mistakes are unrecoverable, and all three are avoidable in about ten seconds of attention.

1. Use the network you were given. The address you get back accepts one asset on one network. USDC sent to a Base address over Ethereum — or Arbitrum, or Polygon — is not detected, is not credited, and in most cases cannot be recovered by anyone. Your wallet will happily let you do it. The CLI prints the network on its own line under the address for exactly this reason; read that line, then pick the matching network in your wallet.

2. Use the address you were just given. Every deposit gets its own address. An address from last week's deposit is attached to last week's deposit, which is closed. Funds sent there are not credited automatically — support can see them and can usually sort it out, but it is a ticket and a wait, not a transfer.

3. Send the exact amount, and check what your wallet deducts. Send the pay_amount shown, in full. Some wallets take the network fee out of the amount you typed rather than adding it on top, which lands you a few cents short. That is not fatal — see Underpayment — but it is worth catching before you sign.


Supported networks and assets

Deposits are accepted in USDC and USDT on Ethereum, Base, Arbitrum, Polygon, and Solana.

Not every network/asset combination is enabled on every deployment. The authoritative answer is the API itself: a pair that is not available returns a validation error (unsupported-chain-asset) at deposit-creation time, before any address is issued. You will never be handed an address you cannot pay.

Choose on cost and speed, not on preference: Base, Arbitrum, Polygon and Solana settle in seconds to a couple of minutes for cents in fees. Ethereum mainnet is the slowest and by far the most expensive, and is worth using only if that is where your funds already sit.

Minimum

$5.00 by default, and the deployment may set a different floor. Below the minimum, network fees and the operational cost of handling a stuck deposit exceed the deposit itself. The live value is returned as min_deposit_cents on GET /v1/billing/deposits, and an under-minimum create is rejected with a validation-error that names the current floor. --amount is in US dollars; the amount of token you send is derived from it and shown as pay_amount.

How long you have

Each deposit carries an expires_at timestamp — currently a 24-hour window from creation. Send within it. The CLI shows the field; do not assume a duration, read the value, because it comes from the payment itself.

If the window closes with nothing received, the deposit goes to expired. Nothing is lost; create a new one.


What gets credited

Your balance is credited with the settled value of the asset you sent. There is no conversion: USDC settles as USDC, USDT as USDT, and a dollar-pegged stablecoin is valued at what actually settled. The credited_cents field is the real number, and amount_usd_cents stays as a record of what you originally requested.

Deposits do not qualify for promotional deposit-match credit. They are real money, credited at real value.

If you send the wrong amount

You sent less than pay_amount. You are credited what actually arrived — not the amount you requested. The deposit lands in credited_underpaid and shows both numbers, so the shortfall is visible rather than mysterious. You do not need to "top up" the same deposit; make another one if you want the remainder.

You sent more. You are credited the full amount that arrived. The deposit lands in credited_overpaid. Nothing is held back.

If you send after the deposit expired

The deposit goes to expired_received. The funds are attributable to you — the address is unique to your deposit — but a closed payment is not credited automatically. Contact support: they can see the amount and will credit your account manually.

If you send on the wrong network, or send the wrong token

Not detected, not credited. There is no automatic path here because there is nothing for the system to see. Contact support with the transaction hash; a recovery attempt is sometimes possible depending on the networks involved, and the outcome is recorded on your deposit either way.

If a deposit says "under review"

Some deposits are reviewed before crediting. A deposit in screening or held_screening is simply waiting; the funds are held, not lost, and the status updates when the review finishes. If it stays there longer than you would expect, contact support.

If the network reorganizes after you were credited

Rare, and mostly a theoretical concern on the networks above. If a confirmed transaction is reversed by the network after we credited it, your balance is adjusted back by the credited amount and the deposit is marked failed. You would need to re-send. Support is notified automatically when this happens.


Checking on a deposit

gpu billing deposits                     # all of them, newest first
gpu billing deposits get <deposit-id>    # one, with address + exact amount

The dashboard shows the same information live, updating as the deposit moves through detection, confirmation, and crediting.

Status meanings are tabulated in the gpu billing deposits reference.

Spending what you deposited

Deposited balance is ordinary account balance — it pays for GPU instances and serverless inference exactly like any other credit. Bound how fast it can be spent with gpu spend-limit, which supports both a monthly limit and an opt-in daily cap.

Getting help

Anything unexpected — a deposit stuck in a status, funds sent on the wrong network, a payment made after expiry — is a support conversation, and the transaction hash is the single most useful thing to include.

← All docs