Prepare a deposit
prepare_deposit[DEPRECATED] Build everything needed to deposit into MetaLend's rebalancer, without signing anything. For gasless tokens (USDC, MUSD, PYUSD) returns an EIP-712 ReceiveWithAuthorization typed-data payload — sign it with your own wallet and pass the signature to submit_deposit. For approval-only tokens (USDT, RLUSD, USDG, USDE) returns on-chain approve() parameters instead — your wallet must broadcast that approval itself (this server has no RPC access and cannot do it for you), then call submit_deposit with no signature. The signature flow only accepts a raw 65-byte EOA-style ECDSA signature — smart-contract wallets (including via ERC-6492 counterfactual deployment) are rejected regardless of validity, even for gasless-eligible tokens. A smart-contract wallet should instead pass method: "approval" explicitly here (works for any token, needs no signature at all) — but chain must then be one that wallet can actually transact on (see chain's own field description); this server cannot validate that. Requires a signed rebalancer config for this token already (use prepare_config/submit_config first if get_config shows none) — and validates the amount against the chain's minimum deposit — before returning anything, so a doomed request never reaches signing. A fixed on-behalf gas fee (see fee in the response, also available standalone via get_transaction_costs) is deducted from amount before the rebalancer credits it — the response's expectedCreditedAmountRaw is what will actually show up in get_balances after the deposit lands, not the full amount you send. Rate limited to 6 calls/minute per caller, no more than one call every 10s.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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) | |
| 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. | |
| method | No | Force a specific flow. Defaults to 'signature' for gasless-eligible tokens, else 'approval'. | |
| 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. |