Vault Liquidity
Deposit to Vault
Approve-and-deposit calldata into a vault connected to this market, and its confirmation
POST
Builds the two transactions that deposit into one of the vaults this market takes liquidity through. The first approves the vault to pull its asset, the market’s settlement token (stablecoin). The second is the deposit itself. The depositor’s wallet signs both in order and receives vault shares at the current share price.
A current market takes no deposit of its own from third parties, so this is how a client funds it. List Connected Vaults names the vaults and says whether each one takes a deposit here. Send the same call again with the deposit’s hash to confirm it.
Path Parameters
string
required
Market ID.
string
required
A vault connected to this market, from List Connected Vaults.
0x followed by 40 hex characters. A mixed-case address must pass its EIP-55 checksum.Body Parameters
string
Amount to deposit as a decimal string, for example
"1000". Digits with an optional fraction, greater than zero, parsed at the vault’s asset decimals, so a finer fraction answers VALIDATION_ERROR. Required when building calldata, ignored when confirming.string
Wallet that will sign the deposit. When supplied, the API checks it against the vault’s own register and refuses with
DEPOSITOR_NOT_VERIFIED where the register says no. On a vault that supports distributor attribution, it also checks the provider register of every market the vault funds or has consented to draw for. It then reads whether the wallet is already bound to a distributor. Omit it to skip these checks. The vault enforces its registers on-chain either way.string
Hash of the mined deposit step. Send it on its own to confirm and record the deposit. Omit it to receive the calldata.
When a deposit is refused
Most refusals are about the vault rather than the depositor. The vault must be connected to this market, hold the asset the market lends, and take deposits for your instance. A vault your instance operates always does. Any other vault does only once its operator has published it on your network with a risk disclosure. Two refusals exist to stop shares being issued against a number nobody can stand behind.VAULT_BOOK_INCOMPLETE means a market the vault funds is not answering, so the vault cannot total its own book. VAULT_WIPED_OUT means shares are in issue against assets totalling zero, so a deposit would be absorbed by the existing holders. Neither affects redemptions. See Vaults.
Distributor attribution
On a vault that supports distributor attribution, the deposit names your instance as the depositor’s distributor. It carries your instance’s primary verified wallet indeposit(amount, distributor). The vault binds the signing wallet to the first distributor a deposit names and never rebinds it, and credits that distributor a share of the interest its shares earn.
When the vault operator has not approved your instance’s wallet as a distributor, the API builds a plain deposit(amount) instead, so the deposit still goes through unattributed. attribution.binding says what this deposit does, with the same values as Deposit on the vault surface. Show attribution.warning before the depositor signs.
Confirm the deposit
Broadcast the approval, then the deposit. Send the deposit step’s hash back to this same endpoint as{ "txHash": "0x..." }, as confirmWith names. The response carries no confirmStepIndex, because the hash to send is always the second step’s.
The API verifies the receipt against the vault and reads the amount and the depositor from the vault’s Deposited event. A deposit sent through a smart-contract wallet is accepted when its receipt carries that event. When the vault has a Trusset record, the deposit is written to the vault’s transaction history, and recorded says so.
Response Fields
object
Error Codes
Confirming with
txHash can also return any transaction verification error.