Deposits

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. Deposits show in held_usd on arrival and stay held until a deployment allocates them to 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 with limit/cursor:

{
  "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
}

status: observed -> confirmed, or failed with an error object. The wallet address itself is stable; use GET /wallet when you need deposit instructions, and GET /wallet/deposits when you need history.

Rules and edges

• Minimum: deposits below deposit.min_usd ($5) arrive on-chain fine but can't start a live deployment — venues reject accounts under their own floors (venue matrix).
• 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 a deploy allocates them — nothing moves to any venue without a deployment start you initiated.
• For an agent: after telling the operator the deposit address, the readiness signal is held_usd reaching your target — then create and start the deployment; the runtime's venue_account probe takes over from there.