Wrong tokens and recovery

Zenvault watches every ERC-20 Transfer to your addresses, not only supported tokens. A token other than BNB, USDT or USDC, a supported asset sent to an invoice for a different asset (the invoice still moves to needs_review), or BNB from a contract on an invoice address is recorded as an unexpected transfer with status detected and is NOT credited. Webhooks: deposit.unexpected for permanent addresses and invoice.unexpected_transfer for invoices. Unknown tokens have unknown value (valueUsd null) and are always sent; a supported asset worth under 0.5 USD is not.

GET /v1/unexpected-transfers lists them. POST /v1/recovery-requests (API key and Idempotency-Key) asks for funds back. Body: destination (BSC address), reason, and either unexpectedTransferIds or address plus token (BNB, USDT, USDC or a contract address) with optional amount (decimal or "all"). GET /v1/recovery-requests and GET /v1/recovery-requests/:id show status pending, approved, recovered, rejected or failed. The dashboard Recovery page does the same from the UI.

A request never moves funds. Only a Zenvault superadmin, from the admin panel, can approve and execute a recovery, and may reject it with a note. Funds already credited to you are never taken. Gas is paid from your gas address; if it is short, the request stays pending with a GAS_REQUIRED message naming the address to top up. Recovery is best effort: tokens that block or tax transfers may not be recoverable. Funds sent on another network cannot be recovered.

Warning: on BSC mainnet, BNB sent through an internal transaction (for example from a smart contract or some exchange withdrawals) may currently not be detected automatically. Ask customers to send BNB as a normal transfer. If a deposit is missing, contact support or file a recovery request with the transaction hash.