Skip to main content
POST
Reports a broadcast deposit or redemption so the vault’s ledger records it. The backend fetches the receipt and checks that it succeeded and called the function the type claims on this vault. It reads the amount from the vault’s events, never from the request body. The ledger row carries the time of the block the transaction was mined in. This endpoint accepts the investor types only: DEPOSIT and REDEEM. The distributor and fee actions confirm on their own endpoints, by sending { "txHash": "0x..." } back to the route that built them. A transaction that reached the vault through another contract, such as a smart account, is accepted when the vault emitted the matching Deposited or Redeemed event. signedBy is then the investor that event names.

Path Parameters

string
required
Vault ID.

Body Parameters

string
required
Hash of the broadcast transaction, 0x and 64 hex characters. For a deposit, use the deposit step’s hash, not the approval’s.
string
required
DEPOSIT or REDEEM. Any other value answers VALIDATION_ERROR.

Response Fields

object
A failed confirmation does not undo the transaction. It is on-chain regardless, so retry the confirmation and the record reconciles. Never re-broadcast because a confirm call errored. Confirming the same hash again is safe, because the ledger holds one row per transaction. A confirmation also drops the cached vault state, so the next read of the vault is fresh.

Error Codes

See transaction verification errors for how to treat TX_NOT_FOUND.