> For the complete documentation index, see [llms.txt](https://docs.primefi.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.primefi.xyz/deep-dive/know-your-algorithm/key-components.md).

# Key Components

**LendingPool:** The core contract orchestrating lending and borrowing operations and storing reserve and user configuration state. Through `LendingPool`, users can deposit assets, withdraw, take variable-rate loans, repay, and perform flash loans. The inherited Aave v2-style ABI includes an `interestRateMode` argument and stable-rate-related internals, but every live reserve on Base, HyperEVM, and XDC has stable borrowing disabled. The contract delegates validation and interest calculations to libraries, updates reserve state during actions, checks pause state, and enforces collateral requirements.

**LendingPoolAddressesProvider & Configurator:** These auxiliary contracts manage PrimeFi component addresses and reserve configuration. The **AddressesProvider** holds references to the active LendingPool, price oracle, interest-rate strategies, and other components. The admin-controlled **LendingPoolConfigurator** can initialize reserves, associate their pToken and debt-token implementations, set an interest-rate strategy, link an incentives controller, and change supported risk parameters. These privileged actions are an administrative trust boundary.

**pToken (Interest-Bearing Deposit Token):** PrimeFi's user-facing name for its Aave v2-derived interest-bearing token is **pToken**; some source-code types and inherited interfaces still use the term `aToken`. For each reserve, the holder has an internal scaled balance. `balanceOf()` applies the reserve's current liquidity index to that scaled balance, so the externally reported pToken balance reflects accounted principal plus accrued supplier interest. Deposits mint pTokens and withdrawals burn the applicable amount. The pToken contract holds or transfers reserve liquidity as directed by `LendingPool`. This underlying-denominated accounting is not a guarantee of immediate redemption: withdrawals remain subject to available liquidity, solvency, pause state, and contract validation.

**VariableDebtToken (vdToken) and StableDebtToken Internals:** Live PrimeFi borrowing uses **VariableDebtToken** balances, exposed to users as vdTokens. A borrow mints variable debt, repayment burns it, and the balance grows through the reserve's variable borrow index. Aave v2-derived deployments may still contain `StableDebtToken` contracts, types, events, or storage fields for architectural compatibility, but stable borrowing is disabled across live Base, HyperEVM, and XDC reserves; those artifacts do not describe an available stable-rate user flow.

**Interest Rate Strategy:** Each reserve is linked to an **InterestRateStrategy** contract, such as `DefaultReserveInterestRateStrategy`, that encapsulates that reserve's utilization target, base rate, and rate-curve slopes. When reserve state changes, `LendingPool` asks the strategy to calculate updated variable-borrow and liquidity rates. Inherited interfaces may also calculate or expose stable-rate values, but those values do not enable stable borrowing when the reserve configuration disables it. Parameters are reserve-specific and should be read from the deployed configuration.

**Price Oracle:** The oracle referenced by the AddressesProvider supplies asset valuations used for borrowing power, Health Factor, withdrawal validation, and liquidation calculations. `ValidationLogic` rejects actions that fail collateral requirements based on the values returned at execution. Where an oracle accepts pushed updates, authorised pusher roles are a critical trust boundary: authorization controls who may submit data but does not itself prove that a submitted price is fresh, accurate, deviation-bounded, or supported by executable market depth. Stale or erroneous prices—and prices for low-liquidity collateral—can cause excessive borrowing, missed or wrongful liquidations, and bad debt. Pausing an affected market may limit exposure, but pause authority, response time, and the restrictions imposed while paused create their own risks. See [Risks & Assumptions](/deep-dive/know-your-algorithm/risks-and-assumptions.md).

**Collateral Manager (Liquidation):** When a position's Health Factor is below 1, an external liquidator can call `liquidationCall()` on the `LendingPool`. The liquidation logic checks the user's debt and collateral configuration, uses oracle prices, and applies the relevant limits. The liquidator repays debt and receives pTokens or released underlying collateral; the borrower's variable debt is reduced. LTV, liquidation threshold, and liquidation bonus are reserve-specific. Liquidation reduces unhealthy debt but does not guarantee that all bad debt is cleared or that the protocol remains solvent.

**ChefIncentivesController (Reward Distributor):** This is the primary contract implementing PrimeFi’s reward distribution algorithm. It is called “Chef” because it is based on the MasterChef pattern. The Chef contract maintains data for each reward **pool** (which corresponds to a PrimeFi token that can earn rewards—typically a pToken and possibly a debt token). Key data include each pool’s allocation points and accumulated reward per share. It also stores each user’s amount and `rewardDebt`. When rewards are emitted, each pool’s share is proportional to its allocation, and within a pool users accrue PRFI according to their recorded share. The controller receives balance-change hooks from pTokens and configured debt tokens through an inherited `IAaveIncentivesController`-compatible interface; `handleActionAfter` updates pool and user accounting. Emission schedules, eligible pools, and allocation points are configurable by authorised roles, so displayed or historical rewards are not guarantees of future emissions.

**MultiFeeDistribution & Fee Forwarding:** PrimeFi uses **MultiFeeDistribution (MFD)** for configured staking, vesting, and reward-token accounting, with **MiddleFeeDistribution** as an intermediary for supported fee/reward assets. The deployed implementation's `forwardReward()` transfers token balances it already holds: it may first send the configured operation-expense share, then forwards the remaining balance to MultiFeeDistribution and notifies applicable vesting/reward accounting. `MiddleFeeDistribution` does **not** mint PRFI merely because its token interface is mintable. Reward creation, funding, eligibility, locking, and distribution should be documented from the specific responsible contracts and live configuration rather than attributed collectively to MFD. Planned NFT profit sharing is not an active MFD guarantee.