---
title: Deposits
description: Fund the managed wallet and list deposit history.
---

Fund the managed wallet by sending USDC on Arbitrum to the `deposit.address` returned by [`GET /wallet`](/wallet/overview). Deposits show in `held_usd` on arrival and stay held until an explicit venue setup reserves them for a venue. A fresh deposit is never displayed as $0: both `held_usd` and `allocated` count toward `total_usd`.

### GET /wallet/deposits

List recent deposits, newest first.

**Query parameters**

| Param | Type | Notes |
|---|---|---|
| `limit` | integer | Optional. `1` to `100`; defaults to `20`. |
| `cursor` | string | Optional opaque cursor returned by the preceding page. Pass it back unchanged; do not parse or modify it. |

**Response — `200`**

```json
{
  "deposits": [
    {
      "id": "depst_01j9ac...",
      "status": "confirmed",
      "asset": "USDC",
      "chain": "arbitrum",
      "amount_usd": 250.0,
      "tx_hash": "0xabc...",
      "created_at": "2026-07-30T09:20:00Z",
      "confirmed_at": "2026-07-30T09:20:41Z"
    }
  ],
  "next_cursor": null
}
```

An empty history is a valid success: `{"deposits": [], "next_cursor": null}`. When another page exists, pass its non-null `next_cursor` as the next request's `cursor`.

**Field presence**

- `status` progresses from `observed` to `confirmed`, or becomes `failed`.
- `tx_hash` is always present and is `null` until a transaction hash is recorded.
- `confirmed_at` appears only after the deposit is confirmed.
- `error` appears only when `status` is `failed` and contains a stable public `code` and `message`.

**Errors**

| Status | Code | When |
|---|---|---|
| `400` | `bad_request` | `limit` is outside `1` to `100`, or `cursor` is invalid. |
| `401` | `unauthorized` | Authentication is missing or invalid. |
| `429` | `rate_limited` | The account or API key exceeded its request allowance. |
| `503` | `wallet_repository_unavailable` | Deposit history could not be read. This is distinct from a valid empty `200`. |

The wallet address itself is stable; use [`GET /wallet`](/wallet/overview) when you need deposit instructions, and `GET /wallet/deposits` when you need history.

## Rules and edges

- **Minimum:** `deposit.min_usd` is Superior's $50 customer-facing minimum. `deposit.protocol_min_usd` is Hyperliquid's $5 bridge safety floor; use $50 or more for a supported deposit and deployment flow ([venue matrix](/context/venues)).
- **Wrong asset / wrong chain:** anything other than Arbitrum USDC is out of scope for automatic crediting — funds sent on other chains are not lost (the address is yours in custody terms), but recovering them is a support conversation, not an API flow. Send exactly what the `deposit` object says.
- **Held means held:** deposits stay in `held_usd` until explicit venue setup reserves them — nothing moves to any venue without your setup request.
- For an agent: after telling the operator the deposit address, the readiness signal is `held_usd` reaching your target — then set up the venue with `POST /wallet/venues/{venue}/setup`, poll `GET /wallet`, and only then create or start a deployment; the [runtime.s `venue_account` probe](/runtime/deployments) takes over from there.