Key Components

LendingPool: The core contract orchestrating all lending and borrowing operations. It holds the state of each reserve (asset) and user configurations. Through LendingPool, users can deposit assets, withdraw collateral, borrow funds, repay loans, choose interest rate modes, and even perform flash loans. This contract delegates to the library logic for validations and interest calculations, and it updates the global state whenever actions occur. It ensures that actions are only executed when the pool is not paused and enforces the rules (e.g., checking collateral sufficiency when borrowing).

LendingPoolAddressesProvider & Configurator: These auxiliary contracts manage the addresses of PrimeFi’s components and enable the addition or configuration of new asset markets. The AddressesProvider holds references to the active LendingPool, price oracle, interest rate strategy contracts, etc., while the LendingPoolConfigurator (accessible only by admins) can initialize new reserves (deploying new aToken and debt token contracts for each asset) and tweak parameters. For example, when a new asset is listed, the configurator sets up its aToken, debt tokens, interest rate strategy, and links the incentives controller.

aToken (Interest-Bearing Token): For each supported asset, PrimeFi issues an ERC20-compliant aToken that represents a user’s deposit in that asset. The aToken balance grows in value as interest accrues – rather than increasing the token count, the aToken uses an internal index to track interest. When a user deposits, LendingPool mints aTokens to the user’s address at the current liquidity index. Conversely, when withdrawing, aTokens are burned. The aToken’s override of balanceOf() multiplies the holder’s underlying scaled balance by the latest interest index, so the balance reflects principal + earned interest. The aToken contract also directs actual underlying asset transfers; on deposit, the underlying is sent into the aToken contract (becoming pool liquidity), and on withdrawal or borrow, the aToken contract sends the underlying out. Each aToken is associated with a specific asset and is upgradable (via proxies) to allow future improvements.

StableDebtToken & VariableDebtToken: These tokens represent a borrower’s debt for each asset, in stable and variable rate mode respectively. They track the amount owed by borrowers. Like aTokens, debt tokens use an index system. A variable debt token’s balance scales up with accrued interest over time, using a variable borrow index, while a stable debt token records a fixed interest rate and accrues interest by increasing the total debt owed (not the token balance). When a user borrows, the LendingPool calls the debt token’s mint() to create debt tokens for the borrower, and when a loan is repaid, the debt tokens are burned accordingly. These tokens allow the system to account for interest on loans: at any point, a borrower’s debt token balance (principal + interest) represents their outstanding loan.

Interest Rate Strategy: Each reserve is linked to an InterestRateStrategy contract (specifically DefaultReserveInterestRateStrategy) that encapsulates the parameters for that asset’s interest model. This contract defines the asset’s optimal utilization (U_optimal) and the slopes/base rates for stable and variable interest. Whenever a reserve’s state is updated (e.g. liquidity added or removed), the LendingPool calls the strategy to calculate new rates. The strategy computes the current variable borrow rate, stable borrow rate, and liquidity (deposit) rate based on the formulas described earlier (utilization and piecewise slopes). These rates are stored in the reserve’s state and applied until the next update. By adjusting strategy parameters per asset, PrimeFi can calibrate risk levels (for example, a volatile asset might have a lower U_optimal or steeper rates to compensate for liquidity risk).

Price Oracle: To determine borrowers’ borrowing power and handle liquidations, PrimeFi uses price oracles (e.g. Chainlink feeds) for asset valuations. The PriceOracle (accessible via the AddressesProvider) provides up-to-date prices for each asset, which the LendingPool queries when users borrow or withdraw to ensure the user’s Loan-to-Value (LTV) and health factor remain in safe ranges. If an action would violate collateralization limits (e.g. withdrawing too much collateral or borrowing beyond the allowed LTV), the transaction is rejected by ValidationLogic. The oracle is also used in liquidation to determine whether a loan is under-collateralized and to calculate collateral amounts to seize.

Collateral Manager (Liquidation): In the event a loan’s health factor falls below 1, a liquidation can be triggered. PrimeFi includes a collateral manager (similar to Aave’s) that allows liquidators to repay a portion of the unhealthy loan on behalf of the borrower and in return claim an equivalent value of the borrower’s collateral (plus a bonus). The LendingPool exposes a liquidationCall function (as in Aave) to facilitate this. This mechanism is an on-chain decision process ensuring bad debt is cleared: it checks the user’s configuration and debt, uses oracle prices, and enforces that only up to a certain close factor of the debt can be liquidated in one go. If liquidation occurs, the borrower’s aTokens are transferred to the liquidator (or burned to release underlying) and their debt is reduced accordingly.

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 each aToken and possibly debt tokens). Key data include each pool’s allocation points (relative weight in reward allocation) and the accumulated reward per share for that pool. It also stores each user’s info (staked amount and a rewardDebt for that pool). When rewards are emitted, each pool’s share is proportional to its allocPoint, and within a pool, users receive PRFI proportional to their share of the pool’s total supply. The Chef contract receives hook calls from aTokens and debt tokens on any balance changes (thanks to the IAaveIncentivesController interface integration) – this triggers the handleActionAfter function to update the user’s accrued rewards in that pool. Internally, it calculates the new accRewardPerShare, updates the user’s pending reward (adding any newly earned portion to a claimable balance), and updates the user’s stored amount and rewardDebt to the new values. This design means reward distribution is “real-time”: with each deposit, withdrawal, or transfer, the rewards are accounted for automatically. The ChefIncentivesController can be configured with a reward emission schedule (it supports setting varying rewardsPerSecond over time), and the PrimeFi team can adjust pool allocation points (e.g. to reward certain markets more). Only the authorized Pool Configurator can add new pools or change allocations, preserving security.

MultiFeeDistribution & Fee Rewards: To handle the distribution and claiming of reward tokens, PrimeFi uses a MultiFeeDistribution (MFD) contract (along with a MiddleFeeDistribution as an intermediary). The MFD acts as an aggregator that holds reward tokens and allows users to claim them, possibly with time locks or the option to stake for boosted rewards. The MiddleFeeDistribution contract, in particular, mints PRFI tokens and splits protocol earnings. According to its design, it “distributes fees to the platform and rewards to stakers”. When rewards are due, this module can mint the appropriate amount of PRFI (since prfiToken is IMintableToken here) and allocate it: a portion may go to an operations/treasury account (according to an expense ratio), and the rest to the MultiFeeDistribution for users. This is how PrimeFi funds the ongoing reward emissions (separate from the interest paid by borrowers). The MFD then allows users to claim their accrued base rewards (as calculated by the Chef controller) and may also handle any bonus distributions (like the NFT profit-share) in a unified interface. Notably, if users meet the criteria (e.g. holding Prime NFTs), they can receive additional reward streams via the same MFD contract, which consolidates base lending rewards, fee profit-sharing, and other incentives for the user.