Prepare a rebalancer config update
prepare_config[DEPRECATED] Build the signing hash for updating a wallet's rebalancer configuration (which pools/protocols/chains it's allowed to move funds into), without signing anything. Computes keccak256(abi.encode(managerAddress, protocolIds, poolAddresses, domainIds, spendingCapRaw)) server-side — sign the returned hashToSign with personal_sign over its raw 32 bytes (not the UTF-8 text of the hex string) and pass the signature to submit_config. Refuses to build a config that would drop a pool you still hold a nonzero balance in — withdraw from it first (prepare_withdrawal) and retry. Also refuses an invalid spendingCapRaw (see its own field description for the exact rules), a non-null collateralExposure with no Aave pool included, containing an untracked symbol, or where no requested Aave pool's live TVL meets requiredTvl, any (domainId, protocolId, poolAddress) tuple that doesn't match a real pool in the current catalog for this token (see list_pools), or a config where every requested pool is blacklisted (see list_pools' blacklisted field) — a deposit under such a config would have no eligible destination and fail later, well after signing — rather than building a hash for it. For a smart-contract wallet: there is no single chain for this signature — the backend derives candidate chains straight from domainIds and requires the SAME signature to independently pass ERC-1271/ERC-6492 verification on EVERY chain named in domainIds, not just one; if the wallet doesn't have (deployed, or via ERC-6492 counterfactual deployment) a valid signer on all of them, the whole update is rejected. That signature must also be cross-chain transferable — supporting ERC-6492 counterfactual deployment does not by itself guarantee that. Some ERC-6492-compliant wallets intentionally bind their signature to a single network domain and are not cross-chain transferable — e.g. Coinbase's Smart Wallet (Base Smart Wallet) supports ERC-6492 but scopes its signature to one chain, so it does not support cross-chain signatures. For a wallet like that, keep domainIds restricted to that single chain (see domainIds' own field description) and sign on that exact chain, rather than mixing pools across chains. An EOA is unaffected (one ECDSA signature covers every chain). Even with a valid signature, submit_config can still be rejected with a 409 if a rebalance or deposit is currently in progress for this wallet+token, or (USDC only) a funding-cap refill is in progress — there is no read-only endpoint to check that ahead of time, so it is NOT pre-validated here; treat a 409 there as temporary and retry later (the error body includes a retryAfterSeconds hint), not as a problem with the signature itself. Rate limited to 5 calls/minute per caller, no more than one call every 12s.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token symbol this config applies to, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD. | |
| domainIds | Yes | Chain domain IDs, one per poolAddresses entry, from list_pools' signData.domainId. Max 200 entries. For a smart-contract wallet, every distinct chain named here must independently verify the SAME signature — the standards supported for smart-wallet signature verification are ERC-1271 and ERC-6492 (counterfactual deployment). Supporting ERC-6492 is not the same as producing a cross-chain-transferable signature: some ERC-6492-compliant wallets intentionally bind their signature to a single network domain, so the same signature will never verify on a second chain regardless of 6492 support. Coinbase's Smart Wallet (Base Smart Wallet) is an example — it does support ERC-6492, but its signatures are domain-bound by design, so it does not support cross-chain signatures. For a wallet like that, keep domainIds single-chain — e.g. all Base, or all Ethereum, matching whichever chain the wallet's signature is scoped to — and sign the hashToSign with that wallet's signer on that exact chain; do not mix pools from other chains into the same config, that combination will always fail verification. | |
| protocolIds | Yes | 0=Aave, 1=Morpho, 2=Euler, 3=AaveV4 — one entry per poolAddresses/domainIds entry, from list_pools' signData.protocolId. Pass only the exact set of (domainId, protocolId, poolAddress) pools you intend to allow, with no duplicate entries. Max 200 entries. | |
| requiredTvl | No | Minimum pool TVL in USD required for a pool to be eligible as a rebalance target — pools below this are skipped when the rebalancer picks where to move funds. 0 (default if omitted) disables the filter. Max 500000000. Accepts a number or a numeric string, and is always returned/forwarded as a string to preserve exact decimal precision (the backend stores this as an unrestricted-precision decimal, and get_config's own response already serializes it as a string for the same reason — pass that value straight through, it is never converted through a JS number here, which would silently round a high-precision value). When reconfiguring an existing signed config, copy this wallet's current value from get_config rather than omitting it, or you'll silently reset it to 0 (no floor). | |
| poolAddresses | Yes | Pool contract addresses to allow, from list_pools' signData.poolAddress. Max 200 entries. | |
| 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. | |
| spendingCapRaw | No | Raw units, USDC only (must be "0"/null/omitted for every other token). "0" means this feature is off (the default if omitted or null — get_config's own response serializes it as null, pass that straight through). A nonzero value turns it on and is the TARGET BALANCE MetaLend automatically keeps topped up in the wallet's OWN address (not the rebalancer contract) as Aave aUSDC + native USDC on Linea combined — it funds a card (e.g. MetaMask card) tied to this wallet that spends directly from that Linea balance. It is not a spending/deposit/withdrawal ceiling and does not limit how much can be deposited or withdrawn elsewhere. MetaLend tops the wallet back up toward this target automatically (pulling from the rebalancer's own positions, bridging cross-chain if needed) on a weekly cycle and whenever the wallet makes a fresh USDC deposit — not instantly on every call. It also biases a USDC deposit whose source chain is Linea itself to land in the Linea Aave pool first (the cheapest source for that top-up) while the wallet's own Linea balance is still under this target. Must match exactly between prepare_config and submit_config. If set nonzero, must be at least 1000000 (1 USDC) and the config must include the Aave pool on Linea. | |
| includeRewardsApy | No | Whether reward-token (e.g. Merkle) APY counts toward the total-APY comparison used to pick the best pool to rebalance into — false restricts the comparison to native lending APY only. Defaults to true if omitted. When reconfiguring an existing signed config, copy this wallet's current value from get_config rather than omitting it, or you'll silently reset it. | |
| collateralExposure | No | Whitelist of collateral asset symbols — applies only to Morpho vault selection; a vault is excluded from rebalancing if its own tracked collateral exposure includes any symbol not in this list. Each symbol must be one MetaLend actually tracks exposure for on at least one Morpho vault (see list_pools' collateralExposure values) — rejected here, before signing, otherwise. null (default if omitted) disables the filter entirely — an empty array is rejected, use null instead. Setting this to a non-null list also requires the config to include at least one Aave pool (rejected here, before signing, if none is present) whose live TVL (see list_pools' poolTvl) also meets requiredTvl — also rejected here, before signing, if none of the requested Aave pools currently qualify. When reconfiguring an existing signed config, copy this wallet's current value from get_config rather than omitting it, or you'll silently disable this filter. | |
| requiredLiquidityMultiplier | No | Requires a candidate pool's available liquidity to be at least this multiplier times the deposit amount (USD) before it's eligible as a rebalance target — a liquidity safety margin, not a percentage. 0 (default if omitted) disables the check. Max 1000. Accepts a number or a numeric string, and is always returned/forwarded as a string to preserve exact decimal precision (the backend stores this as an unrestricted-precision decimal, and get_config's own response already serializes it as a string for the same reason — pass that value straight through, it is never converted through a JS number here, which would silently round a high-precision value). When reconfiguring an existing signed config, copy this wallet's current value from get_config rather than omitting it, or you'll silently reset it to 0 (no margin required). |