The interest-rate model and risk control are the core of any lending protocol. In AAVE, interest updates can be divided into three parts:
As for risk control, I discuss that separately in a later article.
AAVE is a lending protocol, so its core revolves around four major actions: deposit, borrow, repay, and liquidation. In my view, one major reason AAVE looks complex is the existence of stable-rate borrowing, which significantly increases the complexity of the interest-rate model. Without that feature, the overall design would be much easier to understand.
The high-level AAVE architecture looks like this:
Lending was one of the earliest major applications in DeFi. A lending protocol is a smart-contract system that allows users to deposit and borrow tokens. In that sense it resembles a bank: depositors place assets into a lending application, the application lends those assets to borrowers, and depositors earn interest over time. When a borrower’s position becomes undercollateralized, liquidation is triggered. Anyone can participate in the liquidation process, and successful liquidators receive a reward. The liquidation system protects the solvency of the lending market and, in turn, the interests of depositors.
The keepalive discussed here is different from HTTP keepalive. Here we are talking about TCP-level keepalive. Its purpose is to detect network failures between two communicating machines when neither endpoint can immediately observe that the path has broken.
HTTP keepalive means adding a keep-alive header so the server does not close the TCP connection after a single request, allowing the same connection to be reused for later requests.
The Linux kernel documentation for TCP keepalive is here: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html