Guide to Reading Blockchain Lending Transactions on Chain

Read and understand blockchain transactions series

Blockchain lending transactions can be confusing, many of them use a different type of system and your debt is calculated & tracked in a way that users can’t see unless they know how to look. To help, we will go through an on-chain lending transaction to help auditors and researchers understand how a lending transaction works. The hope of this article is that it will tie in some nuances as to the variables there are to consider with a blockchain lending transaction and the parties that are involved in facilitating said transaction.

This example works specifically with a decentralized platform because they are the most nuanced to understand.

The following transaction took place on Arbitrum (an Ethereum L2) on the Aave protocol platform:

---

Supplying Assets - What tokens look like, what you get

Green - A summary of what the transaction is showing, we supplied 0.03 WETH (Ethereum) to Aave.

The user (0xe0dad03b) called the ‘supply()’ function on the Aave Pool V3 contract, depositing 0.03 WETH (Wrapped Ether) as collateral.

Red - A break down of the parties that are transacting

1. 0.03 WETH moves from the user’s wallet to the aWETH token contract (Aave: aWETH Token V3). This is the actual collateral being deposited into the pool.

2. 0.029999999999999999 aWETH tokens are minted from the null address (0x000) to the user. This is the receipt token. The aWETH token represents the user’s deposit and will grow in value over time as interest accrues. The tiny rounding difference (one wei less than 0.03) is due to Aave’s internal scaling math.

Orange - A break down of the transaction fees

This is a breakdown of how much the transaction costs denominated in Ethereum, the fee for this transaction was $0.008689

---

Deep-Dive Supply Breakdown (Can skip if you just want the basics)

These are the logs, they show what real functions were called and the parameters used in each function.

1. (39) ReserveDataUpdated - Before anything moves, Aave updates the global state of the WETH reserve. This log records the current liquidity rate (~1.81%), variable borrow rate (~2.4%), and critically the liquidityIndex (1.0596) and variableBorrowIndex (1.1104). These indices are the compound interest accumulators → they only go up over time, and they’re how Aave tracks interest without updating every individual user’s balance.

2. (40) WETH Transfer - 0.03 WETH moves from the user’s wallet to the aWETH token contract (0xe50fA9b3...). This is the actual collateral being deposited into the pool.

3. (41) Approval — The WETH contract logs that the user still has a remaining approval of 0.97 WETH for the Aave Pool to spend in the future. This is left over from the user’s prior approval transaction.

4. (42) aWETH Transfer (Mint) - 0.029999999999999999 aWETH tokens are minted from the null address (0x000...000) to the user. This is the receipt token. The aWETH token represents the user’s deposit and will grow in value over time as interest accrues. The tiny rounding difference (one wei less than 0.03) is due to Aave’s internal scaling math.

5. (43) Mint event - Confirms the mint was for the user, shows balanceIncrease: 0 (this is the user’s first deposit, so no prior interest had accumulated), and records the index: 1059592412944783121040725824 - this is the liquidityIndex at the time of deposit, which Aave stores as the user’s personal “entry point” for calculating future interest.

6. (44) ReserveUsedAsCollateralEnabled - This event fires because it’s the user’s first supply of WETH. It tells Aave’s risk engine to count this asset as collateral for borrowing purposes. If the user had previously supplied WETH and already enabled it as collateral, this event would not fire again.

7. (45) Supply event - The official Aave Supply event logs the reserve (WETH), user, amount (30000000000000000 = 0.03 in 18-decimal format), and referral code (0).

What an auditor should understand

The user gave up 0.03 WETH and received ~0.03 aWETH. The aWETH is a yield-bearing receipt token - it doesn’t sit static. Its balance will passively increase over time as the liquidityIndex grows. The user’s WETH is now in the Aave pool and can be borrowed by others. The aWETH token is the proof of deposit and the claim to get the WETH back.

---

Borrowing - Variable debt tokens and what they mean

Green - A summary of the transaction with borrowing 10 USDC and receiving variableDebt (interest) token.

The same user (0xe0dad03b) called borrow() on the Aave Pool, requesting 10 USDC at variable rate. They could do this because they had just deposited 0.03 WETH (~$67.76) as collateral, which gave them borrowing power.

Red - Break down of the party and contracts transacting.

1. 10.000001 variable debt tokens are minted from the null address to the user. This is the mirror image of the aToken from the supply step, but instead of representing a deposit, it represents a debt.

2. The contract is at 0xf611aeb5... → this is the variableDebtUSDC token. The extra 0.000001 is a rounding artifact from Aave’s ray math. The variabledebt token is the **ERC20 *****

3. 10 USDC (10000000 in 6-decimal format) moves from the aUSDCn token contract (0x724dc807... → the Aave liquidity pool for USDC) to the user’s wallet.

Orange - A break down of the transaction fees.

---

Deep-Dive Borrow Breakdown (Can skip if you just want the basics)

The logs show the full break-down of the borrowing transaction with function calls and parameters.

1. (15) Variable Debt Token Transfer (Mint) - 10.000001 variable debt tokens are minted from the null address to the user. This is the mirror image of the aToken from the supply step, but instead of representing a deposit, it represents a debt. The contract is at 0xf611aeb5... - this is the variableDebtUSDC token. The extra 0.000001 is a rounding artifact from Aave’s ray math.

2. (16) Mint event on the debt token - Confirms the mint, shows balanceIncrease: 0 (brand new debt, no prior interest), and records the index: 1217793984420741688691991357. This is the variableBorrowIndex at the moment of borrowing - the user’s personal “entry point” for calculating how much interest they’ll owe later.

3. (17) ReserveDataUpdated - Aave recalculates the USDC reserve’s state after this borrow. The new variable borrow rate is ~3.09% and the liquidity rate is ~1.55%. Notice these are different from the WETH reserve’s rates in the supply transaction - each asset has its own independent interest rate market.

4. (18) USDC Transfer - 10 USDC (10000000 in 6-decimal format) moves from the aUSDCn token contract (0x724dc807... - the Aave liquidity pool for USDC) to the user’s wallet. This is the actual borrowed money arriving in the user’s wallet.

5. (19) Borrow event - The official Aave Borrow event logs everything: the reserve (USDC), user, amount (10000000), interestRateMode (2 = variable), and the borrowRate at time of borrow.

What the auditor should understand: The user now holds two Aave token positions - aWETH (their collateral receipt an asset, worth ~$67.76) and variableDebtUSDC (their liability, worth $10). The variable debt token balance will increase over time as interest accrues, just like the aToken balance increases - but in the opposite direction. The debt token is non-transferable; the user can't send it to someone else to shift the debt. The 10 USDC was actually taken from the liquidity pool that other users (suppliers) deposited into.

---

Bonus - Calculating principal vs. interest for any user's debt

Here’s how an auditor can reconstruct the breakdown for any position at any point in time:

The formula:

Actual debt = scaledBalance × (current variableBorrowIndex / user's borrowIndex at origination)

Principal = original amount borrowed

Accrued interest = Actual debt - Principal

Worked example using Tx 4 (the 123 USDC repayment):

We know from the Burn event that:

• The debt tokens burned were 116.954020 (scaled balance)

• The balanceIncrease (interest) was 6.045979 USDC

• The current variableBorrowIndex was 1.21793...

So the user’s total debt at the moment of repayment was approximately: 116.954020 + 6.045979 = ~123.0 USDC (which matches the 123 USDC they sent).

If the user had borrowed, say, 117 USDC originally, then the principal was 117 and the interest was ~6 USDC.

How to do this for any user at any time without a repayment event:

1. Look up the user’s scaledBalance on the variable debt token contract (this is a read call → scaledBalanceOf(userAddress))

2. Look up the current variableBorrowIndex from the reserve data (read call on the Pool contract → getReserveData(assetAddress))

3. Look up the user’s personal borrow index from their original Borrow transaction’s Mint event

4. Calculate: current debt = scaledBalance × (current variableBorrowIndex / borrow-time index)

5. Interest = current debt - original principal

Where to find these on-chain:

• Scaled balance: Call scaledBalanceOf() on the variable debt token contract

• Current index: Available in real-time from the Pool contract’s getReserveData() function or from the most recent ReserveDataUpdated event on that reserve

• Original borrow index: Go back to the user’s original Borrow transaction, find the Mint event on the debt token, and read the index field

This is entirely verifiable by anyone with a block explorer. No custodian, no statement, no trust required → just math and public data.

---

Conclusion:

Blockchain lending serves the same purpose as traditional collateralized lending, but the reporting infrastructure is fundamentally different.

There is no custodian producing statements. Collateral is held by code, not an institution. Interest doesn’t accrue on a schedule - it’s calculated mathematically from a global index that only updates when someone interacts with the protocol. This means a user’s true debt between transactions exists as math, not as a stored balance.

Auditors can’t just pull a token balance at face value they must either:

1. Need the original borrow transaction’s index, the current index, and the scaled balance to derive the real position.

2. Need to take account of the variabledebt tokens and the receipt supply tokens which are usually shown as a ERC 20 ***.

The data is public and verifiable, but it requires a new skill set to extract. The risks are also different: oracle failures, smart contract bugs, and governance votes can change the terms of a loan after origination → risks that have no parallel in traditional custodian reporting. For auditors, the blockchain replaces the custodian’s ledger, but reading it demands understanding the mechanics this article has walked through.

Supply Txn (Me)

https://arbiscan.io/tx/0x662fa2fbcfced014ad92b2a9285953a34603af330feacebf5ca12edc46dca5d4

Borrow Txn (Me)

https://arbiscan.io/tx/0x9cfc08c661c8ce079dae41211d93c3704baa829fb2fba804ec4296087268b498

Repayment Txn (Example)

https://arbiscan.io/tx/0x6f6af8e3588fb110d579c8fbaedc1915ad9aa2ea1995711c987ffc4f3ae7371b

https://arbiscan.io/tx/0x545bed62139aa887f42a3b37f6d39b7d35fa81a07bd5b8b8c1fcb73eb4ea2fc6#eventlog