submit_deposit

io.github.rabeles11/metalend · Verify this server

Submit 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.