Feature request: a base class for lending protocols

Preliminary Checks

• I have already searched for existing issues and confirmed that this issue is not a duplicate.

Is your feature request related to a problem? Please describe

CCXT's unified API assumes the venue's primitive is an order against a book. Lending protocols have a different primitive: supply, withdraw, borrow and repay against a reserve, with one health factor per account deciding whether the position survives.

The margin methods are not a home for it. fetchCrossBorrowRate, fetchBorrowInterest and borrowCrossMargin model an exchange margin account, so an implementation built on them would report a borrow rate and silently drop LTV, liquidation threshold, health factor, collateral flags and e-mode. Those are the numbers that decide whether a position is safe. A bot sizing leverage off that gets a plausible answer that is wrong.

Describe the solution you'd like

A second base class alongside PredictionExchange, with lending's own vocabulary: reserves and their supply and borrow rates, an account's collateral and debt with its health factor, and supply, withdraw, borrow, repay.

The prediction category is why I am asking rather than assuming the answer is no. It landed in July with its own base, its own methods, and EVM helpers inside it, sendEvmTransaction and waitForTransactionReceipt, that limitless and myriad already use. So the onchain path exists and the library has taken on a non-orderbook asset class once already.

The same base would fit Morpho, Compound, Euler and Spark, which is what makes this a category and not one venue. I am with the Aave team and can only commit to ours: v3 on 21 chains, v4 on Ethereum and Avalanche, behind one API we maintain. We would write the integration and keep it current across your language targets.

The question is whether you want the category at all. If yes, do you want to define the method set, or should we open a PR proposing one for you to pull apart?

Describe alternatives you've considered

Implementing aave as an ordinary exchange. It fails the requirements outright: no book, no trades, no OHLCV, no pairs. And forcing it onto the margin methods has the reporting problem above. Better to stay out than to ship that.