Mapping DeFi Protocol Ecosystems

Hello, and welcome to the first lesson in this DeFi course. We will begin with a discipline that makes every later topic easier: drawing a protocol map before judging yields, token prices, or risk.

A DeFi protocol is not just a website or a smart contract. It is a system of people, tokens, contracts, permissions, interfaces, and outside services. In this lesson, Aave V3 serves as a concrete example of a pooled lending protocol. The objective is not to memorize its every component, but to learn a reusable method for mapping any protocol precisely enough to know what is doing what, where assets sit, and which assumptions make the system work.

---

Start with the right unit of analysis

“DeFi protocol” is often too broad a unit. Aave, for example, has deployments on multiple networks. Each deployment has a particular set of contract addresses, supported assets, governance-controlled parameters, and chain-specific conditions. A useful map therefore starts with a scope statement:

Scope: Aave V3 market on one specified blockchain, during one specified period.

This prevents a common error: combining an Ethereum contract, an asset available only on another network, and a governance decision made at a different time into one imaginary system.

A complete protocol map answers six questions:

Map layer	Core question
Users and organizations	Who interacts with the system, and in what role?
Assets and claims	What tokens enter, leave, or represent positions in the system?
Core contracts	Which contracts hold assets, execute actions, and record claims?
Governance and permissions	Who can change parameters or contract configuration?
Interfaces	How do people, applications, and contracts access the system?
External dependencies	What must work correctly even though it is outside the protocol’s core contracts?

The point is not merely to list names. A map must state the relationship between them. “Chainlink” written in a box is not helpful; “price data enters the lending market through an oracle contract, affecting borrowing capacity and liquidation eligibility” is useful.

---

The pooled-lending intuition

Aave is a non-custodial liquidity protocol: users submit transactions from their own wallets, while smart contracts enforce the lending rules. “Non-custodial” does not mean assets are risk-free or never held by contracts. Once supplied, underlying tokens are controlled by the protocol’s contract logic rather than by the supplier’s wallet. The user retains control of their wallet and transaction signatures, but takes smart-contract, governance, oracle, and market-liquidity risks.

Before moving into the contract map, watch this compact conceptual explanation.

In a pooled market, suppliers do not select a specific borrower. Instead, they contribute assets to a reserve managed by the protocol. Borrowers access available liquidity from that reserve after posting eligible collateral. Interest paid by borrowers is the economic source of supplier yield, after any portion retained by the protocol under its configured rules.

The pooled-lending interaction diagram below is a useful first map. It shows users supplying to and borrowing from the Pool, receipt and debt tokens being minted or burned, and a portion of interest potentially accruing to a treasury.

Treat this picture as a functional map. The next step is to identify the specific on-chain objects behind each function.

---

Assets are not all the same kind of thing

A protocol map becomes much clearer when you separate an asset from the token that represents a claim on that asset.

For an Aave market, the asset layer contains at least four distinct categories:

Asset or claim	Holder	Meaning in the map
Underlying reserve asset	Pool contract while supplied; borrower after a loan	The original ERC-20 token, such as USDC or WETH
aToken	Supplier’s wallet	Interest-bearing claim linked to supplied assets in a specific reserve
Variable debt token	Borrower’s account	Non-transferable accounting representation of an outstanding variable-rate debt
Governance or safety token position	Governance participants or safety-module participants	A governance-related claim, distinct from a lending-market deposit or debt position

A supplier who deposits USDC does not simply “earn more USDC” as a wallet balance. They receive an aToken position representing their claim on the Pool. In Aave’s model, the aToken balance reflects interest accumulation. Withdrawing redeems this claim for the underlying asset, subject to two constraints:

1. The reserve must have enough unborrowed liquidity available.
2. If the supplier uses that deposit as collateral, their withdrawal must not make their own borrowing position unsafe.

A borrower has a different kind of claim and obligation. They hold borrowed underlying assets in their wallet, but their account carries debt represented by a variable debt token. This difference matters: an aToken is a claim on a reserve; a debt token records an obligation to it.

The protocol therefore has several different “balances” that should never be collapsed into one number:

• tokens in a user’s wallet;
• underlying tokens held by the Pool;
• aTokens held by suppliers;
• debt positions attributed to borrowers;
• any reserve share set aside for the protocol treasury.

---

The Aave V3 contract map

The main interaction contract is the Pool. From a user’s perspective, supplying, withdrawing, borrowing, repaying, and liquidating are operations routed through this core entry point. But the Pool is not the entire protocol. It relies on a set of surrounding contracts that define permissions, track assets, calculate rates, and provide prices.

Here is a compact map of the principal components and their jobs:

Component	Primary function	Main relationships
Pool	Executes core lending operations and manages reserves	Receives user actions; interacts with reserve tokens, aTokens, debt tokens, pricing, and rate logic
aToken	Represents supplied liquidity and accrued supplier interest	Minted when a user supplies; burned when they withdraw
VariableDebtToken	Represents a user’s variable-rate debt	Created or increased when a user borrows; reduced when they repay
PoolConfigurator	Applies permitted changes to Pool configuration	Used by authorized system roles for reserve and risk configuration
ACLManager	Registry for permissioned roles	Determines who may call particular administrative functions
PoolAddressesProvider	Registry of key protocol component addresses	Points the market to components such as the Pool and ACLManager; may update pointers or proxy implementations
AaveOracle	Supplies asset-price information through registered sources	Prices collateral and debt for borrowing limits and liquidation calculations
PriceOracleSentinel	Restricts selected operations if oracle conditions are unhealthy	Adds a protective check around reliance on price data
Interest-rate strategy	Calculates borrowing and lending rate behavior from reserve conditions	Helps align borrowing demand with available liquidity
Data-provider and helper contracts	Make data access or transaction preparation easier	Support front ends, integrators, and user-facing applications

This map reveals an important analytical rule:

The contract that executes a user action may not be the contract that decides whether the action is allowed, safe, or configurable.

For example, the Pool processes a borrow, but the decision logic relies on reserve parameters, user collateral, debt, oracle prices, and permissions established elsewhere. A protocol map should consequently show both the visible transaction endpoint and the less visible control and data components around it.

---

Users, interfaces, and dependencies

Now add the actors surrounding the contracts.

Users and organizations

At minimum, an Aave-style lending map includes these roles:

• Suppliers: deposit underlying assets, receive aTokens, and seek interest income.
• Borrowers: post collateral and draw liquidity from supported reserves.
• Liquidators: monitor unhealthy accounts, repay eligible debt, and receive collateral at a configured discount.
• Governance participants: token holders, delegates, proposal authors, voters, and authorized executors involved in changing protocol rules.
• Authorized risk or operational roles: addresses granted permissions through the ACL system to execute approved configuration actions.
• Developers and application integrators: build wallets, dashboards, vaults, aggregators, or other products that call Aave contracts.
• Vault managers, where vault products are used: configure strategies and fee arrangements around user deposits, creating an additional layer between a depositor and the core market.

A single wallet can occupy several of these roles. A borrower may also supply collateral; a governance participant may also be a liquidator. Roles describe what an account does in the system, not its identity.

Interfaces

An interface is the route by which an actor accesses a protocol. It is not necessarily part of the protocol’s trusted core.

Interface	Typical user	What it does	Key distinction
Web or mobile front end	Supplier or borrower	Presents balances and prepares transactions	A convenient access layer; not the Pool itself
Wallet	Any transacting user	Signs approvals and contract calls	Controls the user’s authorization, not protocol rules
Smart-contract interface	Integrator or advanced user	Calls Pool methods directly	Direct access can exist even if a front end fails
Data interface	Dashboard, analytics tool, application	Reads reserve, user, and market data	Reading data does not itself move assets
Governance interface	Voter, delegate, proposer	Submits, votes on, and executes approved changes	Connects collective decisions to privileged actions

This distinction helps when diagnosing an incident. If a popular web interface is unavailable, the core contracts may still be operating. Conversely, a polished front end does not reduce risk in the underlying Pool, oracle, or governance structure.

Governance and permissions

Governance is the mechanism through which some protocol rules can change. In lending markets, those rules can include which assets are supported, collateral parameters, liquidation thresholds, interest-rate strategies, and addresses of protocol components.

The diagram is best read as a reminder to map layers of authority, not as a substitute for checking the live permissions of a specific deployment. Governance voting, permission registries, configuration contracts, timelocks, multisignatures, and implementation upgrades can all be separate pieces of the control system.

When mapping governance, write down:

1. Who proposes and votes?
2. What authority does an approved proposal receive?
3. Which contract or role can enact the change?
4. Which components can that role alter?
5. Is execution immediate, delayed, or subject to another control?

Later lessons will examine these powers as risk assumptions. For now, the key is to make them visible on the map rather than treating the protocol as permanently fixed.

External dependencies

An external dependency is something outside the core lending contracts that can still affect outcomes. For Aave, important dependencies include:

Dependency	Why it matters
Underlying blockchain	Provides transaction ordering, execution, finality, and blockspace
Underlying token contracts and issuers	A reserve asset may have its own issuer, blacklist rules, upgrade logic, or market risks
Price sources behind the oracle	Collateral values and liquidation eligibility depend on trustworthy, timely prices
Liquidator ecosystem	Smart-contract liquidation rules require external actors to actually send liquidation transactions during stress
Wallets, RPC providers, and front ends	Affect users’ ability to observe and submit transactions, though they are usually not the lending logic itself
Other DeFi protocols	aTokens, collateral assets, and borrowed funds may be reused elsewhere, transmitting risk across systems

Notice the difference between a contract-level dependency and an economic dependency. The Pool can technically execute without a liquidator being online at a particular moment. Yet if no liquidator acts during a sharp price decline, the market may accumulate losses. That makes liquidators economically essential even though they are independent actors.

---

A reusable mapping workflow

Use this workflow for any DeFi protocol, whether it is a lending market, exchange, stablecoin, vault, or derivatives platform.

1. Fix the scope. Name the protocol version, chain, market, and date.
2. Start from a user action. Choose one action such as deposit, swap, borrow, mint, or stake.
3. List every asset touched. Include the original asset, receipt tokens, debt tokens, reward tokens, and treasury claims.
4. Identify the execution contract. Find the contract that receives the principal user transaction.
5. Add supporting contracts. Include pricing, accounting, configuration, access control, and rate-calculation components.
6. Map control separately from use. Mark who can change parameters, addresses, implementations, or emergency settings.
7. Separate interfaces from dependencies. A front end is an interface; an oracle feed or underlying chain is a dependency.
8. Label each relationship. Use verbs such as “supplies,” “mints,” “prices,” “configures,” “authorizes,” “reads,” or “liquidates.”

A map is complete enough for initial due diligence when every major box answers three questions:

• What does it control or represent?
• Who can interact with it?
• What does it depend on?

Do not claim that an element is decentralized merely because it is on-chain. Instead, identify the relevant authority, dependency, and path of control.

---

Key takeaways

A DeFi protocol map is a structured account of actors, assets, contracts, controls, access routes, and dependencies. In the Aave V3 example:

• suppliers, borrowers, and liquidators are distinct economic roles;
• underlying tokens, aTokens, and debt tokens represent different kinds of assets or claims;
• the Pool is the main execution entry point, but surrounding contracts provide permissions, configuration, pricing, and rate logic;
• governance and privileged roles form a control layer that must be mapped separately from ordinary user activity;
• oracles, the underlying chain, token issuers, liquidators, and access infrastructure all create dependencies beyond the core Pool contract.

In the next lesson, you will use this map operationally: tracing a specific asset from deposit through its protocol representation and eventual withdrawal using documentation and a block explorer.