Skip to main content
Creating a wallet is asynchronous. POST /v2/wallets returns immediately with status: "creating". Deposit addresses and on-chain state are not populated synchronously — poll GET /v2/wallets/{id} until status becomes "idle".

Create a portfolio wallet

Place each yield source under the token it accepts, as shown by its depositToken in GET /v2/wallets/yield-sources. Use cash to keep funds uninvested in that token. If you omit USDC or USDT when creating a wallet, that token defaults to 100% cash. A first POST with a new requestId returns 200 OK with a minimal creating envelope (no deposit addresses, zero balances). An idempotent replay with the same requestId and an identical payload returns 200 OK with the wallet’s current state. Reusing a requestId with a divergent payload (different label or allocations) returns 409 request_id_conflict — use a fresh requestId for a genuinely new wallet. See Idempotency for the full comparison rules.

Creating response

Polling for activation

Poll GET /v2/wallets/{id} every 1-2 seconds until status !== "creating":
See Polling for more on the poll pattern.

Ready response

Once status === "idle", the response is ready for deposits:

Key fields

Failed response

If wallet setup fails terminally, GET /v2/wallets/{id} returns:
Failed wallets cannot be recovered by retrying the same requestId. Create a new wallet with a fresh requestId and contact support if the failure reason is unclear.

Rebalancing

Portfolio wallets are best-effort targets. Over time, or after deposits and withdrawals, holdings drift from target allocations. The system rebalances to bring positions back toward the strategy targets. Deposits first appear as cash and are then deployed into the configured yield sources.

Sandbox notes

In sandbox, deposit address keys include the network suffix (e.g. ethereum_sepolia instead of ethereum). Sandbox USDT uses a Ground-owned mock contract. See Supported Chains for details.