Skip to main content
POST
Transfers seized collateral from the liquidation router to the market’s sale recipient, so it can be sold off-platform. This is step one of the manual settlement workflow, signed by a holder of the router’s OPERATOR_ROLE.
Once collateral leaves the router, the record can only settle with sale proceeds reported against it. If the sale realizes nothing, the router refuses a settlement at zero. The market’s record then waits for the 7 day write-off in Handle Liquidation Timeout. Withdraw only what a sale is arranged for.The destination is not yours to choose. The lender of record fixed the sale recipient when it adopted the market, and the router call carries no recipient at all. The router administrator can rotate it only through an announced change that takes effect after a one-hour delay and is refused while any record on the router is open. This API does not expose that rotation.
A record on a router in two-step mode does not sell itself. The operator withdraws the collateral, arranges the sale through their own channel, and reports the proceeds back with Report Partial Sale or Settle Liquidation. Where the atomic sale is offered, Sell Pending Liquidation sells a whole record to the sale recipient instead, but only before any of its collateral is withdrawn.

Path Parameters

string
required
Liquidation ID on the market’s router, from Get Pending Liquidations or from the Liquidate Loan response.

Body Parameters

string
required
Collateral to withdraw, as a decimal string in collateral token units, at most as many decimals as the collateral token has. Must be greater than zero. An amount above collateralRemaining is not refused here; the router reverts it. Required on the confirm call too.
string
The destination is fixed on the market, so this field cannot choose one. Supply nothing, or supply exactly the market’s saleRecipient. Any other address is refused with RECIPIENT_FIXED, and the refusal names the recipient the market will accept.
string
Names the market whose liquidation you mean. Every market runs its own liquidation router and IDs restart at 1 on each of them, so the same liquidationId can exist on several markets in one instance. Supply this when it does, otherwise the call is refused with AMBIGUOUS_LIQUIDATION_ID and the response lists the candidates. Also accepted as a query parameter. At most 100 characters.
string
Hash of the transaction you broadcast for this operation. Send it together with amount to confirm the transaction and record the result. Omit it to receive the calldata. A value that is not 0x followed by 64 hex characters is refused with 400 VALIDATION_ERROR and nothing is built or recorded. null or an empty string counts as omitted.
The wallet that signs must hold OPERATOR_ROLE on the market’s liquidation router. This endpoint checks the role against your instance’s primary verified wallet, since it takes no signer address. If that wallet lacks the role, the calldata is not returned: the response carries ROUTER_OPERATOR_ROLE_MISSING along with the calldata that grants it.

Response Fields

object
Withdrawal is repeatable. Take the collateral out in tranches as sales are arranged. Each call reduces collateralRemaining on the router. The liquidation’s status stays PENDING throughout, so track progress through collateralRemaining rather than status. If the router administrator set a sale rate limit for the collateral token, a tranche above it reverts.
If the liquidation ID exists on-chain but has no Trusset record, the endpoint adopts it automatically by scanning your instance’s routers. Liquidations triggered outside this API are therefore still settleable through it.

Error Codes

Confirming with txHash can also return any transaction verification error. A withdrawal that reverted on-chain is refused there with TX_REVERTED.