Recover a failed deposit with an owner signature
Return a failed or rejected deposit’s source-chain funds to a destination the user signed for, authorized by the deposit RECIPIENT’s EIP-712 signature rather than by the API key. The server reconstructs the RecoverDeposit typed data from the stored deposit row and verifies the signature against that row’s recipient — on the deposit’s TARGET chain, where the recipient wallet lives — accepting a raw ECDSA signature (embedded EOA), an ERC-1271 signature (deployed smart account) or an ERC-6492 wrapper (counterfactual account). It then runs the same claim + transfer path as the refund endpoint. Because the signature is the authorization boundary, this route is safe to expose to a browser and a read-scoped x-api-key is sufficient. EVM on both source and target chains.
Headers
API key for authentication (omit when sending Authorization)
"your-api-key"
Bearer platform token (e.g. forwarded by user-service). Takes precedence over x-api-key when both are present.
"Bearer eyJhbGciOi..."
Body
Deposit id, as returned by GET /deposits. Identifies the row directly: one transaction can produce several deposits, so a {chain, txHash, account, token} tuple does not.
^\d+$"2551"
Address to receive the recovered tokens on the deposit's source chain. Covered by the signature, so the caller cannot redirect an authorized recovery.
^0x[a-fA-F0-9]{40}$"0x742d35Cc6634C0532925a3b844Bc9e7595f5bE91"
Signature by the deposit recipient over the RecoverDeposit typed data, in whatever form that account verifies: raw ECDSA (EOA), ERC-1271 (deployed smart account), or ERC-6492-wrapped (undeployed).
132 - 8194^0x([a-fA-F0-9]{2})+$"0x1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111"