Pacfinance
Pacfinance borrowing linked collateral limits to debt and repayment on Blast
Last updated -
Pacfinance borrowing used eligible collateral in Blast lending markets to support interest-bearing loans with account-specific limits and repayment obligations. Its original application later became unavailable and the protocol became deprecated. Borrowers owed the selected debt asset plus accrued interest, with eligible supplied assets supporting the loan. Available borrowing capacity described collateral headroom, while reserve settings and liquidity imposed additional constraints. A successful partial repayment reduced an obligation; full settlement required the relevant debt balance to reach zero.
Borrowing tied the chosen reserve to an account obligation
The Pool’s borrow call identified the requested asset, amount, rate mode and account carrying the debt. Its onBehalfOf parameter specified that account, separately from the caller. A signature authorized the proposed action; successful execution created the corresponding borrowing obligation. A transaction hash alone did not establish whether execution succeeded or which account carried the resulting debt. The transaction’s execution result and corresponding debt change distinguished a completed borrow from an unsuccessful attempt.
The Pool’s getUserAccountData method connected the loan to its collateral by returning total collateral, total debt, available borrowing capacity, liquidation threshold, loan-to-value and health factor. Fields ending in Base expressed common valuation units, rather than quantities of whichever token the borrower selected. A meaningful comparison kept the Pool and borrower address consistent, then matched each amount to its unit. A repayment amount used the debt asset’s units; the account’s totalDebtBase expressed its value on the market’s common basis. Subtracting an unconverted token quantity from that account total would mix different units.
What limited borrowing beyond the collateral calculation?
Reserve permissions and available liquidity limited borrowing alongside the account’s collateral capacity. Borrowing required an active, unfrozen, unpaused reserve with borrowing enabled. Core checks covered any applicable borrow cap, isolation ceiling, efficiency-mode restriction, siloed-borrowing rule and price-oracle sentinel.
Loan-to-value, or LTV, governed the debt collateral could support, while the liquidation threshold contributed to the account’s health calculation. A health factor below 1 could permit liquidation of eligible collateral while debt remained. Core borrowing validation also required a pre-borrow health factor above 1. Current capacity could differ from an earlier reading after prices, debt or collateral changed. The selected reserve’s underlying cash imposed a separate liquidity constraint on releasing the requested asset.
A legacy account’s capacity reading did not establish that a new borrowing interface remained available.
Repayment connected the debt asset, rate mode and borrower
Repayment addressed a particular borrowing balance, so its asset, rate mode and borrower fields needed to match. The Pool exposed repay and repayWithPermit, and PacPoolWrapper exposed distinct ETH and ERC-20 repayment methods. These entry points handled different inputs; they did not make native ETH interchangeable with every ERC-20 token.
The requested payment and the amount actually applied to debt were separate concepts. The remaining balance determined whether the selected obligation had closed.
Accrued interest formed part of outstanding debt, so the original loan’s principal could understate a later repayment requirement. The reserve’s debt record represented the obligation at the relevant state, and repayment changed that borrowing record. An unchanged collateral balance did not by itself indicate failure because debt could decrease while supplied collateral stayed in place. Native-yield claims used another operation: NativeYieldDistribute paid claimed yield to the caller without invoking Pool repayment.
The April 1, 2024 Salus audit recorded a patch disabling new stable-debt minting in Pacfinance’s v3 code. Stable-related function names in the inherited interface therefore did not establish access to new stable loans. Repayment still needed the rate mode matching the existing debt.
How could a completed repayment leave debt outstanding?
A partial repayment could complete successfully while leaving a positive debt balance in the selected reserve. For this hypothetical legacy repayment, assume the deployed Blast Pool still permits the action. The account holds variable-rate debt of 38.78 underlying-token units immediately before repayment, including accrued interest. The holder has enough of that token and the required spending authorization.
The holder submits a 12.46-unit repayment against their own debt account. Signing authorizes that instruction; successful Pool execution commits the repayment. If the full 12.46 units reduce debt and no other balance changes intervene, 38.78 - 12.46 = 26.32 units remain. A post-transaction record showing 26.32 confirms the expected partial reduction and records the remaining obligation at this state.
A later comparison needs the same Blast Pool, borrower, debt asset and rate mode because interest accrual or another repayment can change the balance. A zero balance would establish settlement of this selected debt at that state, while other reserve debts would retain their separate obligations.
A rejected repayment did not reduce debt
Core repayment validation required an active, unpaused reserve and debt in the selected rate mode. A NO_DEBT_OF_SELECTED_TYPE rejection meant no outstanding debt matched the supplied rate mode for that borrower and reserve; other account debts could still remain. The selected obligation could already have closed, or the call could have targeted a different asset, mode or borrower.
An asset, mode or borrower mismatch called for correcting the repayment target. Changing the payment amount could not clear a reserve’s pause flag. Repeatedly submitting the same rejected call addressed neither cause, and a spending authorization supplied no evidence of debt reduction. An unexpected result required the affected reserve’s debt record, rather than an assumption that the entire account had closed.
What separated loan repayment from collateral withdrawal?
Repayment reduced borrowing debt, while withdrawal redeemed a supplied position through a separate Pool operation. Settling one reserve’s debt did not settle loans elsewhere, so remaining borrowing could still make supplied collateral relevant to account health. Withdrawal still depended on account health and the reserve’s available cash, even after the selected debt closed.
DeFiReclaim described withdrawal support for selected legacy Pacfinance positions on Blast. Its route redeemed aTokens through the original Pool, subject to wallet-specific eligibility and liquidity checks. That withdrawal support did not establish access to new borrowing or repayment for every loan. An account with settled debt and illiquid supplied assets faced a withdrawal constraint; an account carrying debt retained a borrowing obligation.
Pacfinance borrowing questions worth asking
Can someone else repay a legacy Pacfinance loan?
The historical Pool allowed repayment on another borrower’s behalf through onBehalfOf, provided the call specified an explicit amount and satisfied the selected reserve’s repayment checks; the maximum-value shortcut for repaying the selected debt applied only when the caller repaid their own account.
Did the Pool allow borrowers to repay using their aTokens?
The historical Pool exposed repayWithATokens for repayment using the caller’s aTokens in the same reserve. Its parameters selected the asset, amount and rate mode, and the call identified the caller as the debt account. This operation differed from redeeming aTokens through a third-party withdrawal Router.
Could a frozen Pacfinance reserve still accept repayment?
Freezing alone did not block repayment in the core validation logic, although inactivity or pausing did. Borrow validation separately rejected frozen reserves. A reserve could therefore prevent additional borrowing while allowing debt repayment, provided the repayment satisfied the active-reserve, pause and debt-mode checks.
Does approving ERC-20 spending reduce a legacy loan balance?
An ERC-20 approval authorizes a spender to use tokens without reducing the borrower’s debt. The Pool must execute the matching repayment operation to reduce that obligation. A successful approval transaction therefore establishes spending permission, while the repayment result and debt record establish the reduction.
How did a permit-based Pacfinance repayment handle token authorization?
The historical Pool exposed repayWithPermit for repayment assets implementing the required permit interface. It passed the signature’s deadline and authorization fields to the asset’s permit method before running repayment. This path combined permit processing with repayment in one Pool call, subject to the token’s signature checks and the reserve’s repayment conditions.