Aries Aries flash-loan fees formed part of the repayment requirement
Aries flash loans required settlement of the principal plus an asset-specific fee. In a same-token repayment, a positive fee increased the token amount that had to return to the reserve. The historical Aries Markets lending design on Aptos also described repayment using a different token, subject to its settlement conditions. Flash borrowing supplied temporary liquidity within one transaction, while ordinary collateral-backed borrowing created debt that could remain open. The fee therefore belonged in the repayment calculation before any surplus counted toward the operation’s return. Aries Markets has wound down. Historical fee settings alone do not establish whether new flash loans remain accessible.
Last updatedThe asset reserve determined the flash-loan charge
Each supported asset had its own reserve configuration, including a flash-loan fee parameter. An operation that changed the borrowed asset could therefore face a different charge, even without changing its general purpose. The setting described the cost of temporary borrowing from that reserve. It did not describe the cost of every action that the application performed with those funds. Combining a loan with another operation could introduce additional charges, depending on the contracts involved.
A historical percentage described a particular configuration. It did not establish a permanent rate for every asset or deployment.
How did the fee change the repayment amount?
For repayment in the borrowed token, the amount due equaled the principal plus the applicable flash-loan fee. The reserve configuration expressed the flash-loan fee in hundredths of a basis point. If its raw setting was q, the corresponding fractional rate was q / 1,000,000. The fee calculation was therefore principal × q / 1,000,000, before any rounding that the implementation required. Confusing this raw integer with a percentage would change the calculation substantially.
The principal and fee needed compatible units. A token quantity expressed in its smallest units could not mix directly with a display quantity expressed in whole tokens. Token precision and the contract’s arithmetic determined the executable repayment amount. A rounded display could hide a shortfall that remained material in the token’s smallest units.
Flash borrowing and collateral-backed debt had different obligations
Flash borrowing settled its temporary obligation within the transaction that supplied the funds. Ordinary borrowing against collateral could leave debt outstanding after a successful transaction. Collateral requirements belonged to that ongoing lending position; they did not create extra time for flash-loan settlement.
Could repayment use a different token?
The historical token-agnostic design described borrowing one token and repaying with another. That flexibility still required enough acceptable tokens to settle the obligation. A count of tokens alone did not establish equivalent repayment across different assets. The same-token formula described like-for-like settlement; a different repayment token required the applicable rule for what quantity qualified as sufficient repayment.
A surplus in an arbitrary token did not necessarily cover the obligation that remained due. Repayment required an acceptable asset and amount under the interface in use. No universal exchange rate followed from the token-agnostic feature itself.
Execution costs survived an aborted transaction
Aptos charged gas for transactions that committed with an aborted execution. An abort prevented the application changes from completing, but it did not erase the network’s execution charge. The flash-loan fee and gas covered different things: access to temporary liquidity and blockchain processing. A transaction that Aptos discarded without committing incurred no on-chain gas charge. Larger or more complicated applications could also consume different amounts of gas, independently of the reserve’s flash-loan percentage.
The settlement deadline limited flash-loan applications
The borrowed liquidity had to support an operation that settled within the same transaction. Waiting for a later transaction to supply the repayment funds exceeded that boundary. An application involving swaps also depended on the output that those swaps actually produced. The loan amount alone said nothing about whether the surrounding operation could cover its costs. Contract compatibility mattered because the application needed to use the liquidity and satisfy repayment within the permitted execution.
Successful repayment established settlement. It did not establish profit, especially when an application used additional funds from the sender to close the loan.
A repayment margin before transaction submission
In a hypothetical historical same-token case, assume an enabled reserve had enough liquidity for a principal of 1246 token units. The fee due was 3.21 units. Assume the token supported the decimal precision used here. Assume the application would have 1250.48 units available for repayment under the initial conditions or 1248.96 units under reduced-output conditions, after its other protocol charges.
The repayment requirement was 1246 + 3.21 = 1249.21 units. Both outcomes needed comparison against that same obligation. Network gas remained outside these token-balance calculations.
A simulation that projected 1250.48 units before repayment showed 1.27 units after repayment. That amount represented a surplus before the separate network charge. The reader could inspect this result without submitting a transaction or moving the loan funds on-chain.
For the reduced-output simulation, the assumed balance before repayment was 1248.96 units, a shortfall of 0.25 units. Under the assumed requirement, the application could not complete repayment from that output alone. The reader could leave the transaction unsubmitted and change the proposed operation.
A changed fee or execution output would change the repayment margin. A reserve balance below 1246 units would make the assumed loan unavailable. Submitting it exposed the transaction’s fee payer to execution costs, and successful on-chain execution did not provide a manual undo option.
Did a successful simulation guarantee a completed flash loan?
A successful simulation did not guarantee successful on-chain execution. Aptos simulation previewed a transaction’s effects and costs without charging an execution fee. It evaluated the transaction against a particular state, while submission could occur after relevant balances or parameters changed. The repayment calculation also needed the same asset types and amount units as the actual transaction. A preview of an incomplete operation could not demonstrate that the complete borrowing and settlement would succeed.
A successful submission response confirmed that the node had accepted the transaction. Only a successful committed execution established that the borrowing and settlement completed. A committed abort left the transaction’s fee payer with a gas charge and no completed application operation.
Still have questions?
Did a larger repayment amount mean that the flash-loan rate had risen?
A larger repayment amount did not, by itself, establish a fee-rate increase. A larger principal also increased the absolute fee at an unchanged percentage. Changing the borrowed asset could introduce a different reserve setting. Comparing the fee rate required the same unit convention, while comparing repayment totals also required the principal and settlement asset.
Which reserve balance constrained the possible flash-loan amount?
The cash available in the lending reserve constrained the liquidity that an application could borrow. Total deposits could include assets that borrowers already held, so they did not necessarily equal immediately available funds. The available balance was a funding constraint, not proof that a particular request satisfied every configuration or execution condition.
How did a rejected request differ from an aborted flash-loan transaction for gas purposes?
A request that Aptos discarded without committing incurred no on-chain gas charge. A committed abort incurred gas charges even though the application failed. A submission error, a pending response, and a committed abort described different states. The final transaction state determined whether the committed-execution gas rule applied.
Can a transaction signature confirm that a flash loan was repaid?
A signature alone did not confirm repayment. It authorized the transaction data, while the network still had to accept and execute the transaction. Submission could precede either success or failure. Repayment completion required successful execution of the transaction containing the loan and its settlement, not merely a signed request or transaction identifier.
Was the withdrawal fee the same setting as the flash-loan fee?
Different fee parameters covered withdrawals and flash-loan settlement. The withdrawal fee related to redeeming a liquidity-provider receipt for its underlying asset, while the flash-loan fee added to the amount needed for loan settlement. A fee quote for one operation did not price the other.