Deposits are direct onchain transfers. Glider returns the chain-bound smart
accounts for the portfolio; the user wallet or custody provider submits the
asset transfer to that address.
1. Resolve the destination
Use the smartAccounts returned by POST /v2/enroll, or read them again:
Each accountId is a chain-bound CAIP-10 identifier:
Select the account on the same chain as the asset. If the object includes
depositAccountId, use that value as the destination. This requirement is
important for Solana sub-account enrollment.
If depositAccountId is not present, use the address in accountId.
Use a CAIP library to parse the identifiers. Do not split the identifiers in
production code.
2. Submit the onchain transfer
For EVM, connect the user to the chain in the selected account. Then, send the
native asset or call the ERC-20 transfer method.
For Solana, send the supported SPL asset to the returned deposit account.
Glider does not receive the user’s wallet credentials or sign the funding
transaction.
Confirm that the asset’s CAIP-19 chain matches the destination account’s
CAIP-10 chain. Do not send an asset to the same smart-account address on a
different chain.
3. Verify positions
After the transaction confirms, positions can take a short time to update. Read:
The positions route returns balance, balanceRaw, priceUsd, and valueUsd
for each asset. The API can cache results for a short time. Partial upstream
failures appear in warnings and do not fail the full response.
4. Begin automation
Make sure that the expected assets are visible. Then, start or resume the
schedule with POST /v2/portfolios/{portfolioId}/start.
To rebalance immediately, call
POST /v2/portfolios/{portfolioId}/rebalance. Poll the returned
operationId.
Further reference
