Skip to main content
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.
A deposit buys shares in the vault, not a position in this market. The vault operator places the pooled funds across its own markets, and just-in-time draws move them into a market without a decision per loan. A redemption is paid from idle funds first and then from what those markets have free, so it can fill only partially. A loss that reaches the pool of any market the vault funds lowers the share price for every holder.

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 in deposit(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.