Skip to main content
When a user initiates a deposit into a vault, you pass their instruction through the Turnkey API, and Turnkey forms and broadcasts the corresponding transaction at that user’s direction, depositing the assets into your organization’s fee wrapper for the vault. The token approval and the vault deposit execute as a single atomic batch transaction, so there is no separate approval step to manage.

​
Prerequisites

  • Your organization has deployed a wrapper for the vault, and its deployment status is COMPLETED. Deposits targeting an address with no deployed wrapper fail with EARN_SETUP_REQUIRED.
  • Deposits to the wrapper are not paused: check depositsDisabled on list_earn_enabled_vaults.
  • The signWith wallet holds enough of the vault’s underlying asset. For non-sponsored deposits it also needs the chain’s native token for gas.
Sub-organization wallets can deposit into (and withdraw from) wrappers deployed by their parent organization. The wrapper configuration lives on the parent, the sub-org wallet signs, and no per-sub-org deployment is needed.

​
Submit the deposit

Submit an ACTIVITY_TYPE_EARN_DEPOSIT activity with:
  • the wrapperAddress to deposit into, from list_earn_enabled_vaults
  • the signWith wallet account to deposit from and sign with
  • the amount in assets, in raw onchain units of the underlying asset (e.g. "1000000" for 1 USDC at 6 decimals)
  • the CAIP-2 chain in chainCaip2, and optionally sponsor for gas sponsorship
See Deposit into Earn vault in the API reference for the full request/response schema and cURL example. The activity result contains only a poll handle, depositRequestId.

​
Gas: sponsored vs self-funded

With sponsor: true, network fees are covered through Turnkey’s Gas Station and the batch executes as an EIP-7702 sponsored transaction. The signWith wallet does not need a gas token. With sponsor: false, the signWith wallet pays gas itself, and the user initiating the deposit will need the relevant chain’s gas token.

​
Poll deposit status (required)

A COMPLETED activity means the transaction was enqueued for broadcast, not that it landed onchain. A transaction that later fails (for example, from an insufficient token balance) is invisible in the activity result. Poll get_earn_deposit_status until it reports COMPLETED (included onchain) or FAILED.
Poll with the depositRequestId from the activity result. status is PENDING, COMPLETED, or FAILED; on COMPLETED the response carries the depositTxHash, and on FAILED it includes an error field with the reason. See Submissions for general activity semantics.

​
Next steps