Common hardhat Issues

This is a growing list of common Hardhat and Solidity errors I have run into.

OpenZeppelin supports two main proxy patterns:

• Transparent proxy
• UUPS proxy

The most important difference is where the upgradeTo logic lives. In a transparent proxy, the upgrade logic is implemented in the proxy contract. In a UUPS proxy, the upgrade logic lives in the implementation contract.

Because AAVE contains many contracts, its deployment process is correspondingly complex. AAVE splits deployment into seven tasks, each implemented as a hardhat task, and then uses a full task to orchestrate deployment and initialization end to end.

Full task

Inside package.json, the project defines many deployment commands. The following one deploys to mainnet and verifies contracts:

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.