Flash Loans

A flash loan is a loan that is borrowed and repaid within a single transaction, without collateral. The key is that everything happens inside one transaction. Because repayment happens in the same transaction, no collateral is required. The blockchain can verify whether the repayment amount is greater than or equal to the principal plus interest. If it is not, the whole transaction reverts and all state changes are rolled back. In other words, the borrowed funds are rolled back too, so the lender takes no risk.

Flash loans can also generate meaningful fee income. A single block only lasts a few seconds, yet the protocol can charge 9 basis points. In practice, flash loans are often used with very large position sizes, easily tens or even hundreds of millions of dollars.

Several parameters inside the AAVE interest-rate model interact with one another in fairly complex ways. Stable-rate borrowing is especially tricky, and the formula for the average stable rate is particularly hard to read. In real lending markets, however, many assets do not even support stable-rate borrowing, and among the assets that do, the share of stable-rate debt is very small, often well below 1%. So for beginners, it is completely reasonable to skip the stable-rate part on a first pass.

There are a few points worth highlighting in AAVE’s interest-rate logic:

1. AAVE accrues interest based on timestamps, while Compound accrues interest based on block numbers. In both protocols, rate updates are triggered by actions such as deposit, withdraw, borrow, and repay, and they are only meaningfully updated once per block.
2. Deposit interest grows linearly, while borrowing interest grows in compound form, i.e. exponentially over time.
3. A percentage of borrowing income, the reserve factor (10% by default), is routed into the protocol treasury.
4. The balanceOf method on aToken and debtToken returns the amount of underlying deposit or debt, not merely the raw token share amount.

If all you need is the high-level picture, the core AAVE flows can be summarized like this. The relevant code lives mainly in the LendingPool contract.

Centralized exchanges rely on a CLOB, or central limit order book, for matching. The matching rules are simple: price priority first, time priority second. For an exchange, the matching engine is foundational infrastructure. It must be stable, efficient, scalable, and fault-tolerant, and it must be able to recover or roll back quickly during extreme market conditions or system failures.

Smart Contract Proxies

Upgradeable smart contracts rely heavily on proxy patterns, and AAVE’s proxy system is quite complex. To really understand it, you need to unpack it layer by layer.

Global AAVE proxy diagram:

The transaction fee of uniswap is derived from the identity of x * y = K. In a specific transaction scenario, such as a loopback transaction, our transaction cost can be far lower than the rated fee.

What is a loopback transaction

The loopback transaction is a transaction in a transaction pair tokenA/tokenB, first exchange tokenA to get tokenB, and then immediately exchange the obtained tokenB back to tokenA.

The standard rate of uniswap v2 is 0.3%, then the cost of loopback transaction is 0.6%, this cost is quite high. If we are just to brush the transaction volume, we need an effective way to reduce Handling fees, loopback transactions are a very effective way.

What Is a Meta Transaction?

In simple terms, a meta transaction is a transaction submitted by a third party on behalf of the user.

The usual flow is:

1. The user constructs the transaction parameters and signs them.
2. A third party sends the signed payload to a Relay or Forwarder contract.
3. The Relay or Forwarder contract verifies the user’s signature.
4. The Relay or Forwarder contract calls the target contract.

The interest-rate model and risk control are the core of any lending protocol. In AAVE, interest updates can be divided into three parts:

1. deposit interest
2. variable borrow interest
3. stable borrow interest

As for risk control, I discuss that separately in a later article.

AAVE Architecture Overview

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.

libuv and TCP Keepalive

About Keepalive

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