MetaLend

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['walletAddress'], 'properties': {'chain': {'type': 'string', 'description': "Chain name, e.g. BASE, ETHEREUM, POLYGON. Defaults to ETHEREUM if omitted. Cosmetic only â\x80\x94 shown as the 'Chain ID:' line in the SIWE message text, does not need to match the chain passed to submit_auth_verify."}, 'walletAddress': {'type': 'string', 'description': 'EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted â\x80\x94 it is normalized to its EIP-55 checksum before being forwarded upstream.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['walletAddress'], 'properties': {'tokens': {'type': 'string', 'description': "Comma-separated token symbols to restrict to (e.g. 'USDC,USDT'). Omit for all supported tokens."}, 'walletAddress': {'type': 'string', 'description': "The user's own wallet address (EOA or smart-contract wallet) â\x80\x94 the owner address they used to make deposits. This is NOT the rebalancerAddress that this tool returns: never pass a rebalancerAddress here."}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['walletAddress'], 'properties': {'walletAddress': {'type': 'string', 'description': 'EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted â\x80\x94 it is normalized to its EIP-55 checksum before being forwarded upstream.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['walletAddress'], 'properties': {'walletAddress': {'type': 'string', 'description': 'EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted â\x80\x94 it is normalized to its EIP-55 checksum before being forwarded upstream.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['token'], 'properties': {'token': {'type': 'string', 'description': 'Token symbol, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['trackingId'], 'properties': {'trackingId': {'type': 'string', 'description': 'trackingId returned by submit_deposit.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['walletAddress'], 'properties': {'reloadChain': {'type': 'string', 'description': "Chain name to force a fresh reload for (e.g. 'BASE'). Omit to use cached data."}, 'walletAddress': {'type': 'string', 'description': 'EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted â\x80\x94 it is normalized to its EIP-55 checksum before being forwarded upstream.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['token', 'chain'], 'properties': {'chain': {'type': 'string', 'description': 'Chain name, e.g. BASE, ETHEREUM, POLYGON.'}, 'token': {'type': 'string', 'description': 'Token symbol, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['token'], 'properties': {'token': {'type': 'string', 'description': 'Token symbol, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['trackingId'], 'properties': {'trackingId': {'type': 'string', 'description': 'trackingId returned by submit_withdrawal.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'properties': {}}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'properties': {}}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['walletAddress', 'token', 'protocolIds', 'poolAddresses', 'domainIds'], 'properties': {'token': {'type': 'string', 'description': 'Token symbol this config applies to, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD.'}, 'domainIds': {'type': 'array', 'items': {'type': 'integer'}, 'maxItems': 200, 'description': "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 â\x80\x94 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 â\x80\x94 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 â\x80\x94 e.g. all Base, or all Ethereum, matching whichever chain the wallet's signature is scoped to â\x80\x94 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': {'type': 'array', 'items': {'type': 'integer'}, 'maxItems': 200, 'description': "0=Aave, 1=Morpho, 2=Euler â\x80\x94 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': {'type': ['number', 'string'], 'description': "Minimum pool TVL in USD required for a pool to be eligible as a rebalance target â\x80\x94 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 â\x80\x94 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': {'type': 'array', 'items': {'type': 'string', 'pattern': '^0x[a-fA-F0-9]{40}$'}, 'maxItems': 200, 'description': "Pool contract addresses to allow, from list_pools' signData.poolAddress. Max 200 entries."}, 'walletAddress': {'type': 'string', 'description': 'EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted â\x80\x94 it is normalized to its EIP-55 checksum before being forwarded upstream.'}, 'spendingCapRaw': {'anyOf': [{'type': 'string', 'pattern': '^\\d+$'}, {'type': 'null'}], 'description': '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 â\x80\x94 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 â\x80\x94 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 â\x80\x94 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': {'type': 'boolean', 'description': "Whether reward-token (e.g. Merkle) APY counts toward the total-APY comparison used to pick the best pool to rebalance into â\x80\x94 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': {'anyOf': [{'type': 'array', 'items': {'type': 'string', 'minLength': 1}, 'maxItems': 200, 'minItems': 1}, {'type': 'null'}], 'description': "Whitelist of collateral asset symbols â\x80\x94 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) â\x80\x94 rejected here, before signing, otherwise. null (default if omitted) disables the filter entirely â\x80\x94 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 â\x80\x94 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': {'type': ['number', 'string'], 'description': "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 â\x80\x94 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 â\x80\x94 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)."}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['chain', 'token', 'walletAddress', 'amount'], 'properties': {'chain': {'type': 'string', 'description': "Chain name, e.g. BASE, ETHEREUM, POLYGON â\x80\x94 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 â\x80\x94 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': {'type': 'string', 'description': 'Token symbol, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD.'}, 'amount': {'type': 'string', 'pattern': '^\\d+$', 'description': 'Raw token amount as a decimal-digit string (smallest denomination). Use get_token_info for decimals.'}, 'method': {'enum': ['signature', 'approval'], 'type': 'string', 'description': "Force a specific flow. Defaults to 'signature' for gasless-eligible tokens, else 'approval'."}, 'walletAddress': {'type': 'string', 'description': 'EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted â\x80\x94 it is normalized to its EIP-55 checksum before being forwarded upstream.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['walletAddress', 'chain', 'token', 'poolContract'], 'properties': {'chain': {'type': 'string', 'description': 'Chain name, e.g. BASE, ETHEREUM, POLYGON.'}, 'token': {'type': 'string', 'description': 'Token symbol, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD. Required to disambiguate â\x80\x94 some pool addresses serve multiple tokens.'}, 'amount': {'anyOf': [{'type': 'string', 'const': 'MAX'}, {'type': 'string', 'pattern': '^\\d+$'}], 'description': 'Raw amount to withdraw. Omit or pass "MAX" for a full withdrawal (uses maxUint256).'}, 'poolContract': {'type': 'string', 'pattern': '^0x[a-fA-F0-9]{40}$', 'description': "Pool contract address, from get_balances' perPool[].poolAddress. Combined with `chain` to identify the exact balance â\x80\x94 the same address can exist on several chains."}, 'walletAddress': {'type': 'string', 'description': 'EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted â\x80\x94 it is normalized to its EIP-55 checksum before being forwarded upstream.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['walletAddress', 'signature'], 'properties': {'chain': {'type': 'string', 'description': "Chain name, e.g. BASE, ETHEREUM, POLYGON. Defaults to ETHEREUM if omitted. For an EOA wallet this is irrelevant (signature recovery is chain-agnostic). For a smart-contract wallet, this MUST be the chain it has (or, if undeployed, would have via ERC-6492 counterfactual deployment) a valid signer on for this signature â\x80\x94 it determines which chain's RPC is queried to validate it (ERC-1271/6492), and does not need to match the chain passed to get_auth_challenge."}, 'signature': {'type': 'string', 'description': 'personal_sign signature of the SIWE message from get_auth_challenge.'}, 'walletAddress': {'type': 'string', 'description': 'EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted â\x80\x94 it is normalized to its EIP-55 checksum before being forwarded upstream.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['jwt', 'walletAddress', 'token', 'protocolIds', 'poolAddresses', 'domainIds', 'signature'], 'properties': {'jwt': {'type': 'string', 'description': 'JWT from submit_auth_verify for this walletAddress.'}, 'token': {'type': 'string', 'description': 'Token symbol this config applies to, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD.'}, 'domainIds': {'type': 'array', 'items': {'type': 'integer'}, 'maxItems': 200, 'description': "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 â\x80\x94 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 â\x80\x94 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 â\x80\x94 e.g. all Base, or all Ethereum, matching whichever chain the wallet's signature is scoped to â\x80\x94 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."}, 'signature': {'type': 'string', 'description': "Signature over prepare_config's hashToSign."}, 'protocolIds': {'type': 'array', 'items': {'type': 'integer'}, 'maxItems': 200, 'description': "0=Aave, 1=Morpho, 2=Euler â\x80\x94 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': {'type': ['number', 'string'], 'description': "Minimum pool TVL in USD required for a pool to be eligible as a rebalance target â\x80\x94 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 â\x80\x94 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': {'type': 'array', 'items': {'type': 'string', 'pattern': '^0x[a-fA-F0-9]{40}$'}, 'maxItems': 200, 'description': "Pool contract addresses to allow, from list_pools' signData.poolAddress. Max 200 entries."}, 'walletAddress': {'type': 'string', 'description': 'EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted â\x80\x94 it is normalized to its EIP-55 checksum before being forwarded upstream.'}, 'spendingCapRaw': {'anyOf': [{'type': 'string', 'pattern': '^\\d+$'}, {'type': 'null'}], 'description': '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 â\x80\x94 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 â\x80\x94 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 â\x80\x94 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': {'type': 'boolean', 'description': "Whether reward-token (e.g. Merkle) APY counts toward the total-APY comparison used to pick the best pool to rebalance into â\x80\x94 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': {'anyOf': [{'type': 'array', 'items': {'type': 'string', 'minLength': 1}, 'maxItems': 200, 'minItems': 1}, {'type': 'null'}], 'description': "Whitelist of collateral asset symbols â\x80\x94 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) â\x80\x94 rejected here, before signing, otherwise. null (default if omitted) disables the filter entirely â\x80\x94 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 â\x80\x94 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': {'type': ['number', 'string'], 'description': "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 â\x80\x94 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 â\x80\x94 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)."}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['jwt', 'chain', 'token', 'walletAddress', 'amount'], 'properties': {'jwt': {'type': 'string', 'description': 'JWT from submit_auth_verify for this walletAddress.'}, 'chain': {'type': 'string', 'description': "Chain name, e.g. BASE, ETHEREUM, POLYGON â\x80\x94 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 â\x80\x94 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': {'type': 'string', 'description': "From prepare_deposit's signature-method output."}, 'token': {'type': 'string', 'description': 'Token symbol, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD.'}, 'amount': {'type': 'string', 'pattern': '^\\d+$', 'description': 'Raw token amount as a decimal-digit string (smallest denomination). Use get_token_info for decimals.'}, 'signature': {'type': 'string', 'description': "Signature over prepare_deposit's typedData. Omit for approval-based deposits."}, 'tokenName': {'type': 'string', 'description': "From prepare_deposit's signature-method output."}, 'validAfter': {'type': 'string', 'description': "From prepare_deposit's signature-method output."}, 'validBefore': {'type': 'string', 'description': "From prepare_deposit's signature-method output."}, 'tokenVersion': {'type': 'string', 'description': "From prepare_deposit's signature-method output."}, 'walletAddress': {'type': 'string', 'description': 'EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted â\x80\x94 it is normalized to its EIP-55 checksum before being forwarded upstream.'}}, 'additionalProperties': False}

{'type': 'object', '$schema': 'http://json-schema.org/draft-07/schema#', 'required': ['jwt', 'chain', 'token', 'walletAddress', 'amount', 'deadline', 'signature', 'poolContract'], 'properties': {'jwt': {'type': 'string', 'description': 'JWT from submit_auth_verify for this walletAddress.'}, 'chain': {'type': 'string', 'description': "From prepare_withdrawal's output."}, 'token': {'type': 'string', 'description': 'Token symbol, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD.'}, 'amount': {'type': 'string', 'pattern': '^\\d+$', 'description': "From prepare_withdrawal's output."}, 'deadline': {'type': 'string', 'description': "From prepare_withdrawal's output."}, 'signature': {'type': 'string', 'description': "Signature over prepare_withdrawal's typedData."}, 'poolContract': {'type': 'string', 'pattern': '^0x[a-fA-F0-9]{40}$'}, 'walletAddress': {'type': 'string', 'description': 'EVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted â\x80\x94 it is normalized to its EIP-55 checksum before being forwarded upstream.'}}, 'additionalProperties': False}