> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trusset.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Vaults

> Deposit into a bank-operated earning vault and redeem shares

An operator vault is a bank issuer's own earning product. Verified investors deposit the vault's settlement asset (a stablecoin such as USDC) and receive vault shares. The operator is the lender of record on its external-securities lending markets and allocates the pooled funds into those markets as the liquidity provider. Share price covers idle funds plus the vault's value across every market it funds, so it rises as the markets pay interest.

Trusset holds no role on any vault. Each vault belongs to the issuer operating it, and every response names that operator in `operatedBy`. Show the operator wherever you show the vault.

This API covers the investor side: discovering vaults, reading positions, depositing, and redeeming. Creating a vault, allocating into markets, pausing deposits, lowering the fee, and publishing are operator actions done in the Issuer Portal.

## Base Path

```
https://api.trusset.org/lending-external-securities/api/vaults
```

Every request authenticates with an instance API key in the `X-API-Key` header. See [Authentication](/endpoints/authentication). The instance bound to your key determines which vaults you see: your own instance's vault, plus every vault a bank has published on your network.

| Endpoint                                                       | Method | Purpose                                                              |
| -------------------------------------------------------------- | ------ | -------------------------------------------------------------------- |
| [List Vaults](/endpoints/vaults/list-vaults)                   | GET    | Your vault first, then every published vault                         |
| [Get Vault](/endpoints/vaults/get-vault)                       | GET    | Full record, live chain state, optional holder position              |
| [Get Position](/endpoints/vaults/get-position)                 | GET    | One wallet's shares and value                                        |
| [List Transactions](/endpoints/vaults/list-vault-transactions) | GET    | Recorded vault activity                                              |
| [Deposit](/endpoints/vaults/deposit)                           | POST   | Approve-and-deposit calldata for a verified wallet                   |
| [Redeem](/endpoints/vaults/redeem)                             | POST   | Redemption calldata                                                  |
| [Confirm Transaction](/endpoints/vaults/confirm-transaction)   | POST   | Records a broadcast deposit or redemption after receipt verification |

## Redemptions

An operator can pause deposits. Nothing can pause a redemption. When market utilization blocks part of the vault's value, a redemption pays out what liquidity allows and the remaining shares stay in the wallet. See [Redeem](/endpoints/vaults/redeem).

## Failed reads

The chain state on [Get Vault](/endpoints/vaults/get-vault) carries a `readFailed` flag. When it is `true` the figures are absent, not zero. Keep your last verified values on screen and retry. A vault whose read failed still holds every deposit it held a minute ago.

## Response envelope

```json theme={null}
{
  "success": true,
  "data": { },
  "error": null,
  "metadata": {
    "timestamp": "2026-08-14T12:00:00.000Z",
    "requestId": "550e8400-e29b-41d4-a716-446655440000",
    "instanceId": "inst_abc123"
  }
}
```

On failure, `success` is `false`, `data` is `null`, and `error` carries `code` and `message`. Schema failures use `VALIDATION_ERROR` with `error.details` listing each offending field. `metadata.requestId` always equals the `X-Request-Id` response header, so you can quote it when reporting a problem. Always branch on `success` rather than on the HTTP status alone.

## Writes

Every write endpoint returns unsigned transaction data for a wallet you control to sign and broadcast. Nothing is submitted on your behalf. After broadcasting, report the hash to [Confirm Transaction](/endpoints/vaults/confirm-transaction). The backend verifies the receipt on-chain before recording anything.