Skip to main content
POST
Builds the transactions that deposit tokens into an Earn vault and mint vault shares (LP tokens) to the wallet. The response carries two transactions in txBase64s: an AUM refresh followed by the deposit itself. Sign both with the depositing wallet and submit them in order as one Jito bundle. The deposit transaction already contains the Jito tip. See Sending Earn transactions below. If the vault has requiresAcknowledgment: true (see Get Earn Vault), call Acknowledge Earn Vault for the wallet before its first deposit.

Body

string
required
Earn vault address.
string
required
Depositing wallet. It pays fees and signs both transactions.
string | integer
required
Amount to deposit, in base units of the deposit mint (for example "1000000" is 1 USDC).
string
Token to deposit. Defaults to the vault’s underlying (acceptedAssetMint). Must be one of the vault’s token entries (parsedAccountJson on Get Earn Vault), otherwise the request fails.
string | integer
Minimum shares to receive, in LP base units. The transaction fails if fewer would be minted. Defaults to 0 (no slippage protection).
string
default:"exponent"
Vault provider. Only exponent is supported today.

Response

string[]
Base64 v0 transactions to sign and send in order as one bundle: [aumRefresh, deposit].
string
The deposit transaction on its own (the last entry of txBase64s).
string
deposit.
string
Provider that built the transaction.
string
Vault address.
string
Wallet the transaction was built for.
object[]
Decoded setup instructions in the deposit transaction (compute budget, heap frame, Jito tip, token account creation).
object[]
Decoded vault instructions in the deposit transaction.
string[]
Address lookup tables the deposit transaction uses.
string[]
Extra signers that already signed the deposit transaction. Empty for deposits.
string[]
Lookup tables that could not be loaded. Diagnostic only.
string[]
Accounts passed outside lookup tables. Diagnostic only.

Sending Earn transactions

Every Earn transaction endpoint (deposit, withdraw request, claim, cancel) returns the same shape:
  1. Deserialize each entry of txBase64s as a VersionedTransaction.
  2. Sign each one with the wallet. Keep any signatures already present: a queued withdraw request comes partially signed by its new request account (listed in signers).
  3. Submit the signed transactions in the order returned as a single Jito bundle. The first refreshes the vault’s AUM so the action is priced at current NAV. The last carries the Jito tip. Sending the action alone, or out of order, can fail or price against stale NAV.
Transactions use a recent blockhash from build time, so sign and send promptly.

Errors

If a transaction can’t be built, the endpoint returns 500 with error.code, error.message, and the accountsNotInLuts and missingLuts diagnostics.