Submit a deposit
submit_depositSubmit a deposit to MetaLend's rebalancer — moves funds. Requires a jwt from submit_auth_verify for this walletAddress, and either a signature (from prepare_deposit's signature-method output) or, for approval-based tokens, no signature at all once your wallet has already broadcast the approve() transaction on-chain. Always call prepare_deposit first — this tool does not validate amounts or resolve addresses itself (it does reject a partial set of validAfter/validBefore/nonce/signature/tokenName/tokenVersion — provide all six, or none). This call can time out on its own if the backend accepted the deposit but its response took too long to arrive. For a signature-based deposit, the trackingId needed for get_deposit_status is still recoverable then: retry with the exact same signature/nonce — it cannot double-spend (a real duplicate is rejected with a 409 signature-already-used error, which itself confirms the original deposit went through), and that error's message now includes the original trackingId, so read it from there and call get_deposit_status directly rather than escalating to support. If that error's message doesn't include a trackingId (it's only included when the conflicting deposit belongs to this same wallet), treat the timeout as inconclusive rather than a failure and escalate to support with the wallet address and approximate time instead. For an approval-based deposit (no signature), retrying after an uncertain outcome is safe in the ordinary case without needing to check status first: this tool's own amount is only used by the backend to check against your current on-chain allowance before anything is broadcast — the on-chain deposit transaction itself takes no amount parameter, it just pulls and consumes your entire then-current allowance atomically. So if the original attempt already landed, a retry finds a zero allowance and is rejected outright with a 400 ApprovalValidationError from that same pre-flight check, before anything is broadcast on-chain, rather than moving funds again. The one exception: if you separately call token.approve() again for this token/spender while an earlier submit_deposit for it is still outstanding, a retry (or the original call, if it was merely delayed rather than failed) could then consume that new allowance as a second real deposit — avoid re-approving until you've confirmed via get_deposit_status that any earlier attempt for the same token has reached a terminal state. Can also fail with a 403 if the jwt wasn't issued for this walletAddress, or a 503 if deposits are temporarily paused platform-wide. The signature must be a raw 65-byte ECDSA signature (132 hex chars, 0x-prefixed) — anything else, including an ERC-6492-wrapped or other smart-contract-wallet signature, is rejected outright regardless of validity; there is no counterfactual/smart-wallet support for deposit signatures (unlike withdrawal/config signatures). Use the approval method instead for a smart-contract wallet. Rate limited to 10 calls/minute per caller, no more than one call every 6s.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| jwt | Yes | JWT from submit_auth_verify for this walletAddress. | |
| chain | Yes | Chain name, e.g. BASE, ETHEREUM, POLYGON — the originating chain of this deposit: where the approve() call is broadcast, or for the signature flow, the chain the EIP-712 signature must validate on. Not where the rebalancer later invests the funds — deposits are naturally cross-chain in that sense, and this server only checks that the token has a signed config at all (hasSignedConfig), independent of which chains that config's domainIds allow. For an EOA, this originating chain is supported unconditionally: a raw ECDSA signature has no chain-specific verification step of its own, so any chain works. But when it comes to deposits done on a chain the wallet doesn't have configuration for, the deposit might fail if it's a smart-contract wallet that doesn't support cross-chain signatures (e.g. Coinbase's Smart Wallet / Base Smart Wallet) | |
| nonce | No | From prepare_deposit's signature-method output. | |
| token | Yes | Token symbol, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD. | |
| amount | Yes | Raw token amount as a decimal-digit string (smallest denomination). Use get_token_info for decimals. | |
| signature | No | Signature over prepare_deposit's typedData. Omit for approval-based deposits. | |
| tokenName | No | From prepare_deposit's signature-method output. | |
| validAfter | No | From prepare_deposit's signature-method output. | |
| validBefore | No | From prepare_deposit's signature-method output. | |
| tokenVersion | No | From prepare_deposit's signature-method output. | |
| walletAddress | Yes | EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted — it is normalized to its EIP-55 checksum before being forwarded upstream. |